Re: [Bitcoin-development] [ANN] High-speed Bitcoin Relay Network

[Mike Hearn]

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); (and of
course static imports help too)

I think for this concept to take off, you'd need a website and to recruit
someone to help you market it. Pool operators won't reach out to you.

I still find it perhaps more elegant to just boost the connectivity of the
existing network with bitcoind changes, but this can help for now.



On Thu, Nov 7, 2013 at 12:35 AM, Matt Corallo bitcoin-l...@bluematt.mewrote:

 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 miner a full block's worth of profits, which they are
 fairly unlikely to do. In any case, if it every becomes a problem, its
 not hard to adapt addnode to allow higher DoS scores for individual nodes.

 Matt

 On 11/06/13 07:25, Tier Nolan wrote:
 
 
 
  On Wed, Nov 6, 2013 at 5:50 AM, Matt Corallo bitcoin-l...@bluematt.me
  mailto:bitcoin-l...@bluematt.me 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 without fully checking it with your own bitcoin
 validator
  (as you would any other block relayed from the P2P network).
 
 
  Wouldn't this cause disconnects due to misbehavior?
 
  A standard node connecting to a relay node would receive
  blocks/transactions that are not valid in some way and then disconnect.
 
  Have you looked though the official client to find what things are
  considered signs that a peer is hostile?  I assume things like double
  spending checks count as misbehavior and can't be quickly checked by a
  relay node.
 
  Maybe another bit could be assigned in the services field as relay.
  This means that the node doesn't do any checking.
 
  Connects to relay nodes could be command line/config file only.  Peers
  wouldn't connect to them.


 --
 November Webinars for C, C++, Fortran Developers
 Accelerate application performance with scalable programming models.
 Explore
 techniques for threading, error checking, porting, and tuning. Get the most
 from the latest Intel processors and coprocessors. See abstracts and
 register
 http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most 
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] we can all relax now

[Gregory Maxwell]

On Fri, Nov 8, 2013 at 11:49 AM, Andreas M. Antonopoulos
andr...@rooteleven.com wrote:
 Nicholas Weaver is reporting that pools have already started delaying
 blocks, something that hints at Selfish Mining, since Nov. 3rd.
 https://medium.com/something-like-falling/d321a2ef9317

 He dismisses other reasons for delayed block propagation.

 Any ideas on whether pools are already mucking around with block delaying
 tactics?

 I have no idea if this report is accurate or explained by some other issue
 in the network, does anyone here have a comment on this?

The BC.i timestamps have historically been inaccurate relative to my
local GPS clock measurements on my own nodes... but not just that, it
sounds like he's comparing block timestamps and bc.i numbers.

Thats insane, because it tells you the delay between when the miner
_started_ a work unit and when BC.i claims to have found it. Even
assuming bc.i's times were accurate and assuming miner clocks are
accurate (they are often not) you expect there to be be a gap because
it takes time to compute work, send it to the miner, search for a
valid nonce (an average of 2^31 hash operations, often executed
sequentially on a single core taking ten seconds or so on a lot of
hardware) and then return a result.

Evidence of selfish miners wouldn't be block timestamps (which are
inaccurate and controlled by miners anyways), or data on
blockchain.info (which is inaccurate and controlled by bc.i) ... but
the existence of an unusual amount of orphan blocks. High levels of
blocks are _necessary_ evidence of this sort of things, there can be
other explanations of high orphaning levels, but they're required here
and couldn't be faked.

--
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most 
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development