Hacker News Reader

Comment by crazypython | Hacker News Reader

A Bitcoin full node only takes 5GB of disk space to run, and 256MB of memory.

[0]: https://github.com/bitcoin-dot-org/Bitcoin.org/pull/3624/fil...

In hindsight, I think most would agree it was a good idea to force the smarter scaling solutions rather than brute-force blocksize scaling (which sooner or later would have hit a ceiling anyways).

The "smarter" scaling solutions still aren't here after years of waiting, fees are hitting all-time highs, and other chains can do >4,000 TPS on layer 1. So no, small blocks weren't and aren't a good idea.

They are here, the publicly known nodes alone on lightning have 1.2+k BTC locked in [1], that's ignoring all the private channels which form the majority of the channels (private channels are the end-user channels which don't route transactions themselves and are not broadcast publicly).

We have easy to use wallets [2], easy ways to run lightning nodes [3].

And if you look at the average transaction value, you can see that the blockchain itself is acting more of a settlement layer rather than "coffee transactions" as it should [4].

1: https://1ml.com/

2: https://phoenix.acinq.co/

3: https://getumbrel.com/

4: https://bitinfocharts.com/comparison/transactionvalue-btc-xr...

the blockchain itself is acting more of a settlement layer

That is a sign of failure.

Becoming the most trusted decentralized worldwide settlement layer is considered a failure now?

Many of the cryptos that claim to scale to thousands of tps on layer 1 are all sacrificing decentralization to achieve it, at which point, I might as well use Paypal/Visa. There's no point in being able to scale to those levels in theory if in practice no one uses them.

> Becoming the most trusted decentralized worldwide settlement layer is considered a failure now?

it is, if the original goal was to be something else.

If you start a marathon and stop to eat the greatest hot dog ever made, it wouldn't be considered a successful run, although you can say "but it was the best!" and be happy about it.

Huh, so every startup thats ever pivoted -- including for example Instagram, AirBnB, and Twitter -- are failures huh? Interesting.

Startups have a duty to their shareholders to make money, whereas Bitcoin has at least a nominal duty to its inventor[0] and its whitepaper.

There's nothing wrong, though, with someone taking the open source code and creating LightningCoin from it, though. That would be the equivalent of a pivot.

[0] http://satoshinakamoto.me/2008/11/02/re-bitcoin-p2p-e-cash-p...

Payment channels were invented by Satoshi and actually baked into the transaction format from day one-- it's why transactions have locktimes and sequence numbers.

Not sure if it can be called a pivot when it was in the original release of the software.

Payment channels aren't in the white paper but they were in the first public release and had dedicated opcodes. That first implementation wasn't very practical nor was it secure.

The fact that modern payment channels are implemented with other opcodes may be a pivot in implementation but not in concept.

the company is successful, the original project is failed. Twitter is a successful company, but Odeo was a failed product.

Bitcoin was supposed to be much more than it currently is, and the "success" of it is a product of continuous goalpost shifting.

it's not a marathon, but a permanent olympics

What is a sign of success, multicasting every transaction in the world and storing it on a public ledger? I don't remember that being in the white paper.

The nice thing about using blockchain for settlement is that (using lightning) you don't actually need to wait for the settlement to clear before you are certain you own funds.

Can you elaborate on your perspective? I must admit that I don't use layer2 solutions and many people that think they are, are not (ie. users of Polygon's Proof of Stake network instead of their Plasma network), but I appreciate the progress on those layer2 solutions and actively support the bridges to them

Layer 2 is more complex (pretty much by definition) but has no countervailing benefits compared to a scalable layer 1 chain.

fees are hitting all-time highs

I just checked https://mempool.space

A low-priority transaction cost $2.36; medium is $4.39 and high is $7.48.

To put this into context: you can send $10,000 worth of BTC anywhere in the world in an hour for $2.36 right now.

A bank wire transfer for $10,000 is going to be at least $35; often it's more, depending on which country you're sending to and if you have to use an intermediate bank to get to the bank you're ultimately are attempting to reach.

Bank holidays, weekends, etc. don't apply to bitcoin.

My bank does those wires for free…

International SWIFT wires? What's your bank?

