The senatorial governance of Bitcoin: making (de)centralized money • Hacker News Board

Re: The senatorial governance of Bitcoin: making (de)centralized money

#101

Post by koonsolo » Tue, Jan 07, 2020, 6:14 AM UTC

nytf3 wrote: post #99

tezos is attempting to solve this by incorporating on-chain governance - its dPoS and has a code deployment mechanism with a long voting process (multimonth). They have done 2? upgrades now and quorum seems to be ok so hopefully they can keep up voting % i still think the nano (formerly raiblocks) approach is cool - it scales by running parallel blockchains - each wallet is its own chain. tx's between chains are vote…

Because nano has free transactions, a big concern was indeed spamming the network because transanctions are free (as in you pay no nano). But since each wallet has to calculate their own blockchain, the prosessing power is purely on the client side and so not free in that sense, which limits the spamming to the processing power you have.

Re: The senatorial governance of Bitcoin: making (de)centralized money

#102

Post by cyphertruck » Tue, Jan 07, 2020, 6:16 AM UTC

ac29 wrote: post #88

sunshinerag wrote: post #78

Earlier quoted context omitted.

Lightning protocol addresses that. You can make millions of transactions per second [1]. Quite a lot of crypto sites are already supporting it and wallet support is increasing too [2]. [1] - https://lightning.network [2] - https://blog.bitrefill.com/top-11-lightning-network-wallets-...

Why is an additional layer of complexity an improvement? Why not make bitcoin blocks 10x larger and 10x more frequent? The argument that "only large entities will be able to keep up with that" doesn't really hold - thats the status quo already.

That’s not the status quo at all. You can buy a raspberry pi 4, a 1TB SSD, and have a perfectly functional bitcoin node, and lightning node and BTCPAY server all in one for close to $200.

Secondly, Lightning isn’t “additional complexity” fir bitcoin— it’s taking complexity and putting it where it belongs— at the platform layer.

TCP/IP doesn’t get faster by making packets bigger. Same with bitcoin. And the application layer should be kept separate from the transport layer.

Re: The senatorial governance of Bitcoin: making (de)centralized money

#103

Post by cyphertruck » Tue, Jan 07, 2020, 6:19 AM UTC

JohnJamesRambo wrote: post #36

I still hope that they listen to reason and increase bitcoin’s ability to scale. We are all held hostage by a tiny cabal of developers that think they know what is best and want bitcoin to have a perversely small block size and pitiful 7 transactions per second top speed.

If you read the bitcoin core release notes going back at least the past 5 years, and look at the road map, every release and every planned addition has improved scalability— many of them very significant improvements.

The “bitcoin doesn’t scale” trope is a claim made by people who tried to take over bitcoin (Eg Roger Ver, Craig Wright, the S2X cabal) generally with their own personal benefit as the motive.

Unfortunately, even here in HN, most commenters gave t been reading the release notes.

But you should. Core is very accessible, and the release notes of bitcoin are the developer equivalent of Warren Buffett’s letters to shareholders.

Re: The senatorial governance of Bitcoin: making (de)centralized money

#104

Post by phillipsjk » Tue, Jan 07, 2020, 6:28 AM UTC

nullc wrote: post #97

ac29 wrote: post #88

Earlier quoted context omitted.

Why is an additional layer of complexity an improvement? Why not make bitcoin blocks 10x larger and 10x more frequent? The argument that "only large entities will be able to keep up with that" doesn't really hold - thats the status quo already.

Why add TCP to IP or HTTP to TCP? It's sound engineering. Like in other systems by composing layers you can achieve the advantages of each component while addressing their costs, without creating insurmountable complexity... "have your cake and eat it too". Particularly, the central Bitcoin system is a global broadcast medium-- necessarily for its security. Global broadcast is inherently somewhat limited in its scala…

Scaling with second layers instead of on-chain is NOT "sound engineering"

The Engineering discipline relies on empirical studies. With constantly full blocks, you have no way to measure transaction demand.

Fees are only a weak indicator of transaction demand because of substitute goods.

Re: The senatorial governance of Bitcoin: making (de)centralized money

#105

Post by polyomino » Tue, Jan 07, 2020, 6:30 AM UTC

wbazant wrote: post #70

Exchanges trade both in Bitcoin and BitcoinCash, and I've just learned from the paper that they form a tree with a common origin. Does it mean that if I owned Bitcoin before the Bitcoin-BitcoinCash split, I can now spend it on both chains?

yes, but be aware, bcash is plagued with scammers, so as a precaution you should move your coins on bitcoin to another wallet before attempting to use a bcash wallet which could steal your bitcoin private keys.

Re: The senatorial governance of Bitcoin: making (de)centralized money

#106

Post by nullc » Tue, Jan 07, 2020, 6:34 AM UTC

cyphertruck wrote: post #102

ac29 wrote: post #88

Earlier quoted context omitted.

Why is an additional layer of complexity an improvement? Why not make bitcoin blocks 10x larger and 10x more frequent? The argument that "only large entities will be able to keep up with that" doesn't really hold - thats the status quo already.

That’s not the status quo at all. You can buy a raspberry pi 4, a 1TB SSD, and have a perfectly functional bitcoin node, and lightning node and BTCPAY server all in one for close to $200. Secondly, Lightning isn’t “additional complexity” fir bitcoin— it’s taking complexity and putting it where it belongs— at the platform layer. TCP/IP doesn’t get faster by making packets bigger. Same with bitcoin. And the application…

