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

Peter Todd

legendary

Activity: 1120

Merit: 1152

Quote from: etotheipi on July 04, 2013, 02:00:13 PM

Oh, I understood that part, but I forgot about the part where they don't have to provide a large signature in order to spend it to themselves. And I missed the part that they can mine all of them in a single transaction and produce only one extra output for themself. Okay, it's kind of cool.

Basically you're adding 1+1+8=10 bytes for the OP_TRUE txout and 36+4+1=41 bytes to spend it, or 51 extra bytes in total per transaction. That's not great - it's roughly a 25% overhead for typical transactions - but it's not infeasible either.

etotheipi

legendary

Activity: 1428

Merit: 1093

Core Armory Developer

Quote from: TierNolan on July 04, 2013, 01:57:36 PM

Quote from: etotheipi on July 04, 2013, 01:08:43 PM

Although it's a neat idea, it underestimates the blockchain bloat that comes with it. If this became standard, and we had 1000 tx per block, that's potentially 1,000 extra UTXOs we wouldn't otherwise have. Adding 1000 UTXOs per block would be pretty rough, and the total blockchain size would increase pretty dramatically in an effort to spend all those.

No, OP_TRUE can be spent by anyone. It implicitly means "pay to miner". Ofc, some miners might not detect them and so it becomes pay to the first miner who finds them.

Oh, I understood that part, but I forgot about the part where they don't have to provide a large signature in order to spend it to themselves. And I missed the part that they can mine all of them in a single transaction and produce only one extra output for themself. Okay, it's kind of cool.

TierNolan

legendary

Activity: 1232

Merit: 1094

Quote from: etotheipi on July 04, 2013, 01:08:43 PM

Although it's a neat idea, it underestimates the blockchain bloat that comes with it. If this became standard, and we had 1000 tx per block, that's potentially 1,000 extra UTXOs we wouldn't otherwise have. Adding 1000 UTXOs per block would be pretty rough, and the total blockchain size would increase pretty dramatically in an effort to spend all those.

No, OP_TRUE can be spent by anyone. It implicitly means "pay to miner". Ofc, some miners might not detect them and so it becomes pay to the first miner who finds them.

etotheipi

legendary

Activity: 1428

Merit: 1093

Core Armory Developer

Quote from: jl2012 on July 04, 2013, 12:34:23 PM

I think there is another way to do this, but still need a soft-fork:

1. Define a new transaction version: valid only if total input amount = total output amount

2. Miner fee is sent to OP_TRUE

3. The rest will follow https://gist.github.com/gavinandresen/2355445

This has 2 bonus effect:

a. People using this type of transaction will not accidentally send a huge amount of transaction fee

b. In multi-parties contracts, people can define fee explicitly

The drawback is that would cost extra block space, so the transaction fee will be higher in long run

Comments?

Although it's a neat idea, it underestimates the blockchain bloat that comes with it. If this became standard, and we had 1000 tx per block, that's potentially 1,000 extra UTXOs we wouldn't otherwise have. Adding 1000 UTXOs per block would be pretty rough, and the total blockchain size would increase pretty dramatically in an effort to spend all those.

It seems that you would end up with much more frequent "double-spends", for the same reason coinbase transactions require 100 blocks to become valid. Miners could spend those fees immediately, meaning that orphaned blocks could lead to countless "accidental" double-spends.

jl2012

legendary

Activity: 1792

Merit: 1111

I think there is another way to do this, but still need a soft-fork:

1. Define a new transaction version: valid only if total input amount = total output amount

2. Miner fee is sent to OP_TRUE

3. The rest will follow https://gist.github.com/gavinandresen/2355445

This has 2 bonus effect:

a. People using this type of transaction will not accidentally send a huge amount of transaction fee

b. In multi-parties contracts, people can define fee explicitly

The drawback is that would cost extra block space, so the transaction fee will be higher in long run

Comments?

meowmeowbrowncow

sr. member

Activity: 322

Merit: 250

Do it™

etotheipi

legendary

Activity: 1428

Merit: 1093

Core Armory Developer

Quote from: TierNolan on April 30, 2013, 06:16:59 PM

Quote

It is (or should be) uncontroversial, because it adds an optional, extra restriction to tx validity.

Technically, that makes it a soft fork. What happens if undefined bits in the sighash field are set to 1?

I meant, uncontroversial if you've already accepted that there will be a soft/hard fork. I think inducing a fork just to introduce this would be pretty controversial.

By the way, I accidentally glossed over your soft-fork idea. I like it. But I think more than changing the validation rules, you would require all nodes to start accepting and using that script type (which would require a new address format, I'm sure). And if they use it before it's a valid rule, people could inject incorrect values just for fun. I guess, after the miners all agreed and you reached threshold, you would hardcode the starting height.

One of the nice benefits of the SIGHASH_WITHINPUTVALUE code, is that it doesn't depend at all on the people sending you coins. You are completely in control of whether you are using it. It works will all prior UTXOs in the blockchain, and doesn't require changing any block parsers, etc.

TierNolan

legendary

Activity: 1232

Merit: 1094

Quote from: etotheipi on April 30, 2013, 05:01:33 PM

Yeah, Armory would do it in a heartbeat.

I mean you could include the template without any official changes to the protocol.

You could have a "send to cold store" transaction using the template I suggested.

It would have to send the transaction direct to a miner who will accept non-standard transactions though.

The signing algorithm sees the spend part of the script. The scriptPubKey requires that the last thing the spending tx pushes onto the stack is the value of the TXO.

You cannot spend that output without including the info in the scriptSig.

Quote

It is (or should be) uncontroversial, because it adds an optional, extra restriction to tx validity.

Technically, that makes it a soft fork. What happens if undefined bits in the sighash field are set to 1?

allten

sr. member

Activity: 455

Merit: 250

You Don't Bitcoin 'till You Mint Coin

Quote from: etotheipi on April 30, 2013, 05:01:33 PM

..I'm not sure this is worthy of it's own fork, even if it's popular. I think it makes a perfect add-on to some other update that would cause a fork..

You are probably right.
Looks like I'll have to be patient. Can't wait though.
Thanks again!

etotheipi

legendary

Activity: 1428

Merit: 1093

Core Armory Developer

Quote from: TierNolan on April 30, 2013, 03:07:21 PM

Armory could be setup to format all transactions that way immediately. If users use armory to send coins to their private store, then they don't need so much data when spending.

Yeah, Armory would do it in a heartbeat. But as I said, I'm not sure this is worthy of it's own fork, even if it's popular. I think it makes a perfect add-on to some other update that would cause a fork, because it is:

(1) Simple
(2) Uncontroversial
(3) Useful, but far from critical

It is (or should be) uncontroversial, because it adds an optional, extra restriction to tx validity.

TierNolan

legendary

Activity: 1232

Merit: 1094

This is a hard fork.

Using the Pay to Script Hash (/P2SH/) update as a precedent, you could implement it as a script template and therefore be a soft(ish) fork.

Something like

A new standard transaction is defined

scriptPubKey: [VarInt:value] OP_EQUAL_VERIFY OP_DUP OP_HASH160 [hash160(public key)] OP_EQUALVERIFY OP_CHECKSIG

scriptSig: [/INVAL/] [signature] [public key] [VarInt:value]

This script is considered standard if
- The value of the transaction output being spent is equal to the stated value

The script is considered validated if
- It is valid under the current rules
- The value of the transaction output being spent is equal to the stated value

With immediate effect
- Miners which agree should add /INVAL/ to their coinbase
- Miners which agree should not include transactions which fail these rules in blocks
- Nodes which agree should relay these transactions as standard

Formal acceptance
- Change accepted if included in 550 of the 1000 blocks from Block N to Block N + 999
-- If accepted, miners should reject blocks which contain invalid transactions

---------------------------

Armory could be setup to format all transactions that way immediately. If users use armory to send coins to their private store, then they don't need so much data when spending.

allten

sr. member

Activity: 455

Merit: 250

You Don't Bitcoin 'till You Mint Coin

So, could we get this post transformed into a BIP with a strategy for implementation?
If I understand correctly, Gavin has already laid the ground work for changes such as
these to be integrated into the Bitcoin protocol.

Thanks to the OP for getting this out there.

etotheipi

legendary

Activity: 1428

Merit: 1093

Core Armory Developer

Quote from: gmaxwell on April 29, 2013, 09:18:23 PM

Quote from: etotheipi on April 29, 2013, 05:31:54 PM

If we're going to be implementing something that is "latent-now-but-required-in-12-months" then this should be seriously considered.

Okay, a little confusion on my part then. Whats happening in couple weeks isn't the starting countdown for a hardfork, it's the required end date. So I thought you were proposing this be pulled into that. I think the sighash with input value seems pretty inelegant. Instead I'd just assume it would be a field external to the script for each input.

I knew it was a longshot to even consider it in the near future, but I wanted to get it out there, anyway. And it turns out there's even more support for it than I expected. So maybe there'll be a way to fit it in, in the future. I guess if it is an implemented-but-not-enabled-for-X-months feature, there's no reason it has to be related to this hardfork.

I think the solution is perfectly elegant. I mean, putting it in the transaction serialization would've been a good choice, but doing it this way totally achieves its goal while being fairly non-disruptive -- no one has to rewrite their blockchain parser to implement this. They just add a new SIGHASH code and say it's disabled until date X. And you save the "unnecessary" 8 bytes in the input (meh).

gmaxwell

staff

Activity: 4284

Merit: 8808

Quote from: etotheipi on April 29, 2013, 05:31:54 PM

If we're going to be implementing something that is "latent-now-but-required-in-12-months" then this should be seriously considered.

Okay, a little confusion on my part then. Whats happening in couple weeks isn't the starting countdown for a hardfork, it's the required end date. So I thought you were proposing this be pulled into that. I think the sighash with input value seems pretty inelegant. Instead I'd just assume it would be a field external to the script for each input.

allten

sr. member

Activity: 455

Merit: 250

You Don't Bitcoin 'till You Mint Coin

I really like this..... a lot!
This is how I assumed it worked before getting into hardware development, but what a nasty surprise.

Does anyone else see any downsides? Other than it would have to be rushed to fit it in with this planned hard fork.

Really need some core developers to come out in full support of this right away.

etotheipi

legendary

Activity: 1428

Merit: 1093

Core Armory Developer

Quote from: gmaxwell on April 29, 2013, 05:23:14 PM

You're going to have to work awful hard to convince me that hashing data on the fly as it comes in and storing a single integer out of the middle is so insanely burdensome that it's worth the considerable risk of an incompatible change to the bitcoin protocol, requiring upgrading hundreds of thousands of machines.. etc.

It's certainly not happening in two weeks.

I wasn't recommending this as worthy of its own hardfork. But it's a pretty darned simple and useful modification if we're planning to make incompatible, hard-forking changes anyway. If we're going to be implementing something that is "latent-now-but-required-in-12-months" then this should be seriously considered. The complexity of the process is not the only reason, it's also about the bandwidth. The less data there is to transfer across a channel, the more secure options you have to construct that channel. Right now, if you're going to make an offline signer, you have to accommodate many megabytes going across that channel, even if the vast majority of transactions don't require it. By implementing this, you also leave the transaction sizes up to the user, not the people that sent him coins.

gmaxwell

staff

Activity: 4284

Merit: 8808

You're going to have to work awful hard to convince me that hashing data on the fly as it comes in and storing a single integer out of the middle is so insanely burdensome that it's worth the considerable risk of an incompatible change to the bitcoin protocol, requiring upgrading hundreds of thousands of machines.. etc.

It's certainly not happening in two weeks.

drazvan

full member

Activity: 191

Merit: 100

Quote from: etotheipi on April 29, 2013, 03:49:24 PM

It seems a bit excessive to bring in an extra piece of hardware to try solve this problem. Not to mention there's too many ways for this to go wrong: the compromised system could exploit the presence of the smartcard when you do a legitimate transaction, and pre-sign inputs that are likely to be used on future transactions, etc.

I recognize you're proposing workarounds to the fact that SIGHASH_WITHINPUTVALUE is not implemented. But I'd much rather require supporting-transactions until something like this new SIGHASH can be implemented. Adding extra public keys and authentication of that sort to the offline device is considerably less than ideal.

I'm not sure I understand what you mean, all the smartcard does is take a full transaction as input, check its signatures, then return a list of outputs and their value, signed with an internal private key (for simplicity, it could even be an HMAC using a shared key between the smartcard and the offline device). As long as you feed it valid transactions, it will happily check them for you and "certify" the value of the outputs. It essentially does the same thing you do on your offline Armory machine, but do it in a secure fashion as soon as the transaction is received by the online machine.

You are correct though, your proposal would take care of this at the protocol level. How long do you estimate it will take for all Bitcoin clients to start using the new protocol (if I understand correctly, payments sent without this flag would be unusable by the offline wallet - or they would require you to fallback to sending the transaction along, just like you do now, correct?).

etotheipi

legendary

Activity: 1428

Merit: 1093

Core Armory Developer

Quote from: drazvan on April 29, 2013, 03:41:56 PM

Quote from: btchip on April 21, 2013, 10:44:21 AM

FYI, the way I deal with this issue today (specification update pending), to make things easier :

- A new "trusted input" type is added. A trusted input is : transaction hash + index (prevout) / amount / signature of the previous data (using a key known only by the device)
- The device can generate a trusted input from a transaction output, by parsing a transaction, at any time (so it can be done in a batch before actually using it)
- When creating a new transaction, prevout is replaced by the trusted input.

Another idea would be to have a separate smartcard device that is plugged into an online machine and only generates trusted inputs from outputs (just like you do now). It signs them with its private key and your offline device knows the public key. Your offline device could require that all inputs are trusted inputs, without ever being online.

This way, if the online computer is compromised, it still can't lie to the offline computer about the value of an input - the connected smartcard verifies the transaction before certifying the value of its outputs.

It seems a bit excessive to bring in an extra piece of hardware to try solve this problem. Not to mention there's too many ways for this to go wrong: the compromised system could exploit the presence of the smartcard when you do a legitimate transaction, and pre-sign inputs that are likely to be used on future transactions, etc.

I recognize you're proposing workarounds to the fact that SIGHASH_WITHINPUTVALUE is not implemented. But I'd much rather require supporting-transactions until something like this new SIGHASH can be implemented. Adding extra public keys and authentication of that sort to the offline device is considerably less than ideal.

drazvan

full member

Activity: 191

Merit: 100

Quote from: btchip on April 21, 2013, 10:44:21 AM

FYI, the way I deal with this issue today (specification update pending), to make things easier :

- A new "trusted input" type is added. A trusted input is : transaction hash + index (prevout) / amount / signature of the previous data (using a key known only by the device)
- The device can generate a trusted input from a transaction output, by parsing a transaction, at any time (so it can be done in a batch before actually using it)
- When creating a new transaction, prevout is replaced by the trusted input.

Another idea would be to have a separate smartcard device that is plugged into an online machine and only generates trusted inputs from outputs (just like you do now). It signs them with its private key and your offline device knows the public key. Your offline device could require that all inputs are trusted inputs, without ever being online.

This way, if the online computer is compromised, it still can't lie to the offline computer about the value of an input - the connected smartcard verifies the transaction before certifying the value of its outputs.

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