Topic: Network-enforced performance-bonded dominant assurance contracts (Read 3733 times)

Done and done. I quoted you directly in the web page translation example. Thanks, Mike!

Feel free to edit the page as you see fit. I'd move the examples onto the main Contracts page, perhaps at the start of the section on assurance contracts, then link to the DAC scheme from the end of that section - replace the part where I leave it as an exercise for the reader.

nLockTime works but transaction replacement doesn't, and non-final transactions are accepted to the memory pool and held there.  This is what I didn't understand about nLockTime and why I thought this contract would be usable as soon as P2SH comes out.  Now that I get it, I had to revise the contract to keep track of nLockTime.

I've been working on unit tests for transaction replacement and discussing with people on IRC about it.  I think I'll write a post shortly.  There are lots of places to mess up in trying to re-enable transaction replacement so I'm looking over the existing Contracts page to see what use cases there are and how to accommodate them without introducing weird bugs and perverse incentives.  I think transaction fees are going to become more important with any change to transaction replacement/nLockTime behavior to keep miner incentives aligned.  I believe that in actuality, most if not all the use cases can be taken care of by changing the semantics of nLockTime to mean non-final transactions can't enter the memory pool at all and modifying the schemes to work with that assumption rather than the assumption that transaction replacement will be turned back on.

On that note, I put this scheme on the wiki in a form that assumes transaction replacement will happen.  Mike, I didn't want to link it from your Contracts page without your review/approval.

Kickstarter implements assurance contracts yes. They also add a lot of other value on top, like a nice web UI, curating the projects list, advising projects on how to get funding, etc. I don't think they're going anywhere anytime soon even ignoring that Bitcoin is rather small

I'm more interested in applications that Kickstarter can't manage, due to overhead. For example, consider a browser extension that you send a bit of money to. It detects the current language of the page and broadcasts a pledge for a translation into your language to be prepared. If enough users with the extension land on the same page at the same time (eg, it was linked to from somewhere high traffic), then enough pledges are broadcast to trigger a payment to a company who prepares a high quality translation. When complete it automatically loads in your browser.

This describes a decentralised 'Kickstarter.com' does it not? They seem to be doing pretty well these days, but I might need to add them to my creative destruction list.

nLockTime is enabled and working, as far as I know.

Alternative SIGHASH codes should all work, even on standard transactions. IsStandard checks for the overall script structure but does not examine the precise signature types used.

I think you could just work on the UI side for OP_CHECKMULTISIG. People/miners will be upgrading in parallel to your development effort. It'll probably take some experimentation to find something that works well.

This is a very interesting discussion, exactly the kind of stuff I want to address with Armory when the time comes...

I really like the idea of incentivizing miners, and I'm sure any specific multi-sig scheme like this can be made straightforward with enough UI innovation.  as long as we don't build too much flexibility and options into it, which will really complicate things.  But this may be a very specific case worthy of its own UI just for miner incentivization, and particularly important with the pending block reward decrease.

I believe nLocktime technically works, but replacement is completely disabled, which means a lot of different kinds of contracts are not feasible.  Is locktime currently usable, even without replacement?  (i.e. can we create locked transactions that become valid in the future?)

There's also a strong reliance on alternate hashcodes, which by themselves are pretty powerful.  However, I am similarly unclear about the availability of alternate hashcodes.  I'm sure they are non-standard, but are they completely disabled?  Will a block be rejected by the Satoshi client if it involves a alternate hashcode?  If so, will nodes also forward those transactions?

I think the Bitcoin contracts page is a great place for the theoretical discussion, but I'm intensely interested in what will actually be usable when multi-sig is enabled.  Mainly because I'm planning to tackle multi-sig UIs in Armory at full speed, once it is enabled on the network, but I need to focus on what will actually be accepted by the network, right now.

I think an interesting direction to go with this is network assurance contracts, let's call them NACs for lack of a better term. They are a practical application of the technology.

The basic idea is a new p2p network, perhaps using the existing pubsub mechanism as a co-ordination system, in which nodes are given some money and a target network speed. They broadcast assurance contracts in which the outputs are consumed by timelocked transactions that spend the entire value as fees. nLockTime allows you to specify a time in either block numbers or seconds, so you can have each output be consumed by a transaction locked to one higher block number than the previous to produce a set of incentives for each block.

Nodes on the network pledge on seeing a valid assurance contract being set up that meets their parameters. Pledging means broadcasting a SIGHASH_ANYONECANPAY style transaction that pays to the pre-determined set of outputs. Once enough pledges are collected the finished transactions are broadcast across the Bitcoin network, thus incentivizing mining.

