[Bitcoin-development] please check my debug.log
I've put up some bitcoind nodes after the network is in need of some, and would like some feedback in that the nodes are fully operational and doing something useful. Please check the logs and tell me whether I'm doing good. debug.log from a node that has been running for a day: 2014-04-29 08:06:18 ERROR: CheckTransaction() : vin empty 2014-04-29 08:06:18 ERROR: AcceptToMemoryPool: : CheckTransaction failed 2014-04-29 08:06:18 Misbehaving: 122.224.182.248:23159 (0 - 10) 2014-04-29 08:07:00 receive version message: /getaddr.bitnodes.io:0.1/: version 70001, blocks=298263, us=88.198.51.132:8333, them=0.0.0.0:0, peer=148.251.238.178:63657 2014-04-29 08:07:19 receive version message: /bitcoinseeder:0.01/: version 6, blocks=23, us=[2a01:4f8:131:13ed::2]:8333, them=0.0.0.0:0, peer=[2a02:348:5e:5a29::1]:53921 2014-04-29 08:09:37 receive version message: /Snoopy:0.1/: version 60001, blocks=0, us=88.198.51.132:8333, them=192.33.90.253:8333, peer=192.33.90.253:43104 2014-04-29 08:09:37 socket recv error 104 2014-04-29 08:10:26 receive version message: /getaddr.bitnodes.io:0.1/: version 70001, blocks=298263, us=[2a01:4f8:131:13ed::2]:8333, them=0.0.0.0:0, peer=[2a01:4f8:202:81b1::2]:50624 2014-04-29 08:10:32 receive version message: /bitcoinseeder:0.01/: version 6, blocks=23, us=88.198.51.132:8333, them=0.0.0.0:0, peer=217.78.0.153:37275 2014-04-29 08:10:50 receive version message: /getaddr.bitnodes.io:0.1/: version 70001, blocks=298263, us=88.198.51.132:8333, them=0.0.0.0:0, peer=148.251.238.178:50788 debug.log from a node that I just restarted: 2014-04-29 08:06:16 Opening LevelDB in /home/bitcoind/.bitcoin/blocks/index 2014-04-29 08:06:17 Opened LevelDB successfully 2014-04-29 08:06:17 Opening LevelDB in /home/bitcoind/.bitcoin/chainstate 2014-04-29 08:06:19 Opened LevelDB successfully 2014-04-29 08:06:22 LoadBlockIndexDB(): last block file = 135 2014-04-29 08:06:22 LoadBlockIndexDB(): last block file info: CBlockFileInfo(blocks=631, size=128154379, heights=297633...298263, time=2014-04-25...2014-04-29) 2014-04-29 08:06:22 LoadBlockIndexDB(): transaction index disabled 2014-04-29 08:06:22 LoadBlockIndexDB(): hashBestChain=162f5f571eef4742b70204d983bda3c4b18fc1496ac27f86 height=298263 date=2014-04-29 08:00:23 progress=0.81 2014-04-29 08:06:22 init message: Verifying blocks... 2014-04-29 08:06:22 Verifying last 288 blocks at level 3 2014-04-29 08:07:42 No coin database inconsistencies in last 289 blocks (89 transactions) 2014-04-29 08:07:42 block index 86284ms 2014-04-29 08:07:42 init message: Loading wallet... 2014-04-29 08:07:42 nFileVersion = 90100 2014-04-29 08:07:42 Keys: 101 plaintext, 0 encrypted, 101 w/ metadata, 101 total 2014-04-29 08:07:43 wallet 108ms 2014-04-29 08:07:43 init message: Rescanning... 2014-04-29 08:07:43 Rescanning last 39 blocks (from block 298224)... 2014-04-29 08:07:43 rescan 204ms 2014-04-29 08:07:43 init message: Loading addresses... 2014-04-29 08:07:43 Loaded 14015 addresses from peers.dat 84ms 2014-04-29 08:07:43 mapBlockIndex.size() = 298264 2014-04-29 08:07:43 nBestHeight = 298263 2014-04-29 08:07:43 setKeyPool.size() = 100 2014-04-29 08:07:43 mapWallet.size() = 0 2014-04-29 08:07:43 mapAddressBook.size() = 1 2014-04-29 08:07:43 AddLocal(213.239.218.20:8333,1) 2014-04-29 08:07:43 IPv4 eth0: 213.239.218.20 2014-04-29 08:07:43 AddLocal([2a01:4f8:a0:74c8::2]:8333,1) 2014-04-29 08:07:43 IPv6 eth0: 2a01:4f8:a0:74c8::2 2014-04-29 08:07:43 ext-ip thread start 2014-04-29 08:07:43 dnsseed thread start 2014-04-29 08:07:43 Loading addresses from DNS seeds (could take a while) 2014-04-29 08:07:43 net thread start 2014-04-29 08:07:43 upnp thread start 2014-04-29 08:07:43 opencon thread start 2014-04-29 08:07:43 addcon thread start 2014-04-29 08:07:43 dumpaddr thread start 2014-04-29 08:07:43 msghand thread start 2014-04-29 08:07:43 init message: Done loading 2014-04-29 08:07:43 GetMyExternalIP() received [213.239.218.20] 213.239.218.20:0 2014-04-29 08:07:43 GetMyExternalIP() returned 213.239.218.20 2014-04-29 08:07:43 AddLocal(213.239.218.20:8333,4) 2014-04-29 08:07:43 ext-ip thread exit 2014-04-29 08:07:44 receive version message: /Satoshi:0.8.6/: version 70001, blocks=298263, us=213.239.218.20:44169, them=166.78.243.104:8333, peer=166.78.243.104:8333 2014-04-29 08:07:44 Added time data, samples 2, offset +8 (+0 minutes) 2014-04-29 08:07:51 No valid UPnP IGDs found 2014-04-29 08:07:51 upnp thread exit 2014-04-29 08:07:53 connect() to 71.23.29.162:8333 failed after select(): No route to host 2014-04-29 08:07:53 receive version message: /Satoshi:0.9.1/: version 70002, blocks=298263, us=213.239.218.20:46921, them=91.238.134.58:8333, peer=91.238.134.58:8333 2014-04-29 08:07:53 Added time data, samples 3, offset +0 (+0 minutes) 2014-04-29 08:07:54 106 addresses found from DNS seeds 2014-04-29 08:07:54 dnsseed thread exit 2014-04-29 08:08:16 receive version message: /Satoshi:0.8.6/:
Re: [Bitcoin-development] please check my debug.log
Looks good to me! You're not in the DNS seeds yet. If you leave your nodes up for a while then you'll start getting traffic from bitcoinj clients too. On Tue, Apr 29, 2014 at 10:13 AM, Eugen Leitl eu...@leitl.org wrote: I've put up some bitcoind nodes after the network is in need of some, and would like some feedback in that the nodes are fully operational and doing something useful. Please check the logs and tell me whether I'm doing good. debug.log from a node that has been running for a day: 2014-04-29 08:06:18 ERROR: CheckTransaction() : vin empty 2014-04-29 08:06:18 ERROR: AcceptToMemoryPool: : CheckTransaction failed 2014-04-29 08:06:18 Misbehaving: 122.224.182.248:23159 (0 - 10) 2014-04-29 08:07:00 receive version message: /getaddr.bitnodes.io:0.1/: version 70001, blocks=298263, us=88.198.51.132:8333, them=0.0.0.0:0, peer= 148.251.238.178:63657 2014-04-29 08:07:19 receive version message: /bitcoinseeder:0.01/: version 6, blocks=23, us=[2a01:4f8:131:13ed::2]:8333, them=0.0.0.0:0, peer=[2a02:348:5e:5a29::1]:53921 2014-04-29 08:09:37 receive version message: /Snoopy:0.1/: version 60001, blocks=0, us=88.198.51.132:8333, them=192.33.90.253:8333, peer= 192.33.90.253:43104 2014-04-29 08:09:37 socket recv error 104 2014-04-29 08:10:26 receive version message: /getaddr.bitnodes.io:0.1/: version 70001, blocks=298263, us=[2a01:4f8:131:13ed::2]:8333, them= 0.0.0.0:0, peer=[2a01:4f8:202:81b1::2]:50624 2014-04-29 08:10:32 receive version message: /bitcoinseeder:0.01/: version 6, blocks=23, us=88.198.51.132:8333, them=0.0.0.0:0, peer= 217.78.0.153:37275 2014-04-29 08:10:50 receive version message: /getaddr.bitnodes.io:0.1/: version 70001, blocks=298263, us=88.198.51.132:8333, them=0.0.0.0:0, peer= 148.251.238.178:50788 debug.log from a node that I just restarted: 2014-04-29 08:06:16 Opening LevelDB in /home/bitcoind/.bitcoin/blocks/index 2014-04-29 08:06:17 Opened LevelDB successfully 2014-04-29 08:06:17 Opening LevelDB in /home/bitcoind/.bitcoin/chainstate 2014-04-29 08:06:19 Opened LevelDB successfully 2014-04-29 08:06:22 LoadBlockIndexDB(): last block file = 135 2014-04-29 08:06:22 LoadBlockIndexDB(): last block file info: CBlockFileInfo(blocks=631, size=128154379, heights=297633...298263, time=2014-04-25...2014-04-29) 2014-04-29 08:06:22 LoadBlockIndexDB(): transaction index disabled 2014-04-29 08:06:22 LoadBlockIndexDB(): hashBestChain=162f5f571eef4742b70204d983bda3c4b18fc1496ac27f86 height=298263 date=2014-04-29 08:00:23 progress=0.81 2014-04-29 08:06:22 init message: Verifying blocks... 2014-04-29 08:06:22 Verifying last 288 blocks at level 3 2014-04-29 08:07:42 No coin database inconsistencies in last 289 blocks (89 transactions) 2014-04-29 08:07:42 block index 86284ms 2014-04-29 08:07:42 init message: Loading wallet... 2014-04-29 08:07:42 nFileVersion = 90100 2014-04-29 08:07:42 Keys: 101 plaintext, 0 encrypted, 101 w/ metadata, 101 total 2014-04-29 08:07:43 wallet 108ms 2014-04-29 08:07:43 init message: Rescanning... 2014-04-29 08:07:43 Rescanning last 39 blocks (from block 298224)... 2014-04-29 08:07:43 rescan 204ms 2014-04-29 08:07:43 init message: Loading addresses... 2014-04-29 08:07:43 Loaded 14015 addresses from peers.dat 84ms 2014-04-29 08:07:43 mapBlockIndex.size() = 298264 2014-04-29 08:07:43 nBestHeight = 298263 2014-04-29 08:07:43 setKeyPool.size() = 100 2014-04-29 08:07:43 mapWallet.size() = 0 2014-04-29 08:07:43 mapAddressBook.size() = 1 2014-04-29 08:07:43 AddLocal(213.239.218.20:8333,1) 2014-04-29 08:07:43 IPv4 eth0: 213.239.218.20 2014-04-29 08:07:43 AddLocal([2a01:4f8:a0:74c8::2]:8333,1) 2014-04-29 08:07:43 IPv6 eth0: 2a01:4f8:a0:74c8::2 2014-04-29 08:07:43 ext-ip thread start 2014-04-29 08:07:43 dnsseed thread start 2014-04-29 08:07:43 Loading addresses from DNS seeds (could take a while) 2014-04-29 08:07:43 net thread start 2014-04-29 08:07:43 upnp thread start 2014-04-29 08:07:43 opencon thread start 2014-04-29 08:07:43 addcon thread start 2014-04-29 08:07:43 dumpaddr thread start 2014-04-29 08:07:43 msghand thread start 2014-04-29 08:07:43 init message: Done loading 2014-04-29 08:07:43 GetMyExternalIP() received [213.239.218.20] 213.239.218.20:0 2014-04-29 08:07:43 GetMyExternalIP() returned 213.239.218.20 2014-04-29 08:07:43 AddLocal(213.239.218.20:8333,4) 2014-04-29 08:07:43 ext-ip thread exit 2014-04-29 08:07:44 receive version message: /Satoshi:0.8.6/: version 70001, blocks=298263, us=213.239.218.20:44169, them=166.78.243.104:8333, peer=166.78.243.104:8333 2014-04-29 08:07:44 Added time data, samples 2, offset +8 (+0 minutes) 2014-04-29 08:07:51 No valid UPnP IGDs found 2014-04-29 08:07:51 upnp thread exit 2014-04-29 08:07:53 connect() to 71.23.29.162:8333 failed after select(): No route to host 2014-04-29 08:07:53 receive version message: /Satoshi:0.9.1/: version 70002, blocks=298263,
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
I do think we need to move beyond this idea of Bitcoin being some kind of elegant embodiment of natural mathematical law. It just ain't so. Every time miners and nodes ignore a block that creates formula() coins that's a majority vote on a controversial political matter, as evidenced by the disagreement with mainstream economics and that it's one of the most common things for alt coins to change. Indeed Satoshi's chosen inflation formula is a highly political statement on the value of inflation - he could have programmed Bitcoin to inflate forever and avoided a whole area of politics, but he chose not to. So please, let's agree to accept that Bitcoin is ultimately just a piece of software that encodes rules helping us run our little community in some specific ways. It's not physics and we should believe our own hype by pretending it is. On Mon, Apr 28, 2014 at 11:41 PM, Adam Back a...@cypherspace.org wrote: I think the reason that it would likely work out badly is that its not provable, and so no consensus rule can be constructed requiring proof, so then it risks devolving to a political decision. It's the other way around. If miners decide to fork the chain then that leaves no proof (beyond the old blocks, which could have been a natural fork - there's no way to know - and nodes don't want to keep them around anyway). If they explicitly vote to get the same effect but without actually forking, it leaves a proof in the form of the votes in the coinbase that can be seen afterwards. Step 3: Finney attackers vote down other pools to make the point. It only works if the majority of hashpower is controlled by attackers, in which case Bitcoin is already doomed. So it doesn't matter at that point. -- 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] Coinbase reallocation to discourage Finney attacks
On Tue, Apr 29, 2014 at 7:13 AM, Mike Hearn m...@plan99.net wrote: It only works if the majority of hashpower is controlled by attackers, in which case Bitcoin is already doomed. So it doesn't matter at that point. These parties wouldn't generally consider themselves attackers— nor would many users (presumably everyone who mines on ghash.io, for example)— rather they'd they may consider someone using hashpower voting to reassign coins to be an attacker, and reassigning their coins instead to be a morally justified and pragmatic response. I think we're capable here of discussing the specifics without needing to use generalizations which invite definitional arguments... I don't think that bombastic language like doomed helps the dialog. -- 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] Coinbase reallocation to discourage Finney attacks
These parties wouldn't generally consider themselves attackers Of course not, attackers rarely do :) But they are miners who are taking part in malicious double spending. That makes them attackers. If miners don't exist to stop double spending, what do they exist for? I mean, this is fundamental. What do you think miners exist for? -- 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] Proposal to change payment protocol signing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 We have BIP70 already in use (over a hundred paid requests). Could you elaborate on why this needs changing? On 28-04-14 14:39, Gavin Andresen wrote: There is a discussion about clarifying how BIP70 signs payment requests here: https://github.com/bitcoin/bips/pull/41 The issue is what to do with the signature field before signing. The code Mike and I initially wrote does this: request.set_signature(string()); (sets signature to the empty string) I think that is a mistake; it should be: request.clear_signature(); (clears signature field, so it is not serialized at all). So: if you are implementing, or have implemented, the payment protocol, please chime in. I'd like to change the spec and the reference implementation NOW, while BIP70 is still a 'Draft'. Because this type of hey, I'm implementing your standard and it doesn't work the way I think it should mistake is exactly why BIPs take a while before being declared 'Final.' -- 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTX9bcAAoJELhWickZBkAlKqcH/RVFAr6vGgDjJvYah46StMHy ZhKwpV1oqFCslOts6MyO+bZp9uDRlmYtnAy02CTPmlico3IyK85/+CGCGEdyiGo1 AEI2Ixr5FJs9t8uAVLyUKwOQddUFEJuZuiKXd1Wl9GqfG/z8gwdSxd08Wrq57lSH JdwUnWOG1xBwyhgm7stqFoXgTrrnFNcE97vwsk6QMIzJG/v0suw7Lp42q7bKYaA/ J9xWSQ1cRKSPdsmu4K45oxXriqUmiqz3EouaTSQqC80OO7y8sfa96DqiHR83Vy3w KUna5enjGqhhberWCokg3x5lCiH/IfLPrgK23iib4cg6Vm70jSQ2S2Xh/NuoDaM= =JA5K -END PGP SIGNATURE- -- 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] Proposal to change payment protocol signing
Consensus is the spec should be clarified to match current behavior, so it won't change. -- Gavin Andresen On Apr 29, 2014, at 9:44 AM, Jouke Hofman jo...@bitonic.nl wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 We have BIP70 already in use (over a hundred paid requests). Could you elaborate on why this needs changing? On 28-04-14 14:39, Gavin Andresen wrote: There is a discussion about clarifying how BIP70 signs payment requests here: https://github.com/bitcoin/bips/pull/41 The issue is what to do with the signature field before signing. The code Mike and I initially wrote does this: request.set_signature(string()); (sets signature to the empty string) I think that is a mistake; it should be: request.clear_signature(); (clears signature field, so it is not serialized at all). So: if you are implementing, or have implemented, the payment protocol, please chime in. I'd like to change the spec and the reference implementation NOW, while BIP70 is still a 'Draft'. Because this type of hey, I'm implementing your standard and it doesn't work the way I think it should mistake is exactly why BIPs take a while before being declared 'Final.' --- -- 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] GBT 2.0 wishlist
Let's try to get GBT 2.0 off the ground finally.. :) Here's some wishlist items/ideas: - Extremely low bandwidth use (binary protocol, with compression support) - UDP-based transport protocol? (so message order need not be preserved at the expense of latency) - Ability to instruct miners to insert (username,hash-of-username,hash-of- options-array,hash-of-both,etc) in coinbase at a given position (this enables cheaper proof-of-work auditing of a pool's rewards; it can just save/publish shares meeting higher targets and anyone can verify the shares were found by a given username/hash) - Always encrypted (once by the server), with optional authentication via CA/namecoin/URI - Incrementing precommit id so miners can precommit to settings without needing a new/custom coinbase - Multiple clients should share bandwidth on a LAN (similar to slush's stratum proxy) - Convey prevblock as block header so we can follow blockchains securely. - Fee logic: pools can claim as much coinbase distribution as they require (with hint from miner); miners are expected to ensure subsidy + transaction fees tally up to the required total; any fees beyond requires total may be distributed as the miner wishes. Potentially, pools could allow 50% (or similar) participation allowing a miner to use multiple pools at the same time. Rather than polluting the main development mailing list with what is sure to have quite a bit of discussion, I have asked kinlo (who hosts the poolowners mailing list) to provide a dedicated list for this purpose. Interested parties should please subscribe via http://list.pfoe.be/mailman/listinfo/gbt2 and send replies to g...@list.pfoe.be (once a draft BIP is ready, the main dev mailing list will be once again CC'd). Luke -- 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] Coinbase reallocation to discourage Finney attacks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/29/2014 02:13 PM, Mike Hearn wrote: I do think we need to move beyond this idea of Bitcoin being some kind of elegant embodiment of natural mathematical law. It just ain't so. I think everybody understands that Bitcoin has a positive net present value exactly because it, unlike every other digital currency which came before, does not include a feature that allows for balances to be confiscated. Implementing any such feature, to any degree at all, would render Bitcoin completely valueless. There are two possibilities here: If you understand this, then your proposal is a malicious attempt to undermine Bitcoin. If you don't understand this then you suffer from a very serious case of economic illiteracy, a case so bad that your continued participation in Bitcoin represents a clear and present danger to all Bitcoin users. If you can't even get the easy questions right, then god help us all if you're ever faced with a difficult one. I don't have enough evidence to distinguish between the incompetence hypothesis and the malice hypothesis, but it doesn't matter. Regardless of your abilities or motives your proposal is unacceptable. If you want a currency where miners can vote to steal from other miners then implement it in Hearncoin and leave Bitcoin alone. - -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTX/2dAAoJECoisBQbQ4v0jAoH/R1oNZ1tVp6DJ5BuPg0ZTav0 Dvzq8EfX/uRbRgmxotCHMwY6FJCoXqJTLyOnl2p670t7l5ZXqd91MdKKP2z7jYPY GsVbqfGreF0dWKCd0mKTG5DM8pxndNWteGIsw9/sYvY/3p2Vopzp6N7fpl8TEf6p 2nyIzEqTD4aK5QkhM+sNnP1Cyh/l5AjJTES23GqSQIMG6vzLgqE8kyze+ANFVg1U yka6bz4DX7DO7meyJyyOFaMJu6mgY+m6dSVaR7j/QmQMu22SwlSiPgqe6iO//os3 zcmwe/x4+5CmqJOO/PL5Or28iw/Qdf6vNePiaEIFtBzoKnHBhS2nAtL6jnOL928= =4yIu -END PGP SIGNATURE- 0x1B438BF4.asc Description: application/pgp-keys -- 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
