Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability
On Sunday, February 09, 2014 11:33:02 PM Pieter Wuille wrote: > The proposed document is here: https://gist.github.com/sipa/8907691 Rule 3 & 4 are already enforced. AFAIK nVersion==3 transactions are not currently considered non-standard? Luke -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability
On Mon, Feb 10, 2014 at 12:33:02AM +0100, Pieter Wuille wrote: > Hello all, > > it was something I planned to do since a long time, but with the > recent related issues popping up, I finally got around to writing a > BIP about how we can get rid of transaction malleability over time. > > The proposed document is here: https://gist.github.com/sipa/8907691 > > I expect most rules to not be controversial. Maybe rules 1 and 3, as > they require modifications to wallet software (Bitcoin Core 0.9 and > BitcoinJ already implement it, though) and potentially invalidate some > script functionality. However, these new rules remain optional and > controlled by an nVersion increase. > > Comments please! You should probably add making CHECKMULTISIG require the dummy value to be exactly equal to OP_FALSE; verifying that in the transaction itself is laborious. A more subtle example is we may want both CHECKSIG and CHECKMULTISIG to fail the transaction if the signature is invalid but not exactly equal to OP_FALSE; some transaction forms are significantly more compact if you can have failed signatures, but that's a source of malleability. (are there counter examples people can think of?) But as I said on IRC, I'm a bit hesitant to bake in assumptions about malleability when we have no solid idea if ECC signatures are or are not malleable on a fundemental level; if "whack-a-mole" anti-malleability is all we've got it could be ugly if a break is found. Similarly, we may find we missed something, or some needed change makes the malleability rules difficult to work with for some new script type that is required. I'd rather see a new CHECKSIG mode for the case where malleability absolutely must be eliminated - certain multi-party protocols - and fix wallet software instead. (the malleability problems people see are closely related to inability to handle double-spends and reorgs) But I can easily see that being an impossible goal engineering wise... -- 'peter'[:-1]@petertodd.org 0001465bc2730ffed7493d166d18d288f6cf15e8cdb5d4a3c7b1 signature.asc Description: Digital signature -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Malware authors and best practices for addressing the issue from development / licensing perspective or other
Hello, I have a request, which is how do developers address the circumstance in which someone utilizes your code as part of some effort to deprive (or steal as the case may be) someone of their bitcoin? This hasn't happened to me, but I have posed a question about it at bitcointalk: https://bitcointalk.org/index.php?topic=454903.msg5045596#msg5045596 It was prompted by the apparent use of sx by a malware author who then generated something called Stealthbit (which is malware, and which no-one should touch). [fortunately I have not tried to access or use Stealthbit.) However, this is a question that also touches on bitcoin development generally, due to that (it's happened before, it will happen again, etc.) people may end up using bitcoin code (if they haven't already) to develop something else that would then be used expressly to deprive someone of their bitcoins (such as steal them, but I am not thinking only of theft here). My question for developers is: Given that code is open source and anything can be done with it, good or bad, what are common development approaches to mitigate or potentially prevent malware authors from being able to easily appropriate the code you develop? I realize this question may sound dumb and out of place being that it is pretty obvious that code which is developed in a free, open source context can technically be used for anything. However, beyond suggesting that people just go to bitcoin.org for wallet technology, what can be done in the development community that would lessen the likelihood that the code you develop might be "misappropriated?" Please note: I am not sure how this issue might be approached from a development perspective, or license (MIT, Affero GPL, etc.) perspective, or any other perspective.. I'm just asking the question. I support bitcoin and other decentralized currency efforts including walled development such as darkwallet, and I appreciate what you all are doing. Maybe I'm asking the wrong question and it should be put another way, but I hope you will rephrase my question(s) in a way that makes more sense in the context of the list discussion here. Thanks for your work. -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability
Hello all, it was something I planned to do since a long time, but with the recent related issues popping up, I finally got around to writing a BIP about how we can get rid of transaction malleability over time. The proposed document is here: https://gist.github.com/sipa/8907691 I expect most rules to not be controversial. Maybe rules 1 and 3, as they require modifications to wallet software (Bitcoin Core 0.9 and BitcoinJ already implement it, though) and potentially invalidate some script functionality. However, these new rules remain optional and controlled by an nVersion increase. Comments please! -- Pieter -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Decentralized digital asset exchange with honest pricing and market depth
On Sun, Feb 09, 2014 at 01:04:58PM -0500, Peter Todd wrote: > Alex Mizrahi recently outlined a mechanism(1) based on SIGHASH_SINGLE > that allows colored coins and similar embedded consensus system assets > to be securely transferred to another party in exchange for Bitcoins > atomically. In summary his p2p 2-step-trade mechanism operates as > follows: I'm told there's probably at least one if not more earlier attributions/reinventions for the 2-step-trade protocol using SIGHASH_SINGLE. Please reply with them if you have them so we can give credit where credit is due. -- 'peter'[:-1]@petertodd.org 0001465bc2730ffed7493d166d18d288f6cf15e8cdb5d4a3c7b1 signature.asc Description: Digital signature -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Embedded consensus system upgrade procedures
> > The only 'assertion' of central authority here is people who download and > > run the code and submit to whatever the code asserts they are supposed to > > do. > > > > At least with the 'central authority' of the big-business bitcoin developer > > cabal I can read the code before I submit to it's central authority, and > > this is a significant improvement over amgibuous legislation or proprietary > > high-frequency trading algorithms. > > Standard Disclaimer: Digital asset transfer systems are fundementally > fancy accounting systems; no amount of code can, by itself, make data > represent a physical or legal entity. Only consensus and/or authorities > in the "real world" can do that. Crypto-currencies are only a partial > exception to that rule, and only because a scarce asset that can be > transferred digitally appears to have potential to be broadly useful. How do I document in the embedded consensus system what the ruling in a small-claims court about the ownership of a contested asset was? Good accounting systems (such as mercurial, and proper double-entry financial accounting tools) allow reverting a bad commit, or bad data entry, while maintaining records of the history. Not as good accounting systems (like git) allow you to re-write history. What's the equivalent user interface, process, and wire protocol for reversing a fraudulent transaction while maintaining a full audit trail? Courts can't legislate our code, and we can't expect them to download and trust our 'distributed de-centralized' digital asset tracking system that will be downloaded from a single centralized developer website unless we meet them at least halfway, and probably need to propose model municipal and county ordinances that go along with our code releases. > Those considering investing in or otherwise devoting resources to the > creation of digital asset transfer systems should be warned that their > value in general remains unproven and losing some or all of your > investment is very possible, even probable. I myself have doubts that > these systems serve real-world business needs, but the only way to find > out is to build them and see. I would agree 100% that we need to build them, test the code, use them, and then *try them in court*, and make sure we can explain in very simple plain language what an 'embedded consensus system' is to the distributed de-centralized local court systems. -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Embedded consensus system upgrade procedures
On Sun, Feb 09, 2014 at 12:11:32PM -0600, Troy Benjegerdes wrote: > On Sun, Feb 09, 2014 at 05:25:41PM +, Luke-Jr wrote: > > On Sunday, February 09, 2014 5:12:14 PM Peter Todd wrote: > > > We have an embedded consensus system and we want to be able to upgrade > > > it with new rules. > > > > This asserts a central authority and gives developers too much power. > > I don't quite see how, There is nothing that 'forces' me to upgrade, > unless I have chosen to run an operating system (MacOS, Windows, Android) > that have automatic don't-ask-the-user update mechanisms. > > The bigger problem with 'asset transfer' of assets which do not exist > soley in the blockchain is including the consensus of relevant local and > distributed legal jurisdictions. > > For example, just because the 'colored coin' and blockchain consensus is > that I 'electronically' signed a mortgage document giving some random > internet company the rights to foreclose on my home does not mean that > my local county Judge or Sheriff are going to do anything if the internet > company cannot produce the original paper document with ink signature. > > The only 'assertion' of central authority here is people who download and > run the code and submit to whatever the code asserts they are supposed to do. > > At least with the 'central authority' of the big-business bitcoin developer > cabal I can read the code before I submit to it's central authority, and > this is a significant improvement over amgibuous legislation or proprietary > high-frequency trading algorithms. Standard Disclaimer: Digital asset transfer systems are fundementally fancy accounting systems; no amount of code can, by itself, make data represent a physical or legal entity. Only consensus and/or authorities in the "real world" can do that. Crypto-currencies are only a partial exception to that rule, and only because a scarce asset that can be transferred digitally appears to have potential to be broadly useful. Those considering investing in or otherwise devoting resources to the creation of digital asset transfer systems should be warned that their value in general remains unproven and losing some or all of your investment is very possible, even probable. I myself have doubts that these systems serve real-world business needs, but the only way to find out is to build them and see. Peter Todd Chief Scientist Mastercoin Anyway, the best we can do is build good tools. Dwelling on the underlying metaphysical nature of what those tools may or may not do from a social perspective is frankly off-topic on this email list. -- 'peter'[:-1]@petertodd.org 75829f6169c79d7d5aaa20bfa8da6e9edb2393c4f8662ba0 signature.asc Description: Digital signature -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Embedded consensus system upgrade procedures
On Sun, Feb 09, 2014 at 05:25:41PM +, Luke-Jr wrote: > On Sunday, February 09, 2014 5:12:14 PM Peter Todd wrote: > > We have an embedded consensus system and we want to be able to upgrade > > it with new rules. > > This asserts a central authority and gives developers too much power. I don't quite see how, There is nothing that 'forces' me to upgrade, unless I have chosen to run an operating system (MacOS, Windows, Android) that have automatic don't-ask-the-user update mechanisms. The bigger problem with 'asset transfer' of assets which do not exist soley in the blockchain is including the consensus of relevant local and distributed legal jurisdictions. For example, just because the 'colored coin' and blockchain consensus is that I 'electronically' signed a mortgage document giving some random internet company the rights to foreclose on my home does not mean that my local county Judge or Sheriff are going to do anything if the internet company cannot produce the original paper document with ink signature. The only 'assertion' of central authority here is people who download and run the code and submit to whatever the code asserts they are supposed to do. At least with the 'central authority' of the big-business bitcoin developer cabal I can read the code before I submit to it's central authority, and this is a significant improvement over amgibuous legislation or proprietary high-frequency trading algorithms. -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Embedded consensus system upgrade procedures
On Sun, Feb 09, 2014 at 05:25:41PM +, Luke-Jr wrote: > On Sunday, February 09, 2014 5:12:14 PM Peter Todd wrote: > > We have an embedded consensus system and we want to be able to upgrade > > it with new rules. > > This asserts a central authority and gives developers too much power. Please, the rule change only can happen if users accept it. If anything my proposed mechanism makes it even harder for developers to impose anything by fiat: the spending your digital asset under new rules decreases the amount available of it to trade with users who chose to accept only the old rules. Since there is no safety concern involved, the process is safe for both groups, developers can't plea to the community that "OMG the sky will fall and you'll be all defrauded if you don't upgrade right now!!!" Instead they'll be forced to make it clear that if the community doesn't accept the new rules, whatever assets you've moved to the new system may become forever worthless. -- 'peter'[:-1]@petertodd.org 75829f6169c79d7d5aaa20bfa8da6e9edb2393c4f8662ba0 signature.asc Description: Digital signature -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Decentralized digital asset exchange with honest pricing and market depth
Alex Mizrahi recently outlined a mechanism(1) based on SIGHASH_SINGLE that allows colored coins and similar embedded consensus system assets to be securely transferred to another party in exchange for Bitcoins atomically. In summary his p2p 2-step-trade mechanism operates as follows: Alice controls a colored txout and wishes to sell it for 1BTC. Bob wishes to buy that txout. Alice signs a scriptSig using SIGHASH_SINGLE|ANYONECANPAY for a transaction with a that time. (albeit a offer floor) single input, the colored txout, and a single output with a scriptPubKey she controls and nValue=1 This transaction is not valid as the value out is greater than the value in. She gives this partial transaction to Bob. He can now complete the transaction by providing one or more inputs with a sum value >=1BTC, one output for the colored coins to be directed to, and optionally any other outputs required. (for instance for change) Bob signs his inputs with SIGHASH_ALL and broadcasts the transaction, completing the trade. What Alice has signed, the first txin scriptSig, guarantees that if the colored txout is spent she will receive 1BTC. Meanwhile what Bob has signed, all other txin scriptSigs, sign the colored input and output, guaranteeing that he will receive his coin in exchange for his money. Thus the trade is trust free and atomic. Decentralized markets and honest pricing We can extend Mizrahi's 2-step-trade mechanism to create a decentralized marketplace. First of all, remember that traders wishing to sell their assets want to be sure that their assets offers reach the 100% of the audience who may wish to buy said assets; an attacker may try to manipulate the market to depress the price of an asset by hiding offers from potential buyers. Similarly buyers want assurance that the offers they are responding to represent all offers available. Proof-of-publication(2) offers a solution. Alice can embed her incomplete transaction as data in a second, valid, transaction. She broadcasts this secondary transaction to some agreed upon blockchain, either the one the colored coin is in, or potentially a secondary system with suitable proof-of-publication security. Bidders such as Bob can now scan the blockchain for offers with an acceptable price. (the offers can make use of techniques like prefix filters to allow Bob to only scan part of the blockchain, although Bob needs to know the status of all assets of the type he is interested in anyway) There is still some potential for manipulation with very recent offers, particularly those embedded in unconfirmed transactions. However typically markets have a large number of long-standing offers, which in this case would be committed to the blockchain with one or more confirmations. Interestingly such a system can also provide honest historical pricing information: any offer that goes unfilled for one or more blocks has (in theory) been honestly published to 100% of those watching the blockchain at that time. Thus we can assume the unfufilled offers at any given block height are honest information about the market at that time historically. The overhead involved involved in Alice publishing the offer is roughly a doubling of the overall transaction fees consumed. (remember that the offer transaction is incomplete, and about half the size of the acceptance transaction) Application to other embedded consensus systems === Any embedded consensus system can make use of the 2-step-trade mechanism so long as it is possible to create transactions where spending a single transaction output moves an asset appropriately. Unfortunately extending this to circumstances where more than one input needs to be spent, or more than out output needs to be created, is difficult. SIGHASH_SINGLE by itself results in a signature where the index of the output is signed, but the contents - scriptPubKey and nValue - of all other outputs is not signed. Meanwhile all transaction inputs are signed and changes to that set, other than modifying the nSequence value in each CTxIn, is not possible. If there was a SIGHASH mode that merely truncated vin and vout based on the index of the scriptSig we could commit to data in either, but unfortunately we can't do that. An alternative could be to create a mechanism where some embedded data signified the creation of a temporary transfer txout, where spending that txout made the underlying change desired in the consensus state atomically. 1) Alex Mizrahi, color kernel design considerations, Jan 7th 2014, Colored coins (BitcoinX) mailing list, https://groups.google.com/d/msg/bitcoinx/pON4XCIBeV4/IvzwkU8Vch0J 2) Peter Todd, [Bitcoin-development] Disentangling Crypto-Coin Mining: Timestamping, Proof-of-Publication, and Validation, Nov 19 2013, https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03307.html -- 'peter'[:-1]@petertodd.org 0
Re: [Bitcoin-development] Embedded consensus system upgrade procedures
On Sunday, February 09, 2014 5:12:14 PM Peter Todd wrote: > We have an embedded consensus system and we want to be able to upgrade > it with new rules. This asserts a central authority and gives developers too much power. -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Embedded consensus system upgrade procedures
The Problem === We have an embedded consensus system and we want to be able to upgrade it with new rules. There inevitably will be a transition period where some users use clients that interpret the new rules, while others only interpret the old rules. Since we only rely on the host consensus system for timestamped proof-of-publication the the miner-vote soft-fork upgrade mechanism;(1) there are no validating miners in the system to whome trust can be outsourced. We have a problem: messages encoding actions, such as moving as asset from one owner to another, can be published on the the blockchain according to new and old rules simultaneously, double-spending the asset. Potentially a user with the old v1 software may be tricked into accepting an asset when the consensus of the v2 software is that the asset has already been spent, and the v1-visible transaction is invalid. Solution Split actions into a separate "decrement" and "increment" operations, and ensure that v1 software can see the "decrement" of a balance, spend of a transaction output etc. even if it does not see the corresponding increment operation. This solves the double-spend problem and ensures v1 users can't be ripped off. With obvious analogy to the PoW case, we will refer to this general principle as a embedded consensus system soft-fork. Note how with the Colored Coins technology this principle happens implicitly and with miner validation: colored coins are valid transaction outputs known to the host consensus system and moving them from one owner to another is guaranteed to result in the desctruction of the colored coin from the point of view of any older software version. Older software that does not support the newer colored coin kernel specified by the new asset definition will simply see the respective coins be destroyed in invalid transactions. Note how this implies that asset definitions created by issuers should be careful to ensure that kernels chosen should be designed such that the actioned specified by one kernel can-not be interpreted differently by another; kernels should be clearly incompatible with each other. Balance-based systems = Mastercoin is a balance-based system where transactions increment and decrement balances. Being balance-based, and lacking pruning, an even simplier "scorched earth" approach will be used where each address is associated with a maximum version number seen by transactions signed by the address. Addresses with a max version number higher than what the software understands are considered to be null and have no value of any kind. (counterparty would be wise to do the same) Upgrading implementation Implementations should record in their databases the blockhash associated with transactions that were not recognized yet affected the state of the consensus. For instance a colored coin implementation should record the blockhash and transaction ID where a given coin was destroyed in an invalid transaction; after upgrading these "last transaction understood" markers can be used to replay blockchain data to arrive at the new consensus. Similarly in the case of the Mastercoin system balances associated with addresses that have been frozen should be still allowed to increment so that replaying blockchain data from the last recognized transaction arrives at a upgraded consensus. As an aside, any embedded consensus system would be wise to have a way of generating a master digest representing the state of the consensus in the database. The Bitcoin Core gettxoutsetinfo command is a good model, which provides hash_serialized, a digest representing the entire UTXO set. In all systems this is useful for ensuring that different implementations and instances have in fact arrived at a consensus. 1) BIP-16, Pay to Script Hash, https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki -- 'peter'[:-1]@petertodd.org 75829f6169c79d7d5aaa20bfa8da6e9edb2393c4f8662ba0 signature.asc Description: Digital signature -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
