Bitcoin Forum

Hi

With using Testnet=1 our and using client we find that after about 300 addresses our RPC calls fail to work with Json.

We create a unique address for each transaction, appreciate we could block off 100 and re-circulate them but would rather not.

We have since started using -daemon and running tests now but has anyone else found this problem via running-qt?

We have ran into this problem 3 times now, obviously we are testing in sandbox mode but don't believe we can be the only ones?

Our transactions have exceeded 1,100 with no problems it's just when the addresses reach over 300.

apart from this everything is smooth.

thanks

FYI
Setup IIS 6 server 2003 and II 7+ server 2008 r2
Php 5.3 (curl)

I just generated 10,000 fine. Are you using a locked wallet and draining your keypool?

thanks for the reply, no it's not locked.

What stops working is->sendfrom

- Balance is always good.
- Usually about 10 pending 0/1 confirmations in queue

all other calls will still work through Json RPC

If nobody else has experienced this then logic says it's something else.

Hopefully someone has seen this before

thanks!

Oh, you're flooding the network with unconfirmed transactions and then noticing further sends start taking forever?

The part of coin selection which traverses unconfirmed change has complexity exponential in the amount of unconfirmed coins in your wallet.

Thanks :)

Please can you suggest the best way to address this issue?

please see my profile for the address of our test site, don't want to spam the forum

or PM me

thanks again!

So this is a simple case of the Minconf=1 on sendfrom to address it?

Okay we have initiated a ->move upon 1 confirmation to parent address and set minconf of 1 on all ->sendfrom and parent address maintaining full balance ownership

Hopefully the right direction

thanks

Let me help you read between the lines of gmaxwell's answer: what you're trying to do is going to result in flooding the bitcoin network with more transactions than could ever possibly be confirmed. Either you will die a quick death from transaction fees, or you won't provide enough fees and your transactions will never be relayed let alone confirmed. So what you're doing won't work for reasons unrelated to this performance 'issue' you've identified.

I would suggest rethinking whatever it is you are trying to do.

Hi Maaku

Thanks, even if all transaction fees are covered are you saying that there is a cap on the amount of transactions that could be processed through the Bitcoin RPC?

We have written these solutions through fiat payment gateways with no issues on load, so here there is a cap?

Apologies for the basic questions happy to discuss via PM and donate for solutions

thanks

The entire network is limited to approximately 7 transactions per second, assuming you're using the smallest transaction possible. That comes from the maximum size of 1 megabyte of transaction data per block, 1 block per 10 minutes. That's not 7 per user, that's 7 transactions total, including everyone else in the entire bitcoin network.

But assuming you keep within these limits, minconf=1 should do it.

EDIT: This is not a permanent cap, but is something that will be fixed in time. However there are technical problems that need to be solved before the bitcoin network can scale to higher capacity.

:) Thanks

This we can fix, we can drip them out

Will test for the next few days

pinging through a donation

Thanks, sending via BitStamp

Sept. 10, 2013 Bitcoin 0.51000000 BTC Waiting to be processed

Sept. 10, 2013 Bitcoin 0.51000000 BTC Finished

Thanks again Maaku

Actually your original posts didn't make it clear that it'd be a one-time burst of transactions. So long as you stay well within those limits on average, it doesn't matter if you do them all at once. Except, as already mentioned, the performance issue which minconf=1 solves. Of course setting minconf=1 has other implications:

(1) If you exhaust the list of confirmed outputs, your sends will fail (because there are no unspent outputs to fund the transaction with). In that case just try again later after some confirmations. A good strategy would be to use -blocknotify to call a script which processes transactions until you exhaust your pool of outputs, then exit and wait for the next block.

(2) If your list of unspent outputs shrinks, as it will from time to time, you may unexpectedly limit yourself. If you have just two unspent outputs, you are limited to no more than 2 transactions per 10 minute block with minconf=1. The solution here is split your largest outputs into a couple of smaller ones (by calling 'getnewaddress' a few times and doing a 'sendmany'), so you once again have a large enough list of outputs available.

(3) You can minimize both these problems by batching all the little transactions you want to do into a single transaction, one per block, if your use case allows it.

As for the 0.51btc: unexpected, but thank-you!

This is straight forward to do, so will set this up.


Not a problem, you are welcome! and thanks for taking the time.