>
> - Posts must concern the near-term development of the bitcoin core
> code or bitcoin protocol.
>
Are block size discussions considered acceptable, then?
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
Leaks are not the only explanation possible. Caches and fragmentation can
also give this sort of effect. Unfortunately the tools to debug this aren't
great. You could try a build with tcmalloc and use it to investigate heap
stats.
Odinn, trolling like a 3 year old will get you swiftly banned.
Hi Jorge,
I'm glad we seem to be reaching agreement that hard forks aren't so bad
really and can even have advantages. It seems the remaining area of
disagreement is this rollout specifically.
> a non-upgraded full node and an upgraded full will converge on what they
> see: "the most-work valid
ht, produce a much
> cleaner system for users.
>
>
>
>
>
>
>
>
> On Mon, Oct 5, 2015 at 6:59 AM, Mike Hearn via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Putting aside stupid arguments about who is older or who starting using
&
>
> As Greg explained to you repeatedly, a softfork won't cause a
> non-upgraded full node to start accepting blocks that create more
> subsidy than is valid.
>
It was an example. Adam Back's extension blocks proposal would, in fact,
allow for a soft forking change that creates more subsidy than
Hey Sergio,
To clarify: my *single* objection is that CLTV should be a hard fork. I
haven't been raising never-ending technical objections, there's only one.
I *have* been answering all the various reasons being brought up why I'm
wrong and soft forks are awesome and there do seem to be a
ther action.
>
>
>
> On Thu, Oct 1, 2015 at 12:08 AM, Tao Effect via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Dear list,
>>
>> Mike has made a variety of false and damaging statements about Bitcoin,
>> of which this is but one:
>>
>> O
>
> Exactly, all those "mini divergences" eventually disappear
>
A miner that has accepted a newly invalid transaction into its memory pool
and is trying to mine it, will keep producing invalid blocks forever until
the owner shuts it down and upgrades. This was happening for weeks after
P2SH
>
> Field experience shows it successfully delivers new features to end users
> without a global software upgrade.
>
The global upgrade is required for all full nodes in both types. If a full
node doesn't upgrade then it no longer does what it was designed to do; if
the user is OK with that, they
tl;dr Nothing I have read here has changed my mind. There is still no
consensus to deploy CLTV in this way.
> Yes, your article contained numerous factual and logical inaccuracies
> which I corrected
>
I responded to your response several times. It was not convincing, and I do
not think you
>
> I think from discussion with Gavin sometime during the montreal
> scaling bitcoin workshop, XT maybe willing to make things easy and
> adapt what it's doing.
If Core ships CLTV as is, then XT will have to adopt it - such is the
nature of a consensus system.
This will not change the fact
Hi Gregory,
> I'm surprised to see this response
Why? I have objected to the idea of soft forks many times. I wrote an
entire article about it in August. I also objected in April 2014, for
instance, where Pieter agreed with me that soft forks can result in ugly
hacks, and that they are "not
>
> Other than the fact that doing this as a soft fork requires an extra
> OP_DROP, how would doing this as a hard fork make any difference to SPV
> clients? If, as others have suggested, all clients warn the user on
> unrecognized nVersion
>
All clients do *not* do this. Why would they? What
Hi Jorge,
Yes, there is a difference. Assuming the hashrate majority upgrades, in the
> case of a softfork [snip] .. In the case of a hardfork [snip]
>
Yes, I know what the difference between them is at a technical level. You
didn't explain why this would make any difference to how fast
>
> Mining empty blocks is not fraud.
>
I didn't say it was, sorry, the comma was separating two list items. By
"fraud" I meant double spending. Mining only empty blocks would be a DoS
attack rather than double spending.
___
bitcoin-dev mailing list
>
> Can you explain exactly how you think wallets will "know" how to ignore
> the invalid chain?
>
I'm confused - I already said this. For a fork to work, hard or soft, there
must be support from a majority of the hash power.
Therefore, the usual SPV technique of following the highest work chain
There is *no* consensus on using a soft fork to deploy this feature. It
will result in the same problems as all the other soft forks - SPV wallets
will become less reliable during the rollout period. I am against that, as
it's entirely avoidable.
Make it a hard fork and my objection will be
>
> 1) Do you agree that CLTV should be added to the Bitcoin protocol?
>
> Ignoring the question how exactly it is added, hard-fork or soft-fork.
>
The opcode definition seems OK.
> 2) Will you add a IsSuperMajority() CLTV soft-fork to Bitcoin XT if it
>is added to Bitcoin Core?
>
Yes. It
>
> Also, in the US, despite overwhelming resistance on a broad scale,
> legislation continues to be presented which would violate the 2nd amendment
> right to keep and bear arms.
And yet the proposed legislation goes nowhere, and the USA continues to
stand alone in having the first world's
>
> Let me get this straight. You start this whole debate with a "kick the can
> down the road" proposal to increase the block size to 20MB, which obviously
> would require another hard fork in the future, but if someone else proposes
> a similar "kicka the can" proposal you will outright reject
>
> Your argument is that the state is not a threat to a system designed to
> deprive the state of seigniorage, because the state will see that system
> as too important?
>
And so we get to one of the hearts of the debate.
The axiom upon which you and NxtChg disagree is this: he/she believes
Any change that results in this happening all over again in a few years
does not have consensus.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
I think your summary of what people actually want from decentralisation is
pretty good, Justus.
> I don't believe that any Bitcoin user actually cares
> about decentralization, because none of them I've asked can define that
> term.
>
+1 Insightful
It's been quite impressive to see so many
NACK: stated rationales are invalid: both privacy and DoS (see below for
experimental data).
1 - Bloom filtering doesn't add privacy for node operators, it adds privacy
for lightweight wallets. And in fact, with a high FP rate it does do that.
Most users want both low bandwidth usage *and* query
It is just that no one else is reckless enough to bypass the review process
I keep seeing this notion crop up.
I want to kill this idea right now:
- There were months of public discussion leading to up the authoring of
BIP 101, both on this mailing list and elsewhere.
- BIP 101 was
The code was peer reviewed, in the XT project. I didn't bother submitting
other revisions to Core, obviously, as it was already rejected.
The quantity of incorrect statements in this thread is quite ridiculous.
___
bitcoin-dev mailing list
Hi Eric,
Sorry you feel that way. I devoted a big part of the article to trying to
fairly represent the top 3 arguments made, but ultimately I can't link to a
clear statement of what Bitcoin Core thinks because there isn't one. Some
people think the block size should increase, but not now, or not
Hey Jonas,
I think your analysis of what (some) users need is a good one.
We've discussed this before so I know you prefer your current approach, but
I personally would take a slightly different path to reach the same end:
1. Support serving of SPV wallets from pruned storage. This means
Whilst 1mb to 8mb might seem irrelevant from a pure computer science
perspective payment demand is not really infinite, at least not if by
payment we mean something resembling how current Bitcoin users use the
network.
If we define payment to mean the kind of thing that Bitcoin users and
Hey Jorge,
He is not saying that. Whatever the reasons for centralization are, it
is obvious that increasing the size won't help.
It's not obvious. Quite possibly bigger blocks == more users == more nodes
and more miners.
To repeat: it's not obvious to me at all that everything wrong with
How more users or more nodes can bring more miners, or more importantly,
improve mining decentralization?
Because the bigger the ecosystem is the more interest there is in taking
part?
I mean, I guess I don't know how to answer your question. When Bitcoin was
new it had almost no users and
I agree with Gavin - whilst it's great that a Blockstream employee has
finally made a realistic proposal (i.e. not let's all use Lightning) -
this BIP is virtually the same as keeping the 1mb cap.
Well, centralization of mining is already terrible. I see no reason why we
should encourage making
I do love history lessons from people who weren't actually there.
Let me correct your misconceptions.
Initially there was no block size limit - it was thought that the fee
market would naturally develop and would impose economic constraints on
growth.
The term fee market was never used back
Irrelevant what term was used - and as brilliant as Satoshi might have
been at some things, he obviously got this one wrong.
I don't think it's obvious. You may disagree, but don't pretend any of this
stuff is obvious.
Consider this: the highest Bitcoin tx fees can possibly go is perhaps a
It's worth noting that even massive companies with $30M USD of funding
don't run a single Bitcoin Core node
This has nothing to do with block sizes, and everything to do with Core not
directly providing the services businesses actually want.
The whole node count is falling because of block
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. Transactions that didn't make it into the
post-reorg chain go back into
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 is running the Bitcoin economy, and its developers do
have the authority to set its rules. This is enforced by
One solution would be for the client to combine all the addresses they are
interested in into a single bloom filter and send that to the server.
snip extra ideas
Hey Joseph,
All those ideas are ones we had years ago and they are implemented in the
current Bitcoin protocol.
The trick, as
Thanks Clement!
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
39 matches
Mail list logo
