Re: [Bitcoin-development] we can all relax now
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 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=60136231&iu=/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: • 3 signs your SCM is hindering your productivity • Requirements for releasing software faster • 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
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 wrote: > On Thu, Aug 1, 2013 at 9:30 AM, E willbefull > 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=49501711&iu=/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
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 wrote: > On Wed, Jul 31, 2013 at 6:45 PM, Roy Badami 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: > 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=49501711&iu=/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=49501711&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
