No mention of the 'stress test' that's brought the network to its knees the past few days, or of the soft fork that resulted in suggestions to wait for 30+ confirmations? Puff piece.
C'mon Coinbase, at least spin them into a '<X> is actually good for Bitcoin, because <Y>' format.
For those who don't know, the stress test was where a company tested what would happen if someone filled the network with transactions.
The results were not favorable for bitcoin and highlights key design problems -> some transactions cost $280/transaction to put through, and other transactions that had <$20 fees were not processed and stuck in limbo.
Maybe some people paid fees that high by mistake, but no-one had too. Equally $20/tx fees are still ludicrously high by about three orders of magnitude.
Bitcoin miners prioritize transactions from highest fee to lowest; the attackers never sent transactions with more than 0.2mBTC/KB fees, which works out to about $0.01/tx. In other words, if you paid more than about $0.01 in fees, your transaction was unaffected by the flood.
The problem was a lot of badly written Bitcoin wallets don't let their users set fees at all, nor do they let you resend transactions stuck due to low fees. This is an easily solved problem, and fortunately we're seeing wallet authors fixing it. This should have happened years ago... but a lot of people are heavily invested into the idea that Bitcoin transactions are "free", which just isn't true...
> The results were not favorable for bitcoin and highlights key design problems
Some would disagree, considering the system kept functioning exactly as intended under the circumstances imposed on it.
Personally I agree that the whole thing is troubling, but was anything really discovered here?
Considering that the price has been rising, if you believe in prediction markets, these design problems could likely be overcome. After all, people have been working on it since long before any of these stress tests were performed.
Some would disagree, considering the system kept functioning exactly as intended under the circumstances imposed on it.
Yes, hence the GP stating, very clearly, that the results "[highlighted] key design problems".
The results of the stress test were not surprising to anyone who's been paying close attention, but it was a valuable demonstration that Bitcoin is it currently operates is misarchitected and will require some fundamental redesigns in order to operate at scale. These problems have been under discussion since at least 2011 and have been constantly disregarded, so perhaps this will help. It seems unlikely.
More full nodes would not solve the problem. Raising the maximum block size is the only real solution, although paying $0.02 per transaction instead of $0.01 until the "attackers" stop isn't such a bad thing. Especially compared to potential downsides to raising the maximum block size.
On the contrary, the network worked as expected. A somewhat costly stress test resulting in a backlog of transactions that were prioritized by fee, just as predicted.
The backlog has since been drastically reduced and high priority fees are back in the 50,000 satoshi per kb range [0]... the average Bitcoin transaction is about 250 bytes, so 12,000 satoshi per transaction, or roughly 3 cents. Low priority transactions of < 1 cent are still somewhat easily confirmed [1].
Even during the stress test I saw high priority fees hovering around the 85,000 satoshi/byte range, and never in the 1,000,000+ satoshi/byte range that you're talking about.
What's impressive is that the price [2] of Bitcoin was completely unaffected by a bit of weather [3] on the network and in fact gained in value during the entire ordeal.
Public data storage like the ledger maintained by the Bitcoin blockchain has a definite cost and it makes sense that prices would rise as demand increased. The blockchain is a scarce resource. It might make sense for transactions fees to end up around the price of a postage stamp at some point. It's hard to predict how this economic system will continue to evolve.
What's most important is that the ledger continues to be maintained, eventually consistent, secured by lots of hashing power, 100% verifiable and has an open and equal access to read and write as it ever did.
Not every transaction between two parties needs to be recorded on the blockchain. The blockchain is for clearing and settlement. Between lightning networks [4], private federated offchain networks for batch transactions, and possibly public sidechains (if they every materialize), there's a number of approaches that can help facilitate micropayments and other situations that require very low fees.
>some transactions cost $280/transaction to put through
The stress 'test', (or was it really an attack?), is interesting, though it may be too recent to be included. But where did you get that $280 from? That figure sounds ridiculous.
People who drop an extra 4 dollars so their morning commute is reliable and moderately pleasant are now white privileged elite. I'd hate to hear what you think of people who drive cars.
Wanting to be at work on time without allotting an extra 30 minutes for public transit shenanigans is hardly the epitome of privilege.
What aspect of a fancy bus that drives in normal traffic like any other bus (or car, assuming there are not bus-only lanes) makes it any more capable of getting a person to their destination sooner?
Addendum: this is a private company that technically speaking does not have to adhere to any schedule and isn't liable for various things (according to the TOS posted in this tree), so if anything you're more likely to be on the wrong end of things compared to an organized public transit system.
Not sure about SF, but in Toronto, the only problem is scheduling and management. Also, I won't vouch for Leap or make any assumptions about SF's transit, but if it's anything like Toronto, the only thing you need to change is scheduling. Traffic is not a problem. ONLY SCHEDULING.
The problems in Toronto result in 30-60 minute waits for a bus or a streetcar in the wintertime (during -20°C weather too). Then you will get about 5-10 in a row, all within a few seconds or minutes of each other.
This happens because Toronto does not schedule its transit very well (or at all). So everything is late and miserable.
If Leap schedules things correctly, in part because they are a private company and have incentive to do so, they may be able to beat public transit solutions - in terms of reliability of service - without breaking a sweat.
Again, I don't know how much this info is relevant here or for SF. But there are multiple ways that a private company can improve on the timing and scheduling of existing public transit.
I live in Toronto, and the problem is certainly one of traffic density, exacerbated by the heavy use of streetcars on Queen/King &c and the brain-dead payment model. The TTC doesn't schedule buses and streetcars to stack up -- it happens because of traffic holdups. That's not to say that they couldn't schedule better, of course; I think that dynamic scheduling, where buses can for instance skip stops if there's another following within 90sec or some other heuristic to catch up further on the route.
> If Leap schedules things correctly, in part because they are a private company and have incentive to do so
I don't know what you think the TTC does all day, but it's not sit around and say "if only we had competition, we'd make the busses better". It may not be possible to schedule to avoid busses bunching up during peak times, if that's how traffic behaves. The only way to fix it might be to run an excess of under-utilized busses, which cuts into profit margins. Which is something a private company with higher rates might be able to do, but the TTC is limited because service has to be accessible to everyone.
The risk of a private company like this showing up is that it'll decide to focus intensively on the 20% of routes that yield 80% of profit. This bleeds the public transit service of funds needed to run less profitable services at off times that are used by people without 9-5 jobs, or people in less privileged areas. So the rich get better bus service, and no longer subsidize the service for the poor.
I've lived in SF and Seattle. In SF, in the old days, you got lots of bunching, and usually on particular lines (like the 6 Parnassus which ran in herds), but these days there is very little of that at all. Might have something to do with computerizing the schedules awhile back, I don't know.
In Seattle the buses have posted times on a schedule at each stop and they pretty much nail it in my experience. If a bus is more than about three minutes late people start looking around and checking their watches.
You are assuming that there is no better way to define the schedules, no better way to communicate bus location, and no better way to start buses on time than what currently exists.
There are two sides to on schedule performance - what the bus does, and what the schedule says. You are probably right that the bus can't move any faster just because it is private. On the other hand, I bet a tech savvy company can do vastly better at predicting what the actual bus schedule will be as well as communicating any deviations from the schedule in real time.
> On the other hand, I bet a tech savvy company can do vastly better at predicting what the actual bus schedule will be
It's mainly traffic issues, or a single wheelchair/baby carriage clogging up the exits and requiring more time than anticipated. It's hard to make useful predictions for that.
> as well as communicating any deviations from the schedule in real time.
The municipal public transits in many European cities already have real-time schedule updates (and replacements) delivered via smart phone apps and digital signage posts at the bus stops. Big IT (I think Siemens, e.g.) has been offering and deploying solutions for this for years now.
They specifically mention that they'll eventually intelligently figure out where they need to stop based on who signs up for a ride on the smartphone app. That seems like a pretty big potential win, in that they could do all sorts of creative things to minimize or control stops on the way.
It's worth a shot. I like seeing experiments like this that public transit can't do, even if it ultimately ends up failing.
Why use the profits from October in the headline of an article published in February? The cost of bitcoins has nearly halved in the meanwhile. Hope they had a healthy profit margin before.
On the contrary, it's very interested in the truth. When you want to present an expert witness, you include in the paperwork what truth they're going to tell the court, and their evidence for it.
The trial is a show for the jurors to convey information to them - everything that's going to be said NEEDS to be conveyed to the opposing side in advance, so they can prepare responses.
Surprise witnesses that blow cases wide open are only on TV.
He also claims they passed it back to him immediately before the bust. Only slightly more effective than the "I was holding it for a friend" legal defense.
Only if you're prosecuting. If you're defending yourself, all you have to do is make it sound believable given the circumstances. A jury can find you not guilty just because they don't like the law. To defend yourself in a U.S. court you technically wouldn't need any evidence to substantiate any of your claims just so long as the jury buys it.
"A jury can find you not guilty just because they don't like the law."
This is not really the case. It would be tough to find all jurors didn't LIKE the law. The people sitting on the jury were asked questions during the selection process to make sure they are neutral. The question is, do they understand the law and the issues at hand.
The prosecuting team bears the burden of proof (obviously). The prosecutors are required to prove their version of the actual events. This means that the proposition that is being presented before the judge / jury by the prosecution must be proven to the extent that there could be no reasonable doubt that the defendant is guilty. The defense needs to convince the criminal jury so they are unable to find beyond a reasonable doubt, that this guy is guilty.
The defense seems to be casting doubt for the jury to consider from the get-go. Well played.
Do you honestly think that 12 random people are going to understand the law better than say a 3 judge panel?
There are a few benefits as for example Juries are harder to bribe and sequestered juries are harder to tamper with. But, the core issue and why they were considered so important is there a check on unjust laws or even just laws unjustly applied.
We have to assume not until/unless a lawyer shows up and says otherwise.
Rumors to the contrary, we do have a right to free speech, so you can say anything you want in a courtroom without being arrested, unless it causes immeidate danger (e.g. yelling "FIRE!").
When jury selection happens, I have heard that you can be rejected from being on the jury if you say (essentially) that you don't agree with the law. Not agreeing with the law is precisely what leads to jury nullification.
Good point. And I'm sure if the court is in session, talking out of turn about anything (including jury nullification) would get you held in contempt of court.
So, saying you'll be arrested for talking about jury nullification in court doesn't really give an accurate picture. Though it is probably technically true.
Are you claiming that jury members select a verdict at random? That there is no thought process happening in each of the individuals on the jury? Regardless of whether the juror's beliefs correspond to the actual reality of the case, that individual will still require some reason (evidence) for believing a particular thing. If you are trying to convince a juror of something, you will need to interact with that individual on such a level that you provide them with sufficient evidence for them to believe the claim you want them to believe.
This is separate from the rule of law in the US where a prosecution must prove its allegations beyond a reasonable doubt. It is true that a defense is not required to make any claims or present any evidence. However, depending on the jurors selected, in order to instill or preserve a reasonable doubt, some claims may need to be made. In order for a juror to believe a claim, that individual juror will need to find or receive some evidence sufficient for them to believe the claim.
Out of the millions of trials that have happened I would not be surprised if at least one jury that was undecided simply went with a coin flip or other random means.
Historically this may even have been a unusual, but not that uncommon practice. aka trusting in 'the gods' or some such.
Burden of proof in U.S. criminal cases often seems to be more of a suggestion than an actual mandate. With the way the legal system is structured, it's effectively guilty until proven innocent.
All those regular sellers are most likely the miners, who have to quickly move their bitcoin to cover mining costs. In an unfortunate feedback loop, the cheaper the coins cost, the more of their production they have to sell to cover expenses.
The price is dropping to the point where it's barely profitable even with the newest hardware, unless you're using it as a roundabout method of money laundering (sell coins for USD, pay your electric bill in RUB).
> if someone has backdoored your login server, it no longer matters if passwords are cleartext for the damage they'll do. The level of difficulty you introduce by having passwords hashed originally becomes moot at that point.
If your hacker has a cleartext password and their login ID (email address), you've just given the hacker access to a bunch of their other accounts on non-compromised sites (for the significant % of your userbase that recycles passwords). I think the possible collateral damage creates a far more severe worst-case scenario.
If they have access to your server they can inline javascript that will do the same thing on the client. The client is not secure, ever. If the users are reusing passwords, it's not something you can same them from except not saving the cleartext password yourself. Database attacks are different from on line interception.
That's a fair point, though it doesn't outweigh the myriad other reasons not to do client-side hashing.
Security is always a battle of usability and tradeoffs. Client-side hashing simply doesn't make sense for security. It removes the fundamental point of the hash in the first place and introduces an avenue for possibly attacking or manipulating your database.
In fact, there's hardly ever a reason to do client-side security.
Yes, that's exactly what I mean. Treat all user-input (and by extension, client-side anything) as dangerous. A server putting a security protocol in the hands of the client when it is not unavoidable is usually bad.
One entire million injured? Something must be off there, otherwise the injury rate would be ludicrously high relative to the small number of troops we had in the wars.
Which are the numbers of veterans that accessed VA facilities for health care, not the numbers of veterans that were injured (disabling injuries are one of the major eligibility factors for the VA, but there are other veterans that would also be eligible for VA services).
In particular, young veterans use the VA mostly in the case that they don't have private health insurance (a job with health insurance, mostly), so the healthier young veterans don't use the VA. Older vets often use the VA because they're retired and it has good services. My grandfather uses the VA without any service injuries because they've got comprehensive care for older guys -- all the services in one building; a great-uncle used them for hearing aids (slightly service-related) but not anything else; younger vets I know just use private care for now.
C'mon Coinbase, at least spin them into a '<X> is actually good for Bitcoin, because <Y>' format.