Re: [Bitcoin-development] Proposal: Vote on the blocksize limit with proof-of-stake voting
On 10 June 2013 06:09, John Dillon wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > It has been suggested that we leave the decision of what the blocksize to > be > entirely up to miners. However this leaves a parameter that affects every > Bitcoin participant in the control of a small minority. Of course we can > not > force miners to increase the blocksize if they choose to decrease it, > because > the contents of the blocks they make are their decision and their decision > only. However proposals to leave the maximum size unlimited to allow > miners to > force us to accept arbitrarily large blocks even if the will of the > majority of > Bitcoin participants is that they wish to remain able to validate the > blockchain. > > What we need is a way to balance this asymetrical power relationship. > > Proof-of-stake voting gives us a way of achieving that balance. > Essentially for > a miner to prove that the majority will of the poeple is to accept a larger > blocksize they must prove that the majority has in fact voted for that > increase. The upper limit on the blocksize is then determined by the > median of > all votes, where each txout in the UTXO set is one vote, weighted by txout > value. A txout without a corresponding vote is considered to be a vote for > the > status quo. To allow the voting process to continue even if coins are > "lost" > votes, including default votes, are weighted inversely according to their > age > in years after 1 year. IE a vote with weight 1BTC that is 1.5 years old > will be > recorded the same as a <1 year old vote weighted as 0.67BTC, and a 1 day > old > and 6 months old UTXO are treated equivalently. The 1 year minimum is > simply to > make voting required no more than once per year. (of course, a real > implementation should do all of these figures by block height, IE after > 52,560 > blocks instead of after 1 year) > > A vote will consist of a txout with a scriptPubKey of the following form: > > OP_RETURN magic vote_id txid vout vote scriptSig > > Where scriptSig is a valid signature for a transaction with nLockTime > 500,000,000-1 spending txid:vout to scriptPubKey: > > OP_HASH160 H(OP_RETURN magic vote_id txid vout vote) OP_EQUAL > > vote_id is the ID of the specific vote being made, and magic is included to > allow UTXO proof implementations a as yet unspecified way of identifying > votes > and including the weighted median as part of the UTXO tree sums. (it also > allows SPV clients to verify the vote if the UTXO set is a Patricia tree of > scriptPubKeys) vote is just the numerical vote itself. The vote must > compute > the median, rather than the mean, so as to not allow someone to skew the > vote > by simply setting their value extremely high. Someone who still remembers > their > statistics classes should chime in on the right way to compute a median in > a > merkle-sum-tree. > > The slightly unusual construction of votes makes implementation by wallet > software as simple as possible within existing code-paths. Votes could > still be > constructed even in wallets lacking specific voting capability provided the > wallet software does have the ability to set nLockTime. > > Of course in the future the voting mechanism can be used for additional > votes > with an additional vote_id. For instance the Bitcoin community could vote > to > increase the inflation subsidy, another example of a situation where the > wishes > of miners may conflict with the wishes of the broader community. > > Users may of course actually create these specially encoded txouts > themselves > and get them into the blockchain. However doing so is not needed as a > given > vote is only required to actually be in the chain by a miner wishing to > increase the blocksize. Thus we should extend the P2P protocol with a > mechanism > by which votes can be broadcast independently of transactions. To prevent > DoS > attacks only votes with known vote_id's will be accepted, and only for > txid:vout's already in the blockchain, and a record of txouts for whom > votes > have already broadcast will be kept. (this record need not be > authoritative as > its purpose is only to prevent DoS attacks) Miners wishing to increase the > blocksize can record these votes and include them in the blocks they mine > as > required. To reduce the cost of including votes in blocks 5% of every block > should be assigned to voting only. (this can be implemented by a soft-fork) > > For any given block actual limit in effect is then the rolling median of > the > blocks in the last year. At the beginning of every year the value > considered to > be the status quo resets to the mean of the limit at the beginning and end > of > the interval. (again, by "year" we really mean 52,560 blocks) The rolling > median and periodic reset process ensures that the limit changes gradually > and > is not influenced by temporary events such as hacks to large exchanges or > malicious wallet software. The rolling median
Re: [Bitcoin-development] Proposal: Vote on the blocksize limit with proof-of-stake voting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, Jun 10, 2013 at 8:14 AM, Melvin Carvalho wrote: > -1 > > Firstly I appreciate the ingenious thought that went into this post. > > However, Bitcoin's fundamental philosophy was one CPU one vote. Indeed it was. Which is why as GPU's came onto the scene Satoshi was strongly against them. I have to wonder what he thinks of ASICs where just a handful of companies control the supply of Bitcoin hashing power. Satoshi also never forsaw pools, which are why just 2 or 3 people control the majority of Bitcoin hashing power. > The asymmetry lies in psychological terms, in that new defaults tend to be > adopted 80% of the time, so core devs have disproportionate amount of power > as things stand. That's why I'm very clear that doing nothing is a vote for the status quo. Of course wallet authors can do what they want to try to get users to vote according to their wishes, or for that matter simply steal your vote, but we already must put a lot of faith into wallets to not steal our funds. > Unless there's a very good reason not to, e.g. miners are clearly abusing > the system, we should stick with 1 CPU one vote. People are proposing we put control of the blocksize entirely into the hands of miners, yet we all have an interest in auditing the blocks miners produce. There must be balance. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBCAAGBQJRtY2jAAoJEEWCsU4mNhiPQEsH/0VNA7aJYdUbJjTnIiKoaCv3 JtWS1MKHjAJE6ZPDt+T/QPkEdZI4kNz3DGcZL6EDJtvZxZHfvEIaZDF1gpaH6OkC oIZ0PkFPOxi0cncuAvT/a770evu7LzuT6fisY3EgGnlHujLQZ47LEa73Xo7pJVc7 RJHamGwkj+3HZRIuZIAn87qws/zRyTx5SXvb56xCKb0oxE4ZO0dn+8/nNSPWw13i p3LpLlEQBBu+Du2nPSQupRjkz4MPP8v9EYefV5cjtNBK7ufAvA64OnwKB5dST+h+ N/vBcj3EIj/WEOf4myGcVxKp+skJ2SJDwxLigevgkKYPDNTVfXIverdXB0ANrQA= =c8iU -END PGP SIGNATURE- -- How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: Vote on the blocksize limit with proof-of-stake voting
On Mon, Jun 10, 2013 at 10:14 AM, Melvin Carvalho wrote: > However, Bitcoin's fundamental philosophy was one CPU one vote. This is perhaps the largest misconception that keeps being repeated. Bitcoin is not a democracy; it is a zero-trust system. The rules are set in stone, and every full node verifies all rules and must independently come to the same result as everyone else. Obviously, if everyone changes their software, anything can change, but from within the system there is no way to change which blocks are considered valid, and there is certainly no voting mechanism about that. What is voted about, is the one single thing that cannot be decided by each node individually: namely the order of otherwise valid and non-conflicting transactions, and that's just because it's a necessity. Because deciding the order includes delaying transaction potentially indefinitely, a majority of miners can indeed choose the enforce an additional rule about which transactions are considered valid, but the rules implemented in full nodes do not change without changing the software. For example, miners cannot decide to raise the block subsidy, even if every single miner out there would want that. They'd just end up being ignored by everyone else. > Voting is easily gamed. While this may work in one particular case, it is > perhaps a bad precedent to set. Establishing methods of voting can lead to > single points of failure. The problem is that at some point, you have to look at the system from a higher level than just the technical part. And because ultimately the possibility exists where everyone changes their software, and there is an exceedingly high incentive for consensus (a deliberate hard-fork where two groups of users decide to use different and incompatible rules, aware of eachother, is suicide for the system, in my opinion). This results in the fact that proposed changes can indeed become new adopted hard rules in the system, and I don't think there's anything that can be done about it. Bitcoin is a consensus system - at the technical level - but also a consensus of the people using it, and ultimately they decide the rules. > Unless there's a very good reason not to, e.g. miners are clearly abusing > the system, we should stick with 1 CPU one vote. So you're saying that instead of a zero-trust system, we should move to a system where miners can decide _everything_ - as opposed to just being in charge of ordering transactions? I don't think you understand the system at all, if that is what you're proposing. -- Pieter -- How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: Vote on the blocksize limit with proof-of-stake voting
On 10 June 2013 10:26, John Dillon wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On Mon, Jun 10, 2013 at 8:14 AM, Melvin Carvalho > wrote: > > -1 > > > > Firstly I appreciate the ingenious thought that went into this post. > > > > However, Bitcoin's fundamental philosophy was one CPU one vote. > > Indeed it was. Which is why as GPU's came onto the scene Satoshi was > strongly > against them. I have to wonder what he thinks of ASICs where just a > handful of > companies control the supply of Bitcoin hashing power. > Thanks for your reply. Do you have a pointer to Satoshi being strongly against GPU? I'd be interested to see that. FWIW, I've read all his forum posts a few times, I just dont recall this one, tho I'm sure it's there... > > Satoshi also never forsaw pools, which are why just 2 or 3 people control > the > majority of Bitcoin hashing power. > > > The asymmetry lies in psychological terms, in that new defaults tend to > be > > adopted 80% of the time, so core devs have disproportionate amount of > power > > as things stand. > > That's why I'm very clear that doing nothing is a vote for the status quo. > Of > course wallet authors can do what they want to try to get users to vote > according to their wishes, or for that matter simply steal your vote, but > we > already must put a lot of faith into wallets to not steal our funds. > > > Unless there's a very good reason not to, e.g. miners are clearly abusing > > the system, we should stick with 1 CPU one vote. > > People are proposing we put control of the blocksize entirely into the > hands of > miners, yet we all have an interest in auditing the blocks miners produce. > There must be balance. > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.11 (GNU/Linux) > > iQEcBAEBCAAGBQJRtY2jAAoJEEWCsU4mNhiPQEsH/0VNA7aJYdUbJjTnIiKoaCv3 > JtWS1MKHjAJE6ZPDt+T/QPkEdZI4kNz3DGcZL6EDJtvZxZHfvEIaZDF1gpaH6OkC > oIZ0PkFPOxi0cncuAvT/a770evu7LzuT6fisY3EgGnlHujLQZ47LEa73Xo7pJVc7 > RJHamGwkj+3HZRIuZIAn87qws/zRyTx5SXvb56xCKb0oxE4ZO0dn+8/nNSPWw13i > p3LpLlEQBBu+Du2nPSQupRjkz4MPP8v9EYefV5cjtNBK7ufAvA64OnwKB5dST+h+ > N/vBcj3EIj/WEOf4myGcVxKp+skJ2SJDwxLigevgkKYPDNTVfXIverdXB0ANrQA= > =c8iU > -END PGP SIGNATURE- > -- How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: Vote on the blocksize limit with proof-of-stake voting
On 10 June 2013 10:35, Pieter Wuille wrote: > On Mon, Jun 10, 2013 at 10:14 AM, Melvin Carvalho > wrote: > > However, Bitcoin's fundamental philosophy was one CPU one vote. > > This is perhaps the largest misconception that keeps being repeated. > Bitcoin is not a democracy; it is a zero-trust system. The rules are > set in stone, and every full node verifies all rules and must > independently come to the same result as everyone else. Obviously, if > everyone changes their software, anything can change, but from within > the system there is no way to change which blocks are considered > valid, and there is certainly no voting mechanism about that. > > What is voted about, is the one single thing that cannot be decided by > each node individually: namely the order of otherwise valid and > non-conflicting transactions, and that's just because it's a > necessity. Because deciding the order includes delaying transaction > potentially indefinitely, a majority of miners can indeed choose the > enforce an additional rule about which transactions are considered > valid, but the rules implemented in full nodes do not change without > changing the software. For example, miners cannot decide to raise the > block subsidy, even if every single miner out there would want that. > They'd just end up being ignored by everyone else. > > > Voting is easily gamed. While this may work in one particular case, it > is > > perhaps a bad precedent to set. Establishing methods of voting can lead > to > > single points of failure. > > The problem is that at some point, you have to look at the system from > a higher level than just the technical part. And because ultimately > the possibility exists where everyone changes their software, and > there is an exceedingly high incentive for consensus (a deliberate > hard-fork where two groups of users decide to use different and > incompatible rules, aware of eachother, is suicide for the system, in > my opinion). This results in the fact that proposed changes can indeed > become new adopted hard rules in the system, and I don't think there's > anything that can be done about it. Bitcoin is a consensus system - at > the technical level - but also a consensus of the people using it, and > ultimately they decide the rules. > OK I accept that the timestamping is one CPU one vote. However rule changes seem rather arbitrary. Towit if you use a voting/consensus system and want to destroy bitcion it seems quite easy. Iterate on picking a rule chance that will divide the consensus in such a way as to create ensuing chaos. I think voting is too easy gamed for it it to be meaningful other than a straw poll. If there's a bug, and everyone is unanimous that it's a bug, it can be fixed. If there's a controversial rule change, we should be extremely cautious and not do it unless there's a very good reason. Keeping to satoshi's model as much as possible without introducing human factors, unnecessarily. > > > > Unless there's a very good reason not to, e.g. miners are clearly abusing > > the system, we should stick with 1 CPU one vote. > > So you're saying that instead of a zero-trust system, we should move > to a system where miners can decide _everything_ - as opposed to just > being in charge of ordering transactions? I don't think you understand > the system at all, if that is what you're proposing. > > -- > Pieter > -- How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: Vote on the blocksize limit with proof-of-stake voting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 John, What you are recommending is a drastic change that the conservative bitcoin developers probably wouldn't get behind (but let's see). However proof-of-stake voting on protocol soft-forks has vast implications even beyond the block size limit. Within Freicoin, we have looked at is as a possibility for determining how to distribute the demurrage, a proposal we are calling 'Republicoin' due to the fact that with proxy voting we expect a system to emerge similar to the government budgeting in parliamentary republics. Distributed, non-coersive government by protocol, if you will. So anyway, even if you get shot down, please continue to pursue this proposal. It very likely has uses that you haven't thought of yet. Cheers, Mark On 6/9/13 9:09 PM, John Dillon wrote: > It has been suggested that we leave the decision of what the blocksize to be > entirely up to miners. However this leaves a parameter that affects every > Bitcoin participant in the control of a small minority. Of course we can not > force miners to increase the blocksize if they choose to decrease it, because > the contents of the blocks they make are their decision and their decision > only. However proposals to leave the maximum size unlimited to allow miners to > force us to accept arbitrarily large blocks even if the will of the majority of > Bitcoin participants is that they wish to remain able to validate the > blockchain. > > What we need is a way to balance this asymetrical power relationship. > > Proof-of-stake voting gives us a way of achieving that balance. Essentially for > a miner to prove that the majority will of the poeple is to accept a larger > blocksize they must prove that the majority has in fact voted for that > increase. The upper limit on the blocksize is then determined by the median of > all votes, where each txout in the UTXO set is one vote, weighted by txout > value. A txout without a corresponding vote is considered to be a vote for the > status quo. To allow the voting process to continue even if coins are "lost" > votes, including default votes, are weighted inversely according to their age > in years after 1 year. IE a vote with weight 1BTC that is 1.5 years old will be > recorded the same as a <1 year old vote weighted as 0.67BTC, and a 1 day old > and 6 months old UTXO are treated equivalently. The 1 year minimum is simply to > make voting required no more than once per year. (of course, a real > implementation should do all of these figures by block height, IE after 52,560 > blocks instead of after 1 year) > > A vote will consist of a txout with a scriptPubKey of the following form: > > OP_RETURN magic vote_id txid vout vote scriptSig > > Where scriptSig is a valid signature for a transaction with nLockTime > 500,000,000-1 spending txid:vout to scriptPubKey: > > OP_HASH160 H(OP_RETURN magic vote_id txid vout vote) OP_EQUAL > > vote_id is the ID of the specific vote being made, and magic is included to > allow UTXO proof implementations a as yet unspecified way of identifying votes > and including the weighted median as part of the UTXO tree sums. (it also > allows SPV clients to verify the vote if the UTXO set is a Patricia tree of > scriptPubKeys) vote is just the numerical vote itself. The vote must compute > the median, rather than the mean, so as to not allow someone to skew the vote > by simply setting their value extremely high. Someone who still remembers their > statistics classes should chime in on the right way to compute a median in a > merkle-sum-tree. > > The slightly unusual construction of votes makes implementation by wallet > software as simple as possible within existing code-paths. Votes could still be > constructed even in wallets lacking specific voting capability provided the > wallet software does have the ability to set nLockTime. > > Of course in the future the voting mechanism can be used for additional votes > with an additional vote_id. For instance the Bitcoin community could vote to > increase the inflation subsidy, another example of a situation where the wishes > of miners may conflict with the wishes of the broader community. > > Users may of course actually create these specially encoded txouts themselves > and get them into the blockchain. However doing so is not needed as a given > vote is only required to actually be in the chain by a miner wishing to > increase the blocksize. Thus we should extend the P2P protocol with a mechanism > by which votes can be broadcast independently of transactions. To prevent DoS > attacks only votes with known vote_id's will be accepted, and only for > txid:vout's already in the blockchain, and a record of txouts for whom votes > have already broadcast will be kept. (this record need not be authoritative as > its purpose is only to prevent DoS attacks) Miners wishing to increase the > blocksize can record these votes and include them in the blocks they mine as > required. To reduce
Re: [Bitcoin-development] Proposal: Vote on the blocksize limit with proof-of-stake voting
One major problem I see with this, no matter how well-thought-out it is, it's unlikely that those with money will participate. Those with the most stake, likely have their private keys behind super-secure accessibility barriers, and are not likely to go through the effort just to sign votes. Not only that, but it would require them to reveal their public key, which while isn't technically so terrible, large amounts of money intended to be kept in storage for 10+ years will prefer to avoid any exposure at all, in the oft-chance that QCs come around a lot earlier than we expected. Sure, the actual risk should be pretty much non-existent, but some of the most paranoid folks are probably the same ones who have a lot of funds and want 100.00% of the security that is possible. They will see this as wildly inconvenient. I think this a great thought experiment, and I'd like to see where this idea goes, in terms of designing ways for a decentralized community to find consensus for important decisions, but I don't think that any idea that requires users to dig up their private keys is going to be feasible (or possibly reconstruct them from pieces and/or get multiple signatures). Especially if the system requires some kind of persistent voting. -Alan On 06/10/2013 12:46 PM, Mark Friedenbach wrote: > > John, > > What you are recommending is a drastic change that the conservative > bitcoin developers probably wouldn't get behind (but let's see). > However proof-of-stake voting on protocol soft-forks has vast > implications even beyond the block size limit. Within Freicoin, we > have looked at is as a possibility for determining how to distribute > the demurrage, a proposal we are calling 'Republicoin' due to the fact > that with proxy voting we expect a system to emerge similar to the > government budgeting in parliamentary republics. Distributed, > non-coersive government by protocol, if you will. > > So anyway, even if you get shot down, please continue to pursue this > proposal. It very likely has uses that you haven't thought of yet. > > Cheers, > Mark > > On 6/9/13 9:09 PM, John Dillon wrote: > > It has been suggested that we leave the decision of what the > blocksize to be > > entirely up to miners. However this leaves a parameter that affects > every > > Bitcoin participant in the control of a small minority. Of course we > can not > > force miners to increase the blocksize if they choose to decrease > it, because > > the contents of the blocks they make are their decision and their > decision > > only. However proposals to leave the maximum size unlimited to allow > miners to > > force us to accept arbitrarily large blocks even if the will of the > majority of > > Bitcoin participants is that they wish to remain able to validate the > > blockchain. > > > What we need is a way to balance this asymetrical power relationship. > > > Proof-of-stake voting gives us a way of achieving that balance. > Essentially for > > a miner to prove that the majority will of the poeple is to accept a > larger > > blocksize they must prove that the majority has in fact voted for that > > increase. The upper limit on the blocksize is then determined by the > median of > > all votes, where each txout in the UTXO set is one vote, weighted by > txout > > value. A txout without a corresponding vote is considered to be a > vote for the > > status quo. To allow the voting process to continue even if coins > are "lost" > > votes, including default votes, are weighted inversely according to > their age > > in years after 1 year. IE a vote with weight 1BTC that is 1.5 years > old will be > > recorded the same as a <1 year old vote weighted as 0.67BTC, and a 1 > day old > > and 6 months old UTXO are treated equivalently. The 1 year minimum > is simply to > > make voting required no more than once per year. (of course, a real > > implementation should do all of these figures by block height, IE > after 52,560 > > blocks instead of after 1 year) > > > A vote will consist of a txout with a scriptPubKey of the following > form: > > > OP_RETURN magic vote_id txid vout vote scriptSig > > > Where scriptSig is a valid signature for a transaction with nLockTime > > 500,000,000-1 spending txid:vout to scriptPubKey: > > > OP_HASH160 H(OP_RETURN magic vote_id txid vout vote) OP_EQUAL > > > vote_id is the ID of the specific vote being made, and magic is > included to > > allow UTXO proof implementations a as yet unspecified way of > identifying votes > > and including the weighted median as part of the UTXO tree sums. (it > also > > allows SPV clients to verify the vote if the UTXO set is a Patricia > tree of > > scriptPubKeys) vote is just the numerical vote itself. The vote must > compute > > the median, rather than the mean, so as to not allow someone to skew > the vote > > by simply setting their value extremely high. Someone who still > remembers their > > statistics classes should chime in on the right way to compute a > median in
Re: [Bitcoin-development] Proposal: Vote on the blocksize limit with proof-of-stake voting
On Mon, Jun 10, 2013 at 01:25:05PM -0400, Alan Reiner wrote:
> to sign votes. Not only that, but it would require them to reveal their
> public key, which while isn't technically so terrible, large amounts of
> money intended to be kept in storage for 10+ years will prefer to avoid
> any exposure at all, in the oft-chance that QCs come around a lot
> earlier than we expected. Sure, the actual risk should be pretty much
> non-existent, but some of the most paranoid folks are probably the same
> ones who have a lot of funds and want 100.00% of the security that is
> possible. They will see this as wildly inconvenient.
Solving that problem is pretty easy actually: just add a voting only
public key to your outputs. Specifically you would have an opcode called
something like "OP_VOTE" and put a code-path in your script that only
executes for that specific key.
It'd work best if we implement merklized abstract syntax trees to allow
you to reveal only the part of a script that is actually executed rather
than the whole script, a feature useful for a lot of other things.
Incidentally remember that we can implement as many new opcodes as we
want with a soft-fork by redefining one of the OP_NOP's to be a
OP_VERSION opcode that returns false for a given version:
version OP_VERSION OP_IFNOT {new opcodes} OP_ENDIF
Nodes with the existing codebase will think the script always succeeds,
because the IFNOT branch isn't taken, leaving the non-false version on
the stack, while new nodes will take that branch.
--
'peter'[:-1]@petertodd.org
0109243df1322b7b5173c5796cf979318e933d887210c981c1f8
signature.asc
Description: Digital signature
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Decentralizing mining
So here's the parts that need to be done for step #1: # Protocol Work Basic idea is the miner makes two connections, their pool, and a local bitcoind. They always (usually?) work on the subset of transactions common to both the pool's getblocktemplate and their local one. When they find a share if it doesn't meet difficulty they just hand it to the pool. Currently that is done by handing the whole block over, correct? I know the BIP says otherwise, but we should optimize this to just hand over tx hashes where possible. If the share does meet difficulty, hand it to both the pool and the local bitcoind. Should hand it to the pool first though, because the pool likely has the fastest block propagation, then hand it to local bitcoind. An optimized version may want to have some record of measured bandwidth - this applies Bitcoin in general too, although also has other issues. ## Reducing bandwidth How about for normal shares we just pass the block header, and have the pool randomly pick a subset of transactions to audit? Any fraud cancels the users shares. This will work best in conjunction with a UTXO proof tree to prove fees, or by just picking whole shares randomly to audit. We'll need persistent share storage so if your connection disconnects you can provide the pool with the full share later though. Incedentally, note how the miner can do the reverse: pick random block headers and challenge the pool to prove that they correspond to a valid block. With some modifications Stratum can support this approach. ## Delibrate orphaning of slow to propagate blocks Block headers can be flooded-filled much faster than blocks themselves. They are also small enough to fit into a UDP packet. Nodes should pass headers around separately via UDP, optinally with some tiny number of transactions. When we see a valid block header whose contents we do not know about a miner should switch to mining empty or near empty blocks in solo mode that would orphan the still propagating block. Doing this is safe, we'll never build on an invalid block, economically rational while the inflation subsidy is still high, and helps reduce (although not eliminate!) the advantage a large miner with high-bandwidth connections has over those who don't. Of course, the other option is to build a block extending the one you don't know about, which is even more rational, but doing poses major risks to Bitcoin... This functionality can be implemented later - it's not strictly part of pooled-solo mode. # Pool work So does eliopool already accept arbitrary shares like this and do the correct accounting already? (IE adjust share amount based on fees?) What happens when the pool doesn't get the share directly, but does see the new block? + possible protocol extensions # Miner work Basically we need code to merge the two block templates together to find commonality. I guess you probably want to implement this in bfgminer first, so add the code to libblkmaker first, then maybe python-blkmaker. We also want an automatic fallback to local solo mining if the pool can't be contacted. + possible protocol extensions -- 'peter'[:-1]@petertodd.org 005576673e616271f762a5d8779d5fe7796c6e43ed43df5aa189 signature.asc Description: Digital signature -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Decentralizing mining
On Monday, June 10, 2013 9:09:13 PM Peter Todd wrote: > # Protocol Work This is basically done. > Basic idea is the miner makes two connections, their pool, and a local > bitcoind. > > They always (usually?) work on the subset of transactions common to both > the pool's getblocktemplate and their local one. When they find a share > if it doesn't meet difficulty they just hand it to the pool. Currently > that is done by handing the whole block over, correct? I know the BIP > says otherwise, but we should optimize this to just hand over tx hashes > where possible. The plan was to tell the pool it doesn't need to send transactions at all, and only work on the ones from bitcoind. Currently, share submissions are just the block header and coinbase transaction; in this case, however, the miner will need to send merkle links also, possibly just once via a block proposal in advance. > If the share does meet difficulty, hand it to both the pool and the > local bitcoind. Should hand it to the pool first though, because the > pool likely has the fastest block propagation, then hand it to local > bitcoind. An optimized version may want to have some record of measured > bandwidth - this applies Bitcoin in general too, although also has other > issues. Currently, BFGMiner is doing submission to the pool, waiting for a response, then submitting to a local bitcoind. This is because the pool might need to receive/record the share before it processes the block on bitcoind, or you could lose credit for it. The response from the pool is rather small (a single TCP packet), so this shouldn't delay much longer. > ## Reducing bandwidth > > How about for normal shares we just pass the block header, and have the > pool randomly pick a subset of transactions to audit? Any fraud cancels > the users shares. This will work best in conjunction with a UTXO proof > tree to prove fees, or by just picking whole shares randomly to audit. Might as well just use higher difficulty shares (each one audited) for the same effect. Block proposals allow the miner to tell the pool its transaction set once (per txset change) for any number of shares. IF bandwidth becomes a real problem, I have a draft of a "GBT 2.0" that does some more improvement in this area. > # Pool work > > So does eliopool already accept arbitrary shares like this and do the > correct accounting already? (IE adjust share amount based on fees?) What > happens when the pool doesn't get the share directly, but does see the > new block? > > + possible protocol extensions I don't follow. > # Miner work > > Basically we need code to merge the two block templates together to find > commonality. I guess you probably want to implement this in bfgminer > first, so add the code to libblkmaker first, then maybe python-blkmaker. libblkmaker's API was designed for this from the start, so it should be fairly easily implemented. > We also want an automatic fallback to local solo mining if the pool > can't be contacted. > > + possible protocol extensions Failover already functions, but probably could use a rewrite... Luke -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Decentralizing mining
On 10 June 2013 23:09, Peter Todd wrote: > So here's the parts that need to be done for step #1: > > > # Protocol Work > > Basic idea is the miner makes two connections, their pool, and a local > bitcoind. > > They always (usually?) work on the subset of transactions common to both > the pool's getblocktemplate and their local one. When they find a share > if it doesn't meet difficulty they just hand it to the pool. Currently > that is done by handing the whole block over, correct? I know the BIP > says otherwise, but we should optimize this to just hand over tx hashes > where possible. > > If the share does meet difficulty, hand it to both the pool and the > local bitcoind. Should hand it to the pool first though, because the > pool likely has the fastest block propagation, then hand it to local > bitcoind. An optimized version may want to have some record of measured > bandwidth - this applies Bitcoin in general too, although also has other > issues. > > > ## Reducing bandwidth > > How about for normal shares we just pass the block header, and have the > pool randomly pick a subset of transactions to audit? Any fraud cancels > the users shares. This will work best in conjunction with a UTXO proof > tree to prove fees, or by just picking whole shares randomly to audit. > > We'll need persistent share storage so if your connection disconnects > you can provide the pool with the full share later though. > > Incedentally, note how the miner can do the reverse: pick random block > headers and challenge the pool to prove that they correspond to a valid > block. With some modifications Stratum can support this approach. > > > ## Delibrate orphaning of slow to propagate blocks > > Block headers can be flooded-filled much faster than blocks themselves. > They are also small enough to fit into a UDP packet. Nodes should pass > headers around separately via UDP, optinally with some tiny number of > transactions. When we see a valid block header whose contents we do not > know about a miner should switch to mining empty or near empty blocks in > solo mode that would orphan the still propagating block. Doing this is > safe, we'll never build on an invalid block, economically rational while > the inflation subsidy is still high, and helps reduce (although not > eliminate!) the advantage a large miner with high-bandwidth connections > has over those who don't. > > Of course, the other option is to build a block extending the one you > don't know about, which is even more rational, but doing poses major > risks to Bitcoin... > > This functionality can be implemented later - it's not strictly part of > pooled-solo mode. > > > # Pool work > > So does eliopool already accept arbitrary shares like this and do the > correct accounting already? (IE adjust share amount based on fees?) What > happens when the pool doesn't get the share directly, but does see the > new block? > > + possible protocol extensions > > > # Miner work > > Basically we need code to merge the two block templates together to find > commonality. I guess you probably want to implement this in bfgminer > first, so add the code to libblkmaker first, then maybe python-blkmaker. > > We also want an automatic fallback to local solo mining if the pool > can't be contacted. > > + possible protocol extensions > Sounds very promising. Suspect it will need a fair amount of testing ... > > > -- > 'peter'[:-1]@petertodd.org > 005576673e616271f762a5d8779d5fe7796c6e43ed43df5aa189 > > > -- > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
