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.
Topic: Soft fork to implement SIGHASH_WITHINPUTVALUE (Read 742 times)
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
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?
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:
[OP_INCREASEMAXFEE OP_DROP 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?
Jump to: