Topic: Purchasing fidelity bonds by provably throwing away bitcoins (Read 9052 times)

i also see this as a way to embed value to mining, rather than throwing anything away, it is like you walked into the bank and dumped a bag of money on the floor for the customers, that they in turn spend in the economy, creating more cash flow through the system

With the activation of CLTV (BIP65) and CSV (BIP112), generating fidelity bonds is much easier now. Just send bitcoin to a scriptPubKey of


or


Using CSV is preferred since it guarantees that must be known to everyone for the specified time.

Absolutely. After all, they're called "bonds"; it is quite conceivable a judge could be convinced that means the money should be returned to the users in the event of fraud by the entity that purchased the bond if the recipient is well-known.


In the case of fidelity-bonded banks a reasonable thing to do would be to setup a service that runs a the same sort of trusted hardware cryptographic co-processor with remote attestation the banks themselves would use and have that hardware generate secure fidelity bond deposit addresses. The program running on the hardware would then evaluate any fraud proofs produced by defrauded users, and if the proof was valid refund the user from the deposit address. Equally it could just be a trusted company with some lawyers.

It's not the right solution for every purpose, but the underlying technology has the flexibility to be used this way.

Just to jump in and agree with Mike; I would guess the Foundation would prefer not to participate in this as well; you only need to get named in one suit before it just isn't worth it.

Or, put another way, the risk, terms of service, and general impact on operations for the Foundation indicates to me someone else should probably do this. It's not required for Bitcoin's ongoing growth and safety, and is out of our mission therefore.

In this case, though, there might be a business case to be made for an escrow shop or business to do bonded verification. It depends how 'distributed' you want to make things. On balance, I'm not sure why paying miners directly is a bad idea, unless you can work a decentralized scheme where the fidelity bond buyer gets paid back if there are no claims.

I don't think using charities is a good idea. I explained why on this thread on tor-talk:

https://lists.torproject.org/pipermail/tor-talk/2013-January/027036.html
https://lists.torproject.org/pipermail/tor-talk/2013-January/027041.html

I have spent some time and fleshed out my idea for a decentralized reputation system, and it incorporates your idea of using fidelity bonds and has some examples of network rules. Here:

Repcoin: a decentralized reputation currency

I actually really like this idea. Now I do think we'll find that sending fees to charities and other specific entities will turn out to be a very bad idea for applications that need the highest security, but equally there are applications that don't need the security. Aside from that there is the disadvantage that your proof becomes quite large the transaction spending the money now has a bunch of outputs.

However, if this is a popular idea, you can fix that with multisig addresses. Have the 20-odd or whatever charities get together, submit all their private keys, and create a multisig address only spendable when they all co-operate. (or some subset of the total) They'll probably agree to split the money evenly, but in any case, that's up to them to decide. There is the issue that multisig with more than 3 parties isn't supported, the resulting transactions become large, but you can use a non-P2SH secret sharing system too resulting in just one signature.

The best part of the secret sharing design is it will result in just one address like any other, so it'll still be compatible with the "donate to a single charity" functionality. Just make sure that the specification is written in terms of scriptPubKeys rather than addresses and you can handle any case going forward.

I think there is a better way to issue fidelity bond without the need to pay fee to an unknown miner.

We can have list of 20 trustworthy organization like wikipedia, btc foundation, WWF, International Red Cross, Linux foundation etc. To purchase fidelity bond, one has to donate to at least 5 organizations on the list in the amount and in the  same transaction. For example, by donating 1BTC to each of the 5 organizations, you will have 5 unit of fidelity bonds. Therefore, you don't need to worry about being scammed by someone holding the private keys for these organizations, because it is very unlikely that many organizations will cooperate to scam.

Oh, and where I say "hash of a transaction" in the above, replace that with "hash of the signed part of the transaction + sigs with sig representation standardized to defeat the malleability problem"

Also, no need to call it a coin mixing or swapping system really, just call it fast off-chain payments with immediate settlement. If transactions have arbitrary inputs and outputs, and the blinding system works with arbitrary coin values, that's exactly what it is. For instance you could run satoshidice on this system and avoid the blockchain bloat completely.

