Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability
Instead of trying to remove the possibility of transaction malleability, would it make sense to define a new, canonical transaction hash/ID (cTxID), which would be a hash of the part of the transaction data which we know is not malleable, and have clients use this cTxID internally, thus making the traditional transaction hash irrelevant for a client to function correctly? We already have a non-malleable transaction hash: the hash that is signed, ie. the transaction with each scriptSig replaced by the scriptPubKey it redeems. This could be the cTxID. Or is this simply a too fundamental change to the way bitcoin-qt (and all other clients) work in order to be feasible? As far as I can see, it completely solves the issue of not having a canonical ID for a transaction, but it also increases the computational requirements for a node. For one, as far as I can see, it requires the node to index all transactions, because in order to calculate a cTxID, it would be necessary to fetch all transactions referred to by the transaction in question, in order to pull in the scriptPubKeys that are redeemed. On Mon, Feb 10, 2014 at 4:00 AM, Peter Todd p...@petertodd.org wrote: 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 -- 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=121051231iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/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
I think the solution is simply to encourage Bitcoin software developers to design their software to use this static ID, instead of the full transaction hash.If MtGox had talked those IDs instead of the TX ID, their software would've correctly identified the mutated transactions and there would be no problem. Armory is slightly different, since it doesn't deal with the same stuff as exchanges do. But it didn't have any problems with malleability because it doesn't track anything by ID, it only pays attention to whether inputs and outputs are related to your wallets. It's not necessarily hard to do it this way, people just have to be aware of it. -Alan Sent from my overpriced smartphone On Feb 12, 2014 10:15 AM, Rune Kjær Svendsen runesv...@gmail.com wrote: Instead of trying to remove the possibility of transaction malleability, would it make sense to define a new, canonical transaction hash/ID (cTxID), which would be a hash of the part of the transaction data which we know is not malleable, and have clients use this cTxID internally, thus making the traditional transaction hash irrelevant for a client to function correctly? We already have a non-malleable transaction hash: the hash that is signed, ie. the transaction with each scriptSig replaced by the scriptPubKey it redeems. This could be the cTxID. Or is this simply a too fundamental change to the way bitcoin-qt (and all other clients) work in order to be feasible? As far as I can see, it completely solves the issue of not having a canonical ID for a transaction, but it also increases the computational requirements for a node. For one, as far as I can see, it requires the node to index all transactions, because in order to calculate a cTxID, it would be necessary to fetch all transactions referred to by the transaction in question, in order to pull in the scriptPubKeys that are redeemed. On Mon, Feb 10, 2014 at 4:00 AM, Peter Todd p...@petertodd.org wrote: 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 -- 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=121051231iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk
Re: [Bitcoin-development] Extension for BIP-0070 to support recurring payments
Hi Kevin, On Feb 11, 2014, at 2:00 AM, Kevin Greene kgree...@gmail.com wrote: Figured I would have a crack at reviewing this since Mike is out for a bit. It was great running into you guys at the bitcoin fair in SF! Small world :) Indeed! It was great meeting you! It's always nice to meet people in person... I like how simple this is. You just give it an url to fetch the next payment request and a date to fetch it. What should happen if the client tries to fetch the PaymentRequest early or late? If the client tries to fetch too early, then the merchant will return a PaymentRequest with no output (there is nothing to pay yet). If it fetches too late, this is merchant specific. It could be that the service got discontinued -- extreme case -- or that there are now multiple PaymentRequest pending or that the merchant decided to aggregate those into one. In that scenario, it could lead to a case where the amount to pay goes beyond the contract and the wallet would refuse to make the recurring payment. Does it become valid after some date and stay valid for some length of time? The protocol we sketched does not include (yet) an expiration date. At this point the contract is fairly minimal, and we could envision adding more parameters such as expiration date. So at this point the behavior would be dictated by the merchant. Also, what should happen if the client tries to consume the same PaymentRequest twice (or multiple times) during the same period? The merchant initiates the PaymentRequest and is in charge to make sure they match the invoices that the client should pay. On the client side, the wallet is responsible to verify that the contract is respected, so if a merchant were to issue multiple times the same PaymentRequest, the wallet would detect it goes beyond the bonds defined in the contract and would refuse to make the additional Payments. I do not think daily/weekly/monthly is flexible enough. What do you think about having a concrete start time and end time when the next PaymentRequest will be valid? I agree that daily/weekly/monthly may not be flexible enough. However specifying a fixed date may be very tricky because in some cases a monthly subscription may start on a 31st of a month, and depending on the month, the due date will vary -- could be 30th, 28th, 29th, ... Also note that the frequency (daily/weekly/monthly) is not used as a polling interval, but is only used to verify the contract is respected. There are multiple viable options to specify that contract and ideally we could/should support multiple schemes; different merchants could use different schemes, and the client would decide wether or not he is ready to accept the terms that will later be enforced by the wallet. But of course all this flexibility goes against simplicity and so this is tradeoff... This also prevents the wallet from having to remember when it last sent a payment and getting skewed over time. Today, our current prototype is polling every day -- which is the lowest granularity we introduced -- and so there is no risk of getting skewed. When a wallet hits the polling_url to download the next PaymentRequest, it seems we need a way to communicate an error code to the wallet, for example if the server canceled the contract without the wallet knowing. Perhaps a separate polling_status_url, with a corresponding ACK message to indicate if the PaymentRequest is available. What do you think of that idea? I think reporting such errors to the wallet would make complete sense. However i am not clear why we would a separate url for that? One high-level comment -- the wallet in this design doesn't have any way of knowing when the payments are supposed to end. I feel this is important to show to the user before they start their wallet polling infinitely. Subscriptions are non ending by definition, but at any time the client (through the wallet) or the merchant can decide to terminate the subscriptions -- we did not yet implement cancellation in that prototype but we are planning to add it later this week. Think of your Netflix subscriptions, this is never ending (evergreen) until you decide to terminate it or Netflix does it (abuse, bills not paid,...) Thanks for taking a look! On Sat, Feb 8, 2014 at 6:48 PM, Stephane Brossier steph...@kill-bill.org wrote: Mike, Gavin, We started to work on the merchant side to test the integration of our prototype for the recurring payments. We modified the 'Payment Request Generator' from Gavin to include a new check box 'set recurring'. We forked the code and checked in our modification here: https://github.com/killbill/paymentrequest/commit/e530f6ec528266aacfd076d7c3154ad39267c3f3 We also found a few issues with the code diff that we sent yesterday for bitcoinj and checked in the bug fixes in our fork-- so the diff sent yesterday is slightly outdated. So at this point we have a
Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability
While that solution does work for many use cases, it does make it much harder to do anything needing chained transactions. Granted, this is the short term solution for current implementations, but having a transaction identifier that does not change does open up other use cases. For example, Alice wants to send coins to a multisignature address with Bob, such that both parties are required to spend the coins. Alice also requires for Bob to send coins to this address as well before they will proceed. Alice cannot guarantee that Bob will cooperate (and vice versa), so before she broadcasts the transaction to send to A+B, she sends Bob a transaction that spends her incoming transaction back to herself, but has a time lock of far into the future. Bob signs this, returns it to Alice, and she broadcasts her funding transaction. At this point, Bob disappears, loses his key, or just decides to spite Alice and her coins are locked. Since she has a refund transaction, she can broadcast it in a month and get her coins back. Except her funding transaction has been modified such that the txhash is different, so her refund is now invalid. She would need Bob to issue a new refund as soon as her funding transaction hits the blockchain if it is modified, which defeats the point of the trustless refund transaction. Longer term it would be more ideal have a canonical identifier for the transaction before it even gets to the chain to support these use cases, even if wallets are able to properly identify the status of it's transactions. Obviously this is a difficult problem to solve and cannot be implemented without breaking changes, but it would be a nice goal to be able to completely remove malleability. There are other important use cases where having a unique identifier just for internal accounting is insufficient. -Allen On Wed, Feb 12, 2014 at 10:22 AM, Alan Reiner etothe...@gmail.com wrote: I think the solution is simply to encourage Bitcoin software developers to design their software to use this static ID, instead of the full transaction hash.If MtGox had talked those IDs instead of the TX ID, their software would've correctly identified the mutated transactions and there would be no problem. Armory is slightly different, since it doesn't deal with the same stuff as exchanges do. But it didn't have any problems with malleability because it doesn't track anything by ID, it only pays attention to whether inputs and outputs are related to your wallets. It's not necessarily hard to do it this way, people just have to be aware of it. -Alan Sent from my overpriced smartphone On Feb 12, 2014 10:15 AM, Rune Kjær Svendsen runesv...@gmail.com wrote: Instead of trying to remove the possibility of transaction malleability, would it make sense to define a new, canonical transaction hash/ID (cTxID), which would be a hash of the part of the transaction data which we know is not malleable, and have clients use this cTxID internally, thus making the traditional transaction hash irrelevant for a client to function correctly? We already have a non-malleable transaction hash: the hash that is signed, ie. the transaction with each scriptSig replaced by the scriptPubKey it redeems. This could be the cTxID. Or is this simply a too fundamental change to the way bitcoin-qt (and all other clients) work in order to be feasible? As far as I can see, it completely solves the issue of not having a canonical ID for a transaction, but it also increases the computational requirements for a node. For one, as far as I can see, it requires the node to index all transactions, because in order to calculate a cTxID, it would be necessary to fetch all transactions referred to by the transaction in question, in order to pull in the scriptPubKeys that are redeemed. On Mon, Feb 10, 2014 at 4:00 AM, Peter Todd p...@petertodd.org wrote: 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
Re: [Bitcoin-development] Extension for BIP-0070 to support recurring payments
Thanks for humoring my questions! I think reporting such errors to the wallet would make complete sense. However i am not clear why we would a separate url for that? Hmm, thinking about this more, adding a simple status_code in PaymentRequest would be a much easier way to achieve this. However, continuing to think about this even more, maybe the simple memo field along with an empty set of outputs is enough already. In bitcoinj, right now the code will throw a PaymentRequestException.InvalidOutputs exception if the set of outputs is empty with a message of No Outputs. There isn't a good way to tell the difference between a payment request that had no outputs and a payment request that had some invalid output(s). *Question to everyone:* How does bitcoin-qt handle a PaymentRequest with no outputs? On Tue, Feb 11, 2014 at 10:01 AM, Stephane Brossier steph...@kill-bill.orgwrote: Hi Kevin, On Feb 11, 2014, at 2:00 AM, Kevin Greene kgree...@gmail.com wrote: Figured I would have a crack at reviewing this since Mike is out for a bit. It was great running into you guys at the bitcoin fair in SF! Small world :) Indeed! It was great meeting you! It's always nice to meet people in person... I like how simple this is. You just give it an url to fetch the next payment request and a date to fetch it. What should happen if the client tries to fetch the PaymentRequest early or late? If the client tries to fetch too early, then the merchant will return a PaymentRequest with no output (there is nothing to pay yet). If it fetches too late, this is merchant specific. It could be that the service got discontinued -- extreme case -- or that there are now multiple PaymentRequest pending or that the merchant decided to aggregate those into one. In that scenario, it could lead to a case where the amount to pay goes beyond the contract and the wallet would refuse to make the recurring payment. Does it become valid after some date and stay valid for some length of time? The protocol we sketched does not include (yet) an expiration date. At this point the contract is fairly minimal, and we could envision adding more parameters such as expiration date. So at this point the behavior would be dictated by the merchant. Also, what should happen if the client tries to consume the same PaymentRequest twice (or multiple times) during the same period? The merchant initiates the PaymentRequest and is in charge to make sure they match the invoices that the client should pay. On the client side, the wallet is responsible to verify that the contract is respected, so if a merchant were to issue multiple times the same PaymentRequest, the wallet would detect it goes beyond the bonds defined in the contract and would refuse to make the additional Payments. I do not think daily/weekly/monthly is flexible enough. What do you think about having a concrete start time and end time when the next PaymentRequest will be valid? I agree that daily/weekly/monthly may not be flexible enough. However specifying a fixed date may be very tricky because in some cases a monthly subscription may start on a 31st of a month, and depending on the month, the due date will vary -- could be 30th, 28th, 29th, ... Also note that the frequency (daily/weekly/monthly) is not used as a polling interval, but is only used to verify the contract is respected. There are multiple viable options to specify that contract and ideally we could/should support multiple schemes; different merchants could use different schemes, and the client would decide wether or not he is ready to accept the terms that will later be enforced by the wallet. But of course all this flexibility goes against simplicity and so this is tradeoff... This also prevents the wallet from having to remember when it last sent a payment and getting skewed over time. Today, our current prototype is polling every day -- which is the lowest granularity we introduced -- and so there is no risk of getting skewed. When a wallet hits the polling_url to download the next PaymentRequest, it seems we need a way to communicate an error code to the wallet, for example if the server canceled the contract without the wallet knowing. Perhaps a separate polling_status_url, with a corresponding ACK message to indicate if the PaymentRequest is available. What do you think of that idea? I think reporting such errors to the wallet would make complete sense. However i am not clear why we would a separate url for that? One high-level comment -- the wallet in this design doesn't have any way of knowing when the payments are supposed to end. I feel this is important to show to the user before they start their wallet polling infinitely. Subscriptions are non ending by definition, but at any time the client (through the wallet) or the merchant can decide to terminate the subscriptions -- we did not yet implement cancellation in that prototype
Re: [Bitcoin-development] Decentralized digital asset exchange with honest pricing and market depth
I'm not sure how well this would work. Sure it would provide honest historical pricing, but those who wait for publication confirmation may be at a disadvantage -- to get the best deal possible Bob would connect to as many nodes as he could, examine the stream of unconfirmed asks coming in and sign the best ones before someone else does. The network would gravitate towards an O(n^2) fully connected network, because being fully connected means one is fully aware of all unconfirmed asks at any moment so one can make the best judgement and buy before someone else does. The seller needs a guarantee that all bidders can act on the ask transaction simultaneously. Maybe the partial ask transaction could be time-locked with a network propagation delay, there would be multiple bidder responses and the winner is chosen by lottery (and fee priority) by the bitcoin/alt-coin miner who confirms the atomic transaction in their block. That would eliminate the advantage to being fully connected as it would no longer matter that one can act first, so you have a more sane network. On 2014-02-09 10:04 AM, Peter Todd wrote: 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) -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/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
Agreed. I'm not suggesting that malleability shouldn't be fixed or isn't a problem. I would love to be able to leverage chained TX for Bitcoin contracts. But that in its current state it doesn't have to be complicated to deal with it. Changing the protocol to use these static IDs is a pretty fundamental change that would never happen in Bitcoin. But they can still be useful at the application level to mitigate these issues. Sent from my overpriced smartphone On Feb 12, 2014 11:38 AM, Allen Piscitello allen.piscite...@gmail.com wrote: While that solution does work for many use cases, it does make it much harder to do anything needing chained transactions. Granted, this is the short term solution for current implementations, but having a transaction identifier that does not change does open up other use cases. For example, Alice wants to send coins to a multisignature address with Bob, such that both parties are required to spend the coins. Alice also requires for Bob to send coins to this address as well before they will proceed. Alice cannot guarantee that Bob will cooperate (and vice versa), so before she broadcasts the transaction to send to A+B, she sends Bob a transaction that spends her incoming transaction back to herself, but has a time lock of far into the future. Bob signs this, returns it to Alice, and she broadcasts her funding transaction. At this point, Bob disappears, loses his key, or just decides to spite Alice and her coins are locked. Since she has a refund transaction, she can broadcast it in a month and get her coins back. Except her funding transaction has been modified such that the txhash is different, so her refund is now invalid. She would need Bob to issue a new refund as soon as her funding transaction hits the blockchain if it is modified, which defeats the point of the trustless refund transaction. Longer term it would be more ideal have a canonical identifier for the transaction before it even gets to the chain to support these use cases, even if wallets are able to properly identify the status of it's transactions. Obviously this is a difficult problem to solve and cannot be implemented without breaking changes, but it would be a nice goal to be able to completely remove malleability. There are other important use cases where having a unique identifier just for internal accounting is insufficient. -Allen On Wed, Feb 12, 2014 at 10:22 AM, Alan Reiner etothe...@gmail.com wrote: I think the solution is simply to encourage Bitcoin software developers to design their software to use this static ID, instead of the full transaction hash.If MtGox had talked those IDs instead of the TX ID, their software would've correctly identified the mutated transactions and there would be no problem. Armory is slightly different, since it doesn't deal with the same stuff as exchanges do. But it didn't have any problems with malleability because it doesn't track anything by ID, it only pays attention to whether inputs and outputs are related to your wallets. It's not necessarily hard to do it this way, people just have to be aware of it. -Alan Sent from my overpriced smartphone On Feb 12, 2014 10:15 AM, Rune Kjær Svendsen runesv...@gmail.com wrote: Instead of trying to remove the possibility of transaction malleability, would it make sense to define a new, canonical transaction hash/ID (cTxID), which would be a hash of the part of the transaction data which we know is not malleable, and have clients use this cTxID internally, thus making the traditional transaction hash irrelevant for a client to function correctly? We already have a non-malleable transaction hash: the hash that is signed, ie. the transaction with each scriptSig replaced by the scriptPubKey it redeems. This could be the cTxID. Or is this simply a too fundamental change to the way bitcoin-qt (and all other clients) work in order to be feasible? As far as I can see, it completely solves the issue of not having a canonical ID for a transaction, but it also increases the computational requirements for a node. For one, as far as I can see, it requires the node to index all transactions, because in order to calculate a cTxID, it would be necessary to fetch all transactions referred to by the transaction in question, in order to pull in the scriptPubKeys that are redeemed. On Mon, Feb 10, 2014 at 4:00 AM, Peter Todd p...@petertodd.org wrote: 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
Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability
On Wed, Feb 12, 2014 at 10:12 AM, Rune Kjær Svendsen runesv...@gmail.com wrote: Instead of trying to remove the possibility of transaction malleability, would it make sense to define a new, canonical transaction hash/ID (cTxID), Yes, that is one proposal: https://github.com/sipa/bitcoin/commits/normtxid But it is not a complete solution for all transaction types. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/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 02/10/2014 12:33 AM, Pieter Wuille wrote: The proposed document is here: https://gist.github.com/sipa/8907691 If we are bumping nVersion, how about dropping DER encoding completely and using just 64 bytes directly for signature? Also using 2 different variable integer encodings (in addition to what DER already does) is very confusing. -- Best Regards / S pozdravom, Pavol Rusnak st...@gk2.sk -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/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
It's also not necessary for wallet software - it's really just for human consumption. A wallet can easily detect inputs being respent in another transaction. You don't need a static hash for that (which wouldn't need with all hash types, non-malleability double spends, ...). On Wed, Feb 12, 2014 at 6:13 PM, Jeff Garzik jgar...@bitpay.com wrote: On Wed, Feb 12, 2014 at 10:12 AM, Rune Kjær Svendsen runesv...@gmail.com wrote: Instead of trying to remove the possibility of transaction malleability, would it make sense to define a new, canonical transaction hash/ID (cTxID), Yes, that is one proposal: https://github.com/sipa/bitcoin/commits/normtxid But it is not a complete solution for all transaction types. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/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 Wed, Feb 12, 2014 at 5:56 PM, Pavol Rusnak st...@gk2.sk wrote: On 02/10/2014 12:33 AM, Pieter Wuille wrote: The proposed document is here: https://gist.github.com/sipa/8907691 If we are bumping nVersion, how about dropping DER encoding completely and using just 64 bytes directly for signature? That would be a hard fork. Certainly something to be discussed if we ever introduce a version-2 scripting language, but that's a long-term thing. -- Pieter -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/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 Wed, Feb 12, 2014 at 7:12 AM, Rune Kjær Svendsen runesv...@gmail.com wrote: Instead of trying to remove the possibility of transaction malleability, would it make sense to define a new, canonical transaction hash/ID (cTxID), which would be a hash of the part of the transaction data which we know is not malleable, and have clients use this cTxID internally, thus making the traditional transaction hash irrelevant for a client to function correctly? This is fine and good. But it only scratches the surface of the problems created by malleability, especially for fancier transaction protocols. Mutation allows you to invalidate a chain of unconfirmed transaction by mutating the parent. This breaks any protocol which depends on creating a precomputed nlocked time refund transaction. So a canonical ID can be used to prevent some buggy behavior it doesn't actually fix the problem. Fortunately the non-fixed parts aren't too critical today. On Wed, Feb 12, 2014 at 8:22 AM, Alan Reiner etothe...@gmail.com wrote: I think the solution is simply to encourage Bitcoin software developers to design their software to use this static ID, instead of the full transaction hash.If MtGox had talked those IDs instead of the TX ID, their software would've correctly identified the mutated transactions and there would be no problem. This is incorrect. MtGox was automatically issuing replacement transactions resulting in double payments. When you attempt to replace/reissue/cancel a transaction you __MUST__ double-spend the original transaction. If the original transaction has not been conflicted then it is possible someone will pull the original transaction out of a hat and both your replacement and the original will be confirmed. It is not safe at any time to look to see if the original has been confirmed yet, and if not reissue— not because mutation may mean you're looking in the wrong place— but because the state of the world could change nano-seconds after you looked. If you do double-spend the original then there is no chance that both will go through, you'll have atomic exclusion and only one transaction or the other will be confirmed. -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/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
We're talking about two slightly different things. If their system had tracked by inputs and outputs (or some kind of static ID) , their system wouldn't have been issuing refunds/replacements/cancellations in the first place. I agree with you that the reissuing code should also guarantee that both TX can't be valid... But really their system should do both. Without the I/O based tracking their bookkeeping will be off, regardless of the reissuing code, because they can't properly associate outgoing transactions with customer accounts/actions. Sent from my overpriced smartphone On Feb 12, 2014 1:06 PM, Gregory Maxwell gmaxw...@gmail.com wrote: On Wed, Feb 12, 2014 at 7:12 AM, Rune Kjær Svendsen runesv...@gmail.com wrote: Instead of trying to remove the possibility of transaction malleability, would it make sense to define a new, canonical transaction hash/ID (cTxID), which would be a hash of the part of the transaction data which we know is not malleable, and have clients use this cTxID internally, thus making the traditional transaction hash irrelevant for a client to function correctly? This is fine and good. But it only scratches the surface of the problems created by malleability, especially for fancier transaction protocols. Mutation allows you to invalidate a chain of unconfirmed transaction by mutating the parent. This breaks any protocol which depends on creating a precomputed nlocked time refund transaction. So a canonical ID can be used to prevent some buggy behavior it doesn't actually fix the problem. Fortunately the non-fixed parts aren't too critical today. On Wed, Feb 12, 2014 at 8:22 AM, Alan Reiner etothe...@gmail.com wrote: I think the solution is simply to encourage Bitcoin software developers to design their software to use this static ID, instead of the full transaction hash.If MtGox had talked those IDs instead of the TX ID, their software would've correctly identified the mutated transactions and there would be no problem. This is incorrect. MtGox was automatically issuing replacement transactions resulting in double payments. When you attempt to replace/reissue/cancel a transaction you __MUST__ double-spend the original transaction. If the original transaction has not been conflicted then it is possible someone will pull the original transaction out of a hat and both your replacement and the original will be confirmed. It is not safe at any time to look to see if the original has been confirmed yet, and if not reissue-- not because mutation may mean you're looking in the wrong place-- but because the state of the world could change nano-seconds after you looked. If you do double-spend the original then there is no chance that both will go through, you'll have atomic exclusion and only one transaction or the other will be confirmed. -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/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 02/12/2014 08:44 AM, Alan Reiner wrote: Changing the protocol to use these static IDs is a pretty fundamental change that would never happen in Bitcoin. But they can still be useful at the application level to mitigate these issues. Not to mention that it would be potentially very insecure to have consensus depend on data (scriptSigs) which are not hashed in the Merkle structure of a block. Not that anyone on this list has suggested such a change, but I've seen it raised multiple times on the forum Mark -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/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 Wednesday, February 12, 2014 8:27:52 PM Mark Friedenbach wrote: On 02/12/2014 08:44 AM, Alan Reiner wrote: Changing the protocol to use these static IDs is a pretty fundamental change that would never happen in Bitcoin. But they can still be useful at the application level to mitigate these issues. Not to mention that it would be potentially very insecure to have consensus depend on data (scriptSigs) which are not hashed in the Merkle structure of a block. Not that anyone on this list has suggested such a change, but I've seen it raised multiple times on the forum This would be a problem if it was used in the merkle tree, but I'm pretty sure using it for input selection would be pretty safe. One could even avoid the index by simply using the hashScript as the sole input value; then even CoinJoins would be safe without breaking chains of transactions (although this would break address reuse entirely - but I don't see that as a problem in a theoretical world). One of those things that an altcoin could improve upon Bitcoin with... ;) -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/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
I apologize if this has been discussed many times before. As a long term solution to malleable transactions, wouldn't it be possible to modify the signatures to be of the entire transaction. Why do you have to zero out the inputs? I can see that this would be a hard fork, and maybe it would be somewhat tricky to extract signatures first (since you can sign everything except the signatures), but it would seem to me that this is an important enough change to consider making. On Wed, Feb 12, 2014 at 5:52 PM, Luke-Jr l...@dashjr.org wrote: On Wednesday, February 12, 2014 8:27:52 PM Mark Friedenbach wrote: On 02/12/2014 08:44 AM, Alan Reiner wrote: Changing the protocol to use these static IDs is a pretty fundamental change that would never happen in Bitcoin. But they can still be useful at the application level to mitigate these issues. Not to mention that it would be potentially very insecure to have consensus depend on data (scriptSigs) which are not hashed in the Merkle structure of a block. Not that anyone on this list has suggested such a change, but I've seen it raised multiple times on the forum This would be a problem if it was used in the merkle tree, but I'm pretty sure using it for input selection would be pretty safe. One could even avoid the index by simply using the hashScript as the sole input value; then even CoinJoins would be safe without breaking chains of transactions (although this would break address reuse entirely - but I don't see that as a problem in a theoretical world). One of those things that an altcoin could improve upon Bitcoin with... ;) -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/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 Wed, Feb 12, 2014 at 4:39 PM, Alex Morcos mor...@gmail.com wrote: I apologize if this has been discussed many times before. It has been, but there are probably many people like you who have not bothered researching who may also be curious. As a long term solution to malleable transactions, wouldn't it be possible to modify the signatures to be of the entire transaction. Why do you have to zero out the inputs? I can see that this would be a hard fork, and maybe it would be somewhat tricky to extract signatures first (since you can sign everything except the signatures), but it would seem to me that this is an important enough change to consider making. Because doing so would be both unnecessary and ineffective. Unnecessary because we can very likely eliminate malleability without changing what is signed. It will take time, but we have been incrementally moving towards that, e.g. v0.8 made many kinds of non-canonical encoding non-standard. Ineffective— at least as you describe it— because the signatures _themselves_ are malleable. -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
