Topic: Creating Bitcoin passports using sacrifices (Read 12972 times)
I agree, there's just not a need now or in the near future to find ways to raise mining revenues, and burning them is much simpler.
@jgarzik, due to provably unspendable outputs only taking 80 bytes, is the "official identity protocol" going to move away from announce/commit sacrifices? Should the sacrifice just be burned in a OP_RETURN HASH160(MPK) output until something better comes along (like the OP_VERIFY_LOCKTIME that retep mentioned)?
I can't speak for jgarzik, but I think this is the right approach. As pointed out above announce/commit can incentivize mining centralization, which is extremely bad. I think that downside outweighs the good that sending more fees to miners ever could do; miners already have pretty generous inflation subsidy for now.
@jgarzik, due to provably unspendable outputs only taking 80 bytes, is the "official identity protocol" going to move away from announce/commit sacrifices? Should the sacrifice just be burned in a OP_RETURN HASH160(MPK) output until something better comes along (like the OP_VERIFY_LOCKTIME that retep mentioned)?
FWIW, I posted an extension to the identity protocol that enables use of short pronounceable MPK (master public key) fingerprints here: https://bitcointalksearch.org/topic/transaction-naming-protocol-319633.
Artificial mining fees give an advantage to very large miners and could foster centralization. E.g. BTC guild with 28% hash power can easily give you a 10% discount on sacrifices and still make 18% profit. Even more so if the first sacrifice tx is not released other than as part of an (orphaned) block.
A bit, but this is addressed somewhat: Read the SIN spec, and how announce/commit sacrifices work.
The protocol is specified such that you are required to have made the transaction available to all for mining and spending, for a period of time, before committing the sacrifice.
Of course as Greg noted, fixing the problem of pool-centralization is sadly outside the scope of this work, and more fundamental to bitcoin itself. (encourage p2pool use...)
How about making the sacrifice to miners of blocks that have already been mined?
A sort of miner's pension.
When I make the sacrifice it is entered into a satoshi dice type lottery and awarded at random to the miner of a previously mined block.
It still incentivises miners because they will be earning a free lottery ticket if they mine a new block but there is no problem with miners trying to mine their own sacrifices.
I haven't really thought this through and it may be completely impractical to implement but I thought I'd just throw the idea out there anyway.
A sort of miner's pension.
When I make the sacrifice it is entered into a satoshi dice type lottery and awarded at random to the miner of a previously mined block.
It still incentivises miners because they will be earning a free lottery ticket if they mine a new block but there is no problem with miners trying to mine their own sacrifices.
I haven't really thought this through and it may be completely impractical to implement but I thought I'd just throw the idea out there anyway.
To contemplate this and any further ancillary chain-verified information systems, it seems to me like there should be a consideration of renaming Bitcoin itself. "Statechain" would be as appropriate as it would be ironic. Information can become blockchain-backed.
This has the potential to be extended in a way that creates the most trustworthy information system on the planet, using the most trustworthy monetary record as an underpinning to the whole thing. The strength in that model cannot be overstated.
I mean, there's talk of linking to a government ID if you choose, but a system can be designed such that a definitely proven, genuine and actual, honest-to-god uncompromised identity can be created using the Identity Protocol as it's basis. Why would you bother cross checking to any government record at all, when you can use a more reliable and trustable system? It's the ultimate information tool.
This has the potential to be extended in a way that creates the most trustworthy information system on the planet, using the most trustworthy monetary record as an underpinning to the whole thing. The strength in that model cannot be overstated.
I mean, there's talk of linking to a government ID if you choose, but a system can be designed such that a definitely proven, genuine and actual, honest-to-god uncompromised identity can be created using the Identity Protocol as it's basis. Why would you bother cross checking to any government record at all, when you can use a more reliable and trustable system? It's the ultimate information tool.
"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."
What is meant by this? Can you please explain a bit more? I'm slowly but surely delving deeper into the protocol, so I need to wrap my head around concepts still.
That should get a new thread, if retep has time to follow up on it. Thanks. (I will be deleting my post once it's not needed to keep this thread from going offtopic) What is meant by this? Can you please explain a bit more? I'm slowly but surely delving deeper into the protocol, so I need to wrap my head around concepts still.
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.
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.
"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."
What is meant by this? Can you please explain a bit more? I'm slowly but surely delving deeper into the protocol, so I need to wrap my head around concepts still.
Thanks for explaining the other options. Another quick question: taking a look here (https://en.bitcoin.it/wiki/Script). anyone-can-spend output doesn't have a limit to when it can be spent? I assume that anyone-can-spend MUST be coupled with OP_VERIFY_LOCKTIME so miners have an equal chance. Or am I missing something? [EDIT. Forget this question. I read up on it. It uses nLockTime. For anyone else wondering: https://en.bitcoin.it/wiki/Fidelity_bonds#Announce.2FCommit_Sacrifices].
Artificial mining fees give an advantage to very large miners and could foster centralization.
Welp, better go fix this centralization then... it has a lot more costs and risks for Bitcoin than just SINs.At least it would be wise not to add bad incentives.
Artificial mining fees give an advantage to very large miners and could foster centralization.
Welp, better go fix this centralization then... it has a lot more costs and risks for Bitcoin than just SINs. 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.
the sacrifice can be of little value...Artificial mining fees give an advantage to very large miners and could foster centralization. E.g. BTC guild with 28% hash power can easily give you a 10% discount on sacrifices and still make 18% profit. Even more so if the first sacrifice tx is not released other than as part of an (orphaned) block.
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.
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.
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)
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)
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.
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.
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.
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.
Would it not be much easier to destroy coins as a sacrifice?
also: http://nameid.org a Namecoin id based OpenID provider
also: http://nameid.org a Namecoin id based OpenID provider
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.
Jump to: