Venzen Khaosan [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2015-06-22 to 2015-10-07
💬 Posted a total of 34 messages
📚 Participated in the following categories: bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub1uu2fve28mkg68uequseraz8gee7qg64733lr9r2g4c0xs5pmqnuslr4rpf

Profile Code

nprofile1qqsww9ykv4ramydr7vswgv373r5vulqyd2lgcl3j34y2u8ng2qasf7g35c2t6

Author Public Key

npub1uu2fve28mkg68uequseraz8gee7qg64733lr9r2g4c0xs5pmqnuslr4rpf

Show more details

Last Notes

2023-06-07 17:43:01

- reply

📅 Original date posted:2015-10-07
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Sure, and I share your view - I want to know what is happening in the
Bitcoin development space when I scan this email account.
Unfortunately, one moral imbecile keeps polluting this space.
I am confident that I have the debating resources and mental savvy to
show this individual to be an intellectual lightweight and a bankrupt
speaker that should shut his mouth, for good, in this list.
I'm not sure where your own allegiances lie, but if you think XT is a
bright idea, you can go there and participate to your heart's content.
In the meantime, this is a Bitcoin Core developer list and
self-proclaimed enemies of Core should not post here or pretend to
have consensus-blocking powers, as O'Hearn keeps capitulating.
Let me put this aspiring lord in his place and then we talk again. I
will knock him down in round 1 and knock him out in round 3. If you
love this man, go to xt-dev list and enjoy and spend your coins in
that alternate chain.
Venzen Khaosan
On 10/07/2015 05:26 PM, Patrick Mccorry (PGR) wrote:
> Hi,
>
> I do not mean to be rude (I am sure you have the best intentions).
> But I do not think this e-mail (or the others) are appropriate for
> the mailing list. I want to be notified by new developments in the
> community, not really about public debates of character. Please,
> can these e-mails be kept off-list?
>
> Paddy
>
> ________________________________________ From:
> bitcoin-dev-bounces at lists.linuxfoundation.org
> <bitcoin-dev-bounces at lists.linuxfoundation.org> on behalf of
> Venzen Khaosan via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> Sent: 07 October 2015 11:19
> To: Mike Hearn; Bitcoin Dev Subject: [bitcoin-dev] Public Debate
> Challenge
>
> Mike Hearn,
>
> I challenge you to a public debate with the following conditions:
>
> - the topic is Bitcoin - 15 minutes in length (19mins including
> breaks) - 3 sessions of 5 minutes each - each speaker makes one
> statement in each session, not exceeding 2mins - 2 minute breaks
> between sessions - we agree to an arbiter - a public venue with an
> international audience - I make the first statement versus your
> already well-established position and widely publicized views. -
> each speaker commits to making 3 statements and participating in
> the full duration of the event - 19 minutes - the footage will be
> published as-is with no editing or right to forfeiture, showing
> both participants at all times. - to protect myself from your
> "official" friends, the event will be unannounced and will start
> when you see me on an event panel.
>
> sincerely, Venzen Khaosan
> _______________________________________________ bitcoin-dev
> mailing list bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQEcBAEBAgAGBQJWFPZRAAoJEGwAhlQc8H1mKkUH/jAYVoTMT7OW0bg2dquYBmiF
pNbO5oaqO1F3QGLqlLs/S8h/rxkY0tfaae86HEZ/fVNn9r2k6aykmrrztAZdgOT+
p9a7Po/kdd5BPoJ1F84cTxaAiMtl7y8oPyT/np7Ky+Nnyxs2di5eKdV3UK4gKzpt
6xsCR16CinGC8LPveCkGHNgqlk0Of4sNpnkhW945oO2nJzVB3TogvhJQvecZ3hw9
MzIxj59lXI8EL9qhkE0Ufaia1fHfRorCU0qt7mAOxHaZt4Wy3CpgGqrrRGsqXdud
KC3xePRpCaRmLqyUQVXjXdlvANMnXje5dTg9LH0Gseuhb26RGfq7Z3lQ+3kacVo=
=gHMy
-----END PGP SIGNATURE-----

2023-06-07 17:43:00

- reply

📅 Original date posted:2015-10-07
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Mike Hearn,
I challenge you to a public debate with the following conditions:
- - the topic is Bitcoin
- - 15 minutes in length (19mins including breaks)
- - 3 sessions of 5 minutes each
- - each speaker makes one statement in each session, not exceeding 2mins
- - 2 minute breaks between sessions
- - we agree to an arbiter
- - a public venue with an international audience
- - I make the first statement versus your already well-established
position and widely publicized views.
- - each speaker commits to making 3 statements and participating in the
full duration of the event - 19 minutes
- - the footage will be published as-is with no editing or right to
forfeiture, showing both participants at all times.
- - to protect myself from your "official" friends, the event will be
unannounced and will start when you see me on an event panel.
sincerely,
Venzen Khaosan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQEcBAEBAgAGBQJWFPGuAAoJEGwAhlQc8H1m/6kH/RBdbnuVa/GwKDwgEJbz6p0W
1OKu51Td/IC9Ty5DRhD8is0tzgPtGdJ9I6BFfd548Nhj954YnHE/sKP5XSa75jke
3ombYCWPILrhk64XzIqBfpunygoERKDOUe1r8MmiSdtWY5XHWNEIWxhmydT2GCdZ
DRO3bMKVxBBGhGROxzh2fHHPQ6N2qSmWPRD6QEHMeTvNlN3YN1NyHYiblYZ+Ox8X
1fvemS7ecWhFRovDimiCxMX5yQQCTBSTWbBvyabkyyWUV3p3qgGk8mt+D7rFlLtt
1KnoY6kerW738E5Nd10xMZ5ifeyiD4wATvijLJ0CIa05kiuy0DkaaDYpd28J9tM=
=Qcvl
-----END PGP SIGNATURE-----

2023-06-07 17:43:00

- reply

📅 Original date posted:2015-10-07
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Exactly,
In the coming fee market crunch, any speculator would trade an
extended block in the implied direction and also hedge in the opposite
direction in case it gets rejected.
The speculative public will most likely trade in the same direction,
initially, but arbitrage and futures markets perspectives (generally
more informed) will go the opposite way and create a new chart pattern
that will precede contrarian price motion.
In the end, as the community illusion of non-interdependce fades, we'd
expect bitcoin price to tend to its natural condition: parity with the
most powerful fiat currency out there: the psychological King, the US
dollar.
After decades we could expect an inverse correlation to develop as the
majority world moves from paper to digital - barring a critical
survival event such as a solar EMP, which is due, but which I reserve
judgement upon for investment purposes.
You can buy coffee with XT bitcoins, but that is really small-minded
behavior in the current deflationary environment... Mike Hearn, you
economic imbicile, give me 15 minutes with you in public and I will
knock you out of the Bitcoin space forever...
Venzen Khaosan
On 10/07/2015 04:45 PM, Dr Adam Back via bitcoin-dev wrote:
> Micha I think you are correct, I dont think extension blocks (or
> sidechains for that matter) can allow soft-fork increase of the
> total Bitcoins in the system, because the main chain still enforces
> the 21m coin cap. A given extension block could go fractional, but
> if there was a run to get out, the last users out will lose, or
> they'll all take a hair-cut etc. So presumably users would decline
> to use an extension block with fractional bitcoin.
>
> I mean you could view it like say an exchange (mtgox?) that
> somehow accidentally or intentionally creates fictional Bitcoin
> IOUs in it's system, eg in some kind of pyramid scheme - that
> doesnt create more Bitcoins, it just means people who think they
> have IOUs for real Bitcoins, are fractional or fake. With an
> extension block or sidechain furthermore it is transparent so they
> will know they are fractional.
>
> Relatedly it seems possible to implement a sidechain with
> advertised demurrage, with an exit or entrance fee to discourage
> holding outside of the chain to avoid demurrage. There are
> apparently economic arguments for why people might opt in to that
> (higher velocity economic activity, gresham's law, merchants
> offering discounts for buying with demurrage Bitcoins, maybe lower
> per transaction fees because say miners can mine the demurrage).
> However that is a different topic, again not changing the number of
> coins in circulation.
>
> Adam
>
>
> On 7 October 2015 at 08:13, Micha Bailey via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>
>> On Monday, October 5, 2015, Mike Hearn via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>>
>>>> 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 is valid (or does anything else) by hiding one
>>> block inside another.
>>
>>
>> Maybe I'm missing something, but wouldn't this turn into a hard
>> fork the moment you try to spend an output created in one of
>> these extension blocks? So sure, the block that contains the
>> extension would be considered valid, but unupgraded validators
>> will not update the UTXO set accordingly, meaning that those new
>> TXOs can't be spent because, according to their rules, they don't
>> exist.
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQEcBAEBAgAGBQJWFPA4AAoJEGwAhlQc8H1m6VMH+wXreRpLb8VweIxVJ9mDJL2g
d3rfhLL+50gZTt8csYJ7f/0BzbcS7nICOlvqn3PLAIu+Usr06iPIJSfHezvJ0GvE
gbspU4lNZArScPjOVhrigrQVuN75KM2a84QW/hf/5Epf6rXWnClqc+IR/I33V/Yg
0LUUFcmSXjOHVE18Yh3PB0ELY5I8/JYSzYX0dTu5qpbWzcjXUDfCfqewLKEgveZB
+QGVrvMDPNxnx1AvMuMsmP3el/lvaNBTtuVjKhYZEgF8NhFB4hm/nLRSrMFOuBju
vZlE8gbAQQlShCicuanL+l8KHiUi4/o3O5dIGoI/FwVoiXDK88158hpDLh1slv0=
=GUI4
-----END PGP SIGNATURE-----

2023-06-07 17:42:59

- reply

📅 Original date posted:2015-10-07
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Warren,
I submitted a public apology for a false accusation I leveled at
Sergio Lerner but my message was bounced by the list.
Can you please confirm if there is a know reason for this.
I had also sent the message to his personal email account, but I think
it is important that a public apology be made as soon as possible, in
the interest of goodwill and setting the record straight.
regards,
Venzen Khaosan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQEcBAEBAgAGBQJWFMLXAAoJEGwAhlQc8H1mDvMH/iLQtUyTKfoeC/ztCRRD4kBl
QCIcFyoFzfF7COg38yvyl0N6V1JnUBTzMw3oSPhphKjH/Y5oRyLB+DQdEO9JQqnG
LDV04cbSEoF1TOPvIPAVCY2QetFruSn3thcfhV5NFdNXwF/zAMrGiRMu6p0OJK+d
6ky1fuhvm4tsfrj74elQH9MGXO5BulsaAQJqyAqxf4w8nG8pU/a+vfa7mPeQ7qbu
ypfNOY14yAk7bxaqy5c6kuSzJ1oCmiQePIIrWjZKffzEiAoTT8y6JpbLrQz5wsIh
HgMr3/Z6ktxMrJjO0Bb5qwq84uweelWzt4UfcO6wjecvnyCcSrjlNCC6BM/HZPg=
=ZsCj
-----END PGP SIGNATURE-----

2023-06-07 17:42:53

- reply

📅 Original date posted:2015-10-06
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Sergio Demain,
You and I have had our altercation, in private, about your assumptions
of authority in this community. That was fine when you told me "for
fuck's sake" on IRC. I'm a man and I made you see your error and
apologize for your trespass.
Now, you present me and the list with an interpretation of some higher
goal that an obviously low-level participant, Mike Hearn, is actioning
here.
No. What you espouse is not what Hearn had premeditated. It all
happened in your mind. "Agent" (quoting popular media) Hearn is a
compulsive contrarian and has a verifiable track record of opposing
and arguing against consensus wherever he endevors. According to
Snowden, he did harm to the public and to colleagues vis-a-vis NSA
surveillance while he held office at Google and he is doing the same
via XT. He is no longer at Google - supposedly by free will. I would
venture, from his own stated goals, that he is in Bitcoin in search of
a salary, even though he displays a fundamental lack of understanding
of Open Source methodology and ideology. And a misconception of
Bitcoin's ability to scale.
The self-proclaimed glory of bitcoinj is a false and empty claim. I
have had to code my nodes to ignore bitjoinj because of its disregard
for protocol policy. For numerous reasons they are more of an irritant
than a positive presence on the network.
You, Lerner, not having an issue with his fallacious position and
actions, speaks about you, too. But you "have nothing for or against
Mike personally" so he's just another participant, regardless of his
behavior and track record, then you give him a thumbs up? Many, maybe
a majority, including Satoshi, have expressed deplorement of O'Hearn
and Andresen. With or without Satoshi you can see the terminal
consensus breach these two populists had engaged in for yourself.
Please answer me and the list how their action does not warrant
rejection from the community?
Yet, for the rest of list members: Agent Hearn, a known co-operative,
shows up with challenges and you respond as if to an equal? A former
head-man, before things fell apart, now an accomplice of Agent Hearn,
Andresen, sprays criticism and you dutifully answer, as if to a Big
Man? Who is he? That self-proclaimed grumpy old-timer? "Run to Google
benchmarks" and there you go. Google? Come on! This is the man who
broke the fundamental consensus rule and now he's got you introducing
Google dependencies into Bitcoin? You're OK with that? Go to XT, you
won't find me or anyone in the community objecting to you and Gavin
playing with Google and all sorts of prefab code there.
Sergio, don't presume to tell me or the list what another man is
saying or what rhythmless jive he's playing. Like everyone here, I
have eyes to see and a mind to comprehend: Hearn is not capable of the
double-play you imply. Nor are you, for that matter. So, thanks for
cutting the cake and showing your true colors, but best you don't
speak for someone else. Speak for yourself so everything is clear and
allegiances don't taint you and whatever you may want to speak, for
yourself, later.
On 10/05/2015 10:56 PM, Sergio Demian Lerner via bitcoin-dev wrote:
> Some of the people on this mailing list are blindly discussing the
> technicalities of a soft/hard fork without realizing that is not
> Mike's main intention. At least I perceive (and maybe others too)
> something else is happening.
>
> Let me try to clarify: the discussion has nothing to do with
> technical arguments. I generally like more hard forks than soft
> forks (but I won't explain why because this is not a technical
> thread), but for CLTV this is quite irrelevant (but I won't explain
> why..), and I want CLTV to be deployed asap.
>
> Mike's intention is to criticize the informal governance model of
> Bitcoin Core development and he has strategically pushed the
> discussion to a dead-end where the group either:
>
> 1) ignores him, which is against the established criteria that all
> technical objections coming from anyone must be addressed until
> that person agrees, so that a change can be uncontroversial. If the
> group moves forward with the change, then the "uncontroversial"
> criteria is violated and then credibility is lost. So a new
> governance model would be required for which the change is within
> the established rules.
>
> 2) respond to his technical objections one after the other, on
> never ending threads, bringing the project to a standstill.
>
> As I don't want 2) to happen, then 1) must happen, which is what
> Mike wants. I have nothing for or against Mike personally. I just
> think Mike Hearn has won this battle. But having a more formal
> decision making process may not be too bad for Bitcoin, maybe it
> can actually be good.
>
> Best regards from a non-developer to my dearest developer friends,
> Sergio.
>
>
>
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQEcBAEBAgAGBQJWFATEAAoJEGwAhlQc8H1mlBgH/288r/v0J0FFj2HukN3l4YLj
5+2d4WRJk/r4jfTUQvBiinmEph0cNuY8gtCYssCsipiOe5Ep0k8oQ3Jd/KWx0fIn
v7eCRzHBLkPTDHd7gnrGSnIsHy1xpO7MGM79ROMOMjoQJUZqborxSxRfJVt5Mdqo
bxMcDL0n+tJbKa4dbmjLtARH6EbTIWvE7kKh8c5ZHbLkXTOPSt6gCL9GKSVM+i1u
mlF1m1TEBLSq4jQ2WJk/8aHHbN5IQr2KzpAEneP3tKqSvl/33b2oaW42LVKbxk95
kDnbtKrBChrHGbLeQ/SRb9NADmvIcnDim4NviphsEarPdl/9OyTW36x2u1j0Slk=
=zgDh
-----END PGP SIGNATURE-----

2023-06-07 17:42:40

- reply

📅 Original date posted:2015-10-06
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
That's for Mike Hearn. Sooner the better. Hong Kong, December?
Venzen Khaosan
On 10/07/2015 01:23 AM, Venzen Khaosan via bitcoin-dev wrote:
> Tell you what, eloquent guy...
>
> Give me 15 minutes in a public open mic session with you and i'll
> remove you from your high horse and close your voice in Bitcoin,
> for good.
>
> Guaranteed. You're too stupid for me to let you run loose with
> client funds and this great innovation.
>
> Anytime, anywhere. I'm ready to dismantle your intellectual
> bankruptcy in front of the world.
>
> I'll go for your psychological throat first.
>
> Sincerely, Venzen Khaosan.
>
>
>
> On 10/05/2015 11:56 PM, Mike Hearn via bitcoin-dev wrote:
>> 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 limitless number of such emails .... but on my side it's
>> still just a single objection. If CLTV is a hard fork then I
>> won't be objecting anymore, right?
>
>> CLTV deployment is clearly controversial. Many developers other
>> than me have noted that hard forks are cleaner, and have other
>> desirable properties. I'm not the only one who sees a big
>> question mark over soft forks.
>
>> As everyone in the Bitcoin community has been clearly told that
>> controversial changes to the consensus rules must not happen,
>> it's clear that CLTV cannot happen in its current form.
>
>> Now I'll be frank - you are quite correct that I fully expect
>> the Core maintainers to ignore this controversy and do CLTV as a
>> soft fork anyway. I'm a cynic. I don't think "everyone must
>> agree" is workable and have said so from the start. Faced with a
>> choice of going back on their public statements or having to make
>> changes to something they clearly want, I expect them to redefine
>> what "real consensus" means. I hope I'm wrong, but if I'm not
>> ..... well, at least everyone will see what Gavin and I have been
>> talking about for so many months.
>
>> But I'd rather the opcode is tweaked. There's real financial
>> risks to a soft fork.
>
>
>> _______________________________________________ bitcoin-dev
>> mailing list bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQEcBAEBAgAGBQJWFBLWAAoJEGwAhlQc8H1mRM8H/0p2sz0gtu62bB+NrllRgU20
C4imzMr904X7JicqDsGhtySGdyk8DuHBSK4k1A3pOgPb+DoNQhcOUfZ2ZTNgR2tT
yjJHrJP2X+g8YixyQiQNBf65bogTgeBGEizh/H33RSGzdHwoIfeVS5Qja/AMUnk1
4XO8d+t5OdtYdKANmR/uUZikrnOXd6KIt9rmJhYUjqmLWXbHzQkhES0mFvJ1BdVZ
ZHNjnWzoE74NAEmPqhhhtU/GCFKQhBq7HHAnqkMoeWk0mgJoGCc+b/4/PwchmUJq
CmVO2TJFrnHb4tYAFgw14tdbSe5ERYT0pHW4qM3gJlYL1ik03k0iQDZZ0eStaXM=
=bwvw
-----END PGP SIGNATURE-----

