Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

tandfonline.com

Post reply on HN
Print view View original

181–190 of 344 posts

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

#181

Post by shilch »

im3w1l wrote: post #173
shilch wrote: post #170

Earlier quoted context omitted.

TCP wasn't build on IP because it wasn't scalable. It was build on it because it was. But that aside, calling Lightning on BTC a second-layer is a bit misleading: Lightning data is not encapsulated in BTC data, more like the other way around; so Lightning is more like layer 0 and BTC layer 1 in that model. (That's also not entirely correct either but much closer)

> At the start, TCP handled both datagram transmission and routing, but as the protocol expanded, other researchers started to recommend that these two functions be split into layers. > One of these researchers, Jonathan Postel of the University of California’s Information Sciences Institute and an editor for the Request of[sic] Comments (RFCs) which is a document series capturing the development of the Internet. > P…

I'm not all too familiar with the history of IP and TCP but my point still stands. Protocols aren't build because the underlying protocol doesn't scale in term of throughput, it's for the opposite reason that they scale very well. I could also have used HTTP and TCP.

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

#182

Post by cedivad »

nullc wrote: post #145
sunared wrote: post #131

Earlier quoted context omitted.

> Bitcoin users might get increasingly tyrannical about limiting the size of the chain so it's easy for lots of users and small devices. He was talking about people like you. He didn't advocate for a centrally planned block limit. Stop trying to twist his words. Gavin Andresen and Jeff Garzik are well known big blockers so stop trying to imply otherwise. At least here I won't get censored by theymos like on r\bitcoin…

> He didn't advocate for a centrally planned block limit. I don't know about 'centerally planned' but he hardcoded a limit into the consensus rules. > Gavin Andresen and Jeff Garzik are well known big blockers so stop trying to imply otherwise. That's the point. And I a pointing out that they said all these things in 2010-2014-- as you can see some of the quotes (esp from Jeff) are quite emphatic. I could quote a lot…

He "hardcoded" a spam protection measure at a time when it was legitimately expected an attacker would spend a few dollars and clog up the blockchain significantly.

This was always intended as a temporary measure and it was understood by the community at large that the limit would be removed as soon as it started hindering adoption. As an example, see this reddit thread of mine 86% upvoted: https://old.reddit.com/r/Bitcoin/comments/35hpkt/please_remi...

As history will remember, what happened then is that you decided you had missed out on the boat and you started raising money for your stupid little layer 2 solution while censoring everyone suggesting it had to coexist with a bigger block size.

I'm not going to mince words, you are the reason Bitcoin is a speculative scam instead of a real payments revolution as it was intended to be. It had one chance and thanks to you and your cronies the only people benefiting from it are the ones liquidating noobs on bitmex.

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

#183

Post by mikekchar »

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.

I can answer part of that question. You can't make it much more frequent because the amount of time for the difficulty has to be balanced against propagation time for blocks or else you will have lots of forks. Probably you can make it work, but there are a fair number of assumptions in the Bitcoin protocol about this and it would probably be better to start a new coin if you want to do that. The 10 minute update was chosen specifically to avoid common network partition events.

As for block size, it's been ages since I looked into this stuff at all (and I've only ever watched out of the corner of my eye), but my impression is that the block size is currently limited for relatively arbitrary reasons. I don't think there is actually a lot of resistance to increasing the size sometime. It's just that the developers want to limit the size now to guide development in certain ways.

And really, as far as I'm concerned that's totally fair. If you don't like it, fork the coin. Or start a new one. Or stick with Bitcash. The developers are in control because that's the whole point -- to guide development in the way that they think will work best. Not everybody is going to agree. So what?

I think the only reason people get upset is because of the ludicrous amount of potential money on the line. And again: if you are controlling that ludicrous amount of potential money, you are able to vote with your feet -- to the extent that you can convince other people with ludicrous amounts of potential money to follow suit. If all that insane speculation and fraud were to vacate Bitcoin, the developers could happily code away and there would be nobody left to complain.

Let's face it. If we believe that there are billions of dollars tied up in BTC, the owners of that coin could easily afford to hire programmers to fork the protocol. They don't do it because the politics of doing so is essentially impossible. Most people want to stick with the dev group. Again, I'm left with saying, so what?

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

#184

Post by FreeTrade »

sunshinerag wrote: post #78
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.

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-...

Lightning requires that both sender and receiver be online at the same time to transact.

Lightning was not ready when Bitcoin capacity was crippled by the aforementioned tiny cabal of developers in favor of Lightning.

Lightning remains unready, forever 18 months away from the promised usable technology.

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

#185

Post by nullc »

breavyn wrote: post #107
pshc wrote: post #74

Earlier quoted context omitted.

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 chann…

> You send a payment to the next hop in the route, then they send a payment to the following hop, and so on.

It's not technically a payment at that point, since the payments is atomic end to end. But yes, you send a message your peer, which sends it to another peer, which sends it to another peer...

like any other P2P network.

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

#186

Post by nullc »

ddtaylor wrote: post #179
nullc wrote: post #172

