📅 Original date posted:2021-12-16
📝 Original message:> 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> 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] 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
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/672b3d09/attachment-0001.html>;
vjudeu at gazeta.pl [ARCHIVE] /
npub135…nssga
2023-06-07 23:01:22
in reply to nevent1q…qjvz
Author Public Key
npub1357006afyypkgz03lmq8fnuvlkyjt0rukx8rt56ck8xv396jaceqmnssgaPublished at
2023-06-07 23:01:22Event JSON
{
"id": "9cf73ee829de804d1ec6702a2392928fb4ab6dc8a3918a2787f65cc074c6028b",
"pubkey": "8d3cf7eba921036409f1fec074cf8cfd8925bc7cb18e35d358b1ccc89752ee32",
"created_at": 1686178882,
"kind": 1,
"tags": [
[
"e",
"9a9e1cb20e5c4bb51b22b23239ac4878d89ce4dba6ef6fe0cc58cd4270d58751",
"",
"root"
],
[
"e",
"46df2380640f439abaf0ad3a57f283cbc2e3614ba48e9aa221b4e9ef60b0f27a",
"",
"reply"
],
[
"p",
"a4fc2fc2bfc061e75a1b6e17dfc4b3c93b85fab2fc91001f44fd8499d672b169"
]
],
"content": "📅 Original date posted:2021-12-16\n📝 Original message:\u003e 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?\n \nI 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.\n\u003e 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.\nAll 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.\nOn 2021-12-15 19:00:44 user Billy Tetrud via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\nLooks 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. \nThe primary benefits over what we have today that I can see are:\n1. increased payout regularity, which lowers the viable size of mining pools, and\n2. Lower on chain footprint through combining pay outs from multiple pools.\n \nAm I missing some?\n \nThese 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.\n \nAs 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. \n \nThe 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?\n \nOne 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.\nOn Tue, Dec 14, 2021, 16:12 Bob McElrath via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\nYou are hand waving. Attempting to redefine terms to justify your argument is\nintellectually dishonest. Bitcoin pools have *always* been about variance\nreduction. Your window function fundamentally CANNOT be used to hedge hashrate.\nVarious suggestions below introduce dangerous new games that might be played by\nminers.\nThe fact is that the half-baked design you posted is less than useless, and\ndoesn't do anything that anyone wants.\nYou are trying to justify CTV by making it be all things to all people. \"When\nall you have is a hammer, every problem looks like a nail\". Instead I humbly\nsuggest that you pick ONE problem for which CTV is demonstrably the right and\nbest solution, instead of snowing us with a ton of half-baked things that\n*could* be done, and often don't even require CTV, and some (like this one)\nfundamentally don't work. I do like some of your ideas, but if you had to pick\njust one \"use case\", which would it be?\nJeremy [jlrubin at mit.edu] wrote:\n\u003e Bitcoin didn't invent the concept of pooling: https://en.wikipedia.org/wiki/\n\u003e Pooling_(resource_management). This is a Bitcoin Mining Pool, although it may\n\u003e not be your favorite kind, which is fixated on specific properties of computing\n\u003e contributions before finding a block. Pooling is just a general technique for\n\u003e aggregating resources to accomplish something. If you have another name like\n\u003e pooling that is in common use for this type of activity I would be more than\n\u003e happy to adopt it.\n\u003e\n\u003e This sort of pool can hedge not only against fee rates but also against\n\u003e increases in hashrate since your historical rate 'carries' into the future as a\n\u003e function of the window. Further, windows and reward functions can be defined in\n\u003e a myriad of ways that could, e.g., pay less to blocks found in more rapid\n\u003e succession, contributing to the smoothing functionality.\n\u003e\n\u003e With respect to sub-block pooling, as described in the article, this sort of\n\u003e design also helps with micro-pools being able to split resources\n\u003e non-custodially in every block as a part of the higher order DCFMP. The point\n\u003e is not, as noted, to enable solo mining an S9, but to decrease the size of the\n\u003e minimum viable pool. It's also possible to add, without much validation or\n\u003e data, some 'uncle block' type mechanism in an incentive compatible way (e.g.,\n\u003e add 10 pow-heavy headers on the last block for cost 48 bytes header + 32 bytes\n\u003e payout key) such that there's an incentive to include the heaviest ones you've\n\u003e seen, not just your own, that are worth further study and consideration\n\u003e (particularly because it's non-consensus, only for opt-in participation in the\n\u003e pool).\n\u003e\n\u003e With respect to space usage, it seems you wholly reject the viability of a\n\u003e payment pool mechanism to cut-through chain space. Is this a critique that\n\u003e holds for all Payment Pools, or just in the context of mining? Is there a\n\u003e particular reason why you think it infeasible that \"strongly online\"\n\u003e counterparties would be able to coordinate more efficiently? Is it preferable\n\u003e for miners, the nexus of decentralization for Bitcoin, to prefer to use\n\u003e custodial services for pooling (which may require KYC/AM) over bearing a cost\n\u003e of some extra potential chainload?\n\u003e\n\u003e Lastly, with respect to complexity, the proposal is actually incredibly simple\n\u003e when you take it in a broader context. Non Interactive Channels and Payment\n\u003e Pools are useful by themselves, so are the operations to merge them and swap\n\u003e balance across them. Therefore most of the complexity in this proposal is\n\u003e relying on tools we'll likely see in everyday use in any case, DCFMP or no.\n\u003e\n\u003e Jeremy\n\u003e !DSPAM:61b8f2f5321461582627336!\n--\nCheers, Bob McElrath\n\"For every complex problem, there is a solution that is simple, neat, and wrong.\"\n -- H. L. Mencken\n_______________________________________________\nbitcoin-dev mailing list\nbitcoin-dev at lists.linuxfoundation.org\nhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211216/672b3d09/attachment-0001.html\u003e",
"sig": "46a8c0a399ef69522733d6242a15721ecafcfaf041fa112954f9c934e4c0ff1d2c45bdae5ad3e9ae57543c87ba05e427e69d6a7f4e9a9fac3cc65d0ab3d9094a"
}