Re: [bitcoin-dev] BIP30 and BIP34 interaction (was Re: [BIP Proposal] Buried Deployments)

On 11/17/2016 07:40 AM, Johnson Lau wrote: > >> On 17 Nov 2016, at 20:22, Eric Voskuil via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote: >> >> Given that hash collisions are unquestionably possible, > > Everything you said after this point is

Re: [bitcoin-dev] BIP30 and BIP34 interaction (was Re: [BIP Proposal] Buried Deployments)

On 11/17/2016 02:22 AM, Tier Nolan via bitcoin-dev wrote: > On Thu, Nov 17, 2016 at 12:43 AM, Eric Voskuil > wrote: > > > This means that all future transactions will have different txids... > rules do guarantee it. > > No, it means that

Re: [bitcoin-dev] [BIP Proposal] Buried Deployments

On 11/16/2016 06:47 PM, Pieter Wuille wrote: > On Wed, Nov 16, 2016 at 6:16 PM, Eric Voskuil > wrote: > > On 11/16/2016 05:50 PM, Pieter Wuille wrote: > > > So are checkpoints good now? > > I believe we should get rid of checkpoints

Re: [bitcoin-dev] BIP30 and BIP34 interaction (was Re: [BIP Proposal] Buried Deployments)

On 11/17/2016 12:44 AM, Peter Todd wrote: > On Wed, Nov 16, 2016 at 04:43:08PM -0800, Eric Voskuil via bitcoin-dev wrote: >>> This means that all future transactions will have different txids... >> rules do guarantee it. >> >> No, it means that the chance i

Re: [bitcoin-dev] [BIP Proposal] Buried Deployments

On 11/16/2016 05:50 PM, Pieter Wuille wrote: > If you were trying to point out that buried softforks are similar to > checkpoints in this regard, I agree. Yes, that was my point. > So are checkpoints good now? > I believe we should get rid of checkpoints because they seem to be misunderstood as

Re: [bitcoin-dev] [BIP Proposal] Buried Deployments

er of possible keys exceeds the number of indices in the array. A hashing algorithm, no matter how clever, cannot avoid these collisions." https://en.wikipedia.org/wiki/Pigeonhole_principle e > On Wed, Nov 16, 2016 at 7:00 PM, Eric Voskuil via bitcoin-dev wrote: > > On 11/16/20

Re: [bitcoin-dev] BIP30 and BIP34 interaction (was Re: [BIP Proposal] Buried Deployments)

plementing a hard fork. > > e > > On 11/16/2016 04:31 PM, Tier Nolan via bitcoin-dev wrote: >> >> >> On Thu, Nov 17, 2016 at 12:10 AM, Eric Voskuil via bitcoin-dev >> <bitcoin-dev@lists.linuxfoundation.org >> <mailto:bitcoin-dev@lists.linuxfoundation.org&g

Re: [bitcoin-dev] BIP30 and BIP34 interaction (was Re: [BIP Proposal] Buried Deployments)

tly, it will produce a chain split. As such this is not something that a node can just dismiss. If they do they are implementing a hard fork. e On 11/16/2016 04:31 PM, Tier Nolan via bitcoin-dev wrote: > > > On Thu, Nov 17, 2016 at 12:10 AM, Eric Voskuil via bitcoin-dev &g

Re: [bitcoin-dev] [BIP Proposal] Buried Deployments

ct one implication I made below. The heights in the proposal are required in the absence of BIP34-style activation so that the soft fork validation rules can be properly enforced at those points (whether or not a deep reorg happens). e > On 11/16/2016 01:58 PM, Eric Voskuil via bitcoin-dev wrote: >&

Re: [bitcoin-dev] BIP30 and BIP34 interaction (was Re: [BIP Proposal] Buried Deployments)

No, BIP30 prevents duplicate tx hashes in the case where the new tx hash duplicates that of a preceding tx with unspent outputs. There was one such case that had already become buried in the chain at the time, so it was exempted from validation. There was another case of a duplicate hash, but

Re: [bitcoin-dev] [BIP Proposal] Buried Deployments

I would suggest that, before discussing how best to fork the chain to meet this objective, we consider the objective. The implementers have acknowledged that this does not represent a performance improvement. Especially given that this was apparently not initially understood, that alone is

Re: [bitcoin-dev] [BIP Proposal] Buried Deployments

363725? Somehow I doubt it. > > It seems to me that this change is merely cementing into place a few > attributes of the blockchain's history that are not in dispute. > > - Jameson > >> On Tue, Nov 15, 2016 at 5:42 PM, Eric Voskuil via bitcoin-dev >> <bitcoi

