<unnamed>

Public Key

npub1elukp7mw8u8j8ll4u9rnzp3y95plykvepdyx2uekam7ucxx2f56smdc8ht

Profile Code

nprofile1qqsvl7tqldhr7rerll67z3e3qcjz6qljtxvskjr9wvmwalwvrr9y6dgpzemhxue69uhhyetvv9ujuurjd9kkzmpwdejhg32c9qp

Publishing to

relay.primal.net

Last Notes

2023-06-07 15:34:44 UTC

- reply

📅 Original date posted:2015-05-11
📝 Original message:On 2015-05-11 16:28, Thomas Voegtlin wrote:
> My problem is that this seems to lacks a vision. If the maximal block
> size is increased only to buy time, or because some people think that 7
> tps is not enough to compete with VISA, then I guess it would be
> healthier to try and develop off-chain infrastructure first, such as
> the
> Lightning network.
If your end goal is "compete with VISA" you might as well just give up
and go home right now. There's lots of terrible proposals where people
try to demonstrate that so many hundred thousand transactions a second
are possible if we just make the block size 500GB. In the real world
with physical limits, you literally can not verify more than a few
thousand ECDSA signatures a second on a CPU core. The tradeoff taken
in Bitcoin is that the signatures are pretty small, but they are also
slow to verify on any sort of scale. There's no way competing with a
centralised entity using on-chain transactions is even a sane goal.

2023-06-07 15:34:06 UTC

- reply

📅 Original date posted:2015-05-29
📝 Original message:Are you really that pig headed that you are going to try and blow up the
entire system just to get your way? A bunch of ignorant redditors do not
make consensus, mercifully.
On 2015-05-29 12:39, Gavin Andresen wrote:
> What do other people think?
>
> If we can't come to an agreement soon, then I'll ask for help
> reviewing/submitting patches to Mike's Bitcoin-Xt project that
> implement a big increase now that grows over time so we may never have
> to go through all this rancor and debate again.
>
> I'll then ask for help lobbying the merchant services and exchanges
> and hosted wallet companies and other bitcoind-using-infrastructure
> companies (and anybody who agrees with me that we need bigger blocks
> sooner rather than later) to run Bitcoin-Xt instead of Bitcoin Core,
> and state that they are running it. We'll be able to see uptake on the
> network by monitoring client versions.
>
> Perhaps by the time that happens there will be consensus bigger blocks
> are needed sooner rather than later; if so, great! The early
> deployment will just serve as early testing, and all of the software
> already deployed will ready for bigger blocks.
>
> But if there is still no consensus among developers but the "bigger
> blocks now" movement is successful, I'll ask for help getting big
> miners to do the same, and use the soft-fork block version voting
> mechanism to (hopefully) get a majority and then a super-majority
> willing to produce bigger blocks. The purpose of that process is to
> prove to any doubters that they'd better start supporting bigger
> blocks or they'll be left behind, and to give them a chance to upgrade
> before that happens.
>
> Because if we can't come to consensus here, the ultimate authority for
> determining consensus is what code the majority of merchants and
> exchanges and miners are running.
>
> --
>
> --
> Gavin Andresen
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development