Earlier quoted context omitted.

This thread: $ egrep 'class="hnuser"> ' 21978475 | wc -l 35 21977147 (top thread right now): $ egrep 'class="hnuser"> ' 21977147 | wc -l 0 21974514 (second from top): $ egrep 'class="hnuser"> ' 21974514 | wc -l 1 21974117 (third from top): $ egrep 'class="hnuser"> ' 21974117 | wc -l 1 These threads have similar numbers of comments to this one. 21971545 (Next one down with a lot of comments, 2.5x this one): $ egrep 'c…

I browse both sites daily and see links between the two quite often. What is strange about one site linking to another? Also I don't know if it's HN formatting but the commands you posted don't work. I think you're trying to point out there are N number of new users in this thread?

It's saying at the time I commented there were 35 posts in this thread with green names (36 now), while there were 0, 1, 1, and 1 in the other threads respectively.

If you want to go by the ratio of unique green names instead of posts this thread has 13 times more than those threads that had any at all.

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

#187

Post by tromp »

lawn wrote: post #90
httpz wrote: post #11

Earlier quoted context omitted.

But after all the blocks are mined, how does the blockchain even work?

In addition to the other answers, there are some cryptocurrencies where the block reward never goes to zero. Look up how it works in Monero for example.

There are also cryptocurrencies where the block reward is fixed forever, so that miners at launch are rewarded no more than miners decades later. Note that such a linear emission is still disinflationary in the sense that the yearly inflation rate tends toward zero.

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

#189

Post by nullc »

shilch wrote: post #181
im3w1l wrote: post #173

Earlier quoted context omitted.

> At the start, TCP handled both datagram transmission and routing, but as the protocol expanded, other researchers started to recommend that these two functions be split into layers. > One of these researchers, Jonathan Postel of the University of California’s Information Sciences Institute and an editor for the Request of[sic] Comments (RFCs) which is a document series capturing the development of the Internet. > P…

I'm not all too familiar with the history of IP and TCP but my point still stands. Protocols aren't build because the underlying protocol doesn't scale in term of throughput, it's for the opposite reason that they scale very well. I could also have used HTTP and TCP.

Bitcoin has very strong properties for _security_ which is the inherent property that makes it possible to build other automated trustless systems on top of it.

The comparison with TCP and IP is limit in that TCP data all goes inside IP packets. With second layer transaction systems the relationship is different: the security and stability comes from the underlying blockchain. The higher part adds capacity.

Bitcoin forms a trustworthy robotic court system upon which the wheels of automated commerce can ride.

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

#190

Post by nullc »

cletus wrote: post #87
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.

So having a “currency” (its not really; is an asset) being controlled by an unaccountable “Tony cabal of developers” instead of a central bank is better how exactly? I’ve never understood this argument.

It's good you don't understand it, because it wouldn't be better. It be much worse, because as unaccountable as central banks can be they'd be more accountable than that.

But that simply isn't how Bitcoin works. Bitcoin developers have no such authority. People with no special power beside respect and goodwill, write software on their own as they're free to do just are you're free to do. Other people voluntarily chose to run it. If people don't run it, it's completely inert. They cannot force anyone to run it. Subject to the limitations of public review, they cannot make hidden changes. The software has no automatic updates, and the developers have a long history of being extremely vigorously opposed to automatic updates.

Because whatever effect the software has on the network could only be slowly realized as it's deployed (short of something like a crash bug or an RCE or similar) there is ample time for the public to review a new version -- even if they chose to ignore the open development process -- and sound the alarm against running it if they judge it to be adverse.

If you don't like software put out by one developer, you can run software from another. You could create your own (or pay someone to do it) from scratch. You could run an old version. You could take a version you don't like and make modifications until you do...

Moreover, the biggest community of developers in Bitcoin makes their software all free software, develops it on public lists/websites/irc channels, and has taken considerable efforts to maintain compatibility with other software specific to maximize your ability to choose to not run it without feeling too much conflict or hesitation-- You can happily go take Bitcoin 0.8 from 2013 or and years old copy of knots or a number of other forks or alternative implements... start it up and it will sync and come to consensus with the network. (I wouldn't necessarily recommend running something that old exposed to the internet-- due to vulnerabilities-- but you could and it would work fine.)

I would say your freedom is like your freedom with free software, but it isn't quite: If almost everyone else chooses to run something incompatible you can still keep running your original, but you might find yourself on a separate currency from everyone else. Since money gains it's value from network effects you might fine that less than ideal. But that's the limit, and it's also why the Bitcoin community is cautious with incompatible changes-- essentially never having intentionally made one. Faults in version prior to 0.8 make them self-incompatible, unfortunately. If you want to run a version prior to 0.8 and come to consensus with the network today you'd have to patch a database handling bug in it.

I think this is better. It's certainly very different properties than a trusted third party, and even if you're not sure it's clearly better-- perhaps you can agree that diversity and choice is useful and that you're better off for having the opportunity to use it should the need arise.

Post reply on HN