Bitcoin Forum

Other => Archival => Topic started by: Matt Corallo on September 02, 2014, 08:52:11 AM



Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on September 02, 2014, 08:52:11 AM
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.


Title: Re: How (and why) to use the Relay Network
Post by: gmaxwell on September 02, 2014, 08:54:11 AM
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.


Title: Re: How (and why) to use the Relay Network
Post by: -ck on September 02, 2014, 09:54:44 AM
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.


Title: Re: How (and why) to use the Relay Network
Post by: zvs on September 02, 2014, 09:59:38 AM
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,




Title: Re: How (and why) to use the Relay Network
Post by: mdude77 on September 02, 2014, 11:08:59 AM
Watching.

M


Title: Re: How (and why) to use the Relay Network
Post by: linuxforyou on September 02, 2014, 07:42:03 PM
Thanks Matt for the great work, Like the python version more.


Title: Re: How (and why) to use the Relay Network
Post by: DrHaribo on September 02, 2014, 08:33:48 PM
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.  :D


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on September 02, 2014, 09:23:48 PM
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).


Title: Re: How (and why) to use the Relay Network
Post by: PatMan on September 02, 2014, 09:25:33 PM
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  :)


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on September 02, 2014, 09:28:46 PM
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.  :D
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?


Title: Re: How (and why) to use the Relay Network
Post by: DrHaribo on September 02, 2014, 10:53:21 PM
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?


Title: Re: How (and why) to use the Relay Network
Post by: DrHaribo on September 02, 2014, 10:54:32 PM
Would something similar to this relay network be useful for the p2pool share chain?


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on September 02, 2014, 11:28:17 PM
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.


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on September 02, 2014, 11:28:40 PM
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.


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on September 02, 2014, 11:29:16 PM
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?


Title: Re: How (and why) to use the Relay Network
Post by: -ck on September 02, 2014, 11:40:09 PM
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.


Title: Re: How (and why) to use the Relay Network
Post by: gmaxwell on September 03, 2014, 01:15:36 AM
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)


Title: Re: How (and why) to use the Relay Network
Post by: DrHaribo on September 03, 2014, 07:10:12 AM
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.


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on September 03, 2014, 08:22:11 AM
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.


Title: Re: How (and why) to use the Relay Network
Post by: DrHaribo on September 03, 2014, 10:39:06 AM
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.


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on September 03, 2014, 11:27:16 AM
There were a few major updates and both clients should update...The java client had a rather dumb bug that prevented it from relying outgoing blocks, though it received them fine...the python client was, as is all python, so horrendously non-performant that even a network rtt for a inv->getdata->block process to be faster. With some minor effort the python client now should reliably beat network rtts (seriously python???), though I'd advise using the java client where possible.


Title: Re: How (and why) to use the Relay Network
Post by: PatMan on September 03, 2014, 05:57:46 PM
Damn that java - I just uninstalled it too........


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on September 03, 2014, 06:02:35 PM
Damn that java - I just uninstalled it too........
Well, if you really wanted the python version you could use Jython, but then you're stuck with java anyway...I may benchmark pypy later and see if it helps but early testing shows its ~as fast.


Title: Re: How (and why) to use the Relay Network
Post by: PatMan on September 03, 2014, 06:06:02 PM
Really? That surprises me, I've never used pypy but have heard it's much faster than std python.......


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on September 03, 2014, 06:09:48 PM
Really? That surprises me, I've never used pypy but have heard it's much faster than std python.......
Well, its a JIT, and my tests may simply not have been long-running enough to give it sufficient warm-up time.


Title: Re: How (and why) to use the Relay Network
Post by: spiccioli on September 03, 2014, 07:51:30 PM
Really? That surprises me, I've never used pypy but have heard it's much faster than std python.......
Well, its a JIT, and my tests may simply not have been long-running enough to give it sufficient warm-up time.

Hi,

I came to the same conclusions running p2pool long ago on pypy, it is as fast as python.

See here, for example. (https://bitcointalk.org/index.php?topic=18313.msg8659415#msg8659415)

spiccioli


Title: Re: How (and why) to use the Relay Network
Post by: -ck on September 03, 2014, 10:07:28 PM
There were a few major updates and both clients should update...The java client had a rather dumb bug that prevented it from relying outgoing blocks, though it received them fine...the python client was, as is all python, so horrendously non-performant that even a network rtt for a inv->getdata->block process to be faster. With some minor effort the python client now should reliably beat network rtts (seriously python???), though I'd advise using the java client where possible.
Upgraded, thanks. I did notice messages in both directions now instead of before on the java client.


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on September 06, 2014, 06:03:42 AM
There is now a C++ client. Those who had been using the python client should probably switch to it (its semantics are identical, it runs on Linux and under Wine, so I assume Windows) and it is much, much faster than the python client.


Title: Re: How (and why) to use the Relay Network
Post by: PatMan on September 06, 2014, 10:07:21 AM
Great stuff Matt! Testing now....... :)


Title: Re: How (and why) to use the Relay Network
Post by: jedimstr on September 06, 2014, 03:37:13 PM
There is now a C++ client. Those who had been using the python client should probably switch to it (its semantics are identical, it runs on Linux and under Wine, so I assume Windows) and it is much, much faster than the python client.

Any chance you or someone else could port/compile/brew a Mac C++ version?

I tried porting and compiling myself but all the includes FUBAR'd the attempt. Or, I just need more coffee before I try again.

Been running the Java client for awhile now, but can we get the jar added to the Git Repository too alongside the other clients? It'll make keeping up-to-date much easier.


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on September 06, 2014, 08:45:30 PM
Any chance you or someone else could port/compile/brew a Mac C++ version?

I tried porting and compiling myself but all the includes FUBAR'd the attempt. Or, I just need more coffee before I try again.
Hmm, yea, I assume one or more of the socket calls isnt right? I didnt try it on any BSD. Also, it needs C++11, so if the version of clang OSX ships is particularly out-of-date it may fail there too...I'm happy to help test it if you can get me a list of compile errors.


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on September 06, 2014, 08:59:41 PM
Been running the Java client for awhile now, but can we get the jar added to the Git Repository too alongside the other clients? It'll make keeping up-to-date much easier.
Done.


Title: Re: How (and why) to use the Relay Network
Post by: DrHaribo on September 06, 2014, 09:14:05 PM
Is there a maven repo I need to add to build the java client? It's not finding the required bitcoinj version.

Code:
Missing:
----------
1) com.google:bitcoinj:jar:0.12-SNAPSHOT_nodelay


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on September 06, 2014, 09:31:56 PM
Is there a maven repo I need to add to build the java client? It's not finding the required bitcoinj version.

Code:
Missing:
----------
1) com.google:bitcoinj:jar:0.12-SNAPSHOT_nodelay

If you're building the java client direct from source, it wants the branch at https://github.com/TheBlueMatt/bitcoinj/tree/nodelay (https://github.com/TheBlueMatt/bitcoinj/tree/nodelay). The only real difference is it sets TCP_NODELAY.


Title: Re: How (and why) to use the Relay Network
Post by: IYFTech on September 06, 2014, 11:44:37 PM
Hi Matt,

Sorry to go a bit off topic, but I was looking at your git repo & noticed you've worked on TextSecure. I've been using it for several weeks now - it's great work! Well done & kudos to you  :)

Sorry guys, carry on....... ;)


Title: Re: How (and why) to use the Relay Network
Post by: DrHaribo on September 07, 2014, 07:04:15 PM
If you're building the java client direct from source, it wants the branch at https://github.com/TheBlueMatt/bitcoinj/tree/nodelay (https://github.com/TheBlueMatt/bitcoinj/tree/nodelay). The only real difference is it sets TCP_NODELAY.

Got it. Had to add _nodelay to the version in core/pom.xml so the RelayClient would find it after "mvn install". Strangely the tests for bitcoinj fail if you run them twice without "mvn clean". At least they did for me. But I guess that's a problem with the tests, not the library itself.

Perhaps it's an idea for pools to set up direct peering? Could shave off a little time.

Is it OK to pass new blocks directly to the RelayNodeClient instead of passing them through the local bitcoind ? Could shave off a little bit more time.


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on September 08, 2014, 01:16:30 AM
Got it. Had to add _nodelay to the version in core/pom.xml so the RelayClient would find it after "mvn install". Strangely the tests for bitcoinj fail if you run them twice without "mvn clean". At least they did for me. But I guess that's a problem with the tests, not the library itself.

Perhaps it's an idea for pools to set up direct peering? Could shave off a little time.

Is it OK to pass new blocks directly to the RelayNodeClient instead of passing them through the local bitcoind ? Could shave off a little bit more time.

If you used that branch it should already have had _nodelay added to its version number (and you should probably use that branch of your OS may hold onto data before relaying it for some time).

re: direct peering: sure, pools could do this (most already do afaiu).

Sure, no harm in passing a block out quickly, but this is also why you should treat blocks that come from the relay network identically as some arbitrary blocks you get from an unknown source on the p2p network. See, for example, the for-w branch at https://github.com/TheBlueMatt/RelayNode/tree/for-w/client (https://github.com/TheBlueMatt/RelayNode/tree/for-w/client) which I whipped up for another poolop so that they could peer a single relay network client with a ton of local pool daemons and have it properly route blocks that come in from the relay network to their bitcoind and from one of their pool daemons to all the other pool daemons and the relay network all at once.


Title: Re: How (and why) to use the Relay Network
Post by: DrHaribo on September 08, 2014, 09:36:31 PM
If you used that branch it should already have had _nodelay added to its version number (and you should probably use that branch of your OS may hold onto data before relaying it for some time).

Sorry, I forgot to switch to the nodelay branch.

re: direct peering: sure, pools could do this (most already do afaiu).

Yeah, but I meant with the relay software, running a RelayNode instead of a RelayClientNode. Not sure how much there is to save there, but there may be something.


Title: Re: How (and why) to use the Relay Network
Post by: norgan on September 13, 2014, 08:28:32 AM
I've downloaded the exe client and am running it with "D:\Temp\relay\relaynetworkclient.exe public.au.relay.mattcorallo.com 127.0.0.1 8333" but I just get the following:

Closing bitcoind socket, failed to connect() (10049: Unknown error)
Closing relay socket, failed to connect() (10049: Unknown error)
Closing bitcoind socket, failed to connect() (10049: Unknown error)
Closing relay socket, failed to connect() (10049: Unknown error)
Closing bitcoind socket, failed to connect() (10049: Unknown error)
Closing relay socket, failed to connect() (10049: Unknown error)
Closing bitcoind socket, failed to connect() (10049: Unknown error)
Closing relay socket, failed to connect() (10049: Unknown error)
Closing bitcoind socket, failed to connect() (10049: Unknown error)
Closing relay socket, failed to connect() (10049: Unknown error)
Closing bitcoind socket, failed to connect() (10049: Unknown error)
Closing relay socket, failed to connect() (10049: Unknown error)
Closing bitcoind socket, failed to connect() (10049: Unknown error)

What am I doing wrong?


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on September 13, 2014, 08:45:31 PM
I've downloaded the exe client and am running it with "D:\Temp\relay\relaynetworkclient.exe public.au.relay.mattcorallo.com 127.0.0.1 8333" but I just get the following:

Closing bitcoind socket, failed to connect() (10049: Unknown error)
Closing relay socket, failed to connect() (10049: Unknown error)

What am I doing wrong?

10049 == WSAEADDRNOTAVAIL according to http://msdn.microsoft.com/en-us/library/windows/desktop/ms740668(v=vs.85).aspx (http://msdn.microsoft.com/en-us/library/windows/desktop/ms740668(v=vs.85).aspx). Any chance you're still on XP or have IPv6 explicitly disabled somewhere, which I think I might have broken in a recent push.


Title: Re: How (and why) to use the Relay Network
Post by: norgan on September 13, 2014, 09:01:51 PM
I've downloaded the exe client and am running it with "D:\Temp\relay\relaynetworkclient.exe public.au.relay.mattcorallo.com 127.0.0.1 8333" but I just get the following:

Closing bitcoind socket, failed to connect() (10049: Unknown error)
Closing relay socket, failed to connect() (10049: Unknown error)

What am I doing wrong?

10049 == WSAEADDRNOTAVAIL according to http://msdn.microsoft.com/en-us/library/windows/desktop/ms740668(v=vs.85).aspx (http://msdn.microsoft.com/en-us/library/windows/desktop/ms740668(v=vs.85).aspx). Any chance you're still on XP or have IPv6 explicitly disabled somewhere, which I think I might have broken in a recent push.
It's server 2012 r2. I don't think ipv6 is disabled but I'll check.


Title: Re: How (and why) to use the Relay Network
Post by: norgan on September 13, 2014, 09:13:14 PM
I've downloaded the exe client and am running it with "D:\Temp\relay\relaynetworkclient.exe public.au.relay.mattcorallo.com 127.0.0.1 8333" but I just get the following:

Closing bitcoind socket, failed to connect() (10049: Unknown error)
Closing relay socket, failed to connect() (10049: Unknown error)

What am I doing wrong?

10049 == WSAEADDRNOTAVAIL according to http://msdn.microsoft.com/en-us/library/windows/desktop/ms740668(v=vs.85).aspx (http://msdn.microsoft.com/en-us/library/windows/desktop/ms740668(v=vs.85).aspx). Any chance you're still on XP or have IPv6 explicitly disabled somewhere, which I think I might have broken in a recent push.
It's server 2012 r2. I don't think ipv6 is disabled but I'll check.
It was disabled. Now its enabled but not configured and I still get the same error. I left it running overnight and it started blocking my bitcoind connection and took my node offline.


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on September 13, 2014, 11:14:55 PM
It was disabled. Now its enabled but not configured and I still get the same error. I left it running overnight and it started blocking my bitcoind connection and took my node offline.
Might've missed a windows flag, try again with the latest version?


Title: Re: How (and why) to use the Relay Network
Post by: norgan on September 13, 2014, 11:37:08 PM
It was disabled. Now its enabled but not configured and I still get the same error. I left it running overnight and it started blocking my bitcoind connection and took my node offline.
Might've missed a windows flag, try again with the latest version?

Yup, working now. So I just run it along side p2pool and bitcoind right?


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on September 14, 2014, 01:22:02 AM
Yup, working now. So I just run it along side p2pool and bitcoind right?
Yupyup, just run and point to nearest relay node and bitcoind.


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on September 14, 2014, 02:02:29 AM
Added a list of pools to the second post, respond if you want added to the list.


Title: Re: How (and why) to use the Relay Network
Post by: norgan on September 14, 2014, 07:19:13 AM
Added a list of pools to the second post, respond if you want added to the list.

Norgzpool AU pool now running relay. will add to Singapore node as well shortly.

Matt, do you need an Australian server? I have a 50mbit Fibre link that I could run a server behind, in the next month or two i'll have some Azure compute in AU also.


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on September 14, 2014, 09:01:55 AM
Norgzpool AU pool now running relay. will add to Singapore node as well shortly.

Matt, do you need an Australian server? I have a 50mbit Fibre link that I could run a server behind, in the next month or two i'll have some Azure compute in AU also.
Hmm, for now I think I'm gonna avoid listing every public p2pool node or pools without at least a few hundred THash/s mining on them.


Title: Re: How (and why) to use the Relay Network
Post by: norgan on September 14, 2014, 09:04:49 AM
Norgzpool AU pool now running relay. will add to Singapore node as well shortly.

Matt, do you need an Australian server? I have a 50mbit Fibre link that I could run a server behind, in the next month or two i'll have some Azure compute in AU also.
Hmm, for now I think I'm gonna avoid listing every public p2pool node or pools without at least a few hundred THash/s mining on them.

yeah fair enough, I looked at the list after and realised it was more pools rather than nodes. no probs.


Title: Re: How (and why) to use the Relay Network
Post by: smoothrunnings on September 17, 2014, 12:58:10 AM
I've downloaded the exe client and am running it with "D:\Temp\relay\relaynetworkclient.exe public.au.relay.mattcorallo.com 127.0.0.1 8333" but I just get the following:

Closing bitcoind socket, failed to connect() (10049: Unknown error)
Closing relay socket, failed to connect() (10049: Unknown error)

What am I doing wrong?

10049 == WSAEADDRNOTAVAIL according to http://msdn.microsoft.com/en-us/library/windows/desktop/ms740668(v=vs.85).aspx (http://msdn.microsoft.com/en-us/library/windows/desktop/ms740668(v=vs.85).aspx). Any chance you're still on XP or have IPv6 explicitly disabled somewhere, which I think I might have broken in a recent push.
It's server 2012 r2. I don't think ipv6 is disabled but I'll check.
It was disabled. Now its enabled but not configured and I still get the same error. I left it running overnight and it started blocking my bitcoind connection and took my node offline.

Disable the firewall.


Title: Re: How (and why) to use the Relay Network
Post by: norgan on September 17, 2014, 01:02:08 AM
I've downloaded the exe client and am running it with "D:\Temp\relay\relaynetworkclient.exe public.au.relay.mattcorallo.com 127.0.0.1 8333" but I just get the following:

Closing bitcoind socket, failed to connect() (10049: Unknown error)
Closing relay socket, failed to connect() (10049: Unknown error)

What am I doing wrong?

10049 == WSAEADDRNOTAVAIL according to http://msdn.microsoft.com/en-us/library/windows/desktop/ms740668(v=vs.85).aspx (http://msdn.microsoft.com/en-us/library/windows/desktop/ms740668(v=vs.85).aspx). Any chance you're still on XP or have IPv6 explicitly disabled somewhere, which I think I might have broken in a recent push.
It's server 2012 r2. I don't think ipv6 is disabled but I'll check.
It was disabled. Now its enabled but not configured and I still get the same error. I left it running overnight and it started blocking my bitcoind connection and took my node offline.

Disable the firewall.

nah it was a broken build. the firewall was off :)


Title: Re: How (and why) to use the Relay Network
Post by: norgan on September 17, 2014, 04:10:18 AM
So far so good! 4 good blocks no orphan and no stale. (small I know) it's been tricky in AU to find good peers to reduce orphan blocks but this may be a good way to bring some of that latency.


Title: Re: How (and why) to use the Relay Network
Post by: jonnybravo0311 on September 17, 2014, 02:41:07 PM
Hey Matt,

I ran into a problem running the c++ client today.  I did a git pull and rebuilt; however, when I started it up, I ran into this:
Code:
miner@devildog:~/RelayNode/client$ ./relaynetworkclient public.us-east.relay.mattcorallo.com 127.0.0.1 8333
terminate called after throwing an instance of 'std::system_error'
  what():  Enable multithreading to use std::thread: Operation not permitted
Aborted (core dumped)

I had to tweak the make.sh script as follows:
Code:
g++ $DEFINES -std=c++11 -Wl,--no-as-needed -Wall -I. -I/usr/include ./client.cpp ./flaggedarrayset.cpp ./utils.cpp ./p2pclient.cpp ./crypto/sha2.cpp -o relaynetworkclient -pthread

Notice the inclusion of the "-Wl,--no-as-needed".  There's apparently a known bug with gcc and Ubuntu: https://bugs.launchpad.net/ubuntu/+source/gcc-defaults/+bug/1228201.

Anyway, if anyone is having an issue getting the c++ client running on Ubuntu 14.04 LTS, editing the make.sh script as I have above, and recompiling the client will solve your problems.


Title: Re: How (and why) to use the Relay Network
Post by: cypherdoc on September 20, 2014, 08:03:47 PM
Anyone know if Btcguild is running a relay node? 


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on September 20, 2014, 08:06:31 PM
Anyone know if Btcguild is running a relay node? 
Read the second post ;)


Title: Re: How (and why) to use the Relay Network
Post by: amaclin on September 21, 2014, 06:28:35 PM
what port does relaynetwork use?
8335 or 8336?


Title: Re: How (and why) to use the Relay Network
Post by: norgan on September 21, 2014, 11:42:06 PM
Matt, looks like you have an issue with the SG node.


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on September 22, 2014, 05:58:31 AM
what port does relaynetwork use?
8335 or 8336?
8336

Matt, looks like you have an issue with the SG node.
Strange, can you double-check now...there was a bug due to bitcoind banning relay servers...


Title: Re: How (and why) to use the Relay Network
Post by: norgan on September 22, 2014, 05:59:28 AM
what port does relaynetwork use?
8335 or 8336?
8336

Matt, looks like you have an issue with the SG node.
Strange, can you double-check now...there was a bug due to bitcoind banning relay servers...

looks fine now, thanks.


Title: Re: How (and why) to use the Relay Network
Post by: mdude77 on September 23, 2014, 09:54:43 AM
I've downloaded the exe client and am running it with "D:\Temp\relay\relaynetworkclient.exe public.au.relay.mattcorallo.com 127.0.0.1 8333" but I just get the following:

Closing bitcoind socket, failed to connect() (10049: Unknown error)
Closing relay socket, failed to connect() (10049: Unknown error)
Closing bitcoind socket, failed to connect() (10049: Unknown error)
Closing relay socket, failed to connect() (10049: Unknown error)
Closing bitcoind socket, failed to connect() (10049: Unknown error)
Closing relay socket, failed to connect() (10049: Unknown error)
Closing bitcoind socket, failed to connect() (10049: Unknown error)
Closing relay socket, failed to connect() (10049: Unknown error)
Closing bitcoind socket, failed to connect() (10049: Unknown error)
Closing relay socket, failed to connect() (10049: Unknown error)
Closing bitcoind socket, failed to connect() (10049: Unknown error)
Closing relay socket, failed to connect() (10049: Unknown error)
Closing bitcoind socket, failed to connect() (10049: Unknown error)

What am I doing wrong?

I'm getting this too with the windows exe client on Win7.  It eventually killed my TCP/IP stack, all programs were getting TCP/IP errors until I killed the relay client.

Going back to the python version here.

M


Title: Re: How (and why) to use the Relay Network
Post by: norgan on September 23, 2014, 10:02:54 AM
I've downloaded the exe client and am running it with "D:\Temp\relay\relaynetworkclient.exe public.au.relay.mattcorallo.com 127.0.0.1 8333" but I just get the following:

Closing bitcoind socket, failed to connect() (10049: Unknown error)
Closing relay socket, failed to connect() (10049: Unknown error)
Closing bitcoind socket, failed to connect() (10049: Unknown error)
Closing relay socket, failed to connect() (10049: Unknown error)
Closing bitcoind socket, failed to connect() (10049: Unknown error)
Closing relay socket, failed to connect() (10049: Unknown error)
Closing bitcoind socket, failed to connect() (10049: Unknown error)
Closing relay socket, failed to connect() (10049: Unknown error)
Closing bitcoind socket, failed to connect() (10049: Unknown error)
Closing relay socket, failed to connect() (10049: Unknown error)
Closing bitcoind socket, failed to connect() (10049: Unknown error)
Closing relay socket, failed to connect() (10049: Unknown error)
Closing bitcoind socket, failed to connect() (10049: Unknown error)

What am I doing wrong?

I'm getting this too with the windows exe client on Win7.  It eventually killed my TCP/IP stack, all programs were getting TCP/IP errors until I killed the relay client.

Going back to the python version here.

M
It was a broken build, have you tried the latest? Also try disabling ipv6


Title: Re: How (and why) to use the Relay Network
Post by: mdude77 on September 23, 2014, 11:43:45 AM
I've downloaded the exe client and am running it with "D:\Temp\relay\relaynetworkclient.exe public.au.relay.mattcorallo.com 127.0.0.1 8333" but I just get the following:

Closing bitcoind socket, failed to connect() (10049: Unknown error)
Closing relay socket, failed to connect() (10049: Unknown error)
Closing bitcoind socket, failed to connect() (10049: Unknown error)
Closing relay socket, failed to connect() (10049: Unknown error)
Closing bitcoind socket, failed to connect() (10049: Unknown error)
Closing relay socket, failed to connect() (10049: Unknown error)
Closing bitcoind socket, failed to connect() (10049: Unknown error)
Closing relay socket, failed to connect() (10049: Unknown error)
Closing bitcoind socket, failed to connect() (10049: Unknown error)
Closing relay socket, failed to connect() (10049: Unknown error)
Closing bitcoind socket, failed to connect() (10049: Unknown error)
Closing relay socket, failed to connect() (10049: Unknown error)
Closing bitcoind socket, failed to connect() (10049: Unknown error)

What am I doing wrong?

I'm getting this too with the windows exe client on Win7.  It eventually killed my TCP/IP stack, all programs were getting TCP/IP errors until I killed the relay client.

Going back to the python version here.

M
It was a broken build, have you tried the latest? Also try disabling ipv6

I got it from github, I assume it's the latest.

M


Title: Re: How (and why) to use the Relay Network
Post by: mdude77 on September 23, 2014, 12:23:54 PM
Nevermind.  I forgot my bitcoin port isn't default, so it was pounding 8333 and there wasn't anything there to respond.

:)

M


Title: Re: How (and why) to use the Relay Network
Post by: simdude on September 28, 2014, 11:54:22 AM
I love this concept. I start running the windows version on my windows based p2pool. If you get around to building a exe for relay enabled p2pool i would love to test it out.


Title: Re: How (and why) to use the Relay Network
Post by: -ck on September 29, 2014, 02:18:36 PM
Having issues with the c++ client receiving anything in the last day connecting to us-west without any other changes. Tried restarting and getting repeated
Code:
Closing relay socket, failed to read message header (104: Connection reset by peer)


Title: Re: How (and why) to use the Relay Network
Post by: IYFTech on September 29, 2014, 02:20:33 PM
Having issues with the c++ client receiving anything in the last day connecting to us-west without any other changes. Tried restarting and getting repeated
Code:
Closing relay socket, failed to read message header (104: Connection reset by peer)

The eu server is working well - have you tried that one?  :)


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on September 29, 2014, 04:56:43 PM
Having issues with the c++ client receiving anything in the last day connecting to us-west without any other changes. Tried restarting and getting repeated
Code:
Closing relay socket, failed to read message header (104: Connection reset by peer)

Hmm, I dont see anything in my logs...Is it working now and/or can you pm me the IP you're connecting from?


Title: Re: How (and why) to use the Relay Network
Post by: -ck on September 29, 2014, 09:49:53 PM
Having issues with the c++ client receiving anything in the last day connecting to us-west without any other changes. Tried restarting and getting repeated
Code:
Closing relay socket, failed to read message header (104: Connection reset by peer)

Hmm, I dont see anything in my logs...Is it working now and/or can you pm me the IP you're connecting from?
It's still there. I've PMed you where from.

EDIT: It just started working again. Beats me  ???


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on September 29, 2014, 10:01:22 PM
EDIT: It just started working again. Beats me  ???

I was fuxing with it.


