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] 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

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] 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

[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] 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: > >

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] 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

[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

> 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] 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] 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 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

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

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

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

> 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

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

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

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

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: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

> 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 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] Three hardfork-related BIPs

> On Jan 29, 2017, at 11:15 AM, Tom Harding via bitcoin-dev > wrote: > >> On 1/28/2017 10:29 AM, Peter Todd via bitcoin-dev wrote: >> a world of nodes in large datacenters is a world where it's very easy >> to force the few Bitcoin nodes remaining to

Re: [bitcoin-dev] BIP151 protocol incompatibility

On 02/13/2017 03:14 AM, Jonas Schnelli wrote: >>> Look at feefilter BIP 133 >>> (https://github.com/bitcoin/bips/blob/master/bip-0133.mediawiki#backward-compatibility) >>> or sendheaders BIP130 >>> (https://github.com/bitcoin/bips/blob/master/bip-0130.mediawiki#backward-compatibility) >>> Isn't it

Re: [bitcoin-dev] BIP151 protocol incompatibility

On 02/13/2017 03:11 AM, Matt Corallo wrote: > I believe many, if not all, of those messages are sent irrespective of > version number. In the interest of perfect clarity, see your code: https://github.com/bitcoin/bitcoin/blob/master/src/net_processing.cpp#L1372-L1403 Inside of the VERACK

Re: [bitcoin-dev] BIP151 protocol incompatibility

On 02/13/2017 02:16 AM, Matt Corallo wrote: > For the reasons Pieter listed, an explicit part of our version handshake and protocol negotiation is the exchange of otherwise-ignored messages to set up optional features. Only if the peer is at the protocol level that allows the message: compact

Re: [bitcoin-dev] BIP151 protocol incompatibility

On 02/13/2017 02:07 AM, Jonas Schnelli via bitcoin-dev wrote: >> All adopted BIPs to date have followed this >> pattern. This is not the same and it is not helpful to imply that it is >> just following that pattern. > > Look at feefilter BIP 133 >

[bitcoin-dev] BIP151 protocol incompatibility

The BIP151 proposal states: > This proposal is backward compatible. Non-supporting peers will ignore the encinit messages. This statement is incorrect. Sending content that existing nodes do not expect is clearly an incompatibility. An implementation that ignores invalid content leaves itself

Re: [bitcoin-dev] BIP151 protocol incompatibility

On 02/13/2017 12:47 AM, Pieter Wuille wrote: > On Feb 12, 2017 23:58, "Eric Voskuil via bitcoin-dev" > <bitcoin-dev@lists.linuxfoundation.org wrote: > > The BIP151 proposal states: > > > This proposal is backward compatible. Non-supporting peers will

Re: [bitcoin-dev] Moving towards user activated soft fork activation

On Feb 27, 2017, at 8:02 AM, shaolinfry via bitcoin-dev wrote: >> 3) In terms of complexity for mining pool operators, how well does this >> model scale if there are N soft forks and the pool doesn't want to opt-in to >> any of them? Couldn't this result

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 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] 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

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)

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] 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] [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] [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

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 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] 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

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

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] BIP30 and BIP34 interaction (was Re: [BIP Proposal] Buried Deployments)

What is the difference between downloading a hash and comparing it to a hash vs downloading a hash and then a block and comparing it to a block? You are talking about breaking a system in order to make it run faster. Using the hash is an non-optimization trade against correctness. There is no

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)

You are suggesting that, since a node implements a denial of service policy that actually denies itself otherwise valid blocks, those blocks are conditionally invalid. And that, since the validity condition is based on order of arrival and therefore independently unverifiable, Bitcoin consensus

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] Managing block size the same way we do difficulty (aka Block75)

The presumption of the mining aspect of the Bitcoin security model is that the mining majority is a broadly distributed set of independent people, not one person who controls a majority of the hash power. You seem to have overlooked a qualifier in your Satoshi quote: "...by nodes that are not

Re: [bitcoin-dev] Committed bloom filters for improved wallet performance and SPV security

