Creating Bitcoin passports using sacrifices

[Peter Todd]

Is this really an issue? Well, I think the the question really is why would you use a sacrifice method where the value is so sensitive to so many variables? In particularly, a method where the actual cost of the sacrifice is inversely and exponentially dependent on the size of the largest miner.

You said yourself, the orphan rate is not only measurable but also quite low. I'm not sure it's really that complicated.

Re-read what I wrote. A low orphan rate is what makes the attack possible. Assuming it is always zero is the conservative way of estimating sacrifice value. More to the point, the real issue is the sensitivity to mining power; try experimenting with plotting the cost vs. hashing power curve. It's a very, very fast decline to zero as you get close to even just 20%, whereas tx-in-tx is just a straight linear line from 0% to 100% and doesn't require any analysis.

And again, it only takes a small orphan rate to mess up multiple tx schemes by dramatically increasing the difficulty of getting a valid set of consecutive transactions. You said it yourself that miners don't appear to always be rational profit-driven entities. All you need is some that have a grudge against your service for whatever silly reason.

So then sites that are using passports to avoid being abused just set the multiplier in their config file to 0.7 and they're done. The actual multiplier can be updated every so often and re-distributed ... no big deal as the operators who are accepting these passports already need to share blacklists and so on for the system to work.

You know, I think this gets to the core of my objection: why settle for a system that requires all this maintenance? For tx-in-tx you can set the discount to 0.5 on the assumption that if >50% of the hashing power is controlled you're screwed anyway. Done. If you're particular use allows for resale you will need to check that the secondary market hasn't crashed, but that's true regardless of how the sacrifices are created.

Ultimately I understand that passports probably don't really need iron-clad security, and do need lots of human intervention for other reasons. But the cost of getting the best security possible, short of just sending value to unspendable txouts, is pretty low, and it does make for shorter proofs than multiple-tx schemes. (if n > 2)

It's only real disadvantages is the need to ensure the signatures on the published sacrificial tx are valid, a potentially tricky bit of code, the fact that the initial announcement tx is (currently) non-standard, and the need to write a blockchain watching bot to recognize the sacrificial txs and broadcast them. (or add them to the local mempool and try to mine them yourself) I just don't see those three issues as major problems, and I'd much rather see your passports use the same system as fidelity bonded coin transfer services and whatever else people come up with so efforts can be focused on getting one solid system rather than a couple of incomplete ones.

[Mike Hearn]

OK. I need to think about your argument some more, but I suppose you're right that the program that extracts the inner tx and rebroadcasts it doesn't really have to be a part of the nodes themselves.

[simondlr]

It's only real disadvantages is the need to ensure the signatures on the published sacrificial tx are valid, a potentially tricky bit of code, the fact that the initial announcement tx is (currently) non-standard, and the need to write a blockchain watching bot to recognize the sacrificial txs and broadcast them. (or add them to the local mempool and try to mine them yourself) I just don't see those three issues as major problems, and I'd much rather see your passports use the same system as fidelity bonded coin transfer services and whatever else people come up with so efforts can be focused on getting one solid system rather than a couple of incomplete ones.

Could the new addition of relaying OP_RETURN data txout as provably prune-able (https://github.com/bitcoin/bitcoin/pull/2738) help with passports in some way?

As far as I get it, the main problems are still the fact that miners can mine their own sacrifices, and hence the risk needs to be mitigated somehow, orphans, and somehow maintaining a blacklist?

[Peter Todd]

It's only real disadvantages is the need to ensure the signatures on the published sacrificial tx are valid, a potentially tricky bit of code, the fact that the initial announcement tx is (currently) non-standard, and the need to write a blockchain watching bot to recognize the sacrificial txs and broadcast them. (or add them to the local mempool and try to mine them yourself) I just don't see those three issues as major problems, and I'd much rather see your passports use the same system as fidelity bonded coin transfer services and whatever else people come up with so efforts can be focused on getting one solid system rather than a couple of incomplete ones.

Could the new addition of relaying OP_RETURN data txout as provably prune-able (https://github.com/bitcoin/bitcoin/pull/2738) help with passports in some way?

As far as I get it, the main problems are still the fact that miners can mine their own sacrifices, and hence the risk needs to be mitigated somehow, orphans, and somehow maintaining a blacklist?

Huh?

There are two main ways of making provable sacrifices that make sense:

1) Create a txout with a scriptPubKey that can't be spent that has a non-zero value.

2) Use the the announce/commit sacrifice protocol to ensure all miners have an equal chance.

2.1) Create a anyone-can-spend coinbase txout. (can't be spent for 100 blocks, so again, all miners have an equal chance)

2.2) In the future add an OP_VERIFY_LOCKTIME or similar to make a specific txout unspendable for some amount of time.


That miners can mine their own fee sacrifices makes the whole fee sacrifice thing a horrible, horrible idea and a complete non-starter. It'd dead easy to round up enough mining power to create any single-tx fee sacrifice you want in a reasonable amount of time, and of course you can always turn that into a service. No-one who knew what they were talking about was seriously proposing that idea.

