Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

[Btc Drak via bitcoin-dev]

On Sun, Sep 27, 2015 at 7:50 PM, Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 10) Waiting for nVersion bits and CHECKSEQUENCEVERIFY will significantly
> delay deployment of CLTV
>
> It's been proposed multiple times that we wait until we can do a single
> soft-fork with CSV using the nVersion bits mechanism.
>
> nVersion bits doesn't even have an implementation yet, nor has solid
> consensus been reached on the exact semantics of how nVersion bits
> should work.


Small correction, the suggestion is to aim to roll out CLTV+CSV together by
0.12 release, using IsSuperMajority() (or versionbits if it is ready by
then). If CSV is not ready by then, we'd just roll out CLTV.

However, the CSV related pull requests are ready for final review and if
that can happen soon I don't see why we wouldn't roll CLTV+CSV out together
before 0.12. A considerable amount of time, discussion and iterations have
occurred for the related PRs and I believe they are at the point of
consensus modulo final review before merging.

References:

Mempool-only sequence number constraint verification
https://github.com/bitcoin/bitcoin/pull/6312

Mempool-only CHECKSEQUENCEVERIFY
https://github.com/bitcoin/bitcoin/pull/6564

Mempool-only Median time-past as endpoint for lock-time calculations
https://github.com/bitcoin/bitcoin/pull/6566
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

[Mark Friedenbach via bitcoin-dev]

Agree with all CLTV and nVersionBits points. We should deploy a lock-time
soft-fork ASAP, using the tried and true IsSuperMajoirty test.

However your information regarding BIPs 68 (sequence numbers), 112
(checksequenceverify) and 113 (median time past) is outdated. Debate
regarding semantics has been settled, and there are working implementations
ready for merge on github. See pull requests #6312, #6564, and #6566. I
don’t know what the hold up has been regarding further reviews and merging,
but it is ready.

If you believe there are reasons #6312, #6564, or #6566 should not be
merged, please speak up. Otherwise it appears there is consensus on these
changes. They are related, and there is no reason not to include them in
the soft-fork, delaying applications using these features by 6-12 months.

On Sun, Sep 27, 2015 at 11:50 AM, Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Summary
> ---
>
> It's time to deploy BIP65 CHECKLOCKTIMEVERIFY.
>
> I've backported the CLTV op-code and a IsSuperMajority() soft-fork to
> the v0.10 and v0.11 branches, pull-reqs #6706 and #6707 respectively. A
> pull-req for git HEAD for the soft-fork deployment has been open since
> June 28th, #6351 - the opcode implementation itself was merged two
> months ago.
>
> We should release a v0.10.3 and v0.11.1 with CLTV and get the ball
> rolling on miner adoption. We have consensus that we need CLTV, we have
> a well tested implementation, and we have a well-tested deployment
> mechanism. We also don't need to wait for other soft-fork proposals to
> catch up - starting the CLTV deployment process isn't going to delay
> future soft-forks, or for that matter, hard-forks.
>
> I think it's possible to safely get CLTV live on mainnet before the end
> of the year. It's time we get this over with and done.
>
>
> Detailed Rational
> -
>
> 1) There is a clear need for CLTV
>
> Escrow and payment channels both benefit greatly from CLTV. In
> particular, payment channel implementations are made significantly
> simpler with CLTV, as well as more secure by removing the malleability
> vulnerability.
>
> Why are payment channels important? There's a lot of BTC out there
> vulnerable to theft that doesn't have to be. For example, just the other
> day I was talking with Nick Sullivan about ChangeTip's vulnerability to
> theft, as well as regulatory uncertainty about whether or not they're a
> custodian of their users' funds. With payment channels ChangeTip would
> only be able to spend as much of a deposit as a user had spent, keeping
> the rest safe from theft. Similarly, in the other direction - ChangeTip
> to their users - in many cases it is feasible to also use payment
> channels to immediately give users control of their funds as they
> receive them, again protecting users and helping make the case that
> they're not a custodian. In the future I'm sure we'll see fancy
> bi-directional payment channels serving this role, but lets not let
> perfect be the enemy of good.
>
>
> 2) We have consensus on the semantics of the CLTV opcode
>
> Pull-req #6124 - the implementation of the opcode itself - was merged
> nearly three months ago after significant peer review and discussion.
> Part of that review process included myself(1) and mruddy(2) writing
> actual demos of CLTV. The chance of the CLTV semantics changing now is
> near-zero.
>
>
> 3) We have consensus that Bitcoin should adopt CLTV
>
> The broad peer review and discussion that got #6124 merged is a clear
> sign that we expect CLTV to be eventually adopted. The question isn't if
> CLTV should be added to the Bitcoin protocol, but rather when.
>
>
> 4) The CLTV opcode and IsSuperMajority() deployment code has been
>thoroughly tested and reviewed
>
> The opcode implementation is very simple, yet got significant review,
> and it has solid test coverage by a suite of tx-(in)valid.json tests.
> The tests themselves have been reviewed by others, resulting in Esteban
> Ordano's pull-req #6368 by Esteban Ordano which added a few more cases.
>
> As for the deployment code, both the actual IsSuperMajority() deployment
> code and associated unit-tests tests were copied nearly line-by-line
> from the succesful BIP66. I did this deliberately to make all the peer
> review and testing of the deployment mechanism used in BIP66 be equally
> valid for CLTV.
>
>
> 5) We can safely deploy CLTV with IsSuperMajority()
>
> We've done two soft-forks so far with the IsSuperMajority() mechanism,
> BIP34 and BIP66. In both cases the IsSuperMajority() mechanism itself
> worked flawlessly. As is well-known BIP66 in combination with a large %
> of the hashing power running non-validating "SPV" mining operations did
> lead to a temporary fork, however the root cause of this issue is
> unavoidable and not unique to IsSuperMajority() soft-forks.
>
> Pragmatically speaking, now that miners are well aware of the issue it
> will be easy for them to avoid a repeat of that fork

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

