After slush added sendmany support to his miner, the transactions are confirmed fairly quickly. There are a lot more patched bitcoin instances and the network propagation is also much better.
There is a small bug in the GUI. After sending the sendmany transaction, only one of the "legs" of the transaction is shown and the debit amount is incorrect. It fixes after GUI restart or just after switching tabs from "all transactions" to "sent", after which the transaction is shown as two or more separate transactions as it should.
Topic: [PULL] sendmany RPC command (Read 7825 times)
Be aware that the sendmany transactions will take a very long time to get accepted at the current stage of the Bitcoin network. I sent a sendmany transaction yesterday morning and it still has not reached any 0.3.21 version mined block. Since the old bitcoind versions do not even relay such transactions, unless you mine with 0.3.21 or are connected to a node that accepts such transactions, you are not going to get it confirmed.
This feature was written pool servers in mind. It seems likely that pool operators -- they who mine a lot of blocks anyway -- will upgrade sooner rather than later.
173.255.224.227 (bitcoincharts.com) will accept and relay sendmany transactions to miners that'll include them into their blocks within a day (on average).
Be aware that the sendmany transactions will take a very long time to get accepted at the current stage of the Bitcoin network. I sent a sendmany transaction yesterday morning and it still has not reached any 0.3.21 version mined block. Since the old bitcoind versions do not even relay such transactions, unless you mine with 0.3.21 or are connected to a node that accepts such transactions, you are not going to get it confirmed.
Looks great! This will not only improve scalability and ease of use but make the block explorer output look a bit more intuitive as well :-)
It looked pretty reasonable when I gave it a quick read through. Are there any such transactions on the testnet for us to look at/test with?
Sure, here's one:http://blockexplorer.com/testnet/tx/0d6c3d3470a89e4be56df04e80a9b7da1855bbe2cf07c1e99e22e0212688eb8b
It looked pretty reasonable when I gave it a quick read through. Are there any such transactions on the testnet for us to look at/test with?
How the old miners will check the doublespending if money was spend earlier with new transaction type?
It is not a new transaction type-- transactions could always have multiple TxOuts.
However, to prevent a denial-of-service attack (which was actually attempted-- see block 71036) transactions with more than 2 TxOuts are currently dropped by clients instead of relayed.
Now that there is a need for it, the rules allow "reasonable" multi-output transactions, but still denies "unreasonable" ones (reasonable means: is one of the 2 standard transaction types and only does one ECDSA signature verification per recipient).
So: no, this won't cause a block chain split. And no, old miners will not disagree with new miners, so double-spending is not possible.
They just won't relay them.
If transaction is not replicated and understood by all miners there is a potential of doublespending with malicious setup.
How the old miners will check the doublespending if money was spend earlier with new transaction type?
If doublespending transaction of old type is confirmed by the block from old miner - will the new miner reject such a block and create a fork of the chain?
The old clients will still accept these sendmany transactions if they get into a block. They just won't relay them. I suppose accepting 0-confirmation sendmany transactions might be more risky, but confirmed transactions are just as secure.
Please explain the checks in more details.
I doesn't see incorrect transactions in my scenario. Miner with new version validates transaction to the cleint with new version and it is perfectly valid transaction with good inputs.
So it is possible for miner with old version to confirm the second transaction. And that transaction will be perfectly valid for him.
(I assume, that old client rejects the particular transaction, but acceps the block chain from the new miner. Otherwise there will be a chain fork)
Which basic checks will not pass ?
Thus, anyone who creates a block may create a non-standard transaction, but that transaction -- once it makes it into a block -- must still be verified by the same basic checks that guard against incorrect signatures, double-spending, etc.
I doesn't see incorrect transactions in my scenario. Miner with new version validates transaction to the cleint with new version and it is perfectly valid transaction with good inputs.
Old clients will refuse to relay sendmany transactions
So it is possible for miner with old version to confirm the second transaction. And that transaction will be perfectly valid for him.
(I assume, that old client rejects the particular transaction, but acceps the block chain from the new miner. Otherwise there will be a chain fork)
Which basic checks will not pass ?
Old clients will refuse to relay sendmany transactions
Using this way anyone with new client can doublespend money - send once to client with new version, then send second time to the client with old version.
If someone confirm the second transaction (which is theoretically possible, while not everybody miner update their software), the money will be doublespent.
I think you misunderstand the latitude miners are given.
A block may only belong to the 'best' chain if its transaction inputs may be connected and verified.
Thus, anyone who creates a block may create a non-standard transaction, but that transaction -- once it makes it into a block -- must still be verified by the same basic checks that guard against incorrect signatures, double-spending, etc.
Old clients will refuse to relay sendmany transactions
Using this way anyone with new client can doublespend money - send once to client with new version, then send second time to the client with old version.
If someone confirm the second transaction (which is theoretically possible, while not everybody miner update their software), the money will be doublespent.
If I can setup old and new client in different virtual machines - will I be able to double my money? and repeat that again in 10 minutes?
Old clients will refuse to relay sendmany transactions
Using this way anyone with new client can doublespend money - send once to client with new version, then send second time to the client with old version.
If someone confirm the second transaction (which is theoretically possible, while not everybody miner update their software), the money will be doublespent.
Code:
sendmany {address:amount,...} [minconf=1] [comment]
amounts are double-precision floating point numbers
https://github.com/bitcoin/bitcoin/pull/106amounts are double-precision floating point numbers
Need for this is being driven by mining pool operators; it is much more efficient to pay lots of people with one transaction rather than lots of little transactions.
Old clients will refuse to relay sendmany transactions, so to ensure timely inclusion in a block mining pool operators should either upgrade together and connect their clients together or wait until a good percentage of the network has had a chance to upgrade to the next version of bitcoin.
Examples of use from a bash command-line (note you have to quote the second 'object' argument because the {} characters are interpreted by bash):
Code:
bitcoind sendmany "" '{"mvTt8hav6e9ESjSrXJ1yaJhyULHv8ywcN7":50}' 1 "To the Faucet"
bitcoind sendmany "SomeAccount" '{"myeTWjh876opYp6R5VRj8rzkLFPE4dP3Uw":10,"mikZVLuasDcY1Jmph3rqgT1NXfjB1srSEc":15,"mvTt8hav6e9ESjSrXJ1yaJhyULHv8ywcN7":50}'
bitcoind sendmany "SomeAccount" '{"myeTWjh876opYp6R5VRj8rzkLFPE4dP3Uw":10,"mikZVLuasDcY1Jmph3rqgT1NXfjB1srSEc":15,"mvTt8hav6e9ESjSrXJ1yaJhyULHv8ywcN7":50}'
Jump to: