Bitcoin Forum
December 16, 2017, 04:05:48 AM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Soft fork to implement SIGHASH_WITHINPUTVALUE  (Read 621 times)
TierNolan
Legendary
*
Offline Offline

Activity: 1148


View Profile
August 30, 2015, 10:57:46 PM
 #1

SIGHASH_WITHINPUTVALUE is a hard fork that allows signing an output that is only valid if the output has a particular value.

This helps with offline signing.  The offline signing device/software can sign a transaction and be sure of the total value of coins being spent.

Under the current system, all inputs into a transaction must be provided, in full, in order to verify the input values.  In some cases (very low memory), it may even be O(N^2).

The risk is that a signer might sign a transaction that pays a large output to fee.  A transaction might spend a 100BTC output and only spend 1BTC of it.  The other 99 would be paid to fees and the offline signing tool would have no way of knowing this (without checking all the input transactions).

I suggest converting an OP_NOP into OP_INCREASEMAXFEE opcode. 

This maximum fee for a transaction is the sum of all such values.  If none of the inputs into the transaction have this opcode, then the maximum fee is infinite.

The opcode is only allowed in the scriptPubKey.

A P2SH address could be of the following form

Code:
[<some value> OP_INCREASEMAXFEE OP_DROP <public key> OP_CHECKSIG]

Most wallets could send to such addresses (assuming the can handle P2SH address as a destination).

This requires that users estimate what a reasonable fee would be when they create the transaction, but that shouldn't be a big problem.

A less complex version suggested in the original thread is use an OP_CHECKZEROFEEVERIFY opcode to force the transaction fee to zero and pay the actual fee to OP_TRUE.

The fee estimate could overestimate the actual fee, since the risk is reasonably small of corruption.  Worst case, you end up paying a 5X-10X the fee you were expecting.

With OP_INCREASEMAXFEE, that can still be used.  Do mining pools credit transactions that pay to OP_TRUE?

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
1513397148
Hero Member
*
Offline Offline

Posts: 1513397148

View Profile Personal Message (Offline)

Ignore
1513397148
Reply with quote  #2

1513397148
Report to moderator
1513397148
Hero Member
*
Offline Offline

Posts: 1513397148

View Profile Personal Message (Offline)

Ignore
1513397148
Reply with quote  #2

1513397148
Report to moderator
1513397148
Hero Member
*
Offline Offline

Posts: 1513397148

View Profile Personal Message (Offline)

Ignore
1513397148
Reply with quote  #2

1513397148
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1513397148
Hero Member
*
Offline Offline

Posts: 1513397148

View Profile Personal Message (Offline)

Ignore
1513397148
Reply with quote  #2

1513397148
Report to moderator
gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2366



View Profile
August 31, 2015, 07:07:06 AM
 #2

Ugh.  Thats pretty awful to fix in a txout what the maximum fee for that txout,  you can easily end up making inputs really annoying to spend in the future.

Please, there is no need for something like this. A simple new checksig operation is much more tidy improvement (e.g. like the one in elements alpha that includes the txin value under the hash), and one will be proposed once the current softfork backlog can be cleared.

That anyone ever suggested something like this as a hardfork was purely the result of confusion.

Bitcoin will not be compromised
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!