SIGHASH_WITHINPUTVALUE: Super-lightweight HW wallets and offline data

[natb]

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

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.

[RagnarDanneskjold]

"
""Truly secure hardware wallets will need to be built at the level of electrical engineering, not software engineering."

fuken A man
Fuken A

[Peter Todd]

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.

[RagnarDanneskjold]

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

[CIYAM]

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.

[grau]

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.

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.

[genjix]

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.

[grau]

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.

In contrary, the current situation forces the wallet to know the previous input, especially its value.

The proposal does not require to fetch previous input for signature but to have an opinion on the value of the previous input. If that opinion is wrong the transaction will be rejected and therefore avoided that a value incorrectly assumed goes to the miner.

[etotheipi]

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.

Did I miss something or did you?  The only thing this does is simplifies things for the signer, and negligible impact for the verifiers.  The verifier still has to go fetch the previous TxOut to get its scriptPubKey to cram into the TxIns before signing.  All this does is say "if this SIGHASH bit is on, also grab the value from that TxOut and prepend it to the scriptPubKey".  That simple change allows an offline signing device to sign transactions confidently without having to see the entire previous transactions being spent.

[natb]

So what is the process for getting a request like this in front of the development team for an opinion at least? I read up on https://en.bitcoin.it/wiki/BIP_0001#BIP_Work_Flow and it mentions vetting the idea on this forum as a starting point. Who typically chimes in on this sort of thing, and when do we know if it is worth writing up a BIP or not? I'm fairly new to this process, so forgive any naive questions.

[TierNolan]

They have (or are planning) to move the BIP system to github.

Maybe look at Bloom filtering as a feature being added that wasn't strictly necessary (but useful).

Presumably, one of the authors created the mods to the c++ code, but they don't seem to have linked an implementation to the BIP.

I have to say, that with the current rise in value, improved offline storage would be a good thing.

[genjix]

The script subsystem only requires the tx you are signing.

The point is more succinct - avoid extending the Bitcoin standard.

I would also like a SIGHASH flag where you can specify a specific output to sign (so you can specify change address with pledges for SIGHASH_ANYONECANPAY), but I don't think it's a good idea to change Bitcoin's current design. More dependencies and execution paths = poor design = insecure code. We should be taking things out, not putting in.

[natb]

The script subsystem only requires the tx you are signing.

The point is more succinct - avoid extending the Bitcoin standard.

I would also like a SIGHASH flag where you can specify a specific output to sign (so you can specify change address with pledges for SIGHASH_ANYONECANPAY), but I don't think it's a good idea to change Bitcoin's current design. More dependencies and execution paths = poor design = insecure code. We should be taking things out, not putting in.

When a signing device is presented a tx to sign, unfortunately it requires much more than the tx itself to give the end user an indication of how much is being proposed to send. Only the outputs are known with 100% certainty. The device must also know with 100% confidence the value of the inputs so the fees can be calculated. This in turn creates way more dependencies and code paths for a HW signing device.

Anyway, I'm now genuinely curious on how the Trezor is solving this problem. Etothepi, you mentioned they ran into it, and I presume they have attempted to solve it. Assuming that the software driving the HW wallet is not trusted (which is the cornerstone assumption of a good offline HW wallet design), I don't see how the device can pull this off without having a good deal of the blockchain present including some of it pre-programmed in the device at manufacturing. Maybe I'm missing some technique here, I'm all ears.

[Peter Todd]

When a signing device is presented a tx to sign, unfortunately it requires much more than the tx itself to give the end user an indication of how much is being proposed to send. Only the outputs are known with 100% certainty. The device must also know with 100% confidence the value of the inputs so the fees can be calculated. This in turn creates way more dependencies and code paths for a HW signing device.

Anyway, I'm now genuinely curious on how the Trezor is solving this problem. Etothepi, you mentioned they ran into it, and I presume they have attempted to solve it. Assuming that the software driving the HW wallet is not trusted (which is the cornerstone assumption of a good offline HW wallet design), I don't see how the device can pull this off without having a good deal of the blockchain present including some of it pre-programmed in the device at manufacturing. Maybe I'm missing some technique here, I'm all ears.

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.

[CIYAM]

The problem is not that it might sign an invalid transaction but that it signs a *valid* one which outputs say 1 BTC but includes a 99 BTC fee (assuming the UTXO was 100 BTC).

The offline device can show you that 1 BTC is going to be output but it cannot tell you anything about the change if it doesn't have the relevant information (which I believe that the Trezor doesn't have).

Or have I missed something obvious here?

[Peter Todd]

The problem is not that it might sign an invalid transaction but that it signs a *valid* one which outputs say 1 BTC but includes a 99 BTC fee (assuming the UTXO was 100 BTC).

The offline device can show you that 1 BTC is going to be output but it cannot tell you anything about the change if it doesn't have the relevant information (which I believe that the Trezor doesn't have).

Or have I missed something obvious here?

I checked the sourcecode they've published at https://github.com/trezor/ - it's not totally clear because they haven't published the actual device firmware, but the communications protocol lets the TREZOR fetch both transaction inputs and outputs. This would let the TREZOR build up that transaction incrementally so it doesn't need more than a minimal amount of ram, and of course let it fully verify each txin.

[CIYAM]

Okay - so am guessing the small display should have enough room to display the fee amount then.

Still it would be a lot nicer if offline signing did not have to know all about the inputs (and would allow for 100% secure offline tx signing that could be done with a very cheap device via QR codes).

BTW rather than add the input amount to each input why not just add a single operator at the end of the whole TX that verifies the fee amount (in satoshis) so something like OP_CHECKFEE <amount> (with the tx being invalid if the amount doesn't match the UTXO input amounts - output amounts)?

[grau]

The problem is not that it might sign an invalid transaction but that it signs a *valid* one which outputs say 1 BTC but includes a 99 BTC fee (assuming the UTXO was 100 BTC).

The offline device can show you that 1 BTC is going to be output but it cannot tell you anything about the change if it doesn't have the relevant information (which I believe that the Trezor doesn't have).

Or have I missed something obvious here?

You missed that the transaction hash contains the output value therefore Trezor can rehash the input transaction presented to check that its hash that is in the input.

So the approach is secure but expensive since you need the entire source transaction for the re-hash instead of just the value the output(s) the transaction spends. The source transaction might be arbitrarily large having lots of outputs that do not play any role in the to be signed transaction.

With this proposal the signing device would only need to know the value of the previous output, since even the output script could be implied by the key the device uses to sign. The signature and therefore the transaction would then be either valid with correct fee or invalid entirely.

[grau]

The script subsystem only requires the tx you are signing.

Not really. To create a valid signature you have to hash in the output script of the transaction outputs you are spending. Assuming you sign with the right key, you could even imply those output scripts without retrieving them. You can't responsibly do that know since you would not know the amount spent consequently the fee you spend.

Having the source transaction on hand helps and you can easily verify if it is the right source transaction by rehasing it and comparing the hash to the source in the transaction you sign. The source transaction can however be arbitrary large with outputs you do not care this is a problem for memory constrained hardware devices. In addition it means you need source transaction for offline (cold-wallet) signing.

The burden of retrieving the source transaction could be eliminated if the to be signed hash would contain the assumption on the output value you spend. Is the assumption correct, then you can create a valid transaction without seeing the input, no harm done if not, the signed transaction is just invalid.

[natb]

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.