For those who have been using this to get faster relays to/from the
network, you may have noticed some instability recently. This is because
the nodes were all being upgraded to use some new relaying code which
should cut down on duplicate transaction relaying in blocks, improving
relay speed withi
In the short-term, maybe. Keep in mind that the code for tx relay is
fairly different and the bandwidth for transaction relay on these
nodes is already lower than it is for blocks (by design). That said,
I'd like to look into doing tx-less block relays for transactions that
peers already have to li
On 11/08/13 06:46, Mike Hearn wrote:
> I took a brief look at the code - it's looking very reasonable. You can
> replace any construct like
>
> try {
> Thread.sleep(1000);
> } catch (InterruptedException e) {
> throw new RuntimeException(e);
> }
>
> which is quite verbose, just with
> Unint
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
> To peer with the public relay nodes, simply select the closest region
> out of us-west (West Coast US), us-east (East Coast US), eu (Western
> Europe), au (Australia), or jpy (Japan) and add
> public.REGION.relay.mattcorallo.com to your addnode lis
I took a brief look at the code - it's looking very reasonable. You can
replace any construct like
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
throw new RuntimeException(e);
}
which is quite verbose, just with
Uninterruptibles.sleepUninterruptably(1000, TimeUnit.MILLISECONDS)
No, the transactions relayed are piped through a bitcoind first (ie
fully verified by a bitcoind). For blocks, for which the timing needs to
be tighter, bitcoinj does SPV-validation. Though it is possible to
create a block which passes SPV validation but causes a DoS score, doing
so would cost a mi
On Wed, Nov 6, 2013 at 5:50 AM, Matt Corallo wrote:
> Relay node 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
Good stuff. I have been pushing for private peering agreeents and a
"backbone" for years. Even had a paltry effort going with exmulti.net + a
few manually connected parties.
I hope parties in the bitcoin space take it upon themselves to network with
major sites - miners, payment processors, excha
Very cool, thanks Matt.
I was actually thinking this morning, maybe we should require all nodes to
go through the inv/getdata dance. Otherwise it's possible to improve your
chances at racing a block by mining a block, waiting to see a block inv
from another node, then blasting out your block while
Recently, there has been a reasonable amount of discussion about the
continued fragility of the public Bitcoin network on IRC and elsewhere
(1). To this extent, I'm organizing a system of peering between nodes in
the network by creating a system of high-speed relay nodes for miners
and merchants/ex
10 matches
Mail list logo