Title: Re: How (and why) to use the Relay Network
Post by: simdude on October 01, 2014, 03:39:45 AM
I am still getting the Closing relay socket, failed to read message header (10054: Unknown error)


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on October 01, 2014, 05:12:09 AM
I am still getting the Closing relay socket, failed to read message header (10054: Unknown error)
What node are you connecting to? All nodes seem to be working from here. If you are connect multiple times from the same external IP, this is expected behavior as having multiple connections will decrease your relay time by a huge margin because, in my tests, the most important thing is packet loss requiring extra RTTs for TCP retransmits (if you're behind ISP level NAT I think I can just flip the switch on IPv6 for most of the nodes, just need to actually test the clients to make sure they wont flip).


Title: Re: How (and why) to use the Relay Network
Post by: simdude on October 01, 2014, 11:47:06 AM
Hello,

     public.us-east


Title: Re: How (and why) to use the Relay Network
Post by: amaclin on October 01, 2014, 11:57:38 AM
Quote
public.us-east

us-east and us-west work right now as I see
(us-west had some troubles in the past)


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on October 01, 2014, 06:55:42 PM
public.us-east
I dont see any issues there, can you PM me the IP you're connecting from?


Title: Re: How (and why) to use the Relay Network
Post by: norgan on October 06, 2014, 10:05:22 AM
Seeing issues on the sg node again. Had to change to west-us


Title: Re: How (and why) to use the Relay Network
Post by: amaclin on October 06, 2014, 10:26:42 AM
Seeing issues on the sg node again. Had to change to west-us

us-west does not work from my side right now
I use us-east


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on October 06, 2014, 08:51:09 PM
Ugh, yes, there appear to have been some issues that went unnoticed over the past week or so, should be all good now and I'm monitoring for further hiccups until I can go in and debug a bit more.


Title: Re: How (and why) to use the Relay Network
Post by: norgan on October 08, 2014, 03:28:20 AM
Ugh, yes, there appear to have been some issues that went unnoticed over the past week or so, should be all good now and I'm monitoring for further hiccups until I can go in and debug a bit more.
au/sg working now.

Would there be any negative impact of running two relays to two different relay servers? so if one went down the other would still relay blocks...


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on October 08, 2014, 03:32:01 AM
Ugh, yes, there appear to have been some issues that went unnoticed over the past week or so, should be all good now and I'm monitoring for further hiccups until I can go in and debug a bit more.
au/sg working now.

Would there be any negative impact of running two relays to two different relay servers? so if one went down the other would still relay blocks...
Seems several servers were all hit with the same bug at nearly the same time. Still need to look into it, but for this case, it appears that would not have helped. Still, no, that would probably not be a negative.


Title: Re: How (and why) to use the Relay Network
Post by: spin on October 13, 2014, 02:40:14 PM
Under the C++ folder I see a make script for 5 components (including a windows client).  I am happy with how the client is used and managed to get it going.

Can you perhaps share how the other components could be used to build a relay network? I am not really proficient at reading c++.

My guesses:
relaynetworkproxy -> Connects two relay nodes (both on port 8336).
relaynetworkterminator -> Seems to provide the 8334 and 8335 tx and block only feeds?
relaynetworkoutbound -> Connects a bitcoind and a something on port 8334?
relaynetworkserver -> connects to a trusted bitcoind? Also serves clients?  Also connects to something local on port 8334? I kept getting connection refused to the local bitcoind when I ran it.


Happy to assist with a readme on your github if needs be.


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on October 13, 2014, 04:54:21 PM
Under the C++ folder I see a make script for 5 components (including a windows client).  I am happy with how the client is used and managed to get it going.

Can you perhaps share how the other components could be used to build a relay network? I am not really proficient at reading c++.

My guesses:
relaynetworkproxy -> Connects two relay nodes (both on port 8336).
relaynetworkterminator -> Seems to provide the 8334 and 8335 tx and block only feeds?
relaynetworkoutbound -> Connects a bitcoind and a something on port 8334?
relaynetworkserver -> connects to a trusted bitcoind? Also serves clients?  Also connects to something local on port 8334? I kept getting connection refused to the local bitcoind when I ran it.


Happy to assist with a readme on your github if needs be.

proxy/terminator are correct.
outbound connects to terminator on 8334 and a remote (untrusted) bitcoind.
server connects to a trusted bitcoind to decide which txn to relay, connects to terminator to get/private a data feed from untrusted bitcoinds and also listens on 8336 for relay clients.


Title: Re: How (and why) to use the Relay Network
Post by: naplam on October 13, 2014, 09:16:05 PM
Having issues with the c++ client receiving anything in the last day connecting to us-west without any other changes. Tried restarting and getting repeated
Code:
Closing relay socket, failed to read message header (104: Connection reset by peer)
Same here with us-east now. Us-west seems to work fine at this time.


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on October 13, 2014, 11:34:30 PM
Same here with us-east now. Us-west seems to work fine at this time.
Now?


Title: Re: How (and why) to use the Relay Network
Post by: norgan on October 14, 2014, 07:57:17 AM
Same here with us-east now. Us-west seems to work fine at this time.
Now?
yup same with Singapore node. both my p2pool nodes have out of cache errors as well.


Title: Re: How (and why) to use the Relay Network
Post by: PatMan on October 14, 2014, 09:00:11 AM
EU node trotting along nicely.......


Title: Re: How (and why) to use the Relay Network
Post by: spin on October 14, 2014, 01:18:19 PM
So to build a relaynetwork between two nodes one could do the following:

Node 1: 10.0.0.1
bitcoind
relaynetworkserver
relaynetworkproxy 127.0.0.1 10.0.0.2


Node 2: 10.0.0.2
bitcoind
relaynetworkserver 127.0.0.1 8333


On node 2 I could also just run the relaynetworkclient also.
On node 1 (or 2) I could also add a relaynetworkproxy 127.0.0.1  public.REGION.relay.mattcorallo.com to connect to your network?

Questions:
Would the server also updated the local bitcoind with new tx/blocks?
Do I need the terminator at each node also?  The servers shows less errors when it is running?
Also let me know if you are not happy with me trying this out.


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on October 14, 2014, 08:03:37 PM
yup same with Singapore node. both my p2pool nodes have out of cache errors as well.
Seems to be a bug when run for too long they start disconnecting new peers with that...I'm trying to figure out why, but, for now, they should all work atm.


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on October 14, 2014, 08:07:06 PM
So to build a relaynetwork between two nodes one could do the following:

Node 1: 10.0.0.1
bitcoind
relaynetworkserver
relaynetworkproxy 127.0.0.1 10.0.0.2


Node 2: 10.0.0.2
bitcoind
relaynetworkserver 127.0.0.1 8333


On node 2 I could also just run the relaynetworkclient also.
On node 1 (or 2) I could also add a relaynetworkproxy 127.0.0.1  public.REGION.relay.mattcorallo.com to connect to your network?

Questions:
Would the server also updated the local bitcoind with new tx/blocks?
Do I need the terminator at each node also?  The servers shows less errors when it is running?
Also let me know if you are not happy with me trying this out.

Why not just run two relay node clients from your different nodes? If they're on the same network (or very close to each other, ie you can just be running a regular bitcoin p2p connection between them, try the branch at https://github.com/TheBlueMatt/RelayNode/tree/for-w (https://github.com/TheBlueMatt/RelayNode/tree/for-w), which has code to connect to multiple local mining pool instances and relay between them and to the relay network, with a full bitcoind receiving blocks/txn from the network.


Title: Re: How (and why) to use the Relay Network
Post by: DrHaribo on October 14, 2014, 08:51:58 PM
Will new versions of the relay client be announced somewhere? (here maybe?)


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on October 14, 2014, 09:02:33 PM
Will new versions of the relay client be announced somewhere? (here maybe?)
Major updates will, yes.


Title: Re: How (and why) to use the Relay Network
Post by: norgan on October 15, 2014, 02:48:33 AM
yup same with Singapore node. both my p2pool nodes have out of cache errors as well.
Seems to be a bug when run for too long they start disconnecting new peers with that...I'm trying to figure out why, but, for now, they should all work atm.

it seems to cause p2pool to fall over as well. thats anecdotal of course so can't say for sure but the syptoms seem to line up on both nodes.


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on October 15, 2014, 03:53:16 AM
yup same with Singapore node. both my p2pool nodes have out of cache errors as well.
Seems to be a bug when run for too long they start disconnecting new peers with that...I'm trying to figure out why, but, for now, they should all work atm.

it seems to cause p2pool to fall over as well. thats anecdotal of course so can't say for sure but the syptoms seem to line up on both nodes.
This one makes no sense...The way it was integrated into p2pool was to just kick off a thread and let it connect to bitcoind (not even to p2pool). Unless it hung python or hung your bitcoind, I dont see how this is possible.


Title: Re: How (and why) to use the Relay Network
Post by: norgan on October 15, 2014, 03:55:13 AM
yup same with Singapore node. both my p2pool nodes have out of cache errors as well.
Seems to be a bug when run for too long they start disconnecting new peers with that...I'm trying to figure out why, but, for now, they should all work atm.

it seems to cause p2pool to fall over as well. thats anecdotal of course so can't say for sure but the syptoms seem to line up on both nodes.
This one makes no sense...The way it was integrated into p2pool was to just kick off a thread and let it connect to bitcoind (not even to p2pool). Unless it hung python or hung your bitcoind, I dont see how this is possible.
yeah liek i said anecdotal, i wanted to be clear on that. I'll do some more testing.


Title: Re: How (and why) to use the Relay Network
Post by: -ck on October 15, 2014, 09:25:18 AM
Running of the c++ client now fails to run on linux due to the position of the -pthread linking with the error:
Code:
terminate called after throwing an instance of 'std::system_error'
what():  Enable multithreading to use std::thread: Operation not permitte

Repositioning the -pthread here makes it work:
Code:
g++ -std=c++11 -Wall -I. -I/usr/include ./client.cpp -pthread ./flaggedarrayset.cpp ./utils.cpp ./p2pclient.cpp ./crypto/sha2.cpp -o relaynetworkclient

Probably should at least add -O2 to default build too


Title: Re: How (and why) to use the Relay Network
Post by: naplam on October 15, 2014, 12:15:04 PM
yup same with Singapore node. both my p2pool nodes have out of cache errors as well.
Seems to be a bug when run for too long they start disconnecting new peers with that...I'm trying to figure out why, but, for now, they should all work atm.
Are you hitting the maximum sockets limit or something? maybe you could restart them automatically every day or so for the time being


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on October 16, 2014, 02:31:25 AM
Are you hitting the maximum sockets limit or something? maybe you could restart them automatically every day or so for the time being
No, the issue y'all are seeing is that, if the thread handling the trusted bitcoind hangs or otherwise dies, it cant do its async connection reaping and, thus, people get disconnected as duplicate connections from the same IP if their connection gets reset somehow...Of course to fix this I need to actually figure out why its hanging/deadlocking/dying...


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on October 16, 2014, 02:43:43 AM
Running of the c++ client now fails to run on linux due to the position of the -pthread linking with the error:
Code:
terminate called after throwing an instance of 'std::system_error'
what():  Enable multithreading to use std::thread: Operation not permitte

Repositioning the -pthread here makes it work:
Code:
g++ -std=c++11 -Wall -I. -I/usr/include ./client.cpp -pthread ./flaggedarrayset.cpp ./utils.cpp ./p2pclient.cpp ./crypto/sha2.cpp -o relaynetworkclient

Probably should at least add -O2 to default build too
Huh? Which branch are you building from???
Master is https://github.com/TheBlueMatt/RelayNode/blob/master/c%2B%2B/make.sh which (unless you run with ./make test) has DEFINES set to -O2 and -flto, and -pthread is before any code?


Title: Re: How (and why) to use the Relay Network
Post by: -ck on October 16, 2014, 02:47:30 AM
Running of the c++ client now fails to run on linux due to the position of the -pthread linking with the error:
Code:
terminate called after throwing an instance of 'std::system_error'
what():  Enable multithreading to use std::thread: Operation not permitte

Repositioning the -pthread here makes it work:
Code:
g++ -std=c++11 -Wall -I. -I/usr/include ./client.cpp -pthread ./flaggedarrayset.cpp ./utils.cpp ./p2pclient.cpp ./crypto/sha2.cpp -o relaynetworkclient

Probably should at least add -O2 to default build too
Huh? Which branch are you building from???
Master is https://github.com/TheBlueMatt/RelayNode/blob/master/c%2B%2B/make.sh which (unless you run with ./make test) has DEFINES set to -O2 and -flto, and -pthread is before any code?
Oops, I didn't spot the defines. However -pthread has to be after client.cpp for it to work.


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on October 16, 2014, 03:08:44 AM
Oops, I didn't spot the defines. However -pthread has to be after client.cpp for it to work.
Oh after, ok, willdo.


Title: Re: How (and why) to use the Relay Network
Post by: naplam on October 16, 2014, 11:23:01 AM
yep, -phread after works


Title: Re: How (and why) to use the Relay Network
Post by: Paladin45 on October 18, 2014, 05:56:31 PM
I'm trying this with P2Pool and Armory, Linux Mint 17 64-bit. I'm seeing "Unable to resolve relay peer hostname" messages in the terminal window. Are these errors or normal operation?


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on October 18, 2014, 08:49:42 PM
I'm trying this with P2Pool and Armory, Linux Mint 17 64-bit. I'm seeing "Unable to resolve relay peer hostname" messages in the terminal window. Are these errors or normal operation?
Sounds like you mis-typed the relay node server (or your DNS is messed up)?


Title: Re: How (and why) to use the Relay Network
Post by: Paladin45 on October 18, 2014, 09:12:58 PM
I'm trying this with P2Pool and Armory, Linux Mint 17 64-bit. I'm seeing "Unable to resolve relay peer hostname" messages in the terminal window. Are these errors or normal operation?
Sounds like you mis-typed the relay node server (or your DNS is messed up)?

Yep. I missed the "relay" in the address string. Checked it a couple of times before I posted, but missed both times. Thank you!


Title: Re: How (and why) to use the Relay Network
Post by: spin on October 21, 2014, 11:06:27 PM
Getting lots of
Code:
Closing relay socket, failed to read message header (0: )
Closing relay socket, failed to read message header (104: Connection reset by peer)

On the EU node.  us-east working fine for me.


Title: Re: How (and why) to use the Relay Network
Post by: PatMan on October 22, 2014, 06:55:38 PM
Getting lots of
Code:
Closing relay socket, failed to read message header (0: )
Closing relay socket, failed to read message header (104: Connection reset by peer)

On the EU node.  us-east working fine for me.


Yup, same here with the EU node.......


Title: Re: How (and why) to use the Relay Network
Post by: naplam on October 22, 2014, 07:15:33 PM
I decided to connect to two nodes and forget about it. One will usually be working...


Title: Re: How (and why) to use the Relay Network
Post by: roshii on October 23, 2014, 12:04:37 PM
Yup, same here with the EU node.......

same issue for two days now, I'll switch to us-east this evening


Title: Re: How (and why) to use the Relay Network
Post by: kano on October 24, 2014, 05:02:52 PM
Getting socket errors every so often on the us-west here.

(the main issue with this is that it just sits there stalled for quite a while until it spits out the socket error message)


Title: Re: How (and why) to use the Relay Network
Post by: PatMan on October 24, 2014, 07:12:03 PM
Some kind of auto-switching to a working/fastest/less loaded server would be invaluable too......?


Title: Re: How (and why) to use the Relay Network
Post by: kano on October 25, 2014, 02:20:25 AM
Getting socket errors every so often on the us-west here.

(the main issue with this is that it just sits there stalled for quite a while until it spits out the socket error message)
Seems to be all OK now - no errors in my screen scroll back buffer (which is about 20 minutes) but there were regular ones last night.
I have 2 nodes, current pool and where I'm moving it, and they are both now putting out messages in sync.


Title: Re: How (and why) to use the Relay Network
Post by: kano on October 26, 2014, 11:45:14 AM
Some sort of oversize error (repeatedly) going on at the moment.

Getting this each time:
"Closing relay socket, got freely relayed transaction too large (0: )"
after a whole lot of txns (including some > 25k in size)
(about every 20s)

A ddos?

Edit: 20 minutes later still happening.
The main issue with it is that it's passing all the spam to bitcoind that's then rejecting it all.
Anyone know what's going on?

Looks like I'm gonna have to stop my relay :(

Edit2:
Yep had to kill it:
2014-10-26 12:04:25 Misbehaving: 127.0.0.1:45659 (10200 -> 10300) BAN THRESHOLD EXCEEDED
2014-10-26 12:04:25 Warning: not banning local node 127.0.0.1:45659!

Since the relay is local, bitcoind wont ignore it.

Edit3:
Restarted the relay and the spammer has gone now.


Title: Re: How (and why) to use the Relay Network
Post by: roshii on October 26, 2014, 06:44:56 PM
us-east did not work for long and shows same issue as eu 's one since about this morning
us-west working correctly

Code:
Connected to bitcoind with version 70002
Finished connect handshake with bitcoind
Closing relay socket, failed to read message header (10054: Unknown error)


Title: Re: How (and why) to use the Relay Network
Post by: roshii on October 27, 2014, 07:04:32 AM
eu server is back online :)


Title: Re: How (and why) to use the Relay Network
Post by: galenecrosby on November 06, 2014, 01:32:35 PM
Many of you have likely seen the recent discussions on the P2Pool thread and the post on the foundation blog (https://bitcoinfoundation.org/2014/08/a-bitcoin-backbone/) about the relay network.

It exists as a way for pool operators (and all miners, though not hashers) to get their blocks relayed quickly across a separate network both as a backup to the P2P network and as a quicker way to get the latest blocks as it skips relaying transactions which have already been seen. Thus, if you're a miner anywhere from a small p2pool miner to a large pool, you should be running one of the relay network clients.

You can see more information about its original goals and its original announcement here (http://sourceforge.net/p/bitcoin/mailman/message/32676543/)

Current connection information is as follows:

The relay network's domains are designed to be a bit aggressive to allow for future growth and are laid out by region. The regions are us-east, us-west, eu, sgp, au, jpy, and hk (ie North East US, West Coast US, Western Europe, Singapore, Australia, Japan and Hong Kong). Currently, several regions map to the same set of nodes (all of the asian ones are currently hosted in Singapore), but in the future hopefully things will be more distributed so that you can get nodes closest to your bitcoinds.

You should use the Java relay network client available at https://github.com/TheBlueMatt/RelayNode/raw/master/client/RelayNodeClient.jar (https://github.com/TheBlueMatt/RelayNode/raw/master/client/RelayNodeClient.jar) or the C++ client at https://github.com/TheBlueMatt/RelayNode/tree/master/client (https://github.com/TheBlueMatt/RelayNode/tree/master/client). This will connect using a specialized protocol which will skip relaying transactions which you have already heard about, saving significant bandwidth (and time).

Note that a version of p2pool with a python client integrated directly is available at https://github.com/TheBlueMatt/p2pool (https://github.com/TheBlueMatt/p2pool)

To connect to the relay nodes, you should run RelayNetworkClient.jar or relaynetworkclient with the parameters public.REGION.relay.mattcorallo.com followed by your local bitcoind's address.

eg
$ java -jar ./RelayNodeClient.jar public.us-east.relay.mattcorallo.com 127.0.0.1:8333
or
$ ./relaynetworkclient public.us-east.relay.mattcorallo.com 127.0.0.1 8333


If you are a large pool, you should go to https://docs.google.com/forms/d/1UL82QdcXXEhZwSHJAK04Sk_cWg4zLOu8a216nO7Mt8c/viewform (https://docs.google.com/forms/d/1UL82QdcXXEhZwSHJAK04Sk_cWg4zLOu8a216nO7Mt8c/viewform) to sign up to get a private token which will be used in case of DoS, allowing the relay network to split into private and public parts.

Further details:
 * The relay nodes do some data verification to prevent DoS, but in order to keep relay fast, they do not fully verify the data they are
relaying, thus YOU SHOULD NEVER mine a block building on top of a relayed block without fully checking it with your own bitcoin validator (as you would any other block relayed from the P2P network).
 * The relay nodes all relay among themselves very quickly, so there is no advantage to peering with more than one, in fact, the increased incoming bandwidth during block relay spikes may result in higher latency for your nodes. Please only connect to relay nodes in your region (with multiple peers, one per bitcoind, if you have bitcoinds in multiple regions).
 * The relay nodes are NOT designed to ensure that you never miss data, and may fail to relay some transactions. The relay nodes are NOT a replacement for having peers on the standard P2P network.

You can find the source for the relay nodes at https://github.com/TheBlueMatt/RelayNode

If you have any comments/concerns/suggestions, please do not hesitate to ping me on IRC (BlueMatt on freenode).

Im also running a relay node client and it need a huge bandwidth..thanks for sharing to us this amazing and infomative post matt!!


Title: Re: How (and why) to use the Relay Network
Post by: jedimstr on November 06, 2014, 02:09:31 PM
US East Coast relay seems to be down.  West is fine.


Title: Re: How (and why) to use the Relay Network
Post by: amaclin on November 06, 2014, 02:15:08 PM
US East Coast relay seems to be down.  West is fine.
Confirmed east=down/west=fine from my side


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on November 06, 2014, 05:39:37 PM
US East Coast relay seems to be down.  West is fine.
Ugh, yea, I think it ran out of fds, but I'm adding a bit more logging to be sure...It has been restarted and is working now, but I'll watch for further issues.


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on November 08, 2014, 07:06:28 AM
We now have an Australian node! Those of you already using the 'au' region should (at max) simply need to restart your client to connect to it, otherwise switch to the au region. Thanks to forum member norgan for providing the server.


Title: Re: How (and why) to use the Relay Network
Post by: MissouriMiner on November 12, 2014, 06:15:00 AM
EDIT - It's working.  Dumb newbie (rushing) mistake. :)   I forgot to open 8336 outbound on my firewall (iptables).

I have a couple of newbie questions.  (I've been running p2pool for a long time, but not your relay client.)

How do we verify the client is working?  
 - I already had p2pool running, and ran "./relaynetworkclient public.us-east.relay.mattcorallo.com 127.0.0.1 8333" in a separate screen session.
 - I see "Closing relay socket, failed to connect() (110: Connection timed out)" every so often, but this appears to be normal based on forum discussion.

Do I need to port forward 8336?  
If yes, can I specify a different port?





Title: Re: How (and why) to use the Relay Network
Post by: norgan on November 20, 2014, 08:55:46 PM
Hey Matt, Aussie node is playing up.


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on November 23, 2014, 08:58:41 PM
Hey Matt, Aussie node is playing up.
Indeed, it appears the host decided to reboot the server without warning (WTF?) and it didnt come back up properly.


Title: Re: How (and why) to use the Relay Network
Post by: kano on November 24, 2014, 10:29:38 PM
Sigh,
seems like another relay ddos.
Lots of txns over a short period of time followed by
"Closing relay socket, got freely relayed transaction too large (0: )"

Happening repeatedly.


Title: Re: How (and why) to use the Relay Network
Post by: PatMan on November 24, 2014, 10:36:47 PM
Yup, EU relay has gone bonkers too - switching off for the time being  :(


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on November 24, 2014, 11:57:30 PM
Sigh,
seems like another relay ddos.
Lots of txns over a short period of time followed by
"Closing relay socket, got freely relayed transaction too large (0: )"

Happening repeatedly.
This is not a dos, this is a bug. Specifically, this one (https://github.com/TheBlueMatt/RelayNode/commit/3f8291841c3a6da8dee96631f49880dac90d88ea). (Fixed now).


Title: Re: How (and why) to use the Relay Network
Post by: kano on November 25, 2014, 09:56:46 PM
Sigh,
seems like another relay ddos.
Lots of txns over a short period of time followed by
"Closing relay socket, got freely relayed transaction too large (0: )"

Happening repeatedly.
This is not a dos, this is a bug. Specifically, this one (https://github.com/TheBlueMatt/RelayNode/commit/3f8291841c3a6da8dee96631f49880dac90d88ea). (Fixed now).
Oh nice :)
Bugs are better (IMO) than a ddos, coz there's a definite fix for it :)
Updated.
Thanks.


Title: Re: How (and why) to use the Relay Network
Post by: norgan on November 25, 2014, 10:30:11 PM
Sigh,
seems like another relay ddos.
Lots of txns over a short period of time followed by
"Closing relay socket, got freely relayed transaction too large (0: )"

Happening repeatedly.
This is not a dos, this is a bug. Specifically, this one (https://github.com/TheBlueMatt/RelayNode/commit/3f8291841c3a6da8dee96631f49880dac90d88ea). (Fixed now).
Oh nice :)
Bugs are better (IMO) than a ddos, coz there's a definite fix for it :)
Updated.
Thanks.
sweet, can we have a new exe compiled please?


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on November 25, 2014, 10:58:28 PM
sweet, can we have a new exe compiled please?
Dont need it, just a server-side bug.


Title: Re: How (and why) to use the Relay Network
Post by: chinesebob on November 26, 2014, 12:04:09 AM
How can I test whether running the relay client is actually benefiting me?  In 24 hours since starting it I have 4 shares in p2pool, 2 of which are orphaned, this is high compared to my previous 20 days.  I'm running bitcoind, p2pool, and relaynetworkclient all on the same system.


Title: Re: How (and why) to use the Relay Network
Post by: norgan on November 26, 2014, 12:58:47 AM
sweet, can we have a new exe compiled please?
Dont need it, just a server-side bug.

ah! cool, thanks mate.


Title: Re: How (and why) to use the Relay Network
Post by: norgan on November 26, 2014, 12:59:23 AM
How can I test whether running the relay client is actually benefiting me?  In 24 hours since starting it I have 4 shares in p2pool, 2 of which are orphaned, this is high compared to my previous 20 days.  I'm running bitcoind, p2pool, and relaynetworkclient all on the same system.
it's just a matter of testing over time. It can't make things worse ;)


Title: Re: How (and why) to use the Relay Network
Post by: kano on November 26, 2014, 08:20:40 AM
How can I test whether running the relay client is actually benefiting me?  In 24 hours since starting it I have 4 shares in p2pool, 2 of which are orphaned, this is high compared to my previous 20 days.  I'm running bitcoind, p2pool, and relaynetworkclient all on the same system.
p2pool shares are unrelated to the relay client ...


Title: Re: How (and why) to use the Relay Network
Post by: spin on November 26, 2014, 05:57:50 PM
Still some issues?

Code:
./relaynetworkclient public.eu.relay.mattcorallo.com 127.0.0.1 8333
Connected to bitcoind with version 70002
Finished connect handshake with bitcoind
Sent transaction of size 223 to relay server
Sent transaction of size 223 to relay server
Closing relay socket, failed to read message header (0: )
Closing relay socket, failed to read message header (104: Connection reset by peer)
Sent transaction of size 226 to relay server
Sent transaction of size 473 to relay server
Sent transaction of size 436 to relay server
Sent transaction of size 226 to relay server
Closing relay socket, failed to read message header (104: Connection reset by peer)



Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on November 27, 2014, 03:40:59 AM
Still some issues?

Code:
./relaynetworkclient public.eu.relay.mattcorallo.com 127.0.0.1 8333
Connected to bitcoind with version 70002
Finished connect handshake with bitcoind
Sent transaction of size 223 to relay server
Sent transaction of size 223 to relay server
Closing relay socket, failed to read message header (0: )
Closing relay socket, failed to read message header (104: Connection reset by peer)
Sent transaction of size 226 to relay server
Sent transaction of size 473 to relay server
Sent transaction of size 436 to relay server
Sent transaction of size 226 to relay server
Closing relay socket, failed to read message header (104: Connection reset by peer)


That looks like you have multiple connections from the same IP (note that it takes up to 10 seconds before you can connect again after a disconnect, though I think most clients are set to reconnect every second).


Title: Re: How (and why) to use the Relay Network
Post by: spin on November 27, 2014, 12:08:42 PM
Still some issues?

Code:
./relaynetworkclient public.eu.relay.mattcorallo.com 127.0.0.1 8333
Connected to bitcoind with version 70002
Finished connect handshake with bitcoind
Sent transaction of size 223 to relay server
Sent transaction of size 223 to relay server
Closing relay socket, failed to read message header (0: )
Closing relay socket, failed to read message header (104: Connection reset by peer)
Sent transaction of size 226 to relay server
Sent transaction of size 473 to relay server
Sent transaction of size 436 to relay server
Sent transaction of size 226 to relay server
Closing relay socket, failed to read message header (104: Connection reset by peer)


That looks like you have multiple connections from the same IP (note that it takes up to 10 seconds before you can connect again after a disconnect, though I think most clients are set to reconnect every second).

It somehow ends up in that state from time to time.  I only run one client (the defualt).  I guess it loses connection at some point and when it rapidly reconnects it get's banned/blocked by the relay server?

Can I change the reconnect interval in the client?


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on November 27, 2014, 06:11:16 PM
It somehow ends up in that state from time to time.  I only run one client (the defualt).  I guess it loses connection at some point and when it rapidly reconnects it get's banned/blocked by the relay server?

Can I change the reconnect interval in the client?
Does it not get back in after ~10 seconds? Getting reset a few times while trying to reconnect shouldnt hurt anything.


Title: Re: How (and why) to use the Relay Network
Post by: spin on November 28, 2014, 05:58:35 PM
It somehow ends up in that state from time to time.  I only run one client (the defualt).  I guess it loses connection at some point and when it rapidly reconnects it get's banned/blocked by the relay server?

Can I change the reconnect interval in the client?
Does it not get back in after ~10 seconds? Getting reset a few times while trying to reconnect shouldnt hurt anything.

Not it doesn't.  It stays like that for as far back as my scroll back allows.  It doesn't receive txs during this time, but does try to send to the relay node.


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on November 28, 2014, 06:03:00 PM
Not it doesn't.  It stays like that for as far back as my scroll back allows.  It doesn't receive txs during this time, but does try to send to the relay node.
You should pm me your ip, I cant reproduce.


Title: Re: How (and why) to use the Relay Network
Post by: jedimstr on November 30, 2014, 04:25:11 AM
Looks like East Coast Relay is down again... had to connect to the West Coast one.


Title: Re: How (and why) to use the Relay Network
Post by: OverHash on November 30, 2014, 11:32:26 PM
The following pools (in alphabetical order) are known to use the C++ Relay Network Client (and, thus, will likely see slightly lower orphan rates):

  • P2Pool: If you're running your own P2Pool node you can (and should) absolutely run the client locally connected directly to your bitcoind. Also, many publicly hosted P2Pool nodes run the client as well.
  • Bitminter
  • BTCGuild
  • ckpool/hashmine.io
  • Eligius

If you are a pool operator and are running the C++ (or Java) client on or near your bitcoinds, please find me on IRC or PM me to get added to this list.

Hi Matt Corallo,

If possible would you be able to add OverHash.com to the list of pools as we are running the C++ client for our pool.


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on November 30, 2014, 11:48:42 PM
Hi Matt Corallo,

If possible would you be able to add OverHash.com to the list of pools as we are running the C++ client for our pool.
As noted previously, I'm not gonna add pools to that list that dont have at least a few dozen TH on them.


Title: Re: How (and why) to use the Relay Network
Post by: OverHash on November 30, 2014, 11:50:07 PM
As noted previously, I'm not gonna add pools to that list that dont have at least a few dozen TH on them.

Ah okay, that's fair enough. Sorry should have read a bit more thoroughly.

Thanks for designing the relay though :)


Title: Re: How (and why) to use the Relay Network
Post by: entr04y on December 02, 2014, 02:38:46 PM
I'm getting this in the output:

Code:

Received transaction of size 226 from relay server
Received transaction of size 373 from relay server
Closing bitcoind socket with 127.0.0.1, failed to read message header (104: Connection reset by peer)
Closing bitcoind socket with 127.0.0.1, failed to read message header (0: )



I'm not seeing any errors in my bitcoin debug log, and the port is open on the server.  I'm running the latest bitcoind and I pulled the relay client from github this morning (its the c++ version on linux)

edit: I'm starting the relay client like so:

Code:

./relaynetworkclient public.us-east.relay.mattcorallo.com 127.0.0.1 8333

I saw some other people were getting similar messages on the relay, but not on bitcoind.  Any ideas?

Thanks!


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on December 02, 2014, 08:24:08 PM

Code:
Closing bitcoind socket with 127.0.0.1, failed to read message header (104: Connection reset by peer)
Closing bitcoind socket with 127.0.0.1, failed to read message header (0: )


I'm not seeing any errors in my bitcoin debug log, and the port is open on the server.  I'm running the latest bitcoind and I pulled the relay client from github this morning (its the c++ version on linux)

Have you checked wireshark on your loopback interface, and are you sure bitcoind is listening on loopback and not only on your non-localhost address(es)?


Title: Re: How (and why) to use the Relay Network
Post by: entr04y on December 02, 2014, 08:43:09 PM

Code:
Closing bitcoind socket with 127.0.0.1, failed to read message header (104: Connection reset by peer)
Closing bitcoind socket with 127.0.0.1, failed to read message header (0: )


I'm not seeing any errors in my bitcoin debug log, and the port is open on the server.  I'm running the latest bitcoind and I pulled the relay client from github this morning (its the c++ version on linux)

Have you checked wireshark on your loopback interface, and are you sure bitcoind is listening on loopback and not only on your non-localhost address(es)?

I just double checked that and it is listening on both ipv4 and ipv6.  If I telnet to the port using localhost it connects and then immediately closes the connection. 

then the penny dropped:  maxconnections is set to 20 in my bitcoin.conf and guess how many peers I have connected? ;)


Title: Re: How (and why) to use the Relay Network
Post by: spin on December 03, 2014, 07:38:38 AM
You should pm me your ip, I cant reproduce.
Will do when it happens again.  Won't restart then either.


Title: Re: How (and why) to use the Relay Network
Post by: IYFTech on December 05, 2014, 07:07:57 PM
Is the relay network down? I can't connect to any of the different nodes.......


Title: Re: How (and why) to use the Relay Network
Post by: entr04y on December 05, 2014, 07:23:05 PM
Is the relay network down? I can't connect to any of the different nodes.......

My instance of the relay client seems to be working happily...


Title: Re: How (and why) to use the Relay Network
Post by: IYFTech on December 05, 2014, 07:42:16 PM
Is the relay network down? I can't connect to any of the different nodes.......

Edit: Seems the issue was at my end. My apologies  ;)


Title: Re: How (and why) to use the Relay Network
Post by: norgan on December 16, 2014, 11:25:20 AM
Hi Matt, got an issue on the Aussie node. Unable to read message header


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on December 20, 2014, 12:13:06 AM
Hi Matt, got an issue on the Aussie node. Unable to read message header
Ugh, sorry I missed this...should be fixed now :(


Title: Re: How (and why) to use the Relay Network
Post by: spiccioli on December 21, 2014, 11:17:34 AM
Hi Matt,

I'm getting tons of these on eu node with java client

Code:
Dec 21, 2014 12:15:33 PM com.google.bitcoin.net.ConnectionHandler handleKeyWrite
SEVERE: Error handling SelectionKey write: null
Dec 21, 2014 12:15:35 PM com.google.bitcoin.net.NioClientManager handleKey
INFO: Successfully connected to public.eu.relay.mattcorallo.com/146.185.173.241:8336
Connected to relay peer!
Dec 21, 2014 12:15:35 PM com.google.bitcoin.net.ConnectionHandler handleKeyRead
SEVERE: Error handling SelectionKey read: Connection reset by peer

No problems using us-east.

Best regards

spiccioli


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on December 21, 2014, 09:11:09 PM
I'm getting tons of these on eu node with java client
Ugh, yea...there are, I think, three known issues now with the server-side stuff. Sadly its been on the backburner so the servers just keep getting restarted instead of fixed (luckily clients reconnect quickly and it doesnt really matter), but I should have some time in the next week to catch up on the technical debt on the server-side.


Title: Re: How (and why) to use the Relay Network
Post by: jedimstr on December 23, 2014, 07:53:24 PM
With Bitcoin Core v0.10.0 Release Candidate 1 out for testing, any potential gotcha's for Relay Clients?  I see in the release notes that there are quite a few header related changes.


Title: Re: How (and why) to use the Relay Network
Post by: kano on December 23, 2014, 11:52:25 PM
With Bitcoin Core v0.10.0 Release Candidate 1 out for testing, any potential gotcha's for Relay Clients?  I see in the release notes that there are quite a few header related changes.
Without even looking, I'll say that the header will of course be backwards compatible.
The devs don't do hard forks.


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on December 24, 2014, 01:06:47 PM
With Bitcoin Core v0.10.0 Release Candidate 1 out for testing, any potential gotcha's for Relay Clients?  I see in the release notes that there are quite a few header related changes.
Shouldnt be...Ive been running relay clients against master forever.


Title: Re: How (and why) to use the Relay Network
Post by: jedimstr on December 24, 2014, 01:59:07 PM
Thanks Kano and Matt, just checking :)

Can never be too careful.  I'll probably still wait until the final release of 0.10.0 before switching though.


Title: Re: How (and why) to use the Relay Network
Post by: loshia on December 29, 2014, 07:39:19 AM
With Bitcoin Core v0.10.0 Release Candidate 1 out for testing, any potential gotcha's for Relay Clients?  I see in the release notes that there are quite a few header related changes.
with v0.10.0rc1 works charming ;)


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on January 03, 2015, 06:03:36 PM
With Bitcoin Core v0.10.0 Release Candidate 1 out for testing, any potential gotcha's for Relay Clients?  I see in the release notes that there are quite a few header related changes.
HAH! Now that I say that, it looks like there may actually be issues hiding here (specifically, https://github.com/bitcoin/bitcoin/issues/5588 may be related). Anyway, if it is, its a bug in bitcoin core, to be fixed there.


Title: Re: How (and why) to use the Relay Network
Post by: jedimstr on January 03, 2015, 07:33:38 PM
With Bitcoin Core v0.10.0 Release Candidate 1 out for testing, any potential gotcha's for Relay Clients?  I see in the release notes that there are quite a few header related changes.
HAH! Now that I say that, it looks like there may actually be issues hiding here (specifically, https://github.com/bitcoin/bitcoin/issues/5588 may be related). Anyway, if it is, its a bug in bitcoin core, to be fixed there.

Well, if it's an issue, better found now in the first RC than in the gold version right?


Title: Re: How (and why) to use the Relay Network
Post by: spin on February 09, 2015, 10:41:30 AM
Matt, I've been having issues connecting again.  Both EU and US-east. That's after weeks of rock solid stability. 


Title: Re: How (and why) to use the Relay Network
Post by: IYFTech on February 09, 2015, 06:39:29 PM
Matt, I've been having issues connecting again.  Both EU and US-east. That's after weeks of rock solid stability. 

EU server working fine here  :)


Title: Re: How (and why) to use the Relay Network
Post by: spin on February 10, 2015, 02:07:43 PM
Matt, I've been having issues connecting again.  Both EU and US-east. That's after weeks of rock solid stability.  

EU server working fine here  :)

