Bitcoin Forum
May 04, 2024, 01:05:22 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Bitcoin dev IRC meeting in layman's terms (2015-11-26)  (Read 316 times)
G1lius (OP)
Newbie
*
Offline Offline

Activity: 14
Merit: 4


View Profile
November 30, 2015, 04:23:40 PM
 #1

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


link to this week logs 
Meeting minutes by meetbot 


Main topics discussed where: 
 
CLTV activation 
BIP68/BIP112 implementation 
Replace-by-fee


Short topics/notes 

It was an American holiday (thanksgiving), so there weren't a lot of people in the meeting, which started later as well.


Personal note: My weekly posts are being read by more people than I ever anticipated and people are expecting these to come weekly.   
Next year Mid-February I'll be on vacation for a month, so that's 4 or 5 meetings I won't be able to do.   
If there's anyone who's up for the challenge to take over during those weeks (or maybe just 1 week and share the load with others) feel free to pm me.   
I'm announcing well in advance, so there's more chance to find someone and to not make this a last minute thing.   
I'd prefer someone who doesn't work in the bitcoin space (coding), as I much rather have people work on the future of money instead of enlightening us noobs Smiley



CLTV activation

- background 

CheckLockTimeVerify (CLTV) aka "how you thought nLockTime worked before you actually tried to use it" aka OP_HODL.

- meeting comments

It's plausible the CLTV softfork will activate within just a few weeks, as everyone but a few big miners have adopted it. 
About 20% of the nodes currently run CLTV-supporting versions. The negative effect of not upgrading is a degraded validation (SPV). 


- meeting conclusion 

Do a social media reminder to upgrade nodes to v0.11.2/v0.10.4

BIP68/BIP112 implementation

- 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

The BIP68 and BIP112 texts have been updated to match the implementations. 
There's been a call and discussion to rename CHECKSEQUENCEVERIFY on the mailinglist
btcdrak wants both pull-requests to be merged soon, others feel more hesitant as people seem to only recently started looking at it seriously. 

- meeting conclusion

Merge updated BIP-texts

Replace-by-fee

- background

Currently when a node sees a transaction that spends the same output it ignores it. With replace-by-fee it replaces the current transaction in the mempool if it has a higher fee.   
This allows for things like spending "stuck" transactions, adding more recipients to a transaction in order to prevent chaining, etc. 

Since there are people that accept 0-confirmation transactions and this would make it extremely easy to double spend them, this is made opt-in. 
The sender can choose to opt-in to replace-by-fee by changing the nSequence field of all inputs.   
This is a mempool policy for the upcoming 0.12 release.
There's a good FAQ-ish post on reddit about it.

- meeting comments

petertodd ran some tests with the mempool limiter turned way down and saw no issues.   
It should be technically easy to merge first-seen-safe and full-unconditional as options if there's people who want to write it. 



- meeting conclusion

test and ACK replace-by-fee (Has been merged meanwhile).


Participants

Code:
    btcdrak      btcdrak  
    petertodd    Peter Todd 
    Luke-Jr      Luke Dashjr 
    CodeShark    Eric Lombrozo 
    sipa         Pieter Wuille 
    jtimon       Jorge Timón 



Comic relief


Code:
    19:17	btcdrak		wumpus: so no meeting today then?  
    19:17 CodeShark btcdrak: so no wumpus today then? :) 
    19:17 petertodd btcdrak: since when do you listen to authority? :P 

    19:22 CodeShark is there a quorum? or can we meet anyhow? :) 
    19:22 petertodd CodeShark: I'm in a mcdonalds right now, working on increasing my influence, as measured by mass... 
    19:22 petertodd CodeShark: so yes 

    19:49 btcdrak ### 10 minutes left. are there any other topic suggestions? 
    19:50 petertodd btcdrak: rbf 
    19:50 btcdrak #topic RBF   
    19:51 CodeShark anyone have a topic that pays a higher fee? :)   
    19:51 Luke-Jr this fee is too low, I'm leaving early!     

    19:24 btcdrak #meetingstart 
    19:24 btcdrak #startmeeting 
    19:24 lightningbot Meeting started Thu Nov 26 19:24:40 2015 UTC. The chair is btcdrak. Information about MeetBot at http://wiki.debian.org/MeetBot.

    20:00 btcdrak #endmeeting 
    20:00 btcdrak #meetingend 
    20:00 btcdrak oh ffs, not this problem again 
    20:00 lightningbot Meeting ended Thu Nov 26 20:00:24 2015 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!