📅 Original date posted:2015-06-27
📝 Original message:"Thus we have a fixed capacity system where access is mediated by supply
and demand transaction fees."
There is no supply and demand. That would mean users would be able to adapt
fees and get different quality of service depending on current capacity.
For example if peak load is 10x average load, then at those times fees
would be higher and users would delay transactions to smooth out demand.
On Sat, Jun 27, 2015 at 7:20 PM, Peter Todd <pete at petertodd.org> wrote:
> On Sat, Jun 27, 2015 at 12:19:04PM -0400, Michael Naber wrote:
> > That test seems like a reasonable suggestion; 840GB is not prohibitive
> > given today's computing costs. What other than the successful result of
> > that test would you want to see before agreeing to increase the block
> size
> > to 8MB?
>
> The two main things you need to show is:
>
> 1) Small, anonymous, miners remain approximately as profitable as large
> miners, regardless of whether they are in the world, and even when
> miners are under attack. Remember I'm talking about mining here, not
> just hashing - the process of selling your hashpower to someone else who
> is actually doing the mining.
>
> As for "approximately as profitable", based on a 10% profit margin, a 5%
> profitability difference between a negligable ~0% hashing power miner
> and a 50% hashing power miner is a good standard here.
>
> The hard part here is basically keeping orphan rates low, as the %5
> profitability different on %10 profit margin implies an orphan rate of
> about 0.5% - roughly what we have right now if not actually a bit lower.
> That also implies blocks propagate across the network in just a few
> seconds in the worst case, where blocks are being generated with
> transactions in them that are not already in mempools - circumventing
> propagation optimization techniques. As we're talking about small
> miners, we can't assume the miners are directly conneted to each other.
> (which itself is dangerous from an attack point of view - if they're
> directly connected they can be DoS attacked)
>
> 2) Medium to long term plan to pay for hashing power. Without scarcity
> of blockchain space there is no reason to think that transaction fees
> won't fall to the marginal cost of including a transaction, which
> doesn't leave anything to pay for proof-of-work security. A proposal
> meeting this criteria will have to be clever if you don't keep the
> blocksize sufficiently limited that transaction fees are non-negligable.
> One possible approach - if probably politically non-viable - would be to
> change the inflation schedule so that the currency is inflated
> indefinitely.
>
> --
> 'peter'[:-1]@petertodd.org
> 0000000000000000007fc13ce02072d9cb2a6d51fae41fefcde7b3b283803d24
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150627/df971066/attachment.html>;
Benjamin [ARCHIVE] /
npub17k…sr5tq
2023-06-07 15:40:48
in reply to nevent1q…843j
Author Public Key
npub17kz55p7ysz4ftvq2xyr2zamc776cygwcm5fdz8ndj3jm5umm65xq4sr5tqPublished at
2023-06-07 15:40:48Event JSON
{
"id": "0a85b8bad43c7667ec009259c63a554c361dce82a82323ca857129fbb5201a6c",
"pubkey": "f5854a07c480aa95b00a3106a17778f7b58221d8dd12d11e6d9465ba737bd50c",
"created_at": 1686152448,
"kind": 1,
"tags": [
[
"e",
"302bda6b5cc3b22bc31708bc8101794c3e35655f608a2a34ebc62e92bc3dada4",
"",
"root"
],
[
"e",
"e857a1575532f87cc806cdab5cede9a1eda2d1c4750fa319d026d80b3709e867",
"",
"reply"
],
[
"p",
"daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa"
]
],
"content": "📅 Original date posted:2015-06-27\n📝 Original message:\"Thus we have a fixed capacity system where access is mediated by supply\nand demand transaction fees.\"\n\nThere is no supply and demand. That would mean users would be able to adapt\nfees and get different quality of service depending on current capacity.\nFor example if peak load is 10x average load, then at those times fees\nwould be higher and users would delay transactions to smooth out demand.\n\nOn Sat, Jun 27, 2015 at 7:20 PM, Peter Todd \u003cpete at petertodd.org\u003e wrote:\n\n\u003e On Sat, Jun 27, 2015 at 12:19:04PM -0400, Michael Naber wrote:\n\u003e \u003e That test seems like a reasonable suggestion; 840GB is not prohibitive\n\u003e \u003e given today's computing costs. What other than the successful result of\n\u003e \u003e that test would you want to see before agreeing to increase the block\n\u003e size\n\u003e \u003e to 8MB?\n\u003e\n\u003e The two main things you need to show is:\n\u003e\n\u003e 1) Small, anonymous, miners remain approximately as profitable as large\n\u003e miners, regardless of whether they are in the world, and even when\n\u003e miners are under attack. Remember I'm talking about mining here, not\n\u003e just hashing - the process of selling your hashpower to someone else who\n\u003e is actually doing the mining.\n\u003e\n\u003e As for \"approximately as profitable\", based on a 10% profit margin, a 5%\n\u003e profitability difference between a negligable ~0% hashing power miner\n\u003e and a 50% hashing power miner is a good standard here.\n\u003e\n\u003e The hard part here is basically keeping orphan rates low, as the %5\n\u003e profitability different on %10 profit margin implies an orphan rate of\n\u003e about 0.5% - roughly what we have right now if not actually a bit lower.\n\u003e That also implies blocks propagate across the network in just a few\n\u003e seconds in the worst case, where blocks are being generated with\n\u003e transactions in them that are not already in mempools - circumventing\n\u003e propagation optimization techniques. As we're talking about small\n\u003e miners, we can't assume the miners are directly conneted to each other.\n\u003e (which itself is dangerous from an attack point of view - if they're\n\u003e directly connected they can be DoS attacked)\n\u003e\n\u003e 2) Medium to long term plan to pay for hashing power. Without scarcity\n\u003e of blockchain space there is no reason to think that transaction fees\n\u003e won't fall to the marginal cost of including a transaction, which\n\u003e doesn't leave anything to pay for proof-of-work security. A proposal\n\u003e meeting this criteria will have to be clever if you don't keep the\n\u003e blocksize sufficiently limited that transaction fees are non-negligable.\n\u003e One possible approach - if probably politically non-viable - would be to\n\u003e change the inflation schedule so that the currency is inflated\n\u003e indefinitely.\n\u003e\n\u003e --\n\u003e 'peter'[:-1]@petertodd.org\n\u003e 0000000000000000007fc13ce02072d9cb2a6d51fae41fefcde7b3b283803d24\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150627/df971066/attachment.html\u003e",
"sig": "bcd36e213687463085552e631e270fd2728db71788236daa28b0a5c3eb118ddf052f91f97e3c713b86c535b5297d2e6edbb646787a07c5b3c0ffd73669dfa9bc"
}