SIGHASH_WITHINPUTVALUE: Super-lightweight HW wallets and offline data

[etotheipi]

Yes you are missing something.

The way Trezor works is that the untrusted host computer provides the Trezor wallet with every transaction that the to-be-signed transaction's inputs spend. All transactions refer to transaction inputs by a secure cryptographic hash, the transaction id. Thus it is impossible for the host computer to hide what transaction inputs are in fact being signed by the wallet - the worst the host computer could do is have the wallet harmlessly sign a completely invalid transaction.

Ahh, of course - I was overcomplicating things in my mind. Thanks for setting me straight. My test harness was making up these previous hashes for the purpose of tx signature testing, so I mentally wrote them off as arbitrary.

If my device is presented with the previous transactions for addresses A, B, and C (which include their total value) I can simply SHA256 these, make sure the hashes in the outpoint structures for the tx I'm going to sign match, and then I know the total alleged value for A, B, C and can present outputs and fees to the user. As you said before, the worst thing the SW feeding me stuff to sign can do is make me create a bogus transaction that will be rejected by the network. A bit of a hassle, but at least its just doing a streaming calculation of a SHA256 (not ECDSA thank goodness!) and no blockchain data is necessary. I feel alot better now, back to making progress 

However, life as a HW wallet designer would still be much better with the proposed addition.

For reference, BIP 10 is what I use in Armory to do the same thing.  It was intended to be an ASCII-based way to move all this data in "blocks", either through email or text files on USB.  It does work (Armory has been using it for offline transactions for 2 years), but it will be replaced soon.  I'm told the payment protocol can replace this, but I still haven't had much time to dig into the payment protocol...

Of course, that dramatically increases the complexity of it, having to pass around potentially MB of supporting transactions to verify those 8-byte values.  Can the payment protocol handle it?

[1715365449]

1715365449

[Peter Todd]

For reference, BIP 10 is what I use in Armory to do the same thing.  It was intended to be an ASCII-based way to move all this data in "blocks", either through email or text files on USB.  It does work (Armory has been using it for offline transactions for 2 years), but it will be replaced soon.  I'm told the payment protocol can replace this, but I still haven't had much time to dig into the payment protocol...

Of course, that dramatically increases the complexity of it, having to pass around potentially MB of supporting transactions to verify those 8-byte values.  Can the payment protocol handle it?

The payment protocol has absolutely nothing to do with offline wallets or transaction signing.

[CIYAM]

I mentioned the idea of using an OP_CHECKFEE <amount> instead (as it would only be a single addition to the end of the tx so wouldn't blow out the size).

It would still require a hard-fork but at least doesn't get involved with any of the existing SIG stuff.

If the idea is crap then *please* I'd appreciate an explanation.

[etotheipi]

For reference, BIP 10 is what I use in Armory to do the same thing.  It was intended to be an ASCII-based way to move all this data in "blocks", either through email or text files on USB.  It does work (Armory has been using it for offline transactions for 2 years), but it will be replaced soon.  I'm told the payment protocol can replace this, but I still haven't had much time to dig into the payment protocol...

Of course, that dramatically increases the complexity of it, having to pass around potentially MB of supporting transactions to verify those 8-byte values.  Can the payment protocol handle it?

The payment protocol has absolutely nothing to do with offline wallets or transaction signing.

Kind of... when I posted to the mailing list about making a better version of BIP 10 and asking for community support... Mike Hearn insisted that everything we need will be in the payment protocol.  I took his word for it.  Or I misunderstood him.  If that's not the case, then I'll need to come up with another spec to replace BIP 10 that accommodates signed payment addresses, multisig, and supporting-transaction-lists.

Again, I may just be ignorant about it, because I haven't had any time to look at the payment protocol yet.  And/or I misunderstood Mike.

[justusranvier]

If the idea is crap then *please* I'd appreciate an explanation.

Explanations are extremely important, given that certain organizations are known to infiltrate standards committees and open source projects and steer them away from implementing good security.

Even if no such activity is happening in Bitcoin, it's better to not even have the appearance of something shady going on, like  an proposal for an obvious security enhancement just being silently rejected with no real explanation.

[CIYAM]

I have started a new topic here: https://bitcointalk.org/index.php?topic=343234.0 as I don't think my idea is going to be considered in this topic.

[Peter Todd]

The payment protocol has absolutely nothing to do with offline wallets or transaction signing.

Kind of... when I posted to the mailing list about making a better version of BIP 10 and asking for community support... Mike Hearn insisted that everything we need will be in the payment protocol.  I took his word for it.  Or I misunderstood him.  If that's not the case, then I'll need to come up with another spec to replace BIP 10 that accommodates signed payment addresses, multisig, and supporting-transaction-lists.

Again, I may just be ignorant about it, because I haven't had any time to look at the payment protocol yet.  And/or I misunderstood Mike.

Yeah I dunno what he was smoking there, or you for that matter.

The #1 thing the payment protocol does is creates a framework for the sender to verify who they are really paying the coins to; everything else in it is secondary.

BIP 10 on the other hand looks to be about making a convenient and standard way to pass around unsigned transactions so different parties can sign them. That's a very different application - if anything it'd make sense for BIP 10 to add support for the payment protocol in the form of specifying a way to pass around relevant payment request information as part of the not-yet-signed transaction.

[justusranvier]

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?

[Peter Todd]

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.

[CIYAM]

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.

[justusranvier]

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.

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."

[Peter Todd]

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.

[CIYAM]

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]

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]

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]

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]

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.

[justusranvier]

"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.

[oakpacific]

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.

[CIYAM]

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.