Mike Hearn





Offline



Activity: 1526

Merit: 1008







LegendaryActivity: 1526Merit: 1008 Creating Bitcoin passports using sacrifices February 02, 2013, 03:44:15 PM

Last edit: February 02, 2013, 04:12:24 PM by Mike Hearn #1



"Bitcoin passports" are related to





Services that can be abused (wikis, forums, webmail etc) need a blacklistable identity for each user so bad behaviour can be punished through exclusion. If no such blacklistable identity exists then account termination is pointless because the abuser will just immediately sign up again. This is why Tor tends to have a read-only view of the internet. Mesh networks like cjdns will have the same problem. Small sites tend to use IP address but this is weak; more advanced operations like the Google abuse team use phone verification and other techniques.



For anonymous users to take part, a cost on establishing an identity must be imposed. We can do this by requiring users to present a proof that they gave away some coins to miner fees. The proof is standalone and can be checked by anyone who has a copy of the block headers. The hash of that proof becomes the pseudonym, it can be checked against Spamhaus style DNS blacklists to discover past behaviour that has been associated with that nym and optionally blocked.



To create one, you take X coins and spent them to miner fees over the course of Y consecutive blocks. The outputs of the transactions are set to OP_FALSE so nodes can be taught to prune them. Each transaction and its merkle branch are included into a data structure, called the passport:



Code: message BitcoinPassport {

// A name that sites can refer to the user as - for convenience only, it is

// not checked anywhere and can be of any form. Websites must sanitize

// it for XSS before rendering as there may be arbitrary UTF-8 data in it.

required string textual_name = 1;

repeated Sacrifice sacrifices = 2;

// Some optional data that can help simplify signup for websites ....

optional string email = 3; // etc

}



message Sacrifice {

// The raw transaction as included into the block chain, the merkle branch

// proving its inclusion and the co-ordinates of the block.

required bytes tx = 1;

required bytes merkle_branch = 2;

required bytes included_in_block = 3;

required int inclusion_height = 4; // Some implementations may benefit from this.

}



If a service or application wishes to verify a passport, it asks the operating system to open a URL of the form:



Code: bitcoinpassport+https://accounts.google.com/VerifyAnonymousAccount?value=0.01&challenge=f3626fca2ce9ffd23e0abd859faeff5384b63834&state=dNaBzuXCE7a7UGSO+deEbX/8XDNESGSD/lQ9vmO9/NU=



An application, call it the Passport Manager, handles this URI and then signs the given challenge using each public key in each sacrifice transaction (in order). The challenge is randomly generated by the server. The signatures are then bundled up together with the state and the passport itself:



Code: message IdentityProof {

// An series of embedded messages containing passports. This is not an embedded type to ensure

// reliable hashing of the contents without any confusion caused by protocol upgrades in future.

// There can be more than one so you can present multiple passports to reach the required size

// of sacrifice, in case your first one isn't large enough.

repeated bytes passport = 1;

// A list of signatures, one for each input in each sacrifice, in order.

repeated bytes signatures = 2;

// This is simply a copy of the state parameter in the URI.

optional string state = 3;

}



The state parameter is arbitrary data looped through the client from the server. It allows for a stateless server implementation that does not need a database to track what challenge corresponds to what server action is currently suspended pending verification. For instance, the server could encrypt any state it requires into this field. It is useful for operations that use global load balancing.



Upon receiving an IdentityProof, the server parses the passport field into a BitcoinPassport message, verifies the signatures (the passport is presented by its owner), verifies that the sacrifice transactions link back to the given block headers based on the servers copy of those headers, and then verifies that the number and value of the sacrifices is sufficient. The transactions should appear more or less in consecutive blocks the chain, though there should be a bit of leeway allowed.



If the proof is validated, the server can then check against its own blacklists of abusers or look up the hash in a remote database. If no problems are found, the nym (proof hash) can be stored in the newly created account. If later the account turns out to be abusive, it can be blacklisted. The state variable can be decrypted and whatever data needs to be adjusted then can be. The server replies to the app with an HTTP redirect and the app then opens the redirect URI, which takes the user back to the browser. The redirect URI may complete registration with a welcome message, or alternatively explain to the user why their nym is not accepted.



Passports can be created using the Passport Manager app. It is a standalone program that maintains its own Bitcoin wallet. You send money to it, click the "Make passport" button and then go to bed. It ensures there are outputs of the right quantity and value before starting, and then sends transactions such that they get into consecutive blocks. This may take an hour or two, but once complete the passport can be written to a .passport file which contains the public data and of course, the private keys used to sign for them.



Design choices



(1) Why miner fees instead of a charity?



There are several problems with the idea of donating to charity:



Charities are not politically neutral as miners are. For instance, if you wanted to donate to charities that operate in Iran that might be an issue. Nobody will be able to agree on one set of charities that makes everyone happy - even "no brainers" like open source foundations would be a turnoff to non-technical people who may wish to use the system.

Charities massively prefer to have real relationships with donators who commit to the long term (or can be convinced to do so). Anonymous, unpredictable revenue flows can make their accounting much harder because they don't know when money might arrive, so it can't be relied upon. A charity that received money this way then didn't use it would lose a lot of goodwill through no real fault of their own.

Some charities do not want to or cannot accept anonymous donations at all.

Everyone would have to agree on the list of charities to use ahead of time, so there would be no connection between how well a charity does and how much it received in sacrifice fees. A charity may operate effectively for a few years and then become corrupt or incompetent, but upgrading everyones software to use a new list would be difficult.

Miners are politically neutral, anonymous, indistinguishable, the money is almost guaranteed to quickly re-circulate into the economy via exchanges and it helps support network security.



(2) Why require multiple sacrifices in consecutive blocks?



This is to avoid people mining their own sacrifice. It's very hard to mine 6 consecutive blocks but relatively easy to get transactions into them. A gap of 1 block or so would be acceptable, you don't need to hit every single block to have very high confidence.



(3) What are good values for the size of the sacrifice and the number of blocks?



