Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Relax transaction size constraint for May 15 th, 2019 network upgrade. #260

Closed
wants to merge 2 commits into from

Conversation

Projects
None yet
5 participants
@sickpig
Copy link
Collaborator

sickpig commented Jan 17, 2019

No description provided.

@markblundeberg

This comment has been minimized.

Copy link
Collaborator

markblundeberg commented Jan 17, 2019

Expanding on a comment from the last fork discussion, for historical interest:

There have been 29000 transactions under 64 bytes so far:
https://blockchair.com/bitcoin-cash/transactions?q=size(..63)#

Only five have been 64 bytes exactly:
https://blockchair.com/bitcoin-cash/transactions?q=size(64)#

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.
https://blockchair.com/bitcoin-cash/transactions?q=size(65..99),is_coinbase(true)#

@Mengerian

This comment has been minimized.

Copy link
Contributor

Mengerian commented Jan 17, 2019

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.

This comment has been minimized.

Copy link
@jasonbcox

jasonbcox Jan 18, 2019

Collaborator

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.

This comment has been minimized.

Copy link
@markblundeberg

markblundeberg Jan 18, 2019

Collaborator

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?

This comment has been minimized.

Copy link
@Mengerian

Mengerian Jan 19, 2019

Contributor

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.

This comment has been minimized.

Copy link
@sickpig

sickpig Jan 22, 2019

Author Collaborator

@Mengerian fwiw I agree with you.

This comment has been minimized.

Copy link
@jasonbcox

This comment has been minimized.

Copy link
@zquestz

zquestz Jan 29, 2019

Contributor

I also agree the rule should simply be > 64 bytes.

This comment has been minimized.

Copy link
@Mengerian

Mengerian Jan 30, 2019

Contributor

@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.

@markblundeberg

This comment has been minimized.

Copy link
Collaborator

markblundeberg commented Jan 30, 2019

Another factoid: the absolute shortest possible economic coinbase would be 87 bytes:

  • scriptSig is 4 bytes long: PUSH3 <height>, for BIP34 compliance.
  • scriptPubKey is 23 bytes long P2SH: HASH160 PUSH20 <scripthash> EQUAL

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 PUSH4 <extranonce> (+1 byte). In recent years the shortest was 97 bytes which was P2PKH (+2) and had +8 bytes from extranonce.

@markblundeberg

This comment has been minimized.

Copy link
Collaborator

markblundeberg commented Jan 30, 2019

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:

  • Scriptsig could be as short as 9 bytes -- PUSH plus minimum length ECDSA signature.
  • ScriptPubKey is just one byte -- OP_RETURN

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.

@Mengerian

This comment has been minimized.

Copy link
Contributor

Mengerian commented Feb 28, 2019

This is now obsolete, this change did not it into the May Upgrade so I will remove the Pull request

@Mengerian Mengerian closed this Feb 28, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.