Yes, also now fine for me.


Title: Re: How (and why) to use the Relay Network
Post by: zvs on February 27, 2015, 07:14:48 PM
It gets this for me,

Closing bitcoind socket with nogleg, error during connect (101: Network is unreachable)
Closing bitcoind socket with nogleg, error during connect (101: Network is unreachable)
Closing bitcoind socket with nogleg, error during connect (101: Network is unreachable)
Closing bitcoind socket with nogleg, error during connect (101: Network is unreachable)

ofc ipv6 is unreachable, since I disabled it in sysctl.conf.  

it's the same thing as when bitcoind was screwed and wouldn't start when ipv6 was disabled


ed, oh, i let it run for a while longer and after the 10-15th try it stopped attempting ipv6

so working

ed: well, sort of.

Code:
Closing bitcoind socket with nogleg, error during connect (101: Network is unreachable)
Received transaction of size 226 from relay server
Closing bitcoind socket with nogleg, error during connect (101: Network is unreachable)
Received transaction of size 373 from relay server
Received transaction of size 226 from relay server
Closing bitcoind socket with nogleg, error during connect (101: Network is unreachable)
Received transaction of size 472 from relay server
Received transaction of size 373 from relay server
Closing bitcoind socket with nogleg, error during connect (101: Network is unreachable)
Received transaction of size 226 from relay server
Received transaction of size 470 from relay server
Received transaction of size 616 from relay server
Closing bitcoind socket with nogleg, error during connect (101: Network is unreachable)
Received transaction of size 521 from relay server
Received transaction of size 191 from relay server
Received transaction of size 258 from relay server
Received transaction of size 434 from relay server
Closing bitcoind socket with nogleg, error during connect (101: Network is unreachable)
Received transaction of size 225 from relay server
Received transaction of size 438 from relay server
Closing bitcoind socket with nogleg, error during connect (101: Network is unreachable)
Received transaction of size 223 from relay server
Closing bitcoind socket with nogleg, error during connect (101: Network is unreachable)
Received transaction of size 437 from relay server
Received transaction of size 227 from relay server
Closing bitcoind socket with nogleg, error during connect (101: Network is unreachable)
Received transaction of size 470 from relay server
Received transaction of size 226 from relay server
Closing bitcoind socket with nogleg, error during connect (101: Network is unreachable)
Received transaction of size 471 from relay server
Closing bitcoind socket with nogleg, error during connect (101: Network is unreachable)
Closing bitcoind socket with nogleg, error during connect (101: Network is unreachable)
Received transaction of size 436 from relay server
Closing bitcoind socket with nogleg, error during connect (101: Network is unreachable)

I guess it's a bit annoying, it is also opening up some godawful amount of ipv6 sockets

Code:
tcp6       0      0 ::1:54082               ::1:8333                TIME_WAIT   -
tcp6       0      0 ::1:54066               ::1:8333                TIME_WAIT   -
tcp6       0      0 ::1:54009               ::1:8333                TIME_WAIT   -
tcp6       0      0 ::1:54083               ::1:8333                TIME_WAIT   -
tcp6       0      0 ::1:54092               ::1:8333                TIME_WAIT   -
tcp6       0      0 ::1:54014               ::1:8333                TIME_WAIT   -
tcp6       0      0 ::1:54067               ::1:8333                TIME_WAIT   -
tcp6       0      0 ::1:54073               ::1:8333                TIME_WAIT   -
tcp6       0      0 ::1:54010               ::1:8333                TIME_WAIT   -
tcp6       0      0 ::1:54086               ::1:8333                TIME_WAIT   -
tcp6       0      0 ::1:54063               ::1:8333                TIME_WAIT   -
tcp6       0      0 ::1:54079               ::1:8333                TIME_WAIT   -
tcp6       0      0 ::1:54071               ::1:8333                TIME_WAIT   -
tcp6       0      0 ::1:54048               ::1:8333                TIME_WAIT   -
tcp6       0      0 ::1:54008               ::1:8333                TIME_WAIT   -
tcp6       0      0 ::1:54033               ::1:8333                TIME_WAIT   -
tcp6       0      0 ::1:54013               ::1:8333                TIME_WAIT   -
tcp6       0      0 ::1:54052               ::1:8333                TIME_WAIT   -
tcp6       0      0 ::1:54090               ::1:8333                TIME_WAIT   -
tcp6       0      0 ::1:54062               ::1:8333                TIME_WAIT   -
tcp6       0      0 ::1:54065               ::1:8333                TIME_WAIT   -
tcp6       0      0 ::1:54077               ::1:8333                TIME_WAIT   -
tcp6       0      0 ::1:54074               ::1:8333                TIME_WAIT   -
tcp6       0      0 ::1:54091               ::1:8333                TIME_WAIT   -
tcp6       0      0 ::1:54072               ::1:8333                TIME_WAIT   -
tcp6       0      0 ::1:54075               ::1:8333                TIME_WAIT   -
tcp6       0      0 ::1:54080               ::1:8333                TIME_WAIT   -
tcp6       0      0 zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz    ESTABLISHED 4226/relaynetworkcl
tcp6       0      0 ::1:54005               ::1:8333                TIME_WAIT   -
tcp6       0      0 ::1:54060               ::1:8333                TIME_WAIT   -
tcp6       0      0 ::1:54084               ::1:8333                TIME_WAIT   -
tcp6       0      0 ::1:54028               ::1:8333                TIME_WAIT   -
tcp6       0      0 ::1:54093               ::1:8333                TIME_WAIT   -
tcp6       0      0 ::1:54064               ::1:8333                TIME_WAIT   -
tcp6       0      0 ::1:54007               ::1:8333                TIME_WAIT   -
tcp6       0      0 ::1:54006               ::1:8333                TIME_WAIT   -
tcp6       0      0 ::1:54059               ::1:8333                TIME_WAIT   -
tcp6       0      0 ::1:54078               ::1:8333                TIME_WAIT   -
tcp6       0      0 ::1:54004               ::1:8333                TIME_WAIT   -
tcp6       0      0 ::1:54021               ::1:8333                TIME_WAIT   -
tcp6       0      0 ::1:54085               ::1:8333                TIME_WAIT   -
tcp6       0      0 ::1:54069               ::1:8333                TIME_WAIT   -
tcp6       0      0 ::1:54070               ::1:8333                TIME_WAIT   -
tcp6       0      0 ::1:54012               ::1:8333                TIME_WAIT   -
tcp6       0      0 ::1:54061               ::1:8333                TIME_WAIT   -
tcp6       0      0 ::1:54017               ::1:8333                TIME_WAIT   -
tcp6       0      0 ::1:54056               ::1:8333                TIME_WAIT   -
tcp6       0      0 ::1:54095               ::1:8333                TIME_WAIT   -
tcp6       0      0 ::1:54076               ::1:8333                TIME_WAIT   -
tcp6       0      0 ::1:54038               ::1:8333                TIME_WAIT   -
tcp6       0      0 ::1:54068               ::1:8333                TIME_WAIT   -
tcp6       0      0 ::1:54011               ::1:8333                TIME_WAIT   -
tcp6       0      0 ::1:54089               ::1:8333                TIME_WAIT   -
tcp6       0      0 ::1:54057               ::1:8333                TIME_WAIT   -
tcp6       0      0 ::1:54087               ::1:8333                TIME_WAIT   -
tcp6       0      0 ::1:54094               ::1:8333                TIME_WAIT   -
tcp6       0      0 ::1:54058               ::1:8333                TIME_WAIT   -
tcp6       0      0 ::1:54081               ::1:8333                TIME_WAIT   -
tcp6       0      0 ::1:54088               ::1:8333                TIME_WAIT   -
tcp6       0      0 ::1:54043               ::1:8333                TIME_WAIT   -
tcp6       0      0 ::1:54015               ::1:8333                TIME_WAIT   -

I also have onlynet defined in my bitcoin.conf;

onlynet=ipv4

that is proper text is it not?

oh well.  i  put it on other machine with ipv6 activated, and now it looks like

Code:
Received transaction of size 1337 from relay server
Received transaction of size 437 from relay server
Sent transaction of size 191 to relay server
Received transaction of size 191 from relay server
Sent transaction of size 436 to relay server
Received transaction of size 436 from relay server
Sent transaction of size 370 to relay server
Received transaction of size 370 from relay server
Sent transaction of size 584 to relay server
Received transaction of size 584 from relay server
Sent transaction of size 226 to relay server
Received transaction of size 226 from relay server
Sent transaction of size 226 to relay server
Received transaction of size 226 from relay server
Sent transaction of size 226 to relay server
Received transaction of size 226 from relay server
Sent transaction of size 226 to relay server
Received transaction of size 226 from relay server
Sent transaction of size 796 to relay server
Received transaction of size 796 from relay server
Sent transaction of size 225 to relay server
Received transaction of size 225 from relay server
Sent transaction of size 472 to relay server
Received transaction of size 472 from relay server
Sent transaction of size 35985 to relay server
Sent transaction of size 225 to relay server
Sent transaction of size 192 to relay server
Received transaction of size 225 from relay server
Received transaction of size 192 from relay server
Sent transaction of size 227 to relay server
Received transaction of size 227 from relay server
Sent transaction of size 615 to relay server
Sent transaction of size 225 to relay server
Received transaction of size 615 from relay server
Received transaction of size 225 from relay server
Sent transaction of size 225 to relay server
Received transaction of size 225 from relay server
Sent transaction of size 257 to relay server
Received transaction of size 257 from relay server
Sent transaction of size 225 to relay server
Received transaction of size 225 from relay server
Sent transaction of size 403 to relay server
Received transaction of size 403 from relay server
Sent transaction of size 259 to relay server
Received transaction of size 259 from relay server
Sent transaction of size 436 to relay server
Received transaction of size 436 from relay server
Sent transaction of size 226 to relay server
Sent transaction of size 225 to relay server
Received transaction of size 226 from relay server
Received transaction of size 225 from relay server
Sent transaction of size 405 to relay server
Received transaction of size 405 from relay server
Sent transaction of size 373 to relay server
Received transaction of size 373 from relay server
Sent transaction of size 226 to relay server
Received transaction of size 226 from relay server
Sent transaction of size 374 to relay server
Received transaction of size 374 from relay server

so it is essentially just sending transactions that I send it back to me.  how much bandwidth does this consume?


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on February 27, 2015, 10:22:50 PM

ofc ipv6 is unreachable, since I disabled it in sysctl.conf.  

If you disable ipv6 in sysctl by removing all ipv6 support things are going to break. You need ipv6 support, though you dont need to have ipv6 configured (it just uses ipv6 sockets for ipv4 because doing both is way too much code complexity)


Title: Re: How (and why) to use the Relay Network
Post by: jedimstr on March 11, 2015, 10:32:40 PM
East Coast US relay is spouting errors.  Using US West for now.


Title: Re: How (and why) to use the Relay Network
Post by: zvs on March 16, 2015, 11:27:43 AM

ofc ipv6 is unreachable, since I disabled it in sysctl.conf.  

If you disable ipv6 in sysctl by removing all ipv6 support things are going to break. You need ipv6 support, though you dont need to have ipv6 configured (it just uses ipv6 sockets for ipv4 because doing both is way too much code complexity)
Yah, had the

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1

thing going on. 

Is there a method to get it to just relay blocks instead of blocks and transactions?  It doesn't accept connections to port 8334 anymore, is the only way to do it to modify the source?


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on March 19, 2015, 04:55:20 AM
Is there a method to get it to just relay blocks instead of blocks and transactions?  It doesn't accept connections to port 8334 anymore, is the only way to do it to modify the source?
That would defeat the purpose. It compresses blocks by pre-relaying transactions.


Title: Re: How (and why) to use the Relay Network
Post by: kano on March 19, 2015, 05:32:17 AM
Had a quick look at this but couldn't see it was possible.
Would it be much effort to allow it to connect to multiple bitcoinds?
i.e. if you had 2 bitcoinds in a local network, have it talk to both directly
(having 2 local bitcoinds pointing at each other is crap slow and unreliable :P)


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on March 19, 2015, 07:26:00 PM
Had a quick look at this but couldn't see it was possible.
Would it be much effort to allow it to connect to multiple bitcoinds?
i.e. if you had 2 bitcoinds in a local network, have it talk to both directly
(having 2 local bitcoinds pointing at each other is crap slow and unreliable :P)
The somewhat stale branch of https://github.com/TheBlueMatt/RelayNode/commits/for-w does exactly this. It should be an easy rebase.


Title: Re: How (and why) to use the Relay Network
Post by: MissouriMiner on March 22, 2015, 11:06:33 PM
My relay connection is recently getting banned by bitcoind.  Two things have changed for my node.  The Linux host is now a VM, although with plenty of resources and running on SSD.  And I have recently upgraded bitcoind to v10.  The clock is synched via ntp and resources do not appear stressed. 

The messages below are from the bitcoind debug log.  192.168.44.100 is one of the local IP's.  relaynetworkclient runs on the same Linux VM as bitcoind.

2015-03-21 13:04:21 ERROR: CheckBlock() : hashMerkleRoot mismatch
2015-03-21 13:04:21 ERROR: ProcessNewBlock : CheckBlock FAILED
2015-03-21 13:04:21 Misbehaving: 192.168.44.100:34761 (0 -> 100) BAN THRESHOLD EXCEEDED
2015-03-21 13:04:22 connection from 192.168.44.100:38277 dropped (banned)

relaynetworkclient version below.  I did not re-compile after migrating the Linux host to a VM.
relaynetworkclient: ELF 64-bit LSB  executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=4460be497a8f032b9305ebcd951652a0fe0c29f4, stripped


Title: Re: How (and why) to use the Relay Network
Post by: spin on March 22, 2015, 11:16:58 PM
You could whitelist the ip of the relayclient in your bitcoin.conf? It should really connect with 127.0.0.1 ip though, if it is running on the same machine.


Title: Re: How (and why) to use the Relay Network
Post by: jedimstr on March 24, 2015, 11:48:56 AM
Getting connection resets from the East Coast Node again for the last day or so.  On West for now.


Title: Re: How (and why) to use the Relay Network
Post by: jedimstr on March 25, 2015, 12:30:21 PM
East Coast still down :(  (connection resets)


Title: Re: How (and why) to use the Relay Network
Post by: jedimstr on March 28, 2015, 01:42:01 PM
So.... are the relays just not being maintained anymore?


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on March 30, 2015, 06:57:14 PM
So.... are the relays just not being maintained anymore?
No, they are...minimally. Sadly other things are taking precedance, but when I'm not travelling they do get restarted as things fall over :(.


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on March 30, 2015, 08:06:25 PM
My relay connection is recently getting banned by bitcoind.  Two things have changed for my node.  The Linux host is now a VM, although with plenty of resources and running on SSD.  And I have recently upgraded bitcoind to v10.  The clock is synched via ntp and resources do not appear stressed. 

The messages below are from the bitcoind debug log.  192.168.44.100 is one of the local IP's.  relaynetworkclient runs on the same Linux VM as bitcoind.

2015-03-21 13:04:21 ERROR: CheckBlock() : hashMerkleRoot mismatch
2015-03-21 13:04:21 ERROR: ProcessNewBlock : CheckBlock FAILED
2015-03-21 13:04:21 Misbehaving: 192.168.44.100:34761 (0 -> 100) BAN THRESHOLD EXCEEDED
2015-03-21 13:04:22 connection from 192.168.44.100:38277 dropped (banned)

relaynetworkclient version below.  I did not re-compile after migrating the Linux host to a VM.
relaynetworkclient: ELF 64-bit LSB  executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=4460be497a8f032b9305ebcd951652a0fe0c29f4, stripped

Hmmmm....there seems to be a bug in the merkle tree parsing somewhere...I'll dig into it a bit later :(. That said, you should probably be running on localhost anyway as a malicious actor could potentially get you to ban the relay client (though its not very possible to DoS very significantly over the relay network)


Title: Re: How (and why) to use the Relay Network
Post by: MissouriMiner on April 02, 2015, 10:03:39 PM
I think something is wrong with us-east.  I'm pointed to us-west now, which is working fine for me.

With us-east, I get messages below.  My outbound transactions are working.

Closing relay socket, failed to read message header (0: )
Closing relay socket, failed to read message header (0: )
Sent transaction of size 373 to relay server
Closing relay socket, failed to read message header (0: )


Title: Re: How (and why) to use the Relay Network
Post by: jedimstr on April 06, 2015, 10:36:49 AM
I think something is wrong with us-east.  I'm pointed to us-west now, which is working fine for me.

With us-east, I get messages below.  My outbound transactions are working.

Closing relay socket, failed to read message header (0: )
Closing relay socket, failed to read message header (0: )
Sent transaction of size 373 to relay server
Closing relay socket, failed to read message header (0: )


Well, both US East and US West are dead for me for the last few days.  Figured Matt was traveling per his post above so didn't complain.

Matt - Any chance you could just set both US East/West servers to just automatically restart every day at midnight or something?


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on April 07, 2015, 01:39:23 AM
Well, both US East and US West are dead for me for the last few days.  Figured Matt was traveling per his post above so didn't complain.

Matt - Any chance you could just set both US East/West servers to just automatically restart every day at midnight or something?
Just fixed a bug which could cause the resets we've seen. Lets see what happens now.....


Title: Re: How (and why) to use the Relay Network
Post by: kano on April 07, 2015, 10:32:45 PM
I rearranged my bitcoinds (10 days ago) and ended up with the relay using the external IP
(will fix it next time I restart bitcoind, don't like doing that too often)
Anyway, as a result it got itself banned - seems the relay had a lot of bad transactions 6 hours ago :(

2015-04-07 16:01:35 Misbehaving: a.b.c.d:33466 (0 -> 10)
2015-04-07 16:25:06 Misbehaving: a.b.c.d:33466 (90 -> 100) BAN THRESHOLD EXCEEDED

That's the first message in the 10 days, then only 24 minutes to hit the threshold :(


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on April 08, 2015, 01:13:36 PM
I rearranged my bitcoinds (10 days ago) and ended up with the relay using the external IP
(will fix it next time I restart bitcoind, don't like doing that too often)
Anyway, as a result it got itself banned - seems the relay had a lot of bad transactions 6 hours ago :(

2015-04-07 16:01:35 Misbehaving: a.b.c.d:33466 (0 -> 10)
2015-04-07 16:25:06 Misbehaving: a.b.c.d:33466 (90 -> 100) BAN THRESHOLD EXCEEDED

That's the first message in the 10 days, then only 24 minutes to hit the threshold :(
Can you paste the log contents around those lines (ie why it got banned?)


Title: Re: How (and why) to use the Relay Network
Post by: kano on April 09, 2015, 10:32:40 PM
I rearranged my bitcoinds (10 days ago) and ended up with the relay using the external IP
(will fix it next time I restart bitcoind, don't like doing that too often)
Anyway, as a result it got itself banned - seems the relay had a lot of bad transactions 6 hours ago :(

2015-04-07 16:01:35 Misbehaving: a.b.c.d:33466 (0 -> 10)
2015-04-07 16:25:06 Misbehaving: a.b.c.d:33466 (90 -> 100) BAN THRESHOLD EXCEEDED

That's the first message in the 10 days, then only 24 minutes to hit the threshold :(
Can you paste the log contents around those lines (ie why it got banned?)
Looks like it was these:
Code:
2015-04-07 16:23:53 ERROR: CheckTransaction() : vin empty
2015-04-07 16:23:53 ERROR: AcceptToMemoryPool: : CheckTransaction failed
I'll PM you more of the log


Title: Re: How (and why) to use the Relay Network
Post by: kano on May 29, 2015, 11:26:49 PM
Had a lot of trouble with the relay over the past day.
Anyone else seeing problems with us-west?

And like at the moment, I seem to often be the only one sending data to the relay, not receiving anything from the relay.
... it suddenly comes back to life with a truck load of Receives for a very short time, but again now back to only me Sending


Title: Re: How (and why) to use the Relay Network
Post by: twebit on May 30, 2015, 03:54:20 AM
Had a lot of trouble with the relay over the past day.
Anyone else seeing problems with us-west?

And like at the moment, I seem to often be the only one sending data to the relay, not receiving anything from the relay.
... it suddenly comes back to life with a truck load of Receives for a very short time, but again now back to only me Sending

For me it was sometimes off. Other times saw an inflood of transactions.
Sorry to say I shut it down and moved to pool mining again but I have one question...

Why? if this is a relay, do we/I have to connect to what it says on the home page of this post. Rather connect to anyone? place or thing?
I don't understand much but can't there be other relays in the bunch other than the initial connect to "java -jar ./RelayNodeClient.jar public.us-east.relay.mattcorallo.com 127.0.0.1:8333" ? reliability seems to be not so much currently. No dis on Matt. But why is he the only one to initiate the relay "string" for lack of better word.
I've seen it where it goes down and you can't connect. Connect to another?
Just saying
Thanks


Title: Re: How (and why) to use the Relay Network
Post by: kano on May 30, 2015, 06:53:11 AM
Well I connected to east also and ... all the transactions sent to west came back on east :P
Each time one went out west another would come in on east the same size.
So yeah seems like there's some problems with the relay.

I do still see runs of receives (like just now as I write this after stopping east again) but they never last long.

Edit: heh - well it's finally acting OK now for the last 5 minutes :)
Lasted about an hour and a half or so.
But back to me only sending again (nothing received)

Edit: and it's back working OK again.


Title: Re: How (and why) to use the Relay Network
Post by: kano on June 01, 2015, 04:28:54 AM
Looks like the relay is messed up at the moment.
It seems to be resending the last 1000+ blocks again ...

Its not really causing any problems but seeing so many ignored blocks arrive off the relay is a little disconcerting ...


Title: Re: How (and why) to use the Relay Network
Post by: kano on June 02, 2015, 04:36:15 AM
Another problem with the relay today.

Invalid blocks were coming through for a while which actually resulted in drastically slowing down block acceptance.
I run multiple relays and multiple bitcoinds on multiple nodes so I was able to see that only the relay connected bitcoinds had the problem.

Here's a few (debug.log UTC)
The UpdateTip in each case is when the bitcoind 'later' got it from the net, not via the relay
Code:
2015-06-02 03:55:40 ERROR: CheckBlock() : hashMerkleRoot mismatch
2015-06-02 03:55:40 ERROR: ProcessNewBlock : CheckBlock FAILED
2015-06-02 03:55:40 Misbehaving: 127.0.0.1:37844 (600 -> 700)
2015-06-02 03:55:42 UpdateTip: new best=000000000000000016f785f6c56856755d3fc89ca3ef005064ca10400872c421  height=359029  log2_work=82.873403  tx=70633458  date=2015-06-02 03:54:37 progress=0.999999  cache=5511

2015-06-02 03:56:40 ERROR: CheckBlock() : hashMerkleRoot mismatch
2015-06-02 03:56:40 ERROR: ProcessNewBlock : CheckBlock FAILED
2015-06-02 03:56:40 Misbehaving: 127.0.0.1:46865 (500 -> 600)
2015-06-02 03:57:21 UpdateTip: new best=00000000000000000b3f90e0f60046423db6b2cac055f41290ae29f966433fc9  height=359030  log2_work=82.873437  tx=70633604  date=2015-06-02 03:56:13 progress=0.999999  cache=6156

2015-06-02 04:08:39 ERROR: CheckBlock() : hashMerkleRoot mismatch
2015-06-02 04:08:39 ERROR: ProcessNewBlock : CheckBlock FAILED
2015-06-02 04:08:39 Misbehaving: 127.0.0.1:46865 (600 -> 700)
2015-06-02 04:08:42 CreateNewBlock(): total size 600611
2015-06-02 04:08:42 UpdateTip: new best=00000000000000000fa58e5a02b8676291bb491192a738a6d800f4bef296f3a8  height=359031  log2_work=82.87347  tx=70634550  date=2015-06-02 04:14:25 progress=1.000006  cache=8546
In the above case I was running both east and west relay connections (as you can see they came from both)

On the same node there's another bitcoind not connected to the relay and it was getting the same blocks at roughly the same time, but without errors.

However, on another node somewhere else on the planet also connected to the relay, I didn't get all of them, but only the last one:
Code:
2015-06-02 04:08:39 ERROR: CheckBlock() : hashMerkleRoot mismatch
2015-06-02 04:08:39 ERROR: ProcessNewBlock : CheckBlock FAILED
2015-06-02 04:08:39 Misbehaving: 127.0.0.1:45711 (0 -> 100) BAN THRESHOLD EXCEEDED
2015-06-02 04:08:39 Warning: not banning local peer 127.0.0.1:45711!
2015-06-02 04:08:39 UpdateTip: new best=00000000000000000fa58e5a02b8676291bb491192a738a6d800f4bef296f3a8  height=359031  log2_work=82.87347  tx=70634550  date=2015-06-02 04:14:25 progress=1.000006  cache=8074
2015-06-02 04:08:40 receive version message: /RelayNetworkClient:42/: version 70000, blocks=0, us=[::]:0, peer=4901, peeraddr=127.0.0.1:33197

Then it stopped after block 359031


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on June 15, 2015, 06:16:36 PM
Sorry for this thread being completely dead over the past few weeks. I was working hard on this and then got distracted with Sidechain Elements Alpha release and the blocksize debate. In any case, I pushed a series of updates yesterday and today which include:
  • Fixed a bug on the server where servers were not properly filtering transactions, allowing at best DoSing of nodes (some people saw this as 100% bitcoin node usage) and at worst, getting relay clients banned from local bitcoin nodes.
  • Some simple improvements that speed things up as much as 50%
  • Fixed bug that might have allowed for duplicate block sends
  • Update clients to send their local mempool on first connect/reconect, making the first block(s) sent also compress well
  • Removed the old Java/Python clients, they're slow and dumb - use the C++ ones

Note that these updates include some great client-side changes, though things should still work fine if you dont.

This still leaves the merkle hash tree mismatches, which I've been aware of for a while but are quite hard to track down :/ (oh well, if we miss a few blocks, we miss a few blocks, this is a backup network :p).

Also put up a website at http://bitcoinrelaynetwork.org/ (http://bitcoinrelaynetwork.org/), which should have the latest information. I want to put up a status flag there, but thats for later.


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on June 16, 2015, 01:39:50 AM
Oh, and I believe the merkle tree issues should (finally) be fixed now as well :)


Title: Re: How (and why) to use the Relay Network
Post by: kano on June 16, 2015, 08:31:41 AM
Sorry for this thread being completely dead over the past few weeks. I was working hard on this and then got distracted with Sidechain Elements Alpha release and the blocksize debate. In any case, I pushed a series of updates yesterday and today which include:
  • Fixed a bug on the server where servers were not properly filtering transactions, allowing at best DoSing of nodes (some people saw this as 100% bitcoin node usage) and at worst, getting relay clients banned from local bitcoin nodes.
  • Some simple improvements that speed things up as much as 50%
  • Fixed bug that might have allowed for duplicate block sends
  • Update clients to send their local mempool on first connect/reconect, making the first block(s) sent also compress well
  • Removed the old Java/Python clients, they're slow and dumb - use the C++ ones

Note that these updates include some great client-side changes, though things should still work fine if you dont.

This still leaves the merkle hash tree mismatches, which I've been aware of for a while but are quite hard to track down :/ (oh well, if we miss a few blocks, we miss a few blocks, this is a backup network :p).

Also put up a website at http://bitcoinrelaynetwork.org/ (http://bitcoinrelaynetwork.org/), which should have the latest information. I want to put up a status flag there, but thats for later.
Thanks for this.
Updating a few nodes to see how many of my bitcoin problems are relay and how many are 0.10.x exploit network problems :D
(I run bitcoinds without the relay for comparison)


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on June 17, 2015, 03:15:55 AM
Actually, just pushed yet another big performance win. Things should be back down to much quicker-than-latency compression runs.


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on June 17, 2015, 03:16:35 AM
Oh, and a big memory usage reduction win, too, though clients dont care too much about that :).


Title: Re: How (and why) to use the Relay Network
Post by: loshia on June 17, 2015, 06:48:05 AM
Oh, and a big memory usage reduction win, too, though clients dont care too much about that :).

I do not think so ;)
I am a sawp hater ;D
Thanks Matt great job!


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on June 17, 2015, 09:38:35 PM
I do not think so ;)
I am a sawp hater ;D
Thanks Matt great job!
Well the client-side stuff wont even use more than a few 10s of MB, so I dont think thats an issue for anyone?


Title: Re: How (and why) to use the Relay Network
Post by: loshia on June 18, 2015, 03:26:00 AM
I do not think so ;)
I am a sawp hater ;D
Thanks Matt great job!
Well the client-side stuff wont even use more than a few 10s of MB, so I dont think thats an issue for anyone?
Honestly speaking I did not watch old client mem usage at all. My mem usage issues were not because of your client. What I wanted to say is that we do care about mem usage in general.


Title: Re: How (and why) to use the Relay Network
Post by: kano on June 18, 2015, 07:25:07 AM
I do not think so ;)
I am a sawp hater ;D
Thanks Matt great job!
Well the client-side stuff wont even use more than a few 10s of MB, so I dont think thats an issue for anyone?
Honestly speaking I did not watch old client mem usage at all. My mem usage issues were not because of your client. What I wanted to say is that we do care about mem usage in general.
Get more ram :)
Relay uses about 10Mb of ram at the moment ... nothing compared to anything else running on my pool.


