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.
Here's is how it works:

The operator takes a relative_height parameter and it checks that the
nSequence of the input is lower than that parameter.

Additionally, a new check at the transaction level:

for (unsigned int i = 0; i  tx.vin.size(); i++) {
// ...
if (coins-nHeight + tx.vin[i].nSequence  nSpendHeight)
return state.Invalid(false, REJECT_INVALID,
bad-txns-non-final-input);
// ...
}

Well, this is assuming that we're only using it with heights and not timestamps.
Mark, feel free to elaborate further.

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 p...@petertodd.org 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
 OP_NOPs we have we might as well make it more flexible.

 [snip]

 That said, if people have strong feelings about this, I would be willing
 to make OP_CLTV work as follows:

 nLockTime 1 OP_CLTV

 Where the 1 selects absolute mode, and all others act as OP_NOP's. A
 future relative CLTV could then be a future soft-fork implemented as
 follows:

 relative nLockTime 2 OP_CLTV

 On the bad side it'd be two or three days of work to rewrite all the
 existing tests and example code and update the BIP, and (slightly) gets
 us away from the well-tested existing implementation. It also may
 complicate the codebase compared to sticking with just doing a Script
 v2.0, with the additional execution environment data required for v2.0
 scripts cleanly separated out. But all in all, the above isn't too big
 of a deal.


Adding a parameter to OP_CLTV makes it much more flexible and is the most
economic use of precious NOPs.
The extra time required is ok and it would be good to make this change to
the PR in time for the feature freeze.

Drak
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 p...@petertodd.org wrote:

 My replace-by-fee patch is now available for the v0.10.1 release:

 https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.10.1

 No new features in this version; this is simply a rebase for the Bitcoin
 Core v0.10.1 release. (there weren't even any merge conflicts) As with
 the Bitcoin Core v0.10.1, it's recommended to upgrade.


 The following text is the copied verbatim from the previous release:

 What's replace-by-fee?
 --

 Currently most Bitcoin nodes accept the first transaction they see
 spending an output to the mempool; all later transactions are rejected.
 Replace-by-fee changes this behavior to accept the transaction paying
 the highest fee, both absolutely, and in terms of fee-per-KB. Replaced
 children are also considered - a chain of transactions is only replaced
 if the replacement has a higher fee than the sum of all replaced
 transactions.

 Doing this aligns standard node behavior with miner incentives: earn the
 most amount of money per block. It also makes for a more efficient
 transaction fee marketplace, as transactions that are stuck due to bad
 fee estimates can be unstuck by double-spending them with higher
 paying versions of themselves. With scorched-earth techniques⁵ it gives
 a path to making zeroconf transactions economically secure by relying on
 economic incentives, rather than honesty and alturism, in the same way
 Bitcoin mining itself relies on incentives rather than honesty and
 alturism.

 Finally for miners adopting replace-by-fee avoids the development of an
 ecosystem that relies heavily on large miners punishing smaller ones for
 misbehavior, as seen in Harding's proposal⁶ that miners collectively 51%
 attack miners who include doublespends in their blocks - an unavoidable
 consequence of imperfect p2p networking in a decentralized system - or
 even Hearn's proposal⁷ that a majority of miners be able to vote to
 confiscate the earnings of the minority and redistribute them at will.


 Installation
 

 Once you've compiled the replace-by-fee-v0.10.1 branch just run your
 node normally. With -debug logging enabled, you'll see messages like the
 following in your ~/.bitcoin/debug.log indicating your node is replacing
 transactions with higher-fee paying double-spends:

 2015-02-12 05:45:20 replacing tx
 ca07cc2a5eaf55ab13be7ed7d7526cb9d303086f116127608e455122263f93ea with
 c23973c08d71cdadf3a47bae45566053d364e77d21747ae7a1b66bf1dffe80ea for
 0.00798 BTC additional fees, -1033 delta bytes

 Additionally you can tell if you are connected to other replace-by-fee
 nodes, or Bitcoin XT nodes, by examining the service bits advertised by
 your peers:

 $ bitcoin-cli getpeerinfo | grep services | egrep
 '((0003)|(0401))'
 services : 0003,
 services : 0401,
 services : 0401,
 services : 0003,
 services : 0401,
 services : 0401,
 services : 0003,
 services : 0003,

 Replace-by-fee nodes advertise service bit 26 from the experimental use
 range; Bitcoin XT nodes advertise service bit 1 for their getutxos
 support. The code sets aside a certain number of outgoing and incoming
 slots just for double-spend relaying nodes, so as long as everything is
 working you're node should be connected to like-minded nodes a within 30
 minutes or so of starting up.

 If you *don't* want to advertise the fact that you are running a
 replace-by-fee node, just checkout a slightly earlier commit in git; the
 actual mempool changes are separate from the preferential peering
 commits. You can then connect directly to a replace-by-fee node using
 the -addnode command line flag.

 1) https://github.com/bitcoinxt/bitcoinxt
 2) https://github.com/bitcoin/bitcoin/pull/3883
 3) https://github.com/bitcoin/bitcoin/pull/3883#issuecomment-45543370
 4) https://github.com/luke-jr/bitcoin/tree/0.10.x-ljrP
 5)
 http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg05211.html
 6)
 http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg06970.html
 7)
 http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg04972.html

 --
 'peter'[:-1]@petertodd.org
 059a3dd65f0e5ffb8fdf316d6f31921fefcf0ef726120be9


 --
 One dashboard for servers and applications across Physical-Virtual-Cloud
 Widest out-of-the-box monitoring support with 50+ applications
 Performance metrics, stats and reports that give you Actionable