SIGHASH_WITHINPUTVALUE: Super-lightweight HW wallets and offline data - page 2.

Peter Todd

legendary

Activity: 1120

Merit: 1150

Quote from: etotheipi on November 22, 2013, 01:47:13 PM

Quote from: Peter Todd on November 22, 2013, 01:33:07 PM

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

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.

CIYAM

legendary

Activity: 1890

Merit: 1078

Ian Knowles - CIYAM Lead Developer

I have started a new topic here: https://bitcointalksearch.org/topic/opcheckfee-to-allow-offline-tx-signing-to-see-tx-fee-343234 as I don't think my idea is going to be considered in this topic.

justusranvier

legendary

Activity: 1400

Merit: 1009

Quote from: CIYAM on November 22, 2013, 01:34:17 PM

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.

etotheipi

legendary

Activity: 1428

Merit: 1093

Core Armory Developer

Quote from: Peter Todd on November 22, 2013, 01:33:07 PM

Quote from: etotheipi on November 22, 2013, 01:27:32 PM

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.

CIYAM

legendary

Activity: 1890

Merit: 1078

Ian Knowles - CIYAM Lead Developer

I mentioned the idea of using an OP_CHECKFEE 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.

Peter Todd

legendary

Activity: 1120

Merit: 1150

Quote from: etotheipi on November 22, 2013, 01:27:32 PM

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.

etotheipi

legendary

Activity: 1428

Merit: 1093

Core Armory Developer

Quote from: natb on November 22, 2013, 01:13:42 PM

Quote from: Peter Todd on November 22, 2013, 04:08:04 AM

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?

natb

newbie

Activity: 28

Merit: 12

Quote from: Peter Todd on November 22, 2013, 04:08:04 AM

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.

grau

hero member

Activity: 836

Merit: 1021

bits of proof

Quote from: genjix on November 21, 2013, 09:54:31 PM

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.

grau

hero member

Activity: 836

Merit: 1021

bits of proof

Quote from: CIYAM on November 22, 2013, 04:38:24 AM

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.

CIYAM

legendary

Activity: 1890

Merit: 1078

Ian Knowles - CIYAM Lead Developer

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 (with the tx being invalid if the amount doesn't match the UTXO input amounts - output amounts)?

Peter Todd

legendary

Activity: 1120

Merit: 1150

Quote from: CIYAM on November 22, 2013, 04:38:24 AM

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

legendary

Activity: 1890

Merit: 1078

Ian Knowles - CIYAM Lead Developer

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

legendary

Activity: 1120

Merit: 1150

Quote from: natb on November 22, 2013, 02:33:57 AM

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.

natb

newbie

Activity: 28

Merit: 12

Quote from: genjix on November 21, 2013, 09:54:31 PM

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.

genjix

legendary

Activity: 1232

Merit: 1076

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.

TierNolan

legendary

Activity: 1232

Merit: 1084

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.

natb

newbie

Activity: 28

Merit: 12

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.

etotheipi

legendary

Activity: 1428

Merit: 1093

Core Armory Developer

Quote from: genjix on November 21, 2013, 11:58:15 AM

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.

grau

hero member

Activity: 836

Merit: 1021

bits of proof

Quote from: genjix on November 21, 2013, 11:58:15 AM

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.

Topic: SIGHASH_WITHINPUTVALUE: Super-lightweight HW wallets and offline data - page 2. (Read 9834 times)