Topic: Crazy notion about multisig transactions. (Read 1673 times)

Bob            Bill
A               BC
|_>___10___|| Bob escrows $10 in increments of 2+4+4=10
|____20__<__| Bill escrows $20 in increments of 4+8+8=20

When the escrows are in place, Bob send artwork worth $10 to Bill
Then Bill sends the private key C to Bob. Bob gets $20 worth of BTC and moves it into a secure address.
A                B
|_____10___|
Bob may then send key A to Bill. Bill get's the $10 worth of BTC and moves it to a secure address. If Bob does not send Private key A to Bill then he is an arrse (that's a cross between a pirate and a donkey).

Another option would be to create seperate escrows for each and every amount, and then reverse them slowly rather than all at once. It would take longer, but then the risk that if the seller releases the escrow means he won't get his full payment either.

I dont fully understand it. but it sounds like it makes sense.

You might want to look at multi-party computation. It's a way for people to compute over inputs whilst keeping those inputs private, in a group:

  http://en.wikipedia.org/wiki/Secure_multi-party_computation

I mention it because MPC works by building up "circuits" made up of "gates" that are created out of cryptographic primitives, mostly linear secret sharing. Your MPC program is made of such gates.

Can you make diagram of this? I don't get it as text.. but concept is very nice one

I've come up with another idea based on another discussion. This can get more complex if you add m-of-(2m-1) third party arbitration.

Bob has artwork on craigslist and Bill wants to buy it. Neither trusts the other. Bob is asking $10.
1. Bob creates an address A, Bill creates 2 addresses B,C. Bob creates a 2-of-2 using AB, Bill creates a 2-of-2 using AC
2. Bill sends a 2 of 2 transaction of $4
3. Bob sends a 2 of 2 transaction of $2
4. Bill sends another 2 of 2 transaction using the same addresses of $8
5. Bob sends another 2 of 2 transaction of $4
6. Bill sends another 2 of 2 transaction using the same addresses of $8
7. Bob sends another 2 of 2 transaction of $4
8. Bob sends the artwork to Bill
This can be done in greater of fewer steps until a desired escrow equilibrium is achieved. Bob no longer has the artwork and $10 is in escrow. Bill has $20 in escrow. Bill sends the key to Bob for the $20, then Bob sends the key to Bill for the $10.
This can also be done with each step using different sets of keys A, B, &C. A₁, B₁, &C₁ etc.

heh, yeh m-of-(2m-1) I'll correct that.
The current is built up over time, but that isn't important because it's more like old fashioned relay switches. The number of parties would be volunteering to run such an open source client and would be kept honest by signing to acknowledge they are using deterministic transaction keys. Other sources could be mining or transaction fees, even small amounts add up over a time.

I don't think you really need to get into timing analogies until you talk about digital circuits.

^ I keep smiling after seeing this brainstorm.

Did you mean m-out-of-(2m-1) - a simple majority?

Also, does the resistance simply mean the output would be proportional to the fraction of parties who signed the transaction?

For the analogy to work, you'll need equivalents of current (number of coins per unit time?) and voltage (driving force - maybe the fraction of parties agreeing to the transaction?).

Most multisignature and escrow transactions can be handled by m-of-m and m-of-(2m-1) transactions. These cover 1-of-1, 2-of-2, 3-of-3, 2-of-3, 3-of-5, and so on. These will probably be the most common and most useful transactions. It's when you get into m-of-n transactions that things get really interesting.

Standard m-of-n transactions:
I'll call these resistors. Let's say you have 8 keys. You can have the output private key created to be solved by 1,2,3,4,5,6,7,or all 8 private input keys. Each level acts like increased resistance to passing the Bitcoin current. They can be any random m from the distributed set or they can be required to be sequential m that are randomly distributed. They can even be a combination of both depending on how you design the circuit.

Nested inside of the 8 input transaction could also be several smaller m-of-m or m-of-(2m-1) transactions. For instance, the even numbered inputs could be a 2-of-3 transaction that solves input 1 of the same transaction circuit. By designing a series of circuits, you can create logic gates.

Capacitors: These are merely loads on each address. In order to make a useful circuit, you need a reliable power source so a pre-determined amount of Bitcoin would need to be applied. Requests would need to be issued for these amounts.

Transistors:
Different transistors can be created by signing gates that provide outputs that overcome an m-of-n barrier or merely adds to the resistance load of the main input circuits, depending on the outputs of other areas of the circuit.

This analogy is based on my limited math and technical training, but I can see the usefulness here of writing a client that uses the Bitcoin Network for something useful. At the moment all I can think of is a sort of decentralized Ponzi scheme. Maybe that's not a bad thing if it is Provably Fair.