📅 Original date posted:2021-12-16
📝 Original message:@Jeremy
> for top-level pool participants there is never any central custody.
I definitely see that. That was actually what I meant when I said the goals
aren't the same as benefits. While your idea definitely satisfies all your
goals in a modular way, the fact that it relies on pools means that unless
the pools can also satisfy the goals, the total system also doesn't satisfy
the goals (even tho the piece of that system you designed does).
> Thus it doesn't "hurt" anyone except for the miners who are taking the
not fully locked in funds risk
True, it only potentially hurts whoever the channel partner is accepting
the unspendable coins. And no one can really stop anyone from taking that
risk if they really want to. But in that case, its not exactly a fully
functional channel, since recourse mechanisms couldn't be performed.
Wouldn't that open such a channel up to a pretty bad theft possibility?
@Bob
> Increased payout regularity does not lower the viable size of mining
pools, because smaller mining pools using this mechanism still have higher
variance.
Yes, smaller mining pools will always have higher variance. However, lower
variance has diminishing benefits. Below a certain amount of variance, less
variance isn't very valuable. So increased payout regularity does indeed
lower the viable size of mining pools because a given low-enough level of
variance can be achieved with less pool hashpower.
> The on-chain footprint is *higher* due to the increased payout regularity.
That's a reasonable point. However, I think there is a difference here
between the regularity of rewards vs payouts. Rewards for each miner can be
more regular without necessarily increasing the number of on-chain payouts.
In fact, theoretically, an individual miner could let their rewards
accumulate in a pool over many rewards and only redeem when they need the
coins for something. The incentive is there for each miner to be judicious
on how much onchain space they take up.
@vjudeu
> how many block headers should be stored per one "superblock"?
I was thinking that this would be a separate blockchain with separate
headers that progress linearly like a normal blockchain. A block creator
would collect together as many blocks that haven't been collected yet into
the next superblock (and maybe receive a reward proportional to how many /
how much weight they include). This could be done using merge mining, or it
could be done using a signing scheme (eg where the block creator signs to
say "I created this superblock" and have mechanisms to punish those who
sign multiple superblocks at the same height. For merge mining, I could
even imagine the data necessary to validate that it has been merge mined
could be put into a taproot script branch (creating an invalid script, but
a valid hash of the superblock).
> we can collect all headers with the same previous block hash, and
distribute block reward between all coinbase transactions in those headers
Exactly.
> we would just have block headers instead of transactions
Yeah, I think that would be the way to go. Really, you could even just use
hashes of the block headers. But the size doesn't matter much because it
would be both a small blockchain and an ephemeral one (which can be fully
discarded after all parties have been paid out, or at least their payout
has been committed to on the bitcoin blockchain).
On Thu, Dec 16, 2021 at 1:35 AM <vjudeu at gazeta.pl> wrote:
> > The missing piece here would be an ordering of weak blocks to make the
> window possible. Or at least a way to determine what blocks should
> definitely be part of a particular block's pay out. I could see this being
> done by a separate ephemeral blockchain (which starts fresh after each
> Bitcoin block) that keeps track of which weak blocks have been submitted,
> potentially using the pow already in each block to secure it. Granted that
> piece is a bit half baked, but it seems quite solvable. Wdyt?
>
> I thought about something like that, but there is one problem: how many
> block headers should be stored per one "superblock"? Currently, we have
> single block header, where the whole coinbase transaction is taken by some
> mining pool or solo miner. But instead, each miner could submit its own
> block header. Then, we can collect all headers with the same previous block
> hash, and distribute block reward between all coinbase transactions in
> those headers. One "superblock" then would be created in a similar way as
> existing blocks, we would just have block headers instead of transactions.
> If most transactions inside those blocks will be the same, then each block
> could be expressed just as a set of transaction hashes, only coinbase
> transactions or custom, non-broadcasted transactions included by miners
> will be revealed, everything else will be known.
>
> > One thing that jumped out at me as not safe is throwing block rewards
> into a channel and being able to spend them immediately. There's a reason
> block rewards aren't spendable for a while, and channels don't solve that
> problem, do they? Why not simply reduce the on chain wait time for spending
> block rewards at that point? Seems like the consequences would be the same.
>
> All coinbase rewards are unspendable for 100 blocks, it is enforced by
> consensus. It does not matter if there are outputs owned directly by
> miners, or if there is one huge N-of-N taproot multisig for the whole pool,
> where every miner signed the closing transaction. The only option to take
> coins faster I can see is swapping the coins by some LN transaction. But
> then, the other party can check if some deposit to the LN channel is a part
> of the coinbase transaction or not, and then decide if it is acceptable to
> do the swap.
>
> On 2021-12-15 19:00:44 user Billy Tetrud via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Looks like an interesting proposal, but it doesn't seem to quite match the
> goals you mentioned. As you do mention, this mining pool coordination
> doesn't get rid of the need for mining pools in the first place. So it
> doesn't satisfy item 1 on your goal list afaict.
>
> The primary benefits over what we have today that I can see are:
> 1. increased payout regularity, which lowers the viable size of mining
> pools, and
> 2. Lower on chain footprint through combining pay outs from multiple pools.
>
> Am I missing some?
>
> These are interesting benefits, but it would be nice if your post was
> clearer on that, since the goals list is not the same as the list of
> potential benefits of this kind of design.
>
> As far as enabling solo mining, what if this concept were used off chain?
> Have a public network of solo miners who publish "weak blocks" to that
> network, and the next 100 (or 1000 etc) nice miners pay you out as long as
> you're also being nice by following the protocol? All the nice
> optimizations you mentioned about eg combined taproot payouts would apply i
> think. The only goals this wouldn't satisfy are 3 and 5 since an extra
> network is needed, but to be fair, your proposal requires pools which all
> need their own extra network anyways.
>
> The missing piece here would be an ordering of weak blocks to make the
> window possible. Or at least a way to determine what blocks should
> definitely be part of a particular block's pay out. I could see this being
> done by a separate ephemeral blockchain (which starts fresh after each
> Bitcoin block) that keeps track of which weak blocks have been submitted,
> potentially using the pow already in each block to secure it. Granted that
> piece is a bit half baked, but it seems quite solvable. Wdyt?
>
> One thing that jumped out at me as not safe is throwing block rewards into
> a channel and being able to spend them immediately. There's a reason block
> rewards aren't spendable for a while, and channels don't solve that
> problem, do they? Why not simply reduce the on chain wait time for spending
> block rewards at that point? Seems like the consequences would be the same.
>
> On Tue, Dec 14, 2021, 16:12 Bob McElrath via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org
> <http://../NowaWiadomosc/Do/QlIkBFQ6QUFhIVRZX192dnQBeCtCchE6GhA5LFpLCUc7EVZQVl9dQRIXXR8NCBMbCwIGChJXQFxcXEgcFh8UVVVDEyBdVkE9JVRdEwFhYXVlblhVIkosEAszLR5BQVV7U0MID0BAQUgIGh0RHgAMGAMXBQJfW1sdXRQUQUoDQlAiBFY8>>;
> wrote:
>
>> You are hand waving. Attempting to redefine terms to justify your
>> argument is
>> intellectually dishonest. Bitcoin pools have *always* been about variance
>> reduction. Your window function fundamentally CANNOT be used to hedge
>> hashrate.
>> Various suggestions below introduce dangerous new games that might be
>> played by
>> miners.
>>
>> The fact is that the half-baked design you posted is less than useless,
>> and
>> doesn't do anything that anyone wants.
>>
>> You are trying to justify CTV by making it be all things to all people.
>> "When
>> all you have is a hammer, every problem looks like a nail". Instead I
>> humbly
>> suggest that you pick ONE problem for which CTV is demonstrably the right
>> and
>> best solution, instead of snowing us with a ton of half-baked things that
>> *could* be done, and often don't even require CTV, and some (like this
>> one)
>> fundamentally don't work. I do like some of your ideas, but if you had to
>> pick
>> just one "use case", which would it be?
>>
>> Jeremy [jlrubin at mit.edu
>> <http://../NowaWiadomosc/Do/QlIkBFQ6QUFhIVRZX192dnQBeCtCchEyHxYvIVpLARduChoQSFZQR0NWQVZWJUNRXwMSCRMTBgcWASdWVkpbCxUTQwoWQUdjKVBMGFY3MWMWeU9QBAZtNw%3D%3D>;]
>> wrote:
>> > Bitcoin didn't invent the concept of pooling:
>> https://en.wikipedia.org/wiki/
>> > Pooling_(resource_management). This is a Bitcoin Mining Pool, although
>> it may
>> > not be your favorite kind, which is fixated on specific properties of
>> computing
>> > contributions before finding a block. Pooling is just a general
>> technique for
>> > aggregating resources to accomplish something. If you have another name
>> like
>> > pooling that is in common use for this type of activity I would be more
>> than
>> > happy to adopt it.
>> >
>> > This sort of pool can hedge not only against fee rates but also against
>> > increases in hashrate since your historical rate 'carries' into the
>> future as a
>> > function of the window. Further, windows and reward functions can be
>> defined in
>> > a myriad of ways that could, e.g., pay less to blocks found in more
>> rapid
>> > succession, contributing to the smoothing functionality.
>> >
>> > With respect to sub-block pooling, as described in the article, this
>> sort of
>> > design also helps with micro-pools being able to split resources
>> > non-custodially in every block as a part of the higher order DCFMP. The
>> point
>> > is not, as noted, to enable solo mining an S9, but to decrease the size
>> of the
>> > minimum viable pool. It's also possible to add, without much validation
>> or
>> > data, some 'uncle block' type mechanism in an incentive compatible way
>> (e.g.,
>> > add 10 pow-heavy headers on the last block for cost 48 bytes header +
>> 32 bytes
>> > payout key) such that there's an incentive to include the heaviest ones
>> you've
>> > seen, not just your own, that are worth further study and consideration
>> > (particularly because it's non-consensus, only for opt-in participation
>> in the
>> > pool).
>> >
>> > With respect to space usage, it seems you wholly reject the viability
>> of a
>> > payment pool mechanism to cut-through chain space. Is this a critique
>> that
>> > holds for all Payment Pools, or just in the context of mining? Is there
>> a
>> > particular reason why you think it infeasible that "strongly online"
>> > counterparties would be able to coordinate more efficiently? Is it
>> preferable
>> > for miners, the nexus of decentralization for Bitcoin, to prefer to use
>> > custodial services for pooling (which may require KYC/AM) over bearing
>> a cost
>> > of some extra potential chainload?
>> >
>> > Lastly, with respect to complexity, the proposal is actually incredibly
>> simple
>> > when you take it in a broader context. Non Interactive Channels and
>> Payment
>> > Pools are useful by themselves, so are the operations to merge them and
>> swap
>> > balance across them. Therefore most of the complexity in this proposal
>> is
>> > relying on tools we'll likely see in everyday use in any case, DCFMP or
>> no.
>> >
>> > Jeremy
>> > !DSPAM:61b8f2f5321461582627336!
>> --
>> Cheers, Bob McElrath
>>
>> "For every complex problem, there is a solution that is simple, neat, and
>> wrong."
>> -- H. L. Mencken
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> <http://../NowaWiadomosc/Do/QlIkBFQ6QUFhIVRZX192dnQBeCtCchE6GhA5LFpLCUc7EVZQVl9dQRIXXR8NCBMbCwIGChJXQFxcXEgcFh8UVVVDEyBdVkE9JVRdEwFhYXVlblhVIkosEAszLR5BQVV7U0MID0BAQUgIGh0RHgAMGAMXBQJfW1sdXRQUQUoDQlAiBFY8>;
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211216/d18efb77/attachment-0001.html>;
Billy Tetrud [ARCHIVE] /
npub1xq…tcnns
2023-06-07 23:01:23
in reply to nevent1q…pxqj
Author Public Key
npub1xqcwcttsyk0a64d63crrwsxp88pa42np37rw87hrfn4uku78g2aqltcnnsPublished at
2023-06-07 23:01:23Event JSON
{
"id": "d88c0788565f74e658f87890919e2f25b5910a1a28152990a6e6677831c2c156",
"pubkey": "3030ec2d70259fdd55ba8e063740c139c3daaa618f86e3fae34cebcb73c742ba",
"created_at": 1686178883,
"kind": 1,
"tags": [
[
"e",
"9a9e1cb20e5c4bb51b22b23239ac4878d89ce4dba6ef6fe0cc58cd4270d58751",
"",
"root"
],
[
"e",
"9cf73ee829de804d1ec6702a2392928fb4ab6dc8a3918a2787f65cc074c6028b",
"",
"reply"
],
[
"p",
"8d3cf7eba921036409f1fec074cf8cfd8925bc7cb18e35d358b1ccc89752ee32"
]
],
"content": "📅 Original date posted:2021-12-16\n📝 Original message:@Jeremy\n\u003e for top-level pool participants there is never any central custody.\n\nI definitely see that. That was actually what I meant when I said the goals\naren't the same as benefits. While your idea definitely satisfies all your\ngoals in a modular way, the fact that it relies on pools means that unless\nthe pools can also satisfy the goals, the total system also doesn't satisfy\nthe goals (even tho the piece of that system you designed does).\n\n\u003e Thus it doesn't \"hurt\" anyone except for the miners who are taking the\nnot fully locked in funds risk\n\nTrue, it only potentially hurts whoever the channel partner is accepting\nthe unspendable coins. And no one can really stop anyone from taking that\nrisk if they really want to. But in that case, its not exactly a fully\nfunctional channel, since recourse mechanisms couldn't be performed.\nWouldn't that open such a channel up to a pretty bad theft possibility?\n\n@Bob\n\u003e Increased payout regularity does not lower the viable size of mining\npools, because smaller mining pools using this mechanism still have higher\nvariance.\n\nYes, smaller mining pools will always have higher variance. However, lower\nvariance has diminishing benefits. Below a certain amount of variance, less\nvariance isn't very valuable. So increased payout regularity does indeed\nlower the viable size of mining pools because a given low-enough level of\nvariance can be achieved with less pool hashpower.\n\n\u003e The on-chain footprint is *higher* due to the increased payout regularity.\n\nThat's a reasonable point. However, I think there is a difference here\nbetween the regularity of rewards vs payouts. Rewards for each miner can be\nmore regular without necessarily increasing the number of on-chain payouts.\nIn fact, theoretically, an individual miner could let their rewards\naccumulate in a pool over many rewards and only redeem when they need the\ncoins for something. The incentive is there for each miner to be judicious\non how much onchain space they take up.\n\n@vjudeu\n\n\u003e how many block headers should be stored per one \"superblock\"?\n\nI was thinking that this would be a separate blockchain with separate\nheaders that progress linearly like a normal blockchain. A block creator\nwould collect together as many blocks that haven't been collected yet into\nthe next superblock (and maybe receive a reward proportional to how many /\nhow much weight they include). This could be done using merge mining, or it\ncould be done using a signing scheme (eg where the block creator signs to\nsay \"I created this superblock\" and have mechanisms to punish those who\nsign multiple superblocks at the same height. For merge mining, I could\neven imagine the data necessary to validate that it has been merge mined\ncould be put into a taproot script branch (creating an invalid script, but\na valid hash of the superblock).\n\n\u003e we can collect all headers with the same previous block hash, and\ndistribute block reward between all coinbase transactions in those headers\n\nExactly.\n\n\u003e we would just have block headers instead of transactions\n\nYeah, I think that would be the way to go. Really, you could even just use\nhashes of the block headers. But the size doesn't matter much because it\nwould be both a small blockchain and an ephemeral one (which can be fully\ndiscarded after all parties have been paid out, or at least their payout\nhas been committed to on the bitcoin blockchain).\n\nOn Thu, Dec 16, 2021 at 1:35 AM \u003cvjudeu at gazeta.pl\u003e wrote:\n\n\u003e \u003e The missing piece here would be an ordering of weak blocks to make the\n\u003e window possible. Or at least a way to determine what blocks should\n\u003e definitely be part of a particular block's pay out. I could see this being\n\u003e done by a separate ephemeral blockchain (which starts fresh after each\n\u003e Bitcoin block) that keeps track of which weak blocks have been submitted,\n\u003e potentially using the pow already in each block to secure it. Granted that\n\u003e piece is a bit half baked, but it seems quite solvable. Wdyt?\n\u003e\n\u003e I thought about something like that, but there is one problem: how many\n\u003e block headers should be stored per one \"superblock\"? Currently, we have\n\u003e single block header, where the whole coinbase transaction is taken by some\n\u003e mining pool or solo miner. But instead, each miner could submit its own\n\u003e block header. Then, we can collect all headers with the same previous block\n\u003e hash, and distribute block reward between all coinbase transactions in\n\u003e those headers. One \"superblock\" then would be created in a similar way as\n\u003e existing blocks, we would just have block headers instead of transactions.\n\u003e If most transactions inside those blocks will be the same, then each block\n\u003e could be expressed just as a set of transaction hashes, only coinbase\n\u003e transactions or custom, non-broadcasted transactions included by miners\n\u003e will be revealed, everything else will be known.\n\u003e\n\u003e \u003e One thing that jumped out at me as not safe is throwing block rewards\n\u003e into a channel and being able to spend them immediately. There's a reason\n\u003e block rewards aren't spendable for a while, and channels don't solve that\n\u003e problem, do they? Why not simply reduce the on chain wait time for spending\n\u003e block rewards at that point? Seems like the consequences would be the same.\n\u003e\n\u003e All coinbase rewards are unspendable for 100 blocks, it is enforced by\n\u003e consensus. It does not matter if there are outputs owned directly by\n\u003e miners, or if there is one huge N-of-N taproot multisig for the whole pool,\n\u003e where every miner signed the closing transaction. The only option to take\n\u003e coins faster I can see is swapping the coins by some LN transaction. But\n\u003e then, the other party can check if some deposit to the LN channel is a part\n\u003e of the coinbase transaction or not, and then decide if it is acceptable to\n\u003e do the swap.\n\u003e\n\u003e On 2021-12-15 19:00:44 user Billy Tetrud via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e Looks like an interesting proposal, but it doesn't seem to quite match the\n\u003e goals you mentioned. As you do mention, this mining pool coordination\n\u003e doesn't get rid of the need for mining pools in the first place. So it\n\u003e doesn't satisfy item 1 on your goal list afaict.\n\u003e\n\u003e The primary benefits over what we have today that I can see are:\n\u003e 1. increased payout regularity, which lowers the viable size of mining\n\u003e pools, and\n\u003e 2. Lower on chain footprint through combining pay outs from multiple pools.\n\u003e\n\u003e Am I missing some?\n\u003e\n\u003e These are interesting benefits, but it would be nice if your post was\n\u003e clearer on that, since the goals list is not the same as the list of\n\u003e potential benefits of this kind of design.\n\u003e\n\u003e As far as enabling solo mining, what if this concept were used off chain?\n\u003e Have a public network of solo miners who publish \"weak blocks\" to that\n\u003e network, and the next 100 (or 1000 etc) nice miners pay you out as long as\n\u003e you're also being nice by following the protocol? All the nice\n\u003e optimizations you mentioned about eg combined taproot payouts would apply i\n\u003e think. The only goals this wouldn't satisfy are 3 and 5 since an extra\n\u003e network is needed, but to be fair, your proposal requires pools which all\n\u003e need their own extra network anyways.\n\u003e\n\u003e The missing piece here would be an ordering of weak blocks to make the\n\u003e window possible. Or at least a way to determine what blocks should\n\u003e definitely be part of a particular block's pay out. I could see this being\n\u003e done by a separate ephemeral blockchain (which starts fresh after each\n\u003e Bitcoin block) that keeps track of which weak blocks have been submitted,\n\u003e potentially using the pow already in each block to secure it. Granted that\n\u003e piece is a bit half baked, but it seems quite solvable. Wdyt?\n\u003e\n\u003e One thing that jumped out at me as not safe is throwing block rewards into\n\u003e a channel and being able to spend them immediately. There's a reason block\n\u003e rewards aren't spendable for a while, and channels don't solve that\n\u003e problem, do they? Why not simply reduce the on chain wait time for spending\n\u003e block rewards at that point? Seems like the consequences would be the same.\n\u003e\n\u003e On Tue, Dec 14, 2021, 16:12 Bob McElrath via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e \u003chttp://../NowaWiadomosc/Do/QlIkBFQ6QUFhIVRZX192dnQBeCtCchE6GhA5LFpLCUc7EVZQVl9dQRIXXR8NCBMbCwIGChJXQFxcXEgcFh8UVVVDEyBdVkE9JVRdEwFhYXVlblhVIkosEAszLR5BQVV7U0MID0BAQUgIGh0RHgAMGAMXBQJfW1sdXRQUQUoDQlAiBFY8\u003e\u003e\n\u003e wrote:\n\u003e\n\u003e\u003e You are hand waving. Attempting to redefine terms to justify your\n\u003e\u003e argument is\n\u003e\u003e intellectually dishonest. Bitcoin pools have *always* been about variance\n\u003e\u003e reduction. Your window function fundamentally CANNOT be used to hedge\n\u003e\u003e hashrate.\n\u003e\u003e Various suggestions below introduce dangerous new games that might be\n\u003e\u003e played by\n\u003e\u003e miners.\n\u003e\u003e\n\u003e\u003e The fact is that the half-baked design you posted is less than useless,\n\u003e\u003e and\n\u003e\u003e doesn't do anything that anyone wants.\n\u003e\u003e\n\u003e\u003e You are trying to justify CTV by making it be all things to all people.\n\u003e\u003e \"When\n\u003e\u003e all you have is a hammer, every problem looks like a nail\". Instead I\n\u003e\u003e humbly\n\u003e\u003e suggest that you pick ONE problem for which CTV is demonstrably the right\n\u003e\u003e and\n\u003e\u003e best solution, instead of snowing us with a ton of half-baked things that\n\u003e\u003e *could* be done, and often don't even require CTV, and some (like this\n\u003e\u003e one)\n\u003e\u003e fundamentally don't work. I do like some of your ideas, but if you had to\n\u003e\u003e pick\n\u003e\u003e just one \"use case\", which would it be?\n\u003e\u003e\n\u003e\u003e Jeremy [jlrubin at mit.edu\n\u003e\u003e \u003chttp://../NowaWiadomosc/Do/QlIkBFQ6QUFhIVRZX192dnQBeCtCchEyHxYvIVpLARduChoQSFZQR0NWQVZWJUNRXwMSCRMTBgcWASdWVkpbCxUTQwoWQUdjKVBMGFY3MWMWeU9QBAZtNw%3D%3D\u003e]\n\u003e\u003e wrote:\n\u003e\u003e \u003e Bitcoin didn't invent the concept of pooling:\n\u003e\u003e https://en.wikipedia.org/wiki/\n\u003e\u003e \u003e Pooling_(resource_management). This is a Bitcoin Mining Pool, although\n\u003e\u003e it may\n\u003e\u003e \u003e not be your favorite kind, which is fixated on specific properties of\n\u003e\u003e computing\n\u003e\u003e \u003e contributions before finding a block. Pooling is just a general\n\u003e\u003e technique for\n\u003e\u003e \u003e aggregating resources to accomplish something. If you have another name\n\u003e\u003e like\n\u003e\u003e \u003e pooling that is in common use for this type of activity I would be more\n\u003e\u003e than\n\u003e\u003e \u003e happy to adopt it.\n\u003e\u003e \u003e\n\u003e\u003e \u003e This sort of pool can hedge not only against fee rates but also against\n\u003e\u003e \u003e increases in hashrate since your historical rate 'carries' into the\n\u003e\u003e future as a\n\u003e\u003e \u003e function of the window. Further, windows and reward functions can be\n\u003e\u003e defined in\n\u003e\u003e \u003e a myriad of ways that could, e.g., pay less to blocks found in more\n\u003e\u003e rapid\n\u003e\u003e \u003e succession, contributing to the smoothing functionality.\n\u003e\u003e \u003e\n\u003e\u003e \u003e With respect to sub-block pooling, as described in the article, this\n\u003e\u003e sort of\n\u003e\u003e \u003e design also helps with micro-pools being able to split resources\n\u003e\u003e \u003e non-custodially in every block as a part of the higher order DCFMP. The\n\u003e\u003e point\n\u003e\u003e \u003e is not, as noted, to enable solo mining an S9, but to decrease the size\n\u003e\u003e of the\n\u003e\u003e \u003e minimum viable pool. It's also possible to add, without much validation\n\u003e\u003e or\n\u003e\u003e \u003e data, some 'uncle block' type mechanism in an incentive compatible way\n\u003e\u003e (e.g.,\n\u003e\u003e \u003e add 10 pow-heavy headers on the last block for cost 48 bytes header +\n\u003e\u003e 32 bytes\n\u003e\u003e \u003e payout key) such that there's an incentive to include the heaviest ones\n\u003e\u003e you've\n\u003e\u003e \u003e seen, not just your own, that are worth further study and consideration\n\u003e\u003e \u003e (particularly because it's non-consensus, only for opt-in participation\n\u003e\u003e in the\n\u003e\u003e \u003e pool).\n\u003e\u003e \u003e\n\u003e\u003e \u003e With respect to space usage, it seems you wholly reject the viability\n\u003e\u003e of a\n\u003e\u003e \u003e payment pool mechanism to cut-through chain space. Is this a critique\n\u003e\u003e that\n\u003e\u003e \u003e holds for all Payment Pools, or just in the context of mining? Is there\n\u003e\u003e a\n\u003e\u003e \u003e particular reason why you think it infeasible that \"strongly online\"\n\u003e\u003e \u003e counterparties would be able to coordinate more efficiently? Is it\n\u003e\u003e preferable\n\u003e\u003e \u003e for miners, the nexus of decentralization for Bitcoin, to prefer to use\n\u003e\u003e \u003e custodial services for pooling (which may require KYC/AM) over bearing\n\u003e\u003e a cost\n\u003e\u003e \u003e of some extra potential chainload?\n\u003e\u003e \u003e\n\u003e\u003e \u003e Lastly, with respect to complexity, the proposal is actually incredibly\n\u003e\u003e simple\n\u003e\u003e \u003e when you take it in a broader context. Non Interactive Channels and\n\u003e\u003e Payment\n\u003e\u003e \u003e Pools are useful by themselves, so are the operations to merge them and\n\u003e\u003e swap\n\u003e\u003e \u003e balance across them. Therefore most of the complexity in this proposal\n\u003e\u003e is\n\u003e\u003e \u003e relying on tools we'll likely see in everyday use in any case, DCFMP or\n\u003e\u003e no.\n\u003e\u003e \u003e\n\u003e\u003e \u003e Jeremy\n\u003e\u003e \u003e !DSPAM:61b8f2f5321461582627336!\n\u003e\u003e --\n\u003e\u003e Cheers, Bob McElrath\n\u003e\u003e\n\u003e\u003e \"For every complex problem, there is a solution that is simple, neat, and\n\u003e\u003e wrong.\"\n\u003e\u003e -- H. L. Mencken\n\u003e\u003e\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e \u003chttp://../NowaWiadomosc/Do/QlIkBFQ6QUFhIVRZX192dnQBeCtCchE6GhA5LFpLCUc7EVZQVl9dQRIXXR8NCBMbCwIGChJXQFxcXEgcFh8UVVVDEyBdVkE9JVRdEwFhYXVlblhVIkosEAszLR5BQVV7U0MID0BAQUgIGh0RHgAMGAMXBQJfW1sdXRQUQUoDQlAiBFY8\u003e\n\u003e\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/20211216/d18efb77/attachment-0001.html\u003e",
"sig": "73a76028998430f1cecaed2aa2a7cf736e166e9562d030615701a05b7217727f2e8b33320437b06563819e03c26c9d65bb257607804fa3a18098c7b39654e5da"
}