Live data from Hacker News

The True Cost of Bitcoin Transactions

moneyandstate.com

101–110 of 121 posts

Re: The True Cost of Bitcoin Transactions

#101

Earlier quoted context omitted.

The Core devs signed an agreement with these miners a year ago in Hong Kong, and the agreement was broken. Here are the consequences. Clearly, politics won't be ignored- or Segwit would be on track for activation.

The part you're missing is that Bitcoin is totally fine if it never changed from how it is today. Anonymity will come via Tumblebit. Lightning network can already work even without segwit. Segwit never getting activated may even be a good thing. It will show everyone that Bitcoin has crystalized and can never be changed via petty human emotion. This was always Bitcoin's true selling point and we may be about to demon…

Not at all. Like many in the space, I've had to consider and come to terms with the fact that this might be the best version of Bitcoin we have, forever.

But that's not politics being ignored- this is still a group of humans who couldn't come to an agreement after much politicking. That's politics being exhausted.

I do share your optimism that we have a system that can survive gridlock. It just won't fulfill much of its early promise.

Re: The True Cost of Bitcoin Transactions

#102
post #91

Earlier quoted context omitted.

> for instant & nearly free txs via the Lightning Network It's amazing we're putting all our hopes on a technology best labeled as vaporware. You make it out like it's readily available but the fundamental problem of decentralized routing hasn't been solved and it may even be unsolvable. The simple fact is that blockstream is pushing segwit precisely for it being a necessity for lightning network, not because it's a…

This political argument that it's all just a plot by Blockstream is what is causing the division where the technical benefits of segwit are clear to anybody who knows what they are talking about. As soon as it became about people and BS conspiracies instead of technical rational solutions it was only going to end up in slagging match.

You're dodging my technical argument well yourself. Segwit implemented as a soft fork isn't clearly full of benefits. But it seems you're just appealing to authority.

Re: The True Cost of Bitcoin Transactions

#103
post #94
post #90

Earlier quoted context omitted.

Sigh. > Comments are not being deleted on r/bitcoin for expressing views, discussing ideas or debating proposals. Yes they are. > Comments that promote the use of alternative clients that attempt to alter the bitcoin protocol rules prior to building consensus around the proposal, however, are. Comments promoting non-core clients are. Segwit is a disruptive change to the protocol and yet is has been allowed since day…

> Comments promoting non-core clients are [being removed]. No, they are not. Promoting alternative client software that is compatible with the Bitcoin protocol is definitely allowed. btcd, NBitcoin, Bitcoin Knots, Toshi, Haskoin, bcoin, Bitcoin-S and pynode are all allowed, because they're all compatible with the protocol are not trying to forcefully deploy an hardfork that has no consensus. > how are you supposed to…

> trying to forcefully deploy an hardfork that has no consensus.

This doesn't make any sense. By definition a hardfork can only be successful if it has consensus.

> Discussion of ideas and proposals is not censored.

Keep deceiving yourself.

> All in all, people seem to agree with the moderation policy of r/bitcoin. Everyone are well aware of these policies, yet it is still the most popular bitcoin forum.

The logical fallacy is strong in this one.

> It was never meant to be used to decide on the protocol rules and the validity of chains.

Wrong again, that's the whole point. Why am I arguing with someone who obviously doesn't understand how bitcoin works and openly support censorship? Just a waste of time.

Re: The True Cost of Bitcoin Transactions

#104
post #102

Earlier quoted context omitted.

This political argument that it's all just a plot by Blockstream is what is causing the division where the technical benefits of segwit are clear to anybody who knows what they are talking about. As soon as it became about people and BS conspiracies instead of technical rational solutions it was only going to end up in slagging match.

You're dodging my technical argument well yourself. Segwit implemented as a soft fork isn't clearly full of benefits. But it seems you're just appealing to authority.

I didn't write the and test code myself so you can label that as appealing to authority all you like but I have looked into it and understand the benefits of moving the witness to a subtree of the merkle root so that it can be dropped when it is no longer needed as well as the other changes that are included in the update that allow further soft fork changes enough to see the benefits. I don't just accept someone saying it is good or bad.

Can you explain why such an obvious refactor that is backward and forward compatible isn't a clear benefit?

No it isn't sufficient and won't instantly increase the transaction throughput but the the arguments against it that I've heard are weak and almost all political and could also be argued as appeal to a different authority.

There are two visions of what people see as scaling and are pushing for, on-chain and off-chain. Segwit helps both so being against it can only be politically motivated.

Re: The True Cost of Bitcoin Transactions

#105
post #81

Earlier quoted context omitted.

The issue of propagation delays with bigger blocks was fixed with xthin blocks (aka: compact blocks) months ago. That is no longer a valid reason for limiting the block size.

There is very limited technical documentation on xthin so it is hard for the community to accept and test it. If Bitcoin were to implement xthin (or an alternative proposal such as compact blocks) it would be much better to release outside of the block increase. again the main contention is the mechanism for change that the Bitcoin unlimited enthusiasts want to impose, a contentious hard fork And to clarify, the soft…

