Peter Todd



Offline



Activity: 1106

Merit: 1045







LegendaryActivity: 1106Merit: 1045 Offer: Mastercoin analysis and transaction specification design September 22, 2013, 06:24:37 PM #1 Quote from: dacoinminster on September 16, 2013, 04:02:37 PM Quote https://bitcointalk.org/index.php?topic=265488.msg3164831#msg3164831



I was reading the above post describing efforts to come up with a new Mastercoin tx scheme; there are a lot of issues with the above, in particular misconceptions about how Bitcoin works, as well as missed opportunities to add censorship resistance. In addition there are potential upcoming changes to Bitcoin that could seriously harm your protocol - changes that may end up getting more support than otherwise because they do exactly that.



I'd can create a complete specification taking all these issues into account, including explaining those issues are exactly and what trade-offs (and alternatives) were involved in coming up with the spec. In short I plan to answer the question "How do you implement a blockchain on top of Bitcoin in a robust, low-resource, and censor-proof way?"



If you are interested let me know and we can work out a set of concrete deliverables: specification document, design rational, and (optionally) example code written in Python with python-bitcoinlib implementing the proposed specification. Any contract would be fixed price, no-cure-no-pay, with a third party approved by both parties acting as escrow in a 2-of-3 multisig transaction deciding if I had in fact completed it successfully. Jeff Garzik has done work along these lines in the past ( I was reading the above post describing efforts to come up with a new Mastercoin tx scheme; there are a lot of issues with the above, in particular misconceptions about how Bitcoin works, as well as missed opportunities to add censorship resistance. In addition there are potential upcoming changes to Bitcoin that could seriously harm your protocol - changes that may end up getting more support than otherwise because they do exactly that.I'd can create a complete specification taking all these issues into account, including explaining those issues are exactly and what trade-offs (and alternatives) were involved in coming up with the spec. In short I plan to answer the question "How do you implement a blockchain on top of Bitcoin in a robust, low-resource, and censor-proof way?"If you are interested let me know and we can work out a set of concrete deliverables: specification document, design rational, and (optionally) example code written in Python with python-bitcoinlib implementing the proposed specification. Any contract would be fixed price, no-cure-no-pay, with a third party approved by both parties acting as escrow in a 2-of-3 multisig transaction deciding if I had in fact completed it successfully. Jeff Garzik has done work along these lines in the past ( pybond ) and may be able to take on that role.

I'm not revealing the source, since it was a PM, but it was someone who I believe to have a pretty good grasp of the inner workings - better than my own understanding at any rate. It's also someone who is not particularly enthusiastic about this project, so I imagine their price for the work described would be more than we would be willing to pay. I of course invited them to participate in the contest, but I doubt they will.



I suggest we give Tachikoma's method a shot and see what happens. It may be that we have to change our encoding method again if our skeptical friend is right and future bitcoin changes make this method unworkable. Of course, if anybody has a better idea, I'd love to hear it.

I'm not revealing the source, since it was a PM, but it was someone who I believe to have a pretty good grasp of the inner workings - better than my own understanding at any rate. It's also someone who is not particularly enthusiastic about this project, so I imagine their price for the work described would be more than we would be willing to pay. I of course invited them to participate in the contest, but I doubt they will.I suggest we give Tachikoma's method a shot and see what happens. It may be that we have to change our encoding method again if our skeptical friend is right and future bitcoin changes make this method unworkable. Of course, if anybody has a better idea, I'd love to hear it.

As some of you either know or suspected all along that PM was sent to J.R Willett by myself. He said he probably wasn't going to need my services, but would welcome a fleshed out proposal all the same. Keeping the proposal secret seemed like a bit too much of cloak-n-dagger sillyness to me, and in any case I thought my services might be of interest to MasterCoin investors or even those with unrelated projects using the same concepts, so I'm just going to present it in public and allow the community to consider it.



Stage 1: Analysis



To design a specification for how MasterCoin transactions are to be encoded I first have to analyze the larger MasterCoin protocol. Of course a part of the protocol has already been implemented and used in production: the Exodus Address. But that's simply an initial bootstrapping mechanism to define who owns what MasterCoins - the rest of the MasterCoin protocol and design is essentially unspecified at present. (based on the materials available to me at mastercoin.org, including the wiki and the various versions of the whitepaper, and materials on this forum)



I will first review and solidify the requirements for what MasterCoin is meant to be: What type of consensus model does MasterCoin actually need? Does it need what at all? What information do participants require to make and validate a transaction? Because MasterCoin is meant to be a protocol by which other currencies can be created, the answers to these questions in turn decide what those currencies, and trades between those currencies, are actually capable of. Of course it's not my job to decide what MasterCoin is, but rather to give the MasterCoin community an honest assessment of what options are available and what consequences those choices have.



Part of this analysis includes an honest assessment of whether or not "MasterCoin's" - created by a transfer to the Exodus address prior to August 31st 2013 - are in fact actually required at all. Anyone who has invested in MasterCoins, or is considering doing so, should think hard about this question given that the only thing making their investment valuable is the requirement for MasterCoins. If it is the case that MasterCoins are not an essential part of the protocol it is quite likely that copy-cat's will arise later with many or all of the features that the "official" MasterCoin protocol provides. In this case the value of their investment may be severely diminished and investors would be wise to sell their coins to others while they can still get a good price for them.





Stage 2: Bitcoin blockchain transaction specification



If Stage 1 determines that the Bitcoin blockchain is required in some way the next step is to flesh out how exactly that data will be encoded. Of course, the stage 1 analysis needs to be done taking the options available in stage 2 into account, but it is in this stage where the specific details of those choices are fleshed out. Considerations here include fee efficiency, Blockchain space efficiency, verifiability, and scalability. In addition censorship resistance is important - given the hostility towards MasterCoin's proposed and current use of the blockchain the scheme chosen should be ideally designed to be difficult or impossible for miners to exclude from the transactions they mine. Finally where possible advanced cryptography should be considered, such as non-interactive proofs, so that even if such cryptography is not used now it can be implemented in the future to better achieve technical goals.





Compensation



40BTC for the stage 1 report, and approximately 25BTC for the stage 2 specification, although that figure is subject to change depending on the results of the initial report. In addition I am willing to offer discounts for reports made public: 50% if they are made public immediately, and 25% if they are to be made public at some pre-agreed time in the future. Payment must be made upfront to a 2-of-3 multisig address, with the third pubkey controlled by an third-party escrow agent; expect an additional 5% fee to compensate that agent.



I am open to doing reports for the community as a whole; investors in particular may be interested in an independent analysis of MasterCoin's long-term viability to better decide if they should retain their positions. Such an effort could be done as a KickStarter style pledge where either the report is fully funded, or partial amounts are simply returned to those who pledged them.





Thank you for your time,



Peter Todd As some of you either know or suspected all along that PM was sent to J.R Willett by myself. He said he probably wasn't going to need my services, but would welcome a fleshed out proposal all the same. Keeping the proposal secret seemed like a bit too much of cloak-n-dagger sillyness to me, and in any case I thought my services might be of interest to MasterCoin investors or even those with unrelated projects using the same concepts, so I'm just going to present it in public and allow the community to consider it.To design a specification for how MasterCoin transactions are to be encoded I first have to analyze the larger MasterCoin protocol. Of course a part of the protocol has already been implemented and used in production: the Exodus Address. But that's simply an initial bootstrapping mechanism to define who owns what MasterCoins - the rest of the MasterCoin protocol and design is essentially unspecified at present. (based on the materials available to me at mastercoin.org, including the wiki and the various versions of the whitepaper, and materials on this forum)I will first review and solidify the requirements for what MasterCoin is meant to be: What type of consensus model does MasterCoin actually need? Does it need what at all? What information do participants require to make and validate a transaction? Because MasterCoin is meant to be a protocol by which other currencies can be created, the answers to these questions in turn decide what those currencies, and trades between those currencies, are actually capable of. Of course it's not my job to decide what MasterCoin is, but rather to give the MasterCoin community an honest assessment of what options are available and what consequences those choices have.Part of this analysis includes an honest assessment of whether or not "MasterCoin's" - created by a transfer to the Exodus address prior to August 31st 2013 - are in fact actually required at all. Anyone who has invested in MasterCoins, or is considering doing so, should think hard about this question given that the only thing making their investment valuable is the requirement for MasterCoins. If it is the case that MasterCoins are not an essential part of the protocol it is quite likely that copy-cat's will arise later with many or all of the features that the "official" MasterCoin protocol provides. In this case the value of their investment may be severely diminished and investors would be wise to sell their coins to others while they can still get a good price for them.If Stage 1 determines that the Bitcoin blockchain is required in some way the next step is to flesh out how exactly that data will be encoded. Of course, the stage 1 analysis needs to be done taking the options available in stage 2 into account, but it is in this stage where the specific details of those choices are fleshed out. Considerations here include fee efficiency, Blockchain space efficiency, verifiability, and scalability. In addition censorship resistance is important - given the hostility towards MasterCoin's proposed and current use of the blockchain the scheme chosen should be ideally designed to be difficult or impossible for miners to exclude from the transactions they mine. Finally where possible advanced cryptography should be considered, such as non-interactive proofs, so that even if such cryptography is not used now it can be implemented in the future to better achieve technical goals.40BTC for the stage 1 report, and approximately 25BTC for the stage 2 specification, although that figure is subject to change depending on the results of the initial report. In addition I am willing to offer discounts for reports made public: 50% if they are made public immediately, and 25% if they are to be made public at some pre-agreed time in the future. Payment must be made upfront to a 2-of-3 multisig address, with the third pubkey controlled by an third-party escrow agent; expect an additional 5% fee to compensate that agent.I am open to doing reports for the community as a whole; investors in particular may be interested in an independent analysis of MasterCoin's long-term viability to better decide if they should retain their positions. Such an effort could be done as a KickStarter style pledge where either the report is fully funded, or partial amounts are simply returned to those who pledged them.Thank you for your time,Peter Todd BTC: 1FCYd7j4CThTMzts78rh6iQJLBRGPW9fWv PGP: 7FAB114267E4FA04