[Peter Todd via bitcoin-dev]

On Sun, Sep 27, 2015 at 04:26:12PM -0400, jl2...@xbt.hk wrote:
> +1 for deploying BIP65 immediately without further waiting. Agree
> with all Peter's points.

Thanks!

> By the way, is there any chance to backport it to 0.9? In the
> deployment of BIP66 some miners requested a backport to 0.9 and
> that's why we have 0.9.5.

I certainly could, though there's good reasons to move to v0.10.x; I'd
want to first hear from miners as to why they're still on v0.9.x

-- 
'peter'[:-1]@petertodd.org
0f8ed62397b82b10e56b9aea309fb18c37985d1405808c4f


signature.asc
Description: Digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

[jl2012 via bitcoin-dev]

+1 for deploying BIP65 immediately without further waiting. Agree with 
all Peter's points.


If BIP65 has to follow the 0.12 schedule, it will take almost 9 months 
from now to complete the softfork. I don't see any good reason to wait 
for that long. We have too much talk, too little action.


Some mining pools hinted that they may adopt BitcoinXT at the end of 
2015. If we could start deploying BIP65 earlier, they will have a 
patched version by the time they switch. Gavin has agreed to support 
BIP65 in XT.


By the way, is there any chance to backport it to 0.9? In the deployment 
of BIP66 some miners requested a backport to 0.9 and that's why we have 
0.9.5.

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Weak block thoughts...

[Gregory Maxwell via bitcoin-dev]

On Sun, Sep 27, 2015 at 3:10 PM, Kalle Rosenbaum via bitcoin-dev
 wrote:
> I was mansplaining weak blocks to my wife. She asked a simple question:
>
> Why would I, as a miner, publish a weak block if I find one?
>
> I don't know.
> Sure, I will get faster propagation for my solved block, should I find one.
> On the other hand everybody else mining a similar block will enjoy the same
> benefit. Assuming that I'm not a huge miner, it's unlikely that I will
> actually solve the block, so I'm probably just giving away fast propagation
> times to someone else.
> So how does publishing a weak block benefit the producer of it more than the
> other miners? Please help me understand this.

Keep in mind, because of efficient differential transmission the cost
to you is effectively nothing if your transaction acceptance policy is
predictable, it's a hand-full of bytes sent. And by failing to send
yours you do little to nothing to deny others the improvement.

Lets imagine an alternative weak-blockless weak block implementation:

Every N seconds, every miner send to every other miner what they're
working on.  This isn't totally crazy-- efficient differential
transmission will keep the amount transmitted small.

Any block found can be referenced to any of these earlier worklists.

What the effect be of not transmitting yours?

If your block is unlike everyone elses, you would suffer great delays
in the event you found a block.
If your block is mostly like everyone elses, you wouldn't suffer as
much delay-- but the transmission costs would be negligible in that
case. ... the size sent is proportional to the improvement you get
when finding a block.

In either case, no one else is harmed by you not sending yours... they
still send their lists.

A problem with that scheme is that unless you've layered an identity
based access control system on it anyone can DOS attack it, because
anyone can send as much as they want, they don't even have to be
actual miners.

What weak blocks adds to that is using hashcash as a rate limiting
mechanism-- a coordination free lottery weighed by hash-power decides
who can transmit.

What if you don't participate in the lottery and share your solutions?
 No major harm for the other users... the other users will just choose
a somewhat lower weak-block threshold to get the updates at the
desired rate than they would otherwise. To the extent that what you
were working on was different from anyone else, you'll suffer because
you failed to make use of your chance to influence what could be
efficiently transmitted to include your own blocks.

You could also ask a question of why would you transitively relay
someone elses announcement-- well if it helped their blocks too  (by
reflecting things they also want to mine) the answer is obvious. But
what if it was disjoint from the things they wanted to mine and didn't
help compared to the weak blocks they already relayed?  In that case
it's still in likely in their interest to relay it because if a block
similar to it is produced and they extend that block they may end up
orphaned because of propagation delays their parent block suffered.
What if they receive an announcement which is so "ugly" that they
wouldn't extend the chain with the strong block version of it (they'd
intentionally try to fork it off?)-- in that case they wouldn't want
to relay it.  So much the same logic as why you relay other parties
blocks applies, including-- relaying helps the network, but if you
don't it'll still get along fine without you.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

[Peter Todd via bitcoin-dev]

Summary
---

It's time to deploy BIP65 CHECKLOCKTIMEVERIFY.

I've backported the CLTV op-code and a IsSuperMajority() soft-fork to
the v0.10 and v0.11 branches, pull-reqs #6706 and #6707 respectively. A
pull-req for git HEAD for the soft-fork deployment has been open since
June 28th, #6351 - the opcode implementation itself was merged two
months ago.

We should release a v0.10.3 and v0.11.1 with CLTV and get the ball
rolling on miner adoption. We have consensus that we need CLTV, we have
a well tested implementation, and we have a well-tested deployment
mechanism. We also don't need to wait for other soft-fork proposals to
catch up - starting the CLTV deployment process isn't going to delay
future soft-forks, or for that matter, hard-forks.

I think it's possible to safely get CLTV live on mainnet before the end
of the year. It's time we get this over with and done.


Detailed Rational
-

1) There is a clear need for CLTV

Escrow and payment channels both benefit greatly from CLTV. In
particular, payment channel implementations are made significantly
simpler with CLTV, as well as more secure by removing the malleability
vulnerability.

Why are payment channels important? There's a lot of BTC out there
vulnerable to theft that doesn't have to be. For example, just the other
day I was talking with Nick Sullivan about ChangeTip's vulnerability to
theft, as well as regulatory uncertainty about whether or not they're a
custodian of their users' funds. With payment channels ChangeTip would
only be able to spend as much of a deposit as a user had spent, keeping
the rest safe from theft. Similarly, in the other direction - ChangeTip
to their users - in many cases it is feasible to also use payment
channels to immediately give users control of their funds as they
receive them, again protecting users and helping make the case that
they're not a custodian. In the future I'm sure we'll see fancy
bi-directional payment channels serving this role, but lets not let
perfect be the enemy of good.


2) We have consensus on the semantics of the CLTV opcode

Pull-req #6124 - the implementation of the opcode itself - was merged
nearly three months ago after significant peer review and discussion.
Part of that review process included myself(1) and mruddy(2) writing
actual demos of CLTV. The chance of the CLTV semantics changing now is
near-zero.


3) We have consensus that Bitcoin should adopt CLTV

The broad peer review and discussion that got #6124 merged is a clear
sign that we expect CLTV to be eventually adopted. The question isn't if
CLTV should be added to the Bitcoin protocol, but rather when.


4) The CLTV opcode and IsSuperMajority() deployment code has been
   thoroughly tested and reviewed

The opcode implementation is very simple, yet got significant review,
and it has solid test coverage by a suite of tx-(in)valid.json tests.
The tests themselves have been reviewed by others, resulting in Esteban
Ordano's pull-req #6368 by Esteban Ordano which added a few more cases.