Title: Re: How (and why) to use the Relay Network
Post by: loshia on June 18, 2015, 07:46:26 AM
I do not think so ;)
I am a sawp hater ;D
Thanks Matt great job!
Well the client-side stuff wont even use more than a few 10s of MB, so I dont think thats an issue for anyone?
Honestly speaking I did not watch old client mem usage at all. My mem usage issues were not because of your client. What I wanted to say is that we do care about mem usage in general.
Get more ram :)
Relay uses about 10Mb of ram at the moment ... nothing compared to anything else running on my pool.
I know:)
once again i was speaking in general

for the record ;)

             total       used       free     shared    buffers     cached
Mem:      16431628    6109668   10321960          0     393708    3062792
-/+ buffers/cache:    2653168   13778460
Swap:      9959420          0    9959420

Now Ontopic new relay client with log filtered out



Thu Jun 18 08:28:53 EEST 2015: Starting relaynetworkclient
Connected to bitcoind with version 70002
Finished connect handshake with bitcoind
Closing relay socket, failed to read message header (104: Connection reset by peer)

Connected to relay node with protocol version the blocksize
[2015-06-18 05:56:02+00] 000000000000000004fd86600f6a12e5186ec18f11d7502afba3b7f7e00cae1a Block recv'd, size 932103 with 5222 bytes on the wire
[2015-06-18 05:58:00+00] 00000000000000000bb1ed574ab76212bc3fd86fad043e48a804b5baab873114 Block recv'd, size 924435 with 1573 bytes on the wire
[2015-06-18 06:03:14+00] 000000000000000010e5b0cdfc902b4b7f700177dd400f411f85bb861837fe42 Block recv'd, size 213069 with 827 bytes on the wire
[2015-06-18 06:08:58+00] 00000000000000000d7ba82013c1bd3354330dfab5406e3b5b31d779bae7306d Block recv'd, size 298966 with 1170 bytes on the wire
[2015-06-18 06:22:16+00] 000000000000000008a705191b01905215e1c37de8c4fd5f3c8aec8f4a98fa3f Block recv'd, size 438564 with 1899 bytes on the wire
[2015-06-18 06:24:21+00] 00000000000000001023e903ecbc7d4308c2c0659c92c5bb8d67e95341b81990 Block recv'd, size 118202 with 561 bytes on the wire
[2015-06-18 06:24:47+00] 0000000000000000121fe92d40e84a77c5e1a3e2aa0ef202f2c150e82c7fd1ce Block sent, size 43943 with 35187 bytes on the wire
[2015-06-18 06:24:52+00] 0000000000000000121fe92d40e84a77c5e1a3e2aa0ef202f2c150e82c7fd1ce Block recv'd, size 43919 with 4917 bytes on the wire
[2015-06-18 06:54:13+00] 000000000000000014e4aca7174b5f4468836a7569147b1b6ed787b842869e05 Block recv'd, size 749195 with 3347 bytes on the wire
[2015-06-18 07:05:45+00] 00000000000000000dc26e1e68c1c04e34db2faeaa2771b0156738d463e074bf Block sent, size 707268 with 603451 bytes on the wire
[2015-06-18 07:05:46+00] 00000000000000000dc26e1e68c1c04e34db2faeaa2771b0156738d463e074bf Block recv'd, size 707244 with 1880 bytes on the wire
[2015-06-18 07:09:56+00] 0000000000000000148e854a12e5eb378e5adaf6f8f5e416963e6e78bd0b6e1a Block recv'd, size 201317 with 952 bytes on the wire
[2015-06-18 07:10:20+00] 00000000000000000d1e68b1aabb79565f8307b97655d2a21c6f99b0d209a989 Block sent, size 26317 with 24792 bytes on the wire
[2015-06-18 07:10:39+00] 00000000000000000d1e68b1aabb79565f8307b97655d2a21c6f99b0d209a989 Block recv'd, size 26293 with 229 bytes on the wire
[2015-06-18 07:30:18+00] 0000000000000000119247bbeea1fa3ae3697482e9d1ec294e7d151e5927c583 Block recv'd, size 741555 with 2971 bytes on the wire
[2015-06-18 07:32:34+00] 000000000000000007802e4a62af5b844a93271cb6ab6d14285a4fa34c3b23fe Block recv'd, size 115723 with 395 bytes on the wire

And i am faster with two blocks only  
There is no match between well connected bitcoin deamon and mat realy

Thanks once again Matt!


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on June 21, 2015, 07:08:43 AM
Posted some anonymized stats for those interested at http://bitcoinrelaynetwork.org/stats.html. I had rotated the logs not too long ago because they changed format, so they only go back a few days, but I'll update them every now and again (or when pinged) and they should show more history.


Title: Re: How (and why) to use the Relay Network
Post by: xyzzy099 on June 21, 2015, 10:22:28 PM
I am trying to upgrade to the latest client on github, but it is not working for me for reasons I don't understand.  The old client still seems to work, but when I try to start the new one, I get this:

Code:
relaynetworkclient.exe public.us-east.relay.mattcorallo.com 127.0.0.1 8333
Closing relay socket, failed to read message header (0: )
127.0.0.1 Disconnect: failed to read message header (No error)
127.0.0.1 Disconnect: failed to read message header (No error)
Closing relay socket, failed to read message header (0: )
127.0.0.1 Disconnect: failed to read message header (No error)
Closing relay socket, failed to read message header (0: )
127.0.0.1 Disconnect: failed to read message header (No error)
Closing relay socket, failed to read message header (0: )

Any ideas what the problem might be?


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on June 22, 2015, 09:37:29 PM
Any ideas what the problem might be?
The problem is that Windows is an absolutely terrible OS...but it should work now.


Title: Re: How (and why) to use the Relay Network
Post by: xyzzy099 on June 23, 2015, 02:54:22 AM
Any ideas what the problem might be?
The problem is that Windows is an absolutely terrible OS...but it should work now.

Yep, it works great now.  Thanks! :)


Title: Re: How (and why) to use the Relay Network
Post by: igorwhite on June 23, 2015, 04:01:28 PM
Hello!
Friends, Colleagues.
I read the whole thread of the forum and did not understand.
Explain to me how to run a Relay Network + p2pool?



Title: Re: How (and why) to use the Relay Network
Post by: p3yot33at3r on June 23, 2015, 06:01:06 PM
Since the last update (20 hours ago) I'm unable to build the client on Xubuntu 64bit. When I execute the command "make -f Makefile" from within the c++ folder - I get the following error:

Code:
yasm -f x64 -f elf64 -X gnu -g dwarf2 -D LINUX -o crypto/sha256_code_release/sha256_avx2_rorx2.a crypto/sha256_code_release/sha256_avx2_rorx2.asm
make: yasm: Command not found
make: *** [crypto/sha256_code_release/sha256_avx2_rorx2.a] Error 127

Everything worked fine until the last update  :(

EDIT: The pre-compiled binary will also not run on 64bit system, giving the following error:

Code:
relaynetworkclient: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by relaynetworkclient)

Do I need to download & install dependences now?

EDIT2: I've reverted to the previous build until further news  ;)


Title: Re: How (and why) to use the Relay Network
Post by: p3yot33at3r on June 23, 2015, 06:21:39 PM
Hello!
Friends, Colleagues.
I read the whole thread of the forum and did not understand.
Explain to me how to run a Relay Network + p2pool?


Have a read:

http://sourceforge.net/p/bitcoin/mailman/message/32676543/

http://bitcoinrelaynetwork.org/

I suggest use the prebuilt binary (if it works) & running it from within the folder for simplicity, using the nearest server listed to you  ;)


Title: Re: How (and why) to use the Relay Network
Post by: igorwhite on June 23, 2015, 06:59:59 PM
p3yot33at3r

I read everything. Server public.eu.relay.mattcorallo.com . I can't understand that need to config run bitcoind + relay network + p2pool



Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on June 24, 2015, 01:39:48 AM
Since the last update (20 hours ago) I'm unable to build the client on Xubuntu 64bit. When I execute the command "make -f Makefile" from within the c++ folder - I get the following error:

Code:
yasm -f x64 -f elf64 -X gnu -g dwarf2 -D LINUX -o crypto/sha256_code_release/sha256_avx2_rorx2.a crypto/sha256_code_release/sha256_avx2_rorx2.asm
make: yasm: Command not found
make: *** [crypto/sha256_code_release/sha256_avx2_rorx2.a] Error 127

Do I need to download & install dependences now?

You need to install yasm, as the error indicates :p


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on June 24, 2015, 01:41:06 AM
p3yot33at3r

I read everything. Server public.eu.relay.mattcorallo.com . I can't understand that need to config run bitcoind + relay network + p2pool
Just run bitcoind and p2pool as you normally would, then run the relaynetwork client with "relaynetworkclient public.eu.relay.mattcorallo the-ip-or-hostname-of-your-bitcoind 8333"


Title: Re: How (and why) to use the Relay Network
Post by: jonnybravo0311 on June 24, 2015, 02:52:46 AM
Since the last update (20 hours ago) I'm unable to build the client on Xubuntu 64bit. When I execute the command "make -f Makefile" from within the c++ folder - I get the following error:

Code:
yasm -f x64 -f elf64 -X gnu -g dwarf2 -D LINUX -o crypto/sha256_code_release/sha256_avx2_rorx2.a crypto/sha256_code_release/sha256_avx2_rorx2.asm
make: yasm: Command not found
make: *** [crypto/sha256_code_release/sha256_avx2_rorx2.a] Error 127

Everything worked fine until the last update  :(

EDIT: The pre-compiled binary will also not run on 64bit system, giving the following error:

Code:
relaynetworkclient: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by relaynetworkclient)

Do I need to download & install dependences now?

EDIT2: I've reverted to the previous build until further news  ;)
Code:
sudo apt-get install yasm
Once it's installed just run make and it'll compile just fine.


Title: Re: How (and why) to use the Relay Network
Post by: igorwhite on June 24, 2015, 09:58:38 AM
p3yot33at3r

I read everything. Server public.eu.relay.mattcorallo.com . I can't understand that need to config run bitcoind + relay network + p2pool
Just run bitcoind and p2pool as you normally would, then run the relaynetwork client with "relaynetworkclient public.eu.relay.mattcorallo the-ip-or-hostname-of-your-bitcoind 8333"


user@p2pool:~/RelayNode/client$ ./relaynetworkclient public.eu.relay.mattcorallo.com 127.0.0.1 8333
Illegal instruction (memory dump)

????

Sorry

Assembled on a new relaynetworkclient ALL OK


Title: Re: How (and why) to use the Relay Network
Post by: p3yot33at3r on June 24, 2015, 02:04:28 PM
Since the last update (20 hours ago) I'm unable to build the client on Xubuntu 64bit. When I execute the command "make -f Makefile" from within the c++ folder - I get the following error:

Code:
yasm -f x64 -f elf64 -X gnu -g dwarf2 -D LINUX -o crypto/sha256_code_release/sha256_avx2_rorx2.a crypto/sha256_code_release/sha256_avx2_rorx2.asm
make: yasm: Command not found
make: *** [crypto/sha256_code_release/sha256_avx2_rorx2.a] Error 127

Do I need to download & install dependences now?

You need to install yasm, as the error indicates :p

Yeah, I figured that was what I needed - just wanted to be sure. All good again, thanks for your work, great stuff  ;)


Title: Re: How (and why) to use the Relay Network
Post by: igorwhite on June 24, 2015, 06:46:06 PM
Matt Corallo, Many thanks for your work!
DOA on my node down 3-5%
If interested, I can provide free server in Russia (Moscow) to expand the Relay Network

Best Regards Igor.


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on June 24, 2015, 07:05:22 PM
If interested, I can provide free server in Russia (Moscow) to expand the Relay Network
Are your ping times to the EU/AMS server particularly bad? Unless your ping times/packet loss to that server are particularly bad, there isnt much use in adding a new server in moscow.


Title: Re: How (and why) to use the Relay Network
Post by: igorwhite on June 24, 2015, 07:20:37 PM
ping to eu.relay -- 52-57 ms


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on June 24, 2015, 08:22:44 PM
ping to eu.relay -- 52-57 ms
What about ping from where such a server would be to eu, plus your pings to there?


Title: Re: How (and why) to use the Relay Network
Post by: igorwhite on June 24, 2015, 09:05:21 PM
Quote
What about ping from where such a server would be to eu, plus your pings to there?
I do not understand question
My ping to the server  public.eu.relay.mattcorallo.com -- 52-57ms
My ping to the server  yandex.de and yandex.ru -- 2ms


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on June 25, 2015, 06:26:40 AM
My ping to the server  public.eu.relay.mattcorallo.com -- 52-57ms
My ping to the server  yandex.de and yandex.ru -- 2ms
I dont think you can buy a server on yandex that is colocated to +/- everywhere :p. What about pings to a Moscow looking glass and pings from there to the eu node?
I processed block sources on the relay network and there isnt much east of Germany, so I'm not sure its so worth it either way. Higher latency here doesnt matter unless you have high packet loss or miners broadcasting blocks from Russia.


Title: Re: How (and why) to use the Relay Network
Post by: igorwhite on June 25, 2015, 06:40:15 AM
Of course I can not buy a server Yandex.
But I place the server for free on optical line 500Mbit/s.
I have many friends in Irkutsk, Murom, Nizhny Novgorod, Saratov. Ping from their servers to thepublic.eu.relay.mattcorallo.com ~ 150ms


Title: Re: How (and why) to use the Relay Network
Post by: mdude77 on June 28, 2015, 01:38:10 AM
Since the last update (20 hours ago) I'm unable to build the client on Xubuntu 64bit. When I execute the command "make -f Makefile" from within the c++ folder - I get the following error:

Code:
yasm -f x64 -f elf64 -X gnu -g dwarf2 -D LINUX -o crypto/sha256_code_release/sha256_avx2_rorx2.a crypto/sha256_code_release/sha256_avx2_rorx2.asm
make: yasm: Command not found
make: *** [crypto/sha256_code_release/sha256_avx2_rorx2.a] Error 127

Everything worked fine until the last update  :(

EDIT: The pre-compiled binary will also not run on 64bit system, giving the following error:

Code:
relaynetworkclient: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by relaynetworkclient)

Do I need to download & install dependences now?

EDIT2: I've reverted to the previous build until further news  ;)
Code:
sudo apt-get install yasm
Once it's installed just run make and it'll compile just fine.

Confirmed, once I installed yasm it compiled just fine on my x64 node.  The precompiled version would not run, despite glibcxx already being there.

M


Title: Re: How (and why) to use the Relay Network
Post by: kano on June 30, 2015, 12:24:50 PM
Relay is 'under attack'? again?
Receiving a lot more transactions than usual, but most of them the size is 599 or 600 - so clearly someone is messing with the relay.
They've stopped for now - well there's few if any 599 or 600 bytes - but not zero - still a few 599 showing up that may or may not be related to it - but not enough to care about at the moment.
Spoke too soon :P
It's back on and off.


Title: Re: How (and why) to use the Relay Network
Post by: amaclin on June 30, 2015, 12:34:15 PM
Relay is 'under attack'? again?
Receiving a lot more transactions than usual, but most of them the size is 599 or 600 - so clearly someone is messing with the relay.

Seems to me that somebody is spamming blockchain again
It is visible on http://webbtc.com/ and https://blockchain.info/
Last blocks from 363186 to 363196 (11 in a row!) are filled to maximum sizes


Title: Re: How (and why) to use the Relay Network
Post by: loshia on June 30, 2015, 02:00:29 PM
Relay is 'under attack'? again?
Receiving a lot more transactions than usual, but most of them the size is 599 or 600 - so clearly someone is messing with the relay.

Seems to me that somebody is spamming blockchain again
It is visible on http://webbtc.com/ and https://blockchain.info/
Last blocks from 363186 to 363196 (11 in a row!) are filled to maximum sizes

BLk size depends on POOL bitcoind config only ;)
Max size=Max fee so it is done on purpose


Title: Re: How (and why) to use the Relay Network
Post by: amaclin on June 30, 2015, 02:15:15 PM
BLk size depends on POOL bitcoind config only ;)
Max size=Max fee so it is done on purpose
I know.
FYI: https://bitcointalk.org/index.php?topic=1098263.0


Title: Re: How (and why) to use the Relay Network
Post by: loshia on June 30, 2015, 02:19:10 PM
BLk size depends on POOL bitcoind config only ;)
Max size=Max fee so it is done on purpose
I know.
FYI: https://bitcointalk.org/index.php?topic=1098263.0
Good so it might not be spam in that case :D


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on July 01, 2015, 08:17:40 PM
Good so it might not be spam in that case :D
Not spam? Not sure how that doesnt qualify as spam...


Title: Re: How (and why) to use the Relay Network
Post by: loshia on July 02, 2015, 05:14:08 AM
Good so it might not be spam in that case :D
Not spam? Not sure how that doesnt qualify as spam...

Matt,
My intentions are not to argue with you. But for me each valid TX which contains fee is not a spam.
No matter if it was useless and generated in artificial way or not
For instance
https://bitcointalk.org/index.php?topic=1098263.0
Let us imagine that current BTC transaction rules are 0.1 BTC min fee in order for TX to be accepted at all. So i do not mind the folks from the above thread to "SPAM" network and experiment :D

In order to overcome this in my opinion the Min required fee must be increased and TX with 0 fee shall be forbidden. There is no free lunch and that is all. Let us not forget that after some years when block reward decreases near ZERO all mining shall pay for its cost from TX only  ;) Asuming BTC price does not reach 10K and net diff stays high.... No mining no TX at all. So an equilibrium must be found
Sooner or later it must be done. Sooner the better..

Just my two cents


Title: Re: How (and why) to use the Relay Network
Post by: eleuthria on July 02, 2015, 09:48:29 PM
My intentions are not to argue with you. But for me each valid TX which contains fee is not a spam.

Sending money to yourself constantly is spam.  I don't care what fees you pay.  It is spam.  Period.  You are filling the network and everybody's hard drives with JUNK data that serves absolutely no purpose.  The "stress test" transactions were spam by any rational definition. 

Arguing that because a fee is paid it's not spam is simply wrong.  I get a ton of junk mail in my post office box that companies pay to have delivered to everybody.  Doesn't change the fact that it is junk mail.


Title: Re: How (and why) to use the Relay Network
Post by: loshia on July 03, 2015, 02:33:55 PM
My intentions are not to argue with you. But for me each valid TX which contains fee is not a spam.

Sending money to yourself constantly is spam.  I don't care what fees you pay.  It is spam.  Period.  You are filling the network and everybody's hard drives with JUNK data that serves absolutely no purpose.  The "stress test" transactions were spam by any rational definition. 

Arguing that because a fee is paid it's not spam is simply wrong.  I get a ton of junk mail in my post office box that companies pay to have delivered to everybody.  Doesn't change the fact that it is junk mail.
Oki let us not fight because of it. everybody has own oppinion yours and mat is spam my is opposite
Peace...


Title: Re: How (and why) to use the Relay Network
Post by: p3yot33at3r on July 04, 2015, 03:19:12 PM
Hmmm....I'm unable to compile the latest from git or run the binary of this latest release on Xubuntu 64bit. Has another dependency been added that I'm not aware of?

Is it only me? (again)  :P

My compile log:

Code:
rig@rig:~/RelayNode/c++$ make -f Makefile
yasm -f x64 -f elf64 -X gnu -g dwarf2 -D LINUX -o crypto/sha256_code_release/sha256_avx2_rorx2.a crypto/sha256_code_release/sha256_avx2_rorx2.asm
yasm -f x64 -f elf64 -X gnu -g dwarf2 -D LINUX -o crypto/sha256_code_release/sha256_avx1.a crypto/sha256_code_release/sha256_avx1.asm
yasm -f x64 -f elf64 -X gnu -g dwarf2 -D LINUX -o crypto/sha256_code_release/sha256_sse4.a crypto/sha256_code_release/sha256_sse4.asm
g++ -I. -g -DFORCE_LE -DNDEBUG -O3 -march=native -mtune=native -flto -std=c++11 -Wall -I/usr/include   -c -o flaggedarrayset.o flaggedarrayset.cpp
g++ -I. -g -DFORCE_LE -DNDEBUG -O3 -march=native -mtune=native -flto -std=c++11 -Wall -I/usr/include   -c -o utils.o utils.cpp
g++ -I. -g -DFORCE_LE -DNDEBUG -O3 -march=native -mtune=native -flto -std=c++11 -Wall -I/usr/include   -c -o relayprocess.o relayprocess.cpp
g++ -I. -g -DFORCE_LE -DNDEBUG -O3 -march=native -mtune=native -flto -std=c++11 -Wall -I/usr/include   -c -o p2pclient.o p2pclient.cpp
g++ -I. -g -DFORCE_LE -DNDEBUG -O3 -march=native -mtune=native -flto -std=c++11 -Wall -I/usr/include   -c -o connection.o connection.cpp
connection.cpp: In member function ‘void Connection::do_send_bytes(const std::shared_ptr<std::vector<unsigned char> >&, int)’:
connection.cpp:193:38: warning: ignoring return value of ‘ssize_t write(int, const void*, size_t)’, declared with attribute warn_unused_result [-Wunused-result]
   write(processor.pipe_write, "1", 1);
                                      ^
connection.cpp: In member function ‘void Connection::maybe_send_bytes(const std::shared_ptr<std::vector<unsigned char> >&, int)’:
connection.cpp:217:38: warning: ignoring return value of ‘ssize_t write(int, const void*, size_t)’, declared with attribute warn_unused_result [-Wunused-result]
   write(processor.pipe_write, "1", 1);
                                      ^
connection.cpp: In static member function ‘static void Connection::do_setup_and_read(Connection*)’:
connection.cpp:282:38: warning: ignoring return value of ‘ssize_t write(int, const void*, size_t)’, declared with attribute warn_unused_result [-Wunused-result]
   write(processor.pipe_write, "1", 1);
                                      ^
connection.cpp: In member function ‘ssize_t Connection::read_all(char*, size_t)’:
connection.cpp:309:40: warning: ignoring return value of ‘ssize_t write(int, const void*, size_t)’, declared with attribute warn_unused_result [-Wunused-result]
     write(processor.pipe_write, "1", 1);
                                        ^
g++ -I. -g -DFORCE_LE -DNDEBUG -O3 -march=native -mtune=native -flto -std=c++11 -Wall -I/usr/include   -c -o crypto/sha2.o crypto/sha2.cpp
g++ -I. -g -DFORCE_LE -DNDEBUG -O3 -march=native -mtune=native -flto -std=c++11 -Wall -I/usr/include   -c -o client.o client.cpp
g++ -I. -g -DFORCE_LE -DNDEBUG -O3 -march=native -mtune=native -flto -std=c++11 -Wall -I/usr/include crypto/sha256_code_release/sha256_avx2_rorx2.a crypto/sha256_code_release/sha256_avx1.a crypto/sha256_code_release/sha256_sse4.a flaggedarrayset.o utils.o relayprocess.o p2pclient.o connection.o crypto/sha2.o client.o -Wl,--no-as-needed -pthread -lresolv -o relaynetworkclient
rig@rig:~/RelayNode/c++$

Sorry for my Linux noobness........


Title: Re: How (and why) to use the Relay Network
Post by: jonnybravo0311 on July 04, 2015, 04:03:19 PM
I see some warnings but don't see any errors there.  Am I missing something?


Title: Re: How (and why) to use the Relay Network
Post by: p3yot33at3r on July 04, 2015, 04:15:44 PM
I see some warnings but don't see any errors there.  Am I missing something?

It's weird. I never had any warnings before when compiling (apart from when I had to add yasm), & I've never had any problems running either the pre-compiled or the self compiled one, but this just refuses to run for some reason. I've had to revert back to the older version again, which compiles & runs perfectly..... ???


Title: Re: How (and why) to use the Relay Network
Post by: Duce on July 04, 2015, 07:14:53 PM
I too have the same results. I fixed my last issue of a missing GLIBC...21 but now I am in the same boat as P3....
I have been running the RelayNode since it came out last year and never had any issues until the last two versions. I see that many are not having issues and it is running fine or I am sure this would have been a hot item as the Relay Network is a game changer for the community. I am sure this is an oversight on my part so any assistance or insight would be appreciated.


Title: Re: How (and why) to use the Relay Network
Post by: p3yot33at3r on July 05, 2015, 08:38:08 AM
I see some warnings but don't see any errors there.  Am I missing something?

It's weird. I never had any warnings before when compiling (apart from when I had to add yasm), & I've never had any problems running either the pre-compiled or the self compiled one, but this just refuses to run for some reason. I've had to revert back to the older version again, which compiles & runs perfectly..... ???

Maybe if Matt could post a list of any required/added dependencies on the the git page/web page? At least then we could check....... ;)

It's a bummer not being able to take advantage of the latest improvements...... :(


Title: Re: How (and why) to use the Relay Network
Post by: jonnybravo0311 on July 05, 2015, 04:21:31 PM
I see what you're meaning... I thought you were stating you got errors on the compilation, which was my confusion.  I grabbed the latest from git and compiled.  Saw the same warnings, but the client built.  When I tried to run the client, it would go through the new picking process (since I didn't specify a server), but then segfaults.  Picking a server manually causes it to segfault right out of the gate.

Matt, I'm not sure how much help this will provide, but here's the output from gdb when trying to run the latest pull from git.  I'm on Ubuntu 14.04 x64

Code:
miner@devildog:~/RelayNode/c++$ gdb --args ./relaynetworkclient 127.0.0.1 8333
GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./relaynetworkclient...done.
(gdb) r
Starting program: /home/miner/RelayNode/c++/relaynetworkclient 127.0.0.1 8333
Traceback (most recent call last):
  File "/usr/share/gdb/auto-load/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19-gdb.py", line 63, in <module>
    from libstdcxx.v6.printers import register_libstdcxx_printers
ImportError: No module named 'libstdcxx'
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff6dbb700 (LWP 24308)]
[New Thread 0x7ffff65ba700 (LWP 24309)]
[New Thread 0x7ffff5db9700 (LWP 24310)]
[New Thread 0x7ffff53ac700 (LWP 24311)]
[New Thread 0x7ffff49a5700 (LWP 24312)]
[New Thread 0x7fffe7fff700 (LWP 24313)]
[New Thread 0x7fffe77fe700 (LWP 24314)]
[New Thread 0x7fffe6ffd700 (LWP 24315)]
[New Thread 0x7fffe67fc700 (LWP 24316)]
[New Thread 0x7fffe5ffb700 (LWP 24317)]
[New Thread 0x7fffe57fa700 (LWP 24318)]
[New Thread 0x7fffe4ff9700 (LWP 24319)]
[New Thread 0x7fffc7fff700 (LWP 24320)]
[New Thread 0x7fffc77fe700 (LWP 24321)]
[New Thread 0x7fffc6ffd700 (LWP 24322)]
[New Thread 0x7fffc67fc700 (LWP 24323)]
[New Thread 0x7fffc5ffb700 (LWP 24324)]
[New Thread 0x7fffc57fa700 (LWP 24325)]
[New Thread 0x7fffc4ff9700 (LWP 24326)]
[New Thread 0x7fffaffff700 (LWP 24327)]
[New Thread 0x7fffaf7fe700 (LWP 24328)]
[Thread 0x7fffe77fe700 (LWP 24314) exited]
[Thread 0x7fffe4ff9700 (LWP 24319) exited]
[Thread 0x7fffe5ffb700 (LWP 24317) exited]
[Thread 0x7fffe57fa700 (LWP 24318) exited]
[Thread 0x7fffaf7fe700 (LWP 24328) exited]
[Thread 0x7fffe67fc700 (LWP 24316) exited]
[Thread 0x7fffc6ffd700 (LWP 24322) exited]
[Thread 0x7fffe7fff700 (LWP 24313) exited]
[Thread 0x7fffc77fe700 (LWP 24321) exited]
[Thread 0x7fffc5ffb700 (LWP 24324) exited]
[Thread 0x7fffc4ff9700 (LWP 24326) exited]
[Thread 0x7fffc67fc700 (LWP 24323) exited]
[Thread 0x7fffc57fa700 (LWP 24325) exited]
[Thread 0x7fffe6ffd700 (LWP 24315) exited]
[Thread 0x7fffc7fff700 (LWP 24320) exited]
[Thread 0x7fffaffff700 (LWP 24327) exited]
[Thread 0x7ffff5db9700 (LWP 24310) exited]
[Thread 0x7ffff53ac700 (LWP 24311) exited]
[Thread 0x7ffff65ba700 (LWP 24309) exited]
[Thread 0x7ffff49a5700 (LWP 24312) exited]
Server 0 (public.us-east.relay.mattcorallo.com) took 2028 ms to respond 20 times.
Server 1 (public.us-west.relay.mattcorallo.com) took 1444 ms to respond 20 times.
Server 2 (public.eu.relay.mattcorallo.com) took 1589 ms to respond 20 times.
Server 3 (public.sgp.relay.mattcorallo.com) took 5057 ms to respond 20 times.
Using server public.01.relay.mattcorallo.com
[New Thread 0x7fffaf7fe700 (LWP 24348)]
[New Thread 0x7fffaffff700 (LWP 24349)]
[New Thread 0x7fffc4ff9700 (LWP 24350)]
[New Thread 0x7fffc57fa700 (LWP 24351)]
[Thread 0x7fffaf7fe700 (LWP 24348) exited]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffc4ff9700 (LWP 24350)]
0x0000000000409b07 in OutboundPersistentConnection::OutboundConnection::net_process(std::function<void (char const*)> const&) [clone .local.256] (this=<optimized out>, disconnect=...) at connection.h:90
90 static void do_setup_and_read(Connection* me);
(gdb) q
A debugging session is active.

