2 SHARES Reddit Facebook Twitter Google

Bitcoin Development Discussion for the week ending October 10, 2015

Main topics discussed this week were:

Mempool limiting: chain limits

Low-S change

CLTV & CSV review

Creation of bitcoin discuss mailing list

Off-topic but important notice

This issue https://github.com/feross/buffer/pull/81 has made most JS bitcoin software vulnerable to generating incorrect public keys. “This is an ecosystem threat with the potential to cause millions of dollars in losses that needs higher visibility; though it’s not a bitcoin core/bitcoin network issue. Common, critical, JS code is broken that may cause the generation of incorrect pubkeys (among other issues). Anyone who cares for a JS implementation should read that PR.”

Mempool limiting: chain limits

– background

(c/p from last week)

Chain in this context means connected transactions. When you send a transaction that depends on another transaction that has yet to be confirmed we talk about a chain of transactions. Miners ideally take the whole chain into account instead of just every single transaction (although that’s not widely implemented afaik).

So while a single transaction might not have a sufficient fee, a depending transaction could have a high enough fee to make it worthwhile to mine both. This is commonly known as child-pays-for-parent. Since you can make these chains very big it’s possible to clog up the mempool this way. The first unconfirmed transaction is called the ancestor and the transactions depending on it the descendants. The total amount of transactions is referred to as “packages”.

– since last week

As said in “Chain limits” last week Morcos did write a proposal about lowering the default limits for transaction-chains. 2 use cases came up which are currently in use or happened before.

As example: someone buys bitcoin from a website and can spend those bitcoin. in the marketplace of the same website without waiting for confirmation in order to improve the bitcoin user-experience. This leaves a sequential transaction chain. They don’t need to chain more than 5 transactions deep for this, and it falls within the proposed limits. What’s not within the proposed limits is the chain of � 100 transactions a company had during the spam-attacks.

These where simply increased activities by end-users while not enough UTXO’s where available (3 to be precise)(UTXO: unspent transaction output, an output that can be used as input for a new transaction). Notably this is with the best practices of using confirmed transactions first.

Ways this can be solved from the company’s end is to have more UTXO’s available before hand, bundling transactions (which requires delaying customer’s request) or using replace-by-fee to add payees (which saves blockchain space, is cheaper in fees and gets transactions through quicker, but is not widely deployed by miners atm). Bear in mind these proposals are for default values for the memorypool, not in any way hard limits.

– meeting comments

Sense of urgency. Quoting sipa: “my mempool is 2.5G… we better get some solution!” Current attack analysis assumes child-pays-for-parent mining, it should probably be done again without. Higher limits on number of transactions increase attack-vectors.

Proposed number of transactions gets some push-back, total size limit not. Mixing default values (for example having a 50% of a 10/10 limit and 50% of a 100/100 limit) wastes bandwidth while there are too many factors that limit utility of long chains as well. 25 transaction limit ought to be enough for everyone (for now).

– meeting conclusion

Review & test “Limit mempool by throwing away the cheapest txn and setting min relay fee to it” https://github.com/bitcoin/bitcoin/pull/6722

Provide support for “Lower default limits for tx chains” https://github.com/bitcoin/bitcoin/pull/6771 aka convince people 25 should be enough.

Low-S change

– background

This is in regards to the recent malleability attack. Which is caused by a value ‘S’ in the ECDSA signature which can be 2 values, a high and low value and still be valid. Resulting in different transaction id’s. More info:

http://blog.coinkite.com/post/130318407326/ongoing-bitcoin-malleability-attack-low-s-high

A solution for this is to require nodes to have the “low-s” encoding for signatures. Downside is that it will block most transactions made by sufficiently out of date software (+/- pre-march 2014). This does not replace the need for BIP62, it only eliminates the cheap DOS attack.

– meeting comments

95% of transactions already confirm to this, and more fixes have been applied since. BlueMatt has a node which several people are running that auto-malleates to low-s transactions.

Questions whether we release it ASAP or wait for the next release and get it to a couple of miners in the meantime (possibly with auto-lowS-malleating)

– meeting conclusion

Contact miners about “Test LowS in standardness, removes nuisance malleability vector” https://github.com/bitcoin/bitcoin/pull/6769

Release scheduled for the end of the month, together with likely check-lock-time-verify and possibly check-sequence-verify.

CLTV & CSV backport review

– background

CLTV: checkLockTimeVerify

CSV: checkSequenceVerify

Both new time-related OP-codes.

Been discussed heavily last week.

– meeting comments

CSV doesn’t seem ready enough for release later this month. There’s no clarity on how things look when all 3 time related pull-requests are merged.

There’s a number of people still reviewing the pull-requests. Uncertainty and confusion about whether the semantics are final or not (in regards to using bits from nSequence). nSequence are 4 bytes intended for sequencing time-locked transactions, but this never got used.

Now these bytes are being repurposed for a mixture of things. Currently the plan is: ” bits 0..15 are the relative locktime, bit 30 determines units (0: height, 1: time w/ 512s granularity), and bit 31 toggles BIP 68 (0: on, 1: off). bits 16..29 are masked off and can take any value.”

– meeting conclusion

Clarification from maaku regarding nSequence for BIP68. (after the meeting he explained he was waiting for opinions, but not enough people seemed to know the issue at hand.)

Continue review of pull requests 6312: https://github.com/bitcoin/bitcoin/pull/6312, 6564: https://github.com/bitcoin/bitcoin/pull/6564 and 6566: https://github.com/bitcoin/bitcoin/pull/6566

Creation of bitcoin discuss mailing list

– background

The bitcoin-dev mailing list is intended for technical discussions only. There’s things that don’t belong there but need to be discussed anyway. Now this is done in bitcoin-dev, but the volume of this is getting too big.

There’s recently also an influx of really inappropriate posts, level kindergarden� https://www.mail-archive.com/bitcoin-dev@lists.linuxfoundation.org/msg02539.html.

– meeting comments

No clarity about who are the moderators. Next week there will be a bitcoin-discuss list created. Decisions are needed as to who’ll become the moderators for that and bitcoin-dev. Decisions are needed as to what will be the list and moderation policies.

– meeting conclusion

The bitcoin-discuss list will be created as well as a simple website listing all the lists and corresponding policies.

A meeting is scheduled on monday to discuss the moderation and policies of said lists.

Participants

morcos Alex Morcos

gmaxwell Gregory Maxwell

wumpus Wladimir J. van der Laan

sipa Pieter Wuille

BlueMatt Matt Corallo

btcdrak btcdrak

petertodd Peter Todd

warren Warren Togami

phantomcircuit Patrick Strateman

dstadulis Daniel Stadulis

GreenIsMyPepper ?? Jospeh Poon ??

bsm117532 Bob McElrath

Reprinted from bitcoin-dev Digest, Vol 5, issue 38 thanks to G1lius Caesar <g1liusbitcoin@gmail.com> for the summary! You can join the bitcoin-dev mailing list at https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev