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

Thanks for sending this proposal! I look forward to having a great discussion around this. - Eric On Thursday, June 1, 2017, Olaoluwa Osuntokun via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi y'all, > > Alex Akselrod and I would like to propose a new light client BIP for >

Re: [bitcoin-dev] Bitcoin Classic 1.2.0 released

Can you guys please take this discussion elsewhere? Perhaps to bitcoin-discuss? This is not the place to rehash discussions that have taken place a million times already. The behavior of the network under contentious hard forks has been discussed ad nauseum. This mailing list is for the discussion

Re: [bitcoin-dev] Bitcoin Classic 1.2.0 released

Your release announcement does not make it clear that Bitcoin Classic is incompatible with the current Bitcoin network and its consensus rules. It is a hard fork on mainnet with no safe activation as well as including other unsafe changes. There is also no BIP for the hard fork. There is also no

Re: [bitcoin-dev] Making UTXO Set Growth Irrelevant With Low-Latency Delayed TXO Commitments

Nice! We’ve been talking about doing this forever and it’s so desperately needed. > On May 17, 2016, at 3:23 PM, Peter Todd via bitcoin-dev > wrote: > > # Motivation > > UTXO growth is a serious concern for Bitcoin's long-term decentralization. To > run

Re: [bitcoin-dev] Proposal to update BIP-32

In practice the probability of this case triggering is on the order of 2^-128 or something astronomically tiny. I've been using BIP32 for a few years already as have many others...I don't think we've ever had to handle this case. Justifiably, many app developers feel like the additional

Re: [bitcoin-dev] BIP Classification Process

wn distribution is false (nor desirable): it was down to a strong differing > of technical opinions between Mike and a dozen other developers as well as > node security concerns (which were proved correct). > > > On Fri, Jan 29, 2016 at 12:52 AM, Eric Lombrozo via bitcoin-dev >

[bitcoin-dev] BIP Classification Process

Folks, I think the current situation with forks could have been avoided with a better process that can distinguish between different layers for bitcoin modification proposals. For instance, BIP64 was proposed by Mike Hearn, which does not affect the consensus layer at all. Many Core devs

[bitcoin-dev] Segregated Witness App Development

Hello, folks. I wanted to let all of you know a new IRC channel has been created called #segwit-dev where we welcome all discussion pertaining to integrating and supporting segregated witness transactions in wallets as well as comments or suggestions for improvement to the spec. Please come

Re: [bitcoin-dev] We need to fix the block withholding attack

it. On December 26, 2015 7:33:53 AM PST, "Jorge Timón" <jti...@jtimon.cc> wrote: >On Dec 26, 2015 9:24 AM, "Eric Lombrozo via bitcoin-dev" < >bitcoin-dev@lists.linuxfoundation.org> wrote: > >> Unfortunately, this also means longer confirmation times, lower >

Re: [bitcoin-dev] We need to fix the block withholding attack

actually possible to do with a soft fork. On December 26, 2015 8:09:18 AM PST, Tier Nolan via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote: >On Sat, Dec 26, 2015 at 8:23 AM, Eric Lombrozo via bitcoin-dev < >bitcoin-dev@lists.linuxfoundation.org> wrote: > >&g

Re: [bitcoin-dev] We need to fix the block withholding attack

Note: my stupid email client didn't indent Peter Todd's quote correctly. The first paragraph is his, the second is my response. -- Original Message -- From: "Eric Lombrozo" To: "Peter Todd" ; "Emin Gün Sirer" Cc:

[bitcoin-dev] Segregated Witness BIPs

I've been working with jl2012 on some SEGWIT BIPs based on earlier discussions Pieter Wuille's implementation. We're considering submitting three separate BIPs: CONSENSUS BIP: witness structures and how they're committed to blocks, cost metrics and limits, the scripting system (witness

Re: [bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin

Doesn't a good soft fork signaling mechanism along with an activation warning system for non-upgraded nodes (i.e. BIP9, or even block version ISM for that matter) essentially fix this? I don't quite get why this should be an issue. On December 17, 2015 10:52:39 AM PST, Jeff Garzik via

Re: [bitcoin-dev] On the security of softforks

First of all, that's an expensive beer! Second of all, any consensus rule change risks non-full-validating or non-upgraded nodes seeing invalid confirmations...but assuming a large supermajority (i.e. > 95%) of hashing power is behind the new rule, it is extremely unlikely that very many

Re: [bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin

There are no good short-term scaling solutions...this is a very hard problem that necessarily requires a lot of out-of-the-box thinking, something 2015 has seen a LOT of...and I'm optimistic about the ideas presented thus far. At least SW *is* a scaling solution (albeit most of the important

Re: [bitcoin-dev] Alternative name for CHECKSEQUENCEVERIFY (BIP112)

something important here, but unless there's a reason such data cannot be made prunable, I haven't been able to poke a hole yet. - Eric On November 26, 2015 8:02:45 PM PST, Rusty Russell <ru...@rustcorp.com.au> wrote: >Eric Lombrozo via bitcoin-dev <bitcoin-dev@lists.linuxfo

Re: [bitcoin-dev] Alternative name for CHECKSEQUENCEVERIFY (BIP112)

After a little more though (and some comments from aj), I realize that the opcode naming convention is actually CHECK VERIFY. Therefore, the full opcode name should be CHECKRELATIVELOCKTIMEVERIFY. However, this name is ridiculously long, so at least some part will require abbreviation. In

Re: [bitcoin-dev] Alternative name for CHECKSEQUENCEVERIFY (BIP112)

From a system developer standpoint, CHECKMATURITYVERIFY ties together the semantics of this opcode with another existing feature in the system (coinbase maturity). HOWEVER... from an application developer standpoint, I think the concept of a timelock is more relevant. Maturity is a concept

Re: [bitcoin-dev] Dynamic Hierarchical Deterministic Key Trees

by a path to the immediate parent node in the tree and reserve the children themselves for the signing keys. - Eric -- Original Message -- From: "Tamas Blummer" <ta...@bitsofproof.com> To: "Eric Lombrozo" <elombr...@gmail.com>; "Eric Lo

[bitcoin-dev] Hierarchical Deterministic Script Templates

A while back, I started working with William Swanson on a script template format to allow for interoperability in accounts between different wallets. We made some progress, but both of us got pretty busy with other projects and general interest was still quite low. It seems interest has

[bitcoin-dev] Fw: Making soft forks pluggable

I wanted to clarify that this goal is for AFTER the next release in case that didn't come across. The point is just to ascertain interest and start thinking ahead. VersionBits can be fully ready to go well before then and is well underway. -- Forwarded Message -- From: "Eric Lombrozo"

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

You're right about the potential for 1 bad confirmation even with very low frequency...but with an overwhelming supermajority of hashpower, 2 bad confirmations become quite unlikely, n bad confirmations becomes exponentially unlikely in n. As part of such soft fork deployments, it's true that

Re: [bitcoin-dev] This thread is not about the soft/hard fork technical debate

I prefer the term "clown". Can we please move on? -- Original Message -- From: "cipher anthem via bitcoin-dev" To: mi...@bitcoins.info Cc: bitcoin-dev@lists.linuxfoundation.org Sent: 10/6/2015 12:17:14 AM Subject: Re: [bitcoin-dev] This thread

Re: [bitcoin-dev] This thread is not about the soft/hard fork technical debate

I agree with you, Sergio, up until the part about someone having won a battle. There's a difference between sincere technical objections and someone just being a dick. I think in this case this line has been crossed (and I don't think I'm alone here). - Eric On October 5, 2015 8:56:33 AM PDT,

Re: [bitcoin-dev] Design Competition

I've also got a competition where the object is to build a spaceship using only a watermelon, two donkeys, some duct tape, and a fire hydrant. -- Original Message -- From: "Richard Olsen via bitcoin-dev" To: "bitcoin-dev"

Re: [bitcoin-dev] Versionbits BIP (009) minor revision proposal.

I can go along with making it optional but recommended for the first deployment and making it mandatory later on. It would be purely informational for now...but it will give us valuable data. As has been said before, most of these BIP deployments will likely be accompanied by recommended

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

Mike, Insults were not really my intention. Let's set aside our differences regarding SPV security and assume you understand the different implications for soft forks and hard forks. Other than the fact that doing this as a soft fork requires an extra OP_DROP, how would doing this as a hard

Re: [bitcoin-dev] Versionbits BIP (009) minor revision proposal.

While I would like to get some form of explicit acknowledgment from miners that a new rule is in effect, the truth of the matter is we still lack a means to determine whether or not miners are actually enforcing these rules...unless someone happens to mine a block that breaks the new rule.

Re: [bitcoin-dev] Versionbits BIP (009) minor revision proposal.

Good points, Greg. The way I see it, this mechanism isn't really about "voting" - it's about deployment of fairly uncontroversial changes with the minimum amount of negative disruption. If we have reason to believe a particular BIP stands little chance of hitting the 95% mark relatively

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

Perhaps Adam won't go into the rationale...but I think it is important we clarify this. For better or worse, the only "voting" system available to Bitcoin that cannot be trivially attacked is hashing power. Soft forks are essentially miner-enforced rule changes...rules they could have decided

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

My initial reaction is just HUH?!?!? Is this some sophisticated form of humor I'm just not getting? On September 28, 2015 3:48:57 AM PDT, Mike Hearn via bitcoin-dev wrote: >There is *no* consensus on using a soft fork to deploy this feature. It >will

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

SPV wallets in their current form are inherently insecure. Moreover, while we at least have a soft fork mechanism that is not trivially exploitable (yes, it's got issues...but unlike SPV wallets, it isn't so easily exploitable), we have NO hard fork mechanism in place that isn't highly prone to

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

-- Original Message -- From: "s7r via bitcoin-dev" To: bitcoin-dev@lists.linuxfoundation.org Sent: 9/20/2015 2:33:38 PM Subject: Re: [bitcoin-dev] Scaling Bitcoin conference micro-report The general threat model for which we want to scale is:

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

-- Original Message -- From: "Milly Bitcoin via bitcoin-dev" To: bitcoin-dev@lists.linuxfoundation.org Sent: 9/20/2015 3:02:32 PM Subject: Re: [bitcoin-dev] Scaling Bitcoin conference micro-report Larger user base won't necessarily protect

Re: [bitcoin-dev] Weekly development meetings on IRC

I love the weekly meeting idea...but timezones might be an issue. My general preference would be afternoons to late evenings pacific time, but that translates to late night/early morning for those in europe. On September 18, 2015 12:04:58 AM PDT, Jonas Schnelli via bitcoin-dev

Re: [bitcoin-dev] libconsensus and bitcoin development process

You're aware that my entire stack was built around this model and I've even built a fully fledged desktop GUI, multisig account manager, and servers supporting pull and event subscription atop it, right? On September 17, 2015 5:07:20 PM PDT, "Wladimir J. van der Laan via bitcoin-dev"

Re: [bitcoin-dev] [BIP Proposal] Version bits with timeout and delay.

The exact numbers (95% vs. 75% etc) don't need to be completely specified to start working on an implementation. What really matters for now is defining the states and trigger mechanisms. I'd rather we not argue over the optimal values for supermajority requirement at this point. On September

Re: [bitcoin-dev] libconsensus and bitcoin development process

I basically agree with what has been said here. Refactoring efforts should be well-coordinated. Their short-term impact can be quite disruptive, although if done correctly, longer-term they make it even easier for downstream developers to add and merge changes. By scheduling move-only changes,

Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft)

In principle I am sympathetic to dynamic block size proposals...but in practice it seems we're barking up the wrong tree. Without mechanisms for incentivizing validators...and checks and balances between the interests of regular users (who want to reduce fees and confirmation time), miners (who

Re: [bitcoin-dev] Splitting BIPs

I posted a new draft of the proposal: http://blockhawk.net/bitcoin-dev/bipwiki.html The subsections still need to be fleshed out a bit more. I'd love any comments or suggestions. On Mon, Aug 24, 2015, 4:30 PM Eric Lombrozo elombr...@gmail.com wrote: Also, the current type attribute needs

Re: [bitcoin-dev] Revisiting NODE_BLOOM: Proposed BIP

It would be very useful to not only be able to switch filtering on and off globally...but to be able to switch on a per-connection basis. But then again, perhaps it would be smarter to ditch the whole bloom filter thing in favor of an actual client/server architecture with proper authentication

Re: [bitcoin-dev] Revisiting NODE_BLOOM: Proposed BIP

Indeed, so I don't really have a problem with this proposal. On Mon, Aug 24, 2015, 11:30 AM Wladimir J. van der Laan laa...@gmail.com wrote: On Mon, Aug 24, 2015 at 06:15:39PM +, Eric Lombrozo via bitcoin-dev wrote: It would be very useful to not only be able to switch filtering

Re: [bitcoin-dev] Splitting BIPs

Also, the current type attribute needs modification. There are different degrees of standard. Just because a lot of people do X doesn't need to mean that doing X is officially endorsed by any other devs. At most levels below 1, disagreements might be entirely tolerable for many things. On Mon,

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

I've been pushing for greater modularization since I first got into bitcoin. I got quickly frustrated when I was only able to get through very few things (i.e. moving core structure serialization classes to a separate unit not called main). Working on Bitcoin has an added layer of frustration that

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

One thing it occurs to me (and I don't know if this has been suggested before) we could do is separate the BIP process into at several distinct areas: 1) Commit structure changes/consensus rule change proposals - Consensus-building process (how are proposals debated, improved, vetted, and

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

Unfortunately we have no way of rigorously proving functional equivalence other than code review and unit testing. The simpler the consensus code (and the more we can write it in a style that affords provability of correctness) the easier it will be in the future to compare implementations. Prior

Re: [bitcoin-dev] Bitcoin XT Fork

On Aug 19, 2015, at 12:12 PM, Santino Napolitano via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: Gavin has been very clear about the fact that he's on vacation. I'm not sure what you want Mike to say. It's obvious the Bitcoin Core developer pitchforks are out for him so

Re: [bitcoin-dev] bitcoin-dev list etiquette

Alex, With all due respect, right now the biggest challenge facing Bitcoin is not technical but political. I would love to see this list go back to technical discussions, but unfortunately, until this political stuff is resolved, even technical discussion is purely philosophical as there’s

Re: [bitcoin-dev] Bitcoin XT Fork

Unfortunately, I think that from a PR angle, removing Gavin from commit privileges right now will probably play into his hand. Sadly. Say what you will regarding Gavin and Mike’s technical merits, they’ve been quite clever on the PR front. Framing this issue as “obstructionism from the core

Re: [bitcoin-dev] Annoucing Not-BitcoinXT

NxtChg, In the entire history of Bitcoin we’ve never attempted anything even closely resembling a hard fork like what’s being proposed here. Many of us have wanted to push our own hard-forking changes to the protocol…and have been frustrated because of the inability to do so. This inability

Re: [bitcoin-dev] Bitcoin XT 0.11A

Or can’t you create a transaction that’s still within the op count and sig ops limits but is larger than 1MB? On Aug 17, 2015, at 5:29 AM, Andrew LeCody via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: Wouldn't that require a fork that lasts for more than 100 blocks? On Mon,

Re: [bitcoin-dev] Annoucing Not-BitcoinXT

I should add that in the interest of peace and goodwill, I extend an offer to both Mike and Gavin to make their grievances heard…but only on the condition that we make a good effort to avoid misrepresentation and misreading of the other side’s intentions. On Aug 17, 2015, at 9:37 AM, Eric

Re: [bitcoin-dev] Annoucing Not-BitcoinXT

On Aug 17, 2015, at 6:34 AM, NxtChg via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: Great, so how about you go tell theymos to stop censoring XT posts and banning the other side on /r/Bitcoin? Let users decide what Bitcoin is or isn't. FWIW, I don’t think what theymos

Re: [bitcoin-dev] Annoucing Not-BitcoinXT

probably have to be aborted. Adam On 17 August 2015 at 15:03, Eric Lombrozo via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org mailto:bitcoin-dev@lists.linuxfoundation.org wrote: NxtChg, In the entire history of Bitcoin we’ve never attempted anything even closely resembling a hard

Re: [bitcoin-dev] Bitcoin XT 0.11A

You deeply disappoint me, Mike. Not only do you misrepresent many cogent, well thought out positions from a great number of people who have published and posted a number of articles detailing an explaining in-depth technical concerns…you also seem to fancy yourself more capable of reading into

Re: [bitcoin-dev] Eli Dourado on governance

Rather than speculating on fake markets, why don’t we use theory, empirical data, and engineering to fix the damn problems? On Aug 4, 2015, at 11:28 AM, Owen via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: Given there is no money at stake in these prediction games, it is no

Re: [bitcoin-dev] A reason we can all agree on to increase block size

On Aug 3, 2015, at 1:52 AM, Hector Chu hector...@gmail.com wrote: On 3 August 2015 at 09:38, Eric Lombrozo elombr...@gmail.com mailto:elombr...@gmail.com wrote: We already have much more efficient, far more scalable systems that allow this kind of cooperation you speak of without the

Re: [bitcoin-dev] A reason we can all agree on to increase block size

Bah, I don’t know if you’re just trolling me, Hector…but I’ll give you the benefit of the doubt and act like you aren’t. We already have much more efficient, far more scalable systems that allow this kind of cooperation you speak of without the inconveniences of blockchains and such. These

Re: [bitcoin-dev] Incentivising full nodes by having SPV nodes to pay for data requests

The point is that without concrete direct incentives, many might find it rational to just leech off others...which might actually work for a while...but this is obviously not stable equilibrium...and it's very hard to do any game theory on it. Current SPV implementations necessarily diverge from

Re: [bitcoin-dev] Incentivising full nodes by having SPV nodes to pay for data requests

I proposed something along these lines in the lightning-dev mailing list: http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-July/88.html It's probably a little off-topic there...but I'm very interested in discussing such ideas. On Aug 3, 2015 10:06 AM, Luv Khemani via bitcoin-dev

Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary

@lists.linuxfoundation.org wrote: On Thursday 30. July 2015 16.33.16 Eric Lombrozo via bitcoin-dev wrote: I don’t think it’s really a matter of whether we agree on whether it’s good to raise the block size limit, Gavin. I think it’s a matter of a difference in priorities. Having

Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary

On Jul 30, 2015, at 5:29 AM, Gavin gavinandre...@gmail.com wrote: it is hard to have a rational conversation about that when even simple questions like 'what is s reasonable cost to run a full node' are met with silence. Some of the risks are pretty hard to quantify. But I think this

Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary

On Jul 30, 2015, at 11:02 AM, Mark Friedenbach via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: It is possible for a decentralized system like bitcoin to scale via distribution in a way that introduces minimal trust, for example by probabilistic validation and distribution

Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary

I agree that the historical reasons are irrelevant from an engineering perspective. But they still set a context for the discussion…and might help shed some insight into the motivations behind some of the participants. It’s also good to know these things to counter arguments that start with

Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary

On Jul 28, 2015, at 7:40 PM, Eric Lombrozo elombr...@gmail.com wrote: Note: many of these ideas are neither my own nor really all that new, but it seems in the past we’ve given up too easily on actually moving forward on them despite their critical importance. In retrospect I regret not

Re: [bitcoin-dev] Bitcoin Roadmap 2015, or If We Do Nothing Analysis

On Jul 24, 2015, at 10:40 AM, Peter Todd via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: On Fri, Jul 24, 2015 at 07:09:13AM -0700, Adam Back via bitcoin-dev wrote: (Claim of large bitcoin ecosystem companies without full nodes) this says to me rather we have a need for

Re: [bitcoin-dev] Bitcoin Roadmap 2015, or If We Do Nothing Analysis

Thanks for bringing up the CCSS, Adam and Peter. I was actually working on a post inviting everyone in this mailing list to come and participate…but you guys beat me to it. :) The CCSS is an open standard, born out of the belief that sharing the industry's best practices amongst each other and

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

On Thu, Jul 23, 2015 at 3:14 PM, Eric Lombrozo elombr...@gmail.com mailto:elombr...@gmail.com wrote: Mainstream usage of cryptocurrency will be enabled primarily by direct party-to-party contract negotiation…with the use of the blockchain primarily as a dispute resolution mechanism. The

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

I should also add that I think those who claim that fee pressure will scare away users and break the industry are *seriously* underestimating human ingenuity in the face of a challenge. We can do this - we can overcome this obstacle…we can find good solutions to a fee market. Unless someone can

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

On Jul 23, 2015, at 4:42 PM, Benedict Chan ben...@fragnetics.com wrote: Scaling the network will come in the form of a combination of many optimizations. Just because we do not know for sure how to eventually serve 7 billion people does not mean we should make decisions on global

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

I think it’s pretty clear by now that the assumption that all nodes have pretty similar computational resources leads to very misplaced incentives. Ultimately, cryptocurrencies will allow direct outsourcing of computation, making it possible to distribute computational tasks in an economically

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

On Jul 23, 2015, at 12:35 PM, Gavin Andresen gavinandre...@gmail.com wrote: There are lots of things we can do to decrease costs, and a lot of things have ALREADY been done (e.g. running a pruned full node). I also wanted to point out I fully agree with you that there are still many

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

On Jul 23, 2015, at 11:10 AM, Jameson Lopp jameson.l...@gmail.com wrote: Larger block sizes don't scale the network, they merely increase how much load we allow the network to bear. Very well put, Jameson. And the cost of bearing this load must be paid for. And unless we’re willing to

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

On Jul 23, 2015, at 10:14 AM, Robert Learney via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: That’s not exactly what’s happened though, is it Cipher? Gavin put forward 20Mb then after analysis and discussion has moved to 8Mb, whereas the other camp of core developers is

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

On Jul 23, 2015, at 9:28 AM, Gavin Andresen via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: I'd really like to move from IMPOSSIBLE because... (electrum hasn't been optimized (by the way: you should run on SSDs, LevelDB isn't designed for spinning disks), what if the

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

On Jul 22, 2015, at 3:01 PM, Mike Hearn he...@vinumeris.com wrote: Until we’re able to merge blockchain forks like we’re able to merge git repo forks, the safest option is no fork. Block chain forks merge in the same way as git forks all the time, that's how the reorg algorithm works.

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

On Jul 22, 2015, at 2:43 PM, Mike Hearn via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: Hi Pieter, I think a core area of disagreement is this: Bitcoin Core is not running the Bitcoin economy, and its developers have no authority to set its rules. In fact Bitcoin Core

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

FWIW, I had worked on something similar a while back: https://github.com/CodeShark/bitcoin/tree/coinparams_new/altconf https://github.com/CodeShark/bitcoin/blob/coinparams_new/altconf/bitcoin.conf I like the idea in principle…but we should require a new genesis block, different magic bytes,

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

On Jul 22, 2015, at 5:34 PM, Cory Fields li...@coryfields.com wrote: On Wed, Jul 22, 2015 at 8:13 PM, Eric Lombrozo elombr...@gmail.com wrote: On Jul 22, 2015, at 5:05 PM, Cory Fields li...@coryfields.com wrote: On Wed, Jul 22, 2015 at 7:53 PM, Eric Lombrozo elombr...@gmail.com wrote:

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

On Jul 22, 2015, at 5:27 PM, Tom Harding via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: On 7/22/2015 9:52 AM, Pieter Wuille via bitcoin-dev wrote: It would be irresponsible and dangerous to the network and thus the users of the software to risk forks, or to take a leading