Re: [Bitcoin-development] Relative CHECKLOCKTIMEVERIFY (was CLTV proposal)

2015-05-04 Thread Jorge Timón
What I was describing was an attempt to fix a similar proposal by Mark Friedenbach, but it didn't needed fixing: I was simply misunderstanding it. Mark's RCLTV is completely reorg safe, so there's no need for the 100 block restriction. It also keeps the script validation independent from the utxo.

Re: [Bitcoin-development] Relative CHECKLOCKTIMEVERIFY (was CLTV proposal)

2015-05-04 Thread Btc Drak
On Mon, May 4, 2015 at 12:24 PM, Jorge Timón wrote: > What I was describing was an attempt to fix a similar proposal by Mark > Friedenbach, but it didn't needed fixing: I was simply > misunderstanding it. > Mark's RCLTV is completely reorg safe, so there's no need for the 100 > block restriction.

Re: [Bitcoin-development] CLTV opcode allocation; long-term plans?

2015-05-04 Thread Btc Drak
On Mon, May 4, 2015 at 6:07 AM, Peter Todd wrote: > Matt Corallo brought up¹ the issue of OP_NOP scarcity on the mempool > only CLTV pull-req²: > > "I like merging this, but doing both CLTV things in one swoop would be > really nice. Certainly if we're gonna use one of the precious few >

Re: [Bitcoin-development] New release of replace-by-fee for Bitcoin Core v0.10.1

2015-05-04 Thread Kevin Greene
I feel compelled to re-share Mike Hearn's counter-argument *against * replace-by-fee: https://medium.com/@octskyward/replace-by-fee-43edd9a1dd6d Please carefully consider the effects of replace-by-fee before applying Peter's patch. On Sun, May 3, 2015 at 9:36 PM, Peter Todd wrote: > My replace-