Post
Topic
Board Development & Technical Discussion
Re: Assurance contracts
by
titeuf_87
on 06/10/2012, 15:23:19 UTC
Earlier I was just thinking about detecting double spends and I didn't think further about actually knowing how much has already been pledged.

It is possible to fulfill the assurance contract even if you don't know how much each input is worth but that's not a road I want to take: it involves bringing in all pledges together in one transaction, submitting it to a bitcoin node and if it somehow gets in a block then we know that we had enough pledges. But this has so many downsides that I won't try this.

Quote
The TransactionInput class would need to support caching of the values of the connected outputs. When a transaction is extracted from the chain normally the input values don't matter, you only care about the output values. For pledges you do care. Protobuf serialization would need to be upgraded so you can record that as well.
Agree, this will be needed here.

Quote
We still have the problem as you stated of knowing what the output is. One is that bitcoind could get a new JSON-RPC to inspect the set of unspent outputs. It means some C++ hacking. Other projects can benefit too. Alternatively, Matt Corrallo has upgraded bitcoinj to be fully validating. I am reviewing and merging his code at the moment. Once that work is merged, it could all be done within Java. I think that approach is probably superior as you have enough control to avoid some tricky race conditions.
I'll wait till this is implemented in bitcoinj, especially if the code's already written Smiley

Quote
The Wallet class needs to understand what to do with pledges. I guess a wallet could contain both regular valid transactions and pledges. When you try and construct a spend, it would gather all the pledges that shared an identical output and see if the assurance contract can be completed. If so then it's counted towards your balance and will be used to construct a spend. If not, then no. I think TransactionConfidence might need an extension to reflect that the pledge tx is completely invalid.
There also needs to be a distinction to know if the assurance contract sends the bitcoins to an address owned by that wallet or not.

The way I imagined this is that people can create assurance contracts on a website for a certain amount of bitcoins to be sent to a certain bitcoin address that they choose. The server manages the collecting of pledges and creates the actual transaction when there are enough. At no point will it be able to spend any of the bitcoins, which I think is a big plus as if the server gets cracked into then no one loses any bitcoins.

Quote
One question is, what if you have a wallet with regular funds and some pledges, and you construct a spend that wants the value of all of them? You can merge the pledges together, but you can't then merge that completed contract together with another arbitrary transaction. I think the Wallet API needs to be upgraded to support creating multiple transactions as part of a spend. It doesn't play so well with the current design Sad Alternatively you could just impose some basic restrictions for now, like stating a wallet can contain pledges XOR regular funds. It's probably not an issue in practice.
Creating more than one transaction as part of a spend would also be nice too for when an user does not have the correct output values in order to pledge (for instance user has a 20 and 30 BTC transaction but wants to pledge 25 BTC)
But I won't worry about it for now as this is not really needed, just a nice bonus Smiley