2023-06-07 17:42:39

- reply

📅 Original date posted:2015-10-06
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Tell you what, eloquent guy...
Give me 15 minutes in a public open mic session with you and i'll
remove you from your high horse and close your voice in Bitcoin, for
good.
Guaranteed. You're too stupid for me to let you run loose with client
funds and this great innovation.
Anytime, anywhere. I'm ready to dismantle your intellectual bankruptcy
in front of the world.
I'll go for your psychological throat first.
Sincerely,
Venzen Khaosan.
On 10/05/2015 11:56 PM, Mike Hearn via bitcoin-dev wrote:
> 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 limitless number of such emails .... but on my side it's still
> just a single objection. If CLTV is a hard fork then I won't be
> objecting anymore, right?
>
> CLTV deployment is clearly controversial. Many developers other
> than me have noted that hard forks are cleaner, and have other
> desirable properties. I'm not the only one who sees a big question
> mark over soft forks.
>
> As everyone in the Bitcoin community has been clearly told that
> controversial changes to the consensus rules must not happen, it's
> clear that CLTV cannot happen in its current form.
>
> Now I'll be frank - you are quite correct that I fully expect the
> Core maintainers to ignore this controversy and do CLTV as a soft
> fork anyway. I'm a cynic. I don't think "everyone must agree" is
> workable and have said so from the start. Faced with a choice of
> going back on their public statements or having to make changes to
> something they clearly want, I expect them to redefine what "real
> consensus" means. I hope I'm wrong, but if I'm not ..... well, at
> least everyone will see what Gavin and I have been talking about
> for so many months.
>
> But I'd rather the opcode is tweaked. There's real financial risks
> to a soft fork.
>
>
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQEcBAEBAgAGBQJWFBGjAAoJEGwAhlQc8H1mn2cH/0pTx1C0FK8shPSPaC3xB6sA
DpGTMrLWNai3i9VTwkUw8UvbqeL2QtZDghPdkDcvbmvOMc3UrOMQbc1eQ1eL6i3g
DiUCqUShOIAIvWJXGPTPNBulWBW9VkgK0y3uOprTd5D0VWKpWvDj+DMNqHaAC2Ab
JAfHx0mHlkTfrcBl30eAJWxoqG/ohu5QvTIP64AsK6w53qlbMcB13cES8mS/HJX9
MUtBcCbYRfF3Gu+OeYaEzzzXeuwsqql9qHr2wZYe9rECkSmYgL0DT5+WZiLY8B/x
E3dFtufR7yAHr91/gj9itOKf+unumhduX8LY8ubuIKmuwjdj30MDdNy7fqZ3uGs=
=lftV
-----END PGP SIGNATURE-----

2023-06-07 17:34:48

- reply

📅 Original date posted:2015-08-13
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Geir,
In the scenario below, you argue that the current 1MB limit would lead
to "constantly full" blocks. If the limit is increased to say 1.6GB
then a government or banking group may choose to utilize 1.5GB of the
capacity of each block (and pay fees or not) for their settlement
network. Then how did upping the blocksize remedy anything? Or is this
use-case not plausible?
I would like to ask you, or anyone on the list: when we say that
mining secures the network, what does that mean?
On 08/14/2015 05:01 AM, Geir Harald Hansen via bitcoin-dev wrote:
> 3) A few more people begin using bitcoin. Bitcoin buckles and
> dies.
>
> - Something happens a few months from now causing an influx of new
> users and more transactions. - Blocks are constantly full. - A
> backlog of transactions keeps growing indefinitely. - At first
> people say "bitcoin is slow". After a while they say "bitcoin
> doesn't work". - Changing the hard limit on block size requires a
> fork and takes too long. - As bitcoin no longer works people stop
> using it. - Bitcoin lives out the last of its days in the
> backwaters of the internet with only 5 users. They keep telling
> people "we increased the block size now". Unfortunately noone is
> listening anymore. - People laugh at you and say "I told you that
> buttcoin thing was doomed to fail. After all it wasn't real
> money."
>
> If the hard limit had been increased earlier then mining pools
> would have been able to react quickly by upping their own soft
> limit. But this was not the case and so ended Bitcoin.
>
> So in summary:
>
> By increasing the block size limit you run the risk of: - The
> transaction fee market takes a little longer to develop. By not
> increasing the limit you run the risk of: - Bitcoin dies. The end.
>
> Transaction fees should not be the main topic of this discussion,
> and probably not even a part of it at all. That seems outright
> irresponsible to me.
>
> Regards, Geir H. Hansen, Bitminter mining pool
>
> On 12.08.2015 11:59, Jorge Timón via bitcoin-dev wrote:
>> I believe all concerns I've read can be classified in the
>> following groups:
>>
>>> 1) Potential indirect consequence of rising fees.
>>
>> - Lowest fee transactions (currently free transactions) will
>> become more unreliable. - People will migrate to competing
>> systems (PoW altcoins) with lower fees.
>>
>>> 2) Software problem independent of a concrete block size that
>>> needs to be solved anyway, often specific to Bitcoin Core (ie
>>> other implementations, say libbitcoin may not necessarily share
>>> these problems).
>>
>> - Bitcoin Core's mempool is unbounded in size and can make the
>> program crash by using too much memory. - There's no good way to
>> increase the fee of a transaction that is taking too long to be
>> mined without the "double spending" transaction with the higher
>> fee being blocked by most nodes which follow Bitcoin Core's
>> default policy for conflicting spends replacements (aka "first
>> seen" replacement policy).
>>
>> I have started with the 3 concerns that I read more often, but
>> please suggest more concerns for these categories and suggest
>> other categories if you think there's more.
>> _______________________________________________ bitcoin-dev
>> mailing list bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJVzVHWAAoJEGwAhlQc8H1myaoH+QFo+eTqPqMps/h/Lt5P4Ker
UIyCbouatdrRnKqJlpa+dy70+nK+nkz6fizXLC8fuWFDLPQ2uk1cUnp7FPcJ+f6L
LdGiUktcF/osbA5DW/Xt1DQnClnfbR04oH3+l5ouwhTG2FL8018RQKTAZXYaQafE
/GUzXBZt+dxpENE2ZE0YDORcm62cysFB8KiqS7NmrNC3sig/Bnw0k8x8y745LcSO
j/icLJ/zlSVhtceb8AnSg5bC2xhKXrTsGQBfr4foDh78n0+xcbEQO/6xc29rydeB
l8VwzqCwyFZScM/4lhgYHgEB2KE3MecGNy0vh7jKVqh9lQUMlWtpHRy/Nony5mA=
=MEzL
-----END PGP SIGNATURE-----

2023-06-07 17:34:44

- reply

📅 Original date posted:2015-08-12
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jorge, you say 3 concerns at the end of your message but I only see 1)
and 2). Assuming you've got a 3) and will add it, I'll contribute:
4) General, undefined fear that something bad is going to happen when
nodes choke up on a backlog of transactions.
- - no specific symptoms are pointed at but presumably there is
"pre-traumatic stress" at play.
- - Bitcoin-based businesses are going to lose money, customers and
potentially fail
- - people will flee Bitcoin for another cryptocoin and Bitcoin will be
left in the corner, collecting dust and memories of it will fade as
SuperCoin with its big blocks becomes all things to all people.
5) Specific belief that the exchange rate will decline on network
unreliability
- - traders and investors will bid the price down, or
- - traders/investors will stop speculating all together because even if
their speculation is successful, they're not sure they'll be able to
get their bitcoin out of exchanges, what with the broken network and all.
- - The exchange rate reflects Bitcoin's value and not just speculation
guided by a few large players like in other markets.
6) Belief that Bitcoin's "cargo" is about to be delivered by fate:
- - see https://en.wikipedia.org/wiki/Cargo_cult
- - the cargo is variably presumed to be a range of hoped-for events: an
adoption surge, a speculative rally similar to (or bigger than) 2013,
or a global financial crisis that sees Bitcoin become the safe haven
of choice.
- - for the cargo to be delivered, a "runway" must be built - the larger
the runway, the larger the cargo delivery. If the current runway is
not expanded, then the cargo plane will go to a different island and
won't come to Bitcoin Island.
- - it is short-sighted and, in a way, ungrateful of the "generals" not
to expand the runway - it will be their fault that the cargo doesn't
get delivered and all the island's people, no the whole ocean's
islands, will suffer because of silly security concerns.
- - some people have taken the blueprints of the airbase and are
building a large airstrip elsewhere on Bitcoin Island, but nobody is
helping them build that long and wide runway. Everybody wants to
expand this moderate runway - even the renegades who started Big
Blocks Great Success airstrip.
- - The sacred site of No-Middle-Zero-Attack-Point is at the start of
the current runway. To expand it the site must be destroyed, but some
former generals and many people say: It doesn't matter, we want Cargo,
not a small attack surface. Just blast it!
On 08/12/2015 04:59 PM, Jorge Timón via bitcoin-dev wrote:
> I believe all concerns I've read can be classified in the following
> groups:
>
>> 1) Potential indirect consequence of rising fees.
>
> - Lowest fee transactions (currently free transactions) will
> become more unreliable. - People will migrate to competing systems
> (PoW altcoins) with lower fees.
>
>> 2) Software problem independent of a concrete block size that
>> needs to be solved anyway, often specific to Bitcoin Core (ie
>> other implementations, say libbitcoin may not necessarily share
>> these problems).
>
> - Bitcoin Core's mempool is unbounded in size and can make the
> program crash by using too much memory. - There's no good way to
> increase the fee of a transaction that is taking too long to be
> mined without the "double spending" transaction with the higher fee
> being blocked by most nodes which follow Bitcoin Core's default
> policy for conflicting spends replacements (aka "first seen"
> replacement policy).
>
> I have started with the 3 concerns that I read more often, but
> please suggest more concerns for these categories and suggest
> other categories if you think there's more.
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJVyyxLAAoJEGwAhlQc8H1mEmMH/j6ZAcsHIYT7+8EtOP6T8LTB
0M4njFlkMsT6owruY9sucIP5c+DjNXoTHqFdgdNnWluW2JNQ0L6wnbWSR9NSbo2h
WlwpMKV0o8XdEQIZV3ZH4kltlIH0napvddsjmvMZDiZU2R/2Lp6KVxK0NEPB4IOC
jZ4UM0v/XuYiu1I+zpnvi9MS3X/MTYzf7a5JZ9D6CiCksc+X18GtFLogKJG5uVRn
at58cdHQX/TgIhO/RcYV9PStztT93I6uh92RrQyRmXVMn9u2/bZZXTgk9CL9YkO0
g0Imw7vt0ieZ2E9m0QUlJ8tJQKEESflNI0ccachGPKpOKGTsshqbZ370uDKcDWA=
=v3a1
-----END PGP SIGNATURE-----

2023-06-07 17:34:24

- reply

📅 Original date posted:2015-08-08
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 08/08/2015 01:10 PM, Thomas Zander via bitcoin-dev wrote:
> On Friday 7. August 2015 23.53.43 Adam Back wrote:
>> On 7 August 2015 at 22:35, Thomas Zander via bitcoin-dev
>>> As we concluded in our previous email, the need to run a node
>>> is inversely proportional to the ability (or willingness) to
>>> trust others.
> []
>>> And lets face it, practically everyone trusts others with their
>>> money today.
>
>> Bitcoin's very reason for existence is to avoid that need. For
>> people fully happy to trust others with their money, Bitcoin may
>> not be as interesting to them.
>
> I'm making this a thread of its own because this is very serious.
>
> The idea that Bitcoins very reason for existence is to avoid
> trusting anyone but yourself is something I've heard before, and I
> have to comment because it is a destructive thought. It is very
> much untrue because we don't live in a black/white world.
I think the context is not that "Bitcoin's reason for existence is to
avoid trusting anyone but yourself", as you state above. This kind of
dystopia is not, in my view, what the advocates of trustlessness and
security are implying.
There are those instances where we have no option other than to trust
a centralized authority. They are mostly self-appointed and do not
have the interests of the rest of us in mind. The central bank is the
obvious example - they impose their currency as "official" and then
devalue our savings and purchasing power through money supply
inflation - without our permission and in betrayal of the trust
relationship. Bitcoin allows one to hold money and to conduct money
transactions, transmit value, and so forth without having to trust
*them* - the central bank, or anyone.
In another example, we want to conduct escrow and have to trust the
notary, because of his reputation and framed certificate, but Bitcoin
multisig makes the degree of trust between the escrow parties
irrelevant, so no apparently trustworthy "gentleman" merchant (back
then or now) can socially engineer a transaction and scam us.
I don't know if my reply and its examples is over-simplistic but it
seems you were making a moral appeal that the notion of trustlessness
was destructive - I just wanted to contextualize it to relevant use
cases. It follows, and this is what I understand from Adam's message,
that security and protection of decentralization are paramount
concerns if we want to retain the trustlessness that makes Bitcoin so
useful and powerful.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJVxcZSAAoJEGwAhlQc8H1mmAUH/RprBA/tz13/CIJTQ4HHYU5v
kBAyirwhkx5NEvovFGV40PNpIE7OLqfoN2ThpwJSO8fqnPwbcGEr1qvZAaN9A68y
GD1sjw2y+8+hQUtrikMurBFzCX4msBvfYNPHX4J7SBR9qdxC9L7p6HaY5fvdwpQW
DmUMidKuRPpWH5AL9DqB9ZwHtPZ8mVaJGHMw1aI9QV0cTlq49ktbt/246wAjtRkb
Myw2c9hKT2WIwzmWcruokSXJ4yza6DGYKrcyzprIDCJFEj29geoIderyU+0qzRQ7
julB3Ft05xp2F6LheeH40wa7iyeRs6LWRNr2qElutu6Ta7Rvlg5ZCUGN52SGQtY=
=3rcg
-----END PGP SIGNATURE-----

2023-06-07 17:33:52

- reply

📅 Original date posted:2015-08-12
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 08/12/2015 10:35 AM, Elliot Olds via bitcoin-dev wrote:
> On Tue, Aug 11, 2015 at 2:51 PM, Pieter Wuille via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> On Tue, Aug 11, 2015 at 11:35 PM, Michael Naber
> <mickeybob at gmail.com <mailto:mickeybob at gmail.com>> wrote:
>
> Bitcoin would be better money than current money even if it were a
> bit more expensive to transact, simply because of its other great
> characteristics (trustlessness, limited supply, etc). However...
> it is not better than something else sharing all those same
> characteristics but which is also less expensive. The best money
> will win, and if Bitcoin doesn't increase capacity then it won't
> remain the best.
>
>
> If it is less expensive, it is harder to be reliable (because it's
> easier for a sudden new use case to outbid the available space),
> which is less useful for a payment mechanism.
>
>
> It depends on which use case's reliability that you focus on. For
> any specific use case of Bitcoin, that use case will be more
> reliable with a larger block size (ignoring centralization
> effects).
I read through your message and see the point you're trying to make,
but would like to point out that it is not useful to talk about
hypothetical scenarios involving Bitcoin that include the supposition
"ignoring centralization effects".
Decentralization concerns are fundamental to this innovation, else it
loses its meaning and value. And that's the trade-off that Pieter,
Jorge, Martin, Adam and others have referring to during the past 24
hours: in order to have a secure Bitcoin that is not vulnerable to
centralization, certain sacrifices have to be made and the Consensus
Rule of a relatively small blocksize is the main protection we
currently have.
There are a lot of "larger blocks, more transactions" arguments being
made that overlook this core axiom of decentralization. That is why
the developers and thinkers with the deepest understanding of this
protocol are pointing out the need for another layer on top of
Bitcoin. That is where the scaling can take place to cater for the
use-cases of more txns, quicker txns, remittance, etc. and with it
increased adoption.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJVys/tAAoJEGwAhlQc8H1mDOAH/1JRseGJWFKGsb4v7rapdcuY
V6t4EAeoz8q7xvn1SeOdXzwY1wTOiThwqaWEnEzRfFoW6JYhsHx3rQa9D+s8z2Bq
+lQ4oqkpOCcM6J3WAevzggWdzdP+xF8ztaRG5ynOge+m2lb1A2liadjSaeREz8/v
kEFSfT2V+QbmF+plkXtr7g0efMQq97Qv71hZ8tD+kmVMe5PDmARNwumzwIZ33H0z
eiCK3zombKVYNx7bw20pv8GhWp9z7LsKLJpLwKtuTxjgxG+NYi2FcbVwt3R9MB6/
TBsT4pmIvu29bIqWL2MDYLLnbU+cQTJNFSrrJar/aukqd5YlRDrY2Ikz82Ku86E=
=1bDu
-----END PGP SIGNATURE-----

2023-06-07 17:33:49

- reply

📅 Original date posted:2015-08-12
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Your concern for adoption is valid yet there are a few assumptions in
your discussion and they are a common thread in the current wave of
"bigger blocksize" topics.
1) Supplying bigger blocks will meet the demand of more people:
Anyone can transact via Bitcoin. By increasing blocksize and making
more transactions possible at low fees, what's to stop a large
corporation, bank or government from using the protocol as a cheap
settlement mechanism. They don't have to fund or develop their own
(well, Ecuador has, for this exact use-case) and perhaps the utility
and capacity of the Bitcoin network means reliability and low fees
(cheaper than a bank clearance, say) for their use-case. In the
process they hog xMB of space in each block and discussion about a
capacity limit continues in this list. Increased supply *will* be
utilized - by all kinds of entities - not only the girl next-door and
the unbanked proletariat.
2) Dissatisfied users will move to alt-coins so Bitcoin better be
careful...
The assumption here is that the best skills and most able minds are
fairly evenly distributed amongst alt-coin dev teams. I doubt this is
true and the notion underestimates the quality of developer that is
attracted to Bitcoin Core to apply themselves to this project, often
self-funded. There are few (if any) comparable cryptocurrencies or cc
dev teams out there. Hence the Bitcoin market cap, the large
stakeholder industry, and the established brand.
3) Bitcoin is better money.
Yes, indeed. It's genius and revolution. Yet, it does not fit every
use-case. I know people don't like it when I make this example, but
it's the truth where I live, and by extension, in many places in the
world:
I live in rural Southeast Asia. Some houses have electricity and some
don't: by choice, because rural lifestyle in the tropics does not
always require you to have electricity. People charge their mobile
phones at the community eating house every other day. The electricity
supply is unreliable. I've had to rig a solar charging system to a
UPS, but most people around here have no choice but to deal with
intermittent power cuts. The local market has a diesel generator, so
constant electricity, but if a power cut lasts for long enough the
local cellular mast battery backup depletes and then there is no
cellular connectivity - the only means of accessing the internet.
Now, how does one expect this community to use or adopt
cryptocurrency? They are mostly unbanked, get paid fiat wages at the
end of the week and spend fiat on commodities, rent, food and
entertainment like the rest of the world. But Bitcoin is not a "better
money" in their case, and who knows for how long this condition will
remain true.
4) TBD
The notion that there be dragons at the capacity limit is unfounded
and reactionary. We have to make the journey and find out what is, in
fact, there at the edge - as many others have argued in the list. This
is our opportunity to make scientific observation and discovery for
the benefit of Bitcoin - while it is still in its early years and the
capacity limit untested.
Who knows? The outcome may be an informed decision to implement bigger
blocks. Informed. Based not on fear and uncertainty but on empirical
observation and facts.
On 08/12/2015 04:39 AM, Michael Naber via bitcoin-dev wrote:
> Sure, most people probably would be happy with cheaper off-chain
> systems. There already are and will probably continue to be more
> transactions happening off-chain partly for this very reason.
> That's not the issue we're trying to address though: The main chain
> is the lynch-pin to the whole system. We've got to do a good job
> meeting demand that people have for wanting to utilize the
> main-chain, or else we'll risk being replaced by some other
> main-chain solution that does it better.
>
> On Tue, Aug 11, 2015 at 4:34 PM, Adam Back <adam at cypherspace.org
> <mailto:adam at cypherspace.org>> wrote:
>
> So if they dont care about decentralisation, they'll be happy
> using cheaper off-chain systems, right?
>
> Adam
>
> On 11 August 2015 at 22:30, Angel Leon <gubatron at gmail.com
> <mailto:gubatron at gmail.com>> wrote:
>> tell that to people in poor countries, or even in first world
> countries. The
>> competitive thing here is a deal breaker for a lot of people who
> have no
>> clue/don't care for decentralization, they just want to send
>> money
> from A to
>> B, like email.
>>
>> http://twitter.com/gubatron
>>
>> On Tue, Aug 11, 2015 at 5:23 PM, Adam Back via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>>>
>>> I dont think Bitcoin being cheaper is the main characteristic
>>> of Bitcoin. I think the interesting thing is trustlessness -
>>> being able to transact without relying on third parties.
>>>
>>> Adam
>>>
>>>
>>> On 11 August 2015 at 22:18, Michael Naber via bitcoin-dev
>>> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>>>> The only reason why Bitcoin has grown the way it has, and in
> fact the
>>>> only reason why we're all even here on this mailing list
>>>> talking
> about this,
>>>> is because Bitcoin is growing, since it's "better money than
>>>> other
> money".
>>>> One of the key characteristics toward that is Bitcoin being
> inexpensive to
>>>> transact. If that characteristic is no longer true, then
> Bitcoin isn't
>>>> going to grow, and in fact Bitcoin itself will be replaced by
>>>> better
> money
>>>> that is less expensive to transfer.
>>>>
>>>> So the importance of this issue cannot be overstated -- it's
> compete or
>>>> die for Bitcoin -- because people want to transact with
>>>> global
> consensus at
>>>> high volume, and because technology exists to service that
>>>> want,
> then it's
>>>> going to be met. This is basic rules of demand and supply. I
>>>> don't
> necessarily
>>>> disagree with your position on only wanting to support
> uncontroversial
>>>> commits, but I think it's important to get consensus on the
> criticality
>>>> of the block size issue: do you agree, disagree, or not take
>>>> a
> side, and
>>>> why?
>>>>
>>>>
>>>> On Tue, Aug 11, 2015 at 2:51 PM, Pieter Wuille
> <pieter.wuille at gmail.com <mailto:pieter.wuille at gmail.com>>
>>>> wrote:
>>>>>
>>>>> On Tue, Aug 11, 2015 at 9:37 PM, Michael Naber via
>>>>> bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>>>>>>
>>>>>> Hitting the limit in and of itself is not necessarily a
>>>>>> bad
> thing. The
>>>>>> question at hand is whether we should constrain that
>>>>>> limit
> below what
>>>>>> technology is capable of delivering. I'm arguing that not
>>>>>> only we should not, but that we could not even if we
>>>>>> wanted to, since
> competition
>>>>>> will deliver capacity for global consensus whether it's
>>>>>> in Bitcoin
> or in
>>>>>> some other product / fork.
>>>>>
>>>>>
>>>>> The question is not what the technology can deliver. The
> question is
>>>>> what price we're willing to pay for that. It is not a
>>>>> boolean "at
> this size,
>>>>> things break, and below it, they work". A small constant
>>>>> factor increase will unlikely break anything in the short
>>>>> term, but it will
> come with
>>>>> higher centralization pressure of various forms. There is
>>>>> discussion
> about
>>>>> whether these centralization pressures are significant, but
>>>>> citing
> that it's
>>>>> artificially constrained under the limit is IMHO a
> misrepresentation.
>>>>> It is constrained to aim for a certain balance between
>>>>> utility and
> risk, and
>>>>> neither extreme is interesting, while possibly still
>>>>> "working".
>>>>>
>>>>> Consensus rules are what keeps the system together. You
>>>>> can't
> simply
>>>>> switch to new rules on your own, because the rest of the
> system will
>>>>> end up ignoring you. These rules are there for a reason.
>>>>> You and I
> may agree
>>>>> about whether the 21M limit is necessary, and disagree
>>>>> about whether
> we need
>>>>> a block size limit, but we should be extremely careful
>>>>> with
> change. My
>>>>> position as Bitcoin Core developer is that we should merge
> consensus
>>>>> changes only when they are uncontroversial. Even when you
>>>>> believe a more invasive change is worth it, others may
>>>>> disagree, and the risk from
> disagreement
>>>>> is likely larger than the effect of a small block size
>>>>> increase
> by itself:
>>>>> the risk that suddenly every transaction can be spent twice
>>>>> (once
> on each
>>>>> side of the fork), the very thing that the block chain was
>>>>> designed to prevent.
>>>>>
>>>>> My personal opinion is that we should aim to do a block
>>>>> size
> increase
>>>>> for the right reasons. I don't think fear of rising fees
>>>>> or
> unreliability
>>>>> should be an issue: if fees are being paid, it means
>>>>> someone is
> willing to pay
>>>>> them. If people are doing transactions despite being
> unreliable, there
>>>>> must be a use for them. That may mean that some use cases
>>>>> don't fit
> anymore,
>>>>> but that is already the case.
>>>>>
>>>>> -- Pieter
>>>>>
>>>>
>>>>
>>>> _______________________________________________ bitcoin-dev
>>>> mailing list bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>>>>
>>>
>>> _______________________________________________ bitcoin-dev
>>> mailing list bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
>
>
>
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJVyuNYAAoJEGwAhlQc8H1mUwgH/0//DMUJ7E5npMYLg5HA1cPa
DM0o9L/Dwp5LN/Pn1gnCQr/57YyvcVYxCbI7QCAgwocz3WhL58DOPe+4XxKoqAz0
BoDp54rBEEWTv7E944LhyTHyhx4Fv4ZTSsGAoBOBQxcZL5Xn5zxwGoMQNBJAsB19
ypYwy3n6hlwYNblyIKVQNmpvN4bb1/KG3r7BarSUM+xBZ/wsTFT49nomFttn/nIo
HW0jfLQ4qjFWEbXvI0vn96HHziH9ijE08bRbEtPyW/cmaznWh1sWuRbYwvmKTyPn
g0f4iJW0xmEHo43grYutjNwayRFwdc1BEPho4HSTCpcJFOemrF7hCHXdgWsaVEM=
=x1Hf
-----END PGP SIGNATURE-----

2023-06-07 17:33:01

- reply

📅 Original date posted:2015-08-04
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
correction:
My finance readers, in one camp, and Bitcoin investors, in the other,
want to see the XT 8MB hard-fork testing data that you mentioned for
BIP101 (not 100).
- -------- Forwarded Message --------
Subject: Re: [bitcoin-dev] Block size following technological growth
Date: Tue, 04 Aug 2015 21:30:40 +0700
From: Venzen Khaosan via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org>
Reply-To: venzen at mail.bihthai.net
Organization: Bihthai Bai Mai
To: Gavin Andresen <gavinandresen at gmail.com>, Bitcoin Dev
<bitcoin-dev at lists.linuxfoundation.org>
On 08/04/2015 08:12 PM, Gavin Andresen via bitcoin-dev wrote:
> On Tue, Aug 4, 2015 at 7:27 AM, Pieter Wuille via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> I would say that things already demonstrately got terrible. The
> mining landscape is very centralized, with apparently a majority
> depending on agreements to trust each other's announced blocks
> without validation.
>
> And that is a problem... why?
>
> As far as I can tell,
[snip]
It's a big problem. What are you dismissing it for?
With Bitcoin in fledgling 0.x version state this is neither desirable
nor encouraging.
Development did not freeze at some time in the past and now we see how
the userbase reacts. Miners, btw, are arguibly still a class of user
as long as they are guaranteed coinbase.
When they start making and proving themselves useful in a free
floating fee market absent coinbase subsidy, we can revisit this
topic, with the benefit of hindsight.
> As Bitcoin grows, pieces of the ecosystem will specialize.
> Satoshi's original code did everything: hashing, block assembly,
> wallet, consensus, network. That is changing, and that is OK.
[snip]
>
> And I think the current "demonstrably terrible" Bitcoin system is
> still INCREDIBLY interesting.
>
Pieter never said it wasn't interesting, so this emphatic statement is
strange - like someone is trying to convince an audience - but
anyway... as you, a veritable spring-chicken by your actions and
words, said the other day: having graduated in '88 you're "old" and
speak from experience. Don't come with that jive, bossy man - bring
facts and testing to the technical list.
My finance readers, in one camp, and Bitcoin investors, in the other,
want to see the XT 8MB hard-fork testing data that you mentioned for
BIP100.
"Being ignorant is not so much a shame, as being unwilling to learn."
- - Benjamin Franklin
> -- -- Gavin Andresen
>
Venzen Khaosan
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJVwM93AAoJEGwAhlQc8H1mwcEH/RwxpWyvjlWBrPok5GNRed+/
8O46a4G1T6+Y2+yKWDFQTqG0D2oFEqunHW1A+e7UYABrhijbr1Xwpv0Y//VSuY3p
TnRXPj3+q3j4BdB607y5i0jCo61G4IrXaCUEHpBMzrD5T7SMDC1a31FLgAjx9WDM
etKmT9doWn9aiWzxAl/q8SEY4M04RLyS5kijs95M9YMGp1KVw2jNDfJM37EhPDu2
qDUMQEvcq0qTPCeHn6tCaXC0rWzIpylE6Xaso3VMepmbdzf0Dea92asBmmE0ygsW
Tcfx95UWW+Bb/h2JEO3TCjKpLCwdfiWP/2eXIMKkcdSJIVf/yE32gIxzqPx5ogU=
=BwgG
-----END PGP SIGNATURE-----

2023-06-07 17:32:57

- reply

📅 Original date posted:2015-08-04
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
It is not scientific or sensible to go from proposal stage straight to
voting and then implementation stage.
The proposals you have diligently gathered, summarized and presented
in your document must go through testing, and scenario simulation with
published results, in order for objective evaluation to be made possible.
For that matter, even "running up against a capacity limit" has not
been simulated or tested. Additionally, (and looking the other way)
there is a lack of provision for scaling DOWN in the current proposals
- - hard to envision, yes - but what goes up will eventually come down.
A global credit contraction is not unlikely, nor is natural disaster,
and these scenarios have implications for usage, scale, degree of
decentralization and security.
CS is science, there is no reason for this generation not to apply
rigorous Computer Science to Bitcoin.
Venzen
On 08/04/2015 02:50 PM, jl2012 via bitcoin-dev wrote:
> As now we have some concrete proposals
> (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009808.html),
>
>
I think we should wrap up the endless debate with voting by different
> stakeholder groups.
>
> --------------------------------- Candidate proposals
>
> Candidate proposals must be complete BIPs with reference
> implementation which are ready to merge immediately. They must
> first go through the usual peer review process and get approved by
> the developers in a technical standpoint, without political or
> philosophical considerations. Any fine tune of a candidate proposal
> may not become an independent candidate, unless it introduces some
> “real” difference. “No change” is also one of the voting options.
> --------------------------------- Voter groups
>
> There will be several voter groups and their votes will be counted
> independently. (The time frames mentioned below are just for
> example.)
>
> Miners: miners of blocks with timestamp between 1 to 30 Sept 2015
> are eligible to vote. One block one vote. Miners will cast their
> votes by signing with the bitcoin address in coinbase. If there are
> multiple coinbase outputs, the vote is discounted by output value /
> total coinbase output value. Many well-known pools are reusing
> addresses and they may not need to digitally sign their votes. In
> case there is any dispute, the digitally signed vote will be
> counted.
>
> Bitcoin holders: People with bitcoin in the UTXO at block 372500
> (around early September) are eligible to vote. The total “balance”
> of each scriptPubKey is calculated and this is the weight of the
> vote. People will cast their votes by digital signature. Special
> output types: Multi-sig: vote must be signed according to the
> setting of the multi-sig. P2SH: the serialized script must be
> provided Publicly known private key: not eligible to vote
> Non-standard script according to latest Bitcoin Core rules: not
> eligible to vote in general. May be judged case-by-case
>
> Developers: People with certain amount of contribution in the past
> year in Bitcoin Core or other open sources wallet / alternative
> implementations. One person one vote.
>
> Exchanges: Centralized exchanges listed on Coindesk Bitcoin Index,
> Winkdex, or NYSE Bitcoin index, with 30 days volume >100,000BTC
> are invited. This includes Bitfinex, BTC China, BitStamp, BTC-E,
> itBit, OKCoin, Huobi, Coinbase. Exchanges operated for at least 1
> year with 100,000BTC 30-day volume may also apply to be a voter in
> this category. One exchange one vote.
>
> Merchants and service providers: This category includes all
> bitcoin accepting business that is not centralized fiat-currency
> exchange, e.g. virtual or physical stores, gambling sites, online
> wallet service, payment processors like Bitpay, decentralized
> exchange like Localbitcoin, ETF operators like Secondmarket Bitcoin
> Investment Trust. They must directly process bitcoin without
> relying on third party. They should process at least 100BTC in the
> last 30-days. One merchant one vote.
>
> Full nodes operators: People operating full nodes for at least 168
> hours (1 week) in July 2015 are eligible to vote, determined by the
> log of Bitnodes. Time is set in the past to avoid manipulation. One
> IP address one vote. Vote must be sent from the node’s IP address.
>
> -------------------- Voting system
>
> Single transferable vote is applied.
> (https://en.wikipedia.org/wiki/Single_transferable_vote). Voters
> are required to rank their preference with “1”, “2”, “3”, etc, or
> use “N” to indicate rejection of a candidate. Vote counting starts
> with every voter’s first choice. The candidate with fewest votes is
> eliminated and those votes are transferred according to their
> second choice. This process repeats until only one candidate is
> left, which is the most popular candidate. The result is presented
> as the approval rate: final votes for the most popular candidate /
> all valid votes
>
> After the most popular candidate is determined, the whole counting
> process is repeated by eliminating this candidate, which will find
> the approval rate for the second most popular candidate. The
> process repeats until all proposals are ranked with the approval
> rate calculated.
>
> -------------------- Interpretation of results:
>
> It is possible that a candidate with lower ranking to have higher
> approval rate. However, ranking is more important than the
> approval rate, unless the difference in approval rate is really
> huge. 90% support would be excellent; 70% is good; 50% is marginal;
> <50% is failed.
>
> -------------------- Technical issues:
>
> Voting by the miners, developers, exchanges, and merchants are
> probably the easiest. We need a trusted person to verify the
> voters’ identity by email, website, or digital signature. The
> trusted person will collect votes and publish the named votes so
> anyone could verify the results.
>
> For full nodes, we need a trusted person to setup a website as an
> interface to vote. The votes with IP address will be published.
>
> For bitcoin holders, the workload could be very high and we may
> need some automatic system to collect and count the votes. If
> people are worrying about reduced security due to exposed raw
> public key, they should move their bitcoin to a new address before
> voting.
>
> Double voting: people are generally not allowed to change their
> mind after voting, especially for anonymous voters like bitcoin
> holders and solo miners. A double voting attempt from these classes
> will invalidate all related votes.
>
> Multiple identity: People may have multiple roles in the Bitcoin
> ecology. I believe they should be allowed to vote in all
> applicable categories since they are contributing more than other
> people.
>
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJVwISfAAoJEGwAhlQc8H1mygAH/jxe3C5RjPlsSKfIg+CikEwi
kSttrZKr45s6EzayUqyBjBensgsgQCYKo3RLUq8lSpeJdZSmfu4qis09iZVJmKNX
klA/CTuiHTE8jGgwjAHNeeAI/ZQSFOYictzk4OVTSQWoMuB8Wq6S+QXCiUbulOGH
E/vHQz25ZNPX0+Z1Ypx26kSglBNzWJT1cdtyAvd3SDOTMuRVcH9y4aECSB+399Jt
BT2pBOYCJjrXfuU0lh26yph08UyIKSoToCJ4jxEtBzf4COYppsO0dzHeboYkwLMo
+ZuBhz5Bv9Fy5d6AcQtCUjBJE0dZvyAjf7Zc3U9X5ZXe5sAx/zC36O307YtneHI=
=f/pR
-----END PGP SIGNATURE-----

2023-06-07 17:32:30

- reply

📅 Original date posted:2015-08-04
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 08/04/2015 07:19 PM, Hector Chu via bitcoin-dev wrote:
> On 4 August 2015 at 12:59, Jorge Timón <jtimon at jtimon.cc
> <mailto:jtimon at jtimon.cc>> wrote:
> So if you say 8, I must ask, why not 9? Why 9 MB is not safe for
> mining centralization but 8 MB is?
>
>
> 8MB has simply been the focal point for this debate. 9MB is also
> safe if 8MB is, but I suppose the opponents will be even less
> happy with 9 than with 8, and we don't want to unnecessarily
> increase the conflict.
>
Jorge will answer for himself, but you know that saying "9MB is also
safe if 8MB is" blows your position.
Do you, or me, or XT know that 8MB is "safe"? You say 9MB must then
also be "safe" - there has been no fact for me to grasp and from which
to tell a Bitcoin trading whale group: "here's the bottom line: this
is what it means and these are the implications." They hold
significant amounts of bitcoin and want to see a plan, and a strategy
based on facts. I can assure you, they're not going to XT, it lacks
both a strategy and the seasoned developers present here.
> It seems like the rationale it's always "the bigger the better" and
> the only limitation is what a few people concerned with mining
> centralization (while they still have time to discuss this) are
> willing to accept. If that's the case, then there won't be
> effectively any limit in the long term and Bitcoin will probably
> fail in its decentralization goals.
>
>
> A one-time increase to 8MB is safer than a dynamically growing
> limit over time for exactly this reason. Admittedly whenever the
> next debate to increase the block size over 8MB happens it will be
> even more painful and non-obvious, but that is the safety check to
> prevent unbounded block size increase.
You're articulate and you raise valid issues, but your judgment of
"safer" is not based on anything you or this list can refer to as a
comparator.
It seems you want 8MB for some ideological reason but if you examine
your motive and compare it to the facts, you'll find that many people
in this list are ultimately correct in saying that:
Whatever blocksize is set to, demand will soon fill it.
This is the nature of resource supply inflation - some business plan
will spot the opportunity and exploit it, colonize it and then we deal
with that, with some big-girls'-blouses exclaiming: "if we don't give
them what they want they're all going to leave to XT or ZT!"
Even though XT and ZT perfectly fulfill the needs of certain ambitious
businesses, the creators would rather see it happen on Core's
blockchain. Else why do they still come posit arguments here?
Fortunately, unlike the principle that applies in finance capital,
Bitcoin capacity supply doesn't have be increased on demand (not
without rigorous testing and evaluation) plus there is no maxim here
that "the customer is always right". The maxim is "be your own bank" -
during some periods it might be a slow bank but it _will_ remain
decentralized and it _will_ remain your own - not compromised to some
big business or mining cartel.
We want to compromise to science and reason, not profit motive or
democratic lobbying, right?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJVwL80AAoJEGwAhlQc8H1mTVsH/3mdA4XrrRaBx7m/SckufNUu
OWJF/TPuEb0e3/A+OKNvYJgGtkZ9+8pQe2hQK2F1NxFG8QbbIPFXb4PYIiEnU8by
LMMNuDFfZXq0MEyTXXHgNj+XBSR74QKceXD4KM3jVeuieXE2KXGOyeiUD7Tjx0Gv
fyNAM4rhxmipGFu9kmnI6Bm25I4FBzif+ARQSWNmdZQn2bPkFrK0/Q4s/CyXngbb
S/DiPJ7XZrBJ2ogQycVmA4QesOyz30FpQ+QMt5nFUWma3LpLoYEBPtJd8rsG773i
acqSrOXxgfcGtNfbBU0xeTO/FOO4tXtbDVHBTKCBLZ5MgmBOYcm6OTLAwpeHlYY=
=WhnR
-----END PGP SIGNATURE-----

2023-06-07 17:32:28

- reply

📅 Original date posted:2015-08-04
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 08/04/2015 08:12 PM, Gavin Andresen via bitcoin-dev wrote:
> On Tue, Aug 4, 2015 at 7:27 AM, Pieter Wuille via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> I would say that things already demonstrately got terrible. The
> mining landscape is very centralized, with apparently a majority
> depending on agreements to trust each other's announced blocks
> without validation.
>
> And that is a problem... why?
>
> As far as I can tell,
[snip]
It's a big problem. What are you dismissing it for?
With Bitcoin in fledgling 0.x version state this is neither desirable
nor encouraging.
Development did not freeze at some time in the past and now we see how
the userbase reacts. Miners, btw, are arguibly still a class of user
as long as they are guaranteed coinbase.
When they start making and proving themselves useful in a free
floating fee market absent coinbase subsidy, we can revisit this
topic, with the benefit of hindsight.
> As Bitcoin grows, pieces of the ecosystem will specialize.
> Satoshi's original code did everything: hashing, block assembly,
> wallet, consensus, network. That is changing, and that is OK.
[snip]
>
> And I think the current "demonstrably terrible" Bitcoin system is
> still INCREDIBLY interesting.
>
Pieter never said it wasn't interesting, so this emphatic statement is
strange - like someone is trying to convince an audience - but
anyway... as you, a veritable spring-chicken by your actions and
words, said the other day: having graduated in '88 you're "old" and
speak from experience. Don't come with that jive, bossy man - bring
facts and testing to the technical list.
My finance readers, in one camp, and Bitcoin investors, in the other,
want to see the XT 8MB hard-fork testing data that you mentioned for
BIP100.
"Being ignorant is not so much a shame, as being unwilling to learn."
- - Benjamin Franklin
> -- -- Gavin Andresen
>
Venzen Khaosan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJVwMyOAAoJEGwAhlQc8H1mho4IAKEHVxE4lAs3aIoLXa2fxLP8
3q7MhfM5vIW9QAM7rjz8YzheMg3Wj2CNfZPuUV7YDTVrLZPrIN/aMY6CIftr7GUS
pjMI9nnwezFwYX5oyRU+gW51AMFhvexV6ITZYpiLRtWHgK1FZtXWMG13eO/6Jb5U
Wjflub7suMDvg+ST2PplhQf7fFmnPHrLZg3ISDqK+hvgw20geW1rXC/wCChlewfd
DqSt9fxqs+NIvbIzS2TgLTkIcHlbKNeI5AeqbaFoaIQtvYALD3Ojt2I/qoCJU1za
rB8Il7UK0B5uf6xxgErGcYAHzjVpR6Zhsdzo6MiBF1j4ClfNPEQAlG49YjrRXpI=
=4nai
-----END PGP SIGNATURE-----

2023-06-07 17:32:27

- reply

📅 Original date posted:2015-08-04
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 08/04/2015 08:28 PM, Hector Chu via bitcoin-dev wrote:
> On 4 August 2015 at 14:13, Jorge Timón <jtimon at jtimon.cc
> <mailto:jtimon at jtimon.cc>> wrote:
>
> 2) It doesn't matter who is to blame about the current
> centralization: the fact remains that the blocksize maximum is the
> only** consensus rule to limit mining centralization.
>
>
> Repeating a claim ad-nauseum doesn't make it necessarily true. A
> block size limit won't prevent miners in the future from buying
> each other out.
>
It plays both ways, the technical list requires a proof of concept and
simulation upon which to base judgment going forward, else we'll just
be talking out our backsides (like certain people) without making any
progress.
The tools for simulation exist: Jorge Timon created a variable
blocksize regtest PR here:
https://github.com/bitcoin/bitcoin/pull/6382
No-one needs to postulate what different blocksizes imply - anyone
can run a simulation and demonstrate what they're talking about.
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJVwMFEAAoJEGwAhlQc8H1mo/EH/2USw5YUL/7sgFAsjpXdpcS+
9XZ0M0AK4PNSo36GBBhjaF9rRa76FtK6Vt9nLe+7lgYmeHSkcQ65OLKfP47hCnsz
9XfVR0n7nv+0TqHQKPcjm+WNBoVndKRHGEwNQoQw//bAmO4LOcmQCMXAkk9RfaKm
4olay0nUmAFNqh/7wVOunOUFMJNIRpy/neAlFYxRAHBIJLcc0KQNiLqAHbzwPDZq
e9kLjtIusWwLUCgHFvox01bIEOx+VYIxzjMVRz1MNGyRGwDweg7zk54WA48nYwmx
70Ggdde9kiLytPDwB2ey/IRE4mv/4KS2zivJy36XAsjPExTNeGKxGeGfBqXNwSI=
=aya4
-----END PGP SIGNATURE-----

2023-06-07 17:32:25

- reply

📅 Original date posted:2015-08-04
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 08/04/2015 06:34 PM, Hector Chu via bitcoin-dev wrote:
> Things apparently aren't bad enough to prevent the majority from
> clamoring for larger blocks.
>
> If the majority agreed that things had got worse till this point,
> and that this was to be blamed on the block size, they would be
> campaigning for the other direction. Even yourselves aren't asking
> for a reduction in the block size, as you know full well that you
> would be laughed out.
>
Hector, if you could provide data that convinces why 8MB is better
than 6.18MB or 1MB then we'd get out of the realm of opinion and
pointless rhetoric that threatens to keep this debate in a quagmire.
We'd have actual figures to work with and projections to go by.
But fetching "majority" agreement (where from?) does not cut it for
setting Bitcoin on a future path. If we go by that then we'd soon be
giving coinbase rewards to users for being "loyal supporters" because,
as a majority, they think that's what they'd like to see.
If a proposal is demonstrably, and provably, a good idea - and a
developer consensus agrees - then it should go to testing, and
eventually, code. Other than that it's just conjecture and words
without a research paper and data.
In the final analysis, do we want Bitcoin to be steered by an
uninformed and fickle majority, or do we want to use this list as a
forum to present research proposals containing repeatable, verifiable
facts? A progressive process of convincing those most familiar with
Bitcoin's code and operation so they may implement Good Ideas during
the next century and after is surely preferable to Vote-my-code-Coin. :)
> On 4 August 2015 at 12:27, Pieter Wuille <pieter.wuille at gmail.com
> <mailto:pieter.wuille at gmail.com>> wrote:
>
> I would say that things already demonstrately got terrible. The
> mining landscape is very centralized, with apparently a majority
> depending on agreements to trust each other's announced blocks
> without validation. Full node count is at its historically lowest
> value in years, and outsourcing of full validation keeps growing.
>
> I believe that if the above would have happened overnight, people
> would have cried wolf. But somehow it happened slow enough, and
> "things kept working".
>
> I don't think that this is a good criterion. Bitcoin can "work"
> with gigabyte blocks today, if everyone uses the same few
> blockchain validation services, the same few online wallets, and
> mining is done by a cartel that only allows joining after signing
> a contract so they can sue you if you create an invalid block. Do
> you think people will then agree that "things got demonstratebly
> worse"?
>
> Don't turn Bitcoin into something uninteresting, please.
>
> -- Pieter
>
> On Aug 4, 2015 1:04 PM, "Hector Chu via bitcoin-dev"
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> Mike's position is that he wants the block size limit to
> eventually be removed. That is of course an extreme view.
> Meanwhile, your view that the block size should be artificially
> constrained below the organic growth curve (in a way that will
> penalize a majority of existing and future users) lies at the other
> extreme. The majority position lies somewhere in between (i.e. a
> one-time increase to 8MB). This is the position that ultimately
> matters.
>
> If the block size is increased to 8MB and things get demonstrably
> a whole lot worse, then you will have a solid leg to stand on. In
> that case we can always do another hard fork later to reduce the
> block size back to something smaller, and henceforth the block
> size will never be touched again.
>
> On 4 August 2015 at 11:35, Jorge Timón
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> On Fri, Jul 31, 2015 at 4:58 PM, Mike Hearn <hearn at vinumeris.com
> <mailto:hearn at vinumeris.com>> wrote:
>>> 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?
>
> As explained by Venzen, this is a non-sequitur.
>
>> I mean, I guess I don't know how to answer your question.
>
> I don't know the answer either, that's fine. It's the opposite
> question that I've been insistently repeating and you've been
> (consciously or not) consistently evading. But that's also fine
> because I believe you finally answer it a few lines below.
>
>> When Bitcoin was new it had almost no users and almost no
>> miners. Now there are millions of users and factories producing
>> ASICs just for Bitcoin.
>
> The emergence of a btc price enabled the emergence of professional
> miners, which in turn enabled the emergence of sha256d-specialized
> hardware production companies. Nothing surprising there. By no
> means it consitutes an example of how a bigger consensus sizes can
> cause less mining centralization.
>
>> Surely the correlation is obvious?
>
> Correlation does not imply causation. I will better leave it at
> that...
>
>>> I'm sorry, but until there's a simulation that I can run with
>>> different sizes' testchains (for example using #6382) to
>>> somehow compare them, I will consider any value arbitrary.
>>
>>
>> Gavin did run simulations. 20mb isn't arbitrary, the process
>> behind it was well documented here:
>>
>> http://gavinandresen.ninja/does-more-transactions-necessarily-mean-more-centralized
>
>>
>>
>
>> I chose 20MB as a reasonable block size to target because 170
>> gigabytes per month comfortably fits into the typical 250-300
>> gigabytes per month data cap– so you can run a full node from
>> home on a “pretty good” broadband plan.
>>
>> Did you think 20mb was picked randomly?
>
> No, I think 20 MB was chosen very optimistically, considering 3rd
> party services rates (not the same service as self-hosting) in the
> so-called "first world". And then 20 MB goes to 20 GB, again with
> optimistic and by no means scientific expectations.
>
> But where the number comes from it's not really what I'm demaning,
> what I want is some criterion that can tell you that a given size
> would be "too centralized" but another one isn't. I haven't read
> any analysis on why 8GB is a better option than 7GB and 9GB for a
> given criterion (nor one declaring 20 GB a winner over 19 GB or 21
> GB). A simulation test passing 20 GB but not 21 GB would make it
> far less arbitrary.
>
>>> Agreed on the first sentence, I'm just saying that the
>>> influence of the blocksize in that function is monotonic: with
>>> bigger sizes, equal or worse mining centralization.
>>
>>
>> I have a hard time agreeing with this because I've seen Bitcoin
>> go from blocks that were often empty to blocks that are often
>> full, and in this time the number of miners and hash power on
>> the network has gone up a huge amount too.
>
> I'm of course talking about consensus maximum blocksize, not about
> actual blocksize. Yes, again, when mining becomes profitable,
> economic actors tend to appear and get those profits. But don't
> confuse total hashrate improvements with an "increase in the
> number of miners" or with mining decentralization.
>
>> You can argue that a miner doesn't count if they pool mine. But
>> if a miner mines on a pool that uses exactly the same software
>> and settings as the miner would have done anyway, then it makes
>> no difference. Miners can switch between pools to find one that
>> works the way they like, so whilst less pooling or more
>> decentralised pools would be nice (e.g. getblocktemplate), and
>> I've written about how to push it forward before, I still say
>> there are many more miners than in the past.
>>
>> If I had to pick between two changes to improve mining
>> decentralisation:
>>
>> 1) Lower block size
>
> Finally, I think you finally answered my repetitive question here.
> If I say "Mike Hearn understands that the consensus block size
> maximum rule is a tool for limitting mining centralization" I'm not
> putting words in your mouth, right? I think many users advocating
> for an increase in the consensus limit don't understand this, which
> is extremely unfortunate for the debate.
>
>> 2) Finishing, documenting, and making the UX really slick for a
>> getblocktemplate based decentralised mining pool
>>
>> then I'd pick (2) in a heartbeat. I think it'd be a lot more
>> effective.
>
> Great! Maybe after 2 mining centralization improves so much that
> we're confortable not only not lowering it but rather increasing
> it.
>
>>> you should be consequently advocating for full removal of the
>>> limit rather than changes towards bigger arbitrary values.
>>
>>
>> I did toy with that idea a while ago. Of course there can not
>> really be no limit at all because the code assumes blocks fit
>> into RAM/swap, and nodes would just end up ignoring blocks they
>> couldn't download in time anyway. There is obviously a physical
>> limit somewhere.
>
> Did the fact that you "understand that the consensus block size
> maximum rule is a tool for limitting mining centralization"
> influenced your rejection of that idea at all?
>
>> But it is easier to find common ground with others by
>> compromising. Is 8mb better than no limit? I don't know and I
>> don't care much: I think Bitcoin adoption is a slow, hard
>> process and we'll be lucky to increase average usage 8x over the
>> next couple of years. So if 8mb+ is better for others, that's OK
>> by me.
>
> The only way that "not caring much whther we have a consensus
> limit or not" and "understand that the consensus block size maximum
> rule is a tool for limitting mining centralization" at the same
> time is by not caring about mining centralization at all. Is that
> your position?
>
> If you don't care about having a limit but you don't want to limit
> transaction volume, then ++current_size will ALWAYs be your
> "compromise position" and no blocksize increase will ever be enough
> until the limit is completely removed. Is that your position?
>
>> Re: exchange profit. You can pick some other useful service
>> provider if you like. Payment processors or cold storage
>> providers or the TREZOR manufacturers or whoever.
>
> Yes, and I believe the same points stand.
>
>> My point is you can't have a tiny high-value-transactions only
>> currency AND all the useful infrastructure that the Bitcoin
>> community is making. It's a contradiction. And without the
>> infrastructure bitcoin ceases to be interesting even to people
>> who are willing to pay huge sums to use it.
>
> You keep talking about "high-value-transactions-only" like if
> non-urgent transaction fees rising from zero to, say, 1 satoshi,
> would automatically result in that "high-value-transactions-only"
> Bitcoin. Please, stop talking as if someone was proposing a
> "high-value-transactions-only" Bitcoin. That may happen but nobody
> really knows. If it happens it may not be bad thing necessarily
> (ie bitcoin microtransactions can still happen using trustless
> payment channels and x is still cheaper than x% for any transacted
> value higher than 100) but that's really not what we're talking
> about here so it seems distraction that can only help further
> polirizing this discussion.
>
> What we're talking about here is that hitting the limit would
> (hopefully) make miners start caring about fees. Enough that they
> stop being irrational about free transactions. If both things
> happen, non-urgent transaction fees will likely rise (as said,
> above zero).
>
> You think that would be a catastrophe for adoption and I disagree.
> But (as Pieter has repeatedly explained) for any size there will
> be use cases that will be eventually priced out. So when rising
> this consensus limit, not increasing centralization should be the
> priority and the potential impact in market fees a much more
> secondary concern. Do you agree with this?
>
> I'm sure there are many intermediate positions between "caring more
> about mining centralization than market fees when deciding about a
> consensus rule that limits mining centralization" and "not caring
> about mining centralization at all". I really don't want to put
> words in your mouth, but I honestly don't know what your position
> is. I don't really know how else can I ask the same question: you
> don't care the consensus maximum blocksize rule being here at all
> or not (you just said that). Is it because you don't think it
> limits mining centralization or because you don't care about
> limiting mining centralization with consensus rules at all?
> _______________________________________________ bitcoin-dev
> mailing list bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> _______________________________________________ bitcoin-dev
> mailing list bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
>
> _______________________________________________ bitcoin-dev
> mailing list bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJVwKvEAAoJEGwAhlQc8H1m2g4H/i3jcap3C1mt5hG964EWlF42
MC6/P23MWI6o5AO7Ugz6m35IDO+ZfegY3VlAmAaq0KSwKEoZSWV/FIPQPpVOCGeP
CdIGw4M+Q//kRBaxNEnfC3gM7IYHRFfOEwZtVsda5vriem+Yjb4Fk+YoXyONI2j1
0GqmPAIJ5+eA1H/t541/lUDHVzLyymlsWX34MIjX1BWnKQaap+eaMHucu+DrcRHd
GltkKrqRQ/Hngv7PtaQGTPjUHrQglHISl6BMXNMbmxoEHg2RfrRwifiJGnDmEty6
l/Yve6slLtaQA+SIyAun79SUU5+QJOOWDxU2PlXQTRldx+0YQJ60L0GanQ5CHc8=
=EarG
-----END PGP SIGNATURE-----

2023-06-07 17:32:11

- reply

📅 Original date posted:2015-08-02
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
+1 on every point, sipa
On 08/02/2015 05:32 PM, Pieter Wuille via bitcoin-dev wrote:
>>>> 2. Starting date: 30 days after 75% miner support, but not
>>>> before 2016-01-12 00:00 UTC
>>>>
>>>> Rationale: A 30-day grace period is given to make sure
>>>> everyone has enough time to follow. This is a compromise
>>>> between 14 day in BIP101 and 1 year in BIP103. I tend to
>>>> agree with BIP101. Even 1 year is given, people will just do
>>>> it on the 364th day if they opt to procrastinate.
>>>
>>>
>>> Given the time recent softforks have taken to deploy, I think
>>> that's too soon.
>>
>>
>> Since I'm using "30 days after 75% miner support", the actual
> deployment period will be longer than 30 days. Anyway, if all
> major exchanges and merchants agree to upgrade, people are forced
> to upgrade immediately or they will follow a worthless chain.
>
> If we don't want it to go fast, why let them? A hardfork is a means
> for the community to agree on the rules that different parties have
> to obey.
>
>>>> 3. The block size at 2016-01-12 will be 1,414,213 bytes, and
>>>> multiplied by 1.414213 by every 2^23 seconds (97 days) until
>>>> exactly 8MB is reached on 2017-05-11.
>>>>
>>>> Rationale: Instead of jumping to 8MB, I suggest to increase
>>>> it gradually to 8MB in 16 months. 8MB should not be
>>>> particularly painful to run even with current equipment (you
>>>> may see my earlier post on bitctointalk:
>>>> https://bitcointalk.org/index.php?topic=1054482.0 ). 8MB is
>>>> also
>>>>
>>>> agreed by Chinese miners, who control >60% of the network.
>>>
>>>
>>> I have considered suggesting a faster ramp-up in the beginning,
>>> but I don't think there is indisputable evidence that we can
>>> currently deal with significantly larger blocks. I don't think
>>> "painful" is the right criterion either; I'm sure my equipment
>>> can "handle" 20 MB blocks too, but with a huge impact on
>>> network propagation speed, and even more people choosing the
>>> outsource their full nodes.
>>>
>>> Regarding "reasonable", I have a theory. What if we would have
>>> had 8 MB blocks from the start? My guess is that some more
>>> people would have decided to run their high-transaction-rate
>>> use cases on chain, that we'd regularly see 4-6 MB blocks,
>>> there would be more complaints about low full node counts,
>>> maybe 90% instead of 60% of the hash rate would be have SPV
>>> mining agreements with each other, we'd somehow have accepted
>>> that even worse reality, but people would still be complaining
>>> about the measly 25 transactions per second that Bitcoin could
>>> handle on-chain, and be demanding a faster rampup to a more
>>> "reasonable" 64 MB block size as well.
>>
>>
>> Since the block reward is miners' major income source, no
>> rational
> miner would create mega blocks unless the fee could cover the
> extra orphaning risk. Blocks were not constantly full until recent
> months, and many miners are still keeping the 750kB soft limit.
> This strongly suggests that we won't have 4MB blocks now even
> Satoshi set a 8MB limit.
>
> I disagree. I think "demand" is strongly influenced by the
> knowledge of space that looks available. If you look at historic
> block sizes, you see it follows a series of block functions, not
> nice organic growth. My theory is that this is changed defaults in
> software, new services appearing suddenly, and people reacting to
> it. Demand fills the available space.
>
> Also, SPV mining has nearly zero orphaning risk, only brief chance
> of loss of fees as income.
>
>> I don't have the data now but I believe the Satoshi Dice model
>> failed
> not primarily due to the 1MB cap, but the raise in BTC/USD rate.
> Since minting reward is a fixed value in BTC, the tx fee must also
> be valued in BTC as it is primarily for compensating the extra
> orphaning risk. As the BTC/USD rate increases, the tx fee measured
> in USD would also increase, making micro-payment (measured in USD)
> unsustainable.
>
> I agree, but how does that matter? I don't think high fees and
> full blocks should be the goal, but I think it would be a healthier
> outcome than what we have now.
>
>> We might have less full nodes, but it was Satoshi's original
>> plan: "At
> first, most users would run network nodes, but as the network
> grows beyond a certain point, it would be left more and more to
> specialists with server farms of specialized hardware. A server
> farm would only need to have one node on the network and the rest
> of the LAN connects with that one node." Theoretically, we only
> require one honest full node to prove wrongdoing on the blockchain
> and tell every SPV nodes to blacklist the invalid chain.
>
> Theoretically, we also only need one central bank, then? Sorry, if
> the outcome is one (or just a few) entities that keep the system in
> check, I think it loses any benefit it has over other systems,
> while still keeping its costs and disadvantages (confirmation
> speed, mining infrastructure, subsidy...).
>
> I know that 8 MB blocks do not immediately mean such a dramatic
> outcome. But I do believe that as a community setting the block
> size based on observed demand (which you do by saying "8 is a more
> reasonable size than 2" as argument) is the wrong way. What do you
> do when your 8 MB starts to look "full", before your schedule says
> it can increase?
>
> The block size and its costs - bandwidth, processing,
> centralization effects for miners, ... - are the things that should
> be constrained. Demand will fill it.
>
>> I think SPV mining exists long before the 1MB block became full,
>> and I
> don't think we could stop this trend by artificially suppressing
> the block size. Miners should just do it properly, e.g. stop mining
> until the grandparent block is verified, which would make sure an
> invalid fork won't grow beyond 2 blocks.
>
> That would be a huge reduction in security as a mechanism itself,
> and even worse due to needing to trust miners to follow that
> protocol. Without proper incentives, miners become a trusted party,
> and due to needed SPV mining agreements, potentially a closed group
> too. That is not an interesting future.
>
>> If you believe Bitcoin should become a global settlement network,
>> 32MB
> would be the very minimum as that is only 75% of current SWIFT
> traffic.
>
> See my BIP text about advantages of Bitcoin, please. A future where
> it has to compete with the existing system - using that system's
> own strengths - is not interesting.
>
> -- Pieter
>
>
>
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJVvfMbAAoJEGwAhlQc8H1mzNwH/RqAWfpio7eMrgrtF9Itstp2
6aSC5wMWlmG9lfusbRD75Ks+27C7ZH1AHcjI1H7V0tvWkYZHsZGQLlVH3fTbcZM8
LVC650sEAlCAenxV+5q6Gn9GW65CpKDmTkWOiLs5Z2/sQaDFWsxk4F7Em8D0JDRe
H3RPYRQg2eGW8r1s/pZU0gLrqduHTpigWNrL4znPqNFBfAXChdH1xrMnTiB6vJGA
73d/N/XrklzqLAHrSakhjctxRo4Ya57/uLW6FP/ey/UDKytG2DqhsakCPn73J/mI
Im7xbMtUBnCXxB6Ow8n78lxE1+ib/ntjoX9MqDmqNxRLFViWIO34vmVsHpC2RS4=
=kQ2U
-----END PGP SIGNATURE-----

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

📅 Original date posted:2015-07-31
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 07/31/2015 09:58 PM, Mike Hearn via bitcoin-dev wrote:
> 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?
The logic just flows from one to the other does it? So because Islam
is the biggest religious ecosystem in the world now you and me are
just burning to take part?
By your logic, most people in Asia would horde (or want to pay using)
Chinese Yuan, only they don't. The Yuan and the Yen are the dominant
currencies of large transaction settlement in the region, but try to
use it on the street and you're met with puzzled bemusement, Mike Hearn.
Bitcoin is not suitable as a currency for pervasive dominance, and
ideals of pushing it into every heart and mind around the globe is no
different from religious zealotry.
Bitcoin has its place and we're only at the beginning of a gradual
evolution. How can I say that? Because I'm looking across the rice
paddy to where my neighbors have not adopted the innovation of the
lightbulb, and burn candles for light and cook with gas. And they're
not an anomaly around here or in Asia, Africa and South America.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJVu5QvAAoJEGwAhlQc8H1m1DQH/i54c+ZBnk9tZK+0PfC2G0rT
taLpqvmXGOHPaSqkfHOLjLOm9LxGAw3TZpFIkFSuSuiSlwDfii2VIlKsbYSCEbBe
twCaZuNqam4r+61755ADrvPziPx3Tr2GXN7Zc635prN9uGoGCu58xxc7Iy8sTsrf
vB430ZN5RhagpFG5LCqN4QmDGQlK+ceYh53jLQ5HpNP/8UsOJjGXdnZfb4V24EFW
0NPAWdmWVFVpEPxqbsmAGjzOPVdocSQuRTekOQHJ7e5XNmHaD3YGHI+hwBDKzcD+
tUuFh7v4C684172PwandfJGAtUJMeavdh+IA21fze3+trrcTOVOZMHr+HEfmWGs=
=AToN
-----END PGP SIGNATURE-----

2023-06-07 15:44:18

- reply

📅 Original date posted:2015-07-31
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Mike Hearn, I might be a nobody to you, but you know i talk with
skill, so let me tell this Friday...
On 07/31/2015 05:16 PM, Mike Hearn via bitcoin-dev wrote:
> I agree with Gavin
You would, of course.
> Bitcoin can support a large scale and it must, for all sorts of
> reasons. Amongst others:
>
> 1. Currencies have network effects. A currency that has few users
> is simply not competitive with currencies that have many. There's
> no such thing as a settlement currency for high value transactions
> only, as evidenced by the ever-dropping importance of gold.
References are imperative if you want to appeal to intelligence in
this list. Studies. Impirical evidence. The above sounds like a a
mainstream precis of how money works - an over-simplistic precis. It's
more complex than that. Besides, all we know for a fact is that
currencies come and go. That's not me being down on Bitcoin - that is
the historical record.
>
> 2. A decentralised currency that the vast majority can't use
> doesn't change the amount of centralisation in the world. Most
> people will still end up using banks, with all the normal
> problems. You cannot solve a problem by creating a theoretically
> pure solution that's out of reach of ordinary people: just ask
> academic cryptographers!
Conjecture. And assumption. Banks might not accept most people
forever. Or banks' credibility might not survive the next credit
contraction, for example.
>
> 3. Growth is a part of the social contract. It always has been.
>
Half the story. Casual observation shows that growth and contraction
alternate at every level of existence. Just because the present
fiat-era credit expansion has lasted 40 years does not mean that the
economy will keep expanding forever.
> The best quote Gregory can find to suggest Satoshi wanted small
> blocks is a one sentence hypothetical example about what /might/
[snip]
yes, anyway, Greg Maxwell was justified in bringing you down a few
notches from your "I am Satoshi's rep on earth" history revision, you
were spinning there.
> 4. All the plans for some kind of ultra-throttled Bitcoin network
> used
[snip]
> The network of exchanges, payment processors and startups that are
> paying people to build infrastructure are all based on _the
> assumption_ that the market will grow significantly.
The assumption (my emphasis). You've seen that movie Pulp Fiction:
"Assume makes an "ass" of "U" and "me". Business + assumption =
gambling and potential loss of funds.
The ass-U-me cannot be laid at the doorstep of those developers who
prioritize security, decentralization and conservative, tested
progress of scaling.
> So why should anyone go through the massive hassle of setting up
> exchanges, without the lure of large future profits?
>
Their SWOT analysis includes risks from the banking sector, too. Plus
competition from other exchanges. A sapling 0.x Bitcoin community is
not responsible for nannying anyone's lucrative business model at the
expense of security. How would that make the developers look in
relation to their duty of custody of the protocol? To this and future
generations: Not Good.
>
> 5. Bitcoin needs users, lots of them, for its political survival.
> There are many people out there who would like to see digital cash
> disappear, or be regulated out of existence.
Nonsense, and again that assumption about "how things work" you like
to high horse so. Bitcoin's political survival is guaranteed by its
censorship resistance and its array of innovative and unique utility
functions. What's more, the caliber of developer working on Bitcoin is
not just pulled out of a hat and harnessed for an arbitrary altcoin.
Sometimes the fire of moral incentive overrides monetary reward.
The Fed, Nasdaq, IBM, and every other company whose trusted authority
is being threatened by this flagship are developing blockchains in a
hurry. How is that "many people out there who would like to see
digital cash disappear"? Why would you even type such a blatant falsehood?
> If Bitcoin is a tiny, obscure currency used by drug dealers and a
> handful of crypto-at-any-cost geeks, the cost of simply banning it
> outright will seem trivial and the hammer will drop. There won't be
> a large scale payment network OR a high-value settlement network.
> And then the world is really screwed, because nobody will get a
> second chance for a very long time.
>
That is a low estimation of Bitcoin. Your framing does not honor
Bitcoin or the hard work - your _own_ hard work - on this project.
If you noticed, there has been an increase in technical discussion in
this list in recent days - with the goal of comparing and testing the
various blocksize proposals.
Mike Hearn, I am sorry to say that your pronouncements sound like jazz
- - but jazz without rhythm.
"So what?" - Miles Davis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJVu199AAoJEGwAhlQc8H1mkCMH/iWnFDXAGc5GEjLi81dRLUnz
3UfciwOiby8r+7pvyDsuMYR/9RQZv2RlFoMFjUBkJxwvdUh3eXY5tsQ6F209O+gk
QleFaTKCZLVuZg5UBbwBttGfK3MmejueGWNhExYnlbm6yXpBa2jt0i5n0tr++zVw
RN+zAejOy2OEBjs7jkodgVdy7kfCXsfsn/DKGdSO7nE9m5q0ocuUFBLEf/PJErBw
NncLSDhd2SfVz3Q7L9UrGqKIgQTJT1nR9kJmSPCasIRoLWJzfNemH6RL3XcmiACn
xIQBN19FPnKLv1OY3GlFLlmIlq0mu6MeidJsPl80yyI2h4SciCp39T1Ah/tCnf4=
=2uWe
-----END PGP SIGNATURE-----

2023-06-07 15:44:15

- reply

📅 Original date posted:2015-07-30
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 07/30/2015 10:12 PM, Jorge Timón via bitcoin-dev wrote:
[snip]
> But even if I'm the only one that considers a "technological
> de-growth" possible, I don't think is wise to rely on pseudo-laws
> like Moore's or Nielsen’s so-called "laws". Stealing a quote from
> another thread:
You raise a good point: "de-growth"
Assuming linear (or exponential) growth without sympathetic
contraction at some time in the future would make our future selves
look back and smile at the youthful exuberance.
The pseudo-laws you mention (Moore's etc) do not cater for contraction
and, you're right, scaling UP plans should also wisely make provision
for scaling DOWN, for when the need arises.
>
> So I would prefer a more limited solution like bip102 (even though
> I would prefer to have some simulations leading to a concrete
> value (even if it's bigger) rather than using 2MB's arbitrary
> number.
I just had a look your existing Size N testnet code
https://github.com/bitcoin/bitcoin/pull/6382
and i'll set up a node over the weekend and post its address in that
PR's conversation. Do you or anyone else already have a node running?
what blocksize?
>
> Those are my 3 cents.
>
> [1]
> https://philohist.files.wordpress.com/2008/01/nietzsche-uses-history.pdf
Thanks,
>
will broaden my horizon soon!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJVulKBAAoJEGwAhlQc8H1mUSAH/Rmlek3uitGyIritwyDO4Kf7
BfynlztWmPbnWl7aFYQCS+aIPgS+BvQWIiA0dTI633yj071DWEvcGDzhtcVrk0KT
//Ty8bp8yqsJRdd+SWgnqUzSmB6TI31F3ssxjDfSZhKiy8YF4+pKqjerQmBqlgLY
sKts3md8N8qWV5Onjd7ea+7SoFjhJ6GOm2UFgxO27LCeDH5Ax5fG4MsolNg3MBTT
5y7Hfo1YeFXRwRRSy5uCSSR0afBb8Wauqi/EnSYDuMe5HBcLztc7icXa6oLTlvBC
sfYswasmLRbvHLs4Vy51g75+k60QBjgFKtVlPXJXGN2trbcedF0UbDmenxGqJaI=
=rJPX
-----END PGP SIGNATURE-----

2023-06-07 15:44:00

- reply

📅 Original date posted:2015-07-30
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jorge,
You know, it is always insightful to get the perspective of active
participants and Core developers like yourself. As Adam pointed out
earlier, the developers have done mileage in this space and have
already considered most of the conceptual issues and technical
challenges that must resurface in waves as new interested parties join
the list. Allow me, in this response to your message, to make a
proposal to those who may be interested:
Bitcoin's protocol functions and the implications of this innovation
for the future are difficult to grasp, even for the smartest among us.
Then there are also the words of Niels Bohr:
"Prediction is difficult, especially about the future."
They say a lot of time and energy is wasted because we don't know what
we don't know. Years of discussion among those in the list has
established certain axioms that determine the options for Bitcoin
going forward. According to my comprehension, the following are some
of the most relevant for the present discussion (please correct me
where I'm off the mark):
1. A high degree of decentralization is prima optima.
2. Bitcoin is much more than a payment network. A lot of the
non-payment features are, arguably, what gives Bitcoin most of its
value. Yet, the payment functionality is a major design feature and
all agree that it should scale - subject to axiom 1.
3. The Bitcoin payment network ("Layer 1"), due to technical
constraints imposed by its p2p design, cannot compete with Visa and
other centralized transmission channels for speed or transaction
volume. Nor can it handle the transaction requirements of the world's
population - the scaling required would necessarily render Bitcoin
centralized, insecure and, therefore, worthless.
4. The addition of "layer 2" protocols (such as Lightning and other
sidechains) will allow fast, low-fee (and with virtually instant
confirmation) bitcoin transactions within two years, according to the
developers active in that:
http://www.youtube.com/watch?v=jE_elgnIw3M
http://www.youtube.com/watch?v=fBS_ieDwQ9k
5. This "layering of protocols" simplifies the scaling (blocksize)
debate because it separates
A) the primary concern for security and fidelity via
decentralization, and
B) the ideal of universal accessibility via fast, low-fee transactions.
Discussion about scalability can therefore proceed with the knowledge
that Lightning and other "layer 2" sidechains will make Bitcoin
accessible to the global majority - and be fast like Bruce Lee - while
the Bitcoin developers can focus on making Bitcoin Core protocol
(layer 1) the world heavyweight champion - Muhammad Ali.
Since I've maintained your interest up to the final sentence, I say:
as an insurance against a capacity crisis before layer 2 is deployed,
why not implement bip100's 2MB blocksize proposals in a testnet?
On 07/30/2015 04:38 PM, Jorge Timón wrote:
> It is important ro note that even if lightning was never developed,
> the block size remains at 1 MB forever and fees rise to 10 usd per
> transaction, such "high fees" are still extremely competitive with
> non-decentralized payment systems that have proportional fees. For
> example, 10 usd is still lower than 1% when you are moving more
> than 1000 usd. I know, this doesn't work for micro-transactions,
> but I don't think Bitcoin can be useful for micro-transactions in
> the long term unless something like lightning payment channels is
> deployed. Until we accept the second fact, it will be very hard to
> discuss any projection of future usage. I think that believing that
> all the transactions of the entire world population can be made
> in-chain while keeping bitcoin decentralized is incredibly naive.
> Not even nasdaq has that capacity (and if full node's require
> nasdaq's capacity, I don't think we can talk about a decentralized
> system anymore).
>
> On Jul 30, 2015 11:16 AM, "Venzen Khaosan via bitcoin-dev"
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> Adam,
>
> - From your explanation it is evident that fast, cheap bitcoin
> transactions are possible. It is encouraging that Bitcoin _can_
> indeed compete with Visa, Paypal, et al. via Layer 2 protocols such
> as Lightning.
>
> The youtube interview with you and Greg re: Lightning requires
> some concentration and I'll have to watch it another couple of
> times to better grasp everything that is explained about the
> protocol and its interaction with Bitcoin.
>
> Thank you for your considered and informative response, else
> Raystonn and I might have gotten in an unnecessary scrap about
> fees, economics and what not.
>
> regards, Venzen Khaosan
>
>
>
> On 07/30/2015 10:49 AM, Adam Back wrote:
>> I dont think people consider other blockchains as a competitive
>> threat. A PoW-blockchain is a largely singleton data structure
>> for security reasons (single highest hashrate), it is hard for
>> an alternative chain to bootstrap or provide meaningful
>> security. Secondly the world largely lacks expertise to maintain
>> a blockchain to bitcoin's security level, perhaps you can see a
>> hint of this in the recently disclosed security vulnerability by
>> Pieter Wuille and Gregory Maxwell. Calls to this as an argument
>> are not resonating and probably not helping your argument.
>> Bitcoin has security properties, and a competing system cant
>> achieve better properties by bypassing security, any blockchain
>> faces the same fundamental security / decentralisation
>> limitations.
>
>> Secondly Bitcoin can obviously compete with itself with
>> different parameters and defacto *does* today. I think it is a
>> safe estimate that > 99% of Bitcoin transactions right now are
>> happening in Bitcoin related systems with various degrees of
>> audit, reconciliation, provable reserves etc. I think we can
>> expect this to continue and become more secure via more
>> reconciliation, and longer term via lightning or Bitcoin
>> sidechains with different parameters. It is a different story to
>> have a single central system (Bitcoin with parameters changed to
>> the point of centralisation failure) vs having multiple choices,
>> because some transactions can more easily use relatively
>> centralised systems (eg micropayments), and more interestingly
>> the combination of a secure and decentralised layer 1 plus
>> choices of less decentralised layer 2 options, can be interesting
>> because the layer 2 is provided cover from attack. There is less
>> to be gained by attacking relatively centralised layer 2 because
>> any payments at risk of policy abuse (which is typically a small
>> subset) can easily switch to layer 1. That in itself makes layer
>> 2 transactions also less susceptible to policy abuse. Further
>> lightning it appears from work so far should add significant
>> scale while retaining trustlessness and a good degree of
>> decentralisation.
>
>> Finally you seem to be focusing on "artificial" limits where
>> that is not the issue under consideration. The limits are
>> technical and relating to decentralisation and security. I wont
>> go over them again as this topic has been covered many times in
>> recent months. Any chain that tried to go to extreme parameters
>> (very low block intervals, or very large blocksizes) would have
>> the same decentralisation problems as Bitcoin would if it did the
>> same thing. There are a number of alt coins that have failed as
>> a result of poor parameter choices, there are inherent security
>> limits.
>
>> Adam
>
>> ps Etiquette note for yourself and others: please dont be
>> repetitive or attempt to be forceful. Many people have spent
>> many years understanding this very complex system, from my own
>> experience it is rare indeed to think of an entirely new concept
>> or analysis, that hasnt' been long considered and put to bed 3 or
>> 4 years ago. Thoughtful polite and constructive comments are
>> welcome but I recommend to not start from an assumption that you
>> have a clear and better insight than the entire technical
>> community, because I have to say from my own experience that is
>> very rarely the case. It can be useful to test theories on
>> #bitcoin IRC channel to find out what has been already concluded,
>> find the references and avoid having to have that hashed out on
>> this list which is trying to be focussed on technical solutions.
>
>
>> On 29 July 2015 at 16:10, Raystonn . via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>>>> Cheapest way to send value? Is this what Bitcoin is trying
>>>> to do? So all of the smart contract, programmable money,
>>>> consensus coding and tremendous developer effort is bent to
>>>> the consumer demand for cheaper fees. Surely thou jests!
>>>
>>>
>>> These other features can be replicated into any alternative
>>> blockchain, including those with lower fees. In the
>>> open-source world of cryptocurrency, no feature will remain a
>>> value-add for very long after it has been identified to be
>>> such. Anything adding value will quickly be absorbed into
>>> competing alternative blockchains. That will leave economic
>>> policy as the distinguishing factor.
>>>
>>>> ... it is not the case ... that reluctance to concede
>>>> blocksize is an attempt to constrain capacity. Greg Maxwell
>>>> thoroughly explained in this thread that the protocol's
>>>> current state of development relies on blocksize for
>>>> security and, ultimately, as a means of protecting its degree
>>>> of decentralization.
>>>
>>>
>>> A slow or lack of increase to maximum transaction rate will
>>> cause pressure on fees. Whether this is the desired goal is
>>> not relevant. Everyone has agreed this will be the outcome.
>>> As to a smaller block size being needed for additional
>>> decentralization, one must simply ask how much we are all
>>> willing to pay for that additional decentralization. It is
>>> likely that the benefit thereto will have to be demonstrated by
>>> some power attacking and destroying a less decentralized
>>> currency before the benefit of this feature is given monetary
>>> value by the market. Until then, value will bleed to the
>>> network with the least friction, because it will have the
>>> greatest ability to grow its network effect. That means the
>>> blockchain with adequate features and cheapest fees will
>>> eventually have the largest market share.
>>>
>>>
>>> -----Original Message----- From: Venzen Khaosan Sent:
>>> Wednesday, July 29, 2015 3:11 PM To: Raystonn . Cc:
>>> bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org> Subject: Re:
> [bitcoin-dev]
>>> Why Satoshi's temporary anti-spam measure isn'ttemporary
>>>
>> Raystonn, I'm aware that you're addressing your question to Greg
>> Maxwell, however a point you keep stating as fact calls for
>> reference:
>
>> On 07/30/2015 04:28 AM, Raystonn . via bitcoin-dev wrote: [snip]
>>>>>
>>>>> How do you plan to address the bleeding of value from
>>>>> Bitcoin to alternative lower-fee blockchains created by
>>>>> the artificially-high bitcoin transaction fees when users
>>>>> begin looking for the cheapest way to send value?
>
>> Cheapest way to send value? Is this what Bitcoin is trying to
>> do? So all of the smart contract, programmable money, consensus
>> coding and tremendous developer effort is bent to the consumer
>> demand for cheaper fees. Surely thou jests!
>
>>>>> Modern economic study has shown that liquidity moves to
>>>>> the location of least friction.
>
>> Modern economic study? Can you please provide a link or
>> reference to the study you are referring to.
>
>> "liquidity moves to the location of least friction"
>
>> This sounds like "econo-speak" and makes no sense. The
>> definition of Liquidity is the degree to which an asset/security
>> can be bought or sold in the market without affecting the price.
>
>> That is why bitcoin is said to have low liquidity: buying or
>> selling only 100 BTC visibly affects the exchange price. You
>> probably mean "people like cheap fees", which is true, but as
>> others have said, because of Bitcoin's powerful features, they
>> are willing to pay higher fees and wait longer for transactions
>> to execute.
>
>> As for your public cross-examination of Greg Maxwell, your case
>> seems to be made on the assumption that limiting the size of
>> the blockchain is an attempt to artificially raise tx fees, but
>> it is not the case (as you and others repeatedly argue) that
>> reluctance to concede blocksize is an attempt to constrain
>> capacity. Greg Maxwell thoroughly explained in this thread that
>> the protocol's current state of development relies on blocksize
>> for security and, ultimately, as a means of protecting its degree
>> of decentralization.
>
>> Surely, this is an obvious concern even for those who are
>> campaigning for the hare-brained ideal of making Bitcoin a
>> "faster, cheaper alternative" to visa or paypal? If we lose
>> decentralization, we lose the whole thing, right? Incorrect or
>> correct?
>>> _______________________________________________ bitcoin-dev
>>> mailing list bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJVuieTAAoJEGwAhlQc8H1meAIH/RHUV72bbMItZOT7rvhEU56r
lqEcvwXBSCYgsh1ieVeTdC/ydJnRSzWsdZxM3D7PEOzutlG+VaJQVSJREItGb2GW
PYiZ3uwSwF64nRq5bZ7aS2pT/Zo1a1yAf4H5rbeyxxoWC+zkmSsmcf73MgmslIuU
7XXHNztCX3glfOctr+J61WEKBw0ItQCTsp9J08yVlj/gvKTi3U2jDcYV5mf/3D0j
pvXl244DG4b+nYetRyyonYbZelSUYfCghNBJhUYZApVmcgfKDRPeX1uWfkl0HuUd
Kc+uZtrhJaUXdRlqc50nOsRSCAK+d4PGClF8JFlzI65+SG7VzkVqc8SkSDfNXfY=
=r4SA
-----END PGP SIGNATURE-----

2023-06-07 15:43:58

- reply

📅 Original date posted:2015-07-30
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Adam,
- From your explanation it is evident that fast, cheap bitcoin
transactions are possible. It is encouraging that Bitcoin _can_ indeed
compete with Visa, Paypal, et al. via Layer 2 protocols such as Lightning.
The youtube interview with you and Greg re: Lightning requires some
concentration and I'll have to watch it another couple of times to
better grasp everything that is explained about the protocol and its
interaction with Bitcoin.
Thank you for your considered and informative response, else Raystonn
and I might have gotten in an unnecessary scrap about fees, economics
and what not.
regards,
Venzen Khaosan
On 07/30/2015 10:49 AM, Adam Back wrote:
> I dont think people consider other blockchains as a competitive
> threat. A PoW-blockchain is a largely singleton data structure
> for security reasons (single highest hashrate), it is hard for an
> alternative chain to bootstrap or provide meaningful security.
> Secondly the world largely lacks expertise to maintain a blockchain
> to bitcoin's security level, perhaps you can see a hint of this in
> the recently disclosed security vulnerability by Pieter Wuille and
> Gregory Maxwell. Calls to this as an argument are not resonating
> and probably not helping your argument. Bitcoin has security
> properties, and a competing system cant achieve better properties
> by bypassing security, any blockchain faces the same fundamental
> security / decentralisation limitations.
>
> Secondly Bitcoin can obviously compete with itself with different
> parameters and defacto *does* today. I think it is a safe
> estimate that > 99% of Bitcoin transactions right now are happening
> in Bitcoin related systems with various degrees of audit,
> reconciliation, provable reserves etc. I think we can expect this
> to continue and become more secure via more reconciliation, and
> longer term via lightning or Bitcoin sidechains with different
> parameters. It is a different story to have a single central
> system (Bitcoin with parameters changed to the point of
> centralisation failure) vs having multiple choices, because some
> transactions can more easily use relatively centralised systems (eg
> micropayments), and more interestingly the combination of a secure
> and decentralised layer 1 plus choices of less decentralised layer
> 2 options, can be interesting because the layer 2 is provided cover
> from attack. There is less to be gained by attacking relatively
> centralised layer 2 because any payments at risk of policy abuse
> (which is typically a small subset) can easily switch to layer 1.
> That in itself makes layer 2 transactions also less susceptible to
> policy abuse. Further lightning it appears from work so far should
> add significant scale while retaining trustlessness and a good
> degree of decentralisation.
>
> Finally you seem to be focusing on "artificial" limits where that
> is not the issue under consideration. The limits are technical
> and relating to decentralisation and security. I wont go over them
> again as this topic has been covered many times in recent months.
> Any chain that tried to go to extreme parameters (very low block
> intervals, or very large blocksizes) would have the same
> decentralisation problems as Bitcoin would if it did the same
> thing. There are a number of alt coins that have failed as a
> result of poor parameter choices, there are inherent security
> limits.
>
> Adam
>
> ps Etiquette note for yourself and others: please dont be
> repetitive or attempt to be forceful. Many people have spent many
> years understanding this very complex system, from my own
> experience it is rare indeed to think of an entirely new concept or
> analysis, that hasnt' been long considered and put to bed 3 or 4
> years ago. Thoughtful polite and constructive comments are welcome
> but I recommend to not start from an assumption that you have a
> clear and better insight than the entire technical community,
> because I have to say from my own experience that is very rarely
> the case. It can be useful to test theories on #bitcoin IRC
> channel to find out what has been already concluded, find the
> references and avoid having to have that hashed out on this list
> which is trying to be focussed on technical solutions.
>
>
> On 29 July 2015 at 16:10, Raystonn . via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>> Cheapest way to send value? Is this what Bitcoin is trying to
>>> do? So all of the smart contract, programmable money, consensus
>>> coding and tremendous developer effort is bent to the consumer
>>> demand for cheaper fees. Surely thou jests!
>>
>>
>> These other features can be replicated into any alternative
>> blockchain, including those with lower fees. In the open-source
>> world of cryptocurrency, no feature will remain a value-add for
>> very long after it has been identified to be such. Anything
>> adding value will quickly be absorbed into competing alternative
>> blockchains. That will leave economic policy as the
>> distinguishing factor.
>>
>>> ... it is not the case ... that reluctance to concede blocksize
>>> is an attempt to constrain capacity. Greg Maxwell thoroughly
>>> explained in this thread that the protocol's current state of
>>> development relies on blocksize for security and, ultimately,
>>> as a means of protecting its degree of decentralization.
>>
>>
>> A slow or lack of increase to maximum transaction rate will cause
>> pressure on fees. Whether this is the desired goal is not
>> relevant. Everyone has agreed this will be the outcome. As to a
>> smaller block size being needed for additional decentralization,
>> one must simply ask how much we are all willing to pay for that
>> additional decentralization. It is likely that the benefit
>> thereto will have to be demonstrated by some power attacking and
>> destroying a less decentralized currency before the benefit of
>> this feature is given monetary value by the market. Until then,
>> value will bleed to the network with the least friction, because
>> it will have the greatest ability to grow its network effect.
>> That means the blockchain with adequate features and cheapest
>> fees will eventually have the largest market share.
>>
>>
>> -----Original Message----- From: Venzen Khaosan Sent: Wednesday,
>> July 29, 2015 3:11 PM To: Raystonn . Cc:
>> bitcoin-dev at lists.linuxfoundation.org Subject: Re: [bitcoin-dev]
>> Why Satoshi's temporary anti-spam measure isn'ttemporary
>>
> Raystonn, I'm aware that you're addressing your question to Greg
> Maxwell, however a point you keep stating as fact calls for
> reference:
>
> On 07/30/2015 04:28 AM, Raystonn . via bitcoin-dev wrote: [snip]
>>>>
>>>> How do you plan to address the bleeding of value from Bitcoin
>>>> to alternative lower-fee blockchains created by the
>>>> artificially-high bitcoin transaction fees when users begin
>>>> looking for the cheapest way to send value?
>
> Cheapest way to send value? Is this what Bitcoin is trying to do?
> So all of the smart contract, programmable money, consensus coding
> and tremendous developer effort is bent to the consumer demand for
> cheaper fees. Surely thou jests!
>
>>>> Modern economic study has shown that liquidity moves to the
>>>> location of least friction.
>
> Modern economic study? Can you please provide a link or reference
> to the study you are referring to.
>
> "liquidity moves to the location of least friction"
>
> This sounds like "econo-speak" and makes no sense. The definition
> of Liquidity is the degree to which an asset/security can be bought
> or sold in the market without affecting the price.
>
> That is why bitcoin is said to have low liquidity: buying or
> selling only 100 BTC visibly affects the exchange price. You
> probably mean "people like cheap fees", which is true, but as
> others have said, because of Bitcoin's powerful features, they are
> willing to pay higher fees and wait longer for transactions to
> execute.
>
> As for your public cross-examination of Greg Maxwell, your case
> seems to be made on the assumption that limiting the size of the
> blockchain is an attempt to artificially raise tx fees, but it is
> not the case (as you and others repeatedly argue) that reluctance
> to concede blocksize is an attempt to constrain capacity. Greg
> Maxwell thoroughly explained in this thread that the protocol's
> current state of development relies on blocksize for security and,
> ultimately, as a means of protecting its degree of
> decentralization.
>
> Surely, this is an obvious concern even for those who are
> campaigning for the hare-brained ideal of making Bitcoin a "faster,
> cheaper alternative" to visa or paypal? If we lose
> decentralization, we lose the whole thing, right? Incorrect or
> correct?
>> _______________________________________________ bitcoin-dev
>> mailing list bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJVuetlAAoJEGwAhlQc8H1m2TkH/jKx7V9vCZbOjbxAlfjnR0ai
+QDxMm0K0sL/MlsLVm0FAHwGiKhYJnEeXiZJlXu0eiUz35JALDMtSQiVbQzcHAc2
GvyW3tWUh6+uSfYhsnImQXxlDgCUKIgZvtTM900OWcGXZeLU3W5UdUK5+ietHK0/
1HbZgcljqke+nSsH2aCagd/iNdwCIUcfapsUgB6iPWtZQfLg6SHi8CjbG/Th5Na7
fpA5yJlO4N+Q2JpOVId/LfC7loDCEZtPtYA5NZAsDcEcSIXUycCoGL8LNMIFGJNe
Ko2RNqGeIkb/x8T2USxlkrNUZx/CCF201MMClPLC/LXX1bEMDvO8F0m1TBR1ptg=
=106o
-----END PGP SIGNATURE-----

2023-06-07 15:43:56

- reply

📅 Original date posted:2015-07-29
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Raystonn, I'm aware that you're addressing your question to Greg
Maxwell, however a point you keep stating as fact calls for reference:
On 07/30/2015 04:28 AM, Raystonn . via bitcoin-dev wrote:
[snip]
> How do you plan to address the bleeding of value from Bitcoin to
> alternative lower-fee blockchains created by the artificially-high
> bitcoin transaction fees when users begin looking for the cheapest
> way to send value?
Cheapest way to send value? Is this what Bitcoin is trying to do? So
all of the smart contract, programmable money, consensus coding and
tremendous developer effort is bent to the consumer demand for cheaper
fees. Surely thou jests!
> Modern economic study has shown that liquidity moves to the
> location of least friction.
Modern economic study? Can you please provide a link or reference to
the study you are referring to.
"liquidity moves to the location of least friction"
This sounds like "econo-speak" and makes no sense. The definition of
Liquidity is the degree to which an asset/security can be bought or
sold in the market without affecting the price.
That is why bitcoin is said to have low liquidity: buying or selling
only 100 BTC visibly affects the exchange price. You probably mean
"people like cheap fees", which is true, but as others have said,
because of Bitcoin's powerful features, they are willing to pay higher
fees and wait longer for transactions to execute.
As for your public cross-examination of Greg Maxwell, your case seems
to be made on the assumption that limiting the size of the blockchain
is an attempt to artificially raise tx fees, but it is not the case
(as you and others repeatedly argue) that reluctance to concede
blocksize is an attempt to constrain capacity. Greg Maxwell thoroughly
explained in this thread that the protocol's current state of
development relies on blocksize for security and, ultimately, as a
means of protecting its degree of decentralization.
Surely, this is an obvious concern even for those who are campaigning
for the hare-brained ideal of making Bitcoin a "faster, cheaper
alternative" to visa or paypal? If we lose decentralization, we lose
the whole thing, right? Incorrect or correct?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJVuU+rAAoJEGwAhlQc8H1m9nkH/00xXJ53H4qvHjPrdNRniwvB
RXi96QjbnVj/fxU2J2TBPYF1LxJ13avyL58bbaJF7GKqcpoYNZArCKLQyGaZGCTp
h7Oe/0S+b1QCrvxcVK8Ikeb7a1h9wnhAPf1FvAWoJ1cFGx/qGHetKqx1dQTWkVWz
Mp17vjaofmp2OhBzh0Smj+wV9hXn9w9giZKc6UGvC0Qc7Rf3GL/YVJzM2CZNvlLS
YhQSqnnqduugYztqLV/NvNExF41zC2IMyNmA41q46v/nh8stNSIcJleD39csNMfx
BXjrlnPfZ+JI4RhiH3I0qjOYWPtBH9od788DY509EOn3MT4vU+EVcQaxyuFqZyw=
=lQvy
-----END PGP SIGNATURE-----

2023-06-07 15:42:35

- reply

📅 Original date posted:2015-07-18
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
As an alternative to the preferred BIP100 this proposal is good
because it establishes a plan of action for dealing with the recent
ramp-up (100% increase) in number of transactions and transaction
size. Arguably, a transitory spam attack, yes, but with a speculative
rally brewing (and implied increases in network usage) this BIP may
prove to be just-in-time.
Solutions favoring dynamic vs. scheduled increases in blocksize (and
by how much) are interesting and the proponents should explore and map
out their proposal with data sets, trend projections and future
scenarios. It will require labor and time, but convince the list about
the scientific merit of your proposal.
In the meantime, the current "sufficient" state of network capacity
may soon experience "insufficient" moments. Developer confluence
around a workable plan and testing should, reasonably, begin now.
Jeff's proposal addresses an approaching capacity crunch whilst
honoring decentralization and providing time for testing and
alternative future innovations. It's the best solution the user base
and developers currently have for all the reasons Jeff gives:
conservative blocksize increase, added capacity, low impact and
minimal implication for the network and its users.
Then, many of the more far-reaching proposals being offered can be
tested, formalized, and fleshed out with scenario data.
On 07/17/2015 10:55 PM, Jeff Garzik via bitcoin-dev wrote:
> Opening a mailing list thread on this BIP:
>
> BIP PR: https://github.com/bitcoin/bips/pull/173 Code PR:
> https://github.com/bitcoin/bitcoin/pull/6451
>
> The general intent of this BIP is as a minimum viable alternative
> plan to my preferred proposal (BIP 100).
>
> If agreement is not reached on a more comprehensive solution, then
> this solution is at least available and a known quantity. A good
> backup plan.
>
> Benefits: conservative increase. proves network can upgrade.
> permits some added growth, while the community & market gathers
> data on how an increased block size impacts privacy, security,
> centralization, transaction throughput and other metrics. 2MB
> seems to be a Least Common Denominator on an increase.
>
> Costs: requires a hard fork. requires another hard fork down the
> road.
>
>
>
>
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJVqdbsAAoJEGwAhlQc8H1m3LIIAJeBKYp0HYWYONlBxFNeQfa8
4EpYmMxwTSsDZ62CxdinxEGY3eQTqQo0GGAjpfSict4hq9ivSy74eHRb7AZihdYm
znEVGMnedyMtSDvfyaUdIj/kkUX4k9mrcLyAAJB//E2e2BYQgs3esTAYx2ScCBiR
t/UQ9gIolezasUIEmEovaQG4vOXtwMEtlzXrYy7EiAGhtoBvb1w3CJ3xa8iuF4e7
aXsleE98e44wjs0T/xLbuV4d8lBpnb0i0laOH4rpl77plpTc1HlDzjjqibourPb7
SPZhfwnk5f++3PlNc/dtwEJLFw8p578S5aDWZhUX7h+DfRXSqF6WCxYvv6XdUGQ=
=eoPX
-----END PGP SIGNATURE-----

2023-06-07 15:41:17

- reply

📅 Original date posted:2015-06-30
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Michael, I snipped some of your comparison example to comment. I agree
with your sentiment to lobby for testing the change and your offer to
provide resources, yet it presents some (surmountable) challenges:
On 06/30/2015 10:34 PM, Michael Naber wrote:
> As you know I'm trying to lobby for a block size increase to a
> static 8MB.
>
> I'm happy to try to get the testing done that people want done for
> this, but I think the real crux of this issue is that we need to
> get consensus that we intend to continually push the block size
> upward as bounded only by technology.
Peter Todd, on 23/06/15, proposed a combined back-test and ongoing
forward test as follows:
"... the creation (via reorg) of a realistic full-load blockchain on
testnet to fully test the real-world behavior of the entire
infrastructure ecosystem, including questions like the scalability of
block explorers, SPV wallets, feasibility of initial syncronization,
scalability of the UTXO set, etc. While this is of course inconvenient
- - 2 years of 8MB blocks is 840GB worth of data..."
So, with a working dataset of that size, jumping to 8MB is excluding a
lot of participants and contributors to the testing - someone like
myself for example.
> Do what's best for Bitcoin and define what needs to get done to
> agree to a simple block size increase to a static 8MB.
And this then leads back to the core issue: if an 8MB blocksize
excludes many on this list from testnet, then the proposed 8MB blocks
will exclude a lot of mainnet participants (miners) and degrade the
quality of diversity and decentralization.
How about testing at double the capacity: 2MB?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJVksCfAAoJEGwAhlQc8H1m3E8H/jbfdoYPN3dvJuWWpaEEU+P4
SbdPHLd08ya7dmZEqmJcGBH29aHCD1roqs5PDA6pwNFb7CTD/6aoRGeQnkU16wMj
FQ5UQkmT96niQhtHE17vdpeMHI+LK8ox1n0R3de+3QRn1HbXEN+Q68jPl16KLd8+
SArZfVUauVGUtoJDVLxXv1q2mx2huTUTX/QNeYcTZ5IjB5huMypjwN7VpL9bM8gT
xoN8pd3tjBGAt1zoRFUWk5ZgCR5iDbRdujq032gIyc5CxtP3w+N/cfDKcEwmUd1j
MTX680NODq3K1ACIz+odEd1O6VFTQjHPZdF2SEtI5eHZRNH3RcccwZUJ7S04Fic=
=CHiQ
-----END PGP SIGNATURE-----

2023-06-07 15:40:50

- reply

📅 Original date posted:2015-06-27
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Very interesting point and comparison. So the fee market is unknown,
similar to a market maker's orderbook - except in the case of Bitcoin
it is not being deliberately hidden from users, its just not knowable
how miners are positioning at any given moment.
On 06/28/2015 12:54 AM, Peter Todd wrote:
> On Sat, Jun 27, 2015 at 07:46:55PM +0200, Benjamin wrote:
>> There is no ensured Quality of service, is there? If you "bid"
>> higher, then you don't know what you are going to get. Also
>> because you have no way of knowing what *others* are bidding.
>> Only if you have auctions (increasing increments) you can
>> establish a feedback loop to settle demand and supply. And the
>> supply side doesn't adapt. Adapting supply would help resolve
>> parts of the capacity problem.
>
> There's lots of markets where there is no assured quality of
> service, and where the bids others are making aren't known. Most
> financial markets work that way - there's only ever probabalistic
> guarantees that for a given amount of money you'll be able to buy a
> certain amount of gold at any given time for instance. Similarly
> for nearly all commodities the infrastructure required to mine
> those commodities has very little room for short, medium, or even
> long-term production increases, so whatever the production supply
> is at a given time is pretty much fixed.
>
>
>
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJVjuRiAAoJEGwAhlQc8H1mjnwIAIiUSPf6agfMXsFgupoihsTV
Pr1mJWHdLjrF5QadmdyooivYGPkY+zmfJ+N3fkr8l++PDGh03u0RgALf/gwJSSAQ
qSeMmjSZb8ZEkyLlZAGVHT8Ph+lRda65CVxYspKu/54TolqEezOHVaon9uWYVjtB
cSd8fWoqJMq05Pz25QPagxFUpXmtFX1KvxUWqeGkRsuqMgeWbCurQKpOhRXu48nH
Si73iOIyDUT9i1WsPvlpOi0pSxDlGnkMQKaEyIN5JJfKo1imRAtKVRLZh43rXpSW
jeZf8LMRwd49K4vnvHXZ0UbKWhpelh6XJari22citZ7yb5w5iENAcoP/cSGhLaY=
=nfF5
-----END PGP SIGNATURE-----

2023-06-07 15:40:43

- reply

📅 Original date posted:2015-06-28
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 06/28/2015 02:55 AM, Aaron Voisine wrote:
> On Sat, Jun 27, 2015 at 3:19 AM, Venzen Khaosan
> <venzen at mail.bihthai.net <mailto:venzen at mail.bihthai.net>> wrote:
>
>
> That is a false assumption. Given the increased adoption of Bitcoin
> by users and businesses during the past year, does the price chart
> reflect greater value or price? Of course not, the price chart is
> at terminal lows. Fact not fiction.
>
>
> You're not taking speculative cycles into account. For most of 2013
> the price was in the $100 range. Adoption as a store-of-value is
> what determines the price over the long term, as with any monetary
> commodity.
Aaron, I am most definitely taking speculative cycles into account - I
write Bitcoin market analysis reports on a daily basis.
Since discussion is exploring notions of "value" and assumptions about
"what increases value" I will post the following.
You're correct to point to the speculative influence, since Bitcoin
having the fundamentals it does, and being a commodity that floats
freely in the market, without centralized control - plus being
unregulated - it is a speculator's wildest dream come true. In this
case its exchange value (to fiat) is based on social mood and
perception and not on underlying (fundamental) value. I think that is
what you imply, too.
What is specifically relevant to the wider discussion, is your mention
of *Commodity Money*, because the term accurately describes a major
facet of Bitcoin's function and role.
Bitcoin's exchange rate, as a commodity money floating freely in the
market, will go up and down according to speculative cycles and we
should conceptually separate its valuation in fiat terms, from its
fundamental value which is: mathematical consensus, cryptographic
transaction security and censorship resistance, etc. These values are
critically reliant on Bitcoin's *degree of decentralization* for them
to remain true and for Bitcoin to retain its meaning, and, therefore,
its value. That is what I point out when I say "greater adoption has
not reflected in the price chart". And that may remain the case for
evermore because the value is in the protocol, the blockchain and its
utility and degree of decentralization, not in the chart or the size
of the user base (however, I'm by no means proposing that the user
base be limited - only that it be grown with primary reference to the
requirements imposed by decentralization).
I argue that we already know what the value of Bitcoin is. In its
current form Bitcoin most likely fulfills 80% or 90% of its eventual
fully evolved value. Increased adoption will not strengthen the
fundamentals, so let's proceed with scaling that will safeguard
Bitcoin's fundamental value and implement protections that ensure
quality of decentralization.
Given the start of a new speculative cycle for Bitcoin and the
possibility of a global liquidity crisis in the coming months or
years, block utilization may increase more rapidly than suggested by
current trends. Utilization may ramp up in a spike, so I agree with
suggestions made here for starting tests of a larger blocksize
(2-8MB), or for speeding up blocktime (whichever is technically
preferred).
Gavin Andresen has committed (if i recall correctly) to tests of 8MB
blocks, so a different size test can be agreed by Core developers.
Once test data and fork outcomes can be reviewed then decision making
has actual parameters to proceed from.
Venzen Khaosan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJVkCK8AAoJEGwAhlQc8H1m7c0IAKBjj3QHhBh5cqDKrVDpPsfv
GEdmjC4CVC+OCZR5TjJ71fsbx9s/9Yh1sglKPfKmInBbgUFeLuermpTnAC+GAEq9
rTPJgGKIIqax2vU9E8fLYrUC/uNk8wdB7PG50tQG+kOWATZOXWimy3Qi1hxOFLNI
bWhRlwIW4tO9HTz6M1WLNyv6T1G7eaUGskW3xODgmr69/ISbG4f/uv7Yy1leEu+r
64hwrswBkvIWeLvPJ3lkuA862HZxbLRkoehEpH3ULTUQ3bDJ1kUkSzi9Z4rwOfHG
p02hs69FVrfHckTtV7wQ4owHekiUT8hjob4V/3YrN0/qMGs4JmrxfyerfZ9GQ9o=
=hc1s
-----END PGP SIGNATURE-----

2023-06-07 15:40:42

- reply

📅 Original date posted:2015-06-27
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Advocations of "formalizing the process" may have a good outcome, but
that is not the issue in the current dilemma. The present process is
good enough. And that's as much as we can hope for.
The issue is: does Bitcoin need to scale to business or does business
need to scale to Bitcoin.
Business is not the Holy Spirit that fills Bitcoin with utility.
Bitcoin already has utility and finance capital would like to ride
that utility for its own profit motive. Some posters, here in this
list, would like to accelerate that process and they justify their
argument with the assumption that greater adoption equals greater
utility and value (and price).
That is a false assumption. Given the increased adoption of Bitcoin by
users and businesses during the past year, does the price chart
reflect greater value or price? Of course not, the price chart is at
terminal lows. Fact not fiction.
It is a fiction of common "market wisdom" that greater adoption
increases a commodity's value. Speculation plays with commodity value
even when underlying fundamental value remains unchanged. China has
verifiably been purchasing record amounts of Gold, but there is no
effect in the price chart (or on Gold's objective value).
Bitcoin's price chart will go up and down many times in the coming
years as speculators play their game. It's independent of the
underlying censorship resistance, mathematical consensus and
transaction security of Bitcoin. Once the decentralization is
sacrificed to big business then you can expect the final price chart low.
Until then, let's hold our horses and maintain an even keel: Bitcoin
is not trying to fit into the manic global economy's race toward the
edge of a precipice - Bitcoin is the solution once its all gone wrong
- - for ordinary users, not opportunistic bank-based business models
such as JPMorgan, Pantera Capital or BTC-China.
If you cannot see the inherent centralization problem with most
so-called Bitcoin businesses you just haven't done your homework.
On 06/27/2015 04:55 PM, NxtChg wrote:
>
> On 6/27/2015 at 10:43 AM, "Wladimir J. van der Laan"
> <laanwj at gmail.com> wrote:
>
>> It has been disappointing and scary to see political pressure
>> tactics being used to change a distributed consensus system.
>
> That's why some people are advocating formalizing the process.
> Political pressure will happen anyway, whether somebody likes it or
> not. It's better to deal with it in the open.
>
>
>> They cannot be changed willy-nilly according to needs of some
>> groups, much less than lower gravity can be legislated to help
>> the airline industry.
>
> Except the block size is not gravity. It's more like an arbitrary
> decision to limit planes' wingspan to the most typical hangar door
> of 1940.
>
> And now we have a "controversy" that we can't have modern planes
> out of the fear they won't fit into some of the old hangars.
>
> And to continue with this nice example, some people are even
> arguing that "the demand for flight is, essentially, limitless, so
> why bother making larger jets at all?"
>
>
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJVjnjHAAoJEGwAhlQc8H1m7CMH/273H3C7tnL56jJZ6U9RMbSN
dp2dPLusMJAvjWKiM/P5VjbcXnvARFuA3foIkzlxGdt2mvGlddW+b2x9YVZcDAZz
k9V/IccOmVVEvIpfaP0Awe6H9H8+Gr1PpFWuaFExcem9T9bF6kVGV4o0g6EGzwVe
rGJb0radm2qdWTKvUNvjXAF3kGRtoewFmTZBwyE6R6AxE7tvs/4Zvsf99+EQsD+o
3NZFlXX0gvPmaR7TWK0iOGlgns9MmKMm94xk8lHkESvW0NCMwTw6I0Pz74usPDte
U0lWkZBoKFWkEuf6ChVOOoSdSbYFrOwa0uaiJtPWJB+9TiwZdZbDJumW3uqYG5M=
=4vVg
-----END PGP SIGNATURE-----

2023-06-07 15:40:36

- reply

📅 Original date posted:2015-06-27
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Yes, Eric, blockchains are a means of mathematically determining
consensus among those who use them. The application goes beyond value
token into the realm of vote and deterministic politics. Eventually,
blockchains will allows citizens to choose state projects and to
contribute taxes according to their ability, and to benefit according
to their need.
Economic Participants
The dichotomy of the mining operator as an economic class on one hand
and the user as a dependent on the other is based on the current
Keynesian model of economics that views the centralized as inevitable
and the citizen as a consumer to be enlisted into spending at every
opportunity.
Schools of Thought
Although not a definitive answer, the Austrian School of Economics
illustrates that the Keynesian model (which we all harbor to some
degree, thanks to its global hegemony) is fundamentally flawed:
https://www.youtube.com/watch?v=SLfnpwHu4Hw (Of all the resources
available, this speaker is most succinct, although I cannot vouch for
his degree of Frankfurt School compliance or potential Zionist
leanings - the account conforms to academic agreement of what the
Austrian School of Economics stands for).
Developers are, by necessity, making economic decisions
If the developers will seize this moment of having to make economic
decisions about how Bitcoin will be influenced and grow according to
market dynamics, they should make an informed decision (only the
developers can make the decision at this time), they should strive to
make a well-informed decision - not some fumbled
"hurry-the-blocksize-is-running-out" decision. Pieter Wuille argues
the point convincingly in his initial post.
Fulcrum
The fundamental question to be answered here is: Do developers want to
compete with existing payment networks, or do developers want to
define Bitcoin's network in its own right?
If Bitcoin must compete and win, then centralize it and it will soon
beat the competition on every metric.
If Bitcoin is its own beast, then users and finance capital must adapt
to its constraints, for the benefit of all involved.
Developers have a crucial role to play in implementing economic
policy. It's not self-evident: a multinational or government sponsored
entity mining this blockchain with the purpose of dominating it does
not mean you have done your job of surrendering Bitcoin to the "free
market".
The decision rests on your informed understanding of economics (and
myths about economics) and choosing the way that liberates Bitcoin and
its users, and does not co-opt them into a system that seeks to devour
competition. Talk about making Bitcoin more compliant to finance
capital business is counter-Bitcoin and speakers harboring this
opinion have come to dominate discussion here. If increased business
and user adoption truly increased value, you would see it in the price
chart. What has ignorant, fashion-prone mainstreet adoption done for
Bitcoin? Will it really do something else, as some posters claim, or
will it do more of the same?
Venzen Khaosan
On 06/27/2015 09:18 AM, Eric Lombrozo wrote:
> I’ve been pondering this whole scale issue considerably…and am left
> with the conclusion that blockchains are ultimately dispute
> resolution mechanisms. The vast majority of crypto negotiation will
> be taking place at levels lesser than global consensus in the
> future - global consensus is just far too expensive to require for
> every single cappuccino. There really is little need to take most
> cases globally…unless the participants disagree. I’ve commented in
> other places that blockchains are essentially a “fix” to the
> prisoner’s dilemma - they make cooperation the equilibrium
> strategy.
>
> Regardless of whatever linear factor we scale the blockchain by, it
> is simple math to see that any exponential growth (even if for a
> short time) in usage will overwhelm the current network. If we ever
> intend to take bitcoin mainstream, we will most likely experience
> at least a short time of exponential growth…at least until we
> either reach an inherent limitation or until we saturate. As Pieter
> said earlier, FAPP right now the demand for payments might as well
> be infinite. We’re nowhere near the ability to service it all.
>
> The block size issue is really a usability issue at this point.
> There are two fundamental things we need to solve:
>
> 1) There’s no model for how we’ll introduce a fee market, even
> though the design of Bitcoin fundamentally depends on fees for its
> survival (at least in the current form of the design.)
>
> 2) There’s no mechanism for how to perform fee bidding and
> estimation. Most wallets simply have no way to do this without
> serious usability problems.
>
>
>
> If we’re going to talk about block fees, let’s keep it in the
> context of these relevant issues and not confound it with the
> scalability issue…these are two very different issues.
>
>
> - Eric Lombrozo
>
>
>> On Jun 26, 2015, at 1:44 PM, Owen Gunden <ogunden at phauna.org>
>> wrote:
>>
>> On 06/26/2015 02:23 PM, Jeff Garzik wrote:
>>> Failure to plan now for a hard fork increase 6(?) months in the
>>> future produces that lumpy, unpredictable market behavior.
>>>
>>> The market has baked in the years-long behavior of low fees.
>>> From the market PoV, inaction does lead to precisely that, a
>>> sudden change over the span of a few months.
>>
>> Which market participants are you referring to?
>>
>> I entered the bitcoin market with open eyes, aware that it faces
>> hard scalability challenges by design. I was also aware that
>> because of these challenges, eventually transaction fees would
>> have to rise.
>>
>> Nevertheless, I made the decision to invest because of the
>> utility I gain from the anti-censorship, privacy, control, store
>> of value, and security aspects of bitcoin -- many of which stem
>> from decentralization, which others have demonstrated to be
>> linked to the block size.
>>
>> On the other hand, there are undoubtedly other market
>> participants who heard hype about "zero fee transactions to
>> anywhere in the world", believed it would scale, and made
>> (mal)investments as a result.
>>
>> As for how many market participants of each flavor, and how deep
>> their respective pockets, who knows? My experience in markets has
>> lead me to realize that it's never wise to assume I know what
>> "the market" does and doesn't know. If Jeff Garzik is right about
>> what the market has priced in, then yes, filled blocks will be
>> rocking the boat. But who's to say that the smartest, biggest
>> investors and traders don't already see this scaling problem, and
>> have already priced it in? In this case, a sudden large increase
>> in the block size is actually rocking the boat. The point is, you
>> can't know either way, so trying to pre-empt the market in this
>> way is erroneous.
>>
>> Regarding entrepreneurial investment specifically, why should we
>> favor the entrepreneurs who require a more centralized bitcoin
>> over those who were more considerate of the possibility of rising
>> transaction fees when making their business models?
>>
>> In my mind, we should favor neither, which is why I'm basically
>> in agreement with Pieter that this sense of "emergency" shouldn't
>> really be a part of the debate.
>>
>> Not that I'm taking a stand on the specific block size issue
>> either way. I just think this particular line of reasoning
>> (presupposing what information the market has and has not already
>> baked in) is unsound.
>> _______________________________________________ bitcoin-dev
>> mailing list bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJVjlvYAAoJEGwAhlQc8H1malgH/jKkN27KpNecMQPcSZ+RX/s8
UDIvrqIsNesWUtwnWk1/2WcaoDA8V9ho42VPXmDgGh0GTmYKzKnBUuKPeIBfe1z+
XCtG7OeWRAlo+1Zk+dT8Crv/PEHocpy7q2OFW2iOapWfTEYO/1FTA58RYMYSmKXQ
0snm3QhVIdJA3/3BE12616y0+Oo2aV3H9El6buqQVge/26Z8X8TLIsY5h8dQbTBF
+J9Kq1YdJc8ogANZBpZfZBnURmNRsolyvQ+Sb5SxnpPQz73X3QPGaTyjnNsE0oVX
Occxx6BREN/byoelIS5HMRsEYExmALIisXTiM1kysKzbcYp+ysB6Uzvyp1GzbFg=
=PE+q
-----END PGP SIGNATURE-----

2023-06-07 15:40:28

- reply

📅 Original date posted:2015-06-26
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Apologies in advance for pulling you up on your statement, Tom, I've
noticed you're a regular and well respected poster in this list:
"free market" who?
Are you aware that the Bitcoin rally of 2013 was a result of
speculation by elements in Citi Bank, JPMorgan, and by many other Wall
Street trading desk managers who saw the opportunity of a
free-floating, unregulated commodity?
If the intention is to leave Bitcoin to the "free market" it already
is, and has been there for some time.
As for miners, those are finance capitalist interest too - if not
currently, in their majority, then eventually in China and the rest of
the world, so what does the term "free market" really mean? It must be
defined, because you are speaking to developers here, not visionary
economists or politicized brains, necessarily.
We cannot speak about "the market" without referencing concerns about
centralization, because any centralized business that plays the game
right seeks, by the rules, to corner the market. If they cannot do it
alone, they will seek allies.
"Free market" means as much under capitalism as "open democracy" under
Stalinism. Do you see my point? "Free Market" is a multivariate term
and Bitcoin does not (and should not have to) cater to all its
demands. That's like applying Microsoft standards to FOSS efforts -
becuase that's the "business use-case".
Bitcoin developers have to think about economy in an informed manner
and make provision with protection, else one can just make like Mike
Hearn and jump up and down shouting "faster-faster more-more".
Economics, markets and speculation is more complicated than that.
Venzen
On 06/26/2015 10:38 PM, Tom Harding wrote:
> On 6/26/2015 7:09 AM, Pieter Wuille wrote:
>> Furthermore, systems that compete with Bitcoin in this space
>> already offer orders of magnitude more capacity than we can
>> reasonably achieve with any blockchain technology at this point.
>
> "Reasonably achievable" is a guideline that would keep bitcoin out
> of trouble caused by either too little, or too much, declared
> capacity. This matches Gavin's thinking, though you may differ on
> the numbers.
>
>
>> it seems silly to make a huge increase at once...
>
> Unless it is reasonably achievable. Leave the rest to the free
> market.
>
>
>
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJVjXw4AAoJEGwAhlQc8H1mX2kIAJCLodhsEhkzxkzZl1hUITkZ
fFZWuiKomsHTHU+6cCr0snt0VDI7+mP8SgyawWrwXNKdGKqpiUAX+B454I9POYBQ
pf/CUq/sWMFN/WRO1EYpVBz3zH/mDgMUZeLvnGYti05+3YzxJxBsy2cmkX5HCfUL
oUErqWEo+OjeQNT+ZgFSbYYLSBLO2fDJglPzXD4eTF6RrK3AsZpHgnVqQzlAC+4G
Q7zRQN/h3voXJ5ed684Hy8bb04KKsEo0EYx2Nz6Hd9mGkSnnqydIa8ieJO3ChYyi
IDyJVXpDOth0TshZARbTFuicYg0ULUmU/l5x38Z3HFp9J1G4GFhnoivBwRozlQ8=
=a+o4
-----END PGP SIGNATURE-----

2023-06-07 15:40:26

- reply

📅 Original date posted:2015-06-26
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Pieter,
Sure. Your thinking is sound. I take things beyond where you have in
your post, so I neither imply that this is your position or that this
is the progression of your stated point.
In one sense, one has to ask the question: is there a reasonable case
for making Bitcoin super-capacitated so it can compete with Visa and
just be the fastest-ever payment network with everyone jizzing in
their pants over its speed and capacity and availability and dividends.
By virtue of the core requirement of decentralization, for Bitcoin to
remain meaningful, it will never compete with Visa or the Fed's new
blockchain-based payment system. So, why attempt the impossible and
expend energy on the futile?
Bitcoin's protocol and payment network has features and benefits that
Visa et all cannot have, so I refute the notion, sometimes expressed
here, that 7tps is a major cap on growth and adoption.
Such thinking takes as its axiom the idea that increased adoption
correlates to increased value. Not true. Look at the price chart for
proof: More businesses accept and more people are using and
transacting via Bitcoin now than ever before and yet the price chart
points *down*, not up.
Why should any explicitly centralized exchange and business venture
have their use of the protocol facilitated? Was the protocol designed
to conform to financial capital demands or was it designed to
fundamentally change the way ordinary users interact with markets?
If those present here, do not realize that the blockchain is a means
of escaping (and destroying through its use and promotion)
centralization, then they have shells over their eyes. Bitcoin is not
meant to fit into the system, it will evolve the system, by the system
coming to it.
Does that mean we shouldn't raise the blocksize? Maybe. But 8GB with
BIP100's protections seems a reasonable change given the sudden
increase in network usage that a global liquidity crisis will impose.
Many scenarios are possible, but there is no onus on developers or on
Bitcoin to "keep up". Like it or not, the global economy will
inevitably be forced to Slow Down as a result of the same thinking
that upholds constant growth without sympathetic contraction.
Venzen Khaosan
On 06/26/2015 09:09 PM, Pieter Wuille wrote:
> Hello all,
>
> here I'm going to try to address a part of the block size debate
> which has been troubling me since the beginning: the reason why
> people seem to want it.
>
> People say that larger blocks are necessary. In the long term, I
> agree - in the sense that systems that do not evolve tend to be
> replaced by other systems. This evolution can come in terms of
> layers on top of Bitcoin's blockchain, in terms of the technology
> underlying various aspects of the blockchain itself, and also in
> the scale that this technology supports.
>
> I do, however, fundamentally disagree that a fear for a change in
> economics should be considered to necessitate larger blocks. If it
> is, and there is consensus that we should adapt to it, then there
> is effectively no limit going forward. This is similar to how
> Congress voting to increase the copyright term retroactively from
> time to time is really no different from having an infinite
> copyright term in the first place. This scares me.
>
> Here is how Gavin summarizes the future without increasing block
> sizes in PR 6341:
>
>> 1. Transaction confirmation times for transactions with a given
>> fee
> will rise; very-low-fee transactions will fail to get confirmed at
> all.
>> 2. Average transaction fee paid will rise 3. People or
>> applications unwilling or unable to pay the rising fees
> will stop submitting transactions
>> 4. People and businesses will shelve plans to use Bitcoin,
>> stunting
> growth and adoption
>
> Is it fair to summarize this as "Some use cases won't fit any
> more, people will decide to no longer use the blockchain for these
> purposes, and the fees will adapt."?
>
> I think that is already happening, and will happen at any scale. I
> believe demand for payments in general is nearly infinite, and only
> a small portion of it will eventually fit on a block chain
> (independent of whether its size is limited by consensus rules or
> economic or technological means). Furthermore, systems that compete
> with Bitcoin in this space already offer orders of magnitude more
> capacity than we can reasonably achieve with any blockchain
> technology at this point.
>
> I don't know what subset of use cases Bitcoin will cater to in the
> long term. They have already changed - you see way less betting
> transactions these days than a few years ago for example - and they
> will keep changing, independent of what effective block sizes we
> end up with. I don't think we should be afraid of this change or
> try to stop it.
>
> If you look at graphs of block sizes over time (for example,
> http://rusty.ozlabs.org/?p=498), it seems to me that there is very
> little "organic" growth, and a lot of sudden changes (which could
> correspond to changing defaults in miner software, introduction of
> popular sites/services, changes in the economy). I think these can
> be seen as the economy changing to full up the available space, and
> I believe these will keep happening at any size effectively
> available.
>
> None of this is a reason why the size can't increase. However, in
> my opinion, we should do it because we believe it increases utility
> and understand the risks; not because we're afraid of what might
> happen if we don't hurry up. And from that point of view, it seems
> silly to make a huge increase at once...
>
> -- Pieter
>
>
>
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJVjWQAAAoJEGwAhlQc8H1mIRMH/Rr8v+N3XdAL/EeEXuniT+Iu
/TrtieLJKrhmMPkyIX/jAWc4ggUirzWuTMIQZ7qPwOkVrbcWPcKKHOBKTmmUaCc5
GdnA8wiiC6D6ZMamO1NKtkU2QW7Kzuna/Y4EeqBZWsKWPrMvu1vkirDYH8XRvdiC
bMksVCzoRFm7QnTMYfimrSYNxNPdwQZxCfhtJDSBnJs2Mi0J68Xpw5riVbx6S0mD
TOcNlKWosQJEub11TWeh+wD3i901t5GfxFqBNU5XGN85JRn+vAIrrm2io0bbfbIZ
y58XdqcYcWrx8MQNUdHpQT1EK5+4DAkhxrouW60sjk8jfWHGIVIgfYweDQawbOg=
=f9Fg
-----END PGP SIGNATURE-----

2023-06-07 15:39:37

- reply

📅 Original date posted:2015-06-22
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Granted this is not the gnuPG support list, it would help me and most
members, here, to know just a little more, following your gpg advice
about publishing keys:
Say, subsequent to publishing a key to a keyserver, I then sign that
key (or someone else signs it)
1) would the key need to be published again?
2) does the key used to sign it need to be published in order to make
signature verification possible?
Venzen
On 06/22/2015 09:06 AM, Peter Todd wrote:
> gpg --keyserver hkp://keys.gnupg.net --send-key
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJVh6/4AAoJEGwAhlQc8H1mlL0IAIFZdzyzawOjc43SODLYePo6
NJU+DRKCQLiNhiED/keCFR/t51XarY4dvgG81wr1qskckRarW6s2ZEWU/2l4oaHa
Ys+yO5ASbWOp9jbcBWIMFcAou+ULYx732wqEGTXOgSXljrSsuGa4DO+8vSW1UToc
kY6BhFUa9rjEUQXt+gUqfrXiFlgRFHY4/nd1Tk47VEBipZgcQsJr4j6SYhlXHfbb
CpixpFeIeVFfdHSNQiDMqPkF3xsTLQcqq2LvZpT8TXrA5vQ0wv/gZH49zIIy5QjR
xjmSb1tZl0GZRTZ3CYCsoK4Zq4BdhqdU8XIhlwACC2WXHFDnqQrTXwH4nLeWcG0=
=pYDp
-----END PGP SIGNATURE-----