📅 Original date posted:2017-09-01
📝 Original message:Yes. I meant the single thread as an analogy, if a block is found, other
blocks are worthless. (more or less) Longest chain wins.
My line of though was, that currently the only way to scale with the
traffic (and lowering the fees) is increasing the block size (which is hard
as I learned from recent events), or reducing the complexity which is less
secure (most likely more controversial)
Splitting the chain is effectively increasing the block size, but without
the increased hashing and validation overhead.
The usage growth seems to be more of exponential rather than linear. Sooner
or later the block size will need to be 4 mb then 40 mb, then what is the
real limit? Otherwise waiting times and thus the fees will just grow
rapidly. I don't think that it is desirable.
With splitting the ledger, the block size can remain 1-2 mb for long time,
only new partitions needs to be added on a schedule. This would also make
better use of the hashing capacity.
Cheers,
Tamas
On Fri, Sep 1, 2017 at 7:15 PM Lucas Clemente Vella <lvella at gmail.com>
wrote:
> > The current chain is effectively single threaded.
>>
>> This is not true, since xthin/compactblocks have been introduced we
>> completely removed this bottle-neck.
>> The transactions will be validated continuously, in parallel and not just
>> when a block is found.
>>
>
> If I understood correctly, OP was not talking about the process inside a
> node being single threaded, but instead that the whole bitcoin distributed
> system behaves as single threaded computation. OP seems to be describing a
> system closer to what IOTA uses, by distributing among the miners the task
> of validating the transactions. Although, without more specific details, it
> is hard to judge the benefits.
>
> --
> Lucas Clemente Vella
> lvella at gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170901/d908e965/attachment.html>;
Cserveny Tamas [ARCHIVE] /
npub1hd…ukpkd
2023-06-07 18:05:14
in reply to nevent1q…498p
Author Public Key
npub1hd9vr878fmlk833xsv3t5cqljjqdc56aalyytkdvjp9sfv699s2s8ukpkdPublished at
2023-06-07 18:05:14Event JSON
{
"id": "be5e97b01fd1de048cf21abcf3bb88f65e6c17abe3a82120945d3f83a4800157",
"pubkey": "bb4ac19fc74eff63c6268322ba601f9480dc535defc845d9ac904b04b3452c15",
"created_at": 1686161114,
"kind": 1,
"tags": [
[
"e",
"f0961e135bc3b7ff86ca66a0fab34377a52156a691597288b49433b7e45bba36",
"",
"root"
],
[
"e",
"1d7d9d3c9c361f1aea24cd9aaf0a25a1e4e94cf54a4437af878c816975617f15",
"",
"reply"
],
[
"p",
"8e9ded2eb9fca290998203d61b6d50df7ac2f6dcf13d8c484cbdee405f963df7"
]
],
"content": "📅 Original date posted:2017-09-01\n📝 Original message:Yes. I meant the single thread as an analogy, if a block is found, other\nblocks are worthless. (more or less) Longest chain wins.\n\nMy line of though was, that currently the only way to scale with the\ntraffic (and lowering the fees) is increasing the block size (which is hard\nas I learned from recent events), or reducing the complexity which is less\nsecure (most likely more controversial)\n\nSplitting the chain is effectively increasing the block size, but without\nthe increased hashing and validation overhead.\n\nThe usage growth seems to be more of exponential rather than linear. Sooner\nor later the block size will need to be 4 mb then 40 mb, then what is the\nreal limit? Otherwise waiting times and thus the fees will just grow\nrapidly. I don't think that it is desirable.\n\nWith splitting the ledger, the block size can remain 1-2 mb for long time,\nonly new partitions needs to be added on a schedule. This would also make\nbetter use of the hashing capacity.\n\nCheers,\n\nTamas\n\n\n\n\n\n\nOn Fri, Sep 1, 2017 at 7:15 PM Lucas Clemente Vella \u003clvella at gmail.com\u003e\nwrote:\n\n\u003e \u003e The current chain is effectively single threaded.\n\u003e\u003e\n\u003e\u003e This is not true, since xthin/compactblocks have been introduced we\n\u003e\u003e completely removed this bottle-neck.\n\u003e\u003e The transactions will be validated continuously, in parallel and not just\n\u003e\u003e when a block is found.\n\u003e\u003e\n\u003e\n\u003e If I understood correctly, OP was not talking about the process inside a\n\u003e node being single threaded, but instead that the whole bitcoin distributed\n\u003e system behaves as single threaded computation. OP seems to be describing a\n\u003e system closer to what IOTA uses, by distributing among the miners the task\n\u003e of validating the transactions. Although, without more specific details, it\n\u003e is hard to judge the benefits.\n\u003e\n\u003e --\n\u003e Lucas Clemente Vella\n\u003e lvella at gmail.com\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170901/d908e965/attachment.html\u003e",
"sig": "2214ff7924a64ec257517cade56ba87f78e9e5b448aa107b09b18f543b991d01e7aa664dfc063e47cd24d6d50dd5f877f29bfa849d507d21ed062b4c3ad9283c"
}