My Schwab account does international wires settled in USD or in a number of foreign currencies for free. (The official fee is $15 but it’s always been refunded for me.)

"Free". In the case of any currency conversion - you'll likely be silently stung a single digit percentage during conversion.

Check rates quoted on the final statement versus those prevailing at that time.

For a few limited cases of going USD -> USD (in foreign jurisdiction), and the USD is not converted to anything else ever, there may be a net win.

In all other cases (the majority), you, or the receiver will at some point be paying far more than the wire fee for any transfer over a grand or so.

I didn't do wires with Schwab but I'll trust it's cheaper than your average bank when it comes to conversion rates. (They do refund ATM withdrawal fees for international ATMs)

Schwab forex exchange really is without fees. It’s done at the current forex rate with no basis points taken. I’ve checked my transfers against the forex rate for the day.

Schwab operates these retail banking services as a loss-leader for their investment products.

Happy to be wrong on this.

I've never experienced a bank that hasn't silently gouged on forex, and this is the first I've even heard of one that didn't.

Definitely good to continue to be vigilant about such claims.

As for BTC, I wouldn't use it for anything other than a store of value - there are far better crypto options for transferring value. Some cost fractions of cent and take seconds.

Others cost single-digit dollars, but are fiat-pegged so there's no volatility risk at all.

As the other @garmaine mentions, the currency conversion is at mid-market rates, no fees. I've compared the rates to Wise and other options and it's far less cost, and certainly less cost than the median tx fee of BTC by itself, let alone slippage or fiat conversions or exchange fees. Anyone who thinks BTC has any advantage as a medium of exchange I'm convinced has never actually used it/compared it to existing options.

"Free" or in reality we will get our money one way or the other.

Cheap international wires are $25.

Those transaction cost estimates are extremely volatile. I recently tried to pay 50 sat/vB (~$4) for a transaction on a Monday and it didn’t clear until Saturday. Unfortunately mempool.space doesn’t seem to publish historical data, but it seems that weekends do affect Bitcoin, in that transactions are significantly cheaper.

I payed $0.5 in fees yesterday (900 satoshis) and it took a couple of hours to clear

Just so we're not talking past eachother.

You cannot send $10,000 anywhere in the world via Bitcoin for $2-7, you have to first convert the $10,000 to BTC at a local exchange, wait 3 days, pay 1-2%, suffer slippage, pay $2-7, wait an hour, pay 1-2% at the remote exchange and wait for the money to deposit into a bank account. This is true because you can't spend Bitcoin for goods and services - generally speaking anyways. Bitcoin in this context is just the intermediary unit which is elided in a wire.

Re: wires, domestic US wires are offered free of charge by many institutions, and are instant during regular business hours. Obviously delays apply outside. For reference, an ACH transaction costs banks $0.002 in bulk to the depository institution. A FedWire costs $0.033 in bulk to the depository institution. [1]

Transfers outside the US cost more and take longer because of AML and KYC.

Not to mention that the move in the US from ACH to RTP makes ~free and instant domestic transfers 24/7. No blockchain needed. Because of course there isn't, the current system was based on policy not technical limitations of MySQL. [2]

[1] https://www.frbservices.org/resources/fees/wires-2021.html

[2] https://www.jpmorgan.com/solutions/treasury-payments/insight...

    >> you can send $10,000 worth of BTC anywhere in the world 

    > You cannot send $10,000 anywhere in the world via Bitcoin

You are citing currency exchange costs that would also be applicable to EUR/JPY/GBP/...

This is why the post you responded to said "worth of BTC".

Bitcoin fees have ranged between $0.79 and $33.00 within the past week (feerates between 10 sat/vB and 250 sat/vB) [0].

There have been periods where the prevailing feerate has remained over 150 sat/vB ($12 - $24) for 24 hours.

And unless you're already in $10K of BTC, you will lose exchange fees and are subject to the forex (equivalent) rate. Your receiver will have the same burdens.

Wire transfers/SWIFT/FedWire etc are effectively instantaneous, the fees are 100% predictable, and they are accepted everywhere worldwide for all legitimate business. As you note, they can be inconvenient or impossible on overnights, holidays, and weekends.

