So?.

The Request for Comments (AKA RFCs) are documents published by the IETF like this one. I have yet to see a reference to the number of the RFC you're talking about.

Where's the RFC?.

Then, IMO, the biggest issue left is whether it would be antisocial to mine lots of blocks with 1,000 or more outputs in the coinbase transaction.

No, they are per input. The transaction fee is based on the size of the transaction, which is wholly determined (for standard transactions) based on how many inputs and outputs they have. The context was a 'recombining' transaction with multiple inputs and one output. The size, and hence the fee, will depend on the number of inputs.

No, you'll pay .0005 per input. Do the math. For example, here's a transaction somewhat like the recombining transactions I'm talking about (though in reverse):

http://blockexplorer.com/tx/d28fb4ceeab94b31daf95b87d6e7ae9c740ffba564f4fb0d3c1f4093225b4c4b
Notice the fee was .03 and the number of transaction endpoints was 62. 62x.0005=.031
The fee was roughly .0005 per endpoint, just like I said.

One possible solution would be for pool members to agree to include each other's 'recombining' transactions as high priority transactions for no fee.

With this scheme, you will have one expensive transaction to 'recombine' all your mining revenues. Whether or not this will actually be significant in comparison to the amount of the revenues is an interesting question -- someone will have to do the math.

Currently, transaction fees work out to around .0005 per input for large transactions. This would mean mining pools would have to stay to around 1,000 members or fewer to keep transaction fees under 1% of mining revenue. (Assuming a dedicated 'recombine' transaction to gather mining revenues.) A better question though is how nasty will the chain get if we see more coinbase transctions with 1,000 outputs?

This is not correct, under the hard-coded rules in bitcoind. The data size of a transaction is the primary focus of fees, and will be huge if all the coins are fractions of what people actually spend.

You invite suggestions and then you ignore them.  That's your prerogative i guess.

I think this needs to be described very carefully and it is not as trivial as it sounds.  I don't mean this as a put-down, I do not see an obvious solution either and this is the point I struggled with myself when trying to design a distributed pool scheme.  If you can come up with a way to handle this it would be great.

Otherwise, I think centralized pools are not too bad if you can make them transparent (i.e., have pool publish tx contents that led to merkle root in some easy-to-access location, and even publish all shares submitted too).  Then there's not really much concern other than pool operator not including transactions.   But having a single funnel serialize the TXs in the network makes consistency much much simpler.

In other words, it seems fine to me to let a single node be responsible for serializing transactions as long as things are done in such a way that 1) the node can't "cheat" other than by denying service. 2) in the event that node denies service (or someone else denies service to that node), the TX serializer can be re-elected.

Secure leader-election in the presence of malicious parties is fairly well studied.  The classic reference is Feige's randomized voting scheme, where all nodes pick a random node and vote for that node to be the leader;  The node with the least votes is then elected leader (protocol repeated to break ties).  A google search of "leader election" should yield refs to more recent work.

[1] http://portal.acm.org/citation.cfm?id=796481

If you can't find a non-paywalled copy, here's a blog post on it: http://jsaia.wordpress.com/2009/09/21/consensus-ii-fieges-leader-election-protocol/

I wasn't talking about a transaction fee by the pool, but rather for the miners later when they want to spend it.

That's a cop-out.

That doesn't really fix the problem. CPU miners won't be able to meet that difficulty, and a pool of just CPU miners will never get a block. They are left out in the cold.

Are you suggesting that the coinbase transaction go last? Otherwise, the coinbase transaction will be at the tip of the merkle tree. I think you need the full header, the coinbase transaction, and the hash of every other transaction in the block.

I don't think this will scale.  If each node rebroadcasts every share to every other node, then the shares will have to be very difficult to not overwhelm the network.  I also think that reaching 'agreement' as to what the proper payout is will prove to be problematic, and this in turn makes it hard to tell whether the shares are valid, in a catch-22.  And splitting each block among all network participants will definitely be a problem.

What if the pooling was more 'local' within the network?

Conceptually, if I produce a share and the coinbase would have paid you, I would like to expect (but have no guarantee) that you will generate a share with a coinbase that would have paid me.

There is a sort of prisoner's dilemma problem because there is no way to know that the other person will return a share.  But every share could be considered an iteration, so a tit-for-tat strategy could make 'cheating' less profitable than playing 'honestly'.  And it would make sense if people could observe the shares that other people are generating for each other and identify who is returning share-for-share and who is not.

Each miner might be exchanging shares with dozens of other miners, and they wouldn't necessarily be organized into cliques.  Pools can overlap in an ad-hoc manner, and each person would in a sense be the center of their own pool.  This can scale indefinitely and each coinbase payout stays a limited size.  But staying within the technical limits could mean the variance will only decrease by so much.  Small miners won't be able to get fractions of pennies every hour.  Maybe that's a feature.

This does Proportional payouts, which are predictably unfair. To work, you'd have to also implement auto-hopping-- that is, when total shares reach 43%, throw them all away and start over. Alternatively, there is also a real-world PPLNS implementation in the Pools forum. Also, even with auto-hopping, each share would be valued at down to 0.00006806 at today's difficulty. Payouts of this size would result in huge transfer fees (which is why we added a minimum payout for Eligius) and coinbase transactions. Therefore, this kind of system would need to clutter together miners in different groups by similar hashpower so they all maintain at least 1% or so when the block is found. This also means that any number of CPU miners will still never find a block as a group.

Can somebody please point to some well known scholarly work that frames this argument a bit more elegantly than I can?

Feedback about first impressions/ associations.

I personally like crows, but a lot of people associate corvids with stealing. The thieving magpie and so on.
Definitely not an association you want to evoke if you want people to trust you with their money!

Perhaps you should choose a more innocuous bird to represent your brand.


BTChicken ? BTCrane ? BTCackling goose?