Re: How (and why) to use the Relay Network

[Matt Corallo]

I used to have a list of pools here, but it had gone unupdated in a long time and was very incomplete...essentially, most the major pools and large miners are connecting to the relay network in some capacity.

[gmaxwell]

I've been running the relay node client since Matt wrote it and it appears save a considerable amount of bandwidth (e.g. avoiding resending >95% of all transactions) which means faster block relaying and fewer orphans.

Plus, alternative transports make the network more robust e.g. some crazy firewall starts blocking the Bitcoin P2P network, the relay client may get through and prevent partitioning.

Great stuff.

[-ck]

Thanks Matt, good work. The ckpool instances out there (public and the private one yet to become public) already use this and we're grateful.

[zvs]

does it request blocks/transactions from multiple sources as well?

re:

   "addr" : "public.eu.relay.mattcorallo.com:8335",
        "bytessent" : 21548126,
        "bytesrecv" : 5476607,

or bitcoind i reset maybe an hr ago

        "addr" : "146.185.173.241:8335",
        "bytessent" : 3910519,
        "bytesrecv" : 281180,

[mdude77]

Watching.

M

[linuxforyou]

Thanks Matt for the great work, Like the python version more.

[DrHaribo]

Thanks for this great service, Matt.

I've been using the relay network since it was first announced. The only problem I can report is that I began getting the blocks so quickly that blockchain.info marked a lot of blocks as coming from my pool when they did not. 

[Matt Corallo]

does it request blocks/transactions from multiple sources as well?

re:

   "addr" : "public.eu.relay.mattcorallo.com:8335",
        "bytessent" : 21548126,
        "bytesrecv" : 5476607,

or bitcoind i reset maybe an hr ago

        "addr" : "146.185.173.241:8335",
        "bytessent" : 3910519,
        "bytesrecv" : 281180,

Hmm? Note sure what you're asking here. I know several pools are running one of the clients, and Ive manually made outbound peers to a few large pools and a small set of other random nodes, all of which are received blocks from. I dont think I ever fixed the outbound manual peering to send blocks over those connections, but all other connections should both have blocks and transactions pulled from them and receive blocks (and probably transactions).

[PatMan]

I've been using this neat bit of kit on my p2pool setup for the last week or two, integrates seamlessly with p2pool  - great stuff indeed Matt, many thanks 

[Matt Corallo]

Thanks for this great service, Matt.

I've been using the relay network since it was first announced. The only problem I can report is that I began getting the blocks so quickly that blockchain.info marked a lot of blocks as coming from my pool when they did not. 

Do you use standard bitcoin addnode or have you upgraded to one of the relay network clients? Are there any features you want form the relay clients?

[DrHaribo]

Do you use standard bitcoin addnode or have you upgraded to one of the relay network clients? Are there any features you want form the relay clients?

I'm still just using addnode. I was planning to build the client into my mining server code. But since it is taking me a while to get around to it, I should probably just set up the standard client in the meantime.

Here's how I think a last bit of performance can be squeezed out of this:

Identify blocks coming from the biggest pools, by coinbase address and/or signature. If not recognized consider the source unknown and untrusted.

For known sources, keep track of how many times your local bitcoind accepts and rejects blocks from this source. Sources with 10+ accepted blocks and zero rejected are considered trusted. Other sources are untrusted.

When you receive a block from a trusted source, start building on top of it immediately. Still submit the block to local bitcoind for full verification. If bitcoind rejects the block, push new work data to miners to immediately go back to building on the previous parent block.

Possible issue: some getwork clients will get confused about what is old vs. new work when you send work data it has previously seen. They will get stuck DoSing the pool requesting new work over and over as fast as they can until there is a new block change. I'm not sure if any getblocktemplate clients have issues with going back to "old" work. Maybe they can get stuck mining on the invalid block, thinking it is the latest work? They'll probably be fine, but I need to find out for sure. Stratum clients, using only a single TCP connection, should be fine.

