Live data from Hacker News

The True Cost of Bitcoin Transactions

moneyandstate.com

61–70 of 121 posts

Re: The True Cost of Bitcoin Transactions

#61
post #57
post #42

Earlier quoted context omitted.

SegWit is a block size increase. Pretty much every developer in the bitcoin community supports SegWit.

> Pretty much every developer in the bitcoin community supports SegWit. Only in the censored outskirts. I recommend everyone to read John Blocke's articles: https://medium.com/@johnblocke/the-importance-of-clear-defin... https://medium.com/@johnblocke/its-not-the-censorship-resist...

- 105 businesses and projects from the Bitcoin space support SegWit and are working on implementing it in their products: https://bitcoincore.org/en/segwit_adoption/

- 54 bitcoin developers signed the "capacity increase roadmap" published by Bitcoin Core: https://bitcoin.org/en/bitcoin-core/capacity-increases

- 45 companies and individuals signed in support of Bitcoin Core: https://bitcoincore.org/en/supporters/

- 85% of the nodes on the network are running Bitcoin Core: https://coin.dance/nodes/share

All of that due to censorship in one subreddit, while there are multiple other forums that people talk in? I have to say, that's quite impressive.

Re: The True Cost of Bitcoin Transactions

#62
post #38

Earlier quoted context omitted.

As the value of Bitcoin grows, transaction cost grows relative to other currencies. Really transaction costs in strictly btc/byte have decreased. Pretty much everyone agrees the block size will need to grow at some point, including core devs. It is the current proposed method of introducing this change (via hardfork) that is questioned and scrutinized.

There is at least one prominent core dev that recently seriously proposed _decreasing_ the block size to 1/3rd of what it is currently. The problem is that the block size needed to be increased last year. Agreeing that it needs to be increased at some unspecified point in the future minus any specifics is just a stalling tactic.

Yes some devs believe there is centralization pressure of mining blocks caused by the propogation delay of 1MB blocks. Further increasing the size of blocks would thus increase centralization pressure. Changing any number of variables leads to emergent properties which change mining behaviors. Game theory needs to be considered before tweaking the consensus protocols of Bitcoin. The open source nature of Bitcoin allows for many opinions and critisms and hopefully many more proposals for change in the future.

Re: The True Cost of Bitcoin Transactions

#63
post #60
post #54

Earlier quoted context omitted.

> partly because these off-chain networks would quickly form large central "hubs" which would obviate many of the benefits of Bitcoin The Lightning Network is open-source and decentralized. It has no "hubs", but rather just peers that route payments to each-other using a payment routing algorithm. Lightning has no counterparty risk, as no one can ever steal your bitcoins and you're always in full control. The best wa…

What do you mean that Lightening has no counter party risk? It's my understanding that you have to constantly monitor the Bitcoin network as long as a payment channel is open to make sure your counter party doesn't try to cheat you. I also don't buy that hubs won't tend to centralize since hubs with channels open with a lot of other peers will naturally be central points.

Yes, you have to watch for cheating attempts, but you get all your money back plus a bonus if you catch someone doing that. If you're doing that properly (and there's no reason you won't), then there's no counterparty risk.

Edit: also, you can outsource this task to someone else, who'll take a small fee out of your bonus if he catches the cheating for you (and only if he does).

Re: The True Cost of Bitcoin Transactions

#64
post #52

What they did to Mike Hearn was a disgrace.

Who is "they" and what did they do to Mike Hearn? (I know Hearn left the Bitcoin community and pronounced it a failed experiment, and I know there was some harsh criticism for that assertion...but, did it go beyond that?)

Re: The True Cost of Bitcoin Transactions

#65
post #54

Earlier quoted context omitted.

> partly because these off-chain networks would quickly form large central "hubs" which would obviate many of the benefits of Bitcoin The Lightning Network is open-source and decentralized. It has no "hubs", but rather just peers that route payments to each-other using a payment routing algorithm. Lightning has no counterparty risk, as no one can ever steal your bitcoins and you're always in full control. The best wa…

How do you counter the description of the network in this article? It seems like de-facto hubs will form out of necessity to avoid creating a channel on the fly, which requires getting a transaction committed to the blockchain. https://chrispacia.wordpress.com/2015/12/23/lightning-networ...

> Routing paths are much harder to find when values are considered.

Hard, yes, but definitely possible. There was some great work done on P2P routing for Lightning by the developers at BitFury.

http://bitfury.com/content/5-white-papers-research/whitepape...

> We could end up making more on-chain transactions ... Well, it will have to close one of its existing channels. So the process for making a transaction when your wallet can’t find a route is: 1) Make an on-chain transaction closing out an existing channel. 2) Make an on-chain transaction opening a new channel with the payee.

This is not true. You can close an existing channel and open a new one in a single transaction.

> The vast majority of users will be offline.

Some will, some won't. Some will set this up on a VPS, some will use hosted services, some will be professional liquidity providers (early adopters with lots of coins?) that have a machine dedicated to this.

He's making a prediction that he cannot really support in any way.

> Channels cannot be created on-the-fly.

RBF is opt-in, only if you mark your transaction as such. If you don't want RBF, don't use RBF. His assertion that RBF is somehow required is not true.

