I suppose they will email private keys to all winning bidders. In single Cc: email.

There can be more than one P2Pool. Or P2Pools could be tiered into hierarchy - see this idea https://bitcointalk.org/index.php?topic=648138.msg7309185#msg7309185

How about going tree instead of linear - what if there were multiple "tiers" of P2Pools?

The top of the tree would be Bitcoin blockchain. There will be Tier-1 P2Pool with high hashrate - lets say 10PH with shares difficulty 10 TH. Then, there would be multiple Tier-2 P2Pools, each one trying to mine Tier-1 P2Pool block, using its own blockchain with difficulty 10GH. And so on for Tier-3 P2Pools.

Users would connect to most appropriate P2Pool tier so that they get some payout lets say each day. Of course, payouts for Tier-3 will be in form of shares for Tier-2. But this allows steady-low-variance (holy grail, right) income for any type of device.

What do you think?

Why the HELL someone with Petahash needs pool at all? They should have been mining solo since start.

Possible BUG:

Mining solo to bitcoind via GBT and having additional STRATUM pool for new block notifications does not work. The stratum thread is closed very soon with "Pool 1: Connection not needed, suspending" message.

I checked the code and it seems to calculate target correctly (lowering it based on time) when using getwork or getblocktemplate.

I suspect the real problem is that once the 20 minutes since last block passes, the opportunity window to submit DIFF=1.0 share is very short, someone else wins INSTANTLY and the testnet flips back to high difficulty.

I'm trying to test mine solo some testnet bitcoins, using external miner (USB Erupter). The difficulty is pretty high - 28.6K as of now. Moreover, I found a discrepancy between target in getwork RPC call and difficulty in e.g. getmininginfo RPC call.

I know that when there is no block in 20 minutes on testnet, the difficulty should lower temporarily to 1.0. However, the target remains high (now "target" : "0000000000000000000000000000000000000000000000001d4b020000000000"). This causes problems when using external miner as it does not report difficulty 1 shares, but wait for share satisfying target.

Is this a bug in bitcoind or did I miss something?

I am using latest cgminer to solo mine on testnet and I think there is a bug with handling the testnet difficulty. After no block for 20 minutes, testnet difficulty drops down to 1.0, but cgminer still requires work of previous (high) difficulty (12.3K now).

>bitcoind getwork      returns "target" : "0000000000000000000000000000000000000000000000000d54050000000000"
>bitcoind getinfo       returns  "difficulty" : 1.00000000

Is this a bug in cgminer?

Specifying own change address equal to adding this address as additional destination to the transaction. Well, you need to calculate the remaining amount (this could be done by Mycelium anyway).

It could be some autoimmune disease, maybe from food. If she can try that, I would recommend her to fast for 2-3 days to check if symptoms lessen.

What if miners announced on the network the best PoW reached prior to finding the mined block?

This could kind of close the gap between "0 confirmation" and "1 confirmation". Anyone can check if his transaction is being worked on, because e.g. 50% of difficulty target reached indicate that some work was already spent on that.

For given TXID, the network would return a block containing that TX together with best target reached, so anyone can verify it.

The only problem with this is how to prevent overloading the network/miners with bogus requests/DoS.

Oh, now I understand. Not sure, but:

1) nBits (=target) in block header is stored on disc and verified when loading, you do not want to go all way back
2) there might be some interesting problems when you try to calculate nBits "on the fly" when there are reorgs of chains near the difficulty retarget

thus, it is probably better to keep the value in the header anyway. If there is another, more important reason, I would like to know it, too.

There are strict rules how the target is calculated, so miners cannot fake the target, otherwise the block is invalid.

For example, inside the 2016 window of the same difficulty, the target must match the previous one. On the boundaries, rules for adjusting the difficulty applies.

Who guarantees that the nLockTime transaction will stay in transaction pool for long time? Sending from address A and then destroying its private key looks VERY DANGEROUS to me.

If the nLockTime transactions are preserved in the memory pools of all nodes, how it is prevented for misuse (DOS attacks)?

Yes, it can. As paid service, however:

- use vanitygen to generate your own 1Rain, 1Sunny, 1Snow, 1Tornado etc. BTC addresses
- import these into Bitcoin Core using importprivkey and fund them
- form a transaction from all these vanity addresses to my 1WeathrState subscription address
- then, each day my system will send you 1 mBTC to one of your vanity weather addresses
- thus, you can see incoming transaction indicating the weather for your location right directly in your client!
- I collect just moderate 5% fee for this wonderfull service

Hi! I am currently testing the Mycelium on my phone. Sorry if I am dumb, but I can't figure out how to send BTCs from multiple addresses to multiple addresses?

Is there a way to zero the fee when the transaction size and maturity does not require any? Its more a problem of destroying rounded values when fee is subtracted than the fee itself.

No

Yes. Assuming you own that address. If you created that address in your Blockchain.info account, you should own it (also, you have saved it in your backup, if you got it).

Meanwhile, you can check amount on the address on blockexplorer.com.

You are sending to BTC address, not to blockchain.info wallet.

Each block improves security of blockchain. Even empty one.