I'm not disagreeing with you -- just noting that the quoted Bitcoin fees at any point in time are not reliable, and that the whole process is more complicated than it might appear.

[0] (background for other readers) Bitcoin fees are a function of the transaction size in (virtual) bytes (minimally either ~140 vB or ~240 vB, depending on the type of addresses used), multiplied by the feerate in satoshis per virtual byte. Converting to USD, you have to consider the BTC-USD exchange rate which has been bouncing around $55K lately. So, e.g.:

  240 vB * 250 sat/vB == 60_000 sat
  60_000 sat == 0.0006 BTC          (100_000_000 satoshis per BTC)
  0.0006 BTC == 33.00 USD           (at $55_000 USD per BTC)

Right now (9AM EST) a low priority txn costs $0.49, medium priority costs $0.57, and high priority costs $0.66.

Most payments– imagine hiring a contractor or buying a Starbucks gift card– don't need to go through instantly.

50,000 TPS for Solana

> other chains can do >4,000 TPS on layer 1

read: other chains are centralized databases that have no business being blockchains in the first place and can be replaced by single mysql instance.

the trick is not to have high TPS, bitcoin could have unlimited TPS too, it's just a single line of code change. the trick is to have a decentralized system that functions at saturation on commodity hardware.

the conservative minds prevailed during scaling debate in 2015-2017, creating selection pressure for scaling solutions that optimize limited resource - chain space, rather than populist simplistic "solutions" pushed by cheap propaganda slogans like "we can do this much TPS!".

> read: other chains are centralized databases that have no business being blockchains in the first place and can be replaced by single mysql instance.

This, too, has been a thought of mine, but I'm not exactly sure how I would block diagram the 'locking' mechanism for the MySQL instance.

I've come to believe the locking mechanism is the nonce produced to sufficient solution parameters that appears to use the difficulty of finding said solution as its defensibility.

So how do you get the 'strength' of the miners throwing ExaHashes at a solution with a single instance? We could easily snapshot the DB and sign them, however, the point of failure is no longer in a 50% attack, but in losing said key... which intuitively feels far less secure?

Curious to hear your thoughts

locking is needed to order transactions, mysql already has acid transactions. i use mysql metaphorically to describe a single centralized database protected by single entity that controls all the writes. we already have such payment systems: visa, mastercard, paypal, venmo, etc.

blockchain and miners only make sense if you need and actually maintain decentralization. if you don't and/or can't - miners (and validators in PoS systems) are useless overhead.

Thank you, I had never heard of ACID -- yeah, centralized vs. decentralized becomes fairly philosophical (eco vs. democratized arguments, etc).

To build on the discussion, I'm more amazed at blockchain's capabilities as a cooperation engine outside of the normal channels. To that end, I'm really surprised we haven't seen significant attrition in the current legal system to smart contract systems. I guess the lack of adoption more highlights just how 'customized' a 'standard' contract or dispute is in the real world.

blockchains are great in environments where parties can't audit and trust each other but need write access to the same database. so far it remains an open question whether blockchains will ever be useful for anything other than settlement ledger (and things you can build on top of that).

i don't believe the hype of using blockchains to track some logistical or supply chain data will prove useful simply because all these international corporations already have a system to resolve conflicts and enforce contracts - law.

Right -- many friends are lawyers and they basically say law is a slow grinding gear. So, my naive thought is that any improvement in speed should be a deterrent for the mischievous.

And thinking out loud, it sounds like if blockchain were used to run financial operations for a company, we could make the infamous audits for Luckin Coffee's and GSX's a thing of the past. Or at least after one mistake (the LC coupon issue was an interesting hack to avoid detection), update the contract, then all future instances are robust to the same issues.

GAAP Rules and Arm's Length Transactions could be factually monitored too... interesting

i'm not saying there will never be a valid use case for blockchain beyond bitcoin, i'm just skeptical about the hype of recent years where it's applied left and right to everything. so far all the use cases i've heard of could be replaced with a centralized database maintained by a consortium of interested parties.

so does taproot pave a way that doesn't need lightning?

Lightning isn’t going anywhere, or at least payment channels don’t. Taproot, aggregation and adaptors will make all sorts of scripts more efficient.

