Topic: Multi-party Transactions (Read 1419 times)

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.

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


Thanks for your help

In that case it would seem that you are trying to generate an output (not an input).

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

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?

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?

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.

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.

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.

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.

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: = b to i>
                Index:
                scriptSig: SIGHASH_ALL

        (For each address j in B)

            Output:

                Value: X BTC
                scriptPubKey: OP_DUP OP_HASH160 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?