Abuse is cheap. Let's imagine we deploy this for Gmail. The cost of Gmail accounts on the black market is roughly $100-$150 per thousand accounts. This is what it costs professional spammers to overcome phone verification and successfully avoid bulk termination.



Thus a single account costs about 10 to 15 cents. Assume a price of $20 per coin, that means 10 cents is 0.005 coins. If we say you need to spend 0.005 coins to fees in the space of 6 blocks, then this means 0.001 coins per sacrifice with an allowable gap of 1 block in 6 total. That sounds quite reasonable to me. Because you know when the sacrifice was made, calculating the value of it in the currency of your choice is straightforward despite floating exchange rates.



(4) Why a new URI scheme?



For a website to ask an app for data, there are only a few possibilities. Magic HTTP headers, JavaScript APIs etc all require browser extensions to implement, which is hard or impossible to do on mobile/tablet browsers. URI registration is simple, universally supported and does not impose any browser requirements. I figured I'd start a new thread for this despite that there are a few similar threads already, as I wanted discussion of this exact design all in one place. I will incorporate feedback and put it onto the wiki in the coming week. These ideas are of course not really mine, they have come out of lots of different discussions and debates. But I want to try blending them in a different way, with more technical detail."Bitcoin passports" are related to fidelity bonds discussed elsewhere in this forum , but I think it's a slightly better sounding name (if a little misleading).Services that can be abused (wikis, forums, webmail etc) need a blacklistable identity for each user so bad behaviour can be punished through exclusion. If no such blacklistable identity exists then account termination is pointless because the abuser will just immediately sign up again. This is why Tor tends to have a read-only view of the internet. Mesh networks like cjdns will have the same problem. Small sites tend to use IP address but this is weak; more advanced operations like the Google abuse team use phone verification and other techniques.For anonymous users to take part, a cost on establishing an identity must be imposed. We can do this by requiring users to present a proof that they gave away some coins to miner fees. The proof is standalone and can be checked by anyone who has a copy of the block headers. The hash of that proof becomes the pseudonym, it can be checked against Spamhaus style DNS blacklists to discover past behaviour that has been associated with that nym and optionally blocked.To create one, you take X coins and spent them to miner fees over the course of Y consecutive blocks. The outputs of the transactions are set to OP_FALSE so nodes can be taught to prune them. Each transaction and its merkle branch are included into a data structure, called the passport:If a service or application wishes to verify a passport, it asks the operating system to open a URL of the form:An application, call it the Passport Manager, handles this URI and then signs the given challenge using each public key in each sacrifice transaction (in order). The challenge is randomly generated by the server. The signatures are then bundled up together with the state and the passport itself:The state parameter is arbitrary data looped through the client from the server. It allows for a stateless server implementation that does not need a database to track what challenge corresponds to what server action is currently suspended pending verification. For instance, the server could encrypt any state it requires into this field. It is useful for operations that use global load balancing.Upon receiving an IdentityProof, the server parses the passport field into a BitcoinPassport message, verifies the signatures (the passport is presented by its owner), verifies that the sacrifice transactions link back to the given block headers based on the servers copy of those headers, and then verifies that the number and value of the sacrifices is sufficient. The transactions should appear more or less in consecutive blocks the chain, though there should be a bit of leeway allowed.If the proof is validated, the server can then check against its own blacklists of abusers or look up the hash in a remote database. If no problems are found, the nym (proof hash) can be stored in the newly created account. If later the account turns out to be abusive, it can be blacklisted. The state variable can be decrypted and whatever data needs to be adjusted then can be. The server replies to the app with an HTTP redirect and the app then opens the redirect URI, which takes the user back to the browser. The redirect URI may complete registration with a welcome message, or alternatively explain to the user why their nym is not accepted.Passports can be created using the Passport Manager app. It is a standalone program that maintains its own Bitcoin wallet. You send money to it, click the "Make passport" button and then go to bed. It ensures there are outputs of the right quantity and value before starting, and then sends transactions such that they get into consecutive blocks. This may take an hour or two, but once complete the passport can be written to a .passport file which contains the public data and of course, the private keys used to sign for them.There are several problems with the idea of donating to charity:Miners are politically neutral, anonymous, indistinguishable, the money is almost guaranteed to quickly re-circulate into the economy via exchanges and it helps support network security.This is to avoid people mining their own sacrifice. It's very hard to mine 6 consecutive blocks but relatively easy to get transactions into them. A gap of 1 block or so would be acceptable, you don't need to hit every single block to have very high confidence.Abuse is cheap. Let's imagine we deploy this for Gmail. The cost of Gmail accounts on the black market is roughly $100-$150 per thousand accounts. This is what it costs professional spammers to overcome phone verification and successfully avoid bulk termination.Thus a single account costs about 10 to 15 cents. Assume a price of $20 per coin, that means 10 cents is 0.005 coins. If we say you need to spend 0.005 coins to fees in the space of 6 blocks, then this means 0.001 coins per sacrifice with an allowable gap of 1 block in 6 total. That sounds quite reasonable to me. Because you know when the sacrifice was made, calculating the value of it in the currency of your choice is straightforward despite floating exchange rates.For a website to ask an app for data, there are only a few possibilities. Magic HTTP headers, JavaScript APIs etc all require browser extensions to implement, which is hard or impossible to do on mobile/tablet browsers. URI registration is simple, universally supported and does not impose any browser requirements.

Mike Hearn





Offline



Activity: 1526

Merit: 1008







LegendaryActivity: 1526Merit: 1008 Re: Creating Bitcoin passports using sacrifices February 02, 2013, 04:12:08 PM #2 Fidelity bonds are mentioned in the second paragraph, and it says at the top that these are ideas that have come out of many discussions. Peters thread is hardly the first mention of the idea. But I will add a direct link regardless. Note that the designs are not the same (no tx-in-a-tx).

gmaxwell

Legendary





Offline



Activity: 3178

Merit: 4298









ModeratorLegendaryActivity: 3178Merit: 4298 Re: Creating Bitcoin passports using sacrifices February 02, 2013, 05:29:27 PM #3 Yes, I saw that it mentioned it. I thought it was an inadequate reference without the link. Thanks for adding one.