It is a useful aspect of discussion at this level as it helps higher lever developers understand the actual tradeoffs. Clearly some do not. The market will eventually sort them out, but the discussion both gives developers the necessary information. It also helps core development prioritize

Re: [bitcoin-dev] Committed bloom filters for improved wallet performance and SPV security

Credit card reversals involve an escrow agent with control over the entire network and with a strong interest in preserving the network. A better analogy would be blind acceptance of any slip of paper under the assumption that it is sufficient currency. It may or may not be so, but you are on

Re: [bitcoin-dev] Bitcoin Classic 1.2.0 released

On 01/07/2017 03:10 PM, Aymeric Vitte via bitcoin-dev wrote: > Still wondering why you guys don't care about the ridiculous number of > full nodes, no incentive to run one and what would happen if someone > were to control a majority of full nodes The level of control over a majority of full

Re: [bitcoin-dev] Bitcoin Classic 1.2.0 released

On 01/07/2017 12:26 PM, Chris Priest via bitcoin-dev wrote: > ... it doesn't matter that 75% of hashpower is made up of a dozen > people. That's how the system works, it's not a matter of opinion. It's a bug, not a feature. e signature.asc Description: OpenPGP digital signature

Re: [bitcoin-dev] Issolated Bitcoin Nodes

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 03/23/2017 05:20 PM, Pieter Wuille via bitcoin-dev wrote: > On Thu, Mar 23, 2017 at 3:37 PM, Juan Garavaglia via bitcoin-dev > wrote: >> Long story short, when nodes 0.13+ receive blocks from 0.13+ >>

Re: [bitcoin-dev] Encouraging good miners

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 03/27/2017 10:29 AM, Tom Zander via bitcoin-dev wrote: > For some time now the relation between block size and propagation > speed has been decoupled. Using xthin/compact blocks miners only > send a tiny version of a block which then causes the

