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

2014-05-10 Thread E willbefull
I've created a simulation framework called simbit to simulate the selfish
mining attack, though it is general enough to simulate any p2p network. I
even put together a rough simulation of MinCen. The goal is to be fun/easy
to rapidly prototype protocols and strategies, and visualize them. It's
written in javascript, so it can be demoed in the web browser or run on
Node.

It's still in early alpha and a lot of things are missing.

https://github.com/ebfull/simbit

https://bitcointalk.org/index.php?topic=603171.0

Feedback is appreciated!


On Tue, Nov 5, 2013 at 10:33 PM, kjj bitcoin-de...@jerviss.org wrote:

 One of the things that really gets me going is when someone devises a
 model, tests it against itself, and then pretends that they've learned
 something about the real world.

 Naturally, the Selfish Mining paper is exactly this sort of nonsense.
 Their model is one with no latency, and one where the attacker has total
 visibility across the network.  An iterated FSM is not a suitable
 simulation of the bitcoin system.  The bitcoin network does not have
 states, and to the extent that you can pretend that we do, you can't
 simulate transitions between them with static probabilities.

 The authors understand this deep down inside, even though they didn't
 work out the implications.  They handwave the issue by assuming a total
 sybil attack, and in true academic spirit, they don't realize that the
 condition necessary for the attack is far, far worse than the attack
 itself.

 Greg said he'd like to run some simulations, and I'm thinking about it
 too.  Unfortunately, he is busy all week, and I'm lazy (and also busy
 for most of tomorrow).

 If neither of us get to it first, I'm willing to pitch in 1 BTC as a
 bounty for building a general bitcoin network simulator framework. The
 simulator should be able to account for latency between nodes, and
 ideally within a node.  It needs to be able to simulate an attacker that
 owns varying fractions of the network, and make decisions based only on
 what the attacker actually knows.  It needs to be able to simulate this
 attack and should be generic enough to be easily modified for other
 crazy schemes.

 (Bounty offer is serious, but expires in one year [based on the earliest
 timestamp that my mail server puts on this email], and /may/ be subject
 to change if the price on any reputable exchange breaks 1000 USD per BTC
 in that period.)

 Basically, the lack of a decent network simulator is what allowed this
 paper to get press.  If the author had been able to see the importance
 of the stuff he was ignoring, we wouldn't be wasting so much time
 correcting him (and sadly the reporters that have no way to check his
 claims).

 https://bitcointalk.org/index.php?topic=324413.msg3495663#msg3495663




 --
 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

--
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
#149; 3 signs your SCM is hindering your productivity
#149; Requirements for releasing software faster
#149; Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72

2013-07-31 Thread E willbefull
I think it's important to expect PaymentRequest-only bitcoin URIs in the
future. Some types of payments (exotic transactions) may not make sense to
have a single fallback address. Or, a page with a bitcoin URI link may be
relying on a separate service provider to assemble the transaction.


On Wed, Jul 31, 2013 at 5:33 AM, Gavin Andresen gavinandre...@gmail.comwrote:

 On Wed, Jul 31, 2013 at 6:45 PM, Roy Badami r...@gnomon.org.uk wrote:
 
  Is it envisaged to be possible/sensible to have a URI that is *only* a
  payment request?  i.e. something like the following (although I'm not
  sure this is a valid URI):
 
  bitcoin:?request=https%3A%2F%2Fmerchant.com%2Fpay.php%3Fh%3D2a8628fc2fbe

 I think we'll want a bitcoin address in there for a long time for
 backwards compatibility.

 If web browser support for arbitrary MIME types is strong enough (I
 haven't tested), then a payment request can be initiated with just an
 anchor tag:
   a href=https://merchant.com/pay.php?3D2a8628fc2fbe;
 type=application/bitcoin-paymentrequest

 Doing it that way saves a http round-trip.

 --
 --
 Gavin Andresen


 --
 Get your SQL database under version control now!
 Version control is standard for application code, but databases havent
 caught up. So what steps can you take to put your SQL databases under
 version control? Why should you start doing it? Read more to find out.
 http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
Get your SQL database under version control now!
Version control is standard for application code, but databases havent 
caught up. So what steps can you take to put your SQL databases under 
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72

2013-07-31 Thread E willbefull
P2SH addresses support exotic transaction outputs, but not all exotic
transactions. This payment protocol can allow for combining multiple
outputs. A PaymentRequest for sending money to multiple parties, for
example, could not fall back to a single address.


On Wed, Jul 31, 2013 at 5:38 PM, Gavin Andresen gavinandre...@gmail.comwrote:

 On Thu, Aug 1, 2013 at 9:30 AM, E willbefull ewillbef...@gmail.com
 wrote:
  I think it's important to expect PaymentRequest-only bitcoin URIs in the
  future. Some types of payments (exotic transactions) may not make sense
 to
  have a single fallback address.

 P2SH addresses already support all exotic transactions.

  Or, a page with a bitcoin URI link may be
  relying on a separate service provider to assemble the transaction.

 Do you mean assemble the PaymentRequest message?  Because the payment
 transaction will always be created by the customer's wallet software.

 IF PaymentRequests take over the world and we get 100% wallet software
 support, then I'd be happy to write another BIP that says that a
 bitcoin: URI can be just bitcoin:?request=http...

 --
 --
 Gavin Andresen

--
Get your SQL database under version control now!
Version control is standard for application code, but databases havent 
caught up. So what steps can you take to put your SQL databases under 
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development