Re: [bitcoin-dev] [BIP Proposal] Buried Deployments

iently damaging to the Bitcoin network to > dwarf any concerns about the effects of this proposed change." > > > On Mon, Nov 14, 2016 at 6:47 PM, Eric Voskuil via bitcoin-dev > <bitcoin-dev@lists.linuxfoundation.org> wrote: >> NACK >> >> Horrible precedent (ha

Re: [bitcoin-dev] [BIP Proposal] Buried Deployments

NACK Horrible precedent (hardcoding rule changes based on the assumption that large forks indicate a catastrophic failure), extremely poor process (already shipped, now the discussion), and not even a material performance optimization (the checks are avoidable once activated until a

Re: [bitcoin-dev] Start time for BIP141 (segwit)

If somebody is not "running their own validation code" then they aren't actually using Bitcoin, so their ease in transition is irrelevant. For all they know they are accepting random numbers. e > On Oct 16, 2016, at 9:35 AM, Gavin Andresen via bitcoin-dev >

Re: [bitcoin-dev] Completing the retirement of the alert system

ACK libbitcoin defines the message and includes the public key but only for completeness and reference purposes. It has never been used in the node. e > On Sep 9, 2016, at 5:42 PM, Gregory Maxwell via bitcoin-dev > wrote: > > The alert system was a

Re: [bitcoin-dev] BIP 151

> On Jun 30, 2016, at 9:06 PM, Peter Todd wrote: > > On Thu, Jun 30, 2016 at 08:25:45PM +0200, Eric Voskuil wrote: >>> To be clear, are you against Bitcoin Core's tor support? >>> >>> Because node-to-node connections over tor are encrypted, and make use of >>> onion >>>

Re: [bitcoin-dev] BIP 151

> On Jun 30, 2016, at 6:52 PM, Peter Todd <p...@petertodd.org> wrote: > >> On Thu, Jun 30, 2016 at 05:22:08PM +0200, Eric Voskuil via bitcoin-dev wrote: >> >>> On Jun 30, 2016, at 2:43 PM, Jonas Schnelli <d...@jonasschnelli.ch> wrote: >>> &

Re: [bitcoin-dev] BIP 151

> On Jun 30, 2016, at 2:43 PM, Jonas Schnelli wrote: > The core problem posed by BIP151 is a MITM attack. The implied solution (BIP151 + authentication) requires that a peer trusts that another is not an attacker. >>> >>> BIP151 would increase the risks

Re: [bitcoin-dev] BIP 151

Pieter, these are in my opinion very reasonable positions. I've made some observations inline. > On Jun 30, 2016, at 3:03 PM, Pieter Wuille <pieter.wui...@gmail.com> wrote: > > On Thu, Jun 30, 2016 at 11:57 AM, Eric Voskuil via bitcoin-dev > <bitcoin-dev@lists.linux

Re: [bitcoin-dev] BIP 151

> On Jun 30, 2016, at 2:20 PM, Jonas Schnelli wrote: > > >> Yes, this is exactly what I meant. The complexity of the proposed >> construction is comparable to that of Bitcoin itself. This is not itself >> prohibitive, but it is clearly worthy of consideration. >> >> A

Re: [bitcoin-dev] BIP 151

2016, at 1:17 PM, Alfie John <al...@alfie.wtf> wrote: > > On Tue, Jun 28, 2016 at 06:45:58PM +0200, Eric Voskuil via bitcoin-dev wrote: >>> then we should definitively use a form of end-to-end encryption between >>> nodes. Built into the network layer. >> >> Wide

Re: [bitcoin-dev] BIP 151

On Jun 29, 2016, at 3:01 AM, Gregory Maxwell wrote: > >> On Tue, Jun 28, 2016 at 11:33 PM, Eric Voskuil wrote: >> I don't follow this comment. The BIP aims quite clearly at "SPV" wallets as >> its justifying scenario. > > It cites SPV as an example, doesn't

Re: [bitcoin-dev] BIP 151

>> On Jun 29, 2016, at 12:22 AM, Gregory Maxwell wrote: >> >> On Tue, Jun 28, 2016 at 9:59 PM, Eric Voskuil wrote: >> Passing the session ID out of band is authentication. As this is explicitly >> not part of BIP151 it cannot be that BIP151 provides the

Re: [bitcoin-dev] BIP 151

On Jun 28, 2016, at 9:55 PM, Gregory Maxwell via bitcoin-dev wrote: >> I understand the use, when coupled with a yet-to-be-devised identity system, >> with Bloom filter features. Yet these features > > This is a bit of a strawman, you've selected a

Re: [bitcoin-dev] BIP 151

On Jun 28, 2016, at 10:06 PM, Jonas Schnelli wrote: >>> In my opinion, the question should be "why would you _not_ encrypt". >> >> 1) creation of a false sense of security > > False sense of security is mostly a communication issue. > BIP151 does focus on encryption (not

Re: [bitcoin-dev] BIP 151

low hanging fruit for authentication. >> >> It is the implication of widespread authentication that is at issue. Clearly >> there are ways to implement it using a secure side channels. >> >>> However, let's first get unauthenticated encryption. Force the at

Re: [bitcoin-dev] BIP 151

authenticated encryption. Force the attackers to > use active attacks. (That are thousands times more costly to couduct). > > Sent from my iPhone > >> On 29 Jun 2016, at 00:36, Gregory Maxwell via bitcoin-dev >> <bitcoin-dev@lists.linuxfoundation.org> wrote: >>

Re: [bitcoin-dev] BIP 151

> On Jun 28, 2016, at 11:36 PM, Gregory Maxwell <g...@xiph.org> wrote: > > On Tue, Jun 28, 2016 at 9:22 PM, Eric Voskuil via bitcoin-dev > <bitcoin-dev@lists.linuxfoundation.org> wrote: >> An "out of band key check" is not part of BIP151. > >

Re: [bitcoin-dev] BIP 151

> On Jun 28, 2016, at 10:36 PM, Peter Todd wrote: > >> On Tue, Jun 28, 2016 at 10:29:54PM +0200, Eric Voskuil wrote: >> >> On Jun 28, 2016, at 10:14 PM, Peter Todd wrote: On Tue, Jun 28, 2016 at 08:35:26PM +0200, Eric Voskuil wrote:

Re: [bitcoin-dev] BIP 151

> On Jun 28, 2016, at 10:14 PM, Peter Todd wrote: > >> On Tue, Jun 28, 2016 at 08:35:26PM +0200, Eric Voskuil wrote: >> Hi Peter, >> >> What in this BIP makes a MITM attack easier (or easy) to detect, or >> increases the probability of one being detected? > > BIP151

Re: [bitcoin-dev] BIP 151

Hi Peter, What in this BIP makes a MITM attack easier (or easy) to detect, or increases the probability of one being detected? e > On Jun 28, 2016, at 8:22 PM, Peter Todd <p...@petertodd.org> wrote: > > On Tue, Jun 28, 2016 at 06:45:58PM +0200, Eric Voskuil via bitcoin-d

Re: [bitcoin-dev] BIP 151

continued from previous post... > On Jun 28, 2016, at 2:13 PM, Jonas Schnelli via bitcoin-dev > wrote: > > Hi Eric > > Sorry for not directly addressing your points. No problem. Thanks for the detailed replies. > I try to be more precise in this follow

Re: [bitcoin-dev] BIP 151

Hi Jonas, I'll follow up in your second reply as well. Responses inline: > On Jun 28, 2016, at 10:26 AM, Jonas Schnelli via bitcoin-dev > wrote: > > Hi Eric > >> I haven't seen much discussion here on the rationale behind BIP 151. >> Apologies if I

[bitcoin-dev] BIP 151

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I haven't seen much discussion here on the rationale behind BIP 151. Apologies if I missed it. I'm trying to understand why libbitcoin (or any node) would want to support it. I understand the use, when coupled with a yet-to-be-devised identity

Re: [bitcoin-dev] p2p authentication and encryption BIPs

On 03/23/2016 01:36 PM, Tom via bitcoin-dev wrote: > On Wednesday 23 Mar 2016 16:24:12 Jonas Schnelli via bitcoin-dev wrote: > * why would you not allow encryption on non-pre-approved connections? Agree > * we just removed (ssl) encryption from the JSON interface, how do you > suggest > this

Re: [bitcoin-dev] Hardfork to fix difficulty drop algorithm

On 03/02/2016 12:08 PM, Paul Sztorc wrote: > On 3/2/2016 2:01 PM, Eric Voskuil via bitcoin-dev wrote: >>> A 6 month investment with 3 months on the high subsidy and 3 months on >> low subsidy would not be made… >> >> Yes, this is the essential point. All capi

Re: [bitcoin-dev] Hardfork to fix difficulty drop algorithm

> A 6 month investment with 3 months on the high subsidy and 3 months on low > subsidy would not be made… Yes, this is the essential point. All capital investments are made based on expectations of future returns. To the extent that futures are perfectly knowable, they can be perfectly

Re: [bitcoin-dev] Libconsensus phase 2

On 01/13/2016 12:37 AM, Jorge Timón wrote: > On Tue, Jan 12, 2016 at 8:17 PM, Eric Voskuil wrote: >> Jorge, first, thanks again for your work on this. >> >> Without creating and using a public blockchain interface in phase 2, how >> will you isolate the database dependency from

Re: [bitcoin-dev] Libconsensus phase 2

Jorge, first, thanks again for your work on this. Without creating and using a public blockchain interface in phase 2, how will you isolate the database dependency from consensus critical code? Is it that the interface will exist but you will recommend against its use? This work presumes that

Re: [bitcoin-dev] Scaling Bitcoin conference micro-report

On 09/18/2015 11:06 PM, NxtChg via bitcoin-dev wrote: >> While to many of us that sounds crazy, if you're threat model assumes >> Bitcoin is a legal/regulated service provided by a highly trusted >> mining community it's a reasonable design. > > There is a large, grey area all the way to

Re: [bitcoin-dev] Scaling Bitcoin conference micro-report

On 09/19/2015 12:57 AM, NxtChg wrote:> >> Your vision of censorship resistance is to become such a strong >> central authority that you can resist it in direct physical >> confrontation. If you succeed at this, you are the threat. > > My vision is a strong _decentralized_ system, which is: > >

[bitcoin-dev] BIP-38 issue and altchain support

In the integration of BIP-38 into libbitcoin we ran into two issues. First, the scenario that justifies the "confirmation code" is flawed. We have implemented full support for this, but have also marked it as deprecated. I am seeking counter arguments, in case there is some scenario that we

Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap [BIP 1xx - Draft]

just as in democracy in general One should be clear that Bitcoin is by no possible measure a democracy. The proposed vote is on what goes into a particular github repository. The outcome is ultimately controlled by those with control of that repository. Bitcoin is an anarchy by design. People

Re: [bitcoin-dev] Bitcoin XT Fork

[cross-posted to libbitcoin] On 08/19/2015 03:00 PM, Jorge Timón via bitcoin-dev wrote: On Wed, Aug 19, 2015 at 10:04 PM, Eric Lombrozo elombr...@gmail.com wrote: But the consensus code should NOT be subject to the same commit policies…and we should make an effort to separate the two clearly.

Re: [bitcoin-dev] libconsensus assertion fails if used in multiple threads

On 08/18/2015 03:31 AM, Tamas Blummer via bitcoin-dev wrote: The performance of libconsensus is surprisingly close to the java one. ... Another nice demonstration why one should not trade in advances of languages for the last decades for a marginal gain of performance with C/C++... If

Re: [bitcoin-dev] Bitcoin XT 0.11A

[cross-posted to libbitcoin] I applaud this effort not for the merits of the hard fork but on the effects of the code fork. We have been witnessing the self-destruction of Bitcoin's central authority. This is a necessary outcome. Understandably, many are concerned that if consensus settles on a

Re: [bitcoin-dev] Libconsensus separated repository (was Bitcoin Core and hard forks)

On 07/23/2015 07:30 AM, Jorge Timón wrote: On Thu, Jul 23, 2015 at 2:49 AM, Eric Voskuil via bitcoin-dev wrote: On 07/22/2015 05:13 PM, Eric Lombrozo via bitcoin-dev wrote: Only being partly serious - I strongly am in favor of a sufficiently modularized codebase that swapping out consensus

Re: [bitcoin-dev] Bitcoin Core and hard forks

https://twitter.com/petertoddbtc Thanks for the triggering warning, if not for that I may have gone into seizures. e On 07/27/2015 10:05 AM, Alice Larson via bitcoin-dev wrote: The twitter teenage nonsense from Todd is ridiculous: https://twitter.com/playatodd (warning, triggering)

Re: [bitcoin-dev] Making Electrum more anonymous

On 07/23/2015 08:42 PM, Slurms MacKenzie via bitcoin-dev wrote: From: Eric Voskuil via bitcoin-dev From our perspective, another important objective of query privacy is allowing the caller make the trade-off between the relative levels of privacy and performance - from absolute to non

Re: [bitcoin-dev] Electrum Server Speed Test

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Does to process into the index include time for transport and/or block validation (presumably by bitcoind) or this this exclusively the time for Electrum Server to index a validated block? e On 07/23/2015 08:56 AM, Slurms MacKenzie via bitcoin-dev

Re: [bitcoin-dev] Making Electrum more anonymous

I should add that the obvious resolution to this set of problems is to use a distinct Tor route for each Bitcoin address, not to reinvent Tor and reproduce its community. So ultimately this is easy to implement, but the downside is performance. But it's important to keep in mind that

<    1   2   3