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.

See also: https://bitcointalk.org/index.php?topic=29675.msg3490536#msg3490536

Yes, you wrote that and I understood what you wrote— but that precisely what I was saying no to, it's actually less computation _and_ less space.

[As far as the ranting about thread moves, we were having an extensive sidebar about hash based signature in a months old thread that was very clearly about _ECC_, thats all. Nothing personal.]

No, it requires less computation (than the bidirectional enumeration) and much less space for normal choices of parameters. There are a couple additional codewords (usually two for normal parameters) but all the codewords are half the size of that ladder proposal.

You see incorrectly.

Nothing, which is why it would be pointless.

It was probably mined seconds after the prior blocks. The timestamps are only approximate.

Uh, it's called  a Winternitz signature. Google it.

I like lamport a lot— and first proposed we someday add some form of it to Bitcoin back in 2011... though straight up lamport's single use-ness is a major liability (e.g. say you need to resign an input to add fees later, maybe a couple times… oops, compromised your key).

The space overhead is really considerable— even when using Winternitz compression, to the point that it couldn't be a replacement for bread and butter transactions, but I think it would be nice to support.