* [Bitcoin-development] SIGHASH_WITHINPUTVALUE @ 2015-01-23 14:51 slush 2015-01-23 15:24 ` Alan Reiner 2015-01-23 15:31 ` Tamas Blummer 0 siblings, 2 replies; 20+ messages in thread From: slush @ 2015-01-23 14:51 UTC (permalink / raw) To: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 754 bytes --] Hi, is any progress or even discussion in this area? https://bitcointalk.org/index.php?topic=181734.0 I don't insist on any specific solution, but this is becoming a real issue as hardware wallets are more widespread. I'm sitting next to TREZOR for 40 minutes already, because it streams and validate some complex transaction. By using proposed solution, such signature would be a matter of few seconds. That's also not just about time/resource/hw cost optimization. I'm talking about possibility of huge simplification of the firmware (=security FTW), because 50% of actual codebase is solving this particular downside of Bitcoin protocol. So, there's real world problem. On which solution can we as a community find a wide agreement? Best, Marek [-- Attachment #2: Type: text/html, Size: 1369 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Bitcoin-development] SIGHASH_WITHINPUTVALUE 2015-01-23 14:51 [Bitcoin-development] SIGHASH_WITHINPUTVALUE slush @ 2015-01-23 15:24 ` Alan Reiner 2015-01-23 15:40 ` slush 2015-01-23 16:05 ` Gregory Maxwell 2015-01-23 15:31 ` Tamas Blummer 1 sibling, 2 replies; 20+ messages in thread From: Alan Reiner @ 2015-01-23 15:24 UTC (permalink / raw) To: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 3417 bytes --] The SIGHASH_WITHINPUTVALUE proposal is a hardfork, but otherwise non-intrusive, doesn't change any TxOut scripts, doesn't change any tx/block parsing (besides verification), it works with all existing coins in the network, and existing software doesn't have to use it if they don't want to upgrade their signers. The proposal simply provides a way to optionally sign the input values with the TxOut scripts. In other words a signature right now says "I sign this transaction using these inputs, whatever value they are." With this SIGHASH type, the signature says "I sign this transaction assuming that input 0 is X BTC, input 1 is Y BTC,....". If the online computer providing the data to be signed lies about the value of any input, the resulting signature will be invalid. Unfortunately, it seems that there was no soft-fork way to achieve this benefit, at least not one that had favorable properties. Most of the soft-fork variations of it required the coins being spent to have been originated in a special way. In other words, it would only work if the coins had entered the wallet with some special, modified TxOut script. So it wouldn't work with existing coins, and would require senders to update their software to reshape the way they send transactions to be compatible with our goals. I *strongly* encourage this to be considered for inclusion at some point. Not only does it simplify HW as Marek suggested, it increases the options for online-offline communication channels, which is also a win for security. Right now, QR codes don't work because of the possibility of having to transfer megabytes over the channel, and no way to for the signer to control that size. With this change, it's possible for the signer to control the size of each chunk of data to guarantee it fits in, say, a QR code (even if it means breaking it up into a couple smaller transactions). -Alan On 01/23/2015 09:51 AM, slush wrote: > Hi, > > is any progress or even discussion in this area? > > https://bitcointalk.org/index.php?topic=181734.0 > > I don't insist on any specific solution, but this is becoming a real > issue as hardware wallets are more widespread. I'm sitting next to > TREZOR for 40 minutes already, because it streams and validate some > complex transaction. By using proposed solution, such signature would > be a matter of few seconds. > > That's also not just about time/resource/hw cost optimization. I'm > talking about possibility of huge simplification of the firmware > (=security FTW), because 50% of actual codebase is solving this > particular downside of Bitcoin protocol. > > So, there's real world problem. On which solution can we as a > community find a wide agreement? > > Best, > Marek > > > ------------------------------------------------------------------------------ > New Year. New Location. New Benefits. New Data Center in Ashburn, VA. > GigeNET is offering a free month of service with a new server in Ashburn. > Choose from 2 high performing configs, both with 100TB of bandwidth. > Higher redundancy.Lower latency.Increased capacity.Completely compliant. > http://p.sf.net/sfu/gigenet > > > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development [-- Attachment #2: Type: text/html, Size: 5254 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Bitcoin-development] SIGHASH_WITHINPUTVALUE 2015-01-23 15:24 ` Alan Reiner @ 2015-01-23 15:40 ` slush 2015-01-23 16:05 ` Gregory Maxwell 1 sibling, 0 replies; 20+ messages in thread From: slush @ 2015-01-23 15:40 UTC (permalink / raw) Cc: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 4456 bytes --] > I *strongly* encourage this to be considered for inclusion at some point. Thanks Alan for a nice summary. I also agree that such stuff should be implemented at some point. Anyway, I would probably not vote for doing hard fork *just* for this change, but if I remember well, there're other ideas flying around in the air and waiting for hardfork... Marek On Fri, Jan 23, 2015 at 4:24 PM, Alan Reiner <etotheipi@gmail•com> wrote: > The SIGHASH_WITHINPUTVALUE proposal is a hardfork, but otherwise > non-intrusive, doesn't change any TxOut scripts, doesn't change any > tx/block parsing (besides verification), it works with all existing coins > in the network, and existing software doesn't have to use it if they don't > want to upgrade their signers. The proposal simply provides a way to > optionally sign the input values with the TxOut scripts. In other words a > signature right now says "I sign this transaction using these inputs, > whatever value they are." With this SIGHASH type, the signature says "I > sign this transaction assuming that input 0 is X BTC, input 1 is Y > BTC,....". If the online computer providing the data to be signed lies > about the value of any input, the resulting signature will be invalid. > > Unfortunately, it seems that there was no soft-fork way to achieve this > benefit, at least not one that had favorable properties. Most of the > soft-fork variations of it required the coins being spent to have been > originated in a special way. In other words, it would only work if the > coins had entered the wallet with some special, modified TxOut script. So > it wouldn't work with existing coins, and would require senders to update > their software to reshape the way they send transactions to be compatible > with our goals. > > I *strongly* encourage this to be considered for inclusion at some > point. Not only does it simplify HW as Marek suggested, it increases the > options for online-offline communication channels, which is also a win for > security. Right now, QR codes don't work because of the possibility of > having to transfer megabytes over the channel, and no way to for the signer > to control that size. With this change, it's possible for the signer to > control the size of each chunk of data to guarantee it fits in, say, a QR > code (even if it means breaking it up into a couple smaller transactions). > > -Alan > > > > > On 01/23/2015 09:51 AM, slush wrote: > > Hi, > > is any progress or even discussion in this area? > > https://bitcointalk.org/index.php?topic=181734.0 > > I don't insist on any specific solution, but this is becoming a real > issue as hardware wallets are more widespread. I'm sitting next to TREZOR > for 40 minutes already, because it streams and validate some complex > transaction. By using proposed solution, such signature would be a matter > of few seconds. > > That's also not just about time/resource/hw cost optimization. I'm > talking about possibility of huge simplification of the firmware (=security > FTW), because 50% of actual codebase is solving this particular downside of > Bitcoin protocol. > > So, there's real world problem. On which solution can we as a community > find a wide agreement? > > Best, > Marek > > > ------------------------------------------------------------------------------ > New Year. New Location. New Benefits. New Data Center in Ashburn, VA. > GigeNET is offering a free month of service with a new server in Ashburn. > Choose from 2 high performing configs, both with 100TB of bandwidth. > Higher redundancy.Lower latency.Increased capacity.Completely compliant.http://p.sf.net/sfu/gigenet > > > > _______________________________________________ > Bitcoin-development mailing listBitcoin-development@lists•sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > > > ------------------------------------------------------------------------------ > New Year. New Location. New Benefits. New Data Center in Ashburn, VA. > GigeNET is offering a free month of service with a new server in Ashburn. > Choose from 2 high performing configs, both with 100TB of bandwidth. > Higher redundancy.Lower latency.Increased capacity.Completely compliant. > http://p.sf.net/sfu/gigenet > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > T [-- Attachment #2: Type: text/html, Size: 6819 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Bitcoin-development] SIGHASH_WITHINPUTVALUE 2015-01-23 15:24 ` Alan Reiner 2015-01-23 15:40 ` slush @ 2015-01-23 16:05 ` Gregory Maxwell 2015-01-23 16:18 ` slush ` (2 more replies) 1 sibling, 3 replies; 20+ messages in thread From: Gregory Maxwell @ 2015-01-23 16:05 UTC (permalink / raw) To: Alan Reiner; +Cc: Bitcoin Development On Fri, Jan 23, 2015 at 3:24 PM, Alan Reiner <etotheipi@gmail•com> wrote: > Unfortunately, it seems that there was no soft-fork way to achieve this > benefit, at least not one that had favorable properties. Most of the > soft-fork variations of it required the coins being spent to have been > originated in a special way. In other words, it would only work if the > coins had entered the wallet with some special, modified TxOut script. So > it wouldn't work with existing coins, and would require senders to update > their software to reshape the way they send transactions to be compatible > with our goals. I think this is unreasonable. There is a straight-forward soft-fork approach which is safe (e.g. no risk of invalidating existing transactions). Yes, it means that you need to use newly created addresses to get coins that use the new signature type... but thats only the case for people who want the new capability. This is massively preferable to expecting _every_ _other_ user of the system (including miners, full nodes, etc.) to replace their software with an incompatible new version just to accommodate your transactions, for which they may care nothing about and which would otherwise not have any urgent need to change. I've expected this need to be addressed simply as a side effect of a new, more efficient, checksig operator which some people have been working on and off on but which has taken a backseat to other more urgent issues. On Fri, Jan 23, 2015 at 2:51 PM, slush <slush@centrum•cz> wrote: > as hardware wallets are more widespread. I'm sitting next to TREZOR for 40 > minutes already, because it streams and validate some complex transaction. Can you help me understand whats taking 40 minutes here? Thats a surprisingly high number, and so I'm wondering if I'm not missing something there. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Bitcoin-development] SIGHASH_WITHINPUTVALUE 2015-01-23 16:05 ` Gregory Maxwell @ 2015-01-23 16:18 ` slush 2015-01-23 16:52 ` Gregory Maxwell 2015-01-23 16:23 ` Alan Reiner 2015-01-23 16:27 ` Alan Reiner 2 siblings, 1 reply; 20+ messages in thread From: slush @ 2015-01-23 16:18 UTC (permalink / raw) To: Gregory Maxwell; +Cc: Bitcoin Development [-- Attachment #1: Type: text/plain, Size: 985 bytes --] On Fri, Jan 23, 2015 at 5:05 PM, Gregory Maxwell <gmaxwell@gmail•com> wrote: > I think this is unreasonable. There is a straight-forward soft-fork > approach which is safe (e.g. no risk of invalidating existing > transactions). Yes, it means that you need to use newly created > addresses to get coins that use the new signature type... Can you send me any reference about this? Of course if that solves the problem, hard fork would not be necessary anymore. I'm just not aware of any. Can you help me understand whats taking 40 minutes here? Thats a > surprisingly high number, and so I'm wondering if I'm not missing > something there. > > To sign transaction with hundreds of inputs on device with limited memory capabilities, I need to stream all previous transactions into device, for every signed input. That means roughly 200^2 transaction verifications for 200 inputs to sign. Very slow, but does not limit the device for any particular size of signed transaction. Marek [-- Attachment #2: Type: text/html, Size: 1582 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Bitcoin-development] SIGHASH_WITHINPUTVALUE 2015-01-23 16:18 ` slush @ 2015-01-23 16:52 ` Gregory Maxwell 2015-01-23 17:40 ` slush 0 siblings, 1 reply; 20+ messages in thread From: Gregory Maxwell @ 2015-01-23 16:52 UTC (permalink / raw) To: slush; +Cc: Bitcoin Development On Fri, Jan 23, 2015 at 4:18 PM, slush <slush@centrum•cz> wrote: > Can you send me any reference about this? Of course if that solves the > problem, hard fork would not be necessary anymore. I'm just not aware of > any. Sure; will aggregate up the citations when I'm not travling later today. > To sign transaction with hundreds of inputs on device with limited memory > capabilities, I need to stream all previous transactions into device, for > every signed input. > > That means roughly 200^2 transaction verifications for 200 inputs to sign. > Very slow, but does not limit the device for any particular size of signed > transaction. I'm not sure where the ^2 is coming from. So what I'd understand that you'd do is stream in the input txid:vouts which you spend, then you'd stream the actual inputs which would just be hashed and value extracted (but no other verification), and you'd build a table of txid:vout->value, then the actual transaction to be signed. This should have O(inputs) hashing and communications overhead. Is there a step I'm missing? ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Bitcoin-development] SIGHASH_WITHINPUTVALUE 2015-01-23 16:52 ` Gregory Maxwell @ 2015-01-23 17:40 ` slush 2015-01-23 18:51 ` Gregory Maxwell 0 siblings, 1 reply; 20+ messages in thread From: slush @ 2015-01-23 17:40 UTC (permalink / raw) To: Gregory Maxwell; +Cc: Bitcoin Development [-- Attachment #1: Type: text/plain, Size: 1058 bytes --] Yes, the step you're missing is "and build the table". Dynamic memory allocation is something you want to avoid, as well as any artifical restrictions to number of inputs or outputs. Current solution is slow, but there's really no limitation on tx size. Plus there're significant restrictions to memory in embedded world. Actually TREZOR uses pretty powerful (and expensive) MCU just because it needs to do such validations and calculate such hashes. With SIGHASH_WITHINPUTVALUE or similar we may cut hardware cost significantly. Marek On Fri, Jan 23, 2015 at 5:52 PM, Gregory Maxwell <gmaxwell@gmail•com> wrote: > I'm not sure where the ^2 is coming from. So what I'd understand that > you'd do is stream in the input txid:vouts which you spend, then you'd > stream the actual inputs which would just be hashed and value > extracted (but no other verification), and you'd build a table of > txid:vout->value, then the actual transaction to be signed. > > This should have O(inputs) hashing and communications overhead. Is > there a step I'm missing? > [-- Attachment #2: Type: text/html, Size: 1486 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Bitcoin-development] SIGHASH_WITHINPUTVALUE 2015-01-23 17:40 ` slush @ 2015-01-23 18:51 ` Gregory Maxwell 2015-01-23 19:19 ` slush 0 siblings, 1 reply; 20+ messages in thread From: Gregory Maxwell @ 2015-01-23 18:51 UTC (permalink / raw) To: slush, Bitcoin Development On Fri, Jan 23, 2015 at 5:40 PM, slush <slush@centrum•cz> wrote: > Yes, the step you're missing is "and build the table". Dynamic memory > allocation is something you want to avoid, as well as any artifical > restrictions to number of inputs or outputs. Current solution is slow, but > there's really no limitation on tx size. > > Plus there're significant restrictions to memory in embedded world. Actually > TREZOR uses pretty powerful (and expensive) MCU just because it needs to do > such validations and calculate such hashes. With SIGHASH_WITHINPUTVALUE or > similar we may cut hardware cost significantly. I'm quite familiar with embedded development :), and indeed trezor MCU is what I would generally consider (over-)powered which is why I was somewhat surprised by the numbers; I'm certainly not expecting you to perform dynamic allocation... but wasn't clear on how 40 minutes and was I just trying to understand. Using a table to avoid retransmitting reused transactions is just an optimization and can be done in constant memory (e.g. falling back to retransmission if filled). So what I'm understanding now is that you stream the transaction along with its inputs interleaved in order to reduce the memory requirement to two midstates and a value accumulator; requiring resending the transaction... so in the worst case transaction (since you can't get in more than about 800 inputs at the maximum transaction size) each input spending from (one or more, since even one would be repeated) 100kb input transactions you might send about 800MBytes of data, which could take a half an hour if hashing runs at 45KB/s or slower? (If so, okay then there isn't another thing that I was missing). ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Bitcoin-development] SIGHASH_WITHINPUTVALUE 2015-01-23 18:51 ` Gregory Maxwell @ 2015-01-23 19:19 ` slush 0 siblings, 0 replies; 20+ messages in thread From: slush @ 2015-01-23 19:19 UTC (permalink / raw) To: Gregory Maxwell; +Cc: Bitcoin Development [-- Attachment #1: Type: text/plain, Size: 1989 bytes --] You're right, there can be done some optimizations. Workarounds of workaround. All this adds complexity, which reduces the security. Marek On Fri, Jan 23, 2015 at 7:51 PM, Gregory Maxwell <gmaxwell@gmail•com> wrote: > On Fri, Jan 23, 2015 at 5:40 PM, slush <slush@centrum•cz> wrote: > > Yes, the step you're missing is "and build the table". Dynamic memory > > allocation is something you want to avoid, as well as any artifical > > restrictions to number of inputs or outputs. Current solution is slow, > but > > there's really no limitation on tx size. > > > > Plus there're significant restrictions to memory in embedded world. > Actually > > TREZOR uses pretty powerful (and expensive) MCU just because it needs to > do > > such validations and calculate such hashes. With SIGHASH_WITHINPUTVALUE > or > > similar we may cut hardware cost significantly. > > I'm quite familiar with embedded development :), and indeed trezor MCU > is what I would generally consider (over-)powered which is why I was > somewhat surprised by the numbers; I'm certainly not expecting you to > perform dynamic allocation... but wasn't clear on how 40 minutes and > was I just trying to understand. Using a table to avoid retransmitting > reused transactions is just an optimization and can be done in > constant memory (e.g. falling back to retransmission if filled). > > So what I'm understanding now is that you stream the transaction along > with its inputs interleaved in order to reduce the memory requirement > to two midstates and a value accumulator; requiring resending the > transaction... so in the worst case transaction (since you can't get > in more than about 800 inputs at the maximum transaction size) each > input spending from (one or more, since even one would be repeated) > 100kb input transactions you might send about 800MBytes of data, which > could take a half an hour if hashing runs at 45KB/s or slower? > > (If so, okay then there isn't another thing that I was missing). > [-- Attachment #2: Type: text/html, Size: 2529 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Bitcoin-development] SIGHASH_WITHINPUTVALUE 2015-01-23 16:05 ` Gregory Maxwell 2015-01-23 16:18 ` slush @ 2015-01-23 16:23 ` Alan Reiner 2015-01-23 16:27 ` Alan Reiner 2 siblings, 0 replies; 20+ messages in thread From: Alan Reiner @ 2015-01-23 16:23 UTC (permalink / raw) To: Gregory Maxwell; +Cc: Bitcoin Development On 01/23/2015 11:05 AM, Gregory Maxwell wrote: > On Fri, Jan 23, 2015 at 3:24 PM, Alan Reiner <etotheipi@gmail•com> wrote: >> Unfortunately, it seems that there was no soft-fork way to achieve this >> benefit, at least not one that had favorable properties. Most of the >> soft-fork variations of it required the coins being spent to have been >> originated in a special way. In other words, it would only work if the >> coins had entered the wallet with some special, modified TxOut script. So >> it wouldn't work with existing coins, and would require senders to update >> their software to reshape the way they send transactions to be compatible >> with our goals. > I think this is unreasonable. There is a straight-forward soft-fork > approach which is safe (e.g. no risk of invalidating existing > transactions). Yes, it means that you need to use newly created > addresses to get coins that use the new signature type... but thats > only the case for people who want the new capability. This is > massively preferable to expecting _every_ _other_ user of the system > (including miners, full nodes, etc.) to replace their software with an > incompatible new version just to accommodate your transactions, for > which they may care nothing about and which would otherwise not have > any urgent need to change. > > As far as I'm concerned, anything that requires the coins to originate in the wallet with some special form is a non-starter. The new SIGHASH type allows you to sign transactions with any coins already in your wallet, and imposes no requirements on anyone paying your cold wallet. Any such proposals that require origination structure means that 100% of people paying you need to "be nice" and use this new script type, or else you *have* to ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Bitcoin-development] SIGHASH_WITHINPUTVALUE 2015-01-23 16:05 ` Gregory Maxwell 2015-01-23 16:18 ` slush 2015-01-23 16:23 ` Alan Reiner @ 2015-01-23 16:27 ` Alan Reiner 2015-01-23 16:33 ` Alan Reiner 2015-01-23 16:35 ` slush 2 siblings, 2 replies; 20+ messages in thread From: Alan Reiner @ 2015-01-23 16:27 UTC (permalink / raw) To: Gregory Maxwell; +Cc: Bitcoin Development On 01/23/2015 11:05 AM, Gregory Maxwell wrote: > On Fri, Jan 23, 2015 at 3:24 PM, Alan Reiner <etotheipi@gmail•com> wrote: >> Unfortunately, it seems that there was no soft-fork way to achieve this >> benefit, at least not one that had favorable properties. Most of the >> soft-fork variations of it required the coins being spent to have been >> originated in a special way. In other words, it would only work if the >> coins had entered the wallet with some special, modified TxOut script. So >> it wouldn't work with existing coins, and would require senders to update >> their software to reshape the way they send transactions to be compatible >> with our goals. > I think this is unreasonable. There is a straight-forward soft-fork > approach which is safe (e.g. no risk of invalidating existing > transactions). Yes, it means that you need to use newly created > addresses to get coins that use the new signature type... but thats > only the case for people who want the new capability. This is > massively preferable to expecting _every_ _other_ user of the system > (including miners, full nodes, etc.) to replace their software with an > incompatible new version just to accommodate your transactions, for > which they may care nothing about and which would otherwise not have > any urgent need to change. > > As far as I'm concerned, anything that requires the coins to originate in the wallet with some special form is a non-starter. The new SIGHASH type allows you to sign transactions with *any* coins already in your wallet, and imposes no requirements on anyone paying your cold wallet to be compatible with your signer. Any proposals that require coin origination features means that 100% of people paying you need to "be nice" and send you coins with this special structure. You can't spend old coins that were sent before this proposal was implemented, and if anyone sends you coins without respecting the new structure, then your signing devices need the full-complexity routines to accommodate, which defeats the entire purpose. I am happy to entertain other ideas that achieve our goals here, but I'm fairly confident that the new SIGHASH type is the only way that would allow devices like Trezor to truly simplify their design (and still work securely on 100% of funds contained by the wallet). ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Bitcoin-development] SIGHASH_WITHINPUTVALUE 2015-01-23 16:27 ` Alan Reiner @ 2015-01-23 16:33 ` Alan Reiner 2015-01-23 16:35 ` slush 1 sibling, 0 replies; 20+ messages in thread From: Alan Reiner @ 2015-01-23 16:33 UTC (permalink / raw) To: Gregory Maxwell; +Cc: Bitcoin Development On 01/23/2015 11:27 AM, Alan Reiner wrote: > > I am happy to entertain other ideas that achieve our goals here, but I'm > fairly confident that the new SIGHASH type is the only way that would > allow devices like Trezor to truly simplify their design (and still work > securely on 100% of funds contained by the wallet). > Self-correction ... I didn't mean it's the "only way", I mean it's by far the easiest, simplest, least-intrusive way that achieves the properties we need for this to be useful. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Bitcoin-development] SIGHASH_WITHINPUTVALUE 2015-01-23 16:27 ` Alan Reiner 2015-01-23 16:33 ` Alan Reiner @ 2015-01-23 16:35 ` slush 2015-01-23 17:49 ` Peter Todd 1 sibling, 1 reply; 20+ messages in thread From: slush @ 2015-01-23 16:35 UTC (permalink / raw) To: Alan Reiner; +Cc: Bitcoin Development [-- Attachment #1: Type: text/plain, Size: 1300 bytes --] Oh, now I got the 'soft-fork' alternative. If that means that *senders* to Trezor need to be nice guys and use some special outputs, then it's, obviously, no-go solution. I understand political aspect around hard-fork. Anyway, are there any other pending projects waiting for hard-fork? Maybe we should join our effort in some way. M. On Fri, Jan 23, 2015 at 5:27 PM, Alan Reiner <etotheipi@gmail•com> wrote: > > I am happy to entertain other ideas that achieve our goals here, but I'm > fairly confident that the new SIGHASH type is the only way that would > allow devices like Trezor to truly simplify their design (and still work > securely on 100% of funds contained by the wallet). > > > > ------------------------------------------------------------------------------ > New Year. New Location. New Benefits. New Data Center in Ashburn, VA. > GigeNET is offering a free month of service with a new server in Ashburn. > Choose from 2 high performing configs, both with 100TB of bandwidth. > Higher redundancy.Lower latency.Increased capacity.Completely compliant. > http://p.sf.net/sfu/gigenet > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > [-- Attachment #2: Type: text/html, Size: 1980 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Bitcoin-development] SIGHASH_WITHINPUTVALUE 2015-01-23 16:35 ` slush @ 2015-01-23 17:49 ` Peter Todd 0 siblings, 0 replies; 20+ messages in thread From: Peter Todd @ 2015-01-23 17:49 UTC (permalink / raw) To: slush, Alan Reiner; +Cc: Bitcoin Development -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 23 January 2015 08:35:23 GMT-08:00, slush <slush@centrum•cz> wrote: >Oh, now I got the 'soft-fork' alternative. If that means that *senders* >to >Trezor need to be nice guys and use some special outputs, then it's, >obviously, no-go solution. That's what P2SH is for; the senders will just be sending to a P2SH address. >I understand political aspect around hard-fork. Anyway, are there any >other >pending projects waiting for hard-fork? Hard-forks aren't hard for directly political issues, they're politically hard because they're risky by requiring everyone yo upgrade at once. In the case of signature validation, that touches a *lot* of third party code that people rely on to avoid being defrauded. FWIW I've actually got a half-finished writeup for how to use OP_CODESEPARATOR and a CHECKSIG2 soft-fork to have signatures sign fees and so forth. -----BEGIN PGP SIGNATURE----- Version: APG v1.1.1 iQFQBAEBCAA6BQJUwonGMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8 cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhbwkCADP7AcJ6a6V/y7MHt2x ZiCXYsfHq5j03kbSWXGi1Q/9RqWGVha1fhWPp62yhDxbWOfh5QKauCbrt2g1AqT3 xbnh+2XE1rApBQIiJ6u0wZmpCi+4EhH2M9R8UYu9oIMzBe4K2jhzUbzcOR9Qplyq 9j6yevNrvtNHZb2OTiaKelxnuZUEiAsONHPOvR8Fkflwbd/w279OeilRjHYt3A/J U22KOwjNrpa7/QE/HeC0QINqr3S132Yg4iYFwPviBwGq/WXQuLHIzGtgKOzrIC1T h6kpWO9CjSxVbjMrf68IrSHRv92K8y1LiHFRZvzp3ulzcGBo2btazmrp/fUDLCr0 6uFg =uDeM -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Bitcoin-development] SIGHASH_WITHINPUTVALUE 2015-01-23 14:51 [Bitcoin-development] SIGHASH_WITHINPUTVALUE slush 2015-01-23 15:24 ` Alan Reiner @ 2015-01-23 15:31 ` Tamas Blummer 2015-01-23 15:42 ` Alan Reiner 1 sibling, 1 reply; 20+ messages in thread From: Tamas Blummer @ 2015-01-23 15:31 UTC (permalink / raw) To: slush; +Cc: bitcoin-development [-- Attachment #1.1: Type: text/plain, Size: 123 bytes --] Not a fix, but would reduce the financial risk, if nodes were not relaying excessive fee transactions. Tamas Blummer [-- Attachment #1.2: Type: text/html, Size: 1089 bytes --] [-- Attachment #2: Message signed with OpenPGP using GPGMail --] [-- Type: application/pgp-signature, Size: 496 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Bitcoin-development] SIGHASH_WITHINPUTVALUE 2015-01-23 15:31 ` Tamas Blummer @ 2015-01-23 15:42 ` Alan Reiner 2015-01-23 15:47 ` slush 0 siblings, 1 reply; 20+ messages in thread From: Alan Reiner @ 2015-01-23 15:42 UTC (permalink / raw) To: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 611 bytes --] Unfortunately, one major attack vector is someone isolating your node, getting you to sign away your whole wallet to fee, and then selling it to a mining pool to mine it before you can figure why your transactions aren't making it to the network. In such an attack, the relay rules aren't relevant, and if the attacker can DoS you for 24 hours, it doesn't take a ton of mining power to make the attack extremely likely to succeed. On 01/23/2015 10:31 AM, Tamas Blummer wrote: > Not a fix, but would reduce the financial risk, if nodes were not > relaying excessive fee transactions. > > Tamas Blummer > > [-- Attachment #2: Type: text/html, Size: 2064 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Bitcoin-development] SIGHASH_WITHINPUTVALUE 2015-01-23 15:42 ` Alan Reiner @ 2015-01-23 15:47 ` slush 2015-01-23 16:08 ` Tamas Blummer 0 siblings, 1 reply; 20+ messages in thread From: slush @ 2015-01-23 15:47 UTC (permalink / raw) To: Alan Reiner; +Cc: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 1504 bytes --] Correct, plus the most likely scenario in such attack is that the malware even don't push such tx with excessive fees to the network, but send it directly to attacker's pool/miner. M. On Fri, Jan 23, 2015 at 4:42 PM, Alan Reiner <etotheipi@gmail•com> wrote: > Unfortunately, one major attack vector is someone isolating your node, > getting you to sign away your whole wallet to fee, and then selling it to a > mining pool to mine it before you can figure why your transactions aren't > making it to the network. In such an attack, the relay rules aren't > relevant, and if the attacker can DoS you for 24 hours, it doesn't take a > ton of mining power to make the attack extremely likely to succeed. > > > > > On 01/23/2015 10:31 AM, Tamas Blummer wrote: > > Not a fix, but would reduce the financial risk, if nodes were not relaying > excessive fee transactions. > > Tamas Blummer > > > > > > ------------------------------------------------------------------------------ > New Year. New Location. New Benefits. New Data Center in Ashburn, VA. > GigeNET is offering a free month of service with a new server in Ashburn. > Choose from 2 high performing configs, both with 100TB of bandwidth. > Higher redundancy.Lower latency.Increased capacity.Completely compliant. > http://p.sf.net/sfu/gigenet > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > [-- Attachment #2: Type: text/html, Size: 2978 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Bitcoin-development] SIGHASH_WITHINPUTVALUE 2015-01-23 15:47 ` slush @ 2015-01-23 16:08 ` Tamas Blummer 2015-01-23 16:12 ` Adam Back 0 siblings, 1 reply; 20+ messages in thread From: Tamas Blummer @ 2015-01-23 16:08 UTC (permalink / raw) To: slush; +Cc: bitcoin-development [-- Attachment #1.1: Type: text/plain, Size: 1185 bytes --] You mean an isolated signing device without memory right? An isolated node would still know the transactions substantiating its coins, why would it sign them away to fees ? Tamas Blummer On Jan 23, 2015, at 4:47 PM, slush <slush@centrum•cz> wrote: > Correct, plus the most likely scenario in such attack is that the malware even don't push such tx with excessive fees to the network, but send it directly to attacker's pool/miner. > > M. > > On Fri, Jan 23, 2015 at 4:42 PM, Alan Reiner <etotheipi@gmail•com> wrote: > Unfortunately, one major attack vector is someone isolating your node, getting you to sign away your whole wallet to fee, and then selling it to a mining pool to mine it before you can figure why your transactions aren't making it to the network. In such an attack, the relay rules aren't relevant, and if the attacker can DoS you for 24 hours, it doesn't take a ton of mining power to make the attack extremely likely to succeed. > > > > > On 01/23/2015 10:31 AM, Tamas Blummer wrote: >> Not a fix, but would reduce the financial risk, if nodes were not relaying excessive fee transactions. >> >> Tamas Blummer >> >> > > [-- Attachment #1.2: Type: text/html, Size: 3624 bytes --] [-- Attachment #2: Message signed with OpenPGP using GPGMail --] [-- Type: application/pgp-signature, Size: 496 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Bitcoin-development] SIGHASH_WITHINPUTVALUE 2015-01-23 16:08 ` Tamas Blummer @ 2015-01-23 16:12 ` Adam Back 2015-01-23 16:17 ` Adam Back 0 siblings, 1 reply; 20+ messages in thread From: Adam Back @ 2015-01-23 16:12 UTC (permalink / raw) To: Tamas Blummer; +Cc: bitcoin-development its an always offline node, so it knows nothing really other than a BIP 32 hierarchy of keys & a signature request. So the signature request has to drag with it information to validate what the value is, in order to be sure not to sign away 99% to fees. Signing the transaction value and having the network validate that the value in the sig matches full nodes view of the tx value avoids that issue. Simple, elegant, but... we have no live beta mechanism, and hence risk & testing makes that tricky. Plus the full network upgrade issue if its not backwards compatible. Adam On 23 January 2015 at 16:08, Tamas Blummer <tamas@bitsofproof•com> wrote: > You mean an isolated signing device without memory right? > > An isolated node would still know the transactions substantiating its coins, > why would it sign them away to fees ? > > Tamas Blummer > > On Jan 23, 2015, at 4:47 PM, slush <slush@centrum•cz> wrote: > > Correct, plus the most likely scenario in such attack is that the malware > even don't push such tx with excessive fees to the network, but send it > directly to attacker's pool/miner. > > M. > > On Fri, Jan 23, 2015 at 4:42 PM, Alan Reiner <etotheipi@gmail•com> wrote: >> >> Unfortunately, one major attack vector is someone isolating your node, >> getting you to sign away your whole wallet to fee, and then selling it to a >> mining pool to mine it before you can figure why your transactions aren't >> making it to the network. In such an attack, the relay rules aren't >> relevant, and if the attacker can DoS you for 24 hours, it doesn't take a >> ton of mining power to make the attack extremely likely to succeed. >> >> >> >> >> On 01/23/2015 10:31 AM, Tamas Blummer wrote: >> >> Not a fix, but would reduce the financial risk, if nodes were not relaying >> excessive fee transactions. >> >> Tamas Blummer >> >> >> >> > > > ------------------------------------------------------------------------------ > New Year. New Location. New Benefits. New Data Center in Ashburn, VA. > GigeNET is offering a free month of service with a new server in Ashburn. > Choose from 2 high performing configs, both with 100TB of bandwidth. > Higher redundancy.Lower latency.Increased capacity.Completely compliant. > http://p.sf.net/sfu/gigenet > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Bitcoin-development] SIGHASH_WITHINPUTVALUE 2015-01-23 16:12 ` Adam Back @ 2015-01-23 16:17 ` Adam Back 0 siblings, 0 replies; 20+ messages in thread From: Adam Back @ 2015-01-23 16:17 UTC (permalink / raw) To: Adam Back; +Cc: bitcoin-development Issues like that particular one (simple elegant fix, strong utility justification) plus previously more privacy stuff (like committed tx, homomorphic encrypted values) was what got me wondering about a way to do a live beta (one-way peg) and then to get excited about the 2wp & Greg's mechanism for that. I think it would be hypothetically possible to make a "special" singleton sidechain which is merge mined, and has a consensus rule to require some proportion of reward be sent to it via coinbase tx (a mechanism to address incentive incompatibility) and a general timeline eg 12mo to next version +/- etc. might be an interesting thing to explore as a place to store live versions of "hard fork wishlist" items where people who need them early can help validate them. I am not sure that helps the full network upgrade issue though. Adam On 23 January 2015 at 16:12, Adam Back <adam@cypherspace•org> wrote: > its an always offline node, so it knows nothing really other than a > BIP 32 hierarchy of keys & a signature request. > > So the signature request has to drag with it information to validate > what the value is, in order to be sure not to sign away 99% to fees. > Signing the transaction value and having the network validate that the > value in the sig matches full nodes view of the tx value avoids that > issue. Simple, elegant, but... we have no live beta mechanism, and > hence risk & testing makes that tricky. Plus the full network upgrade > issue if its not backwards compatible. > > Adam > > On 23 January 2015 at 16:08, Tamas Blummer <tamas@bitsofproof•com> wrote: >> You mean an isolated signing device without memory right? >> >> An isolated node would still know the transactions substantiating its coins, >> why would it sign them away to fees ? >> >> Tamas Blummer >> >> On Jan 23, 2015, at 4:47 PM, slush <slush@centrum•cz> wrote: >> >> Correct, plus the most likely scenario in such attack is that the malware >> even don't push such tx with excessive fees to the network, but send it >> directly to attacker's pool/miner. >> >> M. >> >> On Fri, Jan 23, 2015 at 4:42 PM, Alan Reiner <etotheipi@gmail•com> wrote: >>> >>> Unfortunately, one major attack vector is someone isolating your node, >>> getting you to sign away your whole wallet to fee, and then selling it to a >>> mining pool to mine it before you can figure why your transactions aren't >>> making it to the network. In such an attack, the relay rules aren't >>> relevant, and if the attacker can DoS you for 24 hours, it doesn't take a >>> ton of mining power to make the attack extremely likely to succeed. >>> >>> >>> >>> >>> On 01/23/2015 10:31 AM, Tamas Blummer wrote: >>> >>> Not a fix, but would reduce the financial risk, if nodes were not relaying >>> excessive fee transactions. >>> >>> Tamas Blummer >>> >>> >>> >>> >> >> >> ------------------------------------------------------------------------------ >> New Year. New Location. New Benefits. New Data Center in Ashburn, VA. >> GigeNET is offering a free month of service with a new server in Ashburn. >> Choose from 2 high performing configs, both with 100TB of bandwidth. >> Higher redundancy.Lower latency.Increased capacity.Completely compliant. >> http://p.sf.net/sfu/gigenet >> _______________________________________________ >> Bitcoin-development mailing list >> Bitcoin-development@lists•sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2015-01-23 19:20 UTC | newest] Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-01-23 14:51 [Bitcoin-development] SIGHASH_WITHINPUTVALUE slush 2015-01-23 15:24 ` Alan Reiner 2015-01-23 15:40 ` slush 2015-01-23 16:05 ` Gregory Maxwell 2015-01-23 16:18 ` slush 2015-01-23 16:52 ` Gregory Maxwell 2015-01-23 17:40 ` slush 2015-01-23 18:51 ` Gregory Maxwell 2015-01-23 19:19 ` slush 2015-01-23 16:23 ` Alan Reiner 2015-01-23 16:27 ` Alan Reiner 2015-01-23 16:33 ` Alan Reiner 2015-01-23 16:35 ` slush 2015-01-23 17:49 ` Peter Todd 2015-01-23 15:31 ` Tamas Blummer 2015-01-23 15:42 ` Alan Reiner 2015-01-23 15:47 ` slush 2015-01-23 16:08 ` Tamas Blummer 2015-01-23 16:12 ` Adam Back 2015-01-23 16:17 ` Adam Back
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox