<unnamed>

Public Key

npub1uu2fve28mkg68uequseraz8gee7qg64733lr9r2g4c0xs5pmqnuslr4rpf

Profile Code

nprofile1qqsww9ykv4ramydr7vswgv373r5vulqyd2lgcl3j34y2u8ng2qasf7gpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsw0da83

Publishing to

relay.damus.io

nos.lol

Last Notes

2023-06-07 19:42:40 CEST

- 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 19:42:39 CEST

- 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 19:34:48 CEST

- 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 19:34:44 CEST

- 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 19:33:52 CEST

- 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 19:33:49 CEST

- 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 19:32:30 CEST

- 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 19:32:28 CEST

- 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 19:32:27 CEST

- 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 19:32:25 CEST

- 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:46:39 CEST

- reply

2023-06-07 17:45:57 CEST

- reply

2023-06-07 17:45:55 CEST

- reply

2023-06-07 17:44:49 CEST

- reply

2023-06-07 17:44:48 CEST

- reply

2023-06-07 17:44:46 CEST

- reply

2023-06-07 17:44:15 CEST

- 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 17:44:00 CEST

- 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 17:43:58 CEST

- 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 17:43:56 CEST

- 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 17:42:35 CEST

- 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 17:40:50 CEST

- 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 17:40:36 CEST

- 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 17:40:28 CEST

- 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 17:40:26 CEST

- 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-----