Inferior 1 [process 24304] will be killed.

Quit anyway? (y or n) y


Title: Re: How (and why) to use the Relay Network
Post by: p3yot33at3r on July 05, 2015, 04:24:14 PM
Hi JB,

Did you also try running the pre-compiled binary by any chance?


Title: Re: How (and why) to use the Relay Network
Post by: jonnybravo0311 on July 05, 2015, 04:51:31 PM
Hi JB,

Did you also try running the pre-compiled binary by any chance?
OK... did some more digging into this.  I'm pretty sure the problem is that the latest code is requiring GLIBCXX_3.4.21.  Typically, that would be included in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.  However, when looking at the contents, I didn't see 3.4.21 listed - it only went up to 3.4.20.

How to get this resolved?  Here's what I did:
Code:
add-apt-repository ppa:ubuntu-toolchain-r/test
apt-get update
apt-get upgrade
apt-get dist-upgrade

Doing that, and then examining the library again, lo and behold the GLIBCXX_3.4.21 is there.  Now, I did:
Code:
make clean
make
Got the same warnings during the compilation... but this time the code actually executes without throwing a segfault:
Code:
miner@devildog:~/RelayNode/c++$ ./relaynetworkclient 127.0.0.1 8333
Server 0 (public.us-east.relay.mattcorallo.com) took 2031 ms to respond 20 times.
Server 1 (public.us-west.relay.mattcorallo.com) took 1429 ms to respond 20 times.
Server 2 (public.eu.relay.mattcorallo.com) took 1591 ms to respond 20 times.
Server 3 (public.sgp.relay.mattcorallo.com) took 5107 ms to respond 20 times.
Using server public.01.relay.mattcorallo.com
public.01.relay.mattcorallo.com Disconnect: failed to read message header (Connection reset by peer)
Connected to bitcoind with version 70002
Finished connect handshake with bitcoind
Sent transaction of size 189 to relay server
Sent transaction of size 487 to relay server
public.01.relay.mattcorallo.com Disconnect: failed to read message header (Broken pipe)
public.01.relay.mattcorallo.com Disconnect: failed to read message header (Connection reset by peer)
Sent transaction of size 335 to relay server
public.01.relay.mattcorallo.com Disconnect: failed to read message header (Connection reset by peer)
Connected to relay node with protocol version the blocksize
Received transaction of size 225 from relay server
Received transaction of size 371 from relay server
Received transaction of size 517 from relay server
Received transaction of size 669 from relay server
Received transaction of size 334 from relay server
Received transaction of size 225 from relay server
Received transaction of size 374 from relay server
Received transaction of size 373 from relay server
Received transaction of size 225 from relay server
Received transaction of size 668 from relay server
Received transaction of size 963 from relay server
Received transaction of size 996 from relay server
Received transaction of size 338 from relay server
Received transaction of size 335 from relay server
Received transaction of size 226 from relay server
Received transaction of size 2106 from relay server
Received transaction of size 225 from relay server
Received transaction of size 844 from relay server
Received transaction of size 519 from relay server
Received transaction of size 335 from relay server
Received transaction of size 335 from relay server
Received transaction of size 339 from relay server
Received transaction of size 191 from relay server
Received transaction of size 225 from relay server
Received transaction of size 374 from relay server
Received transaction of size 226 from relay server
Received transaction of size 225 from relay server
Received transaction of size 424 from relay server
Received transaction of size 373 from relay server
Received transaction of size 618 from relay server
Received transaction of size 225 from relay server
Received transaction of size 192 from relay server
Received transaction of size 2142 from relay server
Received transaction of size 334 from relay server
Received transaction of size 370 from relay server
Received transaction of size 634 from relay server
Received transaction of size 225 from relay server
Received transaction of size 191 from relay server
Received transaction of size 258 from relay server
Received transaction of size 3294 from relay server
Received transaction of size 334 from relay server
Received transaction of size 191 from relay server
Received transaction of size 373 from relay server
Received transaction of size 226 from relay server
Received transaction of size 223 from relay server
Received transaction of size 373 from relay server
Received transaction of size 336 from relay server
Sent transaction of size 225 to relay server
Sent transaction of size 371 to relay server
Sent transaction of size 517 to relay server
Sent transaction of size 669 to relay server
Sent transaction of size 334 to relay server
Sent transaction of size 225 to relay server


Title: Re: How (and why) to use the Relay Network
Post by: p3yot33at3r on July 05, 2015, 11:42:13 PM
Ah! So it wasn't me going mad then...... ;D

Thanks for the info JB - is it running OK still? No errors?


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on July 06, 2015, 03:09:16 AM
I see what you're meaning... I thought you were stating you got errors on the compilation, which was my confusion.  I grabbed the latest from git and compiled.  Saw the same warnings, but the client built.  When I tried to run the client, it would go through the new picking process (since I didn't specify a server), but then segfaults.  Picking a server manually causes it to segfault right out of the gate.

Matt, I'm not sure how much help this will provide, but here's the output from gdb when trying to run the latest pull from git.  I'm on Ubuntu 14.04 x64

Can you type "bt" from gdb after the segfault and post that? I'm not gonna be able to fix till tomorrow night, but it would be nice to see what's going on when I get to it.

What do you get if you just revert the commits related to the client picking the server automatically?


The glibcxx errors are because I'm building those on arch which is proverbially overachieving in its use of the latest versions of things... I'm not sure I want to post a working build for non-windows, though... The new stuff uses a sse-based sha implementation that needs to know what CPU you're using during build to pick the best implementation, not to mention that -march=native improves performance pretty significantly on my haswell box.


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on July 06, 2015, 03:11:43 AM
Hi JB,

Did you also try running the pre-compiled binary by any chance?
OK... did some more digging into this.  I'm pretty sure the problem is that the latest code is requiring GLIBCXX_3.4.21.  Typically, that would be included in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.  However, when looking at the contents, I didn't see 3.4.21 listed - it only went up to 3.4.20.

How to get this resolved?  Here's what I did:
Code:
add-apt-repository ppa:ubuntu-toolchain-r/test
apt-get update
apt-get upgrade
apt-get dist-upgrade

Doing that, and then examining the library again, lo and behold the GLIBCXX_3.4.21 is there.  Now, I did:
Code:
make clean
make
Got the same warnings during the compilation... but this time the code actually executes without throwing a segfault:

Oh, I missed this, can you try removing the toolchain update (or someone else) and commenting out the stuff related to the cname lookup call in client.cpp/utils.h/cpp?


Title: Re: How (and why) to use the Relay Network
Post by: p3yot33at3r on July 06, 2015, 10:25:34 AM
Hi Matt,

I didn't use the fix JB kindly suggested, as I thought I'd wait for confirmation from yourself first. If you'd like to tell me what you want me to do, in layman's terms due to my lack of Linux skills, I'll help if I can. I'm also using 14.04 64bit  :)

Edit: EU node down?


Title: Re: How (and why) to use the Relay Network
Post by: zvs on July 06, 2015, 05:42:12 PM
This seems to be relaying massive amounts of dust transactions, I had over 25000 stored.

Had to turn it off.  Now debug.log is getting spammed with

Code:
2015-07-06 17:40:14 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:14 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:14 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:14 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:14 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:14 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:14 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:14 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:14 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:14 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:14 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:14 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:14 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:14 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:14 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:14 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:14 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:14 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:14 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:14 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:14 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:14 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:14 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:14 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:14 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:14 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:14 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:14 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:14 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:14 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:14 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:14 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:14 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:14 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:14 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:14 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:14 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:14 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:14 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:14 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:14 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:14 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:14 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:14 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:14 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:14 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:14 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:14 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:14 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:14 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:14 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:14 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:14 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:14 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:14 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:14 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:14 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:14 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:14 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:14 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:14 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:14 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:14 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:14 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:14 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:14 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:14 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:14 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:14 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:14 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:14 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:14 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:14 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:14 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:14 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:14 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:14 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:15 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:15 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:15 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:15 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:15 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:15 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:15 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:15 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:15 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:15 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:15 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:15 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:15 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:15 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:15 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:15 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:15 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:15 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:15 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:15 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:15 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:15 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:15 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:15 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:15 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:15 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:15 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:15 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:15 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:15 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:15 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:15 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:15 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:15 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:15 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:15 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:15 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:15 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:15 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:15 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:15 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:15 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:15 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:15 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:15 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:15 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:15 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:15 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:15 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:15 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:15 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:15 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:15 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:15 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:15 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:15 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:15 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:15 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:15 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:15 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:15 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:16 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:17 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:17 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:17 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:17 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:17 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:17 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:17 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:17 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:17 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:17 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:17 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:17 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:17 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:17 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:17 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:17 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:17 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:17 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:17 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:17 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:17 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:17 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:17 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:17 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:17 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:17 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:17 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:17 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:17 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:17 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:17 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:17 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:17 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:17 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:17 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:17 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:17 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:17 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:17 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:17 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:17 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:17 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:17 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:17 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:17 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:17 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:17 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:17 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:17 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:17 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:17 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:17 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:17 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:17 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: free transaction rejected by rate limiter
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:18 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:19 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:19 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:19 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:19 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:19 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:19 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:19 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:19 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:19 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:19 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:19 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:19 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:19 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:19 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:19 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:19 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:19 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:19 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:19 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:19 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:19 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:19 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:19 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:19 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:19 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:19 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:19 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:19 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:19 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:19 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:19 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:19 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:19 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:19 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:19 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:19 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:19 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:19 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:19 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:19 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:19 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:19 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:19 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:19 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:19 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:19 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:19 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:19 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:19 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:19 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:19 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:19 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:19 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:19 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:19 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:19 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:19 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:19 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:20 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:21 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:21 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:21 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:21 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:21 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:21 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:21 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:21 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:21 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:21 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:21 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:21 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:21 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:21 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:21 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:21 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:21 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:21 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:21 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:21 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:21 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:21 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:21 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:21 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:21 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:21 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:21 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:21 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:21 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:21 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:21 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:21 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:21 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:21 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:21 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:21 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:21 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:21 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:21 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:21 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:21 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:21 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:21 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:21 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:21 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:21 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:21 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:21 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:21 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:21 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:21 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:21 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:21 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:22 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:22 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:22 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:22 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:22 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:22 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:22 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:22 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:22 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:22 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:22 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:22 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:22 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:22 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:22 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:22 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:22 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:22 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:22 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:22 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:22 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:22 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:22 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:22 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:22 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:22 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:22 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-07-06 17:40:22 ERROR: AcceptToMemoryPool: nonstandard transaction: dust

and a good 50% or more of my peers are sending me an inordinate amount of data


Title: Re: How (and why) to use the Relay Network
Post by: -ck on July 07, 2015, 12:07:14 AM
Up to date with git, commit 666d6cf603096880834eb4520d75ffb162bc0017

yasm installed, debian linux 64 bit

Any ideas?

Code:
crypto/sha256_code_release/sha256_avx2_rorx2.asm:665: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:665: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:665: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:665: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:665: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:665: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:665: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:665: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:665: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:665: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:665: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:665: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:668: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:668: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:668: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:668: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:668: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:668: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:668: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:668: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:668: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:668: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:668: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:668: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:668: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:668: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:668: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:668: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:668: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:668: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:668: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:668: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:668: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:668: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:668: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:668: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:696: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:696: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:696: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:696: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:696: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:696: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:696: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:696: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:696: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:696: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:696: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:696: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:696: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:696: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:696: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:696: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:696: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:696: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:696: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:696: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:696: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:696: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:696: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:696: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:697: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:697: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:697: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:697: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:697: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:697: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:697: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:697: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:697: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:697: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:697: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:697: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:697: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:697: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:697: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:697: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:697: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:697: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:697: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:697: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:697: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:697: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:697: error: instruction expected after label
crypto/sha256_code_release/sha256_avx2_rorx2.asm:697: error: instruction expected after label
make: *** [crypto/sha256_code_release/sha256_avx2_rorx2.a] Error 1

edit: I fixed it by disabling it attempting to build that file since it's not even included in my binary. Probably shouldn't build all the assembly files unconditionally.


Title: Re: How (and why) to use the Relay Network
Post by: kano on July 07, 2015, 02:23:51 AM
Hmm seems like the relay is pretty much overloaded and not doing it's job at all today.
One of my nodes is permanently sending tnxs to it, getting disconnected every few minutes, and never getting any blocks from it.
Oh well.


Title: Re: How (and why) to use the Relay Network
Post by: sorry2xs on July 07, 2015, 03:25:34 AM
does that affect confirmations?


Title: Re: How (and why) to use the Relay Network
Post by: btcash on July 07, 2015, 11:20:07 AM
Hmm seems like the relay is pretty much overloaded and not doing it's job at all today.
One of my nodes is permanently sending tnxs to it, getting disconnected every few minutes, and never getting any blocks from it.
Oh well.
Isn't the relay network just for blocks? If not why isn't it?


Title: Re: How (and why) to use the Relay Network
Post by: kano on July 07, 2015, 11:24:33 AM
Hmm seems like the relay is pretty much overloaded and not doing it's job at all today.
One of my nodes is permanently sending tnxs to it, getting disconnected every few minutes, and never getting any blocks from it.
Oh well.
Isn't the relay network just for blocks? If not why isn't it?
Because a block needs all the transactions it contains to be able to verify it.
So the relay client has all those transactions, so when a block shows up it can send the block and all the transaction required to the bitcoind ... which is a local network transfer and thus VERY fast.


Title: Re: How (and why) to use the Relay Network
Post by: btcash on July 07, 2015, 05:13:03 PM
Hmm seems like the relay is pretty much overloaded and not doing it's job at all today.
One of my nodes is permanently sending tnxs to it, getting disconnected every few minutes, and never getting any blocks from it.
Oh well.
Isn't the relay network just for blocks? If not why isn't it?
Because a block needs all the transactions it contains to be able to verify it.
So the relay client has all those transactions, so when a block shows up it can send the block and all the transaction required to the bitcoind ... which is a local network transfer and thus VERY fast.
But it seems like receiving all tx from all nodes is to much for the relay servers to handle. I don't get why not simply focus on blocks. No one cares if a tx needs a few seconds extra till it gets to the miner (tx relay only through p2p network). Since the relay server doesn't verify the tx in a block there is no advantage in pre verifing the tx (signature cache).
When the relay servers receive a new block it cointains all tx. Or does the server only receives the block header an all tx hashes?

BTW:
Quote
Information about when blocks are received is made available publicly
on the stats page
Where do I find this page?


Title: Re: How (and why) to use the Relay Network
Post by: p3yot33at3r on July 08, 2015, 09:28:42 AM
Hi Matt,

I just tried compiling the latest "dirty hack" release:

