Ok lets set this straight since the developers have stopped communicating with us and trying to fix the issue. I have gone above and beyond to make anoncoin work on our exchange. I kept the ANC wallet open when bittrex shut it down to not lock customers from their funds
This was made impossible by the false accusations and general slander from the community and developers themselves
I will say it again. I manage 236 wallets. ANC is the only one to have this issue. And it is NOT a cryptsy issue.
Pay special attention to the bold text
I've done this, but considering i've turned off the wallet, this code is never going to get hit... Is there an easy way to clear this first?
The wallet is disconnected from your exchange software, but it still has many unspent outputs, right? I would create an address in a second Anoncoin wallet, and send a very large amount to it (hence causing a large transaction to be generated) from the wallet with customer accounts. Later, after fixing this problem and before reconnecting the first wallet to the exchange, send that ANC back to it. I don't know the internals of your exchange software, but this would not cause problems for exchanges I have worked with.
I should also mention that this code will only get hit with the "sendtoaddress" RPC command.
Inputs are pretty well merged in our wallet so i had some trouble creating transaction of that size. I moved some around in bunches of 25k
Doesn't appear to be anything useful. Its down to the smallest inputs in that wallet now so ill send the results again after 24 hours
After roughly 20 blocks none of the transactions have been picked up. This caused our security to go a little nuts and paused the ANC market for a few minutes
Cool, thanks for your help. It looks like the check where we added the print statements is always being executed.
It's interesting that none of the transactions were picked up. I'm not sure why that's the case...
Anyway, the next step is to see whether nodes are refusing to relay these transactions, and if so, why. On line 670 of main.cpp, where it says:
Please change it to:
Compile this and start it with a separate like this "mkdir /tmp/relay_anc_datadir && ./anoncoind -datadir=/tmp/relay_anc_datadir". You'll need to setup anoncoin.conf as usual. This will be your relay node; you'll need to know the IP for the next step. You can grep its debug.log for "DEBUGTXN" to see refusals to relay, though it's possible some of them will be from other nodes.
Going back to the regular wallet you were using before, add the argument "-connect=:9377" where RELAY_IP is the IP above. Now it will only connect to that node. Please start it and create another large transaction (if possible).
richiela, if you read this far, please also do the above
This was made impossible by the false accusations and general slander from the community and developers themselves
I will say it again. I manage 236 wallets. ANC is the only one to have this issue. And it is NOT a cryptsy issue.
Pay special attention to the bold text
Hi Mullick,
I am one of the Anoncoin developers, and I want to work with you to see if we can get to the bottom of this. So the issue appears to happen when you create a transaction and it is greater than 100KB. By design, such a transaction will not be relayed in the network.
What RPC commands are you using to create and send these transactions?
Thanks,
Gnosis
I am one of the Anoncoin developers, and I want to work with you to see if we can get to the bottom of this. So the issue appears to happen when you create a transaction and it is greater than 100KB. By design, such a transaction will not be relayed in the network.
What RPC commands are you using to create and send these transactions?
Thanks,
Gnosis
Hello,
Thanks for the reply
The onlycommand issued to our daemons for withdrawal is a "sendtoaddress"
The problem seems to be anoncoind is allowing the transactions instead of reporting "Transaction creation failed" out "Transaction too large" It just happily creates the transactions pretends all is well
Our wallet does have a few thousand unspent inputs which we have been merging on and off to reduce tx sizes
If there is anything else that would help please let me know
-Mullick
mullick@cryptsy.com
Thanks for the reply
The onlycommand issued to our daemons for withdrawal is a "sendtoaddress"
The problem seems to be anoncoind is allowing the transactions instead of reporting "Transaction creation failed" out "Transaction too large" It just happily creates the transactions pretends all is well
Our wallet does have a few thousand unspent inputs which we have been merging on and off to reduce tx sizes
If there is anything else that would help please let me know
-Mullick
mullick@cryptsy.com
If you are only executing "sendtoaddress", then that should perform the size checks to make sure the created transaction is under 100KB. This looks like a bug in our code.
However, from looking at the source of recent versions (see below), it doesn't look like it's possible -- I don't see any way the check could not be performed. What version are you running?
master branch: https://github.com/Anoncoin/anoncoin/blob/master/src/wallet.cpp#L1294
newbase branch: https://github.com/Anoncoin/anoncoin/blob/newbase/src/wallet.cpp#L1320
However, from looking at the source of recent versions (see below), it doesn't look like it's possible -- I don't see any way the check could not be performed. What version are you running?
master branch: https://github.com/Anoncoin/anoncoin/blob/master/src/wallet.cpp#L1294
newbase branch: https://github.com/Anoncoin/anoncoin/blob/newbase/src/wallet.cpp#L1320
I have tried both the master and the previous official release. Currently we are running the master branch
What does "git rev-parse HEAD" say?
Thanks for the reply. Here ya go
Code:
git rev-parse HEAD
fffef88265b965c6d9b6d5ee64e0a9406699018d
fffef88265b965c6d9b6d5ee64e0a9406699018d
Almost done merging inputs as well
Started with over 100k
Started with over 100k
Code:
Remaining are 11672 unspent inputs.
85b72e5119946d6589569cb3f36e796aebdc13e1bc38f0959e7186df5591fd39
85b72e5119946d6589569cb3f36e796aebdc13e1bc38f0959e7186df5591fd39
I just confirmed with bittrex they seem to be having the same issue
Quote
Mullick
https://bitcointalk.org/index.php?topic=227287.msg8354734#msg8354734
Thats what our unconfirmed transactions looked like
@bittrex-richie
"amount" : -969.26520089,
"fee" : -0.60000000,
"confirmations" : 0,
"txid" : "838e3b333ac6a64e5eed95c320bdee2ff2121dac170a634fbe498f739d2257c9",
yeah.. looks to be similar
do they never clear?
Mullick
One of the devs had to solomine with a modified daemon to allow larger transaction sizes
They got most of ours confirmed
nm daemon wasnt modified he just decalred max tx sizes in the anoncoin.conf
Mullick
You could remove it from your wallet and resend after 48 hours as well
after 48 hours it should be cleared from everyone mempool
@bittrex-richie
those both seem like ridicoulous answers
Mullick
lol yep
If they dont have the fix in by the time mintsy goes live ill modify the mintsy daemon to confirm those transactions
https://bitcointalk.org/index.php?topic=227287.msg8354734#msg8354734
Thats what our unconfirmed transactions looked like
@bittrex-richie
"amount" : -969.26520089,
"fee" : -0.60000000,
"confirmations" : 0,
"txid" : "838e3b333ac6a64e5eed95c320bdee2ff2121dac170a634fbe498f739d2257c9",
yeah.. looks to be similar
do they never clear?
Mullick
One of the devs had to solomine with a modified daemon to allow larger transaction sizes
They got most of ours confirmed
nm daemon wasnt modified he just decalred max tx sizes in the anoncoin.conf
Mullick
You could remove it from your wallet and resend after 48 hours as well
after 48 hours it should be cleared from everyone mempool
@bittrex-richie
those both seem like ridicoulous answers
Mullick
lol yep
If they dont have the fix in by the time mintsy goes live ill modify the mintsy daemon to confirm those transactions
So I think this is easier with all 4 of us on one PM thread. Let's try to keep it that way
Mullick, I have confirmed with you that you're building from source. richie, if you aren't, please check out the master branch from our repo (https://github.com/Anoncoin/anoncoin).
At any rate, I would like you both to patch this into your src/wallet.cpp around line 1295. Where it says this:
Replace it with this:
...and then recompile and re-deploy. You can then submit large transactions and search debug.log for "DEBUGTXN". Let me know what you find when this problem happens again.
Thanks,
Gnosis
Mullick, I have confirmed with you that you're building from source. richie, if you aren't, please check out the master branch from our repo (https://github.com/Anoncoin/anoncoin).
At any rate, I would like you both to patch this into your src/wallet.cpp around line 1295. Where it says this:
Code:
// Limit size
unsigned int nBytes = ::GetSerializeSize(*(CTransaction*)&wtxNew, SER_NETWORK, PROTOCOL_VERSION);
if (nBytes >= MAX_STANDARD_TX_SIZE)
{
strFailReason = _("Transaction too large");
return false;
}
dPriority /= nBytes;
unsigned int nBytes = ::GetSerializeSize(*(CTransaction*)&wtxNew, SER_NETWORK, PROTOCOL_VERSION);
if (nBytes >= MAX_STANDARD_TX_SIZE)
{
strFailReason = _("Transaction too large");
return false;
}
dPriority /= nBytes;
Replace it with this:
Code:
// Limit size
unsigned int nBytes = ::GetSerializeSize(*(CTransaction*)&wtxNew, SER_NETWORK, PROTOCOL_VERSION);
if (nBytes >= MAX_STANDARD_TX_SIZE)
{
strFailReason = _("Transaction too large");
printf("DEBUGTXN: disallowing txn %s because size (%d bytes) not less than max (%d bytes)\n",
wtxNew.GetHash().ToString().c_str(), nBytes, MAX_STANDARD_TX_SIZE);
return false;
}
else
printf("DEBUGTXN: allowing txn %s because size (%d bytes) less than max (%d bytes)\n",
wtxNew.GetHash().ToString().c_str(), nBytes, MAX_STANDARD_TX_SIZE);
dPriority /= nBytes;
unsigned int nBytes = ::GetSerializeSize(*(CTransaction*)&wtxNew, SER_NETWORK, PROTOCOL_VERSION);
if (nBytes >= MAX_STANDARD_TX_SIZE)
{
strFailReason = _("Transaction too large");
printf("DEBUGTXN: disallowing txn %s because size (%d bytes) not less than max (%d bytes)\n",
wtxNew.GetHash().ToString().c_str(), nBytes, MAX_STANDARD_TX_SIZE);
return false;
}
else
printf("DEBUGTXN: allowing txn %s because size (%d bytes) less than max (%d bytes)\n",
wtxNew.GetHash().ToString().c_str(), nBytes, MAX_STANDARD_TX_SIZE);
dPriority /= nBytes;
...and then recompile and re-deploy. You can then submit large transactions and search debug.log for "DEBUGTXN". Let me know what you find when this problem happens again.
Thanks,
Gnosis
I've done this, but considering i've turned off the wallet, this code is never going to get hit... Is there an easy way to clear this first?
The wallet is disconnected from your exchange software, but it still has many unspent outputs, right? I would create an address in a second Anoncoin wallet, and send a very large amount to it (hence causing a large transaction to be generated) from the wallet with customer accounts. Later, after fixing this problem and before reconnecting the first wallet to the exchange, send that ANC back to it. I don't know the internals of your exchange software, but this would not cause problems for exchanges I have worked with.
I should also mention that this code will only get hit with the "sendtoaddress" RPC command.
Inputs are pretty well merged in our wallet so i had some trouble creating transaction of that size. I moved some around in bunches of 25k
Code:
anoncoind sendtoaddress Ab8Esj3NSpSdi8DqPLJ1EvzHHyJuZbi3kS 25000
6f5b88f4f7b679f46f3f6c51d226180e886402cea45e7125df64b5332af15e08
anoncoind sendtoaddress Ab8Esj3NSpSdi8DqPLJ1EvzHHyJuZbi3kS 25000
61582db98cd0618ae467e5ab306ec04d31456a8fdd3e1bebefa7b3ed6c60883d
anoncoind sendtoaddress Ab8Esj3NSpSdi8DqPLJ1EvzHHyJuZbi3kS 25000
error: {"code":-4,"message":"Transaction too large"}
anoncoind sendtoaddress Ab8Esj3NSpSdi8DqPLJ1EvzHHyJuZbi3kS 20000
cedd565e12483ada162b8f00501969f8b9041d19b19ebc9d15d0308bbdab32ab
anoncoind sendtoaddress Ab8Esj3NSpSdi8DqPLJ1EvzHHyJuZbi3kS 20000
0d02541a95f87d3f09ab9c9cbbec7dc1c4563b0908d9e7a8b35f9089fe5cd3d5
cat debug.log | grep "DEBUGTXN"
2014-10-15 05:28:06 DEBUGTXN: allowing txn aac9d87e2de8753651732af4a5d3ace4443ee868742bbc4bb9e310e463950694 because size (2024 bytes) less than max (100000 bytes)
2014-10-15 05:28:06 DEBUGTXN: allowing txn 6f5b88f4f7b679f46f3f6c51d226180e886402cea45e7125df64b5332af15e08 because size (1337 bytes) less than max (100000 bytes)
2014-10-15 05:28:12 DEBUGTXN: allowing txn 78cecf1250d0ae7b8e5bd3cc737d7549403e9c7b47414a9de193662738bfcc53 because size (4544 bytes) less than max (100000 bytes)
2014-10-15 05:28:12 DEBUGTXN: allowing txn 61582db98cd0618ae467e5ab306ec04d31456a8fdd3e1bebefa7b3ed6c60883d because size (3497 bytes) less than max (100000 bytes)
2014-10-15 05:28:22 DEBUGTXN: disallowing txn 08521fd96fda8cfd9504c5d0f1d1e3cb422ae70fabb21a5752919695ff1f15f0 because size (207955 bytes) not less than max (100000 bytes)
2014-10-15 05:29:31 DEBUGTXN: allowing txn be881799bd459bbab5652fa557ceb3f91658ba2a0c324a539ee1d8a49371fae8 because size (2777 bytes) less than max (100000 bytes)
2014-10-15 05:29:32 DEBUGTXN: allowing txn cedd565e12483ada162b8f00501969f8b9041d19b19ebc9d15d0308bbdab32ab because size (2594 bytes) less than max (100000 bytes)
2014-10-15 05:37:04 DEBUGTXN: allowing txn 1f5f8f0c2255a115679a94412898ee77788c354eea0a894555e114c71c38ec22 because size (19028 bytes) less than max (100000 bytes)
2014-10-15 05:37:04 DEBUGTXN: allowing txn 0d02541a95f87d3f09ab9c9cbbec7dc1c4563b0908d9e7a8b35f9089fe5cd3d5 because size (12610 bytes) less than max (100000 bytes)
6f5b88f4f7b679f46f3f6c51d226180e886402cea45e7125df64b5332af15e08
anoncoind sendtoaddress Ab8Esj3NSpSdi8DqPLJ1EvzHHyJuZbi3kS 25000
61582db98cd0618ae467e5ab306ec04d31456a8fdd3e1bebefa7b3ed6c60883d
anoncoind sendtoaddress Ab8Esj3NSpSdi8DqPLJ1EvzHHyJuZbi3kS 25000
error: {"code":-4,"message":"Transaction too large"}
anoncoind sendtoaddress Ab8Esj3NSpSdi8DqPLJ1EvzHHyJuZbi3kS 20000
cedd565e12483ada162b8f00501969f8b9041d19b19ebc9d15d0308bbdab32ab
anoncoind sendtoaddress Ab8Esj3NSpSdi8DqPLJ1EvzHHyJuZbi3kS 20000
0d02541a95f87d3f09ab9c9cbbec7dc1c4563b0908d9e7a8b35f9089fe5cd3d5
cat debug.log | grep "DEBUGTXN"
2014-10-15 05:28:06 DEBUGTXN: allowing txn aac9d87e2de8753651732af4a5d3ace4443ee868742bbc4bb9e310e463950694 because size (2024 bytes) less than max (100000 bytes)
2014-10-15 05:28:06 DEBUGTXN: allowing txn 6f5b88f4f7b679f46f3f6c51d226180e886402cea45e7125df64b5332af15e08 because size (1337 bytes) less than max (100000 bytes)
2014-10-15 05:28:12 DEBUGTXN: allowing txn 78cecf1250d0ae7b8e5bd3cc737d7549403e9c7b47414a9de193662738bfcc53 because size (4544 bytes) less than max (100000 bytes)
2014-10-15 05:28:12 DEBUGTXN: allowing txn 61582db98cd0618ae467e5ab306ec04d31456a8fdd3e1bebefa7b3ed6c60883d because size (3497 bytes) less than max (100000 bytes)
2014-10-15 05:28:22 DEBUGTXN: disallowing txn 08521fd96fda8cfd9504c5d0f1d1e3cb422ae70fabb21a5752919695ff1f15f0 because size (207955 bytes) not less than max (100000 bytes)
2014-10-15 05:29:31 DEBUGTXN: allowing txn be881799bd459bbab5652fa557ceb3f91658ba2a0c324a539ee1d8a49371fae8 because size (2777 bytes) less than max (100000 bytes)
2014-10-15 05:29:32 DEBUGTXN: allowing txn cedd565e12483ada162b8f00501969f8b9041d19b19ebc9d15d0308bbdab32ab because size (2594 bytes) less than max (100000 bytes)
2014-10-15 05:37:04 DEBUGTXN: allowing txn 1f5f8f0c2255a115679a94412898ee77788c354eea0a894555e114c71c38ec22 because size (19028 bytes) less than max (100000 bytes)
2014-10-15 05:37:04 DEBUGTXN: allowing txn 0d02541a95f87d3f09ab9c9cbbec7dc1c4563b0908d9e7a8b35f9089fe5cd3d5 because size (12610 bytes) less than max (100000 bytes)
Doesn't appear to be anything useful. Its down to the smallest inputs in that wallet now so ill send the results again after 24 hours
After roughly 20 blocks none of the transactions have been picked up. This caused our security to go a little nuts and paused the ANC market for a few minutes
Cool, thanks for your help. It looks like the check where we added the print statements is always being executed.
It's interesting that none of the transactions were picked up. I'm not sure why that's the case...
Anyway, the next step is to see whether nodes are refusing to relay these transactions, and if so, why. On line 670 of main.cpp, where it says:
Code:
if (!fTestNet && !tx.IsStandard(strNonStd))
return error("CTxMemPool::accept() : nonstandard transaction (%s)",
strNonStd.c_str());
return error("CTxMemPool::accept() : nonstandard transaction (%s)",
strNonStd.c_str());
Please change it to:
Code:
if (!fTestNet && !tx.IsStandard(strNonStd)) {
printf("DEBUGTXN: not accepting tx %s into mempool because '%s'\n", tx.GetHash().ToString().c_str(), strNonStd.c_str());
return error("CTxMemPool::accept() : nonstandard transaction (%s)",
strNonStd.c_str());
}
printf("DEBUGTXN: not accepting tx %s into mempool because '%s'\n", tx.GetHash().ToString().c_str(), strNonStd.c_str());
return error("CTxMemPool::accept() : nonstandard transaction (%s)",
strNonStd.c_str());
}
Compile this and start it with a separate like this "mkdir /tmp/relay_anc_datadir && ./anoncoind -datadir=/tmp/relay_anc_datadir". You'll need to setup anoncoin.conf as usual. This will be your relay node; you'll need to know the IP for the next step. You can grep its debug.log for "DEBUGTXN" to see refusals to relay, though it's possible some of them will be from other nodes.
Going back to the regular wallet you were using before, add the argument "-connect=:9377" where RELAY_IP is the IP above. Now it will only connect to that node. Please start it and create another large transaction (if possible).
richiela, if you read this far, please also do the above