It's not black and white. Would 2MB blocks (and hence 10GB of disk space) be a worthy trade off?

The problem I see is bitcoin devs refusing to be pragmatic. Segwit is just an accounting trick.

I believe the point of segwit is more than accounting. Essentially these signatures /spend-scripts are pruneable once the blocks they are in are old enough.

After all, if a transaction had an invalid spend script, it would not have gotten 100 blocks worth of confirmations.

Bitcoin has checkpoints: https://bitcoin.stackexchange.com/questions/1797/what-are-ch... even for normal P2PK transactions.

Checkpoints don't do what you think they do.

They only exist today as a mechanism to prevent nodes from being flooded by low difficulty fork blocks, forking off back before height 230k, because the initial difficulty of Bitcoin (2^32 hash operations per block) is too low relative to multiple TH/s asic mining devices.

is there any ongoing work to have utxo set commitments? if not - why?

I'm not sure, I haven't been actively involved in development for a couple years.

There were a couple distinct activities. One is the rolling utxo hashes, which has no major engineering hurdles, and can allow a compromised security "bootstrap from a utxo set".

The other are schemes that allow nodes to not have the utxo set but still validate-- these have historically had unfavorable IO costs, and the bandwidth storage tradeoff hasn't seemed that appealing-- e.g. would you find reducing storage from 10 GB to 1MB but at a cost for increasing bandwidth 10x to be appealing? In some applications it would be, not others.

I believe work related to both has been ongoing, however.

> compromised security "bootstrap from a utxo set"

could you elaborate what's compromised about including a sha256 of utxo set in every block and allowing users to choose how far back they want to bootstrap from?

isn't it strictly better than current situation with assumevalid?

Depending on a utxo state in blocks is effectively the SPV security model, -- it's an utter blind trust in miners to set the value honestly. Something which is only theoretically sound on the assumption that someone else is checking.

If you're happy with the spv security model-- perhaps you should be using SPV? :) This is a little trite I know, because it's not quite identical because of the "past": but the vast majority of the sync time is in the last two years in any case, and practical considerations mean you wouldn't be able to just arbitrarily choose how far to sync from (as you need to be able to get the utxo set as of that height).

In the ethereum world effectively almost all synchronization is done using 'fast sync' which is essentially the committed utxo blindly trust miners model. Performance and storage considerations mean you can't go back more than a tiny amount of time (I believe its normally 4 hours). Many commercial entities operate with multiple nodes and if they detect they've fallen behind they just auto-restart and fast sync to catch back up. Effectively this means that if miners commit invalid state they'll just blindly accept it after a couple hours outage.

All assumevalid is doing is asserting that the ancestors two weeks back and further of a specific block hash all have valid signatures. When you get a setting there as part of the software you're running you're assuming that the software isn't backdoored (e.g. because of a public review process, or your own review). Assumevalid is strictly easier to review than pretty much any other aspect of the software integrity. E.g. there are 100 places where a one character change would silently bypass validation completely. Reviewing AV simply requires checking that the value set in it is an accepted block in some existing running node. AV as implemented also requires the blockchain to agree and have two weeks of work ontop of it, so it's just in every way harder to undermine validation by messing with it than changing the code some other way.

On a technically pedantic point. It takes a minute or so to sha256 the UTXO set, so doing literally what you suggest would utterly obliterate validation performance. (fortunately rolling hashes accomplish what you mean without the huge performance hit.)

thanks for detailed response!

> Depending on a utxo state in blocks is effectively the SPV security model, -- it's an utter blind trust in miners to set the value honestly

if it was hardforked in as part of consensus protocol - miner's wouldn't be able to set invalid utxo set hash any more than they are able to "produce" blocks with invalid signatures, or am i missing something?

as for storage and performance, maybe it would make sense to take the performance hit of maintaining a persistent immutable set such that you would be able to travel back as far as you like with minimal overhead.

do you know of any active PRs/branches where utxo commitment work is/has been happening?

They can produce blocks with invalid signatures, but they're stopped by nodes validating. But if instead of validation nodes skip blocks and use a commitment to the state, then they're not validating anymore. How that fails is why I gave the ethereum example, because I think the security has actually practically failed there-- just not been exploited yet.