You are just spouting false propaganda now. The Core equivalent to Xthin, "Compact Blocks", has been released in Bitcoin Core since version 13.0.0

Re: The True Cost of Bitcoin Transactions

#106
post #83
post #79

Earlier quoted context omitted.

Yes, you absolutely have to trust the service. If I have a channel open with Alice and she wants to cheat me but I've out sourced my monitoring to Bob Alice only needs to pay off Bob to go along with her cheating me. I have to trust Bob not to collude with Alice. In Bitcoin I don't have to trust anyone. Surely you can see that there is a difference in the two models.

You can have as many Bobs as you want, which can all function at a very low cost and compete for users with low fees and high service quality. I can easily imagine registering your transactions to tens of different service providers, making it quite impossible for Alice to pay them all of (or even know who they are).

How do you know bob didn't setup many nodes to perform a sybil attack on you? You don't.

Re: The True Cost of Bitcoin Transactions

#107
post #88
post #56

Earlier quoted context omitted.

> With a bigger block size what hardware constraints begin to appear? Mostly it is an issue of disk space and network bandwidth. right now a 1 MB block is produced every 10 minutes. That has to be transferred over the network to every node and each so called "full node" has to store that block. The total size of the Bitcoin block chain for all time is currently ~100GB and grows 1 MB every 10 minutes under current con…

> This whole stink started because some guy who happened to have a ton of BTC was upset that people running full nodes didn't get a cut of any of the transaction fees. What? Who? > Today, the main company that is pushing the Segwit / small block agenda hopes to push everyone to their off chain lightening network where they can collect the fees instead of the miners. Lightning is open-source and was invented by Lighti…

>What? Who?

Mircea Popescu, He is the original guy who started promoting the idea that it was a mistake to raise the block size unless some incentive to run a full node was added to the system. I don't think he actually supports segwit either, he thinks soft forks are crap. He is the original voice in opposition to block size increases though and many people listen to him.

http://trilema.com/

A lot of people disagree with your characterization of how lightening networks will play out. Since they don't really exist in real world usage yet hard to prove one way or the other.

Re: The True Cost of Bitcoin Transactions

#108
post #102

Earlier quoted context omitted.

You're dodging my technical argument well yourself. Segwit implemented as a soft fork isn't clearly full of benefits. But it seems you're just appealing to authority.

I didn't write the and test code myself so you can label that as appealing to authority all you like but I have looked into it and understand the benefits of moving the witness to a subtree of the merkle root so that it can be dropped when it is no longer needed as well as the other changes that are included in the update that allow further soft fork changes enough to see the benefits. I don't just accept someone say…

That's good!

I found this article describes the problem well: https://medium.com/the-publius-letters/segregated-witness-a-...

I'm not against segwit but I and many other have problems with segwit as a soft-fork. The push for a soft-fork segwit seems to be politically motivated.

> Can you explain why such an obvious refactor that is backward and forward compatible isn't a clear benefit?

If seen as a blocksize increase it isn't backwards compatible as old transactions will not get the benefit. It is also not transparent as all wallets needs to be updated to support the new transaction format. No such extra effort is needed for a blocksize increase.

It is in fact necessary to push for on-chain and off-chain scaling, nobody is against that. The position for "big blockers" has been the same for years: we need actual bigger blocks. See: https://medium.com/@johnblocke/the-importance-of-clear-defin...

Re: The True Cost of Bitcoin Transactions

#109
post #86
post #10

Earlier quoted context omitted.

Based on what? Can you name a single dev that expresses support for bigger blocks that hasn't been systematically ridiculed and excluded from Bitcoin Core development by the small block crowd? It isn't even possible to get an accurate perception of Bitcoin Unlimited support from reading the traditional Bitcoin discussion forums like /r/bitcoin because there is ZERO tolerance for discussion of bigger blocks unless it…

That's a false premise. There is a block size increase when segwit activates. The debate is mostly if we should have a hard fork as well as (or even instead of) a soft fork. I think most developers are rightly scared of a hard fork, especially as we've seen what happened to Etherium lately. There was double spending as every node was not perfectly aligned with this. And then, contrary to expectations, the old chain s…

The ETH / ETC situation was only possible because ETH has a much smaller block time than Bitcoin and the difficulty re-target happens every block instead of every 2016 blocks. The upshot for Bitcoin is that any chain with a minority of hashing power will die off.

Dev's are just FUDing to keep control and scare people.

Re: The True Cost of Bitcoin Transactions

#110

The "average" cost of a Bitcoin transaction is just that, the average . It's not (part of) the true cost. The "true" cost is specific to the transaction. The last time I sent around some Bitcoin, it was around 20$ worth and the fee was whatever the client recommended me. It didn't amount to anything near the average. Why would I care about the average?

[deleted]
Post reply on HN