Topic: Coinbaser branch's new JSON-RPC method (Read 5989 times)

How about enabling it exclusively on testnet for the moment? It is possible that badly written merged mining systems might spam BitCoin with blocks of low difficulty while happily mining on their own chains. Having the DOS prevention code enabled would mitigate this risk.

I don't know nuthin about merged mining-- anybody have objections to Luke-Jr's pull?

Right, I didn't think Lukes proposal through properly. It is simpler so I updated the wiki page to say that.

Yeah, that solution does look better. It'd be good to put that on the Alternative Chains wiki page too.

(off-topic, sorry) I think also Luke-Jr's proposal
could use elaboration.  I take it to mean, have the aux chain software enforce uniqueness of its work-proving hashes.  I think that would work too and is a bit more elegant than sticking the value in the aux chain.

Yeah, that solution does look better. It'd be good to put that on the Alternative Chains wiki page too.

Why is it so hard to simply disallow a master-chain block from "vouching for" more than one block in each aux chain? :/

Maybe there's something I missed, after all I haven't actually implemented this.

There is a more flexible solution to the problem.

The problem is that, with MM as first implemented, a miner could cheat the proof-of-work system by putting more than one Namecoin block header into one Bitcoin block.  This "cheating" would not cause a problem if the Namecoin blocks all had the same previous-block hash: one or another would win the race, as happens when competing blocks enter the network.  The problem would arise if a linked series of Namecoin blocks all existed in one Bitcoin block's aux Merkle trees.  The miner could work on them all at once, getting more from his hashes than difficulty warrants.

Vince's solution is to constrain the paths by which Namecoin blocks may be embedded in Bitcoin blocks.  This works, but it complicates the picture for miners and chain designers in a future with many merged-mining chains.

A better solution for new chains is to prevent the existence of linked series of aux chain blocks which lack proof of work.  You might do that by requiring each aux chain block to refer (perhaps via its own coinbase or a new header field) to the "solution" (target-meeting hash of parent chain block) as well as the hash of the previous block in the aux chain.  In Bitcoin, these two are the same, namely hashPrevBlock.  Force blocks to refer not just to the previous block in the chain but to the proof of work on that block.  A series of aux blocks all being worked on would not make sense, because the second block in the series would have to reference the first block's solution, so the first block would have to have been solved.

That's weird. What is the prefix for, if Namecoin doesn't actually need it?

And those blocks without magic prefix are accepted by the rest of the nmc network?  If so that's my concern dealt with.

The original reason for that was simply to help miners avoid a lot of tiny payouts they have to pay large fees to spend.

As I said, valid values can be as low as 1 satoshi...

Well I can see two approaches to determining limit.  Both have issues but just because it's tricky to enforce a limit sensibly isn't a good reason to allow open slather...

1/ Tx outpoint size is relatively constant.  Yes it can vary but for 99% of use cases it will the same type of script which is the same length.  So from simple easy to enfore rule that would probably be the better option.  I notice eligius already has some notion of a payout queue and I thought that might be somehow related to this issue.  I was quite suprised when I started looking a eligius coinbases to find the number of outputs was always far far less than what I'd guess yr total miners would be.  That's actually what got me thinking about this as a potential problem.  When I saw that I thought you were limiting it for that very reason.

2/ min tx value would be easier from a pool ops point of view.  And whilst the size of the outputs would be more variable it would at least prevent extreme accidental abuse.

And what reasonable limit would that be? There are at least legitimate circumstances for having tiny-amount outputs (I always include a single 1 Satoshi output so it shows up on my pool's listtransactions). I suppose there could be a hard-cap on total count of outputs, but what should that be? Maybe 1% of the current block size limit? That gives 294 outputs max at 1 MB (the current hard-coded block size limit)-- an average of ~0.17 BTC each.