Thoughts?

[DrHaribo]

Would something similar to this relay network be useful for the p2pool share chain?

[Matt Corallo]

I'm still just using addnode. I was planning to build the client into my mining server code. But since it is taking me a while to get around to it, I should probably just set up the standard client in the meantime.

Here's how I think a last bit of performance can be squeezed out of this:

Identify blocks coming from the biggest pools, by coinbase address and/or signature. If not recognized consider the source unknown and untrusted.

For known sources, keep track of how many times your local bitcoind accepts and rejects blocks from this source. Sources with 10+ accepted blocks and zero rejected are considered trusted. Other sources are untrusted.

When you receive a block from a trusted source, start building on top of it immediately. Still submit the block to local bitcoind for full verification. If bitcoind rejects the block, push new work data to miners to immediately go back to building on the previous parent block.

Possible issue: some getwork clients will get confused about what is old vs. new work when you send work data it has previously seen. They will get stuck DoSing the pool requesting new work over and over as fast as they can until there is a new block change. I'm not sure if any getblocktemplate clients have issues with going back to "old" work. Maybe they can get stuck mining on the invalid block, thinking it is the latest work? They'll probably be fine, but I need to find out for sure. Stratum clients, using only a single TCP connection, should be fine.

Thoughts?

The relay networlk already doesnt do full verification. It does simple SPV validation simply as a DoS precaution, but thats already rather quick. Building blocks on top of another miner without validation is still not possible no matter what precautions you take...Imagine a pool op of a smaller pool who wants to have some fun...they break into a large, "trusted" miner and change it to include some invalid transaction in its blocks, now it finds a block and everyone else goes off and mines on it, giving the smaller miner a chance to mine blocks for free while the rest of the network is off building invalid crap.

[Matt Corallo]

Would something similar to this relay network be useful for the p2pool share chain?

P2Pool already does something similar within its own network for the share chain.

[Matt Corallo]

Thanks Matt, good work. The ckpool instances out there (public and the private one yet to become public) already use this and we're grateful.

Are you using one of the clients or just a simple -addnode?

[-ck]

Thanks Matt, good work. The ckpool instances out there (public and the private one yet to become public) already use this and we're grateful.

Are you using one of the clients or just a simple -addnode?

Using the full java client.

[gmaxwell]

Would something similar to this relay network be useful for the p2pool share chain?

P2Pool already does something similar within its own network for the share chain.

Yup, has for some time— it's is part of why p2pool's observed orphan rate is less than 1/10th several of the larger pools.

Identify blocks coming from the biggest pools, by coinbase address and/or signature. If not recognized consider the source unknown and untrusted.
For known sources, keep track of how many times your local bitcoind accepts and rejects blocks from this source. Sources with 10+ accepted blocks and zero rejected are considered trusted. Other sources are untrusted.

Please don't do this. It undermines the security model of Bitcoin, and at most saves you a few _milliseconds_ (and even there it isn't lost work because you could theoretically find a block and win the block race) since virtually all the transactions are already verified, and cached in memory and the node doesn't check them again.

SPV clients are counting the blocks you produce to be valid. Setting up that kind of verification also produces extreme fragility in that if a software error makes a good node produce a bad block you could have a whole series of bad blocks created by mutually trusting hosts, creating a large fork in the network. This kind of approach is also vulnerable to attack since without a PKI infrastructure you cannot determine who the source of a block is— for example it could just be a sybil who is relaying good blocks to you from other parties but later starts feeding you trash. (and, of course, imposing identities on mining has a multitude of problems and risks that go beyond the simply technical)

[DrHaribo]

The relay networlk already doesnt do full verification. It does simple SPV validation simply as a DoS precaution, but thats already rather quick. Building blocks on top of another miner without validation is still not possible no matter what precautions you take...Imagine a pool op of a smaller pool who wants to have some fun...they break into a large, "trusted" miner and change it to include some invalid transaction in its blocks, now it finds a block and everyone else goes off and mines on it, giving the smaller miner a chance to mine blocks for free while the rest of the network is off building invalid crap.