> as for storage and performance, maybe it would make sense to take the performance hit of maintaining a persistent immutable set such that you would be able to travel back as far as you like with minimal overhead.

The cost of supporting that arbitrarily would be extremely high over and above the cost of having the complete blockchain. I don't see why anyone would choose to run a node to serve that. I certainly wouldn't-- it's obnoxious enough just to have an archive node. But having some periodic snapshots would probably be fine ... but not that many since each would be on the order of 7GB of additional storage.

No, there is work ongoing I haven't been following closely. Sounds like you're more interested in the assumeutxo style usage, so search for that and muhash.

2 MB doesn't solve the issue, does it? Bitcoin is having exponential growth. You don't go for a hard-fork to just "double" the capacity. If the hard-fork was promising x100-x1.000 capacity, I'd imagine it being less contentious.

> Bitcoin is having exponential growth

in number of transactions? I do not think so, and according to the first few results I've found[0][1] it's not true.

[0] https://www.statista.com/statistics/730806/daily-number-of-b...

[1] https://bitcoinvisuals.com/chain-tx-day

yes, in number of transactions. just realize that if bitcoin went unlimited, most of the altcoin activity would be happening on bitcoin chain. blockchain space being limited resource priced out economically un-viable activity into shitcoins.

I linked two sources that show the number of transactions is not increasing exponentially.

What source do you base your claim that they are?

did your sources include all the activity on all of the altcoins?

Not sure what an accouting trick is, but it might be interesting to note that Bitcoin right now averages 1.4MB blocks.

Would 2MB be preferable? Would it be useful? Just the same magnitude of transactions that visa settles would require slightly above 500MB sized blocks, and that's without any more sophisticated transactions such as atomic swaps, which could potentially be useful.

In hindsight it should be obvious that these "smarter" scaling solutions have utterly failed to keep Bitcoin functioning as peer-to-peer electronic cash, like the original intention was.

This is factually incorrect. And, this sort of misinformation is one of the reasons people don't like the crypto-hype.

Perhaps a pruned node can get somewhere in the area of sub-10G, but a "full node" is actually at around 328G: https://www.statista.com/statistics/647523/worldwide-bitcoin...

A pruned node is a full node. A full node is any node that is fully validating. A pruned node is fully validating;

"Full nodes download every block and transaction and check them against Bitcoin's consensus rules." (https://en.bitcoin.it/wiki/Full_node#Archival_Nodes)

Pruned nodes do just that.

The blockchain data structure means that once verified, you don't need to store old blocks. You only need the most recent blocks to verify new ones.

The nodes you're talking about, that store the entire blockchain, is called an archival node.

Anyway, encouraging people to install full nodes, pruned or not– which enforces the rules– improves Bitcoin's decentralization.[0]

[0]: https://bitcoin.org/en/bitcoin-core/features/validation

It should be clarified that running a node isn't worthwhile as a "set it and forget it" contribution. If you're not actively using it for something, it will just silently break if the network does something against the rules and does nothing to improve decentralization. It doesn't even really matter from a software signalling perspective, because Sybil attacks are easy from someone with enough money to run lots of nodes.

At best it's a gateway drug to get people more involved.

Interestingly, running a lightning routing node actually is a way an individual can run a full node to not only generate some fees to cover the cost, but actively and consistently participate in the cyber economy and have a marginal voice in enforcing the rules. The nodes you have channels with are incentivized to care about your vote if they want to stay connected to you.

Wait what? I thought a full node needed 200GB+… Since when are the requirements so low?

“ It is possible to configure your node to to run in pruned mode in order to reduce storage requirements. This can reduce the disk usage from over 350GB to around 7GB.”

From [1] in the parent.

Ah, so it's 5 (7) GB for a pruned node! That makes sense. But then the comment is inaccurate:

  A Bitcoin full node only takes 5GB of disk space to run, and 256MB of memory.

Should instead read

  A Bitcoin pruned node only takes 5GB of disk space to run, and 256MB of memory.

A full node may still be required for certain use setups (such as when used by lnd – a Lightning Network daemon).

It is definitely possible to run a lightning node using a pruned backend. The official implementation doesn't "support" it, but that is only because some additional thinking is required on the end user's part. It is really just a matter of implementing the code to instruct the backend to get the pruned, but still needed by lnd, transactions - and the work is happening:

https://github.com/lightningnetwork/lnd/pull/5154

The pruned/archival distinction is orthogonal from the full/simplified categorization. A full node that pruned spent transactions is not a contradiction of terms.

Edit: a “full” node is one which fully validates blocks, meaning it checks that blocks meet all of bitcoin’s consensus rules. All data in bitcoin is either validated once the first time it is seen (like witness data), or at most twice (an output and its later spend). Pruned nodes garbage collect this data once it can provably never be referenced again. This does not diminish the nodes ability to check bitcoin’s consensus rules, so it is still a full node.

It is correct in the bitcoin jargon, but it kinda goes against the common usage of "full".

If you have a "full" version that is missing some info, people will be confused.

Full node is an abbreviation of "Fully validating node", which was a term created in contrast to "simplified payment validation" (which basically means perform no validation yourself and trust that the majority of hashpower is being honest due to pressure of other participants validating).

If you define the term "full" like that, then we need a word for a node which stores all the history.

The term is archive node, which has been in use since history pruning was implemented.

Archive node implies non-pruned and txindex enabled?

One thing that made me laugh regarding the Ethereum “archival node” semantics debate was that equivalent functionality (immediate lookup of any transaction by address) in Bitcoin requires an additional index, like ElectrumX. Apparently many of the loudest Bitcoiners would benefit from understanding the distinction between a block explorer and a full node.

no, txindex doesn't do anything network visible at all. It's just a wallet-ish feature.

You only need to store the most recent blocks for security to verify new blocks. 5GB– the minimum Bitcoin Knots, a variant of Bitcoin Core, allows 3 days of blocks. A chain rewrite/51% attack is unlikely to last 3 days because of the probabilistic grantees.

So the state for all addresses ever used fits in those couple gigabytes? Plus of course full state for a few days for longest-chain purposes, like you wrote.

I thought the majority of the hundreds of gigabytes consisted of dormant and throwaway addresses that still have some value on them, but it sounds like I've got the wrong impression and by removing transaction history for empty addresses and other historic block data, it's only a few gigabytes?

Bitcoin nodes only need to work with the state of existing spendable coins.

The need to track previously used stuff in some other systems to prevent transaction replay is a design flaw that Bitcoin avoided.

The vast majority of the blockchain data is digital signatures which you don't need anymore once you've validated them (except to help other people sync up).

Keep in mind most lightning implementations require a full node to function properly.

The current Bitcoin Core on Windows stores 366GB of data on your local drive excluding the app files. Source: Looking at the folders on my PC right now.

Were we getting low on disk space?

https://commons.m.wikimedia.org/wiki/File:Hard_drive_capacit...

It’s perverse you are proud of that and chose a tiny hard drive size over becoming actually useful and doing more than seven transactions per second. Time marches on, technology improves, but Bitcoin is proud they can run a node on a computer from 1995.

Decentralization/trustless aspect of Bitcoin is the utmost important thing, without those, there's no need for it, we can just use fiat.

Once you've accepted that premise, the next question is how do you achieve the most decentralization? The answer is by having the most nodes. How do you get people to run nodes? Make it super cheap to run. It's simple really, people are not paid to run nodes (miners != nodes). It's not about storage space, you also have to consider network latency and propagating those blocks across a large adversarial network.

That! I would never consider running an Ethereum node but btc is well within range and is something that I’m looking at

I bought a second 10TB harddrive just to be able to run a full eth node, right now even fast sync of eth requires like 400GB+, full archives sits at 6TB+ [1]. When infura went down, the whole network had issues [2]. I'm really hoping the eth2 will somewhat improve the situation, but we'll see.

1: https://ethereum.org/en/developers/docs/nodes-and-clients/

2: https://cryptobriefing.com/infura-outage-sparks-debate-over-...

Nodes that neither mine nor have economic weight (e.g. exchanges) just slow down the network; they don't contribute anything.

The idea is that everyone should be able to verify the blockchain. If you can't verify it yourself, you have to trust someone.

Reply on news.ycombinator.com