One problem to solve is how to ensure the money collected is in fact used for network security:

• A node sees that network speed appears to be dropping below the tolerance specified by its owner.
• It broadcasts a proposal for an assurance contract of, say, 10 BTC claimable at a lock time of current block number + 5 blocks, and asks who is interested. The proposal includes a key.
• 5 other nodes indicate their willingness to participate, states how much they'd be willing to contribute, and each one also includes a fresh public key.
• Once each node sees that there are enough offers, they independently construct the assurance contract transaction such that its only output is a CHECKMULTISIG with every broadcast key, and the nodes own input is signed with SIGHASH_ANYONECANPAY. The keys in the output are sorted so every node derives the same structure.
• After deriving the shared transactions, each node broadcasts the signed input to the contract.
• On receiving the complete set of signatures/inputs, each node sorts the inputs, merges them together to create the shared assurance contract, then creates the fee tx which spends the contract to an output of zero value and has a lock time of the agreed upon time (all value goes to fees). The nodes sign that transaction and broadcast their signatures.
• The first node that receives a copy of every signature builds the fee transaction, and then broadcasts the assurance contract and fee transaction together.
• In 5 blocks time miners will now be incentivized to mine in order to claim the 10 BTC.

Although the protocol is fairly complex with multiple stages, it's probably fast enough that it can be run over and over every block interval, thus ensuring that every block has an incentive transaction.

This model of funding network security is, I think, economically superior to attaching fees to every broadcast transaction, because network security is a public good and it uses well known techniques from economics to resolve that. Only people who care about network speed would need to take part. The market would set the consensual speed target. Trade amongst trusted parties would not necessarily need to contribute any fees at all.

Open problems mostly revolve around DoS potential. These sorts of multi-step protocols are often vulnerable to halting attacks.

Due to my previous misunderstanding of nLockTime semantics, corrected here, I'd like to add that the transaction in 3d should have a non-final version number (
Thanks for getting in touch with Mark, Mike.

Oh dear. I emailed Mark about it. Hopefully the wiki will be back soon.

You're right, it could just say "multisig."

Let me see about creating an account on the Wiki so I can put this up.

Is there any vulnerability that I haven't thought of, like bribery/collusion/coercion/etc., that could make this fail and wouldn't be public enough to damage the reputations of the perpetrator(s)?

ETA: I can't seem to create an account on the Wiki (it's asking me to enable my cookies... interesting) and it looks like the Wiki has been spammed, at least on the front page (look at the bottom with the links to jewelry and sunglasses).

Looks pretty reasonable. I find it easier to follow explanations that don't involve P2SH (which is just an optimization), but that's just me.

Want to put it on the wiki page? Or maybe create a new page just for DACs and then link it, as it's fairly involved.

This is an attempt at Mike Hearn's "exercise for the reader." It relies on P2SH (or multisig) and nLockTime, with no transaction replacement.

1. A vendor agrees to produce a good if X BTC are raised by date D and to pay Y BTC to each of n contributors if X BTC are not raised by date D, or to pay nY BTC if X BTC are raised and the vendor fails to produce the good to the satisfaction of 2 of 3 independent arbitrators picked through a fair process
2. The arbitrators create a 2-of-3 P2SH address with a public key from each arbitrator, which will allow them to judge the performance on actually producing the good
3. For each contributor:
3a. The vendor and the contributor exchange public keys
3b. They create a 2-of-2 P2SH address from those public keys
3c. With no change, they create a transaction with an input of X/n BTC from the contributor and an input of Y BTC from the vendor, with X/n+Y going to the address created in 3b
3d. The vendor signs a transaction of the entire balance of the transaction in 3c over to the contributor with nLockTime of D and gives it to the contributor
3e. The contributor signs a transaction where the output is X+nY to the address created in step 2 and the input is the output of the transaction in 3c, signed using SIGHASH_ALL | SIGHASH_ANYONECANPAY and gives it to the vendor
4. As date D nears, nLockTime comes close to expiration.
4a. If enough (n) people contribute, all of the inputs from 3e can combine to make the output valid, creating a valid transaction sending that money to the arbitrators, which only agree to release the funds when the vendor produces a satisfactory output
4b. If not enough people (<n) contribute, nLockTime expires on the transaction in 3d, meaning each contributor can sign and redeem her transaction containing X/n + Y BTC from 3c
4c. Note that there is a limit at which it can be more profitable for the vendor to make the remaining contributions when D approaches