This would make life SO MUCH easier for all hardware wallets and software wallets that don't have access to the full blockchain.
Bitcointalk discussion: https://bitcointalk.org/index.php?topic=181734.0 Bitcoin-dev discussion: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-January/007185.html
Other proposed exotic sighash types, including SIGHASH_WITHINPUTVALUE: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010759.html
I agree that it's complicated to a display a appropriate signing-verification (on a hardware wallet screen or similar) by just having the raw transaction. You only know which outputs are controller by the HWW and you cannot calculate the fees. An MITM attack could – in theory – make you pay insane fees and there is currently no way (with one of the current available hardware wallets [Ledger/Trezor/Keep-Key/etc.]) to avoid this possible attack.
Implementing something like SIGHASH_WITHINPUTVALUE (soft fork or hard fork version) is not the right way IMO. It's to invasive on the protocol level.
A hardware wallet always needs a controller software a.k.a. a watch-only-wallet. Maybe there are other ways of providing a prove to the HWW that can be used to verify the input amounts (=calculating the fees).
make you pay insane fees and there is currently no way (with one of the current available hardware wallets [Ledger/Trezor/Keep-Key/etc.]) to
Wrong. TREZOR does this from the beginning. But at the very high cost of streaming all prev-txs and confirming the input value is correct.
It's to invasive on the protocol level. A hardware wallet always needs a controller software a.k.a. a watch-only-wallet.
You are completely missing the big picture. Protocol has to evolve. Especially such immature protocol as Bitcoin. (As a homework: compare SMTP specs from 1982 and 2008).
Also the whole point of hardware wallets is that everything around is compromised and hardware wallet does not have to trust any outside element, because it can verify the provided info itself.
Wrong. TREZOR does this from the beginning
Thanks for the clarification.
As a homework: compare SMTP specs from 1982 and 2008
Agree that a protocol should evolve. But the reason why you can get this github response immediately – is – not at least, because SMTP was not indiscreet overloaded or over-evolved.
IIRC SIGHASH_WITHINPUTVALUE is controversial (at least I read concerns from @gmaxwell and @petertodd ) and the way how the protocol can evolve is certainly not by opening issues here. Consensus and P2P changes need a BIP first, broad discussions and support for it. Closing.
FWIW, for the sake of more effective communication: The effective ask (minimize data transferred to wallets for signing) here is quite reasonable and has been in many people's plans for a while. Elements Alpha tries out one formulation that accomplish it, though our experience there suggests a different would would be better.
I expect to see a comprehensive soft-fork CHECKSIG upgrade proposal forming within a couple months. (I would have expected earlier, but new discoveries and requirements have been turning up-- as well as other unfortunate distractions). So I think no one should take the fact that an issue here asking for that proposal on BCT (which I think is a very poor proposal) was turned away means nothing will be done on this; quite the opposite; and likely on a timeframe shorter than could be done for the proposal on BCT.
I expect to see a comprehensive soft-fork CHECKSIG upgrade proposal forming within a couple months.
Could you please point me to place where public discussion about this proposal is taking place? Thanks