Re: [bitcoin-dev] Horizontal scaling of blockchain

On Friday, 1 September 2017 20:15:53 CEST Cserveny Tamas wrote: > The usage growth seems to be more of exponential rather than linear. > Sooner or later the block size will need to be 4 mb then 40 mb, then what > is the real limit? Otherwise waiting times and thus the fees will just > grow

Re: [bitcoin-dev] Horizontal scaling of blockchain

On Friday, 1 September 2017 14:47:08 CEST Cserveny Tamas via bitcoin-dev wrote: > The fundamental problem is that if the miners add capacity it will only > increase (protect) their share of block reward, but does not increase the > speed of transactions. Adding more space in blocks has no effect

Re: [bitcoin-dev] A BIP proposal for conveniently referring to confirmed transactions

On Friday, 14 July 2017 20:43:37 CEST Clark Moody via bitcoin-dev wrote: > I can understand the desire to keep all reference strings to the nice > 14-character version by keeping the data payload to 40 bits I’m not so clear on this, to be honest. What is the point of having a user-readable

Re: [bitcoin-dev] Updating the Scaling Roadmap

On Wednesday, 12 July 2017 03:22:59 CEST Karl Johan Alm via bitcoin-dev wrote: > Bitcoin development differs from Linux kernel development in a number > of obvious ways, such as the fact Bitcoin is being "patched in > flight". I've heard this before and it doesn't make any sense to me. Just like

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

On Tuesday, 20 June 2017 00:41:49 CEST Gregory Maxwell via bitcoin-dev wrote: > Can someone make a case why saving no more than those figures would > justify the near total loss of privacy that filtering gives? First, your figures are wrong and also fall out of the sky with no justification.

Re: [bitcoin-dev] BIP148 temporary service bit (1 << 27)

On Monday, 19 June 2017 21:26:22 CEST Luke Dashjr via bitcoin-dev wrote: > To ease the transition to BIP148 and to minimise risks in the event miners > choose to perform a chain split attack, at least Bitcoin Knots will be > using the temporary service bit (1 << 27) to indicate BIP148 support. >

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

On Monday, 19 June 2017 18:30:18 CEST Jonas Schnelli wrote: > I personally would ALWAYS [snip] I mentioned that it was a usability point for a reason, and your personal behavior makes me want to quote one of the main UX guidelines; “You are not your user”

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

On Monday, 19 June 2017 17:49:59 CEST Jonas Schnelli wrote: > Hi > > > On Monday, 19 June 2017 14:26:46 CEST bfd--- via bitcoin-dev wrote: > >> It's been debated if [filtering of] unconfirmed transactions are > >> necessary, > > > > Why would it not be needed? Any SPV client (when used as a > >

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

On Monday, 19 June 2017 14:26:46 CEST bfd--- via bitcoin-dev wrote: > It's been debated if [filtering of] unconfirmed transactions are > necessary, Why would it not be needed? Any SPV client (when used as a payment-receiver) requires this from a simple usability point of view. -- Tom Zander

Re: [bitcoin-dev] Barry Silbert segwit agreement

On Saturday, 27 May 2017 01:09:10 CEST James Hilliard wrote: > > why? > > the main > issue is due to 0.13.1+ having many segwit related features active > already, including all the P2P components, the new network service > flag, the witness-tx and block messages, compact blocks v2 and >

Re: [bitcoin-dev] Barry Silbert segwit agreement

On Friday, 26 May 2017 23:30:37 CEST James Hilliard via bitcoin-dev wrote: > It would not be feasible to schedule any HF until one can be > completely sure BIP141 is active why? > Since it is likely a HF will take months of development and testing I > see this or something similar as the fastest

Re: [bitcoin-dev] Barry Silbert segwit agreement

On Friday, 26 May 2017 19:47:11 CEST Jacob Eliosoff via bitcoin-dev wrote: > Forgive me if this is a dumb question. Sorry for picking your email. I understand people want something different for the agreement, I know I do too. We have a specific agreement on the table, signed by a huge

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

