There is a reason— just that it can hide the faults when your other things failed.  Sort of if you assume everything is right, then no— it's no harm. But of course, if you could really get away with assuming that everything is right you would have not worried with additional entropy sources to begin with.  Another reason is that it makes audit and review harder, e.g. if you can test it and confirm that it always gives the same keys for the same deck then thats a useful property to facilitate testing.

Not a reason to not do it, but it's just something to keep in mind.

It's insufficiently specific, but existing examples which require developer controlled block signing or closed source software don't really pass a sanity check as decentralized tools— though they're often marketed as such.

You may find this enlightening: https://download.wpsoftware.net/bitcoin/pos.pdf

I've generally found it to be pretty easy to shuffle poorly... I'd rather throw hex dice 128 times and compress 2:1 with sha256. Even a little excess entropy plus a cryptographically hard compression function should overcome all small biases, and the order dependence in a shuffle much harder to notice or test for. The excess input also gives you enough data to perform some tests that thwart user misuse (you rolled 0 100 times in a row? really?) without compromising security.

Yes, but they still cost more in marginal fees, instead those transactions used priority to get them through which could have instead been used to make valid transactions... and the loss of priority will me that person must pay more fees in the future.

They are technically spendable but they cost more in marginal fees than they are worth... It's altruistic to redeem them but not rational to do so otherwise.

Several indeed: On average the network tries 16,818,461,371 modifications (each allowing 2^32 hash attempts) per block solved these days.

Normal nodes do not relay old transactions... but, indeed, could have just been them not updated after all this time.

The one I searched for got not hits, good sleuthing.

If they are not in a meaningful sense and you determine how then you will have compromised SHA256— one of the best studied cryptographic pseudorandom functions.

Mining is not a search, it's effectively a lottery. Each attempt is independent of the others and trying one does not increase the probability of your next find being a solution because you do not enumerate a finite space. Once a miner has exhausted the nonce it changes the block content (usually by incrementing something in the coinbase field in the coinbase transaction) and continues.

No.  It might be helpful if you explain why you think it would, since that must be predicated on some misunderstanding which we can correct, but I can't guess what it would be.

BC.i's analysis is ... seldom good.  Just look in the coinbase of the block.

Well one transaction in particular is always distinct: the coinbase.  Every miner will be paying their winnings to a different address.  In the case of pooling, pools usually put a worker-distinguisher in the coinbase field of coinbase transaction to keep the work of the hashers they are paying distinct.

Absolutely not. They are working on block headers which have a different merkel root, always.  Existing mining protocols do not even have a facility to set the nonce position/range.

They all start at zero (or any other number) it doesn't matter as they're all working on work which is merkle root distinct.

There is absolute no random number generation in mining. There is no performance sensitive random number generation anywhere in the bitcoin system.

The times reported on bc.i are just whenever they saw it. Because this is a dust transaction that wouldn't have generally been relayed (and because bc.i themselves suppress these when unconfirmed) it wouldn't have been seen by bc.i until it ended up in a block.

There is an option to control binding separately from access:

  -rpcbind=<addr>        Bind to given address to listen for JSON-RPC connections. Use [host]:port notation for IPv6. This option can be specified multiple times (default: bind to all interfaces)


If you don't set an rpcallowip at all the default is that only 127.0.0.1 is allowed _and_ it only binds to 127.0.0.1. So if you just leave out your redundant allow statement you'll get what you want.   It would probably be prudent to detect rpcallowip=127.0.0.1 and also bind only to localhost in that case— it doesn't matter, but it would avoid false alarms like yours.

Edit: After looking into making the change, I think that detecting localhost is too complex to be worth it. (e.g. correctly detecting 127.0.0.0/8 vs 127.0.0.0/1)

Unconfirmed non-self transactions have never been included in reported balances.

I've already nagged the miner in question about the wad of dust floods they just mined.


If you've received some of this 1e-8 dust to a bitcoin-core wallet, https://github.com/petertodd/dust-b-gone is a good way to get rid of it.

He's probably just blindly posting without reading any of the messages in order to get his signature spam more widely distributed.

I'm going to lock this thread since it seems like the question was asked and answered and isn't making any more progress.

This thread is not self-moderated, so only the forum moderators are deleting posts here. Though it ought to be self moderated, because the incessent trolling is really over the top.