On Wed, Aug 17, 2016 at 9:19 PM, Gregory Maxwell wrote: > On Thu, Aug 18, 2016 at 12:11 AM, Sergio Demian Lerner via bitcoin-dev > wrote: > > I think that we're not attacking the real source of the problem: that the > > witness data size is not signed. > > It's not possible to do that for the general case, since you may not > even know the witness size in advance (even for checksig's ECDSA, the > encoding is variable sized). > > That's why scripts can check a maximum witness size, and not necessarily an exact value. I think that is overly focusing on "someone might change the feerate", > yes that is an example of an undesirable witness tampering, but it's > not the only one. > > I don't think fees are the problem. There is another problem. Let me re-explain. If I send a transaction to an IoT device (say to an OpenDime or to the old Firmcoin), and the OpenDime must verify that the transaction has been mined (SPV verification), then it may expect the witness program to be of certain maximum size (an implementation-imposed limit). If a Miner modifies the witness size and makes it too large, then the device may not be able to accept the transaction and the bitcoins may be lost. Lost because the private key is in the device, and because the device cannot accept that cloned transaction, never ever. The same is true (although less strict) for side-chains and drive-chains: they may have certain restrictions on the size of transactions they accept to lock bitcoins. That's why I'm proposing that a transaction becomes INVALID if the witness size is higher than the expected size (by the sender).