On Friday, 26 May 2017 16:39:30 CEST Erik Aronesty wrote: > Linking a bit4 MASF with a bit4 "lock in of a hard fork in 6 months" is > something that will simply never happen for basic engineering reasons. The modifications to Bitcoin Core would take at most a day to do, plus a week to test. I’m

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

On Friday, 26 May 2017 10:02:27 CEST Cameron Garnham via bitcoin-dev wrote: > So, I started searching for the motivations of such a large amount of the > mining hash-rate holding a position that isn’t at-all represented in the > wider Bitcoin Community. My study of ASICBOOST lead to a ‘bingo’

Re: [bitcoin-dev] Full node "tip" function

I agree with you here, Erik. Greg's standard answer doesn’t apply to your suggestion. I think he was a bit too trigger happy because we have seen a lot of similar suggestions that have the Sybill issue he mentioned. On Thursday, 4 May 2017 15:15:02 CEST Erik Aronesty via bitcoin-dev wrote: > >

Re: [bitcoin-dev] Small Nodes: A Better Alternative to Pruned Nodes

On Wednesday, 19 April 2017 19:30:30 CEST David Vorick via bitcoin-dev wrote: > > I suggested something similar which is a much simpler version; > > https://zander.github.io/scaling/Pruning/ > Your proposal has a significant disadvantage: If every peer is dropping > 75% of all blocks randomly,

Re: [bitcoin-dev] Small Nodes: A Better Alternative to Pruned Nodes

On Monday, 17 April 2017 08:54:49 CEST David Vorick via bitcoin-dev wrote: > The best alternative today to storing the full blockchain is to run a > pruned node The idea looks a little overly complex to me. I suggested something similar which is a much simpler version;

Re: [bitcoin-dev] I do not support the BIP 148 UASF

On Friday, 14 April 2017 22:51:04 CEST James Hilliard wrote: > This doesn't remove the need for consensus rule enforcement of course. Thanks for confirming my point. This means that Gregory was incorrect saying that there is no risk to a non- upgraded node on a SegWit network mining a new

Re: [bitcoin-dev] I do not support the BIP 148 UASF

On Friday, 14 April 2017 21:33:49 CEST James Hilliard wrote: > This is false, > > Those "everyone can spend" transactions are prohibited from being > mined due to policy rules. I expected you to know this, but ok, I'll explain. A policy rule is not a protocol rule, a mining node is certainly

Re: [bitcoin-dev] BIP proposal draft: BIP43 "purpose" allocation for Ethereum

Thinking about this a bit, I support this proposal for a BIP. This is not Bitcoin, but address types are bound to meet in meat-space and it would be good to have a central place where this is defined. I would very much appreciate someone that worked on BIP32/BIP43 itself to comment on the

Re: [bitcoin-dev] I do not support the BIP 148 UASF

On Friday, 14 April 2017 09:56:31 CEST Gregory Maxwell via bitcoin-dev wrote: > Segwit was carefully engineered so that older unmodified miners could > continue operating _completely_ without interruption after segwit > activates. > They [Older nodes] can > upgrade to it [segwit] on their own

Re: [bitcoin-dev] I do not support the BIP 148 UASF

On Friday, 14 April 2017 18:50:47 CEST praxeology_guy via bitcoin-dev wrote: > Criticizing 148 without suggesting a specific alternative leaves the > community in disarray. Here is a list of clear alternatives; https://github.com/bitcoin/bips/ See the BIPs with number 010[1-8]. -- Tom Zander

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

The version field is still needed to actually allow future block version upgrades. We would cut off our road forward if that were to be blocked. On Friday, 7 April 2017 22:06:39 CEST Jimmy Song via bitcoin-dev wrote: > Currently, the version bits (currently 4 bytes, or 32 bits) in the header >

Re: [bitcoin-dev] BIP proposal: Generalized version bits voting (bip-genvbvoting)

On Tuesday, 4 April 2017 20:01:51 CEST Luke Dashjr via bitcoin-dev wrote: > BIP 9 provides a mechanism for having > miners coordinate softforks because they can make the upgrade process > smoother this way. But the same is not true of hardforks: miners are > essentially irrelevant to them, and

Re: [bitcoin-dev] BIP draft: Extended block header hardfork

6:47 AM, Tom Zander via bitcoin-dev > > <bitcoin-dev@lists.linuxfoundation.org> wrote: > > On Sunday, 2 April 2017 22:39:13 CEST Russell O'Connor via bitcoin-dev > > > > wrote: > >> Someone told me a while back that it would be more natural if we move &g

Re: [bitcoin-dev] BIP draft: Extended block header hardfork

On Sunday, 2 April 2017 22:39:13 CEST Russell O'Connor via bitcoin-dev wrote: > Someone told me a while back that it would be more natural if we move the > nHeight from the coinbase script to the coinbase locktime. Have you > considered doing this? That change would not be a consensus change

Re: [bitcoin-dev] BIP proposal: Generalized version bits voting (bip-genvbvoting)

On Monday, 3 April 2017 11:06:02 CEST Sancho Panza wrote: > ==Specification== > > To be elaborated. Please do elaborate :) The meat of the proposal is missing. > It is thought that only cosmetic changes are needed to generalize from > only soft forks to 'soft or hard forks', and to add the

Re: [bitcoin-dev] Inquiry: Transaction Tiering

On Wednesday, 29 March 2017 14:48:42 CEST Martin Stolze wrote: > Your > conception holds under the presupposition that all action of > hash-power is motivated by 'rational' economic interest. This shows you didn't think this through, instead, the concept holds true when there is even a small

Re: [bitcoin-dev] Inquiry: Transaction Tiering

On Monday, 20 March 2017 21:12:36 CEST Martin Stolze via bitcoin-dev wrote: > Background: The current protocol enables two parties to transact > freely, however, transaction processors (block generators) have the > authority to discriminate participants arbitrarily. Nag; they don’t have any

Re: [bitcoin-dev] Requirement for pseudonymous BIP submissions

On Saturday, 18 March 2017 16:23:16 CEST Chris Stewart via bitcoin-dev wrote: > As everyone in the Bitcoin space knows, there is a massive scaling debate > going on. One side wants to increase the block size via segwit, while the > other side wants to increase via hard fork. I have strong

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

On Tuesday, 28 March 2017 19:34:23 CEST Johnson Lau via bitcoin-dev wrote: > So if we really want to get prepared for a potential HF with unknown > parameters, That was not suggested. Maybe you can comment on the very specific suggestion instead? -- Tom Zander Blog: https://zander.github.io

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

On Tuesday, 28 March 2017 18:59:32 CEST Wang Chun via bitcoin-dev wrote: > Despite spam tx on the network, the block capacity is approaching its > limit, and we must think ahead. Shall we code a patch right now, to > remove the block size limit of 1MB, but not activate it until far in > the

Re: [bitcoin-dev] Encouraging good miners

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 receiving node to re-create it using the memory pool. Immediately getting double benefits by including

Re: [bitcoin-dev] Unique node identifiers (and BIP150)

On Wednesday, 8 March 2017 20:47:54 CET Jonas Schnelli via bitcoin-dev wrote: > Please Eric. Stop spreading FUD. > BIP150 has a fingerprint-free **OPTIONAL** authentication. It’s designed > to not reveal any node identifier/identity without first get a > crypto.-proof from other peer that he

Re: [bitcoin-dev] BIP150/151 concerns and some comments

On Tuesday, 14 February 2017 22:01:51 CET Jonas Schnelli via bitcoin-dev wrote: > >> - If you use one of the todays available SPV clients, you will reveal > >> your complete wallet content („~all your addresses") to every network > >> observer between you and the node you have connected to. This

Re: [bitcoin-dev] BIP150/151 concerns and some comments

On Tuesday, 14 February 2017 17:10:15 CET Jonas Schnelli via bitcoin-dev wrote: > - If you use one of the todays available SPV clients, you will reveal > your complete wallet content („~all your addresses") to every network > observer between you and the node you have connected to. This means, if

[bitcoin-dev] Changing the transaction version number to be varint

Hi all, In the transaction today we have a version field which is always 4 bytes. The rest of the integer encoding in a transaction is variable-size because it saves on bytes. Specifically, in practice this means that almost all of the transaction have bytes 2, 3 & 4 set to zero[1]. The

Re: [bitcoin-dev] Bitcoin Classic 1.2.0 released

On Saturday, 7 January 2017 21:15:11 CET Btc Drak via bitcoin-dev wrote: > There actually isn't an activation threshold in Bitcoin Classic. Thats partly correct. There is just not a formal one, there very much is an informal and practical threshold. I, and I'm not alone in this, think that a

Re: [bitcoin-dev] Bitcoin Classic 1.2.0 released

On Saturday, 7 January 2017 00:55:19 CET Eric Lombrozo wrote: > Your release announcement does not make it clear that Bitcoin Classic is > incompatible with the current Bitcoin network and its consensus rules. To explain why I didn't write that; Bitcoin Classic is not incompatible with the

[bitcoin-dev] Bitcoin Classic 1.2.0 released

Bitcoin Classic version 1.2.0 is now available from; This is a new major version release, including new features, various bugfixes and performance improvements. This release marks a change in strategy for Bitcoin Classic, moving from the very

Re: [bitcoin-dev] BIP - 'Block75' - New algorithm

On Monday, 2 January 2017 16:05:58 CET t. khan wrote: > On Mon, Jan 2, 2017 at 3:35 PM, Tom Zander wrote: > > If the input of your math is completely free and human created, how does > > it follow that it was math that created it ? > > Why do you want it math created anyway?

Re: [bitcoin-dev] BIP - 'Block75' - New algorithm

On Monday, 2 January 2017 21:19:10 CET Luke Dashjr wrote: > On Monday, January 02, 2017 8:35:40 PM Tom Zander via bitcoin-dev wrote: > > A maximum is needed, yes. But does it have to be part of the protocol? > > A simple policy which is set by node operators (reject block if gre

Re: [bitcoin-dev] BIP - 'Block75' - New algorithm

On Monday, 2 January 2017 14:32:24 CET t. khan wrote: > Math should decide the max block size, not humans (miners in this > case). The goal of Block75 is to manage the max block size without any > human intervention. If the input of your math is completely free and human created, how does it

Re: [bitcoin-dev] BIP - 'Block75' - New algorithm

On Monday, 2 January 2017 13:04:37 CET t. khan via bitcoin-dev wrote: > Thoughts? This proposal doesn't change the block size, it only changes the maximum block size. Which is expected, nothing bad there. The direct consequence of this, though is that the miners set the maximum block size.

Re: [bitcoin-dev] Forcenet: an experimental network with a new header format

On Sunday, 4 December 2016 21:37:39 CET Hampus Sjöberg via bitcoin-dev wrote: > > Also how about making timestamp 8 bytes? 2106 is coming up soon > > AFAICT this was fixed in this commit: > https://github.com/jl2012/bitcoin/commit/ fa80b48bb4237b110ceffe11edc14c813 >

Re: [bitcoin-dev] New BIP: Hardfork warning system

I am failing to see how you actually will detect a hard fork with this system. Maybe its because of this sentence not being very clear to me; «If a generalized block header chain with non-trivial total proof-of-work is emerging» Also, can you explain what you are actually trying to

Re: [bitcoin-dev] The Excessive-Block Gate: How a Bitcoin Unlimited Node Deals With Large Blocks

On Saturday, 26 November 2016 15:35:49 CET Peter R via bitcoin-dev wrote: > Therefore, it is in the best interest of miners to all set the same block > size limit (and reliably signal in their coinbase TX what that limit is, > as done by Bitcoin Unlimited miners). As a point of interest, last

Re: [bitcoin-dev] The Excessive-Block Gate: How a Bitcoin Unlimited Node Deals With Large Blocks

On Friday, 25 November 2016 20:45:20 CET Sergio Demian Lerner wrote: > I now think my reasoning and conclusions are based on a false premise: > that BU block size policies for miners can be heterogeneous. Agreed. > There can't be short forks because forks are not in the best interest of > the

Re: [bitcoin-dev] The Excessive-Block Gate: How a Bitcoin Unlimited Node Deals With Large Blocks

On Thursday, 24 November 2016 22:39:05 CET Sergio Demian Lerner via bitcoin- dev wrote: > Without a detailed analysis, unlimited block size seems a risky change to > Bitcoin, to me. What exactly do you think is a ‘change’ in bitcoin here? The concept of proof-of-work is that the longer a chain,

Re: [bitcoin-dev] Flexible Transactions.

On Monday, 21 November 2016 10:54:19 CET Russell O'Connor wrote: > Hi Tom, > > On Tue, Sep 20, 2016 at 1:15 PM, Tom via bitcoin-dev > linuxfoundation.org> wrote: > > The OP_CHECKSIG is the most well known and, as its name implies, it > > validates a signature. > > In the

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

Here is my thinking. The BIP process is about changes to a living project which is the bitcoin prptocol. This specific BIP got accepted and we know in the blockchain that this event (the acceptance) is recorded. Before a certain block the rules were one way, after they were changed. I have no

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

On Sunday, 16 October 2016 17:19:37 CEST Andrew C wrote: > On 10/16/2016 4:58 PM, Tom Zander via bitcoin-dev wrote: > > Lets get back to the topic. Having a longer fallow period is a simple > > way to be safe. Your comments make me even more scared that safety is > > n

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

On Sunday, 16 October 2016 12:49:47 CEST Douglas Roark via bitcoin-dev wrote: > It's not the website's fault if wallet devs aren't updating their > statuses. Besides, "WIP" can mean an awful lot of things. As I said, it would be nice to get an updated version so we can see more than 20%

Re: [bitcoin-dev] (no subject)

On Sunday, 16 October 2016 19:35:52 CEST Matt Corallo wrote: > You keep calling flexible transactions "safer", and yet you haven't > mentioned that the current codebase is riddled with blatant and massive > security holes. I am not afraid of people finding issues with my code, I'm only human.

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

On Monday, 17 October 2016 03:11:23 CEST Johnson Lau wrote: > > Honestly, if the reason for the too-short-for-safety timespan is that > > you > > want to use BIP9, then please take a step back and realize that SegWit > > is a contriversial soft-fork that needs to be deployed in a way that is > >

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

On Sunday, 16 October 2016 20:41:34 CEST Jorge Timón wrote: > You keep insisting on "2 months after activation", but that's not how > BIP9 works. We could at most change BIP9's initial date, but if those > who haven't started to work on supporting segwit will keep waiting for > activation, then

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

On Sunday, 16 October 2016 09:47:40 CEST Douglas Roark via bitcoin-dev wrote: > Would I want anyone to lose money due to faulty wallets? Of course not. > By the same token, devs have had almost a year to tinker with SegWit and > make sure the wallet isn't so poorly written that it'll flame out

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

On Sunday, 16 October 2016 12:35:58 CEST Gavin Andresen wrote: > On Sun, Oct 16, 2016 at 10:58 AM, Tom Zander via bitcoin-dev < > > bitcoin-dev@lists.linuxfoundation.org> wrote: > > The fallow period sounds wy to short. I suggest 2 months at minimum > > since a

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

The fallow period sounds wy to short. I suggest 2 months at minimum since anyone that wants to be safe needs to upgrade. Also, please comment on why you won't use the much more safe and much smaller Flexible Transactions. On Sunday, 16 October 2016 16:31:55 CEST Pieter Wuille via

Re: [bitcoin-dev] BIP 2 revival and rework

On Saturday, 15 October 2016 17:02:30 CEST Marco Falke wrote: > >> BIP 2 does not forbid you to release your work under PD in > >> legislations where this is possible > > > > It does, actually. > > Huh, I can't find it in the text I read. The text mentions "not > acceptable", but I don't read

Re: [bitcoin-dev] BIP 2 revival and rework

On Saturday, 15 October 2016 14:12:09 CEST Marco Falke wrote: > On Sat, Oct 15, 2016 at 1:00 PM, Tom Zander via bitcoin-dev > > <bitcoin-dev@lists.linuxfoundation.org> wrote: > > My suggestion (sorry for not explaining it better) was that for BIPS to > > be a publi

Re: [bitcoin-dev] BIP 2 revival and rework

On Saturday, 15 October 2016 12:11:02 CEST Marco Falke wrote: > On Sat, Sep 24, 2016 at 11:41 AM, Tom via bitcoin-dev > wrote: > > I'd suggest saying that "Share alike" is required and "Attribution" is > > optional. > > Please note there is no CC license

Re: [bitcoin-dev] DPL is not only not enough, but brings unfounded confidence to Bitcoin users

On Friday, 14 October 2016 04:51:01 CEST Daniel Robinson via bitcoin-dev wrote: > > Because if not, the DPL is still better than the status quo. > > Agreed. Also worth noting that it has a potential advantage over > unilateral patent disarmament, analogous to the advantage of copyleft > licenses

Re: [bitcoin-dev] Compact Block Relay BIP

On Sunday, May 08, 2016 03:24:22 AM Matt Corallo wrote: > >> ===Intended Protocol Flow=== > > > > I'm not a fan of the solution that a CNode should keep state and talk to > > its remote nodes differently while announcing new blocks. > > Its too complicated and ultimately counter-productive. > >

Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes

On Saturday, February 06, 2016 06:09:21 PM Jorge Timón via bitcoin-dev wrote: > None of the reasons you list say anything about the fact that "being lost" > (kicked out of the network) is a problem for those node's users. That's because its not. If you have a node that is "old" your node will

Re: [bitcoin-dev] [patch] Switching Bitcoin Core to sqlite db

On Monday 26 Oct 2015 11:06:56 Douglas Roark via bitcoin-dev wrote: > While not exactly the most rigorous link, > https://en.wikipedia.org/wiki/LevelDB#Bugs_and_Reliability seems like an > okay place to start. Thanks for that link! Another Google open source product I'll avoid like the plague ;)

Re: [bitcoin-dev] [patch] Switching Bitcoin Core to sqlite db

On Thursday 22 Oct 2015 17:26:42 Jeff Garzik via bitcoin-dev wrote: > It was noted that leveldb is unmaintained, and this is part of researching > alternatives that are maintained and reliable. Apart from it being unmaintained, any links to what are problems with levelDB?

Re: [bitcoin-dev] Memory leaks?

On Tuesday 20 Oct 2015 20:01:16 Jonathan Toomim wrote: > claimed that he had this memory usage issue on Linux, but not on Mac OS X, > under a GBT workload in both situations. If this is true, that would > suggest this might be a fragmentation issue due to poor memory allocation. Please make sure

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

On Monday 5. October 2015 18.03.05 Btc Drak via bitcoin-dev wrote: > However, I would like to challenge your assumption of point 1 that that by > Mike making a rabble, it somehow makes CLTV deployment controversial. His > arguments have been refuted. Unsuccessfully. > Simply making a noise does

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

On Monday 5. October 2015 20.33.04 s7r via bitcoin-dev wrote: > For example, I don't see this controversial nor a violation of the BIP > requirements. Mike had some fair objections, they were explained by > gmaxwell and Jorge, everybody understood. The explanation is clear, > with plausible

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

Gregory, you are good at language and its easy to write eloquent words. Looking at this little dialog, for instance; On Mon, Oct 5, 2015 at 3:56 PM, Sergio Demian Lerner wrote: > > 1) ignores him, which is against the established criteria that all > > technical objections coming from anyone

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

On Monday 5. October 2015 18.04.48 Gregory Maxwell wrote: > > Unsuccessfully. > > I think rather successfully. Arguing that BIP66 rollout was a full success is in the same park of "successful" ? Where for weeks people were told not to trust the longest chain until it was 30 blocks. Lets put

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

On Monday 5. October 2015 20.56.34 Gregory Maxwell wrote: > (In this case, I don't even believe we have any regulator > contributors that disagree). Regular contributor? Please explain how for a fork in the protocol should you only listen to regular Bitcoin Core contributors?

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

On Monday 5. October 2015 19.41.30 Gregory Maxwell wrote: > On Mon, Oct 5, 2015 at 7:13 PM, Tom Zander via bitcoin-dev > > <bitcoin-dev@lists.linuxfoundation.org> wrote: > > It is an eloquent change, but not really the topic we were discussing. It > > also makes you a