On Wed, Feb 10, 2016 at 6:14 AM, David Vorick via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> I'm not clear on the utility of more nodes. Perhaps there is significant
> concern about SPV nodes getting enough bandwidth or the network struggling
> from the load?
>
It is unfortunat
On Wed, February 10, 2016 5:14 pm, David Vorick via bitcoin-dev wrote:
>> I love seeing data! I was considering 0.10 nodes as 'unmaintained'
> because it has been a long time since the 0.11 release.
>
> https://packages.gentoo.org/packages/net-p2p/bitcoin-qt
>
> The Gentoo package manager still
> I love seeing data! I was considering 0.10 nodes as 'unmaintained'
because it has been a long time since the 0.11 release.
https://packages.gentoo.org/packages/net-p2p/bitcoin-qt
The Gentoo package manager still has 0.10.2 as the most recent stable
version. Getting a later version of the soft
Happy Lunar New Year Everyone!
Gavin,
> I suspect there ARE a significant percentage of un-maintained full
> nodes-- probably 30 to 40%. Losing those nodes will not be a problem, for
> three reasons:
The notion of large set ( 30% to 40% ) of un-maintained full nodes are not
evident on the netwo
On Tue, Feb 9, 2016 at 8:59 AM, Yifu Guo wrote:
>
> There are 406 nodes total that falls under the un-maintained category,
> which is below 10% of the network.
> Luke also have some data here that shows similar results.
> http://luke.dashjr.org/programs/bitcoin/files/charts/versions.txt
>
I love
Gavin, please don't quote that list on the Classic website. It's horribly
inaccurate and misleading to the general public.
> That testing is happening by the exchange, library, wallet, etc providers
> themselves. There is a list on the Classic home page:
>
> https://bitcoinclassic.com/
I know for
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.
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
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
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
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
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
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,
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
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
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
[mailto:bitcoin-dev-boun...@lists.linuxfoundation.org] On Behalf Of Jonathan
Toomim via bitcoin-dev
Sent: Monday, 8 February, 2016 01:11
To: Anthony Towns
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2
megabytes
On Feb 7
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
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
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 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
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 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
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 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
On Sat, Feb 06, 2016 at 10:37:30AM -0500, Gavin Andresen via bitcoin-dev wrote:
> 2) People are committing to spinning up thousands of supports-2mb-nodes
> during the grace period.
Why wouldn't an attacker be able to counter-sybil-attack that effort?
Who are these people?
On Sat, Feb 06, 2016 a
Gavin,
I saw this in your blog post:
"Miners producing up-version blocks is a coordination mechanism. Other
coordination mechanisms are possible– there could be a centrally determined
“flag day” or “flag block” when everybody (or almost everybody) agrees that a
change will happen."
Can you de
On Sat, Feb 06, 2016 at 04:11:58PM -0500, Peter Todd via bitcoin-dev wrote:
> On Sat, Feb 06, 2016 at 12:45:14PM -0500, Gavin Andresen via bitcoin-dev
> wrote:
> > On Sat, Feb 6, 2016 at 12:01 PM, Adam Back wrote:
> >
> > >
> > > It would probably be a good idea to have a security considerations
Its mostly a problem for exchanges and miners. Those entities need to
be on the network 100% of the time because they are using the network
100% of the time. A normal wallet user isn't taking payments every few
minutes like the exchanges are. "Getting booted off the network" is
not something to wor
On Sat, Feb 06, 2016 at 12:45:14PM -0500, Gavin Andresen via bitcoin-dev wrote:
> On Sat, Feb 6, 2016 at 12:01 PM, Adam Back wrote:
>
> >
> > It would probably be a good idea to have a security considerations
> > section
>
>
> Containing what? I'm not aware of any security considerations that
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 you list say anything about the fact that "being
> > lost" (kicked out of the network) is a problem for those node's u
On Saturday, February 06, 2016 3:37:30 PM Gavin Andresen wrote:
> I suspect there ARE a significant percentage of un-maintained full nodes--
Do you have evidence these are intentionally unmaintained, and not users who
have simply not had time to review and decide on upgrading?
> There is broad a
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 sto
On Sat, Feb 6, 2016 at 12:01 PM, Adam Back wrote:
>
> It would probably be a good idea to have a security considerations
> section
Containing what? I'm not aware of any security considerations that are any
different from any other consensus rules change.
(I can write a blog post summarizing o
On Feb 6, 2016 16:37, "Gavin Andresen" wrote:
>
> Responding to "28 days is not long enough" :
Any thoughts on the "95% better than 75%" and "grace period before miner
coordination instead of after" comments ?
> I suspect there ARE a significant percentage of un-maintained full
nodes-- probably
Hi Gavin
It would probably be a good idea to have a security considerations
section, also, is there a list of which exchange, library, wallet,
pool, stats server, hardware etc you have tested this change against?
Do you have a rollback plan in the event the hard-fork triggers via
false voting as
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 btcd lead
developer and they all agree "28 days is plenty of time."
For individuals... why would it take somebo
If it is to be uncontroversial and everybody will upgrade, there's no
fear of a "veto power" and there's no good reason not to wait for 95%
block version signaling for deployment coordination, ideally using
bip9.
But that's for chosing the exact block where to start. The grace
period to give time t
On Friday, February 05, 2016 8:51:08 PM Gavin Andresen via bitcoin-dev wrote:
> Blog post on a couple of the constants chosen:
> http://gavinandresen.ninja/seventyfive-twentyeight
Can you put this in the BIP's Rationale section (which appears to be mis-named
"Discussion" in the current draft)?
On Fri, Feb 5, 2016 at 8:51 PM, Gavin Andresen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> This has been reviewed by merchants, miners and exchanges for a couple of
> weeks, and has been implemented and tested as part of the Bitcoin Classic
> and Bitcoin XT implementations.
>
"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 running
that release. Three months later, about 50% of the network was running that
rele
This has been reviewed by merchants, miners and exchanges for a couple of
weeks, and has been implemented and tested as part of the Bitcoin Classic
and Bitcoin XT implementations.
Constructive feedback welcome; argument about whether or not it is a good
idea to roll out a hard fork now will be unp
42 matches
Mail list logo
