Slurms MacKenzie [ARCHIVE]
User Avatar
Slurms MacKenzie [ARCHIVE]
⚠️ This account is not associated with a real person. It's an archival account for mailing list mess
... show more
Not followed by anyone you follow
πŸ“… Original date posted:2015-07-24 πŸ“ Original message:Incentivize investigations for public consumption. The people on this list are the ones who probably care the most. When I looked up that IP address, the Whois info names "OVH" and "Octave Klaba" (who founded OVH, according to Wikipedia) as thanti-hacker-alliance.com/index.php?details=37.187.136.15). Blockchain.info itself returns IP addresses managed by CloudFlare whenever I try it. On Fri, Jul 24, 2015 at 2:12 PM, Slurms MacKenzie via bitcoin-dev < bitcoin-dev at lists.linuxfoundation.org> wrote: > They do not run anything but BitcoinJ (evidenced by them blindly following > invalid chains)lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: <lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150724/5b4b2169/attachment.html>
... show more

Something went wrong.

Error: Failed to construct 'URL': Invalid URL

TypeError: Failed to construct 'URL': Invalid URL
    at component (https://iris.to/assets/index-C9gxoW1a.js:11:29466)
    at df (https://iris.to/assets/vendor-DvO8eVF2.js:44:36408)
    at Df (https://iris.to/assets/vendor-DvO8eVF2.js:44:67270)
    at cp (https://iris.to/assets/vendor-DvO8eVF2.js:44:78842)
    at Up (https://iris.to/assets/vendor-DvO8eVF2.js:44:116069)
    at lg (https://iris.to/assets/vendor-DvO8eVF2.js:44:115074)
    at nh (https://iris.to/assets/vendor-DvO8eVF2.js:44:114894)
    at Bp (https://iris.to/assets/vendor-DvO8eVF2.js:44:111725)
    at Wp (https://iris.to/assets/vendor-DvO8eVF2.js:44:124227)
    at MessagePort.zt (https://iris.to/assets/vendor-DvO8eVF2.js:21:1886)
πŸ“… Original date posted:2015-07-24 πŸ“ Original message:Thanks for bringing up the CCSS, Adam and Peter. I was actually working on a post inviting everyone in this mailing list to come and participate…but you guys beat me to it. :) The CCSS is an open standard, born out of the belief that sharing tblog.cryptoconsortium.org/contributing-to-the-ccss <blog.cryptoconsortium.org/contributing-to-the-ccss/> The standard: cryptoconsortium.github.io/CCSS <cryptoconsortium.github.io/CCSS/> The github repository: github.com/CryptoConsortium/CCSS <github.com/CryptoConsortium/CCSS> - Eric > On Jul 24, 2015, at 10:43 AM, Peter Todd via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote: > > On Fri, Jul 24, 2015 at 03:39:08PM +0200, Thomas Zander via bitcoin-dev wrote: >> On Friday 24. July 2015 05.37.30 Slurms MacKenzielists.linuxfoundation.org/mailman/listinfo/bitcoin-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: <lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150724/b837dbd2/attachment.html> -------------- nelists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150724/b837dbd2/attachment.sig>
... show more
πŸ“… Original date posted:2015-07-24 πŸ“ Original message:They do not run anything but BitcoinJ (evidenced by them blindly following invalid chains), so no proper consensus checking going on here at all. Connected to my nodes is a bad peer (doesn’t relay inventory but downloads everything) from 37.187.
... show more
πŸ“… Original date posted:2015-07-23 πŸ“ Original message:I used Google to establish that there is not already a post from 2015 that mentions "roadmap" in the subject line. Such would be a good skeleton for anyone new to the list (like me). 1. Increase the 7 Tx per second - by increasing block size. lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150723/ea7fd11a/attachment.html>
... show more
πŸ“… Original date posted:2015-07-24 πŸ“ Original message:It's worth noting that even massive companies with $30M USD of funding don't run a single Bitcoin Core node, which is somewhat against the general concept people present of companies having an incentive to run their own to protect their own wall
... show more
πŸ“… Original date posted:2015-07-23 πŸ“ Original message:-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Does "to process into the index" include time for transport and/or block validation (presumably by bitcoind) or this this exclusively the time for Electrum Server to index a validated block? e On
... show more
πŸ“… Original date posted:2015-07-23 πŸ“ Original message:That's purely the time on the wall for electrum-server, validation in bitcoind happens before. As ThomasV has pointed out it is significantly faster with a solid state disk (but much more expensive to operate), if we get to that point it'll only
... show more
πŸ”– Title: Electrum Server Speed Test 🏷️ Categories: bitcoin-dev πŸ‘₯ Authors: β€’ Eric Voskuil ( Eric Voskuil [ARCHIVE] ) β€’ Thomas Voegtlin ( Thomas Voegtlin [ARCHIVE] ) β€’ Slurms MacKenzie ( Slurms MacKenzie [ARCHIVE] ) β€’ Matt Whitlock ( Matt Whitlock [ARCHIVE] ) β€’ Joseph Gleason β‘ˆ ( Joseph Gleason β‘ˆ [ARCHIVE] ) πŸ“… Messages Date: 2015-07-23 βœ‰οΈ Message Count: 7 πŸ“š Total Characters in Messages: 13815
πŸ“… Original date posted:2015-07-23 πŸ“ Original message:Similar to the Bitcoin Node Speed Test, this is a quick quantitative look at how the Electrum server software handles under load. The Electrum wallet is extremely popular, and the distributed servers which power it are all hosted by volunteers w
... show more
πŸ“… Original date posted:2015-07-23 πŸ“ Original message:Thank you a lot for doing this test! Two questions: 1) A node is typically connected to many nodes that would all in parallel download said block. In your test you measured how fast new blocks that presumably are being uploaded in parallel to pastebin.com/raw.php?i=6b4NuiVQ > > > This does not support the theory that the network has the available bandwidth for increased block sizes, as in its current state 37% of nodes would fail to upload a 20MB block to a single peer in under 20 seconds (referencing a number quoted by Gavin). If the bar for suitability is placed at lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: <lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150723/042b0879/attachment-0001.sig>
... show more
πŸ“… Original date posted:2015-07-23 πŸ“ Original message:An HTML attachment was scrubbed... URL: <lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150723/82f24718/attachment.html>
πŸ“… Original date posted:2015-07-23 πŸ“ Original message:You may see much better throughput if you run a few servers around the globe and test based on closest-by-geoip. TCP throughput is rather significantly effected by latency, though I'm not really sure what you should be testing here, ideally. Onpastebin.com/raw.php?i=6b4NuiVQ > > > This does not support the theory that the network has the available bandwidth for increased block sizes, as in its current state 37% of nodes would fail to upload a 20MB block to a single peer in under 20 seconds (referencing a number quoted by Gavin). If the bar for suitability is placed alists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >
... show more
πŸ“… Original date posted:2015-07-24 πŸ“ Original message:Yes that is completely doable for the next crawl, however I am not sure how much that reflects the behavior bitcoind would see when making connections. Nodes do not make any attempt to sync with close peers, which is an undesirable property if y
... show more
πŸ“… Original date posted:2015-07-23 πŸ“ Original message:Are you willing to share the code that you used to run the test? - Jameson On Thu, Jul 23, 2015 at 10:19 AM, slurms--- via bitcoin-dev < bitcoin-dev at lists.linuxfoundation.org> wrote: > On this day, the Bitcoin network was crawled and reachpastebin.com/raw.php?i=6b4NuiVQ > > > This does not support the theory that the network has the available > bandwidth for increased block sizes, as in its current state 37% of nodes > would fail to upload a 20MB block to a single peer in under 20 seconds > (referencing a number quoted by Gavin). If the bar for suitability is > pllists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: <lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150723/312f6262/attachment.html>
... show more
πŸ“… Original date posted:2015-07-23 πŸ“ Original message:An HTML attachment was scrubbed... URL: <lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150723/004e3b9e/attachment.html>
πŸ“… Original date posted:2015-07-24 πŸ“ Original message:Validated - (seen on network) Settled/Cleared - 1 conf Finalised - 6 confs On Sat, 2015-07-25 at 00:37 +1000, Vincent Truong via bitcoin-dev wrote: > > "Fast transactions" > Fast transactions implies it is slower than Visa, and Visa is > 'ilists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
... show more
πŸ“… Original date posted:2015-07-25 πŸ“ Original message:How do you explain to end users that a "validated" transaction can instantly become completely unspendable by a mined block? This seems like setting up people to just be Finney attacked even more. > Sent: Saturday, July 25, 2015 at 4:18 AM > F
... show more
πŸ“… Original date posted:2015-07-23 πŸ“ Original message:There really isn't any need for a 3rd party here. Those "services" can just be the miners themselves. jp > On Jul 24, 2015, at 8:56 AM, Eric Lombrozo <elombrozo at gmail.com> wrote: > > >> On Jul 23, 2015, at 5:45 PM, Jean-Paul Kogelman <je
... show more
πŸ“… Original date posted:2015-07-23 πŸ“ Original message:> Sent: Thursday, July 23, 2015 at 7:28 PM > From: "Gavin Andresen via bitcoin-dev" <bitcoin-dev at lists.linuxfoundation.org> > To: "Tom Harding" <tomh at thinlink.com> > Cc: bitcoin-dev at lists.linuxfoundation.org > Subject: Re: [bitcoin-dev]
... show more