I can't say that I'm a fan of the new name you've given this but I'm not the person to ask. It'll be interesting to see what other people think.



The consecutive block requirement is a bit ugly, as it requires N transactions instead of one or two and the provided fees will need to be somewhat high to get an acceptably gapped run with high confidence.



What advantage do you see in using a consecutive block run over the two transaction announce-commit sequence promoted by Peter Todd? What he proposes would have less pre and post pruning blockchain data, would result in passports 1/3rd the size, and I believe it would be less likely to fail for reasons beyond the user's control.



The dummy output could be completely eliminated by instead authoring the transaction as an anyone can spend and putting part of the fee there.



If you fail to provide a mechanism for transferring ownership of passports it means that there is no economically rational motivation to not violate trust using an identity that you're done with (e.g. as you rotate them out for anonymity purposes). If the passports can be resold while in good standing the problem is removed so long as a liquid market exists. If they are only weakly transferrable (E.g. I give you a couple private keys that I continue to own) then the only place to sell a used bond is to blackhats.



I notice you seem to be describing this using protobuff. If you hash a representation without a single canonical encoding then users could escape blacklisting by changing their encoding.



More thoughts later I'm glad to see other people looking at this.





Peter Todd





Offline



Activity: 1106

Merit: 1045







LegendaryActivity: 1106Merit: 1045 Re: Creating Bitcoin passports using sacrifices February 02, 2013, 06:08:51 PM

Last edit: February 03, 2013, 04:49:48 AM by retep #4



I notice that you are tying the identity to the pubkeys signing the txins. An additional problem to this is the pack of transferability means that key compromise is not recoverable. You also limit the granularity to the minimum fees, which will be much larger in the future.



What I've been working on ties the contract the bond holder is promising to oblige to to the sacrifice tx. Now you have something like one of jgarzik and others bonds, and the bonds can be moved around. For, say, a wiki the contract can be as simple as "I promise not to spam" Proving fraud the. Requires an affected service to put a timestamped proof of spam - which can be just a signature if the service is trusted - in a public place. Buyers of the bond then need to walk the tx chain back to the source, checking that public place for valid fraud notices.



I've got a write up on this almost finished; I'll post it tonight or tomorrow when I get home. FWIW I posted about consecutive miners fees (and the whole bank idea) months ago to the forums and bitcoin dev email list and didn't pursue it because of the risk that the txs wouldn't be consecutive, as well as the size. The tx-in-tx idea is what made me think it was practical without just destroying coins.I notice that you are tying the identity to the pubkeys signing the txins. An additional problem to this is the pack of transferability means that key compromise is not recoverable. You also limit the granularity to the minimum fees, which will be much larger in the future.What I've been working on ties the contract the bond holder is promising to oblige to to the sacrifice tx. Now you have something like one of jgarzik and others bonds, and the bonds can be moved around. For, say, a wiki the contract can be as simple as "I promise not to spam" Proving fraud the. Requires an affected service to put a timestamped proof of spam - which can be just a signature if the service is trusted - in a public place. Buyers of the bond then need to walk the tx chain back to the source, checking that public place for valid fraud notices.I've got a write up on this almost finished; I'll post it tonight or tomorrow when I get home. BTC: 1FCYd7j4CThTMzts78rh6iQJLBRGPW9fWv PGP: 7FAB114267E4FA04

Anon136



Offline



Activity: 1666

Merit: 1211









LegendaryActivity: 1666Merit: 1211 Re: Creating Bitcoin passports using sacrifices February 03, 2013, 12:17:48 AM #5 This makes me wonder. Would this naturally evolve over time into its own crypto currency? You would just sign a public statement with a private key making a prediction about the way in which bitcoins will be destroyed. If your prediction was the first and accurate than it would be considered by the network to be legitimate and stored in a distributed database. (because there is no reason not to allow people to store copies of the database in a distributed manner) Hopefully the end result would be a product that felt a lot like bitcoin. Where you could transfer the value you had assigned to private keys (in this case by "destroying" bitcoins) just like you do with bitcoin. But you would also have the option to send "insurancecoins" into, what would be functionally equivalent to, a joint account to be held in escrow by the distributed network and its protocol until such a time that both parties agree to the release of the funds.



the core of what we are really addressing is the fact that the community lacks a decentralized and anonymous form of escrow.

If one can not confer upon another a right which he does not himself first possess, by what means does the state derive the right to engage in behaviors from which the public is prohibited? Rep Thread: https://bitcointalk.org/index.php?topic=381041 If one can not confer upon another a right which he does not himself first possess, by what means does the state derive the right to engage in behaviors from which the public is prohibited?

chriswilmer



Offline



Activity: 1008

Merit: 1000







LegendaryActivity: 1008Merit: 1000 Re: Creating Bitcoin passports using sacrifices February 03, 2013, 03:58:10 AM #6 Quote from: Mike Hearn on February 02, 2013, 03:44:15 PM Services that can be abused (wikis, forums, webmail etc) need a blacklistable identity for each user so bad behaviour can be punished through exclusion. If no such blacklistable identity exists then account termination is pointless because the abuser will just immediately sign up again. This is why Tor tends to have a read-only view of the internet. Mesh networks like cjdns will have the same problem. Small sites tend to use IP address but this is weak; more advanced operations like the Google abuse team use phone verification and other techniques.



For anonymous users to take part, a cost on establishing an identity must be imposed. We can do this by requiring users to present a proof that they gave away some coins to miner fees. The proof is standalone and can be checked by anyone who has a copy of the block headers. The hash of that proof becomes the pseudonym, it can be checked against Spamhaus style DNS blacklists to discover past behaviour that has been associated with that nym and optionally blocked.



You sir, are a visionary, and I salute you. You sir, are a visionary, and I salute you.

paybitcoin



Offline



Activity: 85

Merit: 10





1h79nc







MemberActivity: 85Merit: 101h79nc Re: Creating Bitcoin passports using sacrifices February 03, 2013, 04:11:36 AM #7



