Re: [Bitcoin-development] Developer documentation on bitcoin.org
On Sun, May 11, 2014 at 4:08 AM, Saïvann Carignan wrote: > A new "Developer Documentation" section should be soon merged on > bitcoin.org . > > Live Preview: > http://bitcoindev.us.to/en/developer-documentation > > GitHub Pull Request: > https://github.com/bitcoin/bitcoin.org/pull/393 > > Bitcointalk Thread: > https://bitcointalk.org/index.php?topic=511876.0 Great work! Very nice to see thorough developer documentation on bitcoin.org. I've already been reading it now and then and haven't found any technical issues yet, if I do, I'll let you know. Wladimir -- "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] A statistical consensus rule for reducing 0-conf double-spend risk
Christophe Biocca wrote: > The problem is that since the rule > isn't enforceable, no miner will wait before mining on the longest > chain (which is the rational move), and you're back to where we are > now. Back up to the miner who decided to include a "seasoned" double-spend in his block. Let's say he saw it 21 seconds after he saw an earlier spend, and included it, despite the rule. The expected cost of including the respend is any revenue loss from doing so: (total miner revenue of block)*(fraction of hashpower following the rule). So today, if only 1% of hashpower follows the rule (ie a near total failure of consensus implementation), he still loses at least .25 BTC. .25 BTC is about 1000x the typical "double-spend premium" I'm seeing right now. Wouldn't the greedy-rational miner just decide to include the earlier spend instead? -- "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Allow cross-site requests of payment requests
Would it be a terrible idea to amend BIP 70 to suggest implementors include a "Access-Control-Allow-Origin: *" response header for their payment request responses? I don't think this opens up any useful attack vectors. I ask because this would make it practical for pure HTML5 web wallets to use the payment protocol entirely in-browser. Without this I think it would be necessary for the server hosting the wallet's HTML to fetch payment requests on the browser's behalf. This is somewhat inelegant and has security/resource implications for the back-end. -Andy -- "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] statoshi.info is now live
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Since it seems unlikely that we'll be able to ship an integrated stats / monitoring feature in the short term, I went ahead and set up a public Statoshi instance and threw a nicer interface on top of it. http://statoshi.info You can also view the raw Graphite stats at http://statoshi.info:8080/ If there are any metrics that you think would be helpful for development or monitoring purposes, just let me know and I'll take a shot at adding them. Jameson -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJTb6/qAAoJEIch3FSFNiDceR4H/jHchii5offrnQRsRcA7o4bh EEeL7ln9ID2FtqpL5wEjFtYq7nXL/8+o1BY7MOULo4SMpQIi0aY3ehNkPUCX3XKh U0F1ZZpkjMpI8BbIqBFwspNAE7bFh8vmRW9/IhWXf3VY8TmgVhZnbMmzxvcw7DwI kb1pgXZOEKCwmMvxBoWdmwDogvZvNPIThoQ9InY+qaGQut3lvrrSQMR7jYXxTY/9 Rebnny5c15KUrM3xwRPJvFHlbFE8F5a6ue9uwGq/STK73/iDqXksJNFnpzk3fnGc AryWmleHFfttfsb1kb991BFn2RCaKWvGBNUnq5dD/cCZIBwu3F16j65JAxboF94= =Xe+e -END PGP SIGNATURE- -- 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
