Re: [Bitcoin-development] Proposal: Vote on the blocksize limit with proof-of-stake voting

2013-06-10 Thread Daniel Lidstrom
Reserving my judgement until I've though about it more (design by committee
scares me, and this voting sounds expensive), I think the SPV-verifiable
moving median can be done by binning the space of block size limits, and
for each node in the UTXO tree, a value for each bin is stored which is the
sum of the corresponding bins of each of the children.  The childless nodes
- which correspond to the individual UTXOs - increment the appropriate bin
of their parents according to the rules you mentioned.  The bin values in
the root node of the UTXO tree would then be added to those, weighted
appropriately, of the previous N blocks.

The hash of a node would be that of the bin values, concatenated with the
child nodes' hashes.  In this way, any step of the calculation of the
median would produce a localized error in the UTXO tree that's easily
verified.

The number of bins would have to be kept relatively small in order to keep
this from adding too much data to the UTXO tree branches though.


On Mon, Jun 10, 2013 at 2:30 AM, Peter Todd p...@petertodd.org wrote:

 On Mon, Jun 10, 2013 at 04:09:26AM +, John Dillon wrote:

 My general comments on the idea are that while it's hard to say if a
 vote by proof-of-stake is really representative, it's likely the closest
 thing we'll ever get to a fair vote. Proof-of-stake is certainely better
 than just letting miners choose; as you point out miners can always
 choose to decrease the blocksize anyway so we only need a vote on
 allowable increases. Proof-of-stake also clearly favors those who
 actually have invested in Bitcoin over those who only talk about
 Bitcoin.

 I'll also say that while I know people will complain about putting
 politics into a technical problem, as I keep saying, is *is* a political
 issue. The limitations may be technical, but the ultimate issue is a
 very political decision about what we want Bitcoin to be. Yes, there
 will be people campaigning left and right to get users to vote for
 various limits with their coins, deal with it. Democracy is messy.

 Voting would take a lot of the nastier politics out of the situation,
 perhaps somewhat ironically. It would quite clearly take control away
 from the core development team, and the Bitcoin Foundation, and put it
 back in the hands of the community; you can't argue conspiracy theories
 that the Foundation is trying to control Bitcoin when there is a
 completely transparent voting system in place. People will complain that
 big Bitcoin players are throwing their weight around, but the blockchain
 itself is a voting mechanism that is anything but 1 person = 1 vote.

 Of course I wouldn't be the slightest bit surprised if users happily
 vote themselves into something looking like a centralized PayPal
 replacement in the long run, but at least if that happens the process by
 which they get there will be transparent and relatively democratic.


  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

 I just wanted to point out how general this mechanism is. Regardless of
 what the scriptPubKey form is, standard, P2SH, multisig, whatever to
 vote is to simply prove you could have spent the txout.

  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.

 Ah, you're assuming a direct Patricia tree. Keep in mind that
 scriptPubKey's can be up to 10,000 bytes long, and an attacker can use
 that (with 10,000 other txouts) to create some extremely deep trees. I
 said on IRC a few days ago about how skeptical I am of implementing
 consensus critical systems with such huge differences in average and
 worst case, but I'll admit this is a decent use-case.

 Having said that, proof to SPV clients leaves open the interesting
 possibility that a third-party holding Bitcoins on your behalf can prove
 that they voted according to your wishes, or even prove they voted
 according to all their users wishes. Basically we'd add a rule for the
 UTXO tree where a specific OP_RETURN form is included in the UTXO tree,
 even though it is unspendable, and is removed from the tree if the
 master txout is spent. Note that in this case by prove they voted we
 mean the service actually taking the step of ensuring their vote was
 recorded in the blockchain.

  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
  

Re: [Bitcoin-development] Proposal: Vote on the blocksize limit with proof-of-stake voting

2013-06-10 Thread Melvin Carvalho
On 10 June 2013 06:09, John Dillon john.dillon...@googlemail.com 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 also ensures that for a
 miner
 the act of including a vote is never wasted due to the 

Re: [Bitcoin-development] Proposal: Vote on the blocksize limit with proof-of-stake voting

2013-06-10 Thread Pieter Wuille
On Mon, Jun 10, 2013 at 10:14 AM, Melvin Carvalho
melvincarva...@gmail.com 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

2013-06-10 Thread Mark Friedenbach

-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 the cost of including votes in blocks 5% of every
block
 should be 

Re: [Bitcoin-development] Proposal: Vote on the blocksize limit with proof-of-stake voting

2013-06-10 Thread Alan Reiner
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 a
  merkle-sum-tree.

  The slightly unusual construction of votes makes implementation by
 wallet
  software as simple as 

Re: [Bitcoin-development] Decentralizing mining

2013-06-10 Thread Peter Todd
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

2013-06-10 Thread Luke-Jr
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

2013-06-10 Thread Melvin Carvalho
On 10 June 2013 23:09, Peter Todd p...@petertodd.org 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