Slurms MacKenzie [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2015-07-23 to 2015-07-25
💬 Posted a total of 14 messages
📚 Participated in the following categories: bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 17:43:36

- reply

📅 Original date posted:2015-07-25
📝 Original message:The answer to that is a less illegal than probing other peoples web servers. Up until recently the reverse name lookup for that IP address was markets.blockchain.info, which I resolve when I log incoming connections in an attempt to filter out some abusive clients coming from university connections.
Other people have noticed these abusive clients too. There’s mentions of other connections running the same version of BitcoinJ coming from sources that appear to be blockchain.info which display similar behavior. A user in #bitcoin-dev was complaining about this client hammering closed ports with connections when they are kicked off.
http://bitcoinstats.com/irc/bitcoin-dev/logs/2015/02/09#l1423513396.0
> Sent: Saturday, July 25, 2015 at 4:23 AM
> From: "Dave Scotese via bitcoin-dev" <bitcoin-dev at lists.linuxfoundation.org>
> To: bitcoin-dev at lists.linuxfoundation.org
> Subject: Re: [bitcoin-dev] Bitcoin Roadmap 2015, or "If We Do Nothing" Analysis
> When I looked up that IP address, the Whois info names "OVH" and "Octave Klaba" (who founded OVH, according to Wikipedia) as the owner. "blockchain.info[http://blockchain.info]" appears in the HTML header as retrieved by the "Anti-Hacker Alliance" (http://anti-hacker-alliance.com/index.php?details=37.187.136.15[http://anti-hacker-alliance.com/index.php?details=37.187.136.15]). Blockchain.info itself returns IP addresses managed by CloudFlare whenever I try it.

2023-06-07 17:43:35

- reply

📅 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.136.15, with the user agent /BitcoinJ:0.12SNAPHOT/Satoshi:0.2.0/ which is owned by blockchain.info. You can also submit an invalid transaction through their /pushtx interface and get a mixture of noise and BitcoinJ error messages out of it as well.
If even the people who have to their claim hundreds of thousands of wallets are relying on their security don’t bother running even a single node to sanity check against, who are we really going to expect people to in the future if the load goes 8x, 16x, 32x higher? Like CoinBase and others, these are the companies which are claimed will be the ones supporting the network with ludicrous sized blocks because they have a financial incentive to.
Well, they don't even do it now when it could be achieved with a $5 VPS.
> Sent: Friday, July 24, 2015 at 8:43 PM
> From: "Peter Todd via bitcoin-dev" <bitcoin-dev at lists.linuxfoundation.org>
> To: "Thomas Zander" <thomas at thomaszander.se>
> Cc: bitcoin-dev at lists.linuxfoundation.org
> Subject: Re: [bitcoin-dev] Bitcoin Roadmap 2015, or "If We Do Nothing" Analysis
> We can test the fact that blockchain.info's wallet and block explorer
> has behaved in a way consistent with not running a full node - they have
> shown invalid data that any full node would reject on multiple
> occasions, most recently invalid confirmations during the BIP66 fork.

2023-06-07 17:43:32

- reply

📅 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 wallet.
> Sent: Friday, July 24, 2015 at 4:57 AM
> From: "Dave Scotese via bitcoin-dev" <bitcoin-dev at lists.linuxfoundation.org>
> To: bitcoin-dev at lists.linuxfoundation.org
> Subject: [bitcoin-dev] Bitcoin Roadmap 2015, or "If We Do Nothing" Analysis
>
> B) The protocol as it is will soon make common computing machines inadequate for running full nodes, and as a result they will not be able to contribute to the ecosystem in meaningful ways.

2023-06-07 17:43:29

- reply

📅 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 be expensive servers with lots of SSD space which are able to keep up with the current software.
I was mostly trying to make a point about other software being impacted in ways which aren't really discussed, rather than a specific dig about electrum-server. I should have made that more clear.
> Sent: Thursday, July 23, 2015 at 9:21 PM
> From: "Eric Voskuil" <eric at voskuil.org>
> To: "Slurms MacKenzie" <slurms at gmx.us>, bitcoin-dev at lists.linuxfoundation.org
> Subject: Re: [bitcoin-dev] Electrum Server Speed Test
>
> -----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
>

2023-06-07 17:43:27

- reply

📅 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 without budget. The server requires a fully indexed Bitcoin Core daemon running, and produces sizable external index in order to allow SPV clients to quickly retrieve their history.
3.9G electrum/utxo
67M electrum/undo
19G electrum/hist
1.4G electrum/addr
24G electrum/
Based on my own logs produced by the electrum-server console, it takes this server (Xeon, lots of memory, 7200 RPM RAID) approximately 3.7 minutes per megabyte of block to process into the index. This seems to hold true through the 10 or so blocks I have in my scroll buffer, the contents of blocks seem to be of approximately the same processing load. Continuing this trend with the current inter-block time of 9.8 minutes, an electrum-server instance running on modest-high end dedicated server is able to support up to 2.64 MB block sizes before permanently falling behind the chain.

2023-06-07 17:43:21

- reply

📅 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 you are attempting to be sybil resistant. With some quick playing around it seems that you do get the expected speedup with close proximity, but it's not a particularly huge difference at present. I'll keep working on it and see where I get.
> Sent: Friday, July 24, 2015 at 4:48 AM
> From: "Matt Corallo via bitcoin-dev" <bitcoin-dev at lists.linuxfoundation.org>
> To: bitcoin-dev at lists.linuxfoundation.org
> Subject: Re: [bitcoin-dev] Bitcoin Node Speed Test
>
> 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.

2023-06-07 17:43:21

- reply

📅 Original date posted:2015-07-23
📝 Original message:An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150723/82f24718/attachment.html>

2023-06-07 17:43:19

- reply

2023-06-07 17:43:13

- reply

📅 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
> From: "gb via bitcoin-dev" <bitcoin-dev at lists.linuxfoundation.org>
> To: "Vincent Truong" <vincent.truong at procabiak.com>
> Cc: bitcoin-dev at lists.linuxfoundation.org
> Subject: Re: [bitcoin-dev] Bitcoin, Perceptions, and Expectations
>
>
> Validated - (seen on network)
>
> Settled/Cleared - 1 conf
>
> Finalised - 6 confs
>

2023-06-07 17:43:00

- reply

📅 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] Bitcoin Core and hard forks
>
> I'm frankly tired of all the negativity here
You complained about the lack of quantitative analysis being used, I gave it to you. There's nothing "negative" about displaying data which doesn't completely back up what your position is, I made a sensible conclusion based on the facts I have in front of me. Ignoring the information I collected and presented for you is incredibly childish.
> I'd really like to move from "IMPOSSIBLE because... (electrum hasn't been optimized
> (by the way: you should run on SSDs, LevelDB isn't designed for spinning disks),
I should stress that I didn't present that timing information as a dig against their software, it just happens to be something I have direct access to and can prevent clean data about. The point that I was attempting to make is that Bitcoin Core isn't the only piece of software in the ecosystem with performance problems, given that a large portion of users have Electrum wallets it would be insane not to consider the impact changes will have on the people that charitably run servers for the community.
By the way, is that an offer to buy my dedicated server some new SSDs?
> work with people like Tom and Mike who have a 'lets get it done' attitude, and
> focus on what it will take to scale up.
Scaling up isn't tweaking parameters and ignoring the brickwork falling around your head. You mention that you think the merkle tree can hold an unlimited amount of information, that's all very well so long as people can actually validate the thing. Miners aren't even willing to validate their own blocks at the peril of losing $7000 USD (on two occasions now), so why would anybody else?

2023-06-07 17:42:47

- reply

📅 Original date posted:2015-07-24
📝 Original message:Keep in mind this is the similar premise as claimed to be offered by BIP37 bloom filters, but faulty assumptions and implementation failure in BitcoinJ have meant that bloom filters uniquely identify the wallet and offer no privacy for the user no matter what the settings are. If you imagine a system where there is somehow complete separation and anonymization between all requests and subscriptions, the timing still leaks the association between the addresses to the listeners. The obvious solution to that is to use a very high latency mix network, but I somehow doubt that there's any desire for a wallet with SPV security that takes a week to return results.
> Sent: Friday, July 24, 2015 at 4:26 AM
> From: "Eric Voskuil via bitcoin-dev" <bitcoin-dev at lists.linuxfoundation.org>
> To: "Stefan Richter" <richter at cs.rwth-aachen.de>, gb <kiwigb at yahoo.com>, "Thomas Voegtlin" <thomasv at electrum.org>
> Cc: bitcoin-dev at lists.linuxfoundation.org
> Subject: Re: [bitcoin-dev] Making Electrum more anonymous
>
>
> From our perspective, another important objective of query privacy is
> allowing the caller make the trade-off between the relative levels of
> privacy and performance - from absolute to non-existent. In some cases
> privacy is neither required nor desired.
>
> Prefix filtering accomplishes the client-tuning objective. It also does
> not suffer server collusion attacks nor is it dependent on computational
> bounds. The primary trade-off becomes result set (download) size against
> privacy.
>

2023-06-07 17:42:47

- reply

📅 Original date posted:2015-07-24
📝 Original message:> Sent: Friday, July 24, 2015 at 6:44 AM
> From: "Eric Voskuil" <eric at voskuil.org>
> To: "Slurms MacKenzie" <slurms at gmx.us>, bitcoin-dev at lists.linuxfoundation.org
> Subject: Re: [bitcoin-dev] Making Electrum more anonymous
>
> This is why privacy remains a significant issue. Privacy is an essential
> aspect of fungibility. This is a central problem for Bitcoin.
Somewhat under discussed too, really. Peoples money doesn't fly out the window when their privacy is ripped out from under them, as such discussing it seems a little meaningless. As some of the most popular wallets don't even use change addresses, for the comfort of the developers and at the cost of the user.
> Solving the latter two problems can go a long way to reducing the impact
> of the former. But currently the only solution is to run a full chain
> wallet. This is not a viable solution for many scenarios, and getting
> less so.
Which makes the general clambering for demise of the full node wallet all the more baffling.
> Well because of presumed relationship in time these are not actually
> separated requests. Which is why even the (performance-unrealistic)
> option of a distinct Tor route for each independent address request is
> *still* problematic.
Yep, any leak is a useful leak. Even if you only expose one single address request to me, I now have an idea of what timezone you are in and can eliminate it from other implausible ones. Onion routing is not a solution in my mind, you're just asking for people to sybil attack Electrum clients to capture as much timing data as possible. There's no defending against that.
> Introducing truly-random timing variations into the mixnet solutions can
> mitigate timing attacks, but yes, this just makes the already
> intolerable performance problem much worse.
Realistically this is all too broken to be building wallets on top of.
SPV clients are neither secure nor private, we should feel guilty for ever promoting them.

2023-06-07 17:42:46

- reply

📅 Original date posted:2015-07-24
📝 Original message:> Sent: Friday, July 24, 2015 at 2:12 PM
> From: "s7r via bitcoin-dev" <bitcoin-dev at lists.linuxfoundation.org>
> To: bitcoin-dev at lists.linuxfoundation.org
> Subject: Re: [bitcoin-dev] Making Electrum more anonymous
>
> Privacy concerned people should run their own Electrum server and make
> it accessible via .onion, and connect the bitcoind running on the
> electrum server host only to other onion peers (onlynet=tor). We should
> highlight that using Electrum with Tor cannot leak more that some
> addresses belong to the same wallet, which is not the end of the world.
>
It leaks your timezone too. As pointed out in another thread running a electrum-server instance is no easy task and can't really be suggested to another as a sensible thing to run for themselves. Enthusiasts maybe, but they'll just want to run Bitcoin core and skip the behemoth middleman.

2023-06-07 17:42:35

- reply

📅 Original date posted:2015-07-24
📝 Original message:> Sent: Friday, July 24, 2015 at 10:52 AM
> From: "Thomas Zander via bitcoin-dev" <bitcoin-dev at lists.linuxfoundation.org>
> To: bitcoin-dev at lists.linuxfoundation.org
> Subject: Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB
>
>
> The reference to bandwidth increases makes no sense, the bandwidth in most of
> the world is already far exceeding the 8Mb limit. Not everyone lives where you
> live :)
>
> In Germany you buy a 150Mbit connection for a flatrate and a cheap monthly
> rate, for instance. Not saying that Germany is where all the miners are, but
> since 150Mbit allows one to comfortably have 16 megabyte blocks, it is a good
> example of how far off Luke's calculations are from real-world.
I'll have better stats available soon, but this does not reflect the current state of the network.
Only 4% of my initial crawl presented bandwidth above your stated 18MB/s.