As for the deployment code, both the actual IsSuperMajority() deployment
code and associated unit-tests tests were copied nearly line-by-line
from the succesful BIP66. I did this deliberately to make all the peer
review and testing of the deployment mechanism used in BIP66 be equally
valid for CLTV.


5) We can safely deploy CLTV with IsSuperMajority()

We've done two soft-forks so far with the IsSuperMajority() mechanism,
BIP34 and BIP66. In both cases the IsSuperMajority() mechanism itself
worked flawlessly. As is well-known BIP66 in combination with a large %
of the hashing power running non-validating "SPV" mining operations did
lead to a temporary fork, however the root cause of this issue is
unavoidable and not unique to IsSuperMajority() soft-forks.

Pragmatically speaking, now that miners are well aware of the issue it
will be easy for them to avoid a repeat of that fork by simply adding
IsSuperMajority() rules to their "SPV" mining code. Equally turning off
SPV mining (temporarily) is perfectly feasable.


6) We have the necessary consensus to deploy CLTV via IsSuperMajority()

The various "nVersion bits" proposals - which I am a co-author of - have
the primary advantage of being able to cleanly deal with the case where
a soft-fork fails to get adopted. However, we do have broad consensus,
including across all sides of the blocksize debate, that CLTV should be
adopted. The risk of CLTV failing to get miner adoption, and thus
blocking other soft-forks, is very low.


7) Using IsSuperMajority() to deploy CLTV doesn't limit or delay other upgrades

It _is_ possible for multiple IsSuperMajority() soft-forks to coexist,
in the sense that if one soft-fork is "in flight" that doesn't prevent
another soft-fork from also being deployed simultaneously.

In particular, if we deploy CLTV via IsSuperMajority() that does _not_
impact the adoption schedule for other future soft-forks, including
soft-forks using a future nVersion bits de

[bitcoin-dev] Bitcoin mining idea

[Neil Haran via bitcoin-dev]

Hi,

I have an idea for a gamified bitcoin mining app that I'd like to partner
with someone on that is very good with cryptography and knows the bitcoin
code base well. I have received interest in this from some, but I'm looking
for the ideal candidate to work with. If this is of interest, please email
me at nhara...@gmail.com.

Thanks,
Neil
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Weak block thoughts...

[Kalle Rosenbaum via bitcoin-dev]

I was mansplaining weak blocks to my wife. She asked a simple question:

Why would I, as a miner, publish a weak block if I find one?

I don't know.

Sure, I will get faster propagation for my solved block, should I find one.
On the other hand everybody else mining a similar block will enjoy the same
benefit. Assuming that I'm not a huge miner, it's unlikely that I will
actually solve the block, so I'm probably just giving away fast propagation
times to someone else.

So how does publishing a weak block benefit the producer of it more than
the other miners? Please help me understand this.

/Kalle Rosenbaum


2015-09-27 11:42 GMT+02:00 Tier Nolan via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org>:

>
>
> On Sun, Sep 27, 2015 at 2:39 AM, Gregory Maxwell via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Unless the weak block transaction list can be a superset of the block
>> transaction list size proportional propagation costs are not totally
>> eliminated.
>>
>
> The POW threshold could be dynamic.  The first weak-block that builds on a
> new block could be forwarded with a smaller target.
>
> This reduces  the window size until at least one weak block is
> propagated.
>
> The change in threshold could be time based (for the first 30 seconds or
> so).  This would cause a surge of traffic when a new block once a new block
> has propagated, so perhaps not so good an idea.
>
>
>> As even if the weak block criteria is MUCH lower than the block
>> criteria (which would become problematic in its own right at some
>> point) the network will sometimes find blocks when there hasn't been
>> any weak block priming at all (e.g. all prior priming has made it into
>> blocks already).
>>
>
> If there is a transaction backlog, then miners could forward merkle
> branches with transactions in the memory pool with a commitment in the
> coinbase.
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] python-bitcoinlib-v0.5.0rc1 - OpenSSL crashes on OSX and Arch Linux should be fixed

[Peter Todd via bitcoin-dev]

On Sun, Sep 06, 2015 at 08:43:24PM -0400, Peter Todd via bitcoin-dev wrote:
> https://github.com/petertodd/python-bitcoinlib/tree/python-bitcoinlib-v0.5.0rc1

