Relax transaction size constraint for May 15 th, 2019 network upgrade. #260
Conversation
|
Expanding on a comment from the last fork discussion, for historical interest: There have been 29000 transactions under 64 bytes so far: Only five have been 64 bytes exactly: There have been 10 coinbases under 100 bytes since the BTC/BCH fork, interestingly they clustered into the few months just before the Nov 2018 fork. Note that such a short coinbase means an 'unknown' miner hence why it's quite rare. |
|
Looks good Andrea, I support the change in concept. A small nit: As part of this PR, would be good to add a link to this document from https://github.com/bitcoincashorg/bitcoincash.org/blob/master/spec/20190515-may-upgrade.md |
| The constraint was introduced to protects against a [Merkle tree vulnerability](https://bitslog.wordpress.com/2018/06/09/leaf-node-weakness-in-bitcoin-merkle-tree-design/) | ||
| that allows attackers to spoof transactions against SPV wallets. | ||
|
|
||
| This is a proposal to relax such constraints so that a transaction should be considered invalid if its size is equal to 64 bytes. |
There was a problem hiding this comment.
I think relaxing to 80-bytes to reduce risk to mining pools (since there were a few coinbase txs < 100-bytes) is the way to go here. I still don't see a legitimate use case for a very small tx with no signature that absolutely must be that small. Txs without a signature that still want to carry out these experiments can pad using OP_RETURN.
There was a problem hiding this comment.
If we can do 80, why not 65? 80 seems totally arbitrary, I don't know why you didn't say 70 or 90 or 65. Is there a problem with 79 byte txes?
There was a problem hiding this comment.
Yeah, I think that the "use-case" argument doesn't really apply in this situation. It makes sense to ask for use cases when adding complexity to the system, or adding in something with specific functionality. But in this case it is equally trivial to restrict *= 64 bytes, or <80 or <100 bytes.
The only rule that logically makes sense is to just disallow transactions that are exactly 64 bytes in size.
There was a problem hiding this comment.
@Mengerian fwiw I agree with you.
There was a problem hiding this comment.
From a quick search, smallest standard 1-in-1-out tx is roughly 85 bytes: https://blockchair.com/bitcoin-cash/transaction/d5a2d9a967f46484d1b71775d0a19a1c6d21cf0d01b9f2c2433a3aff49bc9f2f
There was a problem hiding this comment.
I also agree the rule should simply be > 64 bytes.
There was a problem hiding this comment.
@jasonbcox Regarding use-cases, there is one potential use-case for 66-byte transactions decribed here:
https://gist.github.com/markblundeberg/34d128ddcd95829070e5d8686d44b47a
Although it's not a very important use, I think that the bar should be fairly low in this case... Given the the risk of allowing small transaction is negligible (Eg. Bitcoin has no size constraint through it's entire history, and Bitcoin Cash until a couple months ago). The 64-byte problem is very specific, and there's no reason to think that any other sizes would be a problem.
Philosophically, while we are designing the system to optimize for Cash use-case, we should also allow maximum flexibility on how the system is used, pre-supposing as little as possible. There may be other possible uses for small transactions that we haven't thought of. This particular use, even if it's not very important by itself, is an example that it's reasonable to imagine that such uses could exist.
|
Another factoid: the absolute shortest possible economic coinbase would be 87 bytes:
In practice there is going to be an extranonce in the coinbase so we never see coinbases this short. The shortest-ever actual coinbase was 90 bytes, and that happened pre-BIP34, which used P2PKH (+2 bytes) and lacked height but did have |
|
For non-coinbase economic txes (economic means it must have an owner, i.e., it must have CHECKSIG), the shortest would be spending from P2PK (say, some dust) to donate to miners:
Thus an economic tx could be 70 bytes long. In reality though, it is very hard to get an ECDSA signature shorter than 50 bytes (even using the k=1/2 trick), so the shortest we could expect to reasonably see is ~110 bytes. |
|
This is now obsolete, this change did not it into the May Upgrade so I will remove the Pull request |
No description provided.