As for #1: it's dead easy to create all kinds of scriptPubKeys that you can prove can never be spent. Previously people thought UTXO bloat was an issue, but right now I'm quite convinced UTXO size isn't a big deal due to TXO commitments. (though having invented them, I might be a bit biased!)

Annoyingly only 80 bytes are allowed in a standard OP_RETURN <data> txout, which makes announce/commit sacrifices hard to pull off, but then again they aren't as trustworthy as spend-to-unspendable - for now I don't think we want to use them. Better to eventually add OP_VERIFY_LOCKTIME and lock the coins involved for fairly long amounts of time, months to years.

[Carlton Banks]

Sounds very good as is, but cynical old me has spotted a danger I would like everyone to consider.

The blacklists are local to the individual services under this model, but the blockchain containing the passes is, of course, global. This service specific blacklist information has a value to others though, and I'm imagining a consequential scenario of such a system becoming commonly used. 

If third party services spring up that purchase and aggregate the blacklist information from those services using pass-based registration, then there develops an incentive to be done with it and globalise the blacklist as well. This creates all sorts of problems, not least bloating the blockchain with tattle-tales, but more problematic is that of overly politicised blacklisting (it's arguably always "politicised", and that's not strictly always a bad thing when your overriding political view is that you cannot tolerate spammers and trolls diluting good content/discourse). But of course, politics can be malicious as well as benevolent for the wielder of the political tool, and so you may end up with a system that elicits wilder distortions in behaviour than today's free-for-all can manifest. For instance, being trolled and spammed exclusively by those with the means to pay might be an even more unhappy experience than what we live with now. And so you substitute one set of pests for another, and simultaneously incentivise everyone to behave similarly to how they do with service registration now, expect you have to pay to register, and for broadly the same conditions as we have now. That wouldn't be such an improved situation.

Still, this scheme is not going to get widely adopted any time soon, it requires a more Bitcoin centric (if not Bitcoin ubiquitous) world such that a minimum of some critically significant minority are actually in a position (the position of being a Bitcoin user) to pay for the passes. So there is alot of time and contemplation to refine something like this, and perhaps this issue should play out on a smaller scale before we can establish sensible best practices. It's fairly vital that this happens actually, as this is a powerful and important concept, given the requisite adoption of both Bitcoin and theses passes. One possibility is that the services are encouraged to treat the blacklists as any other highly sensitive user information is, at the behest of preventing the descent into the model of a globalised blacklist tyranny.

Incidentally, maybe just "passes" is a better name, or some post-internet monstrosity like "e-pass". Passport does have too much association with nation-state infrastructure, and this system largely transcends the nation-state, in that familiar old internet fashion.

[inform]

This interestings ideas 

[Carlton Banks]

There could be an economy for blacklists but the possibilities of this overwhelm it. It opens the door to all kinds of possibilities including state recognition of a personally controlled and issued identity opening wide the door for systems like liquid democracy and webs of trust. Identity trading could be risky though and DNA as a private key might raise a few eyebrows.

Hmmm, they can't be absolute identities, as by definition you can obtain more than one (just like actual passports). And an identity based on your DNA has the smallish problem of identical twins.

[jgarzik]

SIN uses OP_RETURN: https://en.bitcoin.it/wiki/Identity_protocol_v1

Though as Peter has noted elsewhere, the current OP_RETURN standard (max 80 bytes) is smaller than the needs found in the SIN specification, which must include a full transaction.

[jgarzik]

Does it need to be able to include additional data such as name, ssn, etc? That sounds like a bloat bomb as there's no upper limit to what information folks will want included plus it adds to the risk, wouldn't it be better as a simple unique identification and let 3rd parties and/or a namcoin like chain handle the data associated with it?

None of the SIN data is in-chain except for the sacrifice transactions.

The main bitcoin blockchain is only used for timestamping a hash of the public key (SIN type 1).

SIN type 2 is completely off-chain, because it is not associated with any sacrifice.

[Carlton Banks]

Does it need to be able to include additional data such as name, ssn, etc? That sounds like a bloat bomb as there's no upper limit to what information folks will want included plus it adds to the risk, wouldn't it be better as a simple unique identification and let 3rd parties and/or a namcoin like chain handle the data associated with it?

None of the SIN data is in-chain except for the sacrifice transactions.

The main bitcoin blockchain is only used for timestamping a hash of the public key (SIN type 1).

Which, in practice, means that all that's going in the blockchain (according to this spec) is a unique identity that isn't your real name or a forum handle. And it's there to prove you paid for it, as the storage identity is encoded in the transaction which you paid with.

[Anon136]

There could be an economy for blacklists but the possibilities of this overwhelm it. It opens the door to all kinds of possibilities including state recognition of a personally controlled and issued identity opening wide the door for systems like liquid democracy and webs of trust. Identity trading could be risky though and DNA as a private key might raise a few eyebrows.

