3 ms·

I'm glad someone finally made this. What do you think about potentially offering more complicated schemes in the future? For example, supporting say three arbi

by ryan-c 13y ago

I'm glad someone finally made this. What do you think about potentially offering more complicated schemes in the future? For example, supporting say three arbitrators, requiring two to agree? You could do this as follows: Seller: Keys S1 and S2 Buyer: Keys B1 and B2 Arbitrators: Keys A1, A2, A3 (one per arbitrator) You then do a 4-of-7 multisig transaction. This generalizes to buyer, seller and N-of-M arbitrators: Seller gets N keys Buyer gets N keys Arbitrators each get one key Actual transaction is 2N of M + 2N.

nadaviv 13y ago
This could be a cool idea, but Bitcoin currently artificially limits the total number of public keys to 3, but that limitation will probably be lifted at some point. Also, in the future, you won't really need hacks like that to make something like that work - Bitcoin has a scripting language that allows you to specify much more complex conditions than m-of-n. You could specify something like `2 of (buyer, seller, (2 of (arb1, arb2, arb3)))`. But currently, the scripting language is limited to a specific white-list of allowed script templates, and doesn't allow doing stuff like that.
- oleganza 13y ago
  Bitcoin does not artificially limit the total number of keys. Transactions with up to 3 keys are considered "standard" by bitcoind, meaning they will be propagated and mined by default. But non-standard 5-of-8 transactions are also valid. If someone relays them and mines them, they will be valid for every node. In practical terms, non-standard transactions mean longer confirmation time, that's it.
  - nullc 13y ago
    It's a bit more complicated than "longer confirmation times" since normal nodes will not relay them. Realistically, production use of non-standard transactions is unwise, but we'll make anything standard that people have a usecaes for and tests for. ... though in this case, you'd really want to use a script like I described instead of inefficiently using multiple keys per player.
nullc 13y ago
Thats a really inefficient way of encoding it. It would result in a much smaller scriptPubKey to encode something like this instead: S_pub OP_CHECKSIG OP_SWAP B_pub OP_CHECKSIG OP_ADD OP_DUP OP_DUP OP_VERIFY OP_2 OP_EQUAL OP_NOTIF 0 2 A1_pub A2_pub A3_pub 3 OP_CHECKMULTISIGVERIFY OP_ENDIF Or something like that— only the 5 pubkeys involved instead of adding extra ones.
- ryan-c 13y ago
  I'm aware it's inefficient, I was trying to suggest something that would currently be accepted as a standard transaction. I wasn't aware of the three key limit that's mentioned elsewhere in the thread, though, so my suggestion wouldn't be standard anyway.

by ryan-c 13y ago

nadaviv 13y ago

This could be a cool idea, but Bitcoin currently artificially limits the total number of public keys to 3, but that limitation will probably be lifted at some point. Also, in the future, you won't really need hacks like that to make something like that work - Bitcoin has a scripting language that allows you to specify much more complex conditions than m-of-n. You could specify something like `2 of (buyer, seller, (2 of (arb1, arb2, arb3)))`. But currently, the scripting language is limited to a specific white-list of allowed script templates, and doesn't allow doing stuff like that.

oleganza 13y ago
Bitcoin does not artificially limit the total number of keys. Transactions with up to 3 keys are considered "standard" by bitcoind, meaning they will be propagated and mined by default. But non-standard 5-of-8 transactions are also valid. If someone relays them and mines them, they will be valid for every node. In practical terms, non-standard transactions mean longer confirmation time, that's it.
- nullc 13y ago
  It's a bit more complicated than "longer confirmation times" since normal nodes will not relay them. Realistically, production use of non-standard transactions is unwise, but we'll make anything standard that people have a usecaes for and tests for. ... though in this case, you'd really want to use a script like I described instead of inefficiently using multiple keys per player.

nullc 13y ago

Thats a really inefficient way of encoding it. It would result in a much smaller scriptPubKey to encode something like this instead: S_pub OP_CHECKSIG OP_SWAP B_pub OP_CHECKSIG OP_ADD OP_DUP OP_DUP OP_VERIFY OP_2 OP_EQUAL OP_NOTIF 0 2 A1_pub A2_pub A3_pub 3 OP_CHECKMULTISIGVERIFY OP_ENDIF Or something like that— only the 5 pubkeys involved instead of adding extra ones.

ryan-c 13y ago
I'm aware it's inefficient, I was trying to suggest something that would currently be accepted as a standard transaction. I wasn't aware of the three key limit that's mentioned elsewhere in the thread, though, so my suggestion wouldn't be standard anyway.