> Recipients have to be online.

Yes, they do. This is perfectly fine for some use-cases, and not good for others. For use-cases where the recipient is offline, people can always resort to on-chain transactions.

I'm not sure what this has to do with hubs, though.

Basically, he's making tons of assumptions and guesses (some of them based on incorrect/outdated technical information). You should go and read-up yourself on the technology and the improvements the developers are coming up with.

Re: The True Cost of Bitcoin Transactions

#66
post #58
post #2

There is a small faction of the Bitcoin community working exceptionally hard to prevent any block size increase. I find their motives really baffling. They had some legitimate arguments a few years ago when discussion of this issue first started but those have all since been superseded by improvements in the protocol like xthin. They now resort to distasteful tactics by running anyone out of town that even so much as…

You're painting a very unbalanced picture. > There is a small faction of the Bitcoin community working exceptionally hard to prevent any block size increase. This small faction is composed of nearly ~all the technical experts we have in the Bitcoin space, over 100 businesses and projects that support SegWit, the majority of bitcoin users that I'm personally familiar with, the majority of full-nodes on the network (~8…

You don't deny that censorship is taking place you are just rationalizing it by calling it "moderation". Lets be clear what is going on there goes way beyond what is commonly understood as moderation. They are systematically silencing a large segment of the Bitcoin community.

If your side really had the support you claim the censorship wouldn't be needed.

Re: The True Cost of Bitcoin Transactions

#67
post #53
post #2

There is a small faction of the Bitcoin community working exceptionally hard to prevent any block size increase. I find their motives really baffling. They had some legitimate arguments a few years ago when discussion of this issue first started but those have all since been superseded by improvements in the protocol like xthin. They now resort to distasteful tactics by running anyone out of town that even so much as…

I was sure you're talking about the chinese miners as I started reading your comment... The ones who oppose a block-size increase today are the miners and the anti-Core crowd. The rest of the bitcoin community, including its technical and business community, are pushing for an increase to 2MB blocks in the form of SegWit. And I think the "hostile comments" referred to by the OP are the non-stop personal attacks and t…

Your comment is a good example of the double speak and gas lighting I often see in /r/bitcoin

Re: The True Cost of Bitcoin Transactions

#68
post #66
post #58

Earlier quoted context omitted.

You're painting a very unbalanced picture. > There is a small faction of the Bitcoin community working exceptionally hard to prevent any block size increase. This small faction is composed of nearly ~all the technical experts we have in the Bitcoin space, over 100 businesses and projects that support SegWit, the majority of bitcoin users that I'm personally familiar with, the majority of full-nodes on the network (~8…

You don't deny that censorship is taking place you are just rationalizing it by calling it "moderation". Lets be clear what is going on there goes way beyond what is commonly understood as moderation. They are systematically silencing a large segment of the Bitcoin community. If your side really had the support you claim the censorship wouldn't be needed.

Do you think HN has no moderation?

Every online community has moderation to some degree. The manipulation, voting bots and endless stream of sockpuppet accounts made it impossible for people like me to discuss ideas and proposals, the signal-the-noise ratio was unbearable to the point of stopping productive discussions to an halt.

Yes, moderation sucks. But no moderation sucks harder. I don't really see a better approach to this.

If you have some time, I truly recommend you to read the "Well-Kept Gardens Die By Pacifism" piece on LessWrong:

http://lesswrong.com/lw/c1/wellkept_gardens_die_by_pacifism/

Re: The True Cost of Bitcoin Transactions

#69
post #61
post #57

Earlier quoted context omitted.

> Pretty much every developer in the bitcoin community supports SegWit. Only in the censored outskirts. I recommend everyone to read John Blocke's articles: https://medium.com/@johnblocke/the-importance-of-clear-defin... https://medium.com/@johnblocke/its-not-the-censorship-resist...

- 105 businesses and projects from the Bitcoin space support SegWit and are working on implementing it in their products: https://bitcoincore.org/en/segwit_adoption/ - 54 bitcoin developers signed the "capacity increase roadmap" published by Bitcoin Core: https://bitcoin.org/en/bitcoin-core/capacity-increases - 45 companies and individuals signed in support of Bitcoin Core: https://bitcoincore.org/en/supporters/ - 85…

The censorship isn't just in /r/bitcoin it also happens on the dev mailing list, on the bitcoin.org website, and on the BitcoinTalk forum. BitcoinTalk, /r/bitcoin, and bitcoin.org are controlled by the same person.

Re: The True Cost of Bitcoin Transactions

#70
post #45

Earlier quoted context omitted.

The Lightning Network is not bitcoin. The people who are fighting against block size increase are the same people pushing segwit. While there is nothing inherently wrong with segwit and the Lightning Network, they are ignoring the most important improvement to Bitcoin itself, which would be a pure block size increase.

But SegWit is a block size increase. It allows twice as many on-chain transactions by making the blocks twice as big. This "SegWit vs block-size increase" talk makes no sense to me. https://segwit.org/is-segwit-a-block-size-increase-705df6a87...

The block size increase with segwit is marginal and a side effect. It's a complicated feature that is meant for purposes other than block size increase. Don't obfuscate the issue. I'm talking about a simple tweaking of a parameter to increase block size.
Post reply on HN