Bitcoin Forum
December 07, 2016, 02:43:47 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: [PULL] sendmany RPC command  (Read 6537 times)
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
March 07, 2011, 07:57:34 PM
 #1

Code:
sendmany <fromaccount> {address:amount,...} [minconf=1] [comment]
amounts are double-precision floating point numbers
   https://github.com/bitcoin/bitcoin/pull/106

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}'

How often do you get the chance to work on a potentially world-changing project?
1481121827
Hero Member
*
Offline Offline

Posts: 1481121827

View Profile Personal Message (Offline)

Ignore
1481121827
Reply with quote  #2

1481121827
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481121827
Hero Member
*
Offline Offline

Posts: 1481121827

View Profile Personal Message (Offline)

Ignore
1481121827
Reply with quote  #2

1481121827
Report to moderator
ArsenShnurkov
Legendary
*
Offline Offline

Activity: 1386



View Profile
March 07, 2011, 08:18:26 PM
 #2

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.
Only-One Bit Coiner
Jr. Member
*
Offline Offline

Activity: 42



View Profile
March 07, 2011, 08:30:21 PM
 #3

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?
jgarzik
Legendary
*
qt
Offline Offline

Activity: 1470


View Profile
March 07, 2011, 08:42:54 PM
 #4

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.


Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
ArsenShnurkov
Legendary
*
Offline Offline

Activity: 1386



View Profile
March 07, 2011, 09:02:15 PM
 #5

Please explain the checks in more details.

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 ?
theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 2492


View Profile
March 07, 2011, 09:09:21 PM
 #6

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.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
ArsenShnurkov
Legendary
*
Offline Offline

Activity: 1386



View Profile
March 07, 2011, 09:25:26 PM
 #7

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?
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
March 07, 2011, 09:44:18 PM
 #8

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.

How often do you get the chance to work on a potentially world-changing project?
Mike Hearn
Legendary
*
expert
Offline Offline

Activity: 1526


View Profile
March 08, 2011, 10:26:17 PM
 #9

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?
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
March 08, 2011, 11:07:39 PM
 #10

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

How often do you get the chance to work on a potentially world-changing project?
Mike Hearn
Legendary
*
expert
Offline Offline

Activity: 1526


View Profile
March 09, 2011, 08:34:39 AM
 #11

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 :-)
jgarzik
Legendary
*
qt
Offline Offline

Activity: 1470


View Profile
March 17, 2011, 10:14:59 PM
 #12

You can see two 'sendmany' transactions in block 113931:

     http://blockexplorer.com/b/113931


Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
Raulo
Full Member
***
Offline Offline

Activity: 238


View Profile
March 17, 2011, 10:44:35 PM
 #13

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.

1HAoJag4C3XtAmQJAhE9FTAAJWFcrvpdLM
tcatm
Sr. Member
****
qt
Offline Offline

Activity: 337


View Profile
March 17, 2011, 10:52:30 PM
 #14

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).
jgarzik
Legendary
*
qt
Offline Offline

Activity: 1470


View Profile
March 17, 2011, 11:54:16 PM
 #15

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.

Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
Raulo
Full Member
***
Offline Offline

Activity: 238


View Profile
March 26, 2011, 12:20:53 PM
 #16

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.

1HAoJag4C3XtAmQJAhE9FTAAJWFcrvpdLM
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!