SIGHASH_WITHINPUTVALUE: Super-lightweight HW wallets and offline data

TierNolan

legendary

Activity: 1232

Merit: 1094

Quote from: etotheipi on April 20, 2013, 04:14:41 PM

So the technical solution is simple: Add a new SIGHASH type, which I dub SIGHASH_WITHINPUTVALUE. This would have hashcode 0x10. This would be OR'd with the existing hash types. i.e. Currently all "regular" transactions are signed with (SIGHASH_ALL), now anyone who wants the benefit would sign with (SIGHASH_ALL | SIGHASH_WITHINPUTVALUE). It is compatible with the existing hash types.

Sorry for necroing.

Would this actually be backward compatible? An old client would just apply the SIGHASH_ALL procedure and then attempt to check the signature. This would give the wrong answer since it would hash without the value. You would have to have OP_CHECKSIG consume two signatures or something.

jl2012

legendary

Activity: 1792

Merit: 1111

Quote from: justusranvier on August 03, 2014, 12:35:25 PM

Quote from: jl2012 on August 03, 2014, 12:33:42 PM

It is trivial to implement this on a new alt-coin. For bitcoin, however, this requires a CHECKSIG 2.0 or even Script 2.0. I doubt we would ever see it

Certainly altcoin pumpers have an incentive to spread the meme that it's impossible to upgrade Bitcoin, but that doesn't make it true.

Very good. I always want to have a Script 2.0 which support not only SIGHASH_WITHINPUTVALUE, but also more public key and hash algorithms, merklised syntax tree, OP_EVAL, OP_CAT, OP_SUBSTR, and more. All could be done with a soft-fork. Please code it and persuade 90% of miners to adopt it.

By the way, I own no altcoin

justusranvier

legendary

Activity: 1400

Merit: 1013

Quote from: jl2012 on August 03, 2014, 12:33:42 PM

It is trivial to implement this on a new alt-coin. For bitcoin, however, this requires a CHECKSIG 2.0 or even Script 2.0. I doubt we would ever see it

Certainly altcoin pumpers have an incentive to spread the meme that it's impossible to upgrade Bitcoin, but that doesn't make it true.

jl2012

legendary

Activity: 1792

Merit: 1111

Quote from: justusranvier on August 03, 2014, 12:08:35 PM

So a year after this thread was started efficient offline signing is still not possible, and there is no clear path for getting features like new hash types into the protocol, even though everything is versioned and upgrades have happened in the past.

It is trivial to implement this on a new alt-coin. For bitcoin, however, this requires a CHECKSIG 2.0 or even Script 2.0. I doubt we would ever see it

justusranvier

legendary

Activity: 1400

Merit: 1013

So a year after this thread was started efficient offline signing is still not possible, and there is no clear path for getting features like new hash types into the protocol, even though everything is versioned and upgrades have happened in the past.

CIYAM

legendary

Activity: 1890

Merit: 1086

Ian Knowles - CIYAM Lead Developer

Quote from: oakpacific on January 15, 2014, 02:54:49 AM

Thank you, noobish question: the code can be easily migrated to Bitcoin, right?

Yes - it shouldn't be very hard to re-implement the same for Bitcoin down the track (the code might not be identical but will be fairly close to it).

oakpacific

hero member

Activity: 784

Merit: 1000

Quote from: CIYAM on January 15, 2014, 02:26:24 AM

Quote from: oakpacific on January 15, 2014, 02:21:09 AM

If someone wants to contribute, please state the time/cost required for such a task right here, I believe many people(at least me) will make an assessment.

I am working on this with Peter Todd's help - you can follow my progress here: https://github.com/ciyam/litecoin/tree/OP_CHECKSIGVERIFY2

So far I have only coded the version 3 block change as I am still undergoing quite a bit of a learning curve this might take some time but I am keen to see this through so assuming Peter doesn't lose patience with me we'll get there.

Thank you, noobish question: the code can be easily migrated to Bitcoin, right?

CIYAM

legendary

Activity: 1890

Merit: 1086

Ian Knowles - CIYAM Lead Developer

Quote from: oakpacific on January 15, 2014, 02:21:09 AM

If someone wants to contribute, please state the time/cost required for such a task right here, I believe many people(at least me) will make an assessment.

I am working on this with Peter Todd's help - you can follow my progress here: https://github.com/ciyam/litecoin/tree/OP_CHECKSIGVERIFY2

So far I have only coded the version 3 block change as I am still undergoing quite a bit of a learning curve this might take some time but I am keen to see this through so assuming Peter doesn't lose patience with me we'll get there.

oakpacific

hero member

Activity: 784

Merit: 1000

If someone wants to contribute, please state the time/cost required for such a task right here, I believe many people(at least me) will make an assessment.

Actually, it's inexplicable to me why there isn't a full list of "high-priority problems assigned to no one" right here on this forum, lots of people might have time/money to give for a crowdfunded project, but without knowing what the problems are they can do nothing.

