Re: [Bitcoin-development] Request for comments on hybrid PoW/PoS enhancement for Bitcoin
Hi Mike, Thanks for the feedback and letting me know that my earlier emails fell victim to spam. My scheme might be better because it would add further incentives for running full nodes. A full node can be run on even a cheap laptop. In my experience, once a person new to bitcoin accepts it as at worthy of attention, the next area of interest is how to mine. They'll learn about mining pools, search, and if they are technical enough, they'll join the pool and likely be disappointed with their results. They'll then consider a graphics card, or ASICs, or just stop mining altogether. And I wouldn't be surprised if, when making that selection of a mining pool, a person might, based on limited information, decide that the best mining pool to join is the largest. I've made a number of assumptions in that progression to further my point, but I don't think that journey is too far off mark. I do so to illustrate that for a person to enjoy some financial reward for running a full node, in practice, it isn't as simple as running a full node . My proposal makes it easier for a full node to enjoy rewards, and to do so on modest hardware. In that sense, it is better than what we have now. Many people new to bitcoin express an interest in mining. I suspect that the primary motive that they want a way to earn bitcoin using the computer ** that they have **. If you too believe this, then I hope you'd agree that my proposal offers a solution that meets the desires of that person new to bitcoin. It makes bitcoin more accommodating, which makes it better, but this time on a social rather than technological scale. This would help ** keep ** people interested in bitcoin and result in ecosystem growth. With a larger ecosystem running full nodes, the blockchain becomes more secure. That's better. Then there are the merits of enodorsement itself which is at the heart of my new scheme which one might argue could raise the bar from 51% to 101% to pull off such an attack. I don't know that my scheme helps on the sybil front, but since it requires and builds on top of the current system, I don't know that is makes it any worse. I tried to be more crisp, but that's one of the areas I need to improve. Thanks -Chris On Wed, Feb 25, 2015 at 7:30 AM, Mike Hearn m...@plan99.net wrote: Hi Chris, Just FYI you may not have received much feedback on this because Gmail put it into the spam folder for some reason. So I'm guessing a lot of people didn't see it. My main feedback is - I do not really see how this is different from actual mining. Mining also incentives the running of full nodes, miners are rewarded via coinbases, etc. I'm missing a crisp description of why your scheme is better than this, in particular, taking into account the difficulty of distinguishing full node sybils of each other. -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Request for comments on hybrid PoW/PoS enhancement for Bitcoin
This is an interesting idea from the standpoint of trying to incentivize people to run nodes, though from a high level it seems to just be adding complexity to the current process by which nodes 'endorse' blocks. When a node receives and validates a block it then informs its peers of the new inventory, thus offering to send the block that 'endorses' as valid. Because there is an incentive to include endorsers, there is an incentive to broadcast mined blocks as soon as possible. - I'd say that this is already the case due to the incentive for a miner's block to get propagated around the network first. My first question would be whether or not your proposal would include a change to how nodes propagate new blocks. At the moment, a node that hears about a second valid block at the tip of the chain will ignore it and not propagate it to its peers. Wouldn't your proposal necessitate a change to this logic so that blocks with 'better' endorsements get propagated even if they are received after non-endorsed or lesser-endorsed blocks? I'd also be interested to know more how endorsements would be limited (fairly) to only a subset of nodes. I'm a bit fuzzy on the endorsement timing. You're saying that a miner will add endorsement payouts in their block based upon nodes that endorsed the previous block? Which means they're paying nodes to endorse a block that they probably didn't even mine? Or would a miner only include payouts to endorsers for the last block that they mined that was accepted by the network? - Jameson On Mon, Feb 23, 2015 at 2:27 PM, Chris Page pag...@gmail.com wrote: I'm soliciting feedback on an idea to will improve security, increase the number of full nodes, and provide more avenues for bitcoin distribution. The idea is still in its infancy, but I need constructive feedback before I take this further, or decide to abandon the idea. In particular, my ego is in check and I'm ready to be made a fool, but in turn, I'll be that much better educated, so fair trade! Here is the high-level overview: 1) A new block B0 is mined and broadcast as usual 2) Full nodes verify block B0. A subset of these nodes broadcast a new endorsement message endorsing the block as valid, and preferred. 3) Miners, now assembling and beginning mining a new block (B1), add endorsements of B0 to B1's coinbase transaction, sharing the block reward with endorsers of B0. As proposed, the idea of Block Endorsement requires a new message, but fits into current structures. Here some details about each of the steps above, and what it buys us: 1) The mining of block B0: No changes to current process or format. Blocks are mined and broadcast as they are today. 2) Only a subset of nodes are eligible to endorse a block, and hence, only a subset are eligible for an endorsement reward. We restrict to avoid a flood of endorsement messages by every node following the announcement of each new block. An endorsement message needs to identify exactly one block at a specific height that it is endorsing. It needs to include a payout address that meets certain validation criteria relative to the block it is endorsing. A valid payout address will include some proof of stake (PoS), whether that be that it has a 1+ bitcoin balance, some age weighted balance, or something else is TBD. The reason for PoS is that it should not be the case that a subversive miner could easily fabricate a valid endorsement payout address. The other requirement is that the tail bits of a valid endorsement payout address, when masked (size of mask TBD) need to match the trailing bits of the hash of the block it is validating. This directly ties endorsements to a specific block, and makes it computationally inexpensive to verify/relay, or drop invalid endorsement messages. The combination of PoS and mask will restrict the number of valid addresses. There are no restrictions on which endorsements a miner can include, as long as they are valid. As part of new block validation, full nodes would need to do all that they do now, but they would also need to validate endorsements included in the coinbase transaction. 3) Miners consider whether to include endorsement payouts as part of their coinbase transaction. They need not do so, but by including endorsements, they significantly increase the likelihood that their block will be selected. CHANGE TO BEST CHAIN SELECTION Block Endorsement requires a change to the best chain selection algorithm to encourage miners to include endorsement payouts. Because there is an incentive to include endorsers, there is an incentive to broadcast mined blocks as soon as possible. For the purpose of best chain selection, a block should get a significant bonus to its work (10%) for each valid endorsement payout included in a block's valid coinbase transaction. How many endorsements should be permitted is a design parameter which is in play, but let's assume that up to
Re: [Bitcoin-development] Request for comments on hybrid PoW/PoS enhancement for Bitcoin
Thanks for the feedback and questions. Answers inline. On Tue, Feb 24, 2015 at 9:54 AM, Jameson Lopp jameson.l...@gmail.com wrote: This is an interesting idea from the standpoint of trying to incentivize people to run nodes, though from a high level it seems to just be adding complexity to the current process by which nodes 'endorse' blocks. When a node receives and validates a block it then informs its peers of the new inventory, thus offering to send the block that 'endorses' as valid. Because there is an incentive to include endorsers, there is an incentive to broadcast mined blocks as soon as possible. - I'd say that this is already the case due to the incentive for a miner's block to get propagated around the network first. I agree with this, for well meaning miners. In the case of a 51% attack, there is an incentive to mine a block and not share it right away, so that another block could be mined on top of it. Because that first block wasn't shared, it wouldn't have endorsers. The total work represented in this attack chain, even with 2 blocks, would ideally represent less work that one fully endorsed block. This is because, as currently proposed, endorsers provide a work multiplier, which when a block has a full complement of endorsers, its proof of work is doubled for the purpose of best chain selection. That's if we allow up to 10 endorsers each providing a 10% work bonus. My concern is that giving endorsers too much power potentially opens up another attack vector where endorsers could collude to endorse an invalid block. But that's why it is so important that the selection criteria for endorsers needs to be both random and narrow. I discuss that more below. My first question would be whether or not your proposal would include a change to how nodes propagate new blocks. At the moment, a node that hears about a second valid block at the tip of the chain will ignore it and not propagate it to its peers. Wouldn't your proposal necessitate a change to this logic so that blocks with 'better' endorsements get propagated even if they are received after non-endorsed or lesser-endorsed blocks? I think that the proposal does impact consensus, which creates a high barrier to acceptance, and I'm not yet convinced that the benefits are worth the risk. My hope is that in sharing the idea, we can identify ways to reduce the risk. Whenever there is a fork, Bitcoin chooses the chain with the most work. I could easily be mistaken, so correct me if I cam wrong, but based on a current level of difficulty, any arriving valid block is going to present an equivalent proof of work. So currently, it makes sense to simply ignore a second valid block. With the proposal, if a second valid block came in with more endorsers, it would displace the current tip. In practice, with proper incentive, I would expect all found blocks to have the same number of endorsers. Therefore all incoming blocks would be interchangeable, and it would be the case that in practice, a second valid block would be ignored just as today. I'd also be interested to know more how endorsements would be limited (fairly) to only a subset of nodes. A node endorses by providing an address for payout. The limiting criteria is a function of that address. The first requirement is that the address must have a relationship to the block that it is endorsing. As an example, 082ab88cefb003f1dc1fa25881dbd56ed58c0548fbec5382 is the hash of a recent block. The requirement is that the address matches some number (TBD) of trailing bits. If the threshold were 32 bits, then the address (more likely, the hash of the public address) would need to end in fbec5382.. An valid address must have some proof of stake. Maybe that isn't fair, because it limits participation by balance, and it is yet another case of the rich get richer. But without proof of stake, everyone would generate enough addresses so that they could always find an address that meets the first requirement. Assuming the idea has merit, in order to get it right, we'd need much discussion to understand what combination of PoS and size of mask makes sense. I'm a bit fuzzy on the endorsement timing. You're saying that a miner will add endorsement payouts in their block based upon nodes that endorsed the previous block? Which means they're paying nodes to endorse a block that they probably didn't even mine? Or would a miner only include payouts to endorsers for the last block that they mined that was accepted by the network? With my proposal, miners would not be required to payout to endorsers at all. I think that this would help us avoid a hard fork. But when they choose to payout to endorsers, yes, they would be paying out to those that endorsed the tip of the chain that they are building on. Why would a miner ever do that? Because they would benefit from the multiplier provided by the endorsers. Any block that includes
Re: [Bitcoin-development] Request for comments on hybrid, PoW/PoS enhancement for Bitcoin
Having stakeholders endorse blocks has, according to you, the benefits of increasing the number of full nodes and making a 51% attack more expensive. It seems to me it would have the opposite effects and other negative side effects. Any stakeholder that has won could just be running an SPV client and be informed by a full node that they have won, then cooperate to collect the reward. You are mistaking proof of stake as a proof you are running a full node. At the same time, the network becomes cheaper to attack in proportion to the amount of the block reward that is paid to endorsers. Another side effect is that miners would have a bigger economy of scale. The more stake a miner has, the more they can endorse their own blocks and not others blocks. I recommend reading this: https://download.wpsoftware.net/bitcoin/pos.pdf -Andrew Lapp -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Request for comments on hybrid, PoW/PoS enhancement for Bitcoin
I definitely need to have an deeper understanding of that paper before proceeding. Thanks for the reference! On Wed, Feb 25, 2015 at 4:58 PM, Andrew Lapp la...@purdue.edu wrote: Having stakeholders endorse blocks has, according to you, the benefits of increasing the number of full nodes and making a 51% attack more expensive. It seems to me it would have the opposite effects and other negative side effects. Any stakeholder that has won could just be running an SPV client and be informed by a full node that they have won, then cooperate to collect the reward. You are mistaking proof of stake as a proof you are running a full node. At the same time, the network becomes cheaper to attack in proportion to the amount of the block reward that is paid to endorsers. Another side effect is that miners would have a bigger economy of scale. The more stake a miner has, the more they can endorse their own blocks and not others blocks. I recommend reading this: https://download.wpsoftware.net/bitcoin/pos.pdf -Andrew Lapp -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
