Topic: Bitcoin dev IRC meeting in layman's terms (2015-10-29) (Read 536 times)
This is a really good idea. I often when reading on Bitcoin forums, see people quoting entire logs of devs talking to each other. Since im not an experienced coder I can't understand half of what's being discussed. A lot of important information gets lost in translation in those logs and putting in in ELI5 (well not that exaggerated, let's just say laymans) is a good initiative.
Once again my attempt to summarize and explain the weekly bitcoin developer meeting in layman's terms.
Link to last weeks summarization
Disclaimer
Please bear in mind I'm not a developer and I'd have problems coding "hello world!", so some things might be incorrect or plain wrong.
Like any other write-up it likely contains personal biases, although I try to stay as neutral as I can.
There are no decisions being made in these meetings, so if I say "everyone agrees" this means everyone present in the meeting, that's not consensus, but since a fair amount of devs are present it's a good representation.
The dev IRC and mailinglist are for bitcoin development purposes. If you have not contributed actual code to a bitcoin-implementation, this is probably not the place you want to reach out to. There are many places to discuss things that the developers read, including this sub-reddit.
link to this week logs
Meeting minutes by meetbot
Meeting google doc
Main topics discussed where:
Upcoming softfork
Chain limits
Clang format
BIP68 and BIP112 implementations
Short topics/notes
The LevelDB topic was started but deferred till after the meeting as there are currently no plans to move to another database. However research and testing is encouraged. mcelrath volunteered to make a LMDB branch, jgarzik already has a sqlite branch.
Upcoming softfork
- background
CheckLockTimeVerify (CLTV) aka "how you thought nLockTime worked before you actually tried to use it" is a softfork scheduled for release at the end of October (ends up being early November).
- meeting comments
Check to see if there's anything that needs to be included in this release that's not already in. Luke-jr has a Pull-request open to add bugfixes.
Check to see if there's any coordination for the softfork in regards to other clients. btcd is ready for it, bitcoinj historically hasn't implemented any softforks.
- meeting conclusion
Release with only CLTV as softfork.
Chain limits
- background
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.
With the recent maleability attacks, anyone who made transactions going multiple layers deep would've already encountered huge problems doing this (beautifully explained in let's talk bitcoin #258 from 13:50 onwards)
Proposal and github link.
- meeting comments
25 as limit is still very high and could be lower.
Discussion on which statistics and measurements would be useful and relevant to this proposal.
- meeting conclusion
Morcos will do some extra measurements to back up the proposal.
Clang format
- background
Just like libconsensus this is something to tidy up the code, but more about the style and format of the code itself. Quoting part of a github comment by gmaxwell:
"Stylistic consistency has actual benefits; it aids newcomers in their contributions because it is easier for them to make sure their work is okay on styleistic grounds; though this may be offset by having to install some particular version of clang-format before they can get started. It eases review because the uniformity creates better expectations; but reformating makes looking at the history harder, which harms review. Good style choices (as opposed to merely consistent) have, at times, been shown to lower defect rates in software-- but there is not a universal opinion on what choices are good."
- meeting comments
Proposal a while ago was to clang-format file set Once done, maintain those files' formatting with automation.
Opinions diverge pretty hard. From let's not change anything for existing files to let's change the entire bitcoin repository.
Some behavior changes from one Clang version to another, which would require everyone to use the same version of clang format, which is burdensome.
- meeting conclusion
No conclusion.
BIP68 and BIP112 implementations
- background
BIP 68 Consensus-enforced transaction replacement signaled via sequence numbers , and current implementation.
BIP 112 CHECKSEQUENCEVERIFY, and current implementation.
In short: BIP 68 changes the meaning of the sequence number field to a relative locktime. BIP 112 makes that field accessible to the bitcoin scripting system.
- meeting comments
Concerns about the fact that the LockTime function skips non-existing inputs.
For review purposes btcdrak combined both pull-requests ( https://github.com/bitcoin/bitcoin/compare/master...btcdrak:sequenceandcsv )
- meeting conclusion
Both implementations should stay separate pull-requests.
No use in deploying BIP 112 before BIP 68.
Participants
gmaxwell Gregory Maxwell
dcousens Daniel Cousens
sipa Pieter Wuille
jgarzik Jeff Garzik
morcos Alex Morcos
Luke-Jr Luke Dashjr
wumpus Wladimir J. van der Laan
mcelrath Bob McElrath
jtimon Jorge Timón
jonasshnelli Jonas Schnelli
btcdrak btcdrak
petertodd Peter Todd
dstadulis Daniel Stadulis
dgenr8 Tom Harding
jeremyrubin Jeremy Rubin
warren Warren Togami
rusty Rusty Russell
sdaftuar Suhas Daftuar
Link to last weeks summarization
Disclaimer
Please bear in mind I'm not a developer and I'd have problems coding "hello world!", so some things might be incorrect or plain wrong.
Like any other write-up it likely contains personal biases, although I try to stay as neutral as I can.
There are no decisions being made in these meetings, so if I say "everyone agrees" this means everyone present in the meeting, that's not consensus, but since a fair amount of devs are present it's a good representation.
The dev IRC and mailinglist are for bitcoin development purposes. If you have not contributed actual code to a bitcoin-implementation, this is probably not the place you want to reach out to. There are many places to discuss things that the developers read, including this sub-reddit.
link to this week logs
Meeting minutes by meetbot
Meeting google doc
Main topics discussed where:
Upcoming softfork
Chain limits
Clang format
BIP68 and BIP112 implementations
Short topics/notes
The LevelDB topic was started but deferred till after the meeting as there are currently no plans to move to another database. However research and testing is encouraged. mcelrath volunteered to make a LMDB branch, jgarzik already has a sqlite branch.
Upcoming softfork
- background
CheckLockTimeVerify (CLTV) aka "how you thought nLockTime worked before you actually tried to use it" is a softfork scheduled for release at the end of October (ends up being early November).
- meeting comments
Check to see if there's anything that needs to be included in this release that's not already in. Luke-jr has a Pull-request open to add bugfixes.
Check to see if there's any coordination for the softfork in regards to other clients. btcd is ready for it, bitcoinj historically hasn't implemented any softforks.
- meeting conclusion
Release with only CLTV as softfork.
Chain limits
- background
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.
With the recent maleability attacks, anyone who made transactions going multiple layers deep would've already encountered huge problems doing this (beautifully explained in let's talk bitcoin #258 from 13:50 onwards)
Proposal and github link.
- meeting comments
25 as limit is still very high and could be lower.
Discussion on which statistics and measurements would be useful and relevant to this proposal.
- meeting conclusion
Morcos will do some extra measurements to back up the proposal.
Clang format
- background
Just like libconsensus this is something to tidy up the code, but more about the style and format of the code itself. Quoting part of a github comment by gmaxwell:
"Stylistic consistency has actual benefits; it aids newcomers in their contributions because it is easier for them to make sure their work is okay on styleistic grounds; though this may be offset by having to install some particular version of clang-format before they can get started. It eases review because the uniformity creates better expectations; but reformating makes looking at the history harder, which harms review. Good style choices (as opposed to merely consistent) have, at times, been shown to lower defect rates in software-- but there is not a universal opinion on what choices are good."
- meeting comments
Proposal a while ago was to clang-format file set Once done, maintain those files' formatting with automation.
Opinions diverge pretty hard. From let's not change anything for existing files to let's change the entire bitcoin repository.
Some behavior changes from one Clang version to another, which would require everyone to use the same version of clang format, which is burdensome.
- meeting conclusion
No conclusion.
BIP68 and BIP112 implementations
- background
BIP 68 Consensus-enforced transaction replacement signaled via sequence numbers , and current implementation.
BIP 112 CHECKSEQUENCEVERIFY, and current implementation.
In short: BIP 68 changes the meaning of the sequence number field to a relative locktime. BIP 112 makes that field accessible to the bitcoin scripting system.
- meeting comments
Concerns about the fact that the LockTime function skips non-existing inputs.
For review purposes btcdrak combined both pull-requests ( https://github.com/bitcoin/bitcoin/compare/master...btcdrak:sequenceandcsv )
- meeting conclusion
Both implementations should stay separate pull-requests.
No use in deploying BIP 112 before BIP 68.
Participants
gmaxwell Gregory Maxwell
dcousens Daniel Cousens
sipa Pieter Wuille
jgarzik Jeff Garzik
morcos Alex Morcos
Luke-Jr Luke Dashjr
wumpus Wladimir J. van der Laan
mcelrath Bob McElrath
jtimon Jorge Timón
jonasshnelli Jonas Schnelli
btcdrak btcdrak
petertodd Peter Todd
dstadulis Daniel Stadulis
dgenr8 Tom Harding
jeremyrubin Jeremy Rubin
warren Warren Togami
rusty Rusty Russell
sdaftuar Suhas Daftuar
Jump to: