Here's a draft BIP I wrote almost a year ago. I'm going to look into revising
and completing it soon, and would welcome any suggestions for doing so.
This hardfork BIP aims to accomplish a few important things:
- Finally deploying proper merge-mining as Satoshi suggested before he left.
- Expandi
On Fri, Feb 05, 2016 at 03:51:08PM -0500, Gavin Andresen via bitcoin-dev wrote:
> Constructive feedback welcome; [...]
> Summary:
> Increase block size limit to 2,000,000 bytes.
> With accurate sigop counting, but existing sigop limit (20,000)
> And a new, high limit on signature hashing
To
This is a specific implementation of the "nuclear option" soft fork (or
"firm-fork").
The problem with any hard-fork (like) change is that there is an incentive
to add as much as possible and then the process gets bogged down.
Since the POW is based on the header 1, you could make header 3
expand
On Sat, Feb 6, 2016 at 3:46 PM, Luke Dashjr via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Saturday, February 06, 2016 5:25:21 PM Tom Zander via bitcoin-dev wrote:
> > On Saturday, February 06, 2016 06:09:21 PM Jorge Timón via bitcoin-dev
> wrote:
> > > None of the reasons yo
On 6 Feb 2016 4:41 p.m., "Gavin Andresen via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Responding to "28 days is not long enough" :
>
> I keep seeing this claim made with no evidence to back it up. As I said,
I surveyed several of the biggest infrastructure providers and the
I apologize if this discussion should be moved to -discuss, I'll let the
moderators decide, I've copied both.
And Gavin, I apologize for picking on you here, because certainly this
carelessness in how people represent "facts" applies to both sides, but
much of this discussion really infuriates me.
On Sun, Feb 07, 2016 at 09:16:02AM -0500, Gavin Andresen via bitcoin-dev wrote:
> There will be approximately zero percentage of hash power left on the
> weaker branch of the fork, based on past soft-fork adoption by miners (they
> upgrade VERY quickly from 75% to over 95%).
The stated reasoning f
Hello world,
The core roadmap calls for having patches at the ready for
implementing hardforking blocksize increases [0]. However, at least
to my understanding, is that the deployment of segregated witness has
a significant impact on what a hardforking blocksize increase should
look like -- with s
On Sun, Feb 07, 2016 at 10:06:06AM -0500, Alex Morcos via bitcoin-dev wrote:
> And the back and forth discussion over your BIP has been in large part a
> charade. People asking why you aren't picking 95% know very well why you
> aren't, but lets have an honest discussion of what the risks and in y
On Feb 7, 2016, at 7:19 AM, Anthony Towns via bitcoin-dev
wrote:
> The stated reasoning for 75% versus 95% is "because it gives "veto power"
> to a single big solo miner or mining pool". But if a 20% miner wants to
> "veto" the upgrade, with a 75% threshold, they could instead simply use
> thei
As I feared, request on feedback for this specific BIP has devolved into a
general debate about the merits of soft-forks versus hard-forks (versus
semi-hard Kosher Free Range forks...).
I've replied to several people privately off-list to not waste people's
time rehashing arguments that have been
You are making a very naïve assumption that miners are just looking for
profit for the next second. Instead, they would try to optimize their short
term and long term ROI. It is also well known that some miners would mine at
a loss, even not for ideological reasons, if they believe that their actio
This looks very interesting. The first time implementing it might be more
painful but that will make subsequent hardforks a lot easier.
Do you think it's good to include the median timestamp of the past 11 blocks
after the block height in coinbase? That would make it easier to use it as
activation
On Feb 7, 2016, at 9:24 AM, jl2...@xbt.hk wrote:
> You are making a very naïve assumption that miners are just looking for
> profit for the next second. Instead, they would try to optimize their short
> term and long term ROI. It is also well known that some miners would mine at
> a loss, even
On Feb 6, 2016, at 9:21 PM, Jannes Faber via bitcoin-dev
wrote:
> They *must* be able to send their customers both coins as separate
> withdrawals.
>
Supporting the obsolete chain is unnecessary. Such support has not been offered
in any cryptocurrency hard fork before, as far as I know. I do
I would expect that custodians who fail to produce coins on both sides
of a fork in response to depositor requests will find themselves in
serious legal trouble.
Especially if the price moves against either fork.
On 02/07/2016 10:55 AM, Jonathan Toomim via bitcoin-dev wrote:
>
> On Feb 6, 2016, a
From: Gavin Andresen [mailto:gavinandre...@gmail.com]
Sent: Friday, 5 February, 2016 06:16
To: Gregory Maxwell
Cc: jl2012 ; Bitcoin Dev
Subject: Re: [bitcoin-dev] Hardfork bit BIP
>It is always possible I'm being dense, but I still don't understand how this
>proposal makes a chain-forking situ
Patrick,
I would say that a company's terms of service should include their position
on this issue. It does not seem reasonable that they all are required to
provide access to coins on every single fork. Are custodial wallet users
also entitled to Clam, Zcash, and Decred, and others?
Regardless,
On Sun, Feb 7, 2016 at 7:03 PM, Patrick Strateman via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> I would expect that custodians who fail to produce coins on both sides
> of a fork in response to depositor requests will find themselves in
> serious legal trouble.
>
If the exchan
On Sunday, February 07, 2016 2:16:02 PM Gavin Andresen wrote:
> On Sat, Feb 6, 2016 at 3:46 PM, Luke Dashjr via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> > On Saturday, February 06, 2016 5:25:21 PM Tom Zander via bitcoin-dev
wrote:
> > > If you have a node that is "old" your
Is it me or did Gavin ignore Yifu's direct questions? In case you missed it
Gavin --
~
"We can look at the adoption of the last major Bitcoin core release to
guess how long it might take people to upgrade. 0.11.0 was released on 12
July, 2015. Twenty eight days later, about 38% of full nodes were
I agree that it seems like a safe assumption that adoption would be faster,
whether it is "very safe" and "significantly faster", whether it will be 6
times faster, all of those assumptions seems significantly less safe and
robust to me.
The nature of the bitcoin protocol, that it is a decentraliz
We don't have any evidence of how fast nodes will upgrade when faced with
an impending hard fork, but it seems like a very safe assumption that the
upgrade pace will be significantly faster. The hard fork case it is:
"upgrade or be kicked off the network". In the previous cases it has been,
"here
Segwit requires work from exchanges, wallets and services in order for
adoption to happen. This is because segwit changes the rules regarding
the Transaction data structure. A blocksize increase does not change
the Transaction rules at all. The blocksize increase is a change to
the Block structure.
> On Feb 7, 2016, at 2:27 PM, wrote:
>
> Normal version number only suggests softforks, which is usually not a concern
> for SPV clients.
Soft forks affect the security of low-confirmation (zero or one) transactions
sent to SPV wallets even more than hard forks, and because many users and
b
On Sun, Feb 07, 2016 at 03:20:27PM -0500, Gavin via bitcoin-dev wrote:
> > On Feb 7, 2016, at 2:27 PM, wrote:
> > Normal version number only suggests softforks, which is usually not a
> > concern for SPV clients.
> Soft forks affect the security of low-confirmation (zero or one) transactions
>
26 matches
Mail list logo