I would think it would be better to have some adjusted-purchasing-power token that you can purchase, and then those could be traded on an alt-chain explicitly (kind of like in Anon136's comment above.) Since it lives outside of Bitcoin there is much more flexibility to the rules that can be enforced explicitly to implement contracts and the like with real power, instead of a web-of-trust method of servers checking hashes or polling for fraud notices that live inside the Bitcoin block chain. It is transferable so you don't have to worry (too much) about key compromise destroying the whole reputation.



I posted a thread on this system a few days ago in



Unfortunately I think it's not really the right audience in Alternative Cryptocurrencies, and I haven't really gotten any good feedback, even a 'you suck and this system sucks' would be valuable though ... The problem that I have with fee values is that the purchasing power with Bitcoin is not fixed - a passport created 3 years ago might have needed to burn 100's or 1000's of BTC to claim legitimacy; requiring any application to have some sort of exchange rate lookup as part of the passport application.I would think it would be better to have some adjusted-purchasing-power token that you can purchase, and then those could be traded on an alt-chain explicitly (kind of like in Anon136's comment above.) Since it lives outside of Bitcoin there is much more flexibility to the rules that can be enforced explicitly to implement contracts and the like with real power, instead of a web-of-trust method of servers checking hashes or polling for fraud notices that live inside the Bitcoin block chain. It is transferable so you don't have to worry (too much) about key compromise destroying the whole reputation.I posted a thread on this system a few days ago in Repcoin: a decentralized reputation currency Unfortunately I think it's not really the right audience in Alternative Cryptocurrencies, and I haven't really gotten any good feedback, even a 'you suck and this system sucks' would be valuable though ...

Anon136



Offline



Activity: 1666

Merit: 1211









LegendaryActivity: 1666Merit: 1211 Re: Creating Bitcoin passports using sacrifices February 03, 2013, 01:13:31 PM

Last edit: February 03, 2013, 01:29:20 PM by Anon136 #8 Quote from: paybitcoin on February 03, 2013, 04:11:36 AM The problem that I have with fee values is that the purchasing power with Bitcoin is not fixed - a passport created 3 years ago might have needed to burn 100's or 1000's of BTC to claim legitimacy; requiring any application to have some sort of exchange rate lookup as part of the passport application.



Since the identities would be marketable the value of the identities would be pegged to bitcoin value. this would only become a problem in the situation where you had used this identity to insure something and during the course of the transaction the value of btc fell enough to make the indentity worth less than the benifit to the other party of scamming you. So long as bitcoin didnt fall precipitously and you made sure to only contract with people who left some wiggle room between the value of the identity and the outstanding obligations tied to that identity it wouldn't be a problem. 25% buffer should keep you safe from anything < than a rapid %25 swing in the value of btc Since the identities would be marketable the value of the identities would be pegged to bitcoin value. this would only become a problem in the situation where you had used this identity to insure something and during the course of the transaction the value of btc fell enough to make the indentity worth less than the benifit to the other party of scamming you. So long as bitcoin didnt fall precipitously and you made sure to only contract with people who left some wiggle room between the value of the identity and the outstanding obligations tied to that identity it wouldn't be a problem. 25% buffer should keep you safe from anything < than a rapid %25 swing in the value of btc

If one can not confer upon another a right which he does not himself first possess, by what means does the state derive the right to engage in behaviors from which the public is prohibited? Rep Thread: https://bitcointalk.org/index.php?topic=381041 If one can not confer upon another a right which he does not himself first possess, by what means does the state derive the right to engage in behaviors from which the public is prohibited?

Mike Hearn





Offline



Activity: 1526

Merit: 1008







LegendaryActivity: 1526Merit: 1008 Re: Creating Bitcoin passports using sacrifices February 03, 2013, 01:55:50 PM #9 Quote I can't say that I'm a fan of the new name you've given this but I'm not the person to ask. It'll be interesting to see what other people think.

I'm not really happy with it either, but I think it's better than fidelity bonds: my issue with this name is that both "fidelity" and "bond" (as a financial concept) are not terms commonly used in English. Fidelity tends to have connotations to sexual loyalty even though it can be used more generally, so it could be confusing to have it crop up in another context. Also whilst anyone who is interested in finance knows all about bonds, most people have never actually experienced one themselves.



Passports are an everyday concept, and everyone immediately understands that you present them to get into places, they are revokable, they are hard to obtain and forge, etc. The main sticking point is that "anonymous passport" is something of a contradiction, but I feel it can be workable.



Still, I'm sure better names are possible.



Quote The consecutive block requirement is a bit ugly, as it requires N transactions instead of one or two and the provided fees will need to be somewhat high to get an acceptably gapped run with high confidence.

Seeing as the transactions are all-fee anyway, miners have no incentive to not include them (unless Bitcoin turns into a network for high value transactions only of course). I'd think you could set a threshold, say 4 of 6 blocks must include them, or something like that. The right gap thresholds could be determined empirically.



I think the main advantage of Peters earlier suggestion for semi-consecutive blocks is simplicity - there's no need for new logic specific to this app in the miners, though auto-pruning OP_FALSE transactions would be a neat optimization for nodes that upgrade. I'm not a big fan of having app-specific stuff in core Bitcoin ... the IsStandard() stuff being a necessary evil in my eye rather than something to strive for. Besides, embedding a transaction inside another transaction seems superfluous (the second tx could just be broadcast and sit in the memory pool for a while).



Post-pruning size with OP_FALSE outputs is zero, is it not?



Quote FWIW I posted about consecutive miners fees (and the whole bank idea) months ago to the forums and bitcoin dev email list and didn't pursue it because of the risk that the txs wouldn't be consecutive, as well as the size. The tx-in-tx idea is what made me think it was practical without just destroying coins. I notice that you are tying the identity to the pubkeys signing the txins. An additional problem to this is the pack of transferability means that key compromise is not recoverable. You also limit the granularity to the minimum fees, which will be much larger in the future.

Ah yes, so you did. I must have forgotten the consecutive tx trick was originally from you as well.



I'm not worried about the size. As I said, all-fee transactions should be completely prunable away. You don't need a whole lot of blocks, just a few would be sufficient, so gaps are OK. I'm not worried about miners who manage to mine the majority of all blocks within the consecutive-blocks period because if that could happen we'd have a 51%+ attacker, and then we'd all have bigger problems than this.



I'm not sure minimum fees will be much larger in future. That's certainly not a consensus anyway. I see fees being similar, lower or even being zero for most casual users, that could happen in a world where miners are funded through assurance contracts of participants who need the security (merchants, exchanges, traders etc).



Being able to re-sell the identities (without changing them) seems important to me. People don't like waiting. Any proposed scheme has a long lead-time to the manufacture of new passports. Having dedicated sellers that keep some in stock means you'd be able to get started right away instead of making them yourself. Yes, it means you have to trust the seller. I like your suggestion of making passports



Quote The problem that I have with fee values is that the purchasing power with Bitcoin is not fixed - a passport created 3 years ago might have needed to burn 100's or 1000's of BTC to claim legitimacy; requiring any application to have some sort of exchange rate lookup as part of the passport application.

The app that checks the passports needs the block headers anyway. It can always record spot rates along side its storage of the headers. There's no trust-free way to bootstrap that, but exchange rates are a matter of public record and would be hard to forge in any significant way without someone noticing that it's historically inconsistent.



Quote You sir, are a visionary, and I salute you.

Chris, thanks, but as you can see from this thread most of the thinking here is done by retep (Peter Todd). I wanted to flesh out more precise specs so we can put it on the wiki, like I've done for other protocols, that way it's possible that someone who is more of a coder than designer has good documentation they can work from. When I did this for smart property and distributed bonds, it did indeed encourage someone (jgarzik) to go ahead and implement it. I'm not really happy with it either, but I think it's better than fidelity bonds: my issue with this name is that both "fidelity" and "bond" (as a financial concept) are not terms commonly used in English. Fidelity tends to have connotations to sexual loyalty even though it can be used more generally, so it could be confusing to have it crop up in another context. Also whilst anyone who is interested in finance knows all about bonds, most people have never actually experienced one themselves.Passports are an everyday concept, and everyone immediately understands that you present them to get into places, they are revokable, they are hard to obtain and forge, etc. The main sticking point is that "anonymous passport" is something of a contradiction, but I feel it can be workable.Still, I'm sure better names are possible.Seeing as the transactions are all-fee anyway, miners have no incentive to not include them (unless Bitcoin turns into a network for high value transactions only of course). I'd think you could set a threshold, say 4 of 6 blocks must include them, or something like that. The right gap thresholds could be determined empirically.I think the main advantage of Peters earlier suggestion for semi-consecutive blocks is simplicity - there's no need for new logic specific to this app in the miners, though auto-pruning OP_FALSE transactions would be a neat optimization for nodes that upgrade. I'm not a big fan of having app-specific stuff in core Bitcoin ... the IsStandard() stuff being a necessary evil in my eye rather than something to strive for. Besides, embedding a transaction inside another transaction seems superfluous (the second tx could just be broadcast and sit in the memory pool for a while).Post-pruning size with OP_FALSE outputs is zero, is it not?Ah yes, so you did. I must have forgotten the consecutive tx trick was originally from you as well.I'm not worried about the size. As I said, all-fee transactions should be completely prunable away. You don't need a whole lot of blocks, just a few would be sufficient, so gaps are OK. I'm not worried about miners who manage to mine the majority of all blocks within the consecutive-blocks period because if that could happen we'd have a 51%+ attacker, and then we'd all have bigger problems than this.I'm not sure minimum fees will be much larger in future. That's certainly not a consensus anyway. I see fees being similar, lower or even being zero for most casual users, that could happen in a world where miners are funded through assurance contracts of participants who need the security (merchants, exchanges, traders etc).Being able to re-sell the identities (without changing them) seems important to me. People don't like waiting. Any proposed scheme has a long lead-time to the manufacture of new passports. Having dedicated sellers that keep some in stock means you'd be able to get started right away instead of making them yourself. Yes, it means you have to trust the seller. I like your suggestion of making passports smart property , that could be a useful extension indeed. Having each sacrifice tx have a control output that is then spent by the next sacrifice in the chain seems like the way to go, then you can just use the last control output to sell the whole thing.The app that checks the passports needs the block headers anyway. It can always record spot rates along side its storage of the headers. There's no trust-free way to bootstrap that, but exchange rates are a matter of public record and would be hard to forge in any significant way without someone noticing that it's historically inconsistent.Chris, thanks, but as you can see from this thread most of the thinking here is done by retep (Peter Todd). I wanted to flesh out more precise specs so we can put it on the wiki, like I've done for other protocols, that way it's possible that someone who is more of a coder than designer has good documentation they can work from. When I did this for smart property and distributed bonds, it did indeed encourage someone (jgarzik) to go ahead and implement it.

Mike Hearn





Offline



Activity: 1526

Merit: 1008







LegendaryActivity: 1526Merit: 1008 Re: Creating Bitcoin passports using sacrifices February 03, 2013, 07:03:07 PM #10 One issue with making passports smart property that just occurred to me is that it'd increase the requirements to having a copy of the utxo set because otherwise you couldn't know if the control output on the tx you were given was already spent or not. So you'd have to either run a full node or extend the p2p protocol so membership in the utxo set could be remotely tested by thin clients.

Peter Todd





Offline



Activity: 1106

Merit: 1045







LegendaryActivity: 1106Merit: 1045 Re: Creating Bitcoin passports using sacrifices February 05, 2013, 06:16:26 AM

Last edit: February 05, 2013, 06:35:20 AM by retep #11



Quote from: Mike Hearn on February 03, 2013, 01:55:50 PM I'm not really happy with it either, but I think it's better than fidelity bonds: my issue with this name is that both "fidelity" and "bond" (as a financial concept) are not terms commonly used in English. Fidelity tends to have connotations to sexual loyalty even though it can be used more generally, so it could be confusing to have it crop up in another context. Also whilst anyone who is interested in finance knows all about bonds, most people have never actually experienced one themselves.



Keep in mind that the term "fidelity bond" isn't just a finance term, it also crops up in stuff like security guard jobs. That's actually the first place I heard it, talking to someone explaining how they were now a bonded guard. That said, more specifically for what you are talking about re: wiki and similar services, I think "passport" is reasonable enough. It's also good that it has the real-world connotation that acceptance of a passport is not absolute. Similarly what is blacklistable behavior is ultimately a human criteria, and you'll find that rough consensus emerges among groups of mutually trusted services, but a passport revoked by Wikipedia may not be considered revoked by 4chan.



Fidelity bonded banking has the advantage that the contracts can be made machine readable. Of course, equally, the disadvantage is that the contracts are machine readable... One little mistake...



As for the term "sacrifice", I think this is a really good one for describing the nitty gritty of any of these protocols; I was racking my brain trying to come up with a decent term and I think sacrifice solves that problem.



Quote from: Mike Hearn on February 03, 2013, 01:55:50 PM Seeing as the transactions are all-fee anyway, miners have no incentive to not include them (unless Bitcoin turns into a network for high value transactions only of course). I'd think you could set a threshold, say 4 of 6 blocks must include them, or something like that. The right gap thresholds could be determined empirically.



It's not just about incentive, what happens when you get a near orphan by pure luck? We already see transactions getting passed up by miners who missed them for whatever reason all the time. Yet as gaps increase, it just makes it easier for a relatively low hash rate miner to just wait until they get lucky, while only risking the small chance that their block is orphaned and another miner picks up the tx for the fee.



Quote from: Mike Hearn on February 03, 2013, 01:55:50 PM Besides, embedding a transaction inside another transaction seems superfluous (the second tx could just be broadcast and sit in the memory pool for a while).



How do you prove that a tx existed in the memory pool after the fact?



Quote from: Mike Hearn on February 03, 2013, 01:55:50 PM Post-pruning size with OP_FALSE outputs is zero, is it not?



I'm pretty sure any script ending in OP_FALSE is guaranteed unspendable. Even the OP_IF stuff has a check (via vfExec) to ensure that an IF block is terminated; there are no op-codes that mark a script as valid and terminate execution. OP_RETURN at the end of the script would work too I think.



Quote from: Mike Hearn on February 03, 2013, 01:55:50 PM I'm not worried about the size. As I said, all-fee transactions should be completely prunable away.



It's not just blockchain size, it's proof size. You have to be able to prove to a SPV client that the transactions exist, so you have to hand them the transactions and the merkle path to the block header. In addition a malicious miner can currently pad transactions to a maximum of 10KiB scriptSigs.



Quote from: Mike Hearn on February 03, 2013, 01:55:50 PM You don't need a whole lot of blocks, just a few would be sufficient, so gaps are OK. I'm not worried about miners who manage to mine the majority of all blocks within the consecutive-blocks period because if that could happen we'd have a 51%+ attacker, and then we'd all have bigger problems than this.



Again, you don't have to have 51%, you just need to get lucky once every few months.



Quote from: Mike Hearn on February 03, 2013, 01:55:50 PM I'm not sure minimum fees will be much larger in future. That's certainly not a consensus anyway. I see fees being similar, lower or even being zero for most casual users, that could happen in a world where miners are funded through assurance contracts of participants who need the security (merchants, exchanges, traders etc).



Well, you're assuming the block size will be lifted which I'm dead set against.



Quote from: Mike Hearn on February 03, 2013, 01:55:50 PM Quote The problem that I have with fee values is that the purchasing power with Bitcoin is not fixed - a passport created 3 years ago might have needed to burn 100's or 1000's of BTC to claim legitimacy; requiring any application to have some sort of exchange rate lookup as part of the passport application.

The app that checks the passports needs the block headers anyway. It can always record spot rates along side its storage of the headers. There's no trust-free way to bootstrap that, but exchange rates are a matter of public record and would be hard to forge in any significant way without someone noticing that it's historically inconsistent.

The app that checks the passports needs the block headers anyway. It can always record spot rates along side its storage of the headers. There's no trust-free way to bootstrap that, but exchange rates are a matter of public record and would be hard to forge in any significant way without someone noticing that it's historically inconsistent.

Being able to sell part of the cost of an identity, as you suggest, fixes the problem of fee values just fine: sell off the part of the fee that you don't need. It's a lot nicer than the huge pain of trying to record spot rates, although having said that you will need some estimate of the liquidity and supply and demand for the current market for fidelity bonds for any given application.





Quote from: Mike Hearn on February 03, 2013, 07:03:07 PM One issue with making passports smart property that just occurred to me is that it'd increase the requirements to having a copy of the utxo set because otherwise you couldn't know if the control output on the tx you were given was already spent or not. So you'd have to either run a full node or extend the p2p protocol so membership in the utxo set could be remotely tested by thin clients.



Well, I think this touches on one of the reasons why I'm 100% against raising the 1MiB block limit, especially with the sort of floating limit that Gavin and others have proposed: you can't have really trustworthy fidelity bonded transaction processors, and unbounded block sizes at the same time. It's in miner's incentives to do what they can to undermine the off-chain transactions to try to get as many transactions as they can for themselves, and just by increasing the block-size they achieve that goal by further centralizing who can verify the utxo set.



Keep in mind it's not even just a total blockchain size issue, it's a bandwidth issue. 1MiB/10minutes is just 2KiB/s, small enough to keep up with even on highly bandwidth constrained nodes stuck behind restrictive firewalls in unfriendly countries. A node operating under these conditions may never need to actually make an on-chain transaction, but they will be able to easily keep track of fund movements for the fidelity-bonded transaction processors they are depending on to move their Bitcoins, and they'll be able to keep track of those movements with a much higher degree of certainty than with any of the utxo proposals, especially because that one single node, which might be the only connection to the blockchain for a big area, can redistribute everything every other node in that area needs to know. And again, in an unbounded blocksize world miners have every reason to sabotage UTXO mechanisms if they'll stop off-chain transaction processors from operating successfully.



I'll write more on this later, but increasing the block size is madness. I thought people were still taught how ugly O(n) and O(n^2) scaling was in school... I posted my first draft of something approaching a proper tech spec for this fidelity bond/contract stuff: https://github.com/petertodd/trustbits/blob/master/fidelitybond.md Keep in mind that the term "fidelity bond" isn't just a finance term, it also crops up in stuff like security guard jobs. That's actually the first place I heard it, talking to someone explaining how they were now a bonded guard. That said, more specifically for what you are talking about re: wiki and similar services, I think "passport" is reasonable enough. It's also good that it has the real-world connotation that acceptance of a passport is not absolute. Similarly what is blacklistable behavior is ultimately a human criteria, and you'll find that rough consensus emerges among groups of mutually trusted services, but a passport revoked by Wikipedia may not be considered revoked by 4chan.Fidelity bonded banking has the advantage that the contracts can be made machine readable. Of course, equally, the disadvantage is that the contracts are machine readable... One little mistake...As for the term "sacrifice", I think this is a really good one for describing the nitty gritty of any of these protocols; I was racking my brain trying to come up with a decent term and I think sacrifice solves that problem.It's not just about incentive, what happens when you get a near orphan by pure luck? We already see transactions getting passed up by miners who missed them for whatever reason all the time. Yet as gaps increase, it just makes it easier for a relatively low hash rate miner to just wait until they get lucky, while only risking the small chance that their block is orphaned and another miner picks up the tx for the fee.How do you prove that a tx existed in the memory pool after the fact?I'm pretty sure any script ending in OP_FALSE is guaranteed unspendable. Even the OP_IF stuff has a check (via vfExec) to ensure that an IF block is terminated; there are no op-codes that mark a script as valid and terminate execution. OP_RETURN at the end of the script would work too I think.It's not just blockchain size, it's proof size. You have to be able to prove to a SPV client that the transactions exist, so you have to hand them the transactions and the merkle path to the block header. In addition a malicious miner can currently pad transactions to a maximum of 10KiB scriptSigs.Again, you don't have to have 51%, you just need to get lucky once every few months.Well, you're assuming the block size will be lifted which I'm dead set against.Being able to sell part of the cost of an identity, as you suggest, fixes the problem of fee values just fine: sell off the part of the fee that you don't need. It's a lot nicer than the huge pain of trying to record spot rates, although having said that you will need some estimate of the liquidity and supply and demand for the current market for fidelity bonds for any given application.Well, I think this touches on one of the reasons why I'm 100% against raising the 1MiB block limit, especially with the sort of floating limit that Gavin and others have proposed: you can't have really trustworthy fidelity bonded transaction processors, and unbounded block sizes at the same time. It's in miner's incentives to do what they can to undermine the off-chain transactions to try to get as many transactions as they can for themselves, and just by increasing the block-size they achieve that goal by further centralizing who can verify the utxo set.Keep in mind it's not even just a total blockchain size issue, it's a bandwidth issue. 1MiB/10minutes is just 2KiB/s, small enough to keep up with even on highly bandwidth constrained nodes stuck behind restrictive firewalls in unfriendly countries. A node operating under these conditions may never need to actually make an on-chain transaction, but they will be able to easily keep track of fund movements for the fidelity-bonded transaction processors they are depending on to move their Bitcoins, and they'll be able to keep track of those movements with a much higher degree of certainty than with any of the utxo proposals, especially because that one single node, which might be the only connection to the blockchain for a big area, can redistribute everything every other node in that area needs to know. And again, in an unbounded blocksize world miners have every reason to sabotage UTXO mechanisms if they'll stop off-chain transaction processors from operating successfully.I'll write more on this later, but increasing the block size is madness. I thought people were still taught how ugly O(n) and O(n^2) scaling was in school... BTC: 1FCYd7j4CThTMzts78rh6iQJLBRGPW9fWv PGP: 7FAB114267E4FA04

Mike Hearn





Offline



Activity: 1526

Merit: 1008







LegendaryActivity: 1526Merit: 1008 Re: Creating Bitcoin passports using sacrifices February 05, 2013, 10:02:10 AM #12 Quote from: retep on February 05, 2013, 06:16:26 AM Keep in mind that the term "fidelity bond" isn't just a finance term, it also crops up in stuff like security guard jobs.



Hmm. I'm not sure this undermines my argument I never heard of a "bonded guard" and I think I read more than the average person.



Quote from: retep on February 05, 2013, 06:16:26 AM It's not just about incentive, what happens when you get a near orphan by pure luck? We already see transactions getting passed up by miners who missed them for whatever reason all the time. Yet as gaps increase, it just makes it easier for a relatively low hash rate miner to just wait until they get lucky, while only risking the small chance that their block is orphaned and another miner picks up the tx for the fee.



I didn't follow this, sorry How does a low hash rate miner get to mine several blocks in a short timeframe, except through such wild luck that it's not worth worrying about?



Quote from: retep on February 05, 2013, 06:16:26 AM How do you prove that a tx existed in the memory pool after the fact?



It's either in the memory pool and waiting to be included (in which case a verifying node can see it), or it's fallen from the pool into the chain, in which case the verifying node can see it or be given it.



Quote from: retep on February 05, 2013, 06:16:26 AM I'm pretty sure any script ending in OP_FALSE is guaranteed unspendable. Even the OP_IF stuff has a check (via vfExec) to ensure that an IF block is terminated; there are no op-codes that mark a script as valid and terminate execution. OP_RETURN at the end of the script would work too I think.



Yes, it is, that's indeed the point - whilst it's guaranteed unspendable the ultraprune algorithm doesn't know that, so we can just tweak it so such outputs drop out of the UTXO set immediately. Then the only nodes that have a cost imposed by sacrificial transactions are archival nodes.



Quote from: retep on February 05, 2013, 06:16:26 AM Keep in mind it's not even just a total blockchain size issue, it's a bandwidth issue. 1MiB/10minutes is just 2KiB/s, small enough to keep up with even on highly bandwidth constrained nodes stuck behind restrictive firewalls in unfriendly countries.



This is better debated on the other thread that's discussing block sizes at the moment. Suffice it to say that I don't care about people who want to run fully validating nodes on their calculator in the middle of the desert A world in which all fully validating nodes run in datacenters is A-OK by me, for the same reason that I don't worry about the fact that nobody runs websites from home any more. The future of Bitcoin is nodes running on dedicated servers, probably servers that won't seem very powerful by the standards of the day. Hmm. I'm not sure this undermines my argumentI never heard of a "bonded guard" and I think I read more than the average person.I didn't follow this, sorryHow does a low hash rate miner get to mine several blocks in a short timeframe, except through such wild luck that it's not worth worrying about?It's either in the memory pool and waiting to be included (in which case a verifying node can see it), or it's fallen from the pool into the chain, in which case the verifying node can see it or be given it.Yes, it is, that's indeed the point - whilst it's guaranteed unspendable the ultraprune algorithm doesn't know that, so we can just tweak it so such outputs drop out of the UTXO set immediately. Then the only nodes that have a cost imposed by sacrificial transactions are archival nodes.This is better debated on the other thread that's discussing block sizes at the moment. Suffice it to say that I don't care about people who want to run fully validating nodes on their calculator in the middle of the desertA world in which all fully validating nodes run in datacenters is A-OK by me, for the same reason that I don't worry about the fact that nobody runs websites from home any more. The future of Bitcoin is nodes running on dedicated servers, probably servers that won't seem very powerful by the standards of the day.

Vitalik Buterin



Offline



Activity: 331

Merit: 377







Sr. MemberActivity: 331Merit: 377 Re: Creating Bitcoin passports using sacrifices February 05, 2013, 11:18:27 AM #13 Quote from: Mike Hearn on February 02, 2013, 03:44:15 PM

(1) Why miner fees instead of a charity?



There are several problems with the idea of donating to charity:



Charities are not politically neutral as miners are. For instance, if you wanted to donate to charities that operate in Iran that might be an issue. Nobody will be able to agree on one set of charities that makes everyone happy - even "no brainers" like open source foundations would be a turnoff to non-technical people who may wish to use the system.

Charities massively prefer to have real relationships with donators who commit to the long term (or can be convinced to do so). Anonymous, unpredictable revenue flows can make their accounting much harder because they don't know when money might arrive, so it can't be relied upon. A charity that received money this way then didn't use it would lose a lot of goodwill through no real fault of their own.

Some charities do not want to or cannot accept anonymous donations at all.

Everyone would have to agree on the list of charities to use ahead of time, so there would be no connection between how well a charity does and how much it received in sacrifice fees. A charity may operate effectively for a few years and then become corrupt or incompetent, but upgrading everyones software to use a new list would be difficult.

There are several problems with the idea of donating to charity:

The thing is that you missed one obvious choice: paying the bitcoins to the forum/email site/whatever itself. That may actually be the best option of all, as there is an argument that the reason why sites are so eager to infringe upon our privacy is that advertising revenue is the only revenue they have, and so if we can convince users to pay a 15 cent fee to the website for setting up an account we may end up fixing not just the spam problem, but also the privacy problem at the same time.



If we do not want to do that, I would prefer if there could be some way to dual-use your mining spending - that is, make your Bitcoin passport out of a transaction fee that you are spending anyway to make a given transaction go faster. Then, the rate could be increased significantly, and the only users that would have to actually pay anything extra are those creating multiple passports, with normal users spending nothing extra at all. The thing is that you missed one obvious choice: paying the bitcoins to the forum/email site/whatever itself. That may actually be the best option of all, as there is an argument that the reason why sites are so eager to infringe upon our privacy is that advertising revenue is the only revenue they have, and so if we can convince users to pay a 15 cent fee to the website for setting up an account we may end up fixing not just the spam problem, but also the privacy problem at the same time.If we do not want to do that, I would prefer if there could be some way to dual-use your mining spending - that is, make your Bitcoin passport out of a transaction fee that you are spending anyway to make a given transaction go faster. Then, the rate could be increased significantly, and the only users that would have to actually pay anything extra are those creating multiple passports, with normal users spending nothing extra at all. Argumentum ad lunam: the fallacy that because Bitcoin's price is rising really fast the currency must be a speculative bubble and/or Ponzi scheme.

Mike Hearn





Offline



Activity: 1526

Merit: 1008







LegendaryActivity: 1526Merit: 1008 Re: Creating Bitcoin passports using sacrifices February 05, 2013, 01:51:18 PM

Last edit: February 05, 2013, 02:21:18 PM by Mike Hearn #14 Quote from: Vitalik Buterin on February 05, 2013, 11:18:27 AM The thing is that you missed one obvious choice: paying the bitcoins to the forum/email site/whatever itself.



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.



Quote That may actually be the best option of all, as there is an argument that the reason why sites are so eager to infringe upon our privacy is that advertising revenue is the only revenue they have, and so if we can convince users to pay a 15 cent fee to the website for setting up an account we may end up fixing not just the spam problem, but also the privacy problem at the same time.



I think micropayments for replacing ads makes a great deal of sense (edit) but I think it's a separate problem from abuse controls. I didn't miss it. It was the first example of how to use contracts I ever put on the wiki: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.

Mike Hearn





Offline



Activity: 1526

Merit: 1008







LegendaryActivity: 1526Merit: 1008 Re: Creating Bitcoin passports using sacrifices February 06, 2013, 08:35:44 AM #18 Quote from: retep on February 06, 2013, 07:27:23 AM 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?



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.



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



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

Peter Todd





Offline



Activity: 1106

Merit: 1045







LegendaryActivity: 1106Merit: 1045 Re: Creating Bitcoin passports using sacrifices February 11, 2013, 09:12:10 AM #19 Quote from: Mike Hearn on February 06, 2013, 08:35:44 AM Quote from: retep on February 06, 2013, 07:27:23 AM 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?



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?

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?

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.



Quote from: Mike Hearn on February 06, 2013, 08:35:44 AM 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.



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



Quote from: Mike Hearn on February 06, 2013, 08:35:44 AM

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

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. 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. BTC: 1FCYd7j4CThTMzts78rh6iQJLBRGPW9fWv PGP: 7FAB114267E4FA04