If a big pool got hacked you might be mining on invalid data from the time you submit their block to your local bitcoind and until you get the response back that it rejects the block. After that you switch to building on the previous parent block and mark this pool as untrusted so it won't be repeated.

About 100 times per day you get a sub-second advantage to avoid creating an orphan race. And very rarely, probably less often than once a year or maybe never, you mine invalid data for a sub-second. For every invalid block you mine, you have avoided 36 500 orphan races, of which you would have lost more than half because the other guy had a head start. Sacrifice one block (or likely zero) to save 20 000.

SPV clients are counting the blocks you produce to be valid. Setting up that kind of verification also produces extreme fragility in that if a software error makes a good node produce a bad block you could have a whole series of bad blocks created by mutually trusting hosts, creating a large fork in the network. This kind of approach is also vulnerable to attack since without a PKI infrastructure you cannot determine who the source of a block is— for example it could just be a sybil who is relaying good blocks to you from other parties but later starts feeding you trash. (and, of course, imposing identities on mining has a multitude of problems and risks that go beyond the simply technical)

In the rare event that an invalid block might be created, it's not going to reach SPV clients.

Verification doesn't need to be 100%. You can check that the difficulty (bits) is correct, that the generation transaction pays to a known address used by a "trusted" pool, and that the block hash is valid at this difficulty. So an attacker could mine an invalid block and cause you to mine invalid data for less than a second. That's a cost of over 25 BTC to them. They could repeat it for every trusted payment address you have, but no more than that.

Say you trust 4 sources. An attacker could spend over 100 BTC to make you mine invalid data for maybe one second in total. A smarter attacker would use blockwithholding instead, making you lose not 1 second of mining but 4 blocks (average) worth of mining effort, which is much much more than any pool does in 1 second.

Please don't do this. It undermines the security model of Bitcoin, and at most saves you a few _milliseconds_ (and even there it isn't lost work because you could theoretically find a block and win the block race) since virtually all the transactions are already verified, and cached in memory and the node doesn't check them again.

I don't see how it undermines the security model of Bitcoin. If you mine a block before the parent is verified by your own bitcoind you could wait until that happens before sending your new block to the relay network. That way an invalid block never leaves your pool. This way others on the relay network will only see the first invalid block from someone else. You will never add another invalid that they will see.

Say you get blocks from trusted sources 100 times per day and it saves you a total of 25 seconds of mining where you would have entered an orphan race and the other guy has a head start. Maybe 15 seconds where you would have lost an orphan race if you had gotten a block. That's an hour and a half of worthless mining saved per year.

You are right there isn't much to save. For most pools 1.5 hours of mining per year isn't a lot of blocks. While I'm pretty sure this would be of help and not do any harm, the benefit probably doesn't outweigh the effort of implementing this, which is why it has just stayed an idea.

[Matt Corallo]

This discussion has been hashed out time and time again so there is no reason to continue it here. Suffice to say, you cannot build on blocks relayed to you by the relay network any more than you can on blocks sent to you from a random peer on the p2p network.

[DrHaribo]

This discussion has been hashed out time and time again so there is no reason to continue it here. Suffice to say, you cannot build on blocks relayed to you by the relay network any more than you can on blocks sent to you from a random peer on the p2p network.

Of course you can. It's a game of probabilities. The probability that your mining effort produces a block that ends up on the blockchain versus the probability that you produce a block that does not (orphaned, invalid, doesn't matter). If you reduce the orphan rate a little at the cost of possibly increasing the invalid rate an extremely tiny bit, then the end result improves. Mining invalid data and orphaned blocks is the same: you end up with nothing.

But even a big pool will only save a couple blocks per year, so it is perhaps not worth discussing further.

I didn't mean to derail the thread.