No issues have been reported with the release candidate, so I've
released v0.5.0 officially pretty much as-is:

https://github.com/petertodd/python-bitcoinlib/tree/python-bitcoinlib-v0.5.0

-- 
'peter'[:-1]@petertodd.org
02221cb8e8732f77da172a50fd6b0290cd5069d2ea192233


signature.asc
Description: Digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Weak block thoughts...

[Tier Nolan via bitcoin-dev]

On Sun, Sep 27, 2015 at 2:39 AM, Gregory Maxwell via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Unless the weak block transaction list can be a superset of the block
> transaction list size proportional propagation costs are not totally
> eliminated.
>

The POW threshold could be dynamic.  The first weak-block that builds on a
new block could be forwarded with a smaller target.

This reduces  the window size until at least one weak block is propagated.

The change in threshold could be time based (for the first 30 seconds or
so).  This would cause a surge of traffic when a new block once a new block
has propagated, so perhaps not so good an idea.


> As even if the weak block criteria is MUCH lower than the block
> criteria (which would become problematic in its own right at some
> point) the network will sometimes find blocks when there hasn't been
> any weak block priming at all (e.g. all prior priming has made it into
> blocks already).
>

If there is a transaction backlog, then miners could forward merkle
branches with transactions in the memory pool with a commitment in the
coinbase.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Build: win64: Package 'mingw-w64-dev' has no installation candidate

[Roy Osherove via bitcoin-dev]

Hi All
As part of trying to learn more about the bitcoin builds, I am trying to
recreate the travis CI build system using TeamCity.
Some of the builds work fine, but the windows builds seem to be having a
problem with getting mingw dev:

[08:31:21][Step 3/3] E: Package 'mingw-w64-dev' has no installation
candidate

I'm using the same exports env vars as the travis script, and actually
using the travis script inside teamcity , incuding adding the PPA for the
mingw packages.

The PPA seems to be importing fine during the build:
[Step 3/3] gpg: keyring `/tmp/tmp_nolyfrh/secring.gpg' created
[08:30:48][Step 3/3] gpg: keyring `/tmp/tmp_nolyfrh/pubring.gpg' created
[08:30:48][Step 3/3] gpg: requesting key F9CB8DB0 from hkp server
keyserver.ubuntu.com
[08:30:48][Step 3/3] gpg: /tmp/tmp_nolyfrh/trustdb.gpg: trustdb created
[08:30:48][Step 3/3] gpg: key F9CB8DB0: public key "Launchpad PPA for
Ubuntu Wine Team" imported
[08:30:48][Step 3/3] gpg: no ultimately trusted keys found
[08:30:48][Step 3/3] gpg: Total number processed: 1
[08:30:48][Step 3/3] gpg: imported: 1 (RSA: 1)

Any ideas why this seems to be working on travis and not on the teamcity
build agent?
The agent is running inside  docker image based on ubuntu.

The full log of the failed build can be found at :
http://btcdev.osherove.com:8111/viewLog.html?tab=buildLog&buildTypeId=Bitcoin_BuildWin64&buildId=332#_state=103&focus=242

same problem appears in win32 build.
there are the env vars:

NameValue passed to buildenv.BASE_OUTDIR%system.teamcity.build.checkoutDir%
env.BITCOIN_CONFIG--enable-gui --enable-reduce-exportsenv.BOOST_TEST_RANDOM
%build.number%env.CCACHE_COMPRESS1env.CCACHE_SIZE100Menv.CCACHE_TEMPDIR
/tmp/.ccache-tempenv.GOALdeployenv.HOSTx86_64-w64-mingw32env.MAKEJOBS-j2
env.PACKAGESnsis gcc-mingw-w64-x86-64 g++-mingw-w64-x86-64
binutils-mingw-w64-x86-64 mingw-w64-dev wine1.7 bcenv.PPAppa:ubuntu-wine/ppa
env.PYTHON_DEBUG1env.RUN_TESTStrueenv.SDK_URL
https://bitcoincore.org/depends-sources/sdksenv.WINEDEBUG

-- 
Thanks,

Roy Osherove

   - *@RoyOsherove* 
   - Read my new book *Notes to a Software Team Leader
*
   - Or *my new course* about Beautiful Builds 
and Continuous Delivery
   - +1-201-256-5575
- Timezone: Eastern Standard Time (New York)
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev