Sorry but I don't think this is worth hard forking Bitcoin over. For validating a signature we currently need only the input (if it's signed). This change increases the number of dependencies for signature checking code. Namely Bitcoin validation nodes now need to fetch the previous output. This could seriously complicate the design and functionality of Bitcoin nodes if widely used. It is a good idea, but there are many ways to improve Bitcoin. I'm not sure Bitcoin is made for these things and should stay more simple and focused (like UNIX vs the other operating systems).
http://www.gwern.net/Bitcoin%20is%20Worse%20is%20Better?2
Bitcoin works because it doesn't try to do much. If we want to maintain a decentralised and open Bitcoin, I think it's a bit of a slippery slope to throw every feature we get excited about into Bitcoin.
Topic: SIGHASH_WITHINPUTVALUE: Super-lightweight HW wallets and offline data - page 3. (Read 9898 times)
November 21, 2013, 10:58:15 AM
November 21, 2013, 10:25:40 AM
For reference, I specifically recall retep talking to Gavin about it on IRC shortly after his last post, and Gavin agreed that modifying the SIGHASH system was a bad idea. I didn't feel like pressing it, at the time, though.
That's not to say that this can't be done or that Gavin and the other devs aren't persuadable. But it would mean mobilizing support for it and presenting a strong case to those that are against it. If the system was built with feature from the start, we'd all be happy and no one would have an issue with it. It's more about convincing folks that the benefit is worth the trouble of making the change. As you said... the people who most strongly support this are the ones actually developing software that has to deal with the megabytes of supporting transactions just to verify a few bytes.
That's not to say that this can't be done or that Gavin and the other devs aren't persuadable. But it would mean mobilizing support for it and presenting a strong case to those that are against it. If the system was built with feature from the start, we'd all be happy and no one would have an issue with it. It's more about convincing folks that the benefit is worth the trouble of making the change. As you said... the people who most strongly support this are the ones actually developing software that has to deal with the megabytes of supporting transactions just to verify a few bytes.
You'll have more luck pushing for this by developing a multisig wallet implementation and getting people to actually use it first - P2SH required a painful soft-fork yet years later it's still hardly ever used, making people question the value of new features. P2SH was something that everyone was supposed to be using by now because of the "obvious" security need; you're proposed reason for a soft-fork and associated system-wide risk is significantly more niche.
Bits of Proof is launching a JV product that uses P2SH before end of this year. Can't tell more yet.
In addition it also facilitates ticket sales for the btc1k party in Frankfurt am Main for which the vault will also use P2SH.
November 21, 2013, 08:48:21 AM
Well I think we are getting off topic here - but just wanted to add my support to etotheipi's idea as I have also created an offline tx signing system (which has no blockchain and just does signing) and it would very much benefit by knowing the tx fee.
As I use QR codes and want to keep the information transferred offline to a minimum I think something along the lines of his suggestion would be a very good idea.
As I use QR codes and want to keep the information transferred offline to a minimum I think something along the lines of his suggestion would be a very good idea.
November 21, 2013, 05:29:45 AM
The sweet spot is probably 16 and 32-bit microprocessors: fast enough to handle crypto without pain, small enough that hiding malicious features is very tough for the manufacturer, and cheap enough that the community has a chance of auditing the actual shipped hardware and firmware against the claimed design.
It shouldn't be a microprocessor at all.Think something like this, but to perform ECDSA instead: https://en.wikipedia.org/wiki/555_timer_IC
Truly secure hardware wallets will need to be built at the level of electrical engineering, not software engineering.
I am an electrical engineer, and frankly what you're saying is crazy.
Just curious - why so crazy?
AND... EVEN MORE CURIOUS - do you mean you are an ELECTRONIC engineer??
ELECTRICAL engineering has NOTHING to do with electronics, hardware, or anything else discussed on this thread? Just sayin.
Mind you, the original commenter also misspoke in describing this as "electrical engineering" work
November 21, 2013, 05:11:11 AM
The sweet spot is probably 16 and 32-bit microprocessors: fast enough to handle crypto without pain, small enough that hiding malicious features is very tough for the manufacturer, and cheap enough that the community has a chance of auditing the actual shipped hardware and firmware against the claimed design.
It shouldn't be a microprocessor at all.Think something like this, but to perform ECDSA instead: https://en.wikipedia.org/wiki/555_timer_IC
Truly secure hardware wallets will need to be built at the level of electrical engineering, not software engineering.
I am an electrical engineer, and frankly what you're saying is crazy.
November 21, 2013, 04:47:35 AM
"
""Truly secure hardware wallets will need to be built at the level of electrical engineering, not software engineering."
fuken A man
Fuken A
""Truly secure hardware wallets will need to be built at the level of electrical engineering, not software engineering."
fuken A man
Fuken A
November 21, 2013, 04:04:17 AM
If it's so trivial to implement then where is your proposed implementation and BIP? It could be re-implemented fifty times through rejections and objections and still be less work that the true work associated with all the testing, wallet implementations, and alt-implementations associated with this idea.
Anyway, it doesn't simplify offline signing all that much, it just makes it possible with more limited hardware. The actual code is basically the same in both cases. Heck, the design effort required for the hardware isn't much different in most cases: moderately fast USB interfaces aren't a big deal these days and come pre-packaged.
This also encourages the design of really limited hardware wallets that don't support the payment protocol: if you don't know who you are paying, all you've done is limited the rate that your funds can be stolen a bit. Heck, on that basis I think I'd actually NACK such a patch myself...
Anyway, it doesn't simplify offline signing all that much, it just makes it possible with more limited hardware. The actual code is basically the same in both cases. Heck, the design effort required for the hardware isn't much different in most cases: moderately fast USB interfaces aren't a big deal these days and come pre-packaged.
This also encourages the design of really limited hardware wallets that don't support the payment protocol: if you don't know who you are paying, all you've done is limited the rate that your funds can be stolen a bit. Heck, on that basis I think I'd actually NACK such a patch myself...
It definitely simplifies offline signing significantly. With the proposed modification, the HW wallet only has to present the user with a prompt to confirm sending X coins to Y address with Z fee using some number of wallet addresses for which it has the private key. If the transaction that the device is being asked to sign is not what the user expects (including the case of large fee), they reject it. Simple.
As it stands now, the HW wallet has to be able to prove without a doubt the current value of its wallet addresses so that the fee can be properly calculated and presented (or to trigger an auto-reject if the fee is above a threshold). This requires tracking and verifying a large enough chunk of the blockchain to prove this. What's the lightest way a small HW wallet can do this without trusting the SW feeding it transactions to sign? It's something I'm researching right now, but the proposed modification would make this problem irrelevant and cut down development and testing time significantly.
November 21, 2013, 03:13:46 AM
The sweet spot is probably 16 and 32-bit microprocessors: fast enough to handle crypto without pain, small enough that hiding malicious features is very tough for the manufacturer, and cheap enough that the community has a chance of auditing the actual shipped hardware and firmware against the claimed design.
It shouldn't be a microprocessor at all.Think something like this, but to perform ECDSA instead: https://en.wikipedia.org/wiki/555_timer_IC
Truly secure hardware wallets will need to be built at the level of electrical engineering, not software engineering.
November 21, 2013, 03:07:59 AM
If it's so trivial to implement then where is your proposed implementation and BIP? It could be re-implemented fifty times through rejections and objections and still be less work that the true work associated with all the testing, wallet implementations, and alt-implementations associated with this idea.
I was talking about from the wallet design perspective. Multi-sig & P2SH increases the complexity of the app. This change is trivial leverage in your software and dramatically simplifies it. I assure you I understand that any such changes are "not trivial" to implement in the protocol. But it certainly doesn't hurt that it's so simple in concept...
November 21, 2013, 02:56:52 AM
Slightly off-topic, but if it wasn't for the rapid blockchain growth and my procrastination in fixing Armory's scalability issues, I'd have Multisig-with-P2SH implemented already. The problem is not the features being useless or unwanted, it's that there's such a shortage of human capital to make progress in this part of the Bitcoin development world. There's so few environments where such a feature could be implemented, and so many other priorities of the few people developing those environments.
However, this particular change is trivial to implement, and dramtically simplifies implementation of any kind of offline signing device. There's no doubt it would be used immediately by Armory and all the HW wallet developers.
However, this particular change is trivial to implement, and dramtically simplifies implementation of any kind of offline signing device. There's no doubt it would be used immediately by Armory and all the HW wallet developers.
If it's so trivial to implement then where is your proposed implementation and BIP? It could be re-implemented fifty times through rejections and objections and still be less work that the true work associated with all the testing, wallet implementations, and alt-implementations associated with this idea.
Anyway, it doesn't simplify offline signing all that much, it just makes it possible with more limited hardware. The actual code is basically the same in both cases. Heck, the design effort required for the hardware isn't much different in most cases: moderately fast USB interfaces aren't a big deal these days and come pre-packaged.
This also encourages the design of really limited hardware wallets that don't support the payment protocol: if you don't know who you are paying, all you've done is limited the rate that your funds can be stolen a bit. Heck, on that basis I think I'd actually NACK such a patch myself...
November 21, 2013, 02:42:14 AM
P2SH was something that everyone was supposed to be using by now because of the "obvious" security need; you're proposed reason for a soft-fork and associated system-wide risk is significantly more niche.
It won't be niche when the PC platform as a whole is rendered unusable for secure applications by firmware-level, airgap-crossing malware.*Secure hardware wallets need to be here before that happens.
*"Secure" means custom silicon specifically hardened against side channel attacks and such, not off the shelf embedded systems containing god-knows-what vulnerabilities.
Custom silicon is the problem: how do you know what it's actually doing?
The sweet spot is probably 16 and 32-bit microprocessors: fast enough to handle crypto without pain, small enough that hiding malicious features is very tough for the manufacturer, and cheap enough that the community has a chance of auditing the actual shipped hardware and firmware against the claimed design.
Microprocessors in this class don't have significant problems with txin's provided they have a reasonable interface to the PC, like USB: just hash the supporting transactions incrementally. With well-designed hardware the fact that the device is connected by USB has no security risks and can be easily audited. (FTDI's USB<->high-speed-serial chips are a good option for the truly paranoid)
November 21, 2013, 02:27:14 AM
You'll have more luck pushing for this by developing a multisig wallet implementation and getting people to actually use it first - P2SH required a painful soft-fork yet years later it's still hardly ever used, making people question the value of new features. P2SH was something that everyone was supposed to be using by now because of the "obvious" security need; you're proposed reason for a soft-fork and associated system-wide risk is significantly more niche.
Slightly off-topic, but if it wasn't for the rapid blockchain growth and my procrastination in fixing Armory's scalability issues, I'd have Multisig-with-P2SH implemented already. The problem is not the features being useless or unwanted, it's that there's such a shortage of human capital to make progress in this part of the Bitcoin development world. There's so few environments where such a feature could be implemented, and so many other priorities of the few people developing those environments.
However, this particular change is trivial to implement, and dramtically simplifies implementation of any kind of offline signing device. There's no doubt it would be used immediately by Armory and all the HW wallet developers.
November 21, 2013, 02:21:17 AM
P2SH was something that everyone was supposed to be using by now because of the "obvious" security need; you're proposed reason for a soft-fork and associated system-wide risk is significantly more niche.
It won't be niche when the PC platform as a whole is rendered unusable for secure applications by firmware-level, airgap-crossing malware.*Secure hardware wallets need to be here before that happens.
*"Secure" means custom silicon specifically hardened against side channel attacks and such, not off the shelf embedded systems containing god-knows-what vulnerabilities.
November 21, 2013, 02:04:42 AM
For reference, I specifically recall retep talking to Gavin about it on IRC shortly after his last post, and Gavin agreed that modifying the SIGHASH system was a bad idea. I didn't feel like pressing it, at the time, though.
That's not to say that this can't be done or that Gavin and the other devs aren't persuadable. But it would mean mobilizing support for it and presenting a strong case to those that are against it. If the system was built with feature from the start, we'd all be happy and no one would have an issue with it. It's more about convincing folks that the benefit is worth the trouble of making the change. As you said... the people who most strongly support this are the ones actually developing software that has to deal with the megabytes of supporting transactions just to verify a few bytes.
That's not to say that this can't be done or that Gavin and the other devs aren't persuadable. But it would mean mobilizing support for it and presenting a strong case to those that are against it. If the system was built with feature from the start, we'd all be happy and no one would have an issue with it. It's more about convincing folks that the benefit is worth the trouble of making the change. As you said... the people who most strongly support this are the ones actually developing software that has to deal with the megabytes of supporting transactions just to verify a few bytes.
You'll have more luck pushing for this by developing a multisig wallet implementation and getting people to actually use it first - P2SH required a painful soft-fork yet years later it's still hardly ever used, making people question the value of new features. P2SH was something that everyone was supposed to be using by now because of the "obvious" security need; you're proposed reason for a soft-fork and associated system-wide risk is significantly more niche.
Like it or not the amount of money that can be lost for a single consensus bug is staggering and gets bigger every day.
FWIW Litecoin will need to undergo a soft-fork soon to finally get height-in-coinbase implemented - talk this over with them, specifically Warren Togami.
November 20, 2013, 02:33:21 AM
The consensus seems to be that no one thinks it's worth doing this. I still think it makes sense to do as one of those latent upgrades that goes in now but isn't active until 12 months from now. But as you can see from the discussion some people are very focused on overhauling the SIGHASH system entirely, and don't think it's worth the effort to do this small change. I disagree, but what can I do?
The consensus unlikely includes those developing wallets. It is the single most dangerous "feature" I came across while implementing Bitcoin that one is not able to validate the fee of a transaction on its own but need to retrieve its referenced predecessors. We should do this.For reference, I specifically recall retep talking to Gavin about it on IRC shortly after his last post, and Gavin agreed that modifying the SIGHASH system was a bad idea. I didn't feel like pressing it, at the time, though.
That's not to say that this can't be done or that Gavin and the other devs aren't persuadable. But it would mean mobilizing support for it and presenting a strong case to those that are against it. If the system was built with feature from the start, we'd all be happy and no one would have an issue with it. It's more about convincing folks that the benefit is worth the trouble of making the change. As you said... the people who most strongly support this are the ones actually developing software that has to deal with the megabytes of supporting transactions just to verify a few bytes.
November 20, 2013, 02:21:56 AM
I'll gladly do what is needed to support this proposal, whatever way I can. I wonder what some of the other HW wallet guys are doing (e.g. Trezor)? Probably some form of SPV - but this kind of thing seriously increases the complexity and resource demands of a small HW wallet implementation.
November 20, 2013, 02:15:26 AM
The consensus seems to be that no one thinks it's worth doing this. I still think it makes sense to do as one of those latent upgrades that goes in now but isn't active until 12 months from now. But as you can see from the discussion some people are very focused on overhauling the SIGHASH system entirely, and don't think it's worth the effort to do this small change. I disagree, but what can I do?
The consensus unlikely includes those developing wallets. It is the single most dangerous "feature" I came across while implementing Bitcoin that one is not able to validate the fee of a transaction on its own but need to retrieve its referenced predecessors. We should do this. November 20, 2013, 02:09:35 AM
Well, that is quite unfortunate. Thanks for the update, guess I have to go find another way to prevent the 'transaction fee' attack on my wallet...
November 20, 2013, 01:59:39 AM
The consensus seems to be that no one thinks it's worth doing this. I still think it makes sense to do as one of those latent upgrades that goes in now but isn't active until 12 months from now. But as you can see from the discussion some people are very focused on overhauling the SIGHASH system entirely, and don't think it's worth the effort to do this small change. I disagree, but what can I do?
November 20, 2013, 01:52:47 AM
etotheipi - your original proposal is just the thing I'm looking for and is quite simple and elegant. I was happily implementing my lightweight HW wallet and blundered across this nasty snag just today. Has there been any further development on this front recently?
Jump to: