Author

Topic: OP_CHECKFEE to allow offline tx signing to see tx fee (Read 730 times)

legendary
Activity: 1890
Merit: 1072
Ian Knowles - CIYAM Lead Developer
If you need to ask whether or not the code will be ignored maybe you just shouldn't do it

No worries - I'll just leave it to you guys that are in the "club". Wink
legendary
Activity: 1120
Merit: 1149
If you need to ask whether or not the code will be ignored maybe you just shouldn't do it - treat it as a good way to learn something more about Bitcoin, if it gets adopted down the road, great! But it probably won't be - at best the implementation will explore the problem for another implementation to learn from down the road.

re: hard-fork... "good way to learn" Smiley
legendary
Activity: 1890
Merit: 1072
Ian Knowles - CIYAM Lead Developer
If you think this is a good idea, you'll get more traction by writing an implementation.

Hint: it doesn't need a hard-fork.

Thanks for the reply - and I have no problem to write the code but more importantly "do you think it is a good idea"?

(writing code to just be ignored by the core devs is not one of my interests)

And I would be interested to know why it wouldn't require a hard fork also (I understand quite a bit about Bitcoin but am sure nowhere near as much as you do).
legendary
Activity: 1120
Merit: 1149
If you think this is a good idea, you'll get more traction by writing an implementation.

Hint: it doesn't need a hard-fork.
legendary
Activity: 1890
Merit: 1072
Ian Knowles - CIYAM Lead Developer
The idea is to add to the end of a tx an optional new op code OP_CHECKFEE plus an amount (in satoshis) for the fee the tx will pay.

This would allow an offline signing device to sign a tx with the signer knowing both the amount to be output (currently available from the raw tx) and the fee (currently not knowable without the relevant full UTXO information).

It would require a hard fork to properly implement (as the idea would be that if the amount in OP_CHECKFEE does not match the tx fee then the tx would be invalid) although it could initially be ignored (in terms of validation) until a certain date in the future.

The advantage is that you could create offline signing devices that need *zero* information from the blockchain (very useful if you want to use QR codes for 100% air-gapped offline txs).

Jump to: