A trivial solution would be to increase the block size, but unfortunately Bitcoin Core developers refuse to do it, under the pretext that it will "increase centralization". In reality, a reasonable (2-4×) increase wouldn't. The amortized cost of running a full node able to support 2-4 times larger blocks is only $5 per month (http://blog.zorinaq.com/full-node-on-5-dollars/). The block propagation delay has also largely been solved with Compact Blocks which transmit a nominal 1MB block in ~20kB. Also, at least 2 on-chain scaling technologies are being developed that would easily let us increase block sizes: UTXO commitment sets can reduce long-term blockchain storage by 50×, and Graphene reduces the size of a 1MB broadcasted block by another order of magnitude, down to ~2kB.
There's no such thing as a trivial change to the bitcoin consensus rules, especially when that change requires everyone to upgrade their software at once on pain of financial loss. We're talking something that's never been done before in the entire history of Bitcoin.
Also, running a full Bitcoin node on a machine with a spinning rust disk and a relatively small amount of RAM is going to be hell - especially if that disk is heavily shared - because it has to do a lot of random reads from the chain state DB in order to retrieve outputs referenced by the transactions, with the number of reads scaling linearly with the block size. I think some of this may be skipped during the initial block download these days, but you can hit 1 minute plus per block easily just with the existing block size limit. It looks like the hosting provider he chose has some kind of SSD cache of unspecified size which might have helped, if everything fitted in it.
> There's no such thing as a trivial change to the bitcoin consensus rules, especially when that change requires everyone to upgrade their software at once on pain of financial loss. We're talking something that's never been done before in the entire history of Bitcoin.
No, not like that. Technically that only required a supermajority of miners to install the fixed version (and everyone to stop trading temporarily, but there wasn't much of that going on back then anyway). This would be harder because it really would require everyone to upgrade. BIP50 is probably closer; that did require everyone to upgrade over a relatively short timespan or work around the issue by changing a setting, ironically enough due to a latent bug triggered by increasing block size closer to the maximum 1MB.
> The bad transaction no longer exists for people using the longest chain. Therefore, the bitcoins created by it do not exist either. While the transaction does not exist anymore, the 0.5 BTC that was consumed by it does. It appears to have come from a faucet and has not been used since.[7]
Wait... so if you wait long enough then old transactions disappear ? I thought the whole blockchain could allow anyone to track every transactions ?
This is not true at all. On the last 10 blocks (495808-495817, ~6000 seconds) there were 22,277 txns and 49,746 txn inputs. That means a full node needs to look up on average only 8.3 inputs per second in the UTXO database. Assuming 1 I/O per lookup, that's 8 IOPS, which is a trivial workload, even on a non-SSD setup.
I am the author of this blog.zorinaq.com post and I can assure you the real-world I/O workload I see on this $5/month node is negligible.
You're assuming that you're content to always be one block behind on average, that the node never goes down and has to catch up, and that the block size never increases. The block size is already increasing, and you're suggesting an even bigger increase. Also, cheap VPSes are often pretty terrible in the IOPS department because storage is shared, worse than a normal non-SSD setup.
The node is never one block behind. Block verification is instantaneous on my VPS. You seem to be under the false impression that when a block is announced, a node has to suddenly verify 2-3k txns in a brief moment. This is not how things work. Txns are verified incrementally as they are added one at a time to the mempool.
> Also, running a full Bitcoin node on a machine with a spinning rust disk and a relatively small amount of RAM is going to be hell
Is anyone even actually doing that? Even several years ago when I last did it, the blockchain was 60+GB (now it's more than twice that) and you were never, ever going to get anything out of it other than heating the room up.
The way I thought most people were going was using something like Electrum, where you still have your own private wallet that nobody else controls, but you're not yourself a full node.
Running a 120GB DB on spinning rust to the level of a dozen tx per minute is a jokingly light load on modern hardware, and dead simple to set up in the cloud.
You don't even do anything with most of the DB once you have it.
> We're talking something that's never been done before in the entire history of Bitcoin.
That is false. There were even rollbacks in the early days. Don’t talk about a subject you haven’t personally experienced or taken the time to research.
The core developers (employed by Blockstream) have intentionally kept the block size at 1MB in order to support the product they're attempting to develop (lightening network layers) which lets them facilitate federated payment processors siphoning fees out.
It's a red herring to claim larger blocks increase centralization when it's just data storage. Drives are cheap. Centralization already happened once sha256 ASIC hardware was produced enmasse, preventing normal users from earning block rewards. The Bitcoin devs are lost in political dogmas, rather than improving the software for users.
There are hundreds of Core developers; only about 6 of them are related to Blockstream. Your conspiracy theory does not hold up to reality.
> have intentionally kept the block size at 1MB
The block size has already been lifted to 2MB-4MB with SegWit.
> Blockstream ... support the product they're attempting to develop (lightening network layers)
Lightning Network was invented by people that have nothing to do with Blockstream, who founded their own company for that: https://lightning.engineering/team.html
There are 5 different teams developing Lightning Network implementations. Blockstream is merely responsible for the C implementation, they have no special control over Lightning.
> It's a red herring to claim larger blocks increase centralization when it's just data storage.
It's not just storage; the main issues are bandwidth, latency and IBD time. There are very real engineering limitations and trade-offs that have been discussed in depth over the years that you're just brushing off here. It's not as simple as you make it appear.
Mate, please, stop with the Blockstream FUD. Blockstream make up only 20% of commits on Bitcoin. Find another strawman.
There is not a 1MB limit, the limit was lifted with the implementation of segwit, as it changed the counting mechanism to weight instead of size, as a result, you can now push upto 3.7MB worth of tx into a block.
Your proposition is wrong and people like you who constantly spout it should be called out and shamed like the fucking charlatans that you are. Blockstream has no financial interest in having Segwit, LN or anything else implemented. They have DEFENSIVE patents against the technology to stop trolls from holding up the development process. Please, locate yourself to Google Patents and search for Blockstream, then consult their Open Patents disclosure for further confirmation that you are wrong and have taken the bait of companies who have an interest in deriding the current decisions of Core.
Core is implementing a variety of changes in the future that will put many businesses against Core out of business.
Cross chain atomic swaps = exchanges
More private transactions = anyone doing blockchain analysis (lolgarzik)
Lightning Network = miners and anyone who processes transactions.
The most painful part of your opinion is that you can't extrapolate network rules and see that in the next 2 years, rewards are going to half, meaning that if we drop TX fees now, it will make it even harder to pull miners back. By implementing a simple situation for on-chain settlement, miners still make decent returns down the line.
Please, if you have any interest in Bitcoin, and have any decent brain about you, call people like this out for being the corporate sockpuppets they really are.
I don't have a leg in this debate. I just found it funny that you're both accusing each other of the same thing, and neither of you provided adequate sourcing so it's impossible for a layman/concerned bystander such as me to figure out who to believe.
Whilst I would usually agree with you, your comments about being a conspiracy theorist are IMO entirely wrong, look at the history of the account, the lifespan of it, and the threads it posts on. I agree that ad hominem is incorrect and pretty much always a bad way to argue, but you need to have some idea of context and the active measures that have recently been taken in this scaling "debate", there is straight up disinformation being circulated.
As far as I'm concerned, I did give facts, the segwit facts are correct. The loss of business is fact. The comment about chain rewards decreasing is fact.
Even if it is a sock puppet (and isn't your account pretty new?), humans are reading here, so my advice is to take the high ground if you want to convince people.
Can you explain why chain rewards decreasing are problematic.
Asic hardware is already bought, so mining still makes sense even if the rewards drop as the cost is sunk.
And in response to his fallacious proclamations that Blockstream controls core.
git shortlog -sn
4982 Wladimir J. van der Laan = Non-Blockstream
1446 Pieter Wuille = Blockstream
1101 Gavin Andresen = Non-Blockstream
639 Philip Kaufmann - Unsure
633 MarcoFalke - Non-Blockstream
559 Matt Corallo - Non-Blockstream
551 Cory Fields - Unsure
533 Jeff Garzik - Non-Blockstream
520 Jonas Schnelli - Non-Blockstream
330 Luke Dashjr - Blockstream
261 Gregory Maxwell - Blockstream
245 s_nakamoto - lol
208 Alex Morcos - Non-Blockstream
208 John Newbery - Non-Blockstream
197 Suhas Daftuar
131 practicalswift
113 Russell Yanofsky
113 fanquake
102 Peter Todd
95 Pavel Janík
86 Jorge Timón
74 Michael Ford
74 jtimon
70 Cozz Lovan
50 Patrick Strateman
40 Andrew Chow
36 João Barbosa
35 R E Broadley
34 Giel van Schijndel
32 BtcDrak
32 Eric Lombrozo
31 Daniel Kraft
30 Jeremy Rubin
29 Karl-Johan Alm
29 Nils Schneider
28 Gregory Sanders
27 Chris Moore
26 Satoshi Nakamoto
26 sirius-m
23 Johnson Lau
23 MeshCollider
23 instagibbs
21 Micha
20 dexX7
19 Warren Togami
19 gavinandresen
19 tcatm
Sorry if I didn't do them all, you're getting the idea, as you go further down the list the impact of the organisation backing them inevitably goes down.
The technical implementations and actions speak louder than words.
Bitcoin maximalists try to rationalize their design flaws, but ultimately it's simply software running a service. There are new teams working on improving designs and useful features meanwhile core has stagnated and stalled for years.
You're clearly emotionally and financially invested in advocating for a single cryptocurrency. Fortunately there are now many to choose from. :)
That doesn't fit. Per bitinfocharts.com the coin with the highest txn rate is Ethereum, followed closely by Bitcoin. The others are far behind. I'd say it's seeing a lot of use.
The capacity was increased (more than doubled). Now its a matter of utilizing this new capacity by upgrading to SegWit-supporting wallets.
Note that upgrading your own wallet to SegWit immediately saves you about 50% on mining fees, regardless of whether other network participants upgraded or not.
It's not due to Bitcoin fees. It's due to BitPay's ridiculous fee mechanics.
Bitcoin works perfectly well when the mempool isn't being logjammed by 1-satoshi transaction spammers, in a misguided attempt to make bcash overtake Bitcoin.
Sometimes, the obvious solution isn't the right one.
Bigger blocks means more bandwidth is needed for blocks found by miners, which are transmitted across the whole network.
Our infrastructure isn't growing as fast as Bitcoin is.
Ergo, on-chain scaling doesn't work. Scaling can only realistically be done off-chain.
From the second screenshot, the transaction value was 0.003857 BTC.
From the guy's post, he transferred 0.003853 BTC. From the first screenshot, BitPay is saying he underpaid by 0.000004 BTC which would seem to be...100% correct?
I mean, obviously Bitcoin is a pretty silly way to buy a game on Steam, but this seems to be 100% user error.
...well, probably. There's some key info missing here, but this seems highly suggestive:
"BitPay emailed me saying I underpaid by 3 cents at the time, and said to refund me. I checked the price of bitcoin 0.003853 btc in usd is around $31 which was a lie on their part."
No, they said he underpaid by 0.000004 BTC. And the number he was googling is, coincidentally, 0.000004 BTC lower than the transaction value in his screenshot, so...
Unless BitPay have changed their policies, the exchange rate is only locked in for 15 minutes. If the transaction doesn't get its first confirmation before then, it expires and if the exchange rate goes up even slightly they consider the transaction underpaid. That's almost certainly what happened here. They used to be more sensible and only require the transaction to be broadcast to them within the 15 minute window, but they quietly changed it a few years back.
> If the transaction doesn't get its first confirmation before then, it expires
I don't think that's true. To the best of my knowledge, they lock-in the rate if the transaction appears on the network within the 15 minutes window, regardless of when its confirmed.
It's certainly possible they fixed this at some point, I gave up on using them after a bad experience with this a few years back. It just wasn't worth the hassle of trying to use Bitcoin for payments, especially after the Humble Bundle stopped accepting it for most things because they wanted to track purchasers' IDs.
Bitcoin was a perfectly reasonable way to buy a game on Steam in February last year. Of course my 0.035631 BTC purchase means I could have paid $15 cash and saved the coins and had $287 worth of BTC today. So maybe it wasn’t reasonable.
The fact that you used BTC for that purchase doesn't matter, you could also have decided to buy BTC instead of anything you bought with another currency.
Although in an environment where the main national currency experiences deflation like bitcoin, you do actually see people responding to the incentive by reducing current purchases, which is bad for economic growth.
Hi @Lazare, I am the dude who posted that reddit post.
The $25 game cost me 0.00424232 BTC (around $32.96 USD at that time). I transferred that much to them, but the network fees for some reason raised within that 2.5 hours. 3 cents. And they cancelled it. The fees were 0.00038932 BTC
It is messed up. Sending money from Coinbase to BitPay, for $29 resulted in $32 dollar in fees.
Nevertheless, this experiment showing a bunch of friends (~10) why Bitcoin is the worst payment provider. Network fees are not calculated correctly, transaction fees too. And at the end, this 3 cents difference from the transaction fees made a big deal.
And worse of all, customer support doesn't exist for the consumer at all when they pay for Bitcoin.
Yeah, it seems plausible that he thought he had to pay $29 in BTC, and so googled and paid that - but it came out 0.000004 BTC lower. And later when he found that what he paid was now $31, he also thought "well that's more than what I had to pay".
Naw, BitPay tells you the exact amount to pay in BTC for a 15 minute window. Around 10 of my friends verified I paid the right price, I was projecting to the big screen to show how it works. For some reason the network fee to pay the miners screwed up in BitPay or the price they received wasn't the right price since bitcoin went down slightly within 2.5 hours. So at the end of the day, the consumer is to blame.
I've never used Bitpay, but according to their docs, the process is:
1. The merchant tells Bitpay the USD value of the transactions
2. Bitpay calculates a BTC value based on current exchange rates
3. Bitpay sends an invoice to the customer valid for 15 minutes
4. If the transaction to transfer BTC is broadcast on the network prior to the invoice expiring, Bitpay will honour their initial quote.
5. Once 6 blocks have confirmed the transaction, Bitpay transfers the original USD amount to the merchant
So in this case, Steam doesn't do the price conversion at all, only Bitpay does. And Bitpay only does it once, when the invoice is issued. It appears that the user either transferred an incorrect amount, OR he waited more than 15 minutes to start the transaction, OR (as some are suggesting) Bitpay is being nefarious and not honouring their quote.
Editorialized title that omits the key role BitPay's policies played and blames this on Bitcoin's network fees. BitPay's policy of failing transactions if they don't confirm within 15 minutes has always been broken, because even if the transaction gets into the next block there's a reasonable chance (about 25%, I think) that no block will be mined within the next 15 minutes.
Maybe not to the customer, but it matters in general because Bitpay and others are pushing Bitcoin Cash as a solution to this on the basis that it has lower fees because of its bigger block size (also because no-one is using it, so the blocks are almost always far below the Bitcoin block size). They likely stiffed him on the transaction fees for the return transaction too; the Bitcoin client's recommended fees are already on the conservative side, and they charged more.
That's usually used as justification for the customer blaming the company they were doing business with. (Which makes a lot of sense; it's that company's job to insulate the customer.) Weird to see you using it the opposite way.
I'm admittedly green when it comes to the day-to-day workings of Bitcoin but put some money into it on Coinbase a few weeks ago.
I decided to see how easy it was to use for transactions, so I bought $2 of credit with an online service. But the payment service this other company used charged a $6 fee of some kind, and there was also a $8 'transaction fee' for the Bitcoin itself, meaning it cost around $16 to get my $2 of credit :-D I decided I'd probably stick with it as an investment instead of a currency..
I really don't see the value of using Bitcoin as a currency either. The transaction fees are absolutely ridiculous and confirmations take hours, sometimes days. I bought some a long time ago and was trying to move them around a couple weeks ago and it was an absolute nightmare.
Ponzi scheme / not everyone is "on the boat" yet. If Bitcoin does hit a million dollars one day, I'd be kicking myself, so have a small "I'm OK with losing this" amount invested now.
I have paid ~180$ dollars of fee couple of days ago while sending around 600 dollars. Tx was around 6 KB though. I was using wrong client for transaction (I had newest bitcoind-qt with fee set manually and older client with automatic fees) and fee was automatically set to that amount.
Also like I said removal of net neutrality regulations means ISPs esp big ones can kill Bitcoin by blocking the default port used by the Bitcoin client and ISPs can more than just blocking a certain port. ISPs can identify and block all P2P traffic (anything that is not being sent or received to/from an approved central service) and do it in the name of protecting MPAA member revenue or whatever blanket execuse like killing off encrypted p2p communication like Signal et al)