> TCP/IP doesn’t get faster by making packets bigger.

Technically larger MTUs can increase performance somewhat by reducing per-packet overheads... but the effect marginal and not that enormous with good nics and drivers.

But still, probably not the best example. :)

Re: The senatorial governance of Bitcoin: making (de)centralized money

#107

Post by breavyn » Tue, Jan 07, 2020, 6:38 AM UTC

pshc wrote: post #74

JohnJamesRambo wrote: post #43

Earlier quoted context omitted.

Lightning Network is not peer to peer which is what most of us signed up for with bitcoin. I don’t want centralized middlemen and their channels, might as well use a bank at that point. Lightning Network isn’t simple and elegant, it is a convoluted mess. The peer to peer foundation of bitcoin is literally in the title of the white paper from Satoshi. Bitcoin: A Peer-to-Peer Electronic Cash System https://bitcoin.org/…

In what sense is Lightning not peer-to-peer? It seems permssionless in that any two people can agree to open a channel.

You're missing the keyword 'network'. If you're routing a payment across the lightning network, then it is technically not peer to peer. You send a payment to the next hop in the route, then they send a payment to the following hop, and so on.

As you said, any two parties are able to open (and close) a channel. However, these actions require an on chain transaction, and your funds are locked until you close the channel. Unless you're going to be exchanging many transactions in a short period of time with your peer, you would be better off creating transactions directly on chain.

I won't get into this here, but the lightning 'network' has its own set of scaling problems, which imo are much worse than that of the bitcoin network itself.

Re: The senatorial governance of Bitcoin: making (de)centralized money

#108

Post by phillipsjk » Tue, Jan 07, 2020, 6:39 AM UTC

bathtub365 wrote: post #75

staplers wrote: post #56

Earlier quoted context omitted.

The creator actually suggested that it could scale fine if they increased the block size and mentioned future miner farms in 2010. However, it would make sense that exchanges and credit-card-like institutions would want to keep bitcoin unscalable for the foreseeable future and stall scalable development.

Do you have any evidence of this kind of collusion?

Blockstream (Which funds Core developers) was funded by AXA Strategic Ventures with about $80Million in two rounds.

Digital Currency Group, which has investment in a lot of Bitcoin companies has a controlling interest from MasterCard.

That alone does not prove anything, but Bitcoin (BTC) failed to scale. When fees hit $50/transaction, with weeks long confirmation times, most companies backed by DGC failed to switch to the upgraded version of Bitcoin (BCH). This was despite BCH being a drop-in replacement, while Segregated Witness (the BTC upgrade) was not.

Part of the reason nobody switched to BCH was a major marketing push to strip Bitcoin Cash of the name "Bitcoin", and to frame it as a "scam" with "air-dropped tokens" you can "claim". (It was just a direct blockchain copy at fork time).

The truth is that BCH forked from BTC after 4 years of obstructionism. We forked just in time: because the huge transaction backlog on BTC happened within months of the fork. The result was an entirely predictable result of failing to scale.

Re: The senatorial governance of Bitcoin: making (de)centralized money

#109

Post by roenxi » Tue, Jan 07, 2020, 6:39 AM UTC

awt wrote: post #76

roenxi wrote: post #35

Earlier quoted context omitted.

Holders of bitcoin are the only people who don't have a say. Buyers, miners and developers decide what is and is not viable (in roughly that order). Holders have a say only as much as they are still buyers.

How do you sell a fork if you aren’t holding it first?

By creating the fork on demand. The only part of Bitcoin that is technically hard to recreate from scratch is the huge hashing power of its mining network.

If buyers were happy with bitcoin-but-a-different-brand then there isn't much existing bitcoin holders can do to hold their market together. There is an unlimited supply of numbers out there, the constraint is numbers that are backed by whatever silly number of hashes per second the Bitcoin network is up to. The holders don't have any particular influence over that constraint.

Re: The senatorial governance of Bitcoin: making (de)centralized money

#110

Post by lawn » Tue, Jan 07, 2020, 6:41 AM UTC

nullc wrote: post #97

ac29 wrote: post #88

Earlier quoted context omitted.

Why is an additional layer of complexity an improvement? Why not make bitcoin blocks 10x larger and 10x more frequent? The argument that "only large entities will be able to keep up with that" doesn't really hold - thats the status quo already.

Why add TCP to IP or HTTP to TCP? It's sound engineering. Like in other systems by composing layers you can achieve the advantages of each component while addressing their costs, without creating insurmountable complexity... "have your cake and eat it too". Particularly, the central Bitcoin system is a global broadcast medium-- necessarily for its security. Global broadcast is inherently somewhat limited in its scala…

It's laughably bad engineering to try to solve the scaling issue of the base layer by adding another layer on top. It's like you'd try to solve a throughput problem of IP by layering TCP or HTTP on top.

But this is the logic of one of the main devs who championed the "fee market" idea of Bitcoin[0], that high fees are required for Bitcoin to function. And who in 2017 celebrated when fees were around $50.[1]

[1]: https://medium.com/@johnblocke/the-fee-market-myth-b9d189e45...

[0]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017...