Hmmm, they can't be absolute identities, as by definition you can obtain more than one (just like actual passports). And an identity based on your DNA has the smallish problem of identical twins.

and chimeras

[Carlton Banks]

And so we come to another potentially pernicious aspect to this; an identity protocol creates a potential set of circumstances where merchants can refuse to allow the custom of a Bitcoin user who does not pay whilst also providing an identity to them. Although this could have undeniable utility in some very specific circumstances... if you bought an identifier that you register with some national ID scheme, it could remove the legal responsibility of shopkeepers when selling items with legal age restrictions to someone they would never believe was old enough when judging them visually, photo ID or not. You can use a different ID to buy pot on a street corner, so privacy can in theory be maintained. I think the danger would be that governments could decide to outlaw (Bitcoin/cryptocurrency) purchases without an attached electronic ID, forcing retailers into the position of everything being ID restricted, with the age restriction layer remaining beyond that.

One thing that immediately springs to mind in terms of the more positive consequences: could this form the basis of the decentralisation of the various centralised technology services that are subject to abuse now? Could we create similarly secure and verifiable identities to replicate the function of the Certificate Authorities? Or of DNS lookup? Or even of TLD registry? Clearly technically possible, but would it be too much bloat at this point on the curve of storage technology development?

Better yet, this could become de facto the definitive ID scheme, and it will exist outside government control anyway. Who would trust a government maintained system, with all the possible errors, corruptions, inaccuracies and inefficiencies. I'm trying to think of a way we could definitively register the birth of a child in the blockchain.... perhaps there is a good reason to start storing hashed copies of an individual's genome!

Edit: the most chain-storage efficient birth certificate would be a signed copy of your genome sequence, in line with ID protocol as is. But hashing it and storing in the blockchain would be the most reliable and trustworthy way, that is in a world of cheap personal yottabyte storage for all that chain bloat... I sense a technocracy coming on....  

[Anon136]

all this talk about linking to real identity, why on earth would you want to do that. its essentially just a fancy fidelity bond. the less one party knows about the other party the better it works.

[Carlton Banks]

all this talk about linking to real identity, why on earth would you want to do that. its essentially just a fancy fidelity bond. the less one party knows about the other party the better it works.

Well depending on the circumstances, the range of which are vast, I would agree. If you were a teenage girl buying a pregnancy kit, or an insurance certified bodyguard having a medical procedure at a private clinic, you would choose to go to the expense of using a private, never to be registered anywhere identity.

I guess this scheme is doing something very specific that is implicit in the design (and the design goals): commoditising identities. Big topic, for real-world implications.

[phelix]

Would it not be much easier to destroy coins as a sacrifice?

also: http://nameid.org   a Namecoin id based OpenID provider

[Carlton Banks]

Would it not be much easier to destroy coins as a sacrifice?

With a potential for a minimum of 7 billion (and counting) identities for a truly representative number of ID's, we risk ending up with a demurrage based money supply. Consider that there is a legitimate justification to have more than one ID per person, well, I think that sews it up.

also: http://nameid.org   a Namecoin id based OpenID provider

I'm kind of keen on a "one chain to rule them all" model right now, it increases the value of whichever chain can hold the most valuable information. Waiting to hear more debate though, this story still appears to be very much at the beginning.

[jgarzik]

One thing that immediately springs to mind in terms of the more positive consequences: could this form the basis of the decentralisation of the various centralised technology services that are subject to abuse now

That's the general idea.

Your markets can be decentralized, as long as the identity protocol is agreed upon.

You control your own level of privacy.  You choose to whom your identity is revealed, and beneath that, the meaning of the hashes attached to your SIN record.

[Carlton Banks]

Well.

It sounds a hell of a lot like this being the most disruptive development since Bitcoin itself, potentially, and even Bitcoin hasn't quite "happened" yet. I think I'm going to have to have a lie down.

[gmaxwell]

In theory SINs could be blinded too:

You write a small program that takes in a SIN SPV fragment, a site name, a minimum sin value, and the private key for the sin. It verifies the SPV fragment, then uses deterministic DSA to sign the sitename and computes then returns {sitename, minimum sin value, H(txid || signature)}.

You run this problem inside a zero-knoweldge proof-of-knoweldge environment and the result is a unique ID per site which proves that there exists a sin of at least the stated value, but no information about which transaction is the SIN.

(The actual implementation of this is annoyingly complex, but we should try to nag the people working in this space to use it as an example application since it's probably the simplest use of these kinds of proofs which would have a big practical value to us)

[dillpicklechips]

Very neat idea. You are all making it hard for me to not get excited about all the areas bitcoin is going to influence now that we can use bitcoin at the protocol level and use it everywhere.


As far as name I would pick: bitcoinized identity - makes it clear that somehow bitcoin technology was used with the identity

Passport seems to be a more fitting name for the software that manages the various bitcoinized identities.