Love the age + free filters. First I'd heard of Swift Playgrounds! I wonder how they decided which ones to include. Also, first time I've seen learning resources broken down by apps, games, videos, etc. To be honest, it makes a lot of sense.
Clarifications (this comment perpetuates some common misconceptions):
- A single bitcoin "transaction" can actually have thousands of inputs and thousands of outputs. So energy "per transaction" or "transactions per second" is not analogous to a typical monetary transaction.
- Bitcoin does not compete with literal credit card transactions (although some use it like that today). I'd compare Bitcoin on-chain transactions with how nation-states settle their central-bank ledgers with gold. Gold is the best comparison to Bitcoin because trading in hard gold is "final". Credit card transactions happen on a higher level in the financial stack. As does cash. As do bank transfers. All of these bubble down into interbank transfers that eventually settle on the base layer of central banks. So compared to shipping and securing gold, Bitcoin is quite cheap!
* Pasted and modified from an earlier comment I made on HN.
> Bitcoin does not compete with literal credit card transactions
That's, like, just your opinion. For a lot of people it competes just fine.
> Credit card transactions happen on a higher level in the financial stack. As does cash
How so? As far as settlement is concerned, a cash transaction is pretty much exactly like a bitcoin transaction (and quite unlike a credit card transaction).
>That's, like, just your opinion. For a lot of people it competes just fine.
Until it doesn't. A payment network is graded on how it handles disputes, not regular transactions. Bitcoin can't do refunds or chargebacks, making it rife for fraud.
Sure, you can implement escrow, but then it's no longer competitive like GP said.
Still limited to 1 000 000 bytes per 10 minutes and then some for segwit which was a unnecessary hack job that actually makes blocks bigger without much added throughput.
In Bitcoin the block size limit was eliminated and replaced with a block weight limit which better reflects the long term operating costs for node. The raw 'size' of transactions inherently is becoming less meaningful in the long term with things like transaction compression and compact encodings.
The weight limit doesn't map perfectly to any size limit because its limiting different things, this evening most blocks have been about 1.3 MB.
Probably technically true, but, it is just a part of the dishonest language-shell-game to fool people into thinking BTC can really scale to become a real peer-to-peer electronic cash for the world's people. 1.3 MB is still tiny! Pretending a small difference matters is so disingenuous.
Blocksize is clearly not literally a rate; that's a ridiculous statement. When you artificially cap it, like putting a limiter on your car in your analogy, it can be rate limiting, i.e. limiting the transaction rate - an actual rate. That chart you posted in meaningless in this context, but clearly just greg being greg, trying to manipulate; are you seriously trying to suggest that the tiny increase from segwit shenanigans is responsible for that (cropped) decrease in tx fees? That's demonic.
It is literally a rate. It is the rate of bytes added per block (which by the system's design is once per ~10 minutes).
Increasing supply above demand radically drops fee rates. That is the logical, predicted, and observed behavior-- both in Bitcoin and in other similar systems.
Look, I'm not one to harp on semantics, but this is bullshit, you can't* just make something a rate by using the word 'per'. If I'm a doughnut shop, and I sell 12-packs of doughnuts, my doughnut-box-size is not a rate, the amount of doughnuts I sell in an hour, or a day etc., is a rate. If my store has a policy of only fulfilling orders once every 10 minutes on average, but only up to one box, or 12 doughnuts per 10 minutes, the doughnut-box-size is still not a fucking rate, even though the shop could say they only sell 12 doughnuts per 10 minutes. Edit: Let me rephrase this somewhat; it's clear greg is trying to use semantic chicanery and multiple definitions and senses of the word 'rate' to obfuscate any actual points. Rate is typically used and understood (let's say in STEM anyhow) to be a measure of 'flow'. Thus his speed example, distance per time, is a rate, or tx per second. It doesn't have to use time as measure, but here what greg is trying to do is say that, using the most generic definition of rate, you can compare doughnuts and boxes and say that doughnuts-per-box (blocksize) is a rate, even though he's really using as example "(dougnuts-per-box)-per-((10 minute)time interval)", which is a rate, and pretending they're the same thing . Of course if you increase the size of the container, the flow, or actual rate of tx/time interval will increase, but saying that the size of the container itself is a rate, is contextually insane.
Of course the fees would drop after raising the blocksize.
The current fees are well above the marginal transaction costs of processing and storing those transactions. (I estimated it was 3cents/kB, assuming GB scale blocks on ~1000 4U (36 bay) servers with 10Gbps networking distributed world-wide.) Other analysis I have seen erroneously assumes the POW is a marginal cost: which is only true with a tiny, limited, block-size.
During the September 1, 2018 "stress test" on the BCH network, the average transaction cost actually went down. All while the network processed 2 million transactions in a day.
Pretty much this. I don't think greg has read any economic theory, let alone introductory microeconomics where you would see the idea of 'marginal analysis'. I mean his reply suggests that demand is entirely static, or inelastic, which would be interesting to study, but certainly shouldn't be assumed, and is likely completely false.
Yes this is true because Bitcoin core plays by the speed of the weakest link.
It's not true for Bitcoin Cash which plays by the "if your node is not making you money why are you running it"
When we upgrade every 6 months or useless nodes just get stuck on the old chain forever and that's it.
Last upgrade there was one miner who upgraded one block to late and lost about 1000 USD. That miner will be the first to run the new software in may.
We had a hacker who got a smart card to get Bitcoin cash to work like a credit card without needing to be online.
Bitcoin cash tx are instant and take on average about 2 seconds to spread to about 1999 out of 2000 mempools.
They settle on the chain on average 10 minutes.
Credit card tx also take a couple of seconds but much longer to settle.
Right now BCH can not yet scale like Visa but we already have the capacity to compete with paypall.
Satoshi's design works at scale but only when you don't delete point 6 from the whitepaper which is "Simple Payment Verification"
Core tries to make you belief the whitepaper was written without points 6 and 7.
7 is how to make the blockchain smaller by pruning it using merkle trees.
Nobody does that yet because storing 200 GB for 10 years is super cheap.
But 6 and 7 are ESSENTIAL in the design to scale.
Core completely ignores them or says: Well SPV is not 100% secure there for it's insecure and should not be used.
Gmax does this with everything, he flips it to extremes.
Meanwhile right now on LN there is couple of hundred thousand dollars that is very easy to steal from non technical people.
1) you find people that want to open a channel with you. These people go online to post their ip addresses and open ports on /r/bitcoin. These posts are encouraged on /r/bitcoin.
2) You open a channel with them for like 100 USD in BTC.
3) You push the balance to their side of the channel by using a swap side that accepts both LN and other coins.
4) You sell this 100 USD for another coin.
5) You publish an old state.
6) You do this to nodes you monitor using nmap to see if they go offline on a regular basis for longer then nlocktime.
7) You can't lose money on this, only win with people that should not be running LN but are.
There is like 6 million USD locked up in LN and about 10% is for grabs.
8) The victims have nowhere to go because if they post about it on their channels they get called stupid and banned and their post deleted.
9) People are already doing this but the victims are still not speaking out. They just belief it was their own fault and move on. Meanwhile the watchtower software is not there yet and if a node does not go offline for nlocktime you can easily DDOS that node for 144 blocks and you doubled your money.
> I wouldn't rely on it because it's committing to an ongoing arms race against the browsers. One that I expect them to win.
Don't be so sure about this. The world's most popular browser is developed by the world's largest advertising company. I'm not saying Google is intentionally sabotaging Chrome, but I doubt they're putting significant resources into anti-ad technologies.
Well, in the end it's their competitors that are hurt most when they close loopholes without warning. All chrome needs to do is hamstring ad-blockers (which they just did) and add a fingerprint that only google can use (like tying your google account to the browser for no reason...)
> Browser fingerprinting is a hack, and exploits clear loopholes in browser privacy models.
> I wouldn't rely on it because it's committing to an ongoing arms race against the browsers.
It doesn't seem to me that browsers are trying to win at all. For example, one of the greatest discriminators - font list - has been known about since people were talking about browser fingerprinting.
The fix would be pretty easy too: in incognito mode (or when toggled by the user), only support 2 fonts: 1 serif and 1 san-serif that ship with the browser on all platforms.
I don't think any of the browsers want to do that.
There are a number of other longstanding fingerprinting issues that are similarly easy to fix.
Last I checked, Safari in fact restricts the fonts web pages can see/use to ones that ship by default with MacOS. So you can't fingerprint a Safari user via fonts any further than "Safari user".
So yes, browsers, at least some of them, are in fact trying to win here.
> You'd need a standardized font rendering engine to defeat fingerprinting via canvas.
That's fair.
But that really only gives the attacker the OS (and perhaps the GPU vendor?). Not ideal for sure, but not that many bits of info, especially if you are in the majority (windows / intel)
Sure, the basic things like "which fonts do you have installed" are easy to make consistent, but there are thousands of other ways to fingerprint a browser, many of which would have serious performance impacts if fixed. For example, Macbook Air's can only run at full CPU speed for about a second before slowing down. Just make a 2 second javascript busy loop and watch for the slowdown. Are you going to slow all users down all the time just so these macbook users can't be identified?
None, its a usecase difference not a technical one. but samesite is designed to tackle csrf (a problem with using cookies for auth). It wont prevent user tracking.
Sure it can. Samesite cookies will prevent e.g. Google Analytics from identifying me between domains, since any samesite cookies they set for the domain from which they’re serving their script/pixel won’t be sent. (Presumably tracking prevention will eventually start to block cookies with samesite disabled).
Browsers have offered a "block third party cookies" setting for decades.
I'm honestly surprised none of the major browsers block third party cookies by default, it's much simpler XSRF protection than this as it doesn't rely on site developers updating and setting the new flag right.
Of course, two sites that seriously want to collaborate on user tracking (or login) can always forward the user’s whole browser window there and back, with URL parameters to synchronise first party cookies.
> as it doesn't rely on site developers updating and setting the new flag right.
Chrome is enabling this flag by default. Websites can opt out, but if they do nothing they are opted in.
Blocking third party cookies doesnt really stop csrf attacks. At most it makes the attack a bit more noticeable as it prevents some of the quieter methods of pulling off the attack. Since as far as i understand, if you submit a cross-domain POST form, that's still a first party cookie
Websites can just opt out if they dont like samesite cookies. Even if they couldnt, its trivial for the website operator to work around if they want (and website operators are almost always in on user tracking)
For authentication, there is also the HTTP basic and digest authentication. However, I do not know that any web browser provides functions for the user to manage this authentication. (It would also make it easier for the user to configure cross-site authentication, too.)
Not sure how this is relavent, but IE had document.execCommand('ClearAuthenticationCache'); for http or TLS auth. Dont think other browsers have anything
That's assuming the alternative thing actually benefits from the money. You mention education, but we've already seen that education spending has a threshold past which spending more money no longer improves outcomes (it just inflates prices), and we're already above that level of education spending.
And even if we weren't, it doesn't follow that moving resources from one place to the other is the right choice. When you have two things that both produce benefits exceeding their costs, you're better off to do both of them.
> It doesn't follow that moving resources from one place to the other is the right choice. When you have two things that both produce benefits exceeding their costs, you're better off to do both of them.
Yes, in an imaginary world we can invest in all the good things at the same time.
In the real world you have a limited amount of resources, so you can't do everything at the same time without borrowing money. But guess what, borrowing money is moving resources from one place to an other.
The world in which you can invest in both drug research and education is not imaginary. We in actual fact already do both of those things at the same time.
> So that's a third pain point for us. Mutable global state is not merely available in Python, it's underfoot everywhere you look: every module, every class, every list or dictionary or set attached to a module or class, every singleton object created at module level. It requires discipline and some Python expertise to avoid accidentally polluting global state at runtime of your program.
> One reasonable take might be that we’re stretching Python beyond what it was intended for. It works great for smaller teams on smaller codebases that can maintain good discipline around how to use it, and we should switch to a less dynamic language.
> But we’re past the point of codebase size where a rewrite is even feasible. And more importantly, despite these pain points, there’s a lot more that we like about Python, and overall our developers enjoy working in Python. So it’s up to us to figure out how we can make Python work at this scale, and continue to work as we grow.
Those are literal quotes from the article. That is quite damning. How did they get to this point? By starting when Python was appropriate, and taking it day by day.
Clarifications (this website perpetuates some common misconceptions):
- A single bitcoin "transaction" can actually have thousands of inputs and thousands of outputs. So energy "per transaction" or "transactions per second" is not analogous to a typical monetary transaction.
- Bitcoin does not compete with literal credit card transactions (although some use it like that today). I'd compare Bitcoin on-chain transactions with how nation-states settle their central-bank ledgers with gold. Gold is the best comparison to Bitcoin because trading in hard gold is "final". Credit card transactions happen on a higher level in the financial stack. As does cash. As do bank transfers. All of these bubble down into interbank transfers that eventually settle on the base layer of central banks. So compared to shipping and securing gold, Bitcoin is quite cheap!
- Adding to the above point; if Bitcoin succeeds in beind "adopted", it would not mean we no longer use credit cards. Credit cards would just port their underlying mechanism on top of Bitcoin instead of fiat moneys.
The linked website attempts to quantify the impact with some stated assumptions. You’ve stated some alternative assumptions, but haven’t quantified the conclusions to determine if they hold.
I’ve been long on Bitcoin, but I am exiting my position over concerns about the environment impact. I don’t think it’s plausible that a proof-of-work based blockchain can be anywhere near as efficient as centralized ledgers are. If any of the proof-of-stake based solutions ever gain traction, maybe I’ll participate in those.
> can be anywhere near as efficient as centralized ledgers are
Yeah, no one ever claimed that they would be more efficient. If you have invested assuming the efficiency is the main goal, you have been misled. What they do provide is efficient decentralized ledgers, which is a whole other game completely.
> Bitcoin does not compete with literal credit card transactions (although some use it like that today). ... So compared to shipping and securing gold, Bitcoin is quite cheap!
I haven't heard the tagline "Bitcoin - it's cheaper than moving around gold on warships" yet. So far, Bitcoin has always been advertised as a new form of internet payment and a new decentralised currently for everyday use.
It's also the very point of cryptocurrencies that there are no intermediate agents, like central banks that could make up the lower levels of your stack.
So the usage patterns that Bitcoin was marketed with absolutely put it in competition with visa transactions.
I think it's fair to blame the marketing mistake. Bitcoin was built for the purpose of making convenient payments. However, it turned out to be an ingenious alternative to gold.
I wish it were labelled cryptoasset instead of cryptocurrency.
In the long-term, the objective nature of Bitcoin should prevail and we'll assess its benefit by whether it is a successful store of value.
Are you comparing Bitcoin to settlement with gold to make Bitcoin seem less inefficient? This seems like a misleading comparison, because which significant central banks still physically move gold around for settlement? Either they don't move gold or it is only moved virtually, and in either case Bitcoin is vastly less efficient.
I am comparing it to settling gold in that a settlement is "final". You can reverse a credit card transaction, a bank wire, etc. You cannot reverse a Bitcoin transaction or Gold shipment without significant risk and cost.
Off-chain transactions effectively don't exist at all in terms of transaction volume, and the players who staked money on Lightning lost approximately 99.97% of that money.
I think you haven't read how Lightning Network works.
People don't need to stake money, just create a multisig transaction with a peer and having a transaction signed by the other peer to get their money back when they want to close the lightning channel. They can get extra fees for enabling transactions, though not that big amount.
Perhaps the Satoshi group should have called their invention BitGold instead of BitCoin? Although it's normal to see tech guys bad at marketing/branding.
He resigned after these conversations blew up https://www.documentcloud.org/documents/6405929-091320191420... but there has never been a shortage of things he's said to make headlines. I'd recommend skipping the commentary/news/blogs on it and just forming your own opinion and going from there.