justusranvier

legendary

Activity: 1400

Merit: 1013

"Hard fork" is a really bad term because it sounds unnecessarily scary.

It's a mandatory upgrade - Bitcoin has had them before and will again.

It kind of sucks to do them unplanned as a form of disaster response, but there's no reason to be afraid of them if they are properly planned.

Seems like it should go something like:

1) Write up BIPs for individual features that will require a new block version.
2) Write up a BIP to cover all the changes that will go into version 3 blocks and the upgrade plan including the conditions when version 3 blocks become mandatory.
3) Write code and tests.
4) Run everything through testnet
5) Release new software and wait for everybody to upgrade.

CIYAM

legendary

Activity: 1890

Merit: 1086

Ian Knowles - CIYAM Lead Developer

Quote from: Peter Todd on January 10, 2014, 11:41:25 AM

Anyway, like I said, do up an implementation for Litecoin of what you want to get the discussion started and show that you are serious. The code will be rewritten and modified at least once, probably more, but it'll help you understand what's involved.

Okay - I will look into this - the source being modified is no issue at all as I am sure I won't get everything right.

My motivation is not being "noted" for the contribution but to see a solution implemented.

Peter Todd

legendary

Activity: 1120

Merit: 1152

Quote from: CIYAM on January 10, 2014, 11:25:57 AM

Quote from: Peter Todd on January 10, 2014, 11:22:25 AM