Code:
rig@rig:~/RelayNode/c++$ make -f Makefile clean; make -f Makefile
rm -f *.o crypto/*.o crypto/sha256_code_release/*.a crypto/*~ *~ *.exe relaynetworkclient relaynetworkterminator relaynetworkproxy relaynetworkoutbound relaynetworkserver relaynetworktest relaynetworkclient.exe
g++ -I. -g -DFORCE_LE -DNDEBUG -O3 -march=native -mtune=native -flto -std=c++11 -Wall -I/usr/include   -c -o flaggedarrayset.o flaggedarrayset.cpp
g++ -I. -g -DFORCE_LE -DNDEBUG -O3 -march=native -mtune=native -flto -std=c++11 -Wall -I/usr/include   -c -o utils.o utils.cpp
g++ -I. -g -DFORCE_LE -DNDEBUG -O3 -march=native -mtune=native -flto -std=c++11 -Wall -I/usr/include   -c -o relayprocess.o relayprocess.cpp
g++ -I. -g -DFORCE_LE -DNDEBUG -O3 -march=native -mtune=native -flto -std=c++11 -Wall -I/usr/include   -c -o p2pclient.o p2pclient.cpp
p2pclient.cpp: In member function ‘virtual void P2PRelayer::net_process(const std::function<void(const char*)>&)’:
p2pclient.cpp:103:44: warning: large integer implicitly truncated to unsigned type [-Woverflow]
    if (connected.fetch_and(~CONNECTED_FLAGS) & CONNECTED_FLAG_REQUEST_MEMPOOL)
                                            ^
p2pclient.cpp: In member function ‘void P2PRelayer::request_mempool()’:
p2pclient.cpp:191:13: warning: large integer implicitly truncated to unsigned type [-Woverflow]
   connected &= ~CONNECTED_FLAG_REQUEST_MEMPOOL;
             ^
g++ -I. -g -DFORCE_LE -DNDEBUG -O3 -march=native -mtune=native -flto -std=c++11 -Wall -I/usr/include   -c -o connection.o connection.cpp
g++ -I. -g -DFORCE_LE -DNDEBUG -O3 -march=native -mtune=native -flto -std=c++11 -Wall -I/usr/include   -c -o crypto/sha2.o crypto/sha2.cpp
g++ -I. -g -DFORCE_LE -DNDEBUG -O3 -march=native -mtune=native -flto -std=c++11 -Wall -I/usr/include   -c -o client.o client.cpp
g++ -I. -g -DFORCE_LE -DNDEBUG -O3 -march=native -mtune=native -flto -std=c++11 -Wall -I/usr/include flaggedarrayset.o utils.o relayprocess.o p2pclient.o connection.o crypto/sha2.o client.o -Wl,--no-as-needed -pthread -lresolv -o relaynetworkclient

When I try to run it, I only get this:

Code:
Using server 8333

Running 14.04 64bit.


Title: Re: How (and why) to use the Relay Network
Post by: igorwhite on July 08, 2015, 09:58:12 AM


When I try to run it, I only get this:

Code:
Using server 8333

Running 14.04 64bit.

Hello!

I have the same issue.  ???

http://s30.postimg.org/43o0fs8w1/relay.png

Prior to update everything worked. Ubuntu Server 64bit 14.04.02


Title: Re: How (and why) to use the Relay Network
Post by: kano on July 08, 2015, 12:21:27 PM
When I try to run it, I only get this:

Code:
Using server 8333

Running 14.04 64bit.
Hello!

I have the same issue.  ???

http://s30.postimg.org/43o0fs8w1/relay.png

Prior to update everything worked. Ubuntu Server 64bit 14.04.02
He changed the parameter order ...

You now should just:
./relaynetworkclient 127.0.0.1 8333

You can specify which server to use on the end, but it will automatically choose one if you don't, by running a ping test to find the closest.

Edit: note the relay isn't responding at the moment at all ...


Title: Re: How (and why) to use the Relay Network
Post by: p3yot33at3r on July 08, 2015, 12:41:44 PM

He changed the parameter order ...

You now should just:
./relaynetworkclient 127.0.0.1 8333

You can specify which server to use on the end, but it will automatically choose one if you don't, by running a ping test to find the closest.

Edit: note the relay isn't responding at the moment at all ...

Kano - thank you for that, I wasn't aware that Matt had changed the start up syntax. However, like you say, it's not responding & as soon as I started it up it locked my system up completely requiring a full reset.

Switched it off & disabled it again  :(


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on July 09, 2015, 02:19:31 AM
Sorry for the lack of replies, I've been heads-down rewriting the way transactions are handled to work in cases where mempools are reasonably large. That seems to be working now (though much tweaking remains to be done to make it perform well). There is also a new node in Tokyo (you may want to restart your client to auto-detect if its closer for you, or if you had already been connecting to the jpy hostname, you should already be using it).

I'm gonna try to be better at keeping an updated news section in on http://bitcoinrelaynetwork.org, so keep an eye there as things get updated. There will be new operating instructions due to the changes (though if you ignore them things will still work, and probably just as effeciently unless you're using strange transaction policy).

Kano - thank you for that, I wasn't aware that Matt had changed the start up syntax. However, like you say, it's not responding & as soon as I started it up it locked my system up completely requiring a full reset.

Switched it off & disabled it again  :(
lol, is your libc REALLY broken??? I'm really not sure how thats possible...is this reproduceable?


edit: I fixed it by disabling it attempting to build that file since it's not even included in my binary. Probably shouldn't build all the assembly files unconditionally.
I did this on master now.

Quote from: btcash
Information about when blocks are received is made available publicly
on the stats page
Where do I find this page?
http://bitcoinrelaynetwork.org/stats.html (though that will probably be wiped in not too long as my stats-processing script doesnt handle adding/removing nodes very well :/, if anyone needs old stats I will be glad to provide them).


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on July 09, 2015, 02:22:25 AM
Oh, and I added a donation address to cover the 45USD/month I'm currently shelling out for the servers :p (1NRuqMJAzUGwvFigukLa3UZqcJXix1dETM, feel free to check that address' balance and only donate if the server costs havent already been covered, though if its usually over I'll invest in more servers)


Title: Re: How (and why) to use the Relay Network
Post by: kano on July 09, 2015, 02:39:58 AM
Oh, and I added a donation address to cover the 45USD/month I'm currently shelling out for the servers :p (1NRuqMJAzUGwvFigukLa3UZqcJXix1dETM, feel free to check that address' balance and only donate if the server costs havent already been covered, though if its usually over I'll invest in more servers)
Just updated my main node from the Jul-4 version to now.

All running OK now.

The Jul-4 version regularly disconnects/reconnects and doesn't send block notifications to bitcoind because of that ... so I'd guess update it is necessary.

What are these?

Code:
Sent transaction of size 226 (out-of-band) to relay server


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on July 09, 2015, 03:13:09 AM
What are these?

Code:
Sent transaction of size 226 (out-of-band) to relay server

out-of-band transactions are transactions sent but not assumed to be in the next block (ie they will not be compressed if they do appear in the next block). More to come on the website soon.


Title: Re: How (and why) to use the Relay Network
Post by: kano on July 09, 2015, 04:07:09 AM
Seems I'm back to only sending (on west) and rarely getting txns back.
The rare Received ones are always just after, and the same size as, so most likely the same transactions as, the non "(out-of-band)" that it says I send.


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on July 09, 2015, 05:04:07 AM
Seems I'm back to only sending (on west) and rarely getting txns back.
The rare Received ones are always just after, and the same size as, so most likely the same transactions as, the non "(out-of-band)" that it says I send.
This is largely expected. When you're sending out-of-band it means you're running an unmodified bitcoind (more on that later). The send/receive is the same as before, you're echoing the server's sent txn (the printing of what is happenning is out of order, I fixed that now). However, the server is now sending transactions less often (only when its view of what the next few blocks should be changes, instead of on each new transaction).


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on July 09, 2015, 05:15:19 AM
This seems to be relaying massive amounts of dust transactions, I had over 25000 stored.

Had to turn it off.  Now debug.log is getting spammed with

and a good 50% or more of my peers are sending me an inordinate amount of data

This is not specific to the relay network, this was just someone flooding the Bitcoin network with lots of transactions. The relay network, at least, will no longer do this.


Title: Re: How (and why) to use the Relay Network
Post by: p3yot33at3r on July 09, 2015, 10:31:29 AM

Kano - thank you for that, I wasn't aware that Matt had changed the start up syntax. However, like you say, it's not responding & as soon as I started it up it locked my system up completely requiring a full reset.

Switched it off & disabled it again  :(

lol, is your libc REALLY broken??? I'm really not sure how thats possible...is this reproduceable?


 :D I'm buggered if I know - it only happened the once too, so not reproducible I'm afraid.

I still get a warning when compiling the latest version, but it does run now. I'm still getting plenty of this:

Code:
127.0.0.1 Disconnect: failed to read message header (Transport endpoint is not connected)
127.0.0.1 Disconnect: failed to read message header (Transport endpoint is not connected)
127.0.0.1 Disconnect: failed to read message header (Transport endpoint is not connected)
127.0.0.1 Disconnect: failed to read message header (Transport endpoint is not connected)
127.0.0.1 Disconnect: failed to read message header (Transport endpoint is not connected)
127.0.0.1 Disconnect: failed to read message header (Transport endpoint is not connected)
127.0.0.1 Disconnect: failed to read message header (Transport endpoint is not connected)

Thanks for adding the extra info to the web page Matt. I'm sure the attack situation must be wrecking your head somewhat, especially with noobs like me constantly asking silly questions!  :D  Your work is very much appreciated, & I for one will be throwing a tip or two your way as & when I can - thanks again  :)


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on July 09, 2015, 05:53:24 PM
lol, is your libc REALLY broken??? I'm really not sure how thats possible...is this reproduceable?

 :D I'm buggered if I know - it only happened the once too, so not reproducible I'm afraid.

Can you try with connections to the relay network blocked (I'm assuming this happened when you couldn't connect to any servers)?

I still get a warning when compiling the latest version, but it does run now. I'm still getting plenty of this:

Code:
127.0.0.1 Disconnect: failed to read message header (Transport endpoint is not connected)
127.0.0.1 Disconnect: failed to read message header (Transport endpoint is not connected)
127.0.0.1 Disconnect: failed to read message header (Transport endpoint is not connected)
127.0.0.1 Disconnect: failed to read message header (Transport endpoint is not connected)
127.0.0.1 Disconnect: failed to read message header (Transport endpoint is not connected)
127.0.0.1 Disconnect: failed to read message header (Transport endpoint is not connected)
127.0.0.1 Disconnect: failed to read message header (Transport endpoint is not connected)
Its having trouble connecting to your local bitcoind it looks like? Anything in your debug.log?

Thanks for adding the extra info to the web page Matt. I'm sure the attack situation must be wrecking your head somewhat, especially with noobs like me constantly asking silly questions!  :D  Your work is very much appreciated, & I for one will be throwing a tip or two your way as & when I can - thanks again  :)
Meh, its a change I had been meaning to make for a while, this just forced my hand.


Title: Re: How (and why) to use the Relay Network
Post by: zvs on July 09, 2015, 11:28:02 PM
This seems to be relaying massive amounts of dust transactions, I had over 25000 stored.

Had to turn it off.  Now debug.log is getting spammed with

and a good 50% or more of my peers are sending me an inordinate amount of data

This is not specific to the relay network, this was just someone flooding the Bitcoin network with lots of transactions. The relay network, at least, will no longer do this.
Oh, yah, I realized that.  I figured turning it off would save some bandwidth, at least.  Everything is running with the updated code now, though I still wish there was a way to set it to blocks only.. don't need transactions relayed to any of my nodes, really.

but it still

Code:
----system---- ------sockets------ -net/venet0 ---load-avg---
     time     |tot tcp udp raw frg| recv  send| 1m   5m  15m
09-07 17:24:12|  0 117   7   0   0|   0     0 |0.31 0.30 0.36
09-07 17:24:13|  0 117   7   0   0| 654k   95k|0.29 0.30 0.36
09-07 17:24:14|  0 116   7   0   0| 593k  125k|0.29 0.30 0.36
09-07 17:24:15|  0 116   7   0   0| 495k   83k|0.29 0.30 0.36
09-07 17:24:16|  0 116   7   0   0| 496k   72k|0.29 0.30 0.36
09-07 17:24:17|  0 116   7   0   0| 335k   31k|0.29 0.30 0.36
09-07 17:24:18|  0 116   7   0   0| 402k   32k|0.27 0.29 0.36
09-07 17:24:19|  0 116   7   0   0| 523k   39k|0.27 0.29 0.36
09-07 17:24:20|  0 116   7   0   0| 443k   74k|0.27 0.29 0.36
09-07 17:24:21|  0 116   7   0   0| 474k  138k|0.27 0.29 0.36
09-07 17:24:22|  0 116   7   0   0| 469k   82k|0.27 0.29 0.36
09-07 17:24:23|  0 116   7   0   0| 451k   71k|0.24 0.29 0.35
09-07 17:24:24|  0 115   7   0   0| 533k   98k|0.24 0.29 0.35
09-07 17:24:25|  0 115   7   0   0| 611k   97k|0.24 0.29 0.35
09-07 17:24:26|  0 115   7   0   0| 648k   84k|0.24 0.29 0.35
09-07 17:24:27|  0 115   7   0   0| 652k  149k|0.24 0.29 0.35
09-07 17:24:28|  0 115   7   0   0| 635k   66k|0.30 0.30 0.36
09-07 17:24:29|  0 115   7   0   0| 458k   70k|0.30 0.30 0.36
09-07 17:24:30|  0 115   7   0   0| 514k  124k|0.30 0.30 0.36
09-07 17:24:31|  0 115   7   0   0| 444k   60k|0.30 0.30 0.36
09-07 17:24:32|  0 115   7   0   0| 366k   41k|0.30 0.30 0.36
09-07 17:24:33|  0 115   7   0   0| 375k   51k|0.28 0.29 0.36
09-07 17:24:34|  0 115   7   0   0| 402k   47k|0.28 0.29 0.36
09-07 17:24:35|  0 115   7   0   0| 790k  105k|0.28 0.29 0.36
09-07 17:24:36|  0 115   7   0   0| 502k   72k|0.28 0.29 0.36
09-07 17:24:37|  0 115   7   0   0| 623k   86k|0.28 0.29 0.36
09-07 17:24:38|  0 115   7   0   0| 403k  127k|0.34 0.31 0.36
09-07 17:24:39|  0 115   7   0   0| 595k   56k|0.34 0.31 0.36
09-07 17:24:40|  0 115   7   0   0| 466k  112k|0.34 0.31 0.36
09-07 17:24:41|  0 115   7   0   0| 340k   89k|0.34 0.31 0.36
09-07 17:24:42|  0 115   7   0   0| 655k   71k|0.34 0.31 0.36
09-07 17:24:43|  0 115   7   0   0| 598k   93k|0.31 0.30 0.36
09-07 17:24:44|  0 115   7   0   0| 595k   48k|0.31 0.30 0.36
09-07 17:24:45|  0 115   7   0   0| 465k   95k|0.31 0.30 0.36
09-07 17:24:46|  0 115   7   0   0| 543k   89k|0.31 0.30 0.36
09-07 17:24:47|  0 115   7   0   0| 489k   43k|0.31 0.30 0.36
09-07 17:24:48|  0 115   7   0   0| 492k   50k|0.29 0.29 0.35
09-07 17:24:49|  0 116   7   0   0| 652k  122k|0.29 0.29 0.35
09-07 17:24:50|  0 116   7   0   0| 461k  121k|0.29 0.29 0.35
09-07 17:24:51|  0 116   7   0   0| 601k   57k|0.29 0.29 0.35
09-07 17:24:52|  0 116   7   0   0|1074k   71k|0.29 0.29 0.35
09-07 17:24:53|  0 116   7   0   0|2315k  123k|0.26 0.29 0.35
09-07 17:24:54|  0 116   7   0   0|2372k  213k|0.26 0.29 0.35
09-07 17:24:55|  0 116   7   0   0|2290k  136k|0.26 0.29 0.35
09-07 17:24:56|  0 116   7   0   0|2475k  117k|0.26 0.29 0.35
09-07 17:24:57|  0 116   7   0   0|3616k  174k|0.26 0.29 0.35
09-07 17:24:58|  0 116   7   0   0|3001k  154k|0.24 0.28 0.35
09-07 17:24:59|  0 116   7   0   0|2388k  110k|0.24 0.28 0.35
09-07 17:25:00|  0 116   7   0   0| 392k  110k|0.24 0.28 0.35
09-07 17:25:01|  0 116   7   0   0| 486k   39k|0.24 0.28 0.35
09-07 17:25:02|  0 116   7   0   0|1098k  165k|0.24 0.28 0.35
09-07 17:25:03|  0 116   7   0   0|2137k  239k|0.30 0.30 0.35
09-07 17:25:04|  0 117   7   0   0|3196k  125k|0.30 0.30 0.35
09-07 17:25:05|  0 117   7   0   0|5036k  137k|0.30 0.30 0.35
09-07 17:25:06|  0 117   7   0   0|7243k  120k|0.30 0.30 0.35
09-07 17:25:07|  0 117   7   0   0|5251k  200k|0.30 0.30 0.35
09-07 17:25:08|  0 117   7   0   0|5138k  147k|0.36 0.31 0.36^C

can't be stopped, unless I go through and start firewalling every single one of those nodes.  That's on one of my 100mbit connections too, which is why it only has 100 connections.  I've seen 50MB/s receive amts on 1Gbit

ed:   someone with several thousand $'s to waste could easily get some 10Gbit dedicated lines, and just flood everyone out with trash transactions.

ed2: and i suppose I should point out that this would be different from a typical DoS attack in that they'd have hundreds, or a thousand or two or three helpers, all transmitting as many of those transactions as their bandwidth could handle (turning it into a DDoS, with the quickness!)...   ed3 (last one I hope, wtf):  I've considered upping the minimum version level of connections...  that would get rid of 99%, just the 1% malicious would remain


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on July 10, 2015, 05:33:57 AM
Oh, yah, I realized that.  I figured turning it off would save some bandwidth, at least.  Everything is running with the updated code now, though I still wish there was a way to set it to blocks only.. don't need transactions relayed to any of my nodes, really.
THat would entirely defeat the purpose...you cant compress without pre-relaying.


Title: Re: How (and why) to use the Relay Network
Post by: zvs on July 14, 2015, 12:57:13 AM
Oh, yah, I realized that.  I figured turning it off would save some bandwidth, at least.  Everything is running with the updated code now, though I still wish there was a way to set it to blocks only.. don't need transactions relayed to any of my nodes, really.
THat would entirely defeat the purpose...you cant compress without pre-relaying.
don't get it.. blocks?   the relay always sends me transactions after i've already received them, so it's essentially wasting bandwidth


Title: Re: How (and why) to use the Relay Network
Post by: amaclin on July 14, 2015, 04:23:22 AM
don't get it.. blocks?   the relay always sends me transactions after i've already received them, so it's essentially wasting bandwidth
Your Gangnam-nodes are also a relay-network :)


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on July 16, 2015, 06:18:33 AM
Your Gangnam-nodes are also a relay-network :)
Except without compressing blocks, which saves a ton of time, which is why the transactions have to be relayed first to begin with :)


Title: Re: How (and why) to use the Relay Network
Post by: amaclin on July 16, 2015, 06:54:38 AM
Except without compressing blocks, which saves a ton of time, which is why the transactions have to be relayed first to begin with :)
Yes. But RelayNetwork depends of you.
So, this is centralization and may be dangerous.
You are able to relay blocks to one pools faster and to other pools slower.
I do not say that you are doing it. But... You have possibility and right to do it.
Even if RelayNetwork is used with the normal BitcoinNetwork.


Title: Re: How (and why) to use the Relay Network
Post by: kano on July 16, 2015, 07:47:37 AM
So ... I've been trying to work out what's the actual state of the relay over the past few days.
Anyone got any idea if it is actually working properly?

For the past few days I've only ever been sending transactions, never receiving any except of course if I exit the client and start it again.
Blocks do show up on the relay, but never any received transactions.

I updated the code an hour or so ago and then connected again and now the console shows nothing other than the ping tests and connecting to my bitcoind.

Does no one use it any more?
Does it still work?


Title: Re: How (and why) to use the Relay Network
Post by: -ck on July 16, 2015, 07:55:23 AM
My relay said
Code:
Relay network is using a later version (PLEASE UPGRADE)

So I obediently upgraded. I can't see any blocks being propagated in the messages any more.


Title: Re: How (and why) to use the Relay Network
Post by: loshia on July 16, 2015, 08:34:14 AM
My relay said
Code:
Relay network is using a later version (PLEASE UPGRADE)

So I obediently upgraded. I can't see any blocks being propagated in the messages any more.
That is odd. I upgraded this morning and commented out some TX printf's

I see blocks but i am wandering why do i see

???Relay network is using a later version (PLEASE UPGRADE) ?????

./relaynetworkclient 127.0.0.1 8333
Server 0 (public.us-east.relay.mattcorallo.com) took 2428 ms to respond 20 times.
Server 1 (public.us-west.relay.mattcorallo.com) took 3741 ms to respond 20 times.
Server 2 (public.eu.relay.mattcorallo.com) took 858 ms to respond 20 times.
Server 3 (public.sgp.relay.mattcorallo.com) took 6142 ms to respond 20 times.
Server 4 (public.jpy.relay.mattcorallo.com) took 5821 ms to respond 20 times.
Using server public.02.relay.mattcorallo.com
Connected to bitcoind with version 70002
Finished connect handshake with bitcoind
Connected to relay node with protocol version the blocksize
[2015-07-16 05:30:40+00] 00000000000000000e96a0ff24ef141df395d2257f18dca51a65d1482c5b0ec3 recv'd, size 280356 with 282790 bytes on the wire
[2015-07-16 05:33:06+00] 00000000000000000078bd09b27f2cf08088feb9336e45ca629bd4a975d1e0a3 recv'd, size 932873 with 934667 bytes on the wire
[2015-07-16 05:34:20+00] 00000000000000000d1e51d46b6ccf5c54b787a4caef58c3019cb376c76545ea recv'd, size 749130 with 750464 bytes on the wire
[2015-07-16 05:43:45+00] 00000000000000000592738f801e87e8ecd19f1503dd4842f086e47df5f7202b recv'd, size 998191 with 1001090 bytes on the wire
[2015-07-16 05:44:25+00] 000000000000000004e6ce77718d9a42c9024d95b7b8efba45b9f0a47bd376db recv'd, size 209 with 145 bytes on the wire
[2015-07-16 06:07:56+00] 00000000000000001432cd6c4cc7b757f9765a5c8c2f6cdf208202feb5435680 recv'd, size 949143 with 956012 bytes on the wire
public.02.relay.mattcorallo.com Disconnect: failed to read message header (Transport endpoint is not connected)
Relay network is using a later version (PLEASE UPGRADE)
Connected to relay node with protocol version the blocksize
[2015-07-16 06:21:31+00] 0000000000000000012b7407d2546b6f4e669a63876425222ef6677617d05179 recv'd, size 998070 with 1002864 bytes on the wire
Failed to process block from bitcoind (SEEN)
public.02.relay.mattcorallo.com Disconnect: failed to read message header (Transport endpoint is not connected)
Relay network is using a later version (PLEASE UPGRADE)
Connected to relay node with protocol version the blocksize
[2015-07-16 06:23:10+00] 000000000000000001785d0840164a5ef27ecb4d847b7690903fce64ce3b0085 recv'd, size 749191 with 750810 bytes on the wire
[2015-07-16 06:58:56+00] 00000000000000000a8a1e247226a15b3c055ab3e3f13a12e351b6680aadaa15 recv'd, size 830343 with 839567 bytes on the wire
[2015-07-16 07:23:39+00] 00000000000000000220392a7944d4454e0b62903530ce51f9b7c2bcd97d64c0 recv'd, size 266 with 202 bytes on the wire
[2015-07-16 07:26:08+00] 00000000000000000f8f405ce360f6da4744d9a9e0ec71284de1881ae9685011 recv'd, size 989208 with 996552 bytes on the wire
[2015-07-16 07:31:14+00] 00000000000000000018a610c4133feeea6403a5e27876d279ff1804a8daec8c recv'd, size 998087 with 1002056 bytes on the wire
Failed to process block from bitcoind (SEEN)
[2015-07-16 07:55:11+00] 0000000000000000128b4f3fc564bf84c8483d1c87bbe171584c266d43ac1c91 recv'd, size 934443 with 942117 bytes on the wire
[2015-07-16 07:56:12+00] 00000000000000000c09e33dd20f69e76506e6796ec0b44bcdb271e2c604ccf1 recv'd, size 98929 with 99330 bytes on the wire
[2015-07-16 08:11:39+00] 000000000000000014ddf3f1756dded5fd7a39ff3456b682197965267d1dfda6 recv'd, size 492914 with 497943 bytes on the wire
[2015-07-16 08:16:28+00] 0000000000000000033b7f9875e58d51646d6a98b6e2d06faaa13f98900e4207 recv'd, size 186463 with 188302 bytes on the wire
Failed to process block from bitcoind (SEEN)
[2015-07-16 08:20:49+00] 00000000000000000d0870d681ac8a346a596685291f851a58f8b28fa91344d4 recv'd, size 184175 with 185804 bytes on the wire
Failed to process block from bitcoind (SEEN)
[2015-07-16 08:21:33+00] 000000000000000007ee91112a839f09569119925a3f5a433e3afdb90e4615b5 recv'd, size 99994 with 101693 bytes on the wire
Failed to process block from bitcoind (SEEN)
[2015-07-16 08:28:43+00] 000000000000000007ed25a03616c31ea33e54e854f8f6148160520fca58e7d0 recv'd, size 913328 with 916607 bytes on the wire




Title: Re: How (and why) to use the Relay Network
Post by: p3yot33at3r on July 16, 2015, 09:14:06 AM
Does no one use it any more?
Does it still work?

I've not been able to get it working since upgrading to Bitcoind v11 a few days ago.......... :(


Title: Re: How (and why) to use the Relay Network
Post by: -ck on July 16, 2015, 09:44:32 AM
Does no one use it any more?
Does it still work?

I've not been able to get it working since upgrading to Bitcoind v11 a few days ago.......... :(
I'm on 0.11 as of recently as well. Perhaps that's the common issue...


Title: Re: How (and why) to use the Relay Network
Post by: p3yot33at3r on July 16, 2015, 09:54:53 AM
Does no one use it any more?
Does it still work?

I've not been able to get it working since upgrading to Bitcoind v11 a few days ago.......... :(
I'm on 0.11 as of recently as well. Perhaps that's the common issue...

I just done a git pull - it's working again, but I'm not receiving - only sending.........


Title: Re: How (and why) to use the Relay Network
Post by: loshia on July 16, 2015, 10:54:25 AM
Does no one use it any more?
Does it still work?

I've not been able to get it working since upgrading to Bitcoind v11 a few days ago.......... :(
I'm on 0.11 as of recently as well. Perhaps that's the common issue...
I am on 0.11 also


Title: Re: How (and why) to use the Relay Network
Post by: jonnybravo0311 on July 16, 2015, 02:36:58 PM
I'm on 0.11 as well... having just updated and rebuilt the client, this is what I see:
Code:
miner@devildog:~/RelayNode/c++$ ./relaynetworkclient 127.0.0.1 8333
Server 0 (public.us-east.relay.mattcorallo.com) took 2036 ms to respond 20 times.
Server 1 (public.us-west.relay.mattcorallo.com) took 24449 ms to respond 20 times.
Server 2 (public.eu.relay.mattcorallo.com) took 1676 ms to respond 20 times.
Server 3 (public.sgp.relay.mattcorallo.com) took 5156 ms to respond 20 times.
Server 4 (public.jpy.relay.mattcorallo.com) took 3309 ms to respond 20 times.
Using server public.02.relay.mattcorallo.com
Connected to relay node with protocol version sponsor printer
Connected to bitcoind with version 70002
Finished connect handshake with bitcoind
Sent transaction of size 373 (out-of-band) to relay server
Sent transaction of size 374 (out-of-band) to relay server
Sent transaction of size 743 (out-of-band) to relay server
Sent transaction of size 191 (out-of-band) to relay server
Sent transaction of size 407 (out-of-band) to relay server
Sent transaction of size 373 (out-of-band) to relay server
Sent transaction of size 223 (out-of-band) to relay server
Sent transaction of size 14798 (out-of-band) to relay server
Sent transaction of size 225 (out-of-band) to relay server
Sent transaction of size 782 (out-of-band) to relay server
Sent transaction of size 225 (out-of-band) to relay server
Sent transaction of size 257 (out-of-band) to relay server
Sent transaction of size 14787 (out-of-band) to relay server
Sent transaction of size 226 (out-of-band) to relay server
Sent transaction of size 257 (out-of-band) to relay server
Sent transaction of size 192 (out-of-band) to relay server
Sent transaction of size 225 (out-of-band) to relay server
Sent transaction of size 373 (out-of-band) to relay server
Sent transaction of size 226 (out-of-band) to relay server
Sent transaction of size 226 (out-of-band) to relay server
Sent transaction of size 404 (out-of-band) to relay server
Sent transaction of size 226 (out-of-band) to relay server
Sent transaction of size 225 (out-of-band) to relay server
Sent transaction of size 14790 (out-of-band) to relay server
Sent transaction of size 259 (out-of-band) to relay server
Sent transaction of size 3379 (out-of-band) to relay server
Sent transaction of size 438 (out-of-band) to relay server
Sent transaction of size 369 (out-of-band) to relay server
Sent transaction of size 14787 (out-of-band) to relay server
Sent transaction of size 521 (out-of-band) to relay server
Sent transaction of size 191 (out-of-band) to relay server
Sent transaction of size 225 (out-of-band) to relay server
Sent transaction of size 372 (out-of-band) to relay server
Sent transaction of size 340 (out-of-band) to relay server
Sent transaction of size 14799 (out-of-band) to relay server

I haven't seen a single received transaction.
EDIT:
Just got my first received transaction:
Code:
[2015-07-16 15:15:54+00] 00000000000000000e76821cb710d1a40878ead2e83fa8a0ec26b31f92263b09 recv'd, size 592138 with 597877 bytes on the wire


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on July 16, 2015, 09:52:28 PM
So ... I've been trying to work out what's the actual state of the relay over the past few days.
Anyone got any idea if it is actually working properly?

For the past few days I've only ever been sending transactions, never receiving any except of course if I exit the client and start it again.
Blocks do show up on the relay, but never any received transactions.

I updated the code an hour or so ago and then connected again and now the console shows nothing other than the ping tests and connecting to my bitcoind.

Does no one use it any more?
Does it still work?
Yes, it does. Its been on and off due to various bugs, most notably it worked last night and then I woke up and it had deadlocked :(. In any case, things are stabalizing some now that the network supports crazy over-large mempools (thought I had it working stable-y before the whole spam thing :(   ).


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on July 16, 2015, 09:56:06 PM
It should now work again no matter your bitcoind version, and also compress blocks somewhat OK, though its not working nearly as well as it used to when entire mempools were in cache constantly.

In other news, Ive been digging into relay network in China to better connect the huge percent of the network there. Sadly, peering in Asia, especially with Chinese telecoms generally sucks. Does anyone (or a group of people) have any interest in sponsoring a node on Softlayer (25$/mo) Japan, which seems to be the only well-peered VPS provider in Tokyo?


Title: Re: How (and why) to use the Relay Network
Post by: kano on July 16, 2015, 10:18:30 PM
Well the ping times are back to normal now.
I got this one a few hours ago:
Code:
...
Server 1 (public.us-west.relay.mattcorallo.com) took 28696 ms to respond 20 times.
Server 2 (public.eu.relay.mattcorallo.com) took 305084 ms to respond 20 times.
...
Now it's normal.

But still after the pings I only get:
Code:
Using server public.01.relay.mattcorallo.com
Connected to bitcoind with version 70002
Finished connect handshake with bitcoind

I waited for a block to go by to see if there was any other reply ... but no, since I presume it's not connected anyway.

I'm of course not running 0.11.x since there's no way I'd switch over to that soon after it's release ...
I'm on 0.10.2


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on July 16, 2015, 10:46:15 PM
Well the ping times are back to normal now.
I got this one a few hours ago:
Code:
...
Server 1 (public.us-west.relay.mattcorallo.com) took 28696 ms to respond 20 times.
Server 2 (public.eu.relay.mattcorallo.com) took 305084 ms to respond 20 times.
...
Now it's normal.
Strange, I'm not sure why that would have ever happened...bad connection on your end? Maybe the select loop was slow, though I'm not sure why that would have been....

But still after the pings I only get:
Code:
Using server public.01.relay.mattcorallo.com
Connected to bitcoind with version 70002
Finished connect handshake with bitcoind

I waited for a block to go by to see if there was any other reply ... but no, since I presume it's not connected anyway.
Strange, the us-west node works for me?


Title: Re: How (and why) to use the Relay Network
Post by: p3yot33at3r on July 16, 2015, 11:14:42 PM
Pulled the latest, compiled without error on 14.04 64bit & it runs - but still getting disconnects in between bandwidth saturation with tx sizes 3404 using the eu node  :(


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on July 17, 2015, 01:31:40 AM
Pulled the latest, compiled without error on 14.04 64bit & it runs - but still getting disconnects in between bandwidth saturation with tx sizes 3404 using the eu node  :(
Fixed server memory usage, bumped the buffer size, should work now?


Title: Re: How (and why) to use the Relay Network
Post by: p3yot33at3r on July 17, 2015, 01:45:30 AM
Pulled the latest, compiled without error on 14.04 64bit & it runs - but still getting disconnects in between bandwidth saturation with tx sizes 3404 using the eu node  :(
Fixed server memory usage, bumped the buffer size, should work now?

Nope:

Code:
Sent transaction of size 3644 to relay server
Received transaction of size 3644 from relay server
Sent transaction of size 3644 to relay server
Received transaction of size 3644 from relay server
Sent transaction of size 3644 to relay server
Received transaction of size 3644 from relay server
Sent transaction of size 3644 to relay server
Received transaction of size 3644 from relay server
Sent transaction of size 3644 to relay server
Received transaction of size 3644 from relay server
Sent transaction of size 3644 to relay server
Received transaction of size 3644 from relay server
Sent transaction of size 3644 to relay server
127.0.0.1 Disconnect: failed to read message header (Transport endpoint is not connected)
127.0.0.1 Disconnect: failed to read message header (Transport endpoint is not connected)
127.0.0.1 Disconnect: failed to read message header (Transport endpoint is not connected)
127.0.0.1 Disconnect: failed to read message header (Transport endpoint is not connected)
127.0.0.1 Disconnect: failed to read message header (Transport endpoint is not connected)
127.0.0.1 Disconnect: failed to read message header (Transport endpoint is not connected)

...still getting flooded with large tx's all the same size too  :(


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on July 17, 2015, 01:53:00 AM
Pulled the latest, compiled without error on 14.04 64bit & it runs - but still getting disconnects in between bandwidth saturation with tx sizes 3404 using the eu node  :(
Fixed server memory usage, bumped the buffer size, should work now?

Nope:

...still getting flooded with large tx's all the same size too  :(
Whats your connection like? If you have a particularly slow downstream you may get kicked off for not keeping up (this mostly happens if you're trying to connect to a server far away from you). PM me your ip and I'll look up why you got disconnected.


Title: Re: How (and why) to use the Relay Network
Post by: kano on July 17, 2015, 02:25:39 AM
...
Strange, the us-west node works for me?
Fixed by commenting these out:
Code:
+               //int v6only = 0;
+               //setsockopt(sock, IPPROTO_IPV6, IPV6_V6ONLY, (char *)&v6only, sizeof(v6only));
I've no idea why it fails the remote connection on my server ...


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on July 17, 2015, 02:41:21 AM
Fixed by commenting these out:
Code:
+               //int v6only = 0;
+               //setsockopt(sock, IPPROTO_IPV6, IPV6_V6ONLY, (char *)&v6only, sizeof(v6only));
I've no idea why it fails the remote connection on my server ...

Huh, what OS/libc are you on?


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on July 17, 2015, 09:10:46 PM
My bitcoind server was killed by the host. The problem has now been resolved, but I'm waiting on it to sync the chain again before transactions will again be relayed within the network. See http://bitcoinrelaynetwork.org/ for latest updates.


Title: Re: How (and why) to use the Relay Network
Post by: kano on July 17, 2015, 09:45:55 PM
My bitcoind server was killed by the host. The problem has now been resolved, but I'm waiting on it to sync the chain again before transactions will again be relayed within the network. See http://bitcoinrelaynetwork.org/ for latest updates.
Ah OK - then ignore the 2nd part of my PM :)


Title: Re: How (and why) to use the Relay Network
Post by: bicer on July 18, 2015, 01:41:32 AM
Is constant "(out-of-band)" normal?

Code:
Sent transaction of size 815 (out-of-band) to relay server
Sent transaction of size 339 (out-of-band) to relay server
Sent transaction of size 373 (out-of-band) to relay server
Sent transaction of size 226 (out-of-band) to relay server


Title: Re: How (and why) to use the Relay Network
Post by: kano on July 18, 2015, 02:29:10 AM
Until he fixes his bitcoind.

If he is re-downloading the blockchain ... that may take a loooooong while.

(The advantage of running mutliple bitcoind without a wallet ...
save config, wipe bad one, rsync good to bad, stop the working one, rsync good to bad again, restore the config, start them both :)


Title: Re: How (and why) to use the Relay Network
Post by: kano on July 19, 2015, 06:37:17 AM
My bitcoind server was killed by the host. The problem has now been resolved, but I'm waiting on it to sync the chain again before transactions will again be relayed within the network. See http://bitcoinrelaynetwork.org/ for latest updates.
You wouldn't happen to have an ETA on this?

I wrote a little script to report the tail 9999 lines of my log every 10s instead of having thousands of lines scrolling by.
It still says 0 txn received.


Title: Re: How (and why) to use the Relay Network
Post by: Peter R on July 19, 2015, 04:59:28 PM
Can anyone in this thread help me figure something out?

I'm trying to estimate the block propagation rate using the relay network to make an apples-to-apples comparison with the 17 sec/MB figure from this TradeBlock analysis (https://tradeblock.com/blog/bitcoin-network-capacity-analysis-part-6-data-propagation).  

TradeBlock's number is the average time it would take 50% of the nodes that it's watching to receive a solved block over the P2P network.

Between the moment a node on the relay network has a solution to a block, how long until 50% of the entities listening on the relay network have received enough information to verify the block solution?

I've seen these stats (http://bitcoinrelaynetwork.org/stats.html) but I don't know how to interpret them.


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on July 19, 2015, 06:35:54 PM
You wouldn't happen to have an ETA on this?
Yes, it should be resolved by now.


Title: Re: How (and why) to use the Relay Network
Post by: p3yot33at3r on July 19, 2015, 06:41:07 PM
I'm still getting disconnects I'm afraid, but not constant as before:

Code:
127.0.0.1 Disconnect: failed to read message header (Transport endpoint is not connected)
127.0.0.1 Disconnect: failed to read message header (Transport endpoint is not connected)
Received transaction of size 4027 from relay server
Sent transaction of size 4027 to relay server
127.0.0.1 Disconnect: failed to read message header (Transport endpoint is not connected)
127.0.0.1 Disconnect: failed to read message header (Transport endpoint is not connected)
Received transaction of size 407 from relay server
Sent transaction of size 407 to relay server
127.0.0.1 Disconnect: failed to read message header (Transport endpoint is not connected)
127.0.0.1 Disconnect: failed to read message header (Transport endpoint is not connected)
Received transaction of size 519 from relay server
Sent transaction of size 519 to relay server
Received transaction of size 1057 from relay server
Sent transaction of size 1057 to relay server
127.0.0.1 Disconnect: failed to read message header (Transport endpoint is not connected)
127.0.0.1 Disconnect: failed to read message header (Transport endpoint is not connected)
Received transaction of size 225 from relay server
Sent transaction of size 225 to relay server
Received transaction of size 225 from relay server
Sent transaction of size 225 to relay server
Received transaction of size 226 from relay server
Sent transaction of size 226 to relay server
127.0.0.1 Disconnect: failed to read message header (Transport endpoint is not connected)
127.0.0.1 Disconnect: failed to read message header (Transport endpoint is not connected)
Received transaction of size 226 from relay server
Sent transaction of size 226 to relay server
Received transaction of size 373 from relay server
Sent transaction of size 373 to relay server
Received transaction of size 226 from relay server
Sent transaction of size 226 to relay server
127.0.0.1 Disconnect: failed to read message header (Transport endpoint is not connected)
127.0.0.1 Disconnect: failed to read message header (Transport endpoint is not connected)


Title: Re: How (and why) to use the Relay Network
Post by: kano on July 19, 2015, 09:33:41 PM
You wouldn't happen to have an ETA on this?
Yes, it should be resolved by now.
Yep all the numbers looking OK again :)
Last 9999 messages: Sent: 5752 Received: 4224


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on July 20, 2015, 11:22:43 PM
I'm still getting disconnects I'm afraid, but not constant as before:
Strange, the server logs just shows you disconnecting. Can you run Wireshark? It looks like your outbound bandwidth may be saturated by the uploading of transactions (its quite small), though I would expect your client to print errors about the buffer blowing up.


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on July 21, 2015, 12:29:02 AM
Turned on the new node in Beijing provided by f2pool and switched to a more expensive host in Tokyo which has better peering, especially into and out of China.


Title: Re: How (and why) to use the Relay Network
Post by: p3yot33at3r on July 21, 2015, 08:36:52 AM
I'm still getting disconnects I'm afraid, but not constant as before:
Strange, the server logs just shows you disconnecting. Can you run Wireshark? It looks like your outbound bandwidth may be saturated by the uploading of transactions (its quite small), though I would expect your client to print errors about the buffer blowing up.

I can't see any reference to buffer blow-ups in the console, only the disconnects. I'll download wireshark & see what I can see. It just seems weird that these problems have only become apparent since bitcoind v11 - it ran fine previously.


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on July 21, 2015, 08:57:07 AM
I can't see any reference to buffer blow-ups in the console, only the disconnects. I'll download wireshark & see what I can see. It just seems weird that these problems have only become apparent since bitcoind v11 - it ran fine previously.
I suspect this has more to do with transaction flooding on the network and new versions of the relay network client than new versions of bitcoin.


Title: Re: How (and why) to use the Relay Network
Post by: p3yot33at3r on July 21, 2015, 10:45:28 AM
I can't see any reference to buffer blow-ups in the console, only the disconnects. I'll download wireshark & see what I can see. It just seems weird that these problems have only become apparent since bitcoind v11 - it ran fine previously.
I suspect this has more to do with transaction flooding on the network and new versions of the relay network client than new versions of bitcoin.

PM'd you ping & trace results from my router.

Edit: latest release compiled without issue & running. Still getting disconnects, but far less frequent:

Code:
Sent transaction of size 427 to relay server
Received transaction of size 427 from relay server
Sent transaction of size 427 to relay server
public.eu.relay.mattcorallo.com Disconnect: failed to read message header (Transport endpoint is not connected)
127.0.0.1 Disconnect: failed to read message header (Transport endpoint is not connected)
127.0.0.1 Disconnect: failed to read message header (Transport endpoint is not connected)
127.0.0.1 Disconnect: failed to read message header (Transport endpoint is not connected)
public.eu.relay.mattcorallo.com Disconnect: failed to read message header (Connection reset by peer)
127.0.0.1 Disconnect: failed to read message header (Transport endpoint is not connected)
public.eu.relay.mattcorallo.com Disconnect: failed to read message header (Connection reset by peer)
127.0.0.1 Disconnect: failed to read message header (Transport endpoint is not connected)
Connected to relay node with protocol version sponsor printer
Received transaction of size 426 from relay server
Sent transaction of size 426 to relay server
Received transaction of size 426 from relay server
Sent transaction of size 426 to relay server
Received transaction of size 426 from relay server
Sent transaction of size 426 to relay server
Received transaction of size 426 from relay server
Sent transaction of size 426 to relay server
Received transaction of size 426 from relay server
Sent transaction of size 426 to relay server
Received transaction of size 426 from relay server
Sent transaction of size 426 to relay server
Received transaction of size 426 from relay server
Sent transaction of size 426 to relay server
127.0.0.1 Disconnect: failed to read message header (Transport endpoint is not connected)
Received transaction of size 426 from relay server
Sent transaction of size 426 to relay server
Received transaction of size 426 from relay server

The amount of Tx sizes of 226/7 & 427/8 flying by at light speed is mind blowing - never seen so many of the same size. However, what ever changes you're making seem to be an improvement, so we appear to be on the right road  ;)

Edit2:

I think I've nailed the disconnect problem. I just noticed that the default number of threads to service RPC calls is set at 4 on bitcoind, which, seeing as I'm merge mining 10 other coins plus the relaynetworkclient on my p2pool node - doesn't seem enough. So I increased this value to 10 in the .conf file using:

Code:
rpcthreads=10

...and restarted bitcoind. Since doing this I've not observed a single disconnect - only the constant stream of 226/7 & 427/8 Tx fees flying by at warp speed  :)

I'll keep an eye on it, but hopefully this info will prove useful to other merge miners.


Title: Re: How (and why) to use the Relay Network
Post by: loshia on July 21, 2015, 07:03:37 PM
p3yot33at3r,

What is your isp connection?
My impressions are that you are using some kind of DSL with PPPoE or dhcp.
You need a static Routable ip in order to play this game. If you are behind nat your router gw is a private ip or your Routable ip changes too often that will kill your tcp connections for sure ;)

If your ip is public and static you can try kano tcp6 sock hack
.

The above is a BULSHIT Forget it

Back to your problem
 I do not think that dropped connections have anything in common with bitcoin rpc max threads at all.
Relay client is not using RPC at all. It talks raw to btcd and relay servers
Other thing to check is your BTC max peer count. I had this problem when I reached max peer connections and I have restarted relay client it would never connect.
So one of the hacks to  my btcd deamon is to use peer -1 and always to have a room for relay client  ;)
I am running btcd 0.11 and relay with kano hack (because it never worked without it-thanks kano) and after block downloading again after mats incident it works just fine no issues


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on July 21, 2015, 07:16:24 PM
Code:
Sent transaction of size 427 to relay server
Received transaction of size 427 from relay server
Sent transaction of size 427 to relay server
public.eu.relay.mattcorallo.com Disconnect: failed to read message header (Transport endpoint is not connected)
127.0.0.1 Disconnect: failed to read message header (Transport endpoint is not connected)
127.0.0.1 Disconnect: failed to read message header (Transport endpoint is not connected)
127.0.0.1 Disconnect: failed to read message header (Transport endpoint is not connected)
public.eu.relay.mattcorallo.com Disconnect: failed to read message header (Connection reset by peer)
127.0.0.1 Disconnect: failed to read message header (Transport endpoint is not connected)
public.eu.relay.mattcorallo.com Disconnect: failed to read message header (Connection reset by peer)
127.0.0.1 Disconnect: failed to read message header (Transport endpoint is not connected)
Connected to relay node with protocol version sponsor printer
Received transaction of size 426 from relay server
Sent transaction of size 426 to relay server
Received transaction of size 426 from relay server
Sent transaction of size 426 to relay server
Received transaction of size 426 from relay server
Sent transaction of size 426 to relay server
Received transaction of size 426 from relay server
Sent transaction of size 426 to relay server
Received transaction of size 426 from relay server
Sent transaction of size 426 to relay server
Received transaction of size 426 from relay server
Sent transaction of size 426 to relay server
Received transaction of size 426 from relay server
Sent transaction of size 426 to relay server
127.0.0.1 Disconnect: failed to read message header (Transport endpoint is not connected)
Received transaction of size 426 from relay server
Sent transaction of size 426 to relay server
Received transaction of size 426 from relay server

The amount of Tx sizes of 226/7 & 427/8 flying by at light speed is mind blowing - never seen so many of the same size. However, what ever changes you're making seem to be an improvement, so we appear to be on the right road  ;)

Edit2:

I think I've nailed the disconnect problem. I just noticed that the default number of threads to service RPC calls is set at 4 on bitcoind, which, seeing as I'm merge mining 10 other coins plus the relaynetworkclient on my p2pool node - doesn't seem enough. So I increased this value to 10 in the .conf file using:

Code:
rpcthreads=10

...and restarted bitcoind. Since doing this I've not observed a single disconnect - only the constant stream of 226/7 & 427/8 Tx fees flying by at warp speed  :)

I'll keep an eye on it, but hopefully this info will prove useful to other merge miners.

LOL, I'm blind! That is disconnecting from 127.0.0.1, so, yea, its not able to hold a connection to your bitcoind (because your bitcoind is overloaded). It has little to nothing to do with the relay network.


Title: Re: How (and why) to use the Relay Network
Post by: loshia on July 21, 2015, 07:19:28 PM
Super  ;)
Listen to Mat advise ...
You need to hack your Bitcoin or to restart it while relay is running as temporally solution and pray to good it will connect :P
Note if relay client disconnects from btcd for some reason other peer will take it's place and same shit will happen again


Title: Re: How (and why) to use the Relay Network
Post by: p3yot33at3r on July 21, 2015, 07:49:31 PM
LOL, I'm blind! That is disconnecting from 127.0.0.1, so, yea, its not able to hold a connection to your bitcoind (because your bitcoind is overloaded). It has little to nothing to do with the relay network.

You & me both!  :D

I couldn't understand why it was happening, then I realized that the other merge mined coins were also connecting on port 127.0.0.1 & it hit me when I read about the default rpc being set at 4 - what a plonker I am!  :P

Still, if nothing else - I've just learned something more & you've tuned the relaynetworkclient even more in your search for a solution....... ;)

Thanks Matt, & sorry to have wasted your valuable time  :)

Edit: I'm still confused as to why it has only recently started causing problems though, it ran fine since the beginning........


Title: Re: How (and why) to use the Relay Network
Post by: loshia on July 21, 2015, 08:03:18 PM
The real problem is not that your btcd is overloaded. Every btcd will reach max peer count sooner or later. Just make sure that there is always a room for relay client
Can I say that my btcd with 150 peers is overloaded - no of course. I just want it to work that way but I do always have a room for relay client always


Title: Re: How (and why) to use the Relay Network
Post by: jonnybravo0311 on July 23, 2015, 05:50:25 PM
LOL, I'm blind! That is disconnecting from 127.0.0.1, so, yea, its not able to hold a connection to your bitcoind (because your bitcoind is overloaded). It has little to nothing to do with the relay network.

You & me both!  :D

I couldn't understand why it was happening, then I realized that the other merge mined coins were also connecting on port 127.0.0.1 & it hit me when I read about the default rpc being set at 4 - what a plonker I am!  :P

Still, if nothing else - I've just learned something more & you've tuned the relaynetworkclient even more in your search for a solution....... ;)

Thanks Matt, & sorry to have wasted your valuable time  :)

Edit: I'm still confused as to why it has only recently started causing problems though, it ran fine since the beginning........
Merge mining other coins has no impact on your bitcoind.  The impact it has is on your miners... the more coins you are merge mining, the more restarts your miners are subjected to.  You aren't connecting to port 127.0.0.1 - that's an IP address.  You are connecting to that IP address on multiple different ports (each coin has its own... for example, Bitcoin's RPC port is 8332).  What do you have running that could be consuming the RPC connections?  That's what you need to investigate.  P2Pool is certainly one... anything else?


Title: Re: How (and why) to use the Relay Network
Post by: loshia on July 23, 2015, 05:58:59 PM
Jonny,
Relay client is like Bitcoin node peer for his btcd. It has nothing to do with RPC or how ovreloaded btc deamon was.
Max peer count is exhausted and that is all. All of us shall take care of it in one way or on other.


Title: Re: How (and why) to use the Relay Network
Post by: jonnybravo0311 on July 23, 2015, 06:28:23 PM
Exactly.  I was asking him to investigate what he's got going on with his bitcoin daemon since the relay client doesn't connect to issue RPC commands over 8332, it connects as a peer over 8333.  I was also letting him know that merge mining coins on p2pool doesn't impact his bitcoin daemon.  It impacts his miners, and the pool is constantly sending restarts (resulting in higher discarded/rejected work) as new blocks are found on those alt coins.

In other words, changing the rpcthreads parameter should have no impact on the relay client.  Now, if he's solo mining and has 100 miners pointed to that bitcoin daemon, each making requests to create blocks, then he'd want to increase the rpcthreads parameter.

Seeing all of those disconnects, I'd suggest looking at the maxconnections.  Default is 125.  If he's running up against that number, then the relay client connection could be rejected by the node.  Then again, my node runs at 125 connections and the relay network doesn't suffer the disconnection problem he's reporting.


Title: Re: How (and why) to use the Relay Network
Post by: loshia on July 23, 2015, 07:07:02 PM
Thanks Jonny,
That was exactly what I wanted to say from beginnig. But my English sucks ;)


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on July 25, 2015, 01:00:20 AM
Added a node in Siberia which improves Japan/Beijing<->EU times, though its not publicly available to connect to (if anyone is mining in Russia and wants to connect to it, please ping me). Check out the nice little map of where the nodes are now at the bottom of the stats page (http://bitcoinrelaynetwork.org/stats.html#hotspot_map)


Title: Re: How (and why) to use the Relay Network
Post by: squidicuz on July 26, 2015, 01:10:41 AM
Check out the nice little map of where the nodes are now at the bottom of the stats page (http://bitcoinrelaynetwork.org/stats.html#hotspot_map)
Awesome!  It is neat being able to see the network map. :)


Title: Re: How (and why) to use the Relay Network
Post by: kano on July 26, 2015, 10:23:44 PM
Added a node in Siberia which improves Japan/Beijing<->EU times, though its not publicly available to connect to (if anyone is mining in Russia and wants to connect to it, please ping me). Check out the nice little map of where the nodes are now at the bottom of the stats page (http://bitcoinrelaynetwork.org/stats.html#hotspot_map)
Question:
So if I see 'S' 66% sends and 'R' 34% receives in the data in my log, that would represent that I'm supplying ~50% of the transactions to the server I connect to?
... since each receive is followed by a send, 'S' 66% would be 100% of the transactions and 'R' 34% would be the amount of those transaction that were sent to me?
i.e. 100 - (R / S) would be my % ?


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on July 27, 2015, 03:20:18 AM
Question:
So if I see 'S' 66% sends and 'R' 34% receives in the data in my log, that would represent that I'm supplying ~50% of the transactions to the server I connect to?
... since each receive is followed by a send, 'S' 66% would be 100% of the transactions and 'R' 34% would be the amount of those transaction that were sent to me?
i.e. 100 - (R / S) would be my % ?
Ignore out-of-band transactions (it should be pretty much 1:1, then, which means you are, as expected, pretty much just echoing all the transactions the server sends you...see https://github.com/TheBlueMatt/RelayNode/issues/11). Out-of-band transactions are just you sending transactions that the relay network may or may not have already seen that probably arent going to be used to compress things (see https://github.com/TheBlueMatt/RelayNode/issues/13).


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on July 27, 2015, 03:22:50 AM
In other news, things seem to be working pretty well now but I probably wont be able to devote a ton of time writing new features in the near future, and since I spent a ton of time recently refactoring the whole codebase, contributing should now be reasonably possible. I'm sure we could drop global relay times another 10-20% pretty easily, and put up some issues at https://github.com/TheBlueMatt/RelayNode/issues that should be reasonably doable for people without stepping on code everywhere else (well, except maybe the rething-low-level-transport-protocol one).


Title: Re: How (and why) to use the Relay Network
Post by: amaclin on July 31, 2015, 03:35:33 PM
WTF with latest executable?

Code:
D:\RelayNetwork>relaynetworkclient.exe
Assertion failed: connection.cpp:78

D:\RelayNetwork>relaynetworkclient.exe --help
UASsAsGeEr:t iDo:n\ failed: connection.cReplpa:y7N8e
two


Title: Re: How (and why) to use the Relay Network
Post by: loshia on July 31, 2015, 09:35:54 PM
WTF with latest executable?

Code:
D:\RelayNetwork>relaynetworkclient.exe
Assertion failed: connection.cpp:78

D:\RelayNetwork>relaynetworkclient.exe --help
UASsAsGeEr:t iDo:n\ failed: connection.cReplpa:y7N8e
two
Wtf dude M$ crap
.....


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on August 01, 2015, 12:59:50 AM
WTF with latest executable?
Should be fixed now.


Title: Re: How (and why) to use the Relay Network
Post by: amaclin on August 01, 2015, 12:06:09 PM
WTF with latest executable?
Should be fixed now.
Now it does not start at all  ;D
Windows 7x64

What stable build can be used?


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on August 02, 2015, 08:01:37 PM
Now it does not start at all  ;D
Windows 7x64

What stable build can be used?
Well, I told you I fixed your original bug :p. Sadly, I dont have any Windows boxes anywhere to test with, and it works in wine now....So you get not prints when you try to run it, and it also doesnt run when you specify your local bitcoind (ie "relaynetworkclient.exe my-bitcoind-address 8333")?


Title: Re: How (and why) to use the Relay Network
Post by: amaclin on August 02, 2015, 08:21:59 PM
Well, I told you I fixed your original bug :p. Sadly, I dont have any Windows boxes anywhere to test with, and it works in wine now....So you get not prints when you try to run it, and it also doesnt run when you specify your local bitcoind (ie "relaynetworkclient.exe my-bitcoind-address 8333")?
When I execute it with parameters it prints some garbage.
And few seconds later windows halts the program.
(Sorry, the Windows displays dialog box in Russian)
https://i.imgur.com/aCdlR6T.png?1


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on August 02, 2015, 08:41:43 PM
When I execute it with parameters it prints some garbage.
And few seconds later windows halts the program.
(Sorry, the Windows displays dialog box in Russian)
Strange that it prints garbage to start, but that does actually look like its working. Wait 30 seconds and see if it prints a bunch of messages about transactions received/sent?


Title: Re: How (and why) to use the Relay Network
Post by: amaclin on August 02, 2015, 08:49:59 PM
Strange that it prints garbage to start, but that does actually look like its working. Wait 30 seconds and see if it prints a bunch of messages about transactions received/sent?
And few seconds later windows halts the program.
The message in the dialog box means that windows have closed the program


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on August 08, 2015, 01:14:36 PM
If people could update to at least include https://github.com/TheBlueMatt/RelayNode/commit/6c479374f1f7f9a9338b656f8d5baa45d91e7d2c in their build, it would help a lot...when people start spamming the network the b/w usage on the relay servers spikes to much higher than reasonable, which may cause most servers to use more b/w than their monthly allotment.

It has no effect on the effectiveness of the relay network, and is almost entirely redundant.


Title: Re: How (and why) to use the Relay Network
Post by: p3yot33at3r on August 08, 2015, 01:22:48 PM
Done  :)


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on August 24, 2015, 06:40:30 PM
So currently the relay network *really* cant handle the spam attacks, because of things that need changed in the way mining works in bitcoin - see https://github.com/TheBlueMatt/RelayNode/issues/12 and https://github.com/bitcoin/bitcoin/issues/6531. When the next spam attacks start, expect block compression to go from 1/2 packets quite often to 500k very quickly (see-also http://bitcoinrelaynetwork.org/stats.html, though without changes I'll have to just turn off compression completely because of bandwidth costs, probably).


Title: Re: How (and why) to use the Relay Network
Post by: CohibAA on September 10, 2015, 07:07:07 PM
So currently the relay network *really* cant handle the spam attacks, because of things that need changed in the way mining works in bitcoin - see https://github.com/TheBlueMatt/RelayNode/issues/12 and https://github.com/bitcoin/bitcoin/issues/6531. When the next spam attacks start, expect block compression to go from 1/2 packets quite often to 500k very quickly (see-also http://bitcoinrelaynetwork.org/stats.html, though without changes I'll have to just turn off compression completely because of bandwidth costs, probably).

Matt, I just wanted to thank you for your great work on this and other projects.

FWIW, my RelayNode has not had any problems during the last 24+ hours of increased transaction activity (and for a pretty long time before).


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on September 10, 2015, 09:13:22 PM
So currently the relay network *really* cant handle the spam attacks, because of things that need changed in the way mining works in bitcoin - see https://github.com/TheBlueMatt/RelayNode/issues/12 and https://github.com/bitcoin/bitcoin/issues/6531. When the next spam attacks start, expect block compression to go from 1/2 packets quite often to 500k very quickly (see-also http://bitcoinrelaynetwork.org/stats.html, though without changes I'll have to just turn off compression completely because of bandwidth costs, probably).

Matt, I just wanted to thank you for your great work on this and other projects.

FWIW, my RelayNode has not had any problems during the last 24+ hours of increased transaction activity (and for a pretty long time before).
Yea, I didnt bother turning off compression, but set the mempool query code to only select a smaller set. This has resulted in a huge drop in compression effeciency (see graphs  linked above), but it does till work...


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on September 25, 2015, 10:53:57 PM
Oops, I didnt bother to update this thread when I switched servers around. Here are the latest updates from bitcoinrelaynetwork.org, copied:

September 16th: New topology is now active, but having some issues with GFW. New HK node is thus not yet available to connect to as it might have to move again. Got a new IP for the HK server, which seems to have fixed the GFW issues, so it has been enabled and the stats have been reset and reenabled.
September 15th: DigitalOcean Singapore's generally shitty service finally pissed me off enough and I destroyed that server when it went down yet again. Waiting on a new Hong Kong server to be provisioned from a new provider and switched to a different host in Singapore which has much better routing and will be used as a hop-only node (ie be used for transit and will not be connectable by clients). Stats are broken but the rest of the network should generally not have any problems.


Title: Re: How (and why) to use the Relay Network
Post by: p3yot33at3r on November 03, 2015, 09:25:49 PM
Is the network down?   :(


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on November 04, 2015, 10:47:44 AM
Is the network down?   :(
No known issues atm.


Title: Re: How (and why) to use the Relay Network
Post by: p3yot33at3r on November 05, 2015, 01:46:15 AM
Is the network down?   :(
No known issues atm.

Sorted, my dns were playing up.... :P


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on November 11, 2015, 09:27:43 PM
If you're one of the many users still (somehow) using version "toucan twink" you need to upgrade NOW. At some point in the next day or two the servers will start simply dropping your connections.


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on November 11, 2015, 09:28:06 PM
If you're not, update coming soon that you should really upgrade to as well :).


Title: Re: How (and why) to use the Relay Network
Post by: kano on November 11, 2015, 10:08:25 PM
Yeah as you probably know already :)
Those numbers I posted in the solo ckpool thread about the first solo ckpool orphan, they were my log of relay network times, not my pool bitcoind times.
So if f2pool is using the relay network, it took almost 5seconds for the east coast relay to see the f2pool block ...

Edit:
Code:
[2015-11-11 14:00:48.440+00] 0000000000000000045792b02a12ecf0767d50d392471a3fded2371d56ab7b8a recv'd, size 998146 with 111285 bytes on the wire                 
[2015-11-11 14:00:53.293+00] 000000000000000008f0667bc0b60726ea2035d1bc6ab1910f81f2ed19d8741e recv'd, size 999907 with 954717 bytes on the wire                 
00457 was solo
008f0 was f2pool


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on November 12, 2015, 04:23:15 AM
Network performance for the past week or so has been rather dismal. 5 seconds seems pretty excessive, but either way I just pushed a rather large update to github and on the servers. It should improve compression a ton (and also drops connections for those using many-months-old clients).


Title: Re: How (and why) to use the Relay Network
Post by: -ck on November 12, 2015, 11:18:16 AM
Bytes on the wire seem lower than ever, good work.


Title: Re: How (and why) to use the Relay Network
Post by: kano on November 12, 2015, 01:49:02 PM
Yeah now seeing full 1M blocks with as low as 4k on the wire ... very nice :)


Title: Re: How (and why) to use the Relay Network
Post by: kano on November 13, 2015, 03:10:53 AM
Had 2 relay issues in the last few hours.
One where it went down for a short while.

Another, at the moment, where I'm only seeing blocks coming from the relay (for the last 3 blocks), no txns coming or going - so the blocks are about the same size 'on the wire'
It's also slower than one of my non-relay bitcoinds so I'm guessing there's a problem?
(code is of course current as at ea55c37)

Edit: restart (temporarily) fixed it, but it only lasted 327 txns until it stopped again.
(and a second restart lasted 326)


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on November 13, 2015, 08:45:32 AM
Had 2 relay issues in the last few hours.
One where it went down for a short while.

Another, at the moment, where I'm only seeing blocks coming from the relay (for the last 3 blocks), no txns coming or going - so the blocks are about the same size 'on the wire'
It's also slower than one of my non-relay bitcoinds so I'm guessing there's a problem?
(code is of course current as at ea55c37)

Edit: restart (temporarily) fixed it, but it only lasted 327 txns until it stopped again.
(and a second restart lasted 326)
There were some server issues this evening (PST). I'm monitoring closely but expect some hiccups in the next day or two. Client restarts should (hopefully) not be required as they will reset when your connection to the server is reset, but do notify me if a client restart fixes things.


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on November 23, 2015, 06:03:21 AM
Is anyone still accessing the Relay Network via the P2P protocol (ie via -addnode)? I would very much like to turn that off in the coming days....speak now or forever get your connections -j REJECT'ed.


Title: Re: How (and why) to use the Relay Network
Post by: o_solo_miner on December 14, 2015, 10:47:20 PM
simple question:
is there a "how to" written somewhere where I can read a bit on how to install and use it for
bitcoind on a Linux System and cgminer on windows?
I tryed => relaynetworkclient.exe 192.168.2.112 8332 public.eu.relay.mattcorallo.com
where 192.168.2.112 is my bitcoind server on port 8332
The programm run on win but i see no messages or what so ever?

Using server public.eu.relay.mattcorallo.com is the only info it displayes


Title: Re: How (and why) to use the Relay Network
Post by: e46btc on December 15, 2015, 05:54:56 AM
Use bitcoind 8333 port, but not RPC port 8332


Title: Re: How (and why) to use the Relay Network
Post by: o_solo_miner on December 15, 2015, 10:14:14 AM
TY, changed that and opend the port 8333 to be on the linux machine.

Edit:

should I insert an addnode for the relay in the bitcoind.conf or using connect?
because the relayclient is running on a different machine, or is it generaly not possible to
have them seperated?



Maybe clear up some (stupid) questions:

What kind of Windows version the client is desigend to run on?
Is it possible to build a linux client version?

Well the title of this thread is "How a miner use the relay Network", the why is clearly stated but I realy miss the how to!
Well, is not my day today, sry!


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on December 15, 2015, 10:08:53 PM
The relay client will gladly work on a separate machine (most larger users do this, I believe), but is really only designed to run on the same LAN/on a network with incredibly low latency and great bandwidth between your relay client and your bitcoind. As for running it on Windows, it should work, in theory, but recent comments by other windows users indicate that it may not work at all (see https://github.com/TheBlueMatt/RelayNode/issues/16 (https://github.com/TheBlueMatt/RelayNode/issues/16)). Since I dont have anything running Windows I cant test it outside of Wine.


Title: Re: How (and why) to use the Relay Network
Post by: o_solo_miner on December 15, 2015, 10:21:44 PM
Thank you Matt, I will try it on my Debian machine (bitcoind is also there) and for shure it will work.
I saw you on Youtube explaining the hole thing, wich helped a lot to understand the reason for it.
 :D TCP sucks






Title: Re: How (and why) to use the Relay Network
Post by: dan91 on January 07, 2016, 01:04:03 PM
Hi, i am using the windows exe version. Is it normal for it to be using 40+ % CPU usage on an i5 3570K at 4Ghz? Just wanted to check to see if it was perhaps something wrong.


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on January 07, 2016, 06:38:29 PM
Hi, i am using the windows exe version. Is it normal for it to be using 40+ % CPU usage on an i5 3570K at 4Ghz? Just wanted to check to see if it was perhaps something wrong.
That is definitely wrong. It shouldn't average more than 1-5%, maybe with spikes up higher, but 40% is crazy unless you built it in test mode.


Title: Re: How (and why) to use the Relay Network
Post by: dan91 on January 07, 2016, 06:52:26 PM
Hi thanks for getting back to me, i am using the .exe in the master branch in the client folder. Is this not recommended?

https://i.imgur.com/85Pyv05.png


Title: Re: How (and why) to use the Relay Network
Post by: xyzzy099 on January 07, 2016, 07:07:49 PM
Hi, i am using the windows exe version. Is it normal for it to be using 40+ % CPU usage on an i5 3570K at 4Ghz? Just wanted to check to see if it was perhaps something wrong.
That is definitely wrong. It shouldn't average more than 1-5%, maybe with spikes up higher, but 40% is crazy unless you built it in test mode.

I am seeing a consistent 25% cpu usage with windows on my i7-3820 @ 3.6GHz.  Also using the client binary from the client folder in the repository.


Title: Re: How (and why) to use the Relay Network
Post by: dan91 on January 08, 2016, 01:48:39 PM
I fired up a linux vm and running it in that now. It seems to work fine :)


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on January 10, 2016, 10:52:15 PM
Note: The Relay Network is no longer being actively maintained. If you wish to take over its operation and keep it running, please contact me.


Title: Re: How (and why) to use the Relay Network
Post by: -ck on January 11, 2016, 12:31:16 AM
Note: The Relay Network is no longer being actively maintained. If you wish to take over its operation and keep it running, please contact me.
This is a real shame since it was an obvious boon to minimising orphans. Does this mean you're only stopping development of the code and maintenance of it or are you shutting down the servers too?


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on January 11, 2016, 02:13:21 AM
Does this mean you're only stopping development of the code and maintenance of it or are you shutting down the servers too?
Development, first. There's about three months of changes that I think would be much faster that seem to work, but I'm not gonna switch the servers to using them since that would mean a ton of work debugging when they inevitably fall over in production. Eventually I'll probably shut down the servers, since it would be nice if other people ran similar networks anyway.


Title: Re: How (and why) to use the Relay Network
Post by: dan91 on January 11, 2016, 11:23:46 AM
Does this mean you're only stopping development of the code and maintenance of it or are you shutting down the servers too?
Development, first. There's about three months of changes that I think would be much faster that seem to work, but I'm not gonna switch the servers to using them since that would mean a ton of work debugging when they inevitably fall over in production. Eventually I'll probably shut down the servers, since it would be nice if other people ran similar networks anyway.

Is the code for the severs available anywhere? I have only managed to find the clients.


Title: Re: How (and why) to use the Relay Network
Post by: bitsolutions on January 11, 2016, 05:51:41 PM
Is the code for the severs available anywhere? I have only managed to find the clients.
It's just a different option in the makefile. You can see it here (https://github.com/TheBlueMatt/RelayNode/blob/master/c%2B%2B/Makefile#L109).


Title: Re: How (and why) to use the Relay Network
Post by: jtoomim on January 11, 2016, 10:49:43 PM
Matt, I'm asking around to see if we can find one or two people to take over maintenance of the code and maintenance of the infrastructure.


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on January 12, 2016, 12:21:15 AM
Matt, I'm asking around to see if we can find one or two people to take over maintenance of the code and maintenance of the infrastructure.
To be fair, having a miner or  pool do it would be a significant conflict of interest. That, and I'd largely prefer to have multiple people run different networks, so I'd kinda prefer to not hand over the network as it is, and just shut it down at some point.


Title: Re: How (and why) to use the Relay Network
Post by: jtoomim on January 12, 2016, 03:10:28 AM
The conflict of interest issue can probably be handled. I think Jeff Garzik is trying to set up a company of bitcoin-developers-for-hire. We could set up a multisig wallet which various miners pay into voluntarily, and where the keys are distributed among the miners and/or other caretaker entities, and use that to pay for a professional, politically neutral maintainer.

Balancing between "conflict of interest in how it is run" and "interested in making sure it continues to run" can be tricky to get right, but I think the worst thing we can do is to abandon it before we've got the replacement ready.

I think most of the potential conflicts of interest would be present in the choices of where to place relay nodes. Am I right? Do you think it would be okay to have a miner or pool (or two) contribute the code maintenance to keep it running?


Title: Re: How (and why) to use the Relay Network
Post by: theRattler on January 19, 2016, 12:24:38 PM
Is it correct that list of pools here has gone un-updated in a long time it seems incomplete... I thought that most major pools and large miners were connecting to the relay network in some capacity...?


Title: Re: How (and why) to use the Relay Network
Post by: WBF1 on February 24, 2016, 09:11:03 PM
Is this functional but just not actively maintained? Don't want to put effort in to getting up and running if it won't connect anywhere.


Title: Re: How (and why) to use the Relay Network
Post by: p3yot33at3r on February 24, 2016, 09:27:56 PM
Is this functional but just not actively maintained? Don't want to put effort in to getting up and running if it won't connect anywhere.

It's working fine.


Title: Re: How (and why) to use the Relay Network
Post by: WBF1 on February 25, 2016, 03:04:23 AM
Does "on the wire" mean the amount left remaining to get for the new block?


Title: Re: How (and why) to use the Relay Network
Post by: WBF1 on February 25, 2016, 04:16:56 AM
also, does this currently not relay blocks mined on bitcoin classic? seems to cause an issue for me whenever one is being mined (for example, block 399914).

Without relaying this block, bitcoind tells me the relay client is misbehaving when it tries to relay the next block.


nevermind it was a miscofiguration on my end.


Title: Re: How (and why) to use the Relay Network
Post by: o_solo_miner on March 10, 2016, 03:54:32 PM
 ??? looks like that the public.eu.relay.mattcorallo.com Node is down, as I got this message:

[2016-03-10 12:39:25.858+00] 00000000000000000149a9d6ccc79d07f460bbe888bc220e9ed643b3ba0226ec sent, size 998129 with 882427 bytes on the wire
[2016-03-10 12:39:25.868+00] public.02.relay.mattcorallo.com Disconnect: failed to read message header (Broken pipe)


I manualy changed to US-WEST and that works.
Strange, as it went down after the blockfound message.

Anybody else with problems on eu?


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on March 10, 2016, 08:23:39 PM
Yea, eu went down for a bit...should be good now.


Title: Re: How (and why) to use the Relay Network
Post by: o_solo_miner on March 10, 2016, 08:28:05 PM
Thank you matt
now it works ok.

I was just suprised, never got an error before.






Title: Re: How (and why) to use the Relay Network
Post by: -ck on March 10, 2016, 08:36:36 PM
Hey Matt. Any update on what the plans are for your invaluable network? Thanks.


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on March 10, 2016, 10:39:23 PM
I was just suprised, never got an error before.
Servers go down sometimes :).

Hey Matt. Any update on what the plans are for your invaluable network? Thanks.
Until other things that are much higher priority (ie the current drama) is dealt with, I will keep restarting servers when they go down but no other changes are gonna happen...I'll revisit things in a month or three.


Title: Re: How (and why) to use the Relay Network
Post by: MeatPopsicle on March 13, 2016, 11:44:06 PM
If worst comes to worst could you throw together a short docu on how the server components fit together? Trying to piece together how and with what each of them talk to by digging through the C code is less than optimal.


Title: Re: How (and why) to use the Relay Network
Post by: mmeijeri on March 16, 2016, 04:28:41 PM
I didn't want to wade through 19 pages of text and I know this has been answered before, but why would it be a bad idea to integrate this into the P2P network on a bilateral basis? Wouldn't it still help a bit?


Title: Re: How (and why) to use the Relay Network
Post by: kano on March 16, 2016, 09:56:54 PM
I didn't want to wade through 19 pages of text and I know this has been answered before, but why would it be a bad idea to integrate this into the P2P network on a bilateral basis? Wouldn't it still help a bit?
Yeah I asked that already ... the problem is that at least some of the bitcoin devs are morons.
https://github.com/bitcoin/bitcoin/issues/7049

... especially when you get the part where gmaxwell considers exceptionally useful code black magic :P


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on May 05, 2016, 04:11:06 AM
I didn't want to wade through 19 pages of text and I know this has been answered before, but why would it be a bad idea to integrate this into the P2P network on a bilateral basis? Wouldn't it still help a bit?
See https://github.com/TheBlueMatt/bips/blob/master/bip-TODO.mediawiki (https://github.com/TheBlueMatt/bips/blob/master/bip-TODO.mediawiki) for something similar which is more targeted at the P2P nature of Bitcoin. See-also https://github.com/TheBlueMatt/bitcoin/tree/udp-wip (https://github.com/TheBlueMatt/bitcoin/tree/udp-wip) for something which is intended to eventually replace the Relay Network - a whitelisted-peers-only secondary relay channel that is easy for miners to use between their own nodes (ie its just an additional flag) and will also be much faster than the relay network today in its worst-case (and probably average) relay times.


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on May 27, 2016, 09:08:54 PM
For those paying attention...The relay network donation address was recently nearly entirely depleted to pay for a new set of servers...The network is going to switch entirely to a new infrastructure based on bitcoind with UDP-FEC (ie no more delays from TCP lag) which allows for cut-through routing by rumoring UDP-FEC packets around the entire network before receiving the entire block. You can find the source for this patch at https://github.com/TheBlueMatt/bitcoin/tree/udp-wip (https://github.com/TheBlueMatt/bitcoin/tree/udp-wip)...The API to it is being refactored to enable the cut-through routing optimizations, and note that it includes some LGPL components in the binary, so its probably all secretly under LGPL, but IANAL, please dont sue me.


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on July 07, 2016, 09:31:25 PM
So I'm sure everyone has seen, by now, my blog post on the future of the relay network (http://bluematt.bitcoin.ninja/2016/07/07/relay-networks/). I do have a test-network based on FIBRE which has shown incredibly good performance, but I'm not quite sure if I will allow public connections to it (it currently only connects to random nodes on the public P2P network and to the original relay network) or allow others to use FIBRE to take up the mantle of running high-speed relay networks. For now, the original relay network continues to run and the FIBRE network running side-by-side is only making it faster!
If you want any help running your own FIBRE-based network, I'm more than happy to help out!


Title: Re: How (and why) to use the Relay Network
Post by: kano on July 07, 2016, 10:23:20 PM
I block all UDP and run no UDP services coz it's been the majority cause of DDoS that occurred since I started the pool ...
... since there is no 'network security' applied to UDP on the internet.


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on July 07, 2016, 11:01:57 PM
I block all UDP and run no UDP services coz it's been the majority cause of DDoS that occurred since I started the pool ...
... since there is no 'network security' applied to UDP on the internet.
If you're talking about running your own FIBRE-based network: No need to enable incoming UDP on pool servers to run FIBRE. TCP/Compact Block relay to servers only a few ms away is plenty fast, so you could just as easily put a relay network server on a separate server (and probably should, given that its still beta and based on Bitcoin Core master just before segwit was merged).

If you're talking about connecting to someone else's: I never really envisioned it as running over UDP between miners and the first-hop server. While this is definitely an option (and FIBRE has an "untrusted" mode for this), there is little advantage to spending 10ms calculating FEC data over just eating the 10ms RTT for a dropped packet or two if the servers are nearby. FIBRE is great for long-haul links, but Compact Blocks work just as well if you're talking about short-hops.

General note: FIBRE's UDP does have a shared-key HMAC in each packet, so that packets are easily and trivially authenticated.


Title: Re: How (and why) to use the Relay Network
Post by: kano on July 07, 2016, 11:14:36 PM
I block all UDP and run no UDP services coz it's been the majority cause of DDoS that occurred since I started the pool ...
... since there is no 'network security' applied to UDP on the internet.
If you're talking about running your own FIBRE-based network: No need to enable incoming UDP on pool servers to run FIBRE. TCP/Compact Block relay to servers only a few ms away is plenty fast, so you could just as easily put a relay network server on a separate server ...
Yep good solution.
One collection of 'satellites' I have are sub 1ms (around 1/3ms)

Quote
(and probably should, given that its still beta and based on Bitcoin Core master just before segwit was merged).
Well looks like I'll be behind the times for a while if it's been merged, coz yeah not really interested in adding code to centralise bitcoin and give away mining fees to those centralising it so they can take those fees.


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on July 07, 2016, 11:17:53 PM
If anyone is looking to set up a FIBRE-based network, I'm happy to share the slow-as-fuck bash script which generates the slow-to-render pretty graphs on test network stats page (http://bitcoinfibre.org/stats.html).


Title: Re: How (and why) to use the Relay Network
Post by: -ck on September 18, 2016, 12:36:31 PM
This has been misbehaving for the last week or so. Any chance it could get a kick?


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on October 18, 2016, 03:46:36 PM
Hi folks,

I'd like to turn off the relay network on December 1st. For that to happen, I'd like to first have a public relay network of nodes based on FIBRE available ASAP.

In order to make the network much more reliable/lower-latency than the original relay network, I'd like to use real servers with good,
dedicated, bandwidth. I speced out a network which would cost about $1550/month and would have public peering nodes in Hong Kong, Tokyo, Seattle, Washington DC, Beijing, and one of London/Amsterdam/Frankfurt. Additionally, there would be (at least) one node in Siberia to utilize the TEA Cable route.

A few folks have already agreed to chip in to make this a reality, but I'd love to see a few more so that we can make it incredibly cheap for
everyone involved. If you'd like to help, I'm looking for people willing to make commitments to cover a fair share of the above costs, and would list the sponsors on bitcoinrelaynetwork.org (which would be updated with new info).


Title: Re: How (and why) to use the Relay Network
Post by: kano on October 18, 2016, 11:36:34 PM
Well ... a few things.

I take it that the current relay network has been crappy for a while coz you decided you weren't getting enough sponsorship?
i.e. when the sponsorship isn't enough in your (unstated) opinion you just let it go to crap?
(No I've never sponsored it - but I do connect to every relay ... even the long dead hk one - our ckpool block relay is faster than using the relay to distribute to other relay nodes so I connect to all nodes to get our blocks out faster)

Unless you have the top pools connected (i.e. every pool over a few % of the network) it's value is marginal so I'd think you should actually list the pools that are sponsoring and are connected - and update it when that changes - since that's not a large list.
I'd also suggest you whitelist access to most of it. That way you know who is connected and know it is still useful.
e.g. f2pool wasn't on the relay until long after the relay existed, and I've no idea if all of the 3 bitmain pools use it. Bitfury's high orphan rate at times makes me wonder if they have always used it.

Well I'm certainly no where near 7% of the network but I'll put forward ~$100 in BTC :) a month towards it (as long as the biggest pools are on it)
N.B. none of my servers but the single main back end cost me even half of that :) So I guess this network is either using an expensive provider or high end servers on every node :)


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on October 19, 2016, 06:11:39 PM
I take it that the current relay network has been crappy for a while coz you decided you weren't getting enough sponsorship?
i.e. when the sponsorship isn't enough in your (unstated) opinion you just let it go to crap?
(No I've never sponsored it - but I do connect to every relay ... even the long dead hk one - our ckpool block relay is faster than using the relay to distribute to other relay nodes so I connect to all nodes to get our blocks out faster)
Yea, the HK one died after the host decided to wipe the drive on the server when the NIC failed....yes, you read that right. I didn't bother to re-install since a) I dont actually remember how to reinstall that stuff, and havent had time to look it up (FIBRE is so much easier...) and b) I want to turn the thing off for SegWit (though getting a public FIBRE network up has taken longer than expected :/.

Unless you have the top pools connected (i.e. every pool over a few % of the network) it's value is marginal so I'd think you should actually list the pools that are sponsoring and are connected - and update it when that changes - since that's not a large list.
I'd also suggest you whitelist access to most of it. That way you know who is connected and know it is still useful.
e.g. f2pool wasn't on the relay until long after the relay existed, and I've no idea if all of the 3 bitmain pools use it. Bitfury's high orphan rate at times makes me wonder if they have always used it.
Indeed, one of the things I'm planning on doing is listing those sponsoring on the site by putting their logo up. I assume if folks are paying 2-300$/month for something they will use it. Indeed, it was an uphill battle to get people to use it initially, but its much better these days. Bitfury still has some insanity occasionally, but I'm working with them to solve it.

Well I'm certainly no where near 7% of the network but I'll put forward ~$100 in BTC :) a month towards it (as long as the biggest pools are on it)
N.B. none of my servers but the single main back end cost me even half of that :) So I guess this network is either using an expensive provider or high end servers on every node :)
Yea, they're all dedicated servers since the random lag introduced by VPSes was incredibly annoying. Sadly, for dedicated servers, unlike virtual ones, it can be hard to get them in good locations in some places (APAC especially), and its also very nice to have them all on one network, so they're all on Softlayer. They're a bit more expensive than neccessary, but they have really, really good latency between any two points on their network (with the exception of JPY<->EU as they dont have TEA bandwidth), as well as solid peering in Tokyo/HK with PCCW/Pacnet, which is important for China.


Title: Re: How (and why) to use the Relay Network
Post by: newIndia on October 19, 2016, 06:37:51 PM
@Matt I think it is good if u please update OP with FIBRE related information.


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on November 01, 2016, 07:44:17 PM
The new peering instructions are up at http://bitcoinfibre.org/public-network.html (http://bitcoinfibre.org/public-network.html).


Title: Re: How (and why) to use the Relay Network
Post by: kano on November 01, 2016, 09:47:09 PM
The new peering instructions are up at http://bitcoinfibre.org/public-network.html (http://bitcoinfibre.org/public-network.html).
So correct me if I'm wrong but ...

Old network
'Relay' to 'local' using TCP but only a small 'compressed' block and that passes it to the local bitcoind for full verification

New network
'Relay' to 'remote' using UDP, full size 'compressed' block?, full verification?, then pass to 'local' bitrcoind for full verification again

So ... that looks like it's slower than before ...

... and also I must run segwit ... which I don't want to do.

... and of course any pool that would open their main bitcoind to UDP traffic (to remove the extra step) clearly has never considered the risks of doing that or has no idea about how UDP works ... as I brought up before ...


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on November 02, 2016, 12:09:41 AM
So correct me if I'm wrong but ...

Old network
'Relay' to 'local' using TCP but only a small 'compressed' block and that passes it to the local bitcoind for full verification

New network
'Relay' to 'remote' using UDP, full size 'compressed' block?, full verification?, then pass to 'local' bitrcoind for full verification again
Really not sure what you're trying to say here, but - New network is UDP between its own servers (dedicated 1Gbps on every link except the Beijing one, but its fast enough, too), but then Bitcoin-P2P protocol between the servers and clients. Hopefully you're using Bitcoin 0.13+ so you'll be using compact blocks, which are generally more effecient than the old relay network protocol by a decent margin (plus I have some hacks to force compact block clients into low-latency mode). If you have a server which is particularly far from the nearest relay network server I'm happy to talk about setting up something that isnt Bitcoin-P2P, and am thinking about doing FIBRE-based peering (so UDP floods for block announce).

... and also I must run segwit ... which I don't want to do.
Nope, see https://github.com/bitcoinfibre/bitcoinfibre/commit/335f87424a60af1fc02bffb7c84e90b8e2eadeca (https://github.com/bitcoinfibre/bitcoinfibre/commit/335f87424a60af1fc02bffb7c84e90b8e2eadeca) which will fast-relay compact blocks out to peers within a few ms of receiving the block if either a) you're a segwit peer or b) segwit has not activated.

... and of course any pool that would open their main bitcoind to UDP traffic (to remove the extra step) clearly has never considered the risks of doing that or has no idea about how UDP works ... as I brought up before ...
Ahh, I see the misunderstanding - nope, its only Bitcoin-P2P publicly for now.


Title: Re: How (and why) to use the Relay Network
Post by: kano on November 16, 2016, 05:49:32 AM
OK, so correct me if I'm wrong, but why is a slower relay considered better?

If I understand the limitations you've added correctly, all you have done is speed up your internal UDP relay, but replaced the external connections to it with a slower relay and added excessive burden on the bitcoind.

The current (old) relay means there's a program (normally) local to the bitcoind that's hit with transactions at whatever rate is happening with the relay, then when a block is found, the traffic from your service is minimal, usually just a small compressed block, and then the local relay pushes a whole block to the local bitcoind that happens to (normally) be 0ms away, so no network issue at all.

With this new 'connect a bitcoind' directly to your network, all traffic from your network comes and goes directly to the main bitcoind.
How is the block compression compared to the current (old) relay?
Do you send transactions from your new relay to the bitcoind? Coz that will also be an unwanted thing to happen.

Basically it sounds like the new relay is really a transaction improvement relay, not a block relay improvement, so an improvement for payment sources, but a slower block relay for pools.

Your internal network may be faster, but the external network seems slower by design.

Edit: here's the last 50 old relay block sizes in transferred bytes (that last number). What's the new one for these?
Code:
[2016-11-16 02:48:11.106+00] ..00092682eadc186df.. recv'd, size 480071 with 7759 bytes 
[2016-11-16 02:48:43.987+00] ..00090e83c28f2e244.. recv'd, size 40890 with 372 bytes
[2016-11-16 02:58:44.541+00] ..001df2eba7161c6f3.. recv'd, size 815374 with 6467 bytes
[2016-11-16 03:17:48.229+00] ..00194859b7edddd08.. recv'd, size 749215 with 4347 bytes
[2016-11-16 03:21:53.697+00] ..000b8a18e37427efc.. recv'd, size 995350 with 107909 bytes
[2016-11-16 03:24:56.709+00] ..001f852409054b6b9.. recv'd, size 379872 with 55638 bytes
[2016-11-16 03:45:50.157+00] ..00390e6e74393934d.. recv'd, size 998890 with 43410 bytes
[2016-11-16 03:54:36.501+00] ..000177238c9682e4f.. recv'd, size 998190 with 4671 bytes
[2016-11-16 04:12:17.972+00] ..0044f0b258077f23c.. recv'd, size 998142 with 5109 bytes
[2016-11-16 04:18:16.561+00] ..00048ef2fddab806c.. recv'd, size 775518 with 3192 bytes
[2016-11-16 04:19:00.934+00] ..0033c9e6d5f71d09b.. recv'd, size 102301 with 54094 bytes
[2016-11-16 04:19:12.686+00] ..002f51db6db619e07.. recv'd, size 42063 with 414 bytes
[2016-11-16 04:19:30.174+00] ..002a16788c9ad4aef.. recv'd, size 55625 with 382 bytes
[2016-11-16 04:19:39.133+00] ..000dc7a6eed875d98.. recv'd, size 8488 with 6485 bytes
[2016-11-16 04:42:00.685+00] ..00335deb00d796f75.. recv'd, size 999967 with 5814 bytes
[2016-11-16 04:48:45.110+00] ..0030cc64619151b69.. recv'd, size 859533 with 3710 bytes
[2016-11-16 04:52:07.216+00] ..0020d7cec45f78a15.. recv'd, size 998197 with 709974 bytes
[2016-11-16 04:58:05.087+00] ..001994c1f03adbbe9.. recv'd, size 362497 with 2132 bytes
[2016-11-16 05:11:25.948+00] ..0036ef48e33c117c7.. recv'd, size 999164 with 82598 bytes
[2016-11-16 05:13:17.240+00] ..0038a1e01b6de37cf.. recv'd, size 145171 with 693 bytes
[2016-11-16 05:27:12.666+00] ..000761cf6e37b57af.. recv'd, size 998038 with 4244 bytes
[2016-11-16 05:27:30.403+00] ..00398a5b97f368fec.. recv'd, size 97689 with 632 bytes
[2016-11-16 05:36:41.080+00] ..003c56ee2ea460182.. recv'd, size 755314 with 3028 bytes
[2016-11-16 05:43:48.049+00] ..003ddbca9351653f9.. recv'd, size 592994 with 34850 bytes
[2016-11-16 05:51:45.980+00] ..000ed0e3df1e5d3f9.. recv'd, size 993582 with 358432 bytes
[2016-11-16 06:03:21.346+00] ..00354d61136d8659a.. recv'd, size 879448 with 9050 bytes
[2016-11-16 06:06:48.633+00] ..003738fe282036c86.. recv'd, size 341092 with 86181 bytes
[2016-11-16 06:13:56.436+00] ..00335e2307e39a9eb.. recv'd, size 543532 with 2902 bytes
[2016-11-16 06:35:00.886+00] ..003659797406d34c9.. recv'd, size 999045 with 91518 bytes
[2016-11-16 06:37:33.387+00] ..002fe93e6a654620e.. recv'd, size 562524 with 2522 bytes
[2016-11-16 06:39:35.114+00] ..00048cf85b8a28f1c.. recv'd, size 111666 with 826 bytes
[2016-11-16 06:42:45.695+00] ..0019e8ee8a754b8c3.. recv'd, size 997973 with 722715 bytes
[2016-11-16 06:47:39.188+00] ..002a3bb0e0abf4450.. recv'd, size 275764 with 1653 bytes
[2016-11-16 06:48:22.713+00] ..0013298e19f4ab876.. recv'd, size 120658 with 469 bytes
[2016-11-16 06:49:07.700+00] ..003fe9c7f91392e0f.. recv'd, size 135217 with 78859 bytes
[2016-11-16 07:11:23.336+00] ..001ece483a24a3504.. recv'd, size 997997 with 6018 bytes
[2016-11-16 07:12:14.726+00] ..00415a03fd0ad8d16.. recv'd, size 749156 with 80903 bytes
[2016-11-16 07:23:08.089+00] ..000a731efbfec2080.. recv'd, size 997997 with 2541 bytes
[2016-11-16 07:25:22.546+00] ..0012d0155e0a287c1.. recv'd, size 683120 with 36350 bytes
[2016-11-16 07:36:08.687+00] ..002073bf93047c1bd.. recv'd, size 684824 with 3809 bytes
[2016-11-16 07:46:41.966+00] ..001feaae195e3d206.. recv'd, size 849255 with 4149 bytes
[2016-11-16 07:47:09.905+00] ..003d2504008e560cc.. recv'd, size 997374 with 918590 bytes
[2016-11-16 07:47:41.005+00] ..00252cb551eb2ba3e.. recv'd, size 49173 with 329 bytes
[2016-11-16 08:13:43.015+00] ..0029b70d5b108efbb.. recv'd, size 997890 with 5902 bytes
[2016-11-16 08:17:14.009+00] ..001b4ec9166d9a8b6.. recv'd, size 998211 with 4539 bytes
[2016-11-16 08:22:23.174+00] ..001c33f82658413f9.. recv'd, size 807397 with 3143 bytes
[2016-11-16 08:26:39.030+00] ..000001c04a845d6d1.. recv'd, size 307998 with 1756 bytes
[2016-11-16 08:28:48.756+00] ..001caa93923bb5cec.. recv'd, size 201068 with 1220 bytes
[2016-11-16 08:28:50.152+00] ..0006c8dbd2026ce8a.. recv'd, size 191 with 127 bytes
[2016-11-16 08:56:17.868+00] ..003c616e0ac5df293.. recv'd, size 998106 with 5367 bytes


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on November 16, 2016, 10:02:36 PM
OK, so correct me if I'm wrong, but why is a slower relay considered better?

If I understand the limitations you've added correctly, all you have done is speed up your internal UDP relay, but replaced the external connections to it with a slower relay and added excessive burden on the bitcoind.
Not sure what "excessive burden" you're referring to here - replacing one P2P connection with another shouldn't change the load on your bitcoind, even if one is remote...If you really want to split hairs you should see less load on your bitcoind because the message hashing for an entire block no longer happens.

The current (old) relay means there's a program (normally) local to the bitcoind that's hit with transactions at whatever rate is happening with the relay, then when a block is found, the traffic from your service is minimal, usually just a small compressed block, and then the local relay pushes a whole block to the local bitcoind that happens to (normally) be 0ms away, so no network issue at all.
Not quite...the old relay network protocol is bandwidth-limited to only send out a certain number of transactions per second (I think its like 5Mbps, so it shouldnt ever really hit that, but it does means that if you get a burst it could get behind.

With this new 'connect a bitcoind' directly to your network, all traffic from your network comes and goes directly to the main bitcoind.
How is the block compression compared to the current (old) relay?
Compact Blocks get much better compression than the old relay network in real-world testing. There are a few minor tweaks that need to happen that will take them from reasonably-often-missing-transactions to rarely-missing-transactions (including orphan pool, recent-replacements, etc).

Do you send transactions from your new relay to the bitcoind? Coz that will also be an unwanted thing to happen.
This isnt a change from the old behavior - the old client used to send transactions it received to bitcoind locally ((re-)starting a relay network client remains one of the easiest ways to get your mempool filled after restart a node, at least until 0.14).

Basically it sounds like the new relay is really a transaction improvement relay, not a block relay improvement, so an improvement for payment sources, but a slower block relay for pools.

Your internal network may be faster, but the external network seems slower by design.
Compact Blocks is a far, far superior protocol to use on the wire vs the old realy network protocol, and the fact that its in bitcoind directly instead of via an external daemon means the latency of it can be much lower (it can skip, for example, the hash-message-check-message-hash stuff that happens now). Indeed, there is a drawback of occasionally having an extra round-trip from clients to relay network servers, but current testing shows that a) the improvement in average latency between the servers far outweighs most RTTs to clients (eg within a continent you shouldn't see more than 50-100ms RTT), b) its relatively easy to shave another 10-30ms (yes, really, its that bad) off the total receive->ProcessNewBlock time, which should all happen in 0.14, in compact blocks, whereas for the RN code its really not so trivial, and c) we can hopefully make the RTTs much less common with some simple fixes which the compact blocks protocol already supports, just aren't yet implemented.


Title: Re: How (and why) to use the Relay Network
Post by: kano on November 16, 2016, 11:35:22 PM
...
With this new 'connect a bitcoind' directly to your network, all traffic from your network comes and goes directly to the main bitcoind.
How is the block compression compared to the current (old) relay?
Compact Blocks get much better compression than the old relay network in real-world testing. There are a few minor tweaks that need to happen that will take them from reasonably-often-missing-transactions to rarely-missing-transactions (including orphan pool, recent-replacements, etc).
...
Do you have numbers to compare - coz that's really the point here.
I of course have the old compression numbers for every block since the beginning of time since I've used your relay :P
If the new one is better compression (= faster block transmission) then you can say that if you have numbers :)
Post a run of any 100 blocks and I'll get the same blocks and see (like my 50 block post above) - that's really what I want to see.

Edit: well to make it simpler - all blocks 439000 to whenever you can find the stats (currently 439277)

Edit2: there's also another question in the interface design - what's the comparison of the 2 for back and forward communication?
e.g. comparing the two (I don't know what that are)
1) 'send block'-> (finished)
2) 'message'-> 'reply'<- 'block'-> (finished)
0r
3) something else added to handle the txns
Or
4) ...
etc.

My main concern is that bitcoind sux.
It's hopeless at keeping connections and has too much overhead.
The relay seemed to be able to keep the connection for a long time (I have counters that display in a different colour when it loses/regains the connections) so I've seen how reliable that can be.
(I don't "watch" the old relay log, I instead have a script run a simple analysis of the last 9999 lines in the log every 10 seconds)
I suspect that the relay was pretty minimal in back and forth communication and data size vs bitcoind.


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on November 17, 2016, 01:47:08 AM
Do you have numbers to compare - coz that's really the point here.
I of course have the old compression numbers for every block since the beginning of time since I've used your relay :P
If the new one is better compression (= faster block transmission) then you can say that if you have numbers :)
First of all, you're making a common mistake here - less data != faster block transmission when you're talking about things in the 1-20k range. The extra cost of a packet isnt a ton (loss is not hugely likely if you're on a decent connection until you start talking about 100k+ data) and the extra transmission time of a packet is virtually nothing - so an additional 20ms in receive->ProcessNewBlock time is often worth it. With stuff like https://github.com/bitcoin/bitcoin/pull/9125 (https://github.com/bitcoin/bitcoin/pull/9125) this is very realistic.

Post a run of any 100 blocks and I'll get the same blocks and see (like my 50 block post above) - that's really what I want to see.
I dont have tons of numbers handy, but if you look at a bitcoind with -debug running that receives blocks not over the RN, then you can easily see compact block reconstruction info (eg blocktxn and cmpctblock message sizes). In my recent log for blocks received over compact blocks most blocks took between 12k and 17k for the blocktxn, and few needed a blocktxn roundtrip (printed in log as having received a 33-byte blocktxn, which isnt a real message on the wire).

Edit2: there's also another question in the interface design - what's the comparison of the 2 for back and forward communication?
e.g. comparing the two (I don't know what that are)
As noted in the previous post, the old RN protocol is one-way as far as blocks are concerned...it makes strong assumptions about knowledge of the other side's mempool (requires you to store the last N txn sent to you by the server), and can thus just send you the compressed block and knows you can reconstruct it. The Compact Blocks protocol isnt so nice, and sometimes requires a round-trip to request missing transactions, though being able to send the cmpctblock message 5-10ms sooner and saving 10-20ms on the receiving side can almost make up for that if you're (reasonably) close to one of the RN servers (eg AWS us-east or us-west should meet that criteria easily). Hopefully further optimizations to the compact block implementation (that the protocol designed for) in 0.14 will will make the likelyhood of round-trips much lower.

My main concern is that bitcoind sux.
It's hopeless at keeping connections and has too much overhead.
The relay seemed to be able to keep the connection for a long time (I have counters that display in a different colour when it loses/regains the connections) so I've seen how reliable that can be.
(I don't "watch" the old relay log, I instead have a script run a simple analysis of the last 9999 lines in the log every 10 seconds)
I suspect that the relay was pretty minimal in back and forth communication and data size vs bitcoind.
Yea, this is something I thought about a lot when considering the protocol change, actually this more than the latency concerns. While I dont know why it would be bad at keeping connections, aside from not reconnecting agressively enough, the agressive reconnection stuff that I have in the old RN is super nice since I can pretty freely restart the servers, etc. As for protocol-chatty-ness, I think they're not that far off, bitcoind will send more transactions, but thats a good thing - more transactions to match the compact block against :).


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on November 28, 2016, 05:25:35 AM
For those using the new FIBRE-based Relay Network, I just added the following paragraph to the public-network page:

"Note that, because bitcoind treats the -addnode argument as an extra seednode it may use, and not as a connection which it should maintain, it is recommended that you use an external daemon to keep the connection reliable. There is a simple connect-two-bitcoinds-together client available in the Relay Network Client Source Tree (called fibrenetworkclient after you run make) which takes, as arguments, two bitcoind instances, and connects them to each other, reliably reconnecting if one goes down."


Title: Re: How (and why) to use the Relay Network
Post by: kano on December 11, 2016, 06:18:07 PM
So since it's now next to impossible to see what's going on in the fibre relay network, you wouldn't happen to know yourself what happened at UTC 2016-12-11 16:43pm for the blocks that came though during that minute?

I can see both sides of the network seeing the two different blocks, but no idea about the timing of the opposing blocks crossing the GFW.
It would seem that the fibre network wasn't getting into china very well at all for the orphan I got then ...
The two I see are mine at 16:43:57.141 UTC and one in china later at 16:43:58.910 UTC (that won the orphan race when antpoo confirmed it)

The old relay stopped 15 minutes before that.

Edit: you should see my block coming in to all non-chinese fibre nodes directly, during that, before the block was found inside china.
Though that depends on bitcoind (0.13.0) and when it got around to deciding to send it to your fibre relay, and when you accepted it.


Title: Re: How (and why) to use the Relay Network
Post by: blacksmithtm on January 01, 2017, 04:29:22 PM
"Note that, because bitcoind treats the -addnode argument as an extra seednode it may use, and not as a connection which it should maintain, it is recommended that you use an external daemon to keep the connection reliable.

Any work on-going on making this step easier? For example a "better" -addnode argument that maintains the connection to the added seednode?


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on January 01, 2017, 04:30:54 PM
Any work on-going on making this step easier? For example a "better" -addnode argument that maintains the connection to the added seednode?
See https://github.com/bitcoin/bitcoin/pull/9319 (https://github.com/bitcoin/bitcoin/pull/9319).


Title: Re: How (and why) to use the Relay Network
Post by: blacksmithtm on January 02, 2017, 03:29:11 PM
Any work on-going on making this step easier? For example a "better" -addnode argument that maintains the connection to the added seednode?
See https://github.com/bitcoin/bitcoin/pull/9319 (https://github.com/bitcoin/bitcoin/pull/9319).

Thank you very much. Excellent stuff.


Title: Re: How (and why) to use the Relay Network
Post by: fasbit on January 17, 2017, 02:59:46 PM
Lets talk Metrics here.... I run a full public bitcoin node with p2pool attached.... my getblock latency mean averages around .25s ... but gets as low as .12s on occasion....
I do not yet have the Relay set up and running.
If my latency is .25s or less, do I NEED a relay? 
./fasbit


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on January 17, 2017, 03:56:45 PM
Lets talk Metrics here.... I run a full public bitcoin node with p2pool attached.... my getblock latency mean averages around .25s ... but gets as low as .12s on occasion....
I do not yet have the Relay set up and running.
If my latency is .25s or less, do I NEED a relay? 
This has nothing to do with getblock latency. This has to do with the time until you see a block. p2pool has no idea how long it took from when someone else found a block to when you received it, and this is the part that relay networks work to solve.


Title: Re: How (and why) to use the Relay Network
Post by: fasbit on January 18, 2017, 04:45:46 PM
Lets talk Metrics here.... I run a full public bitcoin node with p2pool attached.... my getblock latency mean averages around .25s ... but gets as low as .12s on occasion....
I do not yet have the Relay set up and running.
If my latency is .25s or less, do I NEED a relay? 
This has nothing to do with getblock latency. This has to do with the time until you see a block. p2pool has no idea how long it took from when someone else found a block to when you received it, and this is the part that relay networks work to solve.

OK.. got it.  Next Question:

I have whitelisted my IP at the US East coast relay and my regular v13 bitcoin node has it listed as a peer. 
What performance improvements will result from using the specialized "bitcoinfibre" node and using the "addtrustedudpnode" (or "addudpnode") command(s)?
And how can I measure it or see the improvement locally?



Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on January 18, 2017, 06:05:12 PM
The udpnode stuff is not exposed on the public FIBRE instances because I dont significantly trust that there isnt some bug in the implementation somewhere which could cause the nodes to crash with data sent corrupted in some way. The other option (the fibrenetworkclient thing from my RelayNode github) exists only to make sure connections stay up reliably. See two posts up (where we talked about https://github.com/bitcoin/bitcoin/pull/9319 (https://github.com/bitcoin/bitcoin/pull/9319)), which will make -addnode a much more reliable "keep this connection open" option in Bitcoin Core 0.14. fibrenetworkclient shouldn't make any performance difference at all.


Title: Re: How (and why) to use the Relay Network
Post by: aliyagiz207 on June 12, 2017, 08:24:00 AM
Back to your problem
 I do not think that dropped connections have anything in common with bitcoin rpc max threads at all.
Relay client is not using RPC at all. It talks raw to btcd and relay servers
Other thing to check is your BTC max peer count. I had this problem when I reached max peer connections and I have restarted relay client it would never connect.
So one of the hacks to  my btcd deamon is to use peer -1 and always to have a room for relay client  Wink
I am running btcd 0.11 and relay with kano hack (because it never worked without it-thanks kano) and after block downloading again after mats incident it works just fine no issues


Title: Re: How (and why) to use the Relay Network
Post by: kano on June 22, 2017, 02:08:35 PM
Seattle (us-west) fibre relay has been dead for about 45 minutes 2 hours
Fixed :)
Thanks Matt :)


Title: Re: How (and why) to use the Relay Network
Post by: btcwonder1 on June 29, 2017, 12:31:41 PM
I really appreciate your work, Matt. You have no idea how many problems your simple post has solved for me. Thanks a lot!


Title: Re: How (and why) to use the Relay Network
Post by: btctousd81 on September 15, 2017, 02:08:15 PM
idk if this is still managed.,
but i tried building it from source and when i started it

i got

"Failed to parse -udpport option, not starting FIBRE"

even though i had

udpport=8444,8555,8666

in my config file.

i even checked logs for details and found above message.


Title: Re: How (and why) to use the Relay Network
Post by: o_solo_miner on September 21, 2017, 03:40:59 PM
The Relaynode Network has been replaced by fibre and it is build in Core 14 / 15.01.
All you need is to register on the fibre  Network: http://bitcoinfibre.org/public-network.html
Please read the first Page of this topic.
https://bitcointalk.org/index.php?topic=766190.msg8635670#msg8635670


Title: Re: How (and why) to use the Relay Network
Post by: Matt Corallo on September 21, 2017, 07:02:02 PM
"Failed to parse -udpport option, not starting FIBRE"
...
udpport=8444,8555,8666
Not sure exactly what you're trying to do here...As o_solo_miner pointed out, to use the public relay network for receiving-blocks-quickly, you should simply run unmodified Bitcoin Core 14/15 and addnode to one of the FIBRE nodes (see http://bitcoinfibre.org/public-network.html (http://bitcoinfibre.org/public-network.html)).

If you wish to run your own FIBRE network to propagate blocks quickly between your own nodes, note that the udpport syntax (as pointed out in the --help output) is udpport=port,group,bw where port is a port number, group is a monotonically-increasing group id (ie it should be 0, the second port should use 1, etc) and bw is a bandwidth to use for sending to that group, in Mbps.


Title: Re: How (and why) to use the Relay Network
Post by: kano on December 25, 2017, 11:09:28 PM
US-West relay been dead for 2.25 4 hours.
Anyone running a small pool in US-West, make sure you are connected to at least one of the other relays ...

Edit: it was fixed - in case anyone was still wondering :)