Bitcoin Forum

I voted no because of the fine-print in your original post.

I think setworkaux is OK, but I don't like "doesn't work on windows" changes to support one mining pool.

So, how do you intend setworkaux to be used?

setworkaux <id> [data]
If [data] is not specified, deletes aux.

It might work on Windows with a few changes, but I don't have a Windows system to test on. http://msdn.microsoft.com/en-us/library/96ayss4b(v=vs.71).aspx

I'd really like to see something like this get in, but I agree with Steve - it's not clear why this is different to what Vince has already done.

setworkaux looks pretty much like what I'd imagined. You might want to split the command line option out, as that's a separate and unrelated change.

BTW, what's the backwards-time detection stuff about? I know time can sometimes go backwards on some machines, but you could add a comment explaining why this code is there (was it observed in the wild on eligius machines)? Also it doesn't currently log anything when extraNonce overflows - is that an exceptional condition or something that's expected to happen normally? If the former (it's a bug) maybe assert/terminate. If the latter does it need to be logged? If it's unknown, logging for a while seems to make sense.

Does setauxwork interact with the new getmemorypool RPC command at all?  Should it?

And should there be a listauxwork RPC command?

No, getmemorypool has nothing to do with setworkaux, coinbases, or merged mining. It's a JSON-RPC command that was merged with even less review than coinbaser, and is only used by a single pool.

Huh?  getmemorypool discussion is/was here:  https://bitcointalk.org/index.php?topic=39088.0 (https://bitcointalk.org/index.php?topic=39088.0)

I'll just note that I'm damned if I do pull stuff that has some discussion here (and no objections raised), but damned if I don't pull stuff that first had no discussion, and then had a little discussion with some dissent.

What dissent? I see questions, and some "no" votes (strangely, most of which just appeared today), but no arguments against this.

The argument that I have: it appears that "getmemorypool" is a step towards allowing the miner to record a reasonably accurate time of finding the block. Which is in turn a step towards more tight and accurate timekeeping in the whole block chain.

Your patch just perpetuates the existing bad situation where the block times are untrustworthy and acausal.

It is impossible and unreasonable to force everyone to have the exact same system clock.

I think that Lolcust and ArtForz provided a good counter-example by their GeistGeld alt-chain that uses SNTP for time synchronization. The objective is not "exact-same" system clock, but the system clock differences that are within currently acceptable norms: I think it is still one minute in the insurance industry and in something close to one second in the finance industry.

Insert exactly one of these headers into the scriptSig of the coinbase on the parent chain. vinced's code always inserts an OP_2, 0xfa, 0xbe, 'm', 'm' in front of it, but you don't have to.

The remain concerns are:  Does the -coinbase <cmd> enforce either a minimum tx output value or a max number of tx outputs?  If not it should.  The primary use case for this for pools to payout their miners and have invalid blocks dealt with automagically.  It there are no limits it's only a matter of time before some pools start paying out tiny balances to masses of miners.  This could bloat the coinbase a lot unless I'm missing something.

My second concern is that Luke has made the following comment in the wiki:


As far as I can see this patch doesn't deal with validation of the aux blocks.  Presumably this will be left to vinced's original code as you'd require an update to all namecoin miners to alter it's validation rules.  So the question is, will the absence of OP_2, 0xfa, 0xbe, 'm', 'm' before the aux header prevent vinced's validation from working?  If so then the rpc call should check this and return an error if it doesn't.

There is nothing anyone can do to stop block-makers from producing tiny coins. Coinbaser does prevent invalid outputs, though-- if the output is not consistent (ie, tries to pay too much, to an invalid address, etc) it fails over the the default behaviour.

No, the reason I changed this to say optional is because I am successfully using it on Eligius without that magic prefix.

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

*If* a reasonable limit on coinbase outputs could be added then for what it's worth I'd be happy to add my vote in favour on the change.  Without said limits then my vote is in favour of the 'setworkaux' part of the change only.

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.

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.

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...

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

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

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.

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? :/

(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.

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

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

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.