Topic: Creating Bitcoin passports using sacrifices - page 2. (Read 12972 times)

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.

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....  

and chimeras

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.

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.

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.

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.

This interestings ideas 

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.

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 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.

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?

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.

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.



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.

Whilst I think these are bold assumptions - pure profit-driven miners should theoretically offer all kinds of services that in practice they don't - let's assume you are right.

Then the actual cost of a sacrifice would be some multiplier <1.0 of the value sacrificed. That multiplier can easily be figured out by looking at the market rates advertised by the largest miners. Eg they'll say, send us 0.8 BTC and we'll send you the keys for a 1 BTC sacrifice, and it works for them because it only cost them 0.7 BTC to make due to them mining their own initial sacrifices.

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 said yourself, the orphan rate is not only measurable but also quite low. I'm not sure it's really that complicated.

I sat down and (half) wrote a god-damn paper this weekend analyzing this stuff properly. I'll finish it up and make it public if anyone is actually interested, but the process absolutely convinced me that the two-step tx-in-a-tx solution is the only thing close to feasible that will keep a stable sacrifice market value. (without just sending coins to unspendable txouts of course)

First of all you have to assume that services will pop up to create these sacrifices for you. Thus you need to assume the sacrifice is being created by the entity with the largest single concentration of hashing power, and that's likely to be in the range of 10% to 30%.

Secondly because of that, for any mining-fee-based sequence, the first transaction is always nearly free. You can always mine it yourself by waiting a bit, and the only cost is the approximately 1% or 2% probability that the block gets orphaned and another miner gets the tx fee instead.

This means that asking for "two blocks n apart" is at best 50% efficient, because you have to assume the first block was self-mined. Secondly mining is a random process, so asking for exactly 1 block apart or 100 makes absolutely no difference.


Sure, but this is a supply and demand problem. Let ω be the probability that the block a transaction is in is orphaned, and the transaction is mined by someone else. If we attempt to mine a transaction containing a fee of value V ourselves, the cost to us is then V*ω. Assuming that miners always build on the best known block and don't deliberately attempt to orphane blocks to collect the transactions within ω is probably approximately equal to the orphan rate itself, which appears to be around 1% or so. Also note that for a large miner ω is less than for a small miner.

Now if I control q of the total hashing power my expected number of blocks before I get n consecutive is ((1-q)^(-n)-1)/(1-q) For 10% I need 1 million attempts for n=6, however the number of attempts drops extremely quickly as q and n decrease. Basically that means if there exists q and n such that ((1-q)^(-n)-1)/(1-q)*ω < v/V, where v is the actual value of the sacrifice and V is the face value, you are better off attempting to mine the sacrifice yourself rather than buying it fairly. For q=25% and n=3 this is true for v=V. (remember that you can always finish the other blocks in a sacrifice by the conventional way) Allowing for n-of-m blocks just makes the problem worse, because it effectively increases the apparently hashing power available to the miner. Yet at the same time griefers can do a lot of damage by deliberately excluding your sacrifice transactions if n-of-m is not allowed, and additionally orphans quickly push up the cost of sacrifices. (about 10% extra for n=6 and 1% orphans)

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.

My later tx-in-a-tx proposal is far easier to reason about because the cost is simply bounded by the largest miners hashing power and has no dependence on difficult to measure values like orphan rates. It's just a much better idea, which might explain why it took me 6 more months to think of it...


But the tx-in-a-tx sacrifice isn't valid until the second tx, the one that actually sacrifices coins, is spent so the tx being in the mempool is a non-issue. Anyway sacrifices need to be provable to SPV nodes who don't care about the mempool.

Well, the assumption behind the 2-step process is that you can't predict who will mine a block a long way in the future. You could equally have your proof contain two transactions in two blocks and insist in the protocol that those blocks always be exactly 100 blocks apart and it'd work the same way, I'd think?

It seems like the difficulty of obtaining 5-of-6 blocks in a row or similar is essentially equivalent - you have to dominate the network in either case, or be infeasibly lucky, but you can make a proof faster if you're trying to fill a majority of blocks in a span.


If the node that's verifying can't see it in the mempool and it's not in a block, then presumably the first transaction could be double-spent. Nodes can sync to each others mempools these days using the mempool command, and I guess in future if we find a solution to zombie transactions living forever it'd be good to make nodes sync their mempools at startup. The current "solution" (I hesitate to use that word) is hardly convincing

Ha. Might be a geographic thing; I'm in Canada. Of course, security is a niche field ultimately...


Someone else should chime in with the math to work it out explicitly - I know way too little about probability math - but can you see how the probability aspect of it makes hash power much less important than the two-step publish commit?


Right, but if that node trying to verify the sacrifice didn't see it in the mempool, there is no way to prove it ever was in the mempool after the fact.

I can see this sort of thing being useful...!

This is a really interesting idea.

I didn't miss it. It was the first example of how to use contracts I ever put on the wiki:

   https://en.bitcoin.it/wiki/Contracts#Example_1:_Providing_a_deposit

The problem being that I don't really want to have to pay every blog I comment on. The passport concept is useful because you can create it once and then re-use it anywhere, without having to manage deposits at random websites. Prolific but valuable contributors aren't discouraged.


I think micropayments for replacing ads makes a great deal of sense (edit) but I think it's a separate problem from abuse controls.