Bitcoin Forum
November 22, 2017, 11:58:50 AM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Multi-party Transactions  (Read 1290 times)
nnn
Jr. Member
*
Offline Offline

Activity: 42


View Profile
January 15, 2013, 02:42:22 PM
 #1

I am looking to construct a multi-party transaction.


Here's the scenario:

- I have a set of N addresses, call it A
- I have another set of N addresses, call it B


I wish to build a transaction such that:

- Each address in A inputs at least X BTC (any extra is given as a tx fee)
- Each address in B receives as output X BTC
- It is only valid when each address in A signs the transaction


This is how I think that it should be done:

    Transaction:

        (For each address i in A)

            Input:

                Previous tx: <a standard tx with an output >= b to i>
                Index: <an appropriate index from the previous tx>
                scriptSig: <signature from i> <public key of i> SIGHASH_ALL

        (For each address j in B)

            Output:

                Value: X BTC
                scriptPubKey: OP_DUP OP_HASH160 <hash of j's public key> OP_EQUALVERIFY OP_CHECKSIG
       


Is this on the right lines?




Now I understand that SIGHASH_ALL requires a signed hash of all of the transaction, bar the input scriptSigs. Am I correct in thinking that this means that each i in A can sign the transaction in turn, without risk of the transaction becoming valid untill all inputs are signed?

1511351930
Hero Member
*
Offline Offline

Posts: 1511351930

View Profile Personal Message (Offline)

Ignore
1511351930
Reply with quote  #2

1511351930
Report to moderator
1511351930
Hero Member
*
Offline Offline

Posts: 1511351930

View Profile Personal Message (Offline)

Ignore
1511351930
Reply with quote  #2

1511351930
Report to moderator
1511351930
Hero Member
*
Offline Offline

Posts: 1511351930

View Profile Personal Message (Offline)

Ignore
1511351930
Reply with quote  #2

1511351930
Report to moderator
Join ICO Now A blockchain platform for effective freelancing
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1511351930
Hero Member
*
Offline Offline

Posts: 1511351930

View Profile Personal Message (Offline)

Ignore
1511351930
Reply with quote  #2

1511351930
Report to moderator
1511351930
Hero Member
*
Offline Offline

Posts: 1511351930

View Profile Personal Message (Offline)

Ignore
1511351930
Reply with quote  #2

1511351930
Report to moderator
kjj
Legendary
*
Offline Offline

Activity: 1302



View Profile
January 15, 2013, 03:06:43 PM
 #2

The actual signature prep stage is complicated, but basically with SIGHASH_ALL alone, you can't change any important part of the transaction without invalidating the signature.  You can neither add, nor remove, nor reorder the inputs.  Ditto with the outputs.

Keep in mind that the hash flags are a property of the signature, not properties of the transaction.

p2pcoin: a USB/CD/PXE p2pool miner - 1N8ZXx2cuMzqBYSK72X4DAy1UdDbZQNPLf - todo
I routinely ignore posters with paid advertising in their sigs.  You should too.
DannyHamilton
Legendary
*
Offline Offline

Activity: 1988



View Profile
January 15, 2013, 03:39:00 PM
 #3

Note that your transaction seems to require that each party have a previous transaction prepared that has a single output equal to X (or slightly more).

If I were intending to be a party to this transaction on the supply side, and I only have the private key to a single address that had only received 3 previous outputs each less than X, but which when added together result in a value of 1.49(X) then I would first have to create a transaction to myself accumulating those 3 previous outputs into 2 new outputs (one valued at X and one valued at 0.49X).

I'd run into a similar problem if I only have the private key to a single address that had only received a single previous output of 100(X).  Unless I want to contribute 99(X) as a transaction fee, I would first need to create a transaction using my 100X output as an input and generate 2 outputs (one valued at X and one valued at 99X).  Then I'd need to make sure that the output valued at X is used in your transaction rather than the output valued at 99X.

Seems to me it would be better if each input participant could contribute as many outputs from as many addresses as they want as long as the total of the participants contributions is >= X.  It also seems like it would be better if each input participant were allowed to contribute a single output to an address of their choosing so long as the difference between the total of their contributed inputs and their contributed output is >= X.

In the case of my suggestions, I wouldn't have to generate extra transactions in my scenarios above.

In the first scenario I could contribute all three of my existing outputs (since their total is >= X) and I could contribute an output of 0.489X.  This would result in 0.489X back to me (or to wherever/whomever I wish), 0.001X as a transaction fee, and X available for the B address in your transaction.

In the second scenario I could do something similar, contributing the 100X input to the transaction and supplying a 98.999X output.  This would result in 98.999X back to me (or to wherever/whomever I wish), 0.001X as a transaction fee, and X available for the B address in your transaction.

nnn
Jr. Member
*
Offline Offline

Activity: 42


View Profile
January 15, 2013, 06:08:06 PM
 #4

Yes, this was something that I had considered.

Unfortunately other aspects of my application are made considerably simpler by having everyone input and output the same amounts. I am building off of BitcoinJ though, so I will be able to automate the creation of these 'pre' transactions for the user.
Mike Hearn
Legendary
*
expert
Offline Offline

Activity: 1526


View Profile
January 15, 2013, 06:45:11 PM
 #5

Your understanding is correct. You can send the unsigned transaction to each party, and each party can then send the signature for their own input to everyone else.
nnn
Jr. Member
*
Offline Offline

Activity: 42


View Profile
January 15, 2013, 06:53:49 PM
 #6

Great!

Mike, If you have a second:
Does BitcoinJ provide an easy way to generate an input with a certain amount, or does this need to be done manually?
DannyHamilton
Legendary
*
Offline Offline

Activity: 1988



View Profile
January 15, 2013, 07:12:43 PM
 #7

Great!

Mike, If you have a second:
Does BitcoinJ provide an easy way to generate an input with a certain amount, or does this need to be done manually?

When you say "generate", I assume you mean "select"?  I'm sure you are aware that you don't generate the amount in the input, you select previous outputs and use them as inputs.  So I'm guessing that you are asking if there is an easy way to find the previous output (associated with an address?  associated with an account? associated with a wallet?) that is closest to a requested value without being less than the value?

nnn
Jr. Member
*
Offline Offline

Activity: 42


View Profile
January 15, 2013, 08:50:00 PM
 #8

By "generate" I mean to imply that you may have to create a new transaction to combine some inputs.
DannyHamilton
Legendary
*
Offline Offline

Activity: 1988



View Profile
January 15, 2013, 08:51:18 PM
 #9

By "generate" I mean to imply that you may have to create a new transaction to combine some inputs.
In that case it would seem that you are trying to generate an output (not an input).

nnn
Jr. Member
*
Offline Offline

Activity: 42


View Profile
January 17, 2013, 01:06:49 PM
 #10

Well an output to immediately be used as an input. This is all just semantics really.


Thanks for your help Smiley
Mike Hearn
Legendary
*
expert
Offline Offline

Activity: 1526


View Profile
January 17, 2013, 01:51:45 PM
 #11

The API is pretty straightforward. Take a look at some of the example apps and documentation on the website. Ask on the mailing list if you get stuck.
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!