For stuff like looking for forum sock puppets, sure, donations are ok. But in that case, you almost might as well just ask for payment; it's basically what 4chan does with their Bitcoin to avoid captchas scheme.

However, here's an application where you really do want to be sure the Bitcoins are being thrown away: coin mixing. Or to be exact, coin swapping. While blinded chaum tokens are nice, you do need to trust the server, but that's exactly what a fidelity bond can let you do.

So Bob the banker opens shop by acquiring a fidelity bond for 100BTC, now tied to a keypair under his control. (note that for Bob's IT security, the actual implementation needs to support multiple keypairs for everything) Bob creates an advertisement, signed by that keypair, which contains the information about the fidelity bond, the address(s) that will be used to hold funds, and the public keys that will be used to sign the various denominations of tokens, along with the expiry times of those keys. (expiry block #'s might be safer, or just use nLockTime notation to allow either) Note that this advertisement needs to be something that can be amended and revised, a private blockchain of sorts.

Alice now decides to make a deposit. She downloads the advertisement and checks that the expiry date is sufficiently far into the future, that the fidelity bond is valid, and that the total amount of deposits Bob has accepted to the addresses is sufficiently low that Bob has an incentive to behave honestly. Note how that calculation also needs to include the rate of growth of deposits.

She now takes the scriptPubKey she wants the fund to go to and blinds it to create a chaum token. (I assume the actual implementation would need take the hash or something first? I'm not too familiar with how the math actually works)

Alice now creates a deposit request containing the blinded token and the hash of the transaction she will use to send the funds. Bob responds with a signed deposit acceptance message that includes the hash of his initial service advertisement, Alice's transaction hash and the hash of the signed token Bob will give Alice. (somewhere the # of confirmations required needs to be specified) Alice now publishes her transaction. Once a sufficient number of confirmations have happened Bob finally gives Alice the token itself.

To redeem the token Alice contacts Bob again sometime later anonymously, perhaps through Tor. Equally Alice could give the token to someone else to publish, possibly as payment itself if they are happy with the embedded scriptPubKey. Bob checks the signature and creates a transaction sending the funds to the scriptPubKey. Alice can now spend the funds as required.

Alice could also take that token and use it in a deposit request. She'll need to sign the request with the same keys that would be used to spend the inner scriptPubKey. She may also want/have to include a normal transaction to pay fees, and equally she could specify that the change is returned... of course this is looking kinda like a transaction isn't it...


If Bob doesn't give her the signed, blinded token she can prove Bob's fraud with the merkle path from the transaction to a block, and Bob's signed deposit acceptance message.

If Bob doesn't honor the redemption request she simply has to publish the signed unblinded token itself. Note how she does not need to reveal her identity to do this. (somewhere Bob needs to advertise a guaranteed payment response time)

On the other hand if the redemption wasn't honored because it's part of a previous swap of a token for a token, Bob just has to include the signed swap to prove he's in the right.


Now lets look at how Alice can grief Bob. First of all she can't do any harm by transfering funds to Bob's deposit addresses, without the deposit acceptance she can't show Bob has done anything wrong, so Bob is free to simply move the funds and keep the cash.

She can purchase a token and just sit on it to use up Bob's fidelity bonds, but the rules state that after the expiry time Bob is free to keep the funds. Bob just needs to set the expiry short enough that he'll still be happy with his return on the cost of the bond.

If she publishes fake message that Bob didn't send her signed token she wanted Bob just has to publish the token; nothing about the blinded token is private. At the other end publishing the signed token can be responded to by simply transferring the funds as requested. Note that this message needs to be timestamped.


Finally, so where are these fraud notices going to go? Well, I've got an idea that could be done right now, but I think you guys are going to hate me for it so I'll let you figure that one out for yourself.

I was thinking about such topics lately in the context of Tor and allowing usage of abusable services from it.

My gut feeling is to start simple - allocate the money to miner fees - and only make things more complicated if you do actually see people mining their own blocks in order to create fake identities. My suspicion is that this is too much effort for the types of usages anonymous "identities" would find and the complexity of your tx-in-a-tx trick is no longer needed, neat though it is.

I think the right place to start, if you want to pursue this work, is an upgrade to MediaWiki that understands these portable registration proofs. The way I'd do it is actually to define a kind of certificate message (protocol buffer) that contains useful data and a public EC key, and then have put a hash of that certificate into the tx that spends all to fees. Your self-contained identity message can then wrap the cert (which can contain whatever you want, like an email address) and the block/merkle branch. Then you can write a standalone server that checks these identities against a community-maintained reputation database so if people abuse their purchased identity it can be burned.

Like with most things, the crypto isn't really the hardest part. All the plumbing around it, integration with popular systems, getting consensus etc, that's the hard part. The Tor community should be natural allies.

A bit of an OT tangent— but since people are talking about why having these things in the first place—  I'm as much of a sucker for cipherpunk as anyone else— but I think there are generally much better ways to accomplish this with only a modest loss of decentralization.

You can use donations to a charity or a public interest foundation as your bonding procedure, this serves a dual benefit of encouraging support of public infrastructure (always a difficult subject when for those reject other ways of getting them funded as unjust…). The cost is that the charity could cheat, but I suspect the levels of confidence where fidelity bonds would be most useful ("I am probably not a forum-troll sockpuppet!") they're a good fit.  If you start talking about really large levels of trust such that people might be inclined to start spinning up fake charities and getting them trusted just to not toss coins... well, I don't think fidelity bonds are a good mechanism for those kinds of trust. People interested in pulling off big scams are inherently gamblers. "Lets raise a million coins, so that I can scam people out of a half million" is actually attractive to some deranged minds.

Of course mining fees are one kind of public good— but there are more many more of them out there.

OK, sorry for the rambling, and I don't want to hijack the thread. Just imagine a centralized implementation of an insurance system then, since that's more straightforward. If I figure out a good mechanism for decentralization, I will post it separately.

Back on topic, how do you revoke the bond/identity that they have built up? Is it just by virtue of labeling the person a SCAMMER and distributing their public key on a blacklist?

Also, is there a way to transfer/sell the identity (besides just handing over the private key?)
Oops, you posted this already...

Well, there is one really big incentive: in a fully decentralized system it might turn out to be the only way of posting a revocable bond. As for the "all parties problem", that's why I'm posting this idea now so that it's out there and people can think about it while they work on the hard parts of doing any of this stuff. I could write a Python implementation of the above with a nice API in a weekend or two, the rest of the stuff actually using it however could be literally months of careful work.


Saying it's decentralized is all well and good, but how exactly is that going to work? What is the technical mechanism that returns credits to the defrauded individual? What lines of software code actually implements it?

Ok, I see where you are going, but personally I still think the destruction of coins is not the way to go. Unless all parties are already using this system to determine a market value for trust in the destroyed coins, then there is absolutely no incentive to use this system for any party.

I could definitely see an alternate system dedicated to this purpose, where an organization would purchase "credits" at some price in BTC that would work like bonds. If you use an alt chain, this would allow for a market to buy and sell credit to give those credits an intrinsic value that would work for the 'close up shop' honesty factor. The special rules for fraud could be built into the chain though: if the organization is behaving dishonestly (rules TBD ...), all of their credits, or a percentage of their credits depending on the amount of fraud, would be liquidated and returned to the defrauded individual. So more like traditional insurance, but decentralized.

You know, I shouldn't call it a reputation, I should call it purchasing a fidelity bond.


Think of it like a bond, where if you behave honestly you get to continue using it, and collecting more fees from your service. Bob might only have 10BTC of deposits at any one moment, but if the velocity of those deposits just has to be high enough for him to collect 2BTC/month in fees to earn a pretty good 24%/year return on his 100BTC investment. Of course, the acceptable bond/deposits ratio can evolve over time, subject to market forces. As is already true in industries like security, being able to advertise a hefty fidelity bond is valuable.

In particular being able to sell these bonds helps solve a very important problem: making sure services behave honestly when they decide to close up shop. Similarly if Bob has just fallen on hard times and needs cash now he's better off behaving honestly and selling some or all of his bond to someone else than taking the smaller amount of deposits and running.

Personally, I think jl2012 is right, throwing away money wouldn't be a popular way to build up a reputation, or at least you need a better marketing term for it...

In your example even, I am still confused as to what it solves: even if Bob has thrown away 100 BTC in the past to build up his reputation, how will this in any way affect his future scammy-ness? It's possible that he has just fallen on hard times so he's still going to dump any incoming deposits on sdice... It would be like everyone suddenly showing up with signed pirate IOUs and violations, even when he spent a long time building up reputation. I guess I can kinda see the value if you want to see if you're sending deposits to a known scammer... but I can't see expecting everyone to throw away 10+ times their expected incoming deposits in an effort to prove their reputation???

I would think this situation would be handled better and more simply by a traditional escrow provider and a nice API for trust verification, because then you can stop future scams just as well as current scams. Without an escrow provider, some automated way of adding a transaction to reverse the contract or donate a punitive amount on the failure of Bob to do the right thing would be needed. This might be handled in the violation notice stored in an alt-chain, which contains a signed transaction to this effect. This violation notice is then unlocked with a key (or parts of a key) that is given to Alice during the transaction, but only if Bob fails to keep up his end of the contract.

I'm sure this escrow mechanism has been discussed in the past before, either with P2SH or OpenTransaction stuff? I think that there is a lot of value in having a centralized, traditional service to handle the management of digital trust and reputation and someone to call up when Bob does something wrong though.

Doing that means anyone with access to the private keys of those organizations donation addresses can defraud you without consequences. It's even worse because the whole point of this mechanism is automated validation, so even if such theft is detected anyone who fails to update their software's "well-recognized donation address" is at risk.

The same could be achieved by donation to well-recognized organizations: bitcointalk.org, Bitcoin Foundation, Linux Foundation, WWF, WikiPedia, WikiLeaks, etc. It's much better than sending to a random miner (which may just dump the BTC on MtGox or buy CP) or burning it by sending to 1111111111111111111114oLvT2 as you suggested previously.

It's just game theory. Lets suppose you want to accept an IOU from some identity, a good example would be a digital bearer certificate issued as part of a microtransactions or chaum-based coin-swapping system. To know if you should accept that debt from the identity you need to be able to figure out the value of the identity, determine how much the identity owes others in total, and be able to publicly prove the identity has done something wrong to destroy it's reputation. My proposal allows you to solve the first problem by providing a way of assigning a known value to the identity.

Suppose you, Alice, want to know if you should accept a 0.001BTC micro-transaction certificate issued by "Bob" as payment. You know (somehow) that the total value of all such certificates issued at this time is 10BTC. Bob has used the above mechanism to provably throw away 100BTC of value. Thus if Bob simply keeps all his deposits he'll get to keep the 10BTC of deposits, but he's thrown away a reputation that cost him 100BTC to aquire. Thus it's in his interest to honor the deposit certificates.

What's nice about this proposal is that the proof of value is just a list of transaction pairs, and if you include the merkle paths up to the block header even SPV clients can validate the proof. You can also make these reputations securely exchangeable by using their outputs as smartcoins, and again SPV clients can validate the proof by giving them the transaction history - if a "reputation" can be sold it means that an identity that wants to shutdown a service still has an incentive to pay back outstanding debts because the reputation still has value. (although you'll need to limit what the reputation can be used for, see below)

Of course, the value assignment is the easy part... Creating efficient mechanisms for determining the total amount of outstanding debt as well as ways of publicly publishing and automatically validating proofs of wrong doing is much more complex and will depend on exactly what sort of transaction is being done. (similar to what OpenTransactions attempts to solve) Either way this mechanism will work best if people can agree on one way to do it, and helps strengthen security by promoting mining too.