Litecoin needs to do a soft-fork in the near future for a few reasons. (I've been hired to do it) You might have better luck there. It's a significantly simpler ecosystem, and if the fork goes badly the losses to miners would "only" be up to $28,000 per hour. (for me, kinda scary to think about actually)

This is interesting - if you think that it could be something that Litecoin would take on then I might be interested to work on this (am presuming you prefer etotheipi's solution than the one I separately suggested).

etotheipi's solution requires either a hard-fork, or a second signature to work. gmaxwell and I have discussed the idea of doing a better OP_CHECKSIG before, so I actually prefer your approach of redefining an OP_NOP to OP_CHECKSIGVERIFY2 and adding in the better SIGHASH flags we've been wanting for ages.

Anyway, like I said, do up an implementation for Litecoin of what you want to get the discussion started and show that you are serious. The code will be rewritten and modified at least once, probably more, but it'll help you understand what's involved.

CIYAM

legendary

Activity: 1890

Merit: 1086

Ian Knowles - CIYAM Lead Developer

Quote from: Peter Todd on January 10, 2014, 11:22:25 AM

Litecoin needs to do a soft-fork in the near future for a few reasons. (I've been hired to do it) You might have better luck there. It's a significantly simpler ecosystem, and if the fork goes badly the losses to miners would "only" be up to $28,000 per hour. (for me, kinda scary to think about actually)

This is interesting - if you think that it could be something that Litecoin would take on then I might be interested to work on this (am presuming you prefer etotheipi's solution than the one I separately suggested).

Peter Todd

legendary

Activity: 1120

Merit: 1152

Quote from: CIYAM on January 10, 2014, 10:56:46 AM

I think that if etotheipi isn't going to try something because there is no support from the devs then it is going to pretty hard to motivate others whose efforts are far more likely to be ignored.

If at least one core dev was supporting of the idea then I would gladly volunteer my time to implement it but I am very busy on my own project and am not really happy to spend hours or days on something that will end up just being ignored.

Bitcoin has a $11 billion market cap - don't be surprised if people are reluctant to make changes that could threaten the integrity of that system. If a bug in a SIGHASH_WITHINPUTVALUE implementation lead to a fork at current prices miners alone would be losing up to $150,000 per hour.

Litecoin needs to do a soft-fork in the near future for a few reasons. (I've been hired to do it) You might have better luck there. It's a significantly simpler ecosystem, and if the fork goes badly the losses to miners would "only" be up to $28,000 per hour. (for me, kinda scary to think about actually)

CIYAM

legendary

Activity: 1890

Merit: 1086

Ian Knowles - CIYAM Lead Developer

Quote from: Peter Todd on January 10, 2014, 10:46:35 AM

It's notably how for all the discussion in this thread, no-one has stepped up and done a weekend's worth of work and actually implemented SIGHASH_WITHINPUTVALUE. Sure, that code probably won't be what actually gets used in the end, but the amount of work involved in making a prototype is tiny compared to the sum total work required to make any of these proposed changes happen.

FWIW I sat down for a few hours once to do exactly that myself for my OP_CHECKLOCKTIMEVERIFY pet proposal; don't take the attitude that it'd be wasted effort.

I think that if etotheipi isn't going to try something because there is no support from the devs then it is going to pretty hard to motivate others whose efforts are far more likely to be ignored.

If at least one core dev was supporting of the idea then I would gladly volunteer my time to implement it but I am very busy on my own project and am not really happy to spend hours or days on something that will end up just being ignored.

Peter Todd

legendary

Activity: 1120

Merit: 1152

Quote from: justusranvier on January 10, 2014, 10:36:01 AM

Quote from: CIYAM on January 10, 2014, 10:23:42 AM

I have no idea why the devs have no interest in this and why instead the topic needs to be changed to push other peoples ideas (why not create your own topics as I did?).

Hopefully the answer is as simple as, "it would require work that nobody wants to do" and not, "if someone is found who is willing to do the work, their pull requests will be filibustered."

It's notably how for all the discussion in this thread, no-one has stepped up and done a weekend's worth of work and actually implemented SIGHASH_WITHINPUTVALUE. Sure, that code probably won't be what actually gets used in the end, but the amount of work involved in making a prototype is tiny compared to the sum total work required to make any of these proposed changes happen.

FWIW I sat down for a few hours once to do exactly that myself for my OP_CHECKLOCKTIMEVERIFY pet proposal; don't take the attitude that it'd be wasted effort.

justusranvier

legendary

Activity: 1400

Merit: 1013

Quote from: CIYAM on January 10, 2014, 10:23:42 AM

The point of this topic was "super-lightweight" - and the easiest way to achieve this would be to have the "fee" explicitly included in the tx.

Alan's original solution, on the other hand, solves two problems at once by making hardware wallets easier and also improving SPV security.

Quote from: CIYAM on January 10, 2014, 10:23:42 AM

I have no idea why the devs have no interest in this and why instead the topic needs to be changed to push other peoples ideas (why not create your own topics as I did?).

Hopefully the answer is as simple as, "it would require work that nobody wants to do" and not, "if someone is found who is willing to do the work, their pull requests will be filibustered."

CIYAM

legendary

Activity: 1890

Merit: 1086

Ian Knowles - CIYAM Lead Developer

The point of this topic was "super-lightweight" - and the easiest way to achieve this would be to have the "fee" explicitly included in the tx.

I have no idea why the devs have no interest in this and why instead the topic needs to be changed to push other peoples ideas (why not create your own topics as I did?).

Perhaps one or more alts will look at this issue more seriously than Bitcoin.

Peter Todd

legendary

Activity: 1120

Merit: 1152

Quote from: justusranvier on January 10, 2014, 08:44:36 AM

Doesn't this have even more significant implications that the ability to build simple, easy to secure, hardware wallets?

Unless I'm completely mistaken the inability of SPV nodes to detect if a miner is inflating the currency is related to the output values not being signed along with TxOut scripts.

A miner can create an invalid transaction that lies about the value of an input and use that excess input value as a transaction fee that the miner gets to keep.

An SPV node can not detect this because it doesn't have a copy of all prior transactions, but if the value was signed along with the script would it not block this class of attack?

Yes, this is a flaw that's been known for a long time; even better than just detection is to be able to create a compact fraud proof to warn other SPV clients. That's also why I've been pushing for systems that blur the distinctions between SPV and full nodes, so that more nodes have more data and thus more opportunities to detect fraud.

justusranvier

legendary

Activity: 1400

Merit: 1013

Quote from: etotheipi on April 20, 2013, 04:14:41 PM

Raw Technical Solution:

All this because Satoshi made one little oversight in the OP_CHECKSIG procedure: the TxOut script is copied into the input being signed, but not the value. If the value was copied prepended to the TxOut script, then the offline system only needs to be given the 8 bytes, and it could securely present the correct fee to the user and sign it. If an attacker compromises the online computer and puts incorrect values into there to trick the offline computer, the offline signature will be invalid (because full nodes verifying the transaction will use the correct value the signature won't match).

So the technical solution is simple: Add a new SIGHASH type, which I dub SIGHASH_WITHINPUTVALUE. This would have hashcode 0x10. This would be OR'd with the existing hash types. i.e. Currently all "regular" transactions are signed with (SIGHASH_ALL), now anyone who wants the benefit would sign with (SIGHASH_ALL | SIGHASH_WITHINPUTVALUE). It is compatible with the existing hash types.

Analogy:
Right Now: "I, the offline computer, sign this input to be sent to this address, no matter how much this input is worth"
Proposal: "I, the offline computer, have been told this input is worth 13.28 BTC. This signature is only valid if that's how much it's actually worth"

Doesn't this have even more significant implications that the ability to build simple, easy to secure, hardware wallets?

Unless I'm completely mistaken the inability of SPV nodes to detect if a miner is inflating the currency is related to the output values not being signed along with TxOut scripts.

A miner can create an invalid transaction that lies about the value of an input and use that excess input value as a transaction fee that the miner gets to keep.

An SPV node can not detect this because it doesn't have a copy of all prior transactions, but if the value was signed along with the script would it not block this class of attack?

Topic: SIGHASH_WITHINPUTVALUE: Super-lightweight HW wallets and offline data (Read 9898 times)