Re: [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 03/26/2017 01:22 PM, Bryan Bishop via bitcoin-dev wrote: > On Sun, Mar 26, 2017 at 2:05 PM, Peter R via bitcoin-dev > > wrote: > > With a tightening of the

Re: [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 03/26/2017 12:05 PM, Peter R via bitcoin-dev wrote: Peter, > Yes, it is different. It’s different because the future network > upgrade to larger blocks includes a loosening of the consensus > ruleset whereas previous upgrades have included a

Re: [bitcoin-dev] Segregated witness p2p layer compatibility

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 03/27/2017 12:22 PM, Suhas Daftuar via bitcoin-dev wrote: > Eric Voskuil wrote: > >> Given the protocol requirements of the segwit proposal this is >> not the case. A miner running pre-segwit code will produce >> blocks that no segwit node will

Re: [bitcoin-dev] Hard fork proposal from last week's meeting

As an independently verifiable, decentralized store of public information, the Bitcoin block tree and transaction DAG do have an advantage over systems such as Visa. The store is just a cache. There is no need to implement reliability in storage or in communications. It is sufficient to be able

Re: [bitcoin-dev] Two altcoins and a 51% attack (was: Defending against empty or near empty blocks from malicious miner takeover?)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 03/25/2017 01:28 PM, Peter R via bitcoin-dev wrote: > In the case of the coming network upgrade to larger blocks, a primary concern [...] is the possibility of a blockchain split and the associated confusion, replay risk, etc. > [...] a

Re: [bitcoin-dev] Unique node identifiers

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Reposting this response since this made it neither to distribution nor to the moderation archive. - Forwarded Message Subject: Re: [bitcoin-dev] Unique node identifiers Date: Wed, 8 Mar 2017 18:59:42 -0800 From: Eric Voskuil

Re: [bitcoin-dev] Using a storage engine without UTXO-index

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 04/08/2017 04:58 PM, Tomas wrote: > You seem to ignore here the difference between base load and peak > load. If Compact blocks/XThin with further optimizations can > presync nearly 100% of the transactions, and nodes can do as much > as

Re: [bitcoin-dev] Hard fork proposal from last week's meeting

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 03/31/2017 02:23 PM, Rodney Morris via bitcoin-dev wrote: > If the obsession with every personal computer being able to run a > fill node continues then bitcoin will be consigned to the dustbin > of history, The cause of the block size debate is

Re: [bitcoin-dev] Hard fork proposal from last week's meeting

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 03/31/2017 11:18 PM, Jared Lee Richardson wrote: >> If a typical personal computer cannot run a node there is no >> security. > > If you can't describe an attack that is made possible when typical > personal computers can't run nodes, this kind

Re: [bitcoin-dev] A Small Modification to Segwit

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 04/08/2017 11:15 AM, praxeology_guy via bitcoin-dev wrote: > ASICBOOST causes Bitcoin's PoW to become more memory/latency > throttled instead of raw computation throttled. > > There is the equation: Power Cost + Captial Rent + Labor ~= block >

Re: [bitcoin-dev] Using a storage engine without UTXO-index

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 04/06/2017 05:17 PM, Tomas wrote: > Thanks, but I get the impression that the similarity is rather > superficial. My point was that "Using a storage engine without UTXO-index" has been done, and may be a useful reference, not that

Re: [bitcoin-dev] Using a storage engine without UTXO-index

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 04/11/2017 01:43 AM, Tomas wrote: > Splitting transactions only happens *on storage* and is just a > minor optimization compared to storing them in full. Ok > Sure, we can still call switching tips a "reorg". And it is indeed > a trade off as

Re: [bitcoin-dev] Unique node identifiers

On 03/08/2017 11:47 AM, Jonas Schnelli wrote: >>> Nodes are by design not supposed to be identifiable in any way >> >> This is of course my objection to BIP150 ("a way for peers to ... >> guarantee node ownership“). > > Please Eric. Stop spreading FUD. I'm always willing to debate this issue.

Re: [bitcoin-dev] Moving towards user activated soft fork activation

On 03/06/2017 05:07 PM, Edmund Edgar via bitcoin-dev wrote: > On 7 March 2017 at 08:23, Gareth Williams wrote: >> What you're describing is a hashpower activated soft fork to censor transactions, in response to a user activated soft fork that the majority of hashpower disagrees

Re: [bitcoin-dev] Moving towards user activated soft fork activation

There are two aspects of system security in Bitcoin, mining (hash power) and payment validation (economy). The security of each is a function of its level of decentralization. Another way to think of it is that a system with less decentralization has a smaller community (consensus). A large

Re: [bitcoin-dev] Unique node identifiers

> On Mar 5, 2017, at 5:57 AM, John Hardy via bitcoin-dev > wrote: > > > Nodes are by design not supposed to be identifiable in any way This is of course my objection to BIP150 ("a way for peers to ... guarantee node ownership"). > I feel you're

Re: [bitcoin-dev] Using a storage engine without UTXO-index

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 04/07/2017 11:39 AM, Bram Cohen via bitcoin-dev wrote: > Expanding on this question a bit, it's optimized for parallel > access, but hard drive access isn't parallel and memory accesses > are very fast, so shouldn't the target of optimization be

Re: [bitcoin-dev] Using a storage engine without UTXO-index

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 04/07/2017 02:44 PM, Tomas via bitcoin-dev wrote: > Hi Eric, > > On Fri, Apr 7, 2017, at 21:55, Eric Voskuil via bitcoin-dev wrote: >> Optimization for lower memory platforms then becomes a process >> of reducin

Re: [bitcoin-dev] Using a storage engine without UTXO-index

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 04/06/2017 03:12 PM, Tomas via bitcoin-dev wrote: Hi Tomas, > I have been working on a bitcoin implementation that uses a > different approach to indexing for verifying the order of > transactions. Instead of using an index of unspent outputs,

Re: [bitcoin-dev] Height based vs block time based thresholds

Just as an implementation consideration, time basis creates complexity. There are no other reasons to index by time, but many to index by height. The time-based activation window of BIP9 forces nodes to either index by time or scan the chain. e > On Jul 6, 2017, at 10:20 AM, Jorge Timón via

Re: [bitcoin-dev] BIP: Block signal enforcement via tx fees

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 If people want to influence the decisions of miners, all they need to do is mine. I do not see why any person would want to pay, and then trust, another to mine accordingly. Each person can mine and attain their level of influence. This not only

Re: [bitcoin-dev] BIP: Block signal enforcement via tx fees

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/12/2017 10:45 PM, Luke Dashjr wrote: > On Saturday 13 May 2017 3:26:08 AM Eric Voskuil wrote: >> If people want to influence the decisions of miners, all they >> need to do is mine. > > Most people cannot mine except at a huge expense (profit

Re: [bitcoin-dev] BIP: Block signal enforcement via tx fees

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/12/2017 08:54 PM, ZmnSCPxj wrote: > Good morning, > >> I do not see why any person would want to pay, and then trust, >> another to mine accordingly. Each person can mine and attain >> their level of influence. This not only avoids the side

Re: [bitcoin-dev] Network-layer attacks

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/09/2017 09:09 AM, Raystonn . via bitcoin-dev wrote: > This study was released last week, detailing some attacks at the > network layer: https://btc-hijack.ethz.ch/files/btc_hijack.pdf. Of > the countermeasures discussed in the paper, the use

Re: [bitcoin-dev] BIP proposal: NODE_NETWORK_LIMITED service bits

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/11/2017 01:36 PM, Aymeric Vitte via bitcoin-dev wrote: > Sorry again, is this discussion really serious? > > In this thread, previous ones or others, the level of approximation > is obvious, often shadowed by useless maths/papers and strange

Re: [bitcoin-dev] BIP Proposal: Compact Client Side Filtering for Light Clients

The reason that BIP37 presents a long list of problems is that it is a client-server scenario wedged into a peer-to-peer network. The only possible excuse for this design was implementation shortcut. As this thread and others demonstrate, reproducing this design flaw will not eliminate the

Re: [bitcoin-dev] Emergency Deployment of SegWit as a partial mitigation of CVE-2017-9230

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Cameron, Presumably the "very serious security vulnerability" posed is one of increased centralization of hash power. Would this danger exist without the patent risk? e On 05/26/2017 01:02 AM, Cameron Garnham via bitcoin-dev wrote: > Thank you

Re: [bitcoin-dev] Emergency Deployment of SegWit as a partial mitigation of CVE-2017-9230

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Anthony, For the sake of argument: (1) What would the situation look like if there was no patent? (2) Would the same essential formulation exist if there had been a patent on bitcoin mining ASICs in general? (3) Would an unforeseen future

Re: [bitcoin-dev] Emergency Deployment of SegWit as a partial mitigation of CVE-2017-9230

On 05/29/2017 04:19 AM, Anthony Towns wrote: > On Sat, May 27, 2017 at 01:07:58PM -0700, Eric Voskuil via bitcoin-dev wrote: >> Anthony, >> For the sake of argument: > > (That seems like the cue to move any further responses to bitcoin-discuss) I didn't meant to imply that t

Re: [bitcoin-dev] Proposal: Demonstration of Phase in Full Network Upgrade Activated by Miners

> On Jun 14, 2017, at 9:55 PM, Jameson Lopp via bitcoin-dev > wrote: > > > >> On Wed, Jun 14, 2017 at 11:29 AM, Zheming Lin wrote: >> Hi Jameson: >> >>> 在 2017年6月15日，01:20，Jameson Lopp 写道： >>> >>> >>> >>>

Re: [bitcoin-dev] Proposal: Demonstration of Phase in Full Network Upgrade Activated by Miners

sonable way for users to coordinate changes independently of miners and > with very high consensus levels. > > >> On Thu, Jun 15, 2017 at 1:04 AM, Eric Voskuil via bitcoin-dev >> <bitcoin-dev@lists.linuxfoundation.org> wrote: >> >> >&g

  1   2   3   >