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

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

#331

Post by phillipsjk » Wed, Jan 08, 2020, 11:27 PM UTC

once_inc wrote: post #162

kain_niak wrote: post #129

Earlier quoted context omitted.

Hardly, because building LN on the 1MB base layer is like building a pyramid upside down, it's unstable and creates more problems than it was meant to solve. Lightning was supposed to make tx fees low right? Well it technically has, but it also introduced the following problems that Bitcoin never had: - LN requires that both sender and receiver be online at the same time to transact. This never existed on Bitcoin. -…

> LN requires that both sender and receiver be online at the same time to transact. This never existed on Bitcoin. Correct, but this is clearly stated in its whitepaper and is one of the tradeoffs to get massively more txs and privacy. > If you're an LN merchant accepting payments, you must periodically topoff your side of the channel...just so you can keep accepting money. This problem never existed on Bitcoin. I ca…

According to a recent study, the privacy properties of the lighting Network are weak.

The problem with lightning privacy is that to get good privacy you need more than about 2 hops. The problem is that every hop locks up money equal to the amount transferred: increasing the cost of the transaction.

The study also finds that the LN is currently subsidized, and based on the capital costs alone, fees should be comparable to on-chain (BTC) transactions. BCH transactions are currently subsidized as well, but not to the same extent (I estimate 3cents/kB would pay for processing and storage).

https://blog.dshr.org/2020/01/bitcoins-lightning-network.htm...

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

#332

Post by phillipsjk » Wed, Jan 08, 2020, 11:42 PM UTC

nullc wrote: post #148

6nf wrote: post #85

Earlier quoted context omitted.

Thats bullshit. ETH has loads of transaction volume, second only to Bitcoin. Lightning network transaction volume is almost zero right now.

You have no idea what lightning transaction volume is, for all you can tell I'm currently making 1000 transactions per second in a loop between a set of lightning wallets. :) Because lightning is actually relatively scalable it doesn't broadcast every action to everyone.

Researchers have done black-box capacity testing. It can process around 7,000 transactions per day. Even BTC can handle that volume on-chain.

https://blog.dshr.org/2020/01/bitcoins-lightning-network.htm...

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

#333

Post by j23450n » Wed, Jan 08, 2020, 11:55 PM UTC

nullc wrote: post #256

j23450n wrote: post #247

Earlier quoted context omitted.

Blocksize is clearly not literally a rate; that's a ridiculous statement. When you artificially cap it, like putting a limiter on your car in your analogy, it can be rate limiting, i.e. limiting the transaction rate - an actual rate. That chart you posted in meaningless in this context, but clearly just greg being greg, trying to manipulate; are you seriously trying to suggest that the tiny increase from segwit shena…

It is literally a rate. It is the rate of bytes added per block (which by the system's design is once per ~10 minutes). Increasing supply above demand radically drops fee rates. That is the logical, predicted, and observed behavior-- both in Bitcoin and in other similar systems.

Look, I'm not one to harp on semantics, but this is bullshit, you can't* just make something a rate by using the word 'per'. If I'm a doughnut shop, and I sell 12-packs of doughnuts, my doughnut-box-size is not a rate, the amount of doughnuts I sell in an hour, or a day etc., is a rate. If my store has a policy of only fulfilling orders once every 10 minutes on average, but only up to one box, or 12 doughnuts per 10 minutes, the doughnut-box-size is still not a fucking rate, even though the shop could say they only sell 12 doughnuts per 10 minutes. Edit: Let me rephrase this somewhat; it's clear greg is trying to use semantic chicanery and multiple definitions and senses of the word 'rate' to obfuscate any actual points. Rate is typically used and understood (let's say in STEM anyhow) to be a measure of 'flow'. Thus his speed example, distance per time, is a rate, or tx per second. It doesn't have to use time as measure, but here what greg is trying to do is say that, using the most generic definition of rate, you can compare doughnuts and boxes and say that doughnuts-per-box (blocksize) is a rate, even though he's really using as example "(dougnuts-per-box)-per-((10 minute)time interval)", which is a rate, and pretending they're the same thing . Of course if you increase the size of the container, the flow, or actual rate of tx/time interval will increase, but saying that the size of the container itself is a rate, is contextually insane.

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

#334

Post by phillipsjk » Wed, Jan 08, 2020, 11:59 PM UTC

nullc wrote: post #257

mathiasrw wrote: post #93

Earlier quoted context omitted.

You have to pre-setup a connection to others that you know and hope they know someone that knows someone that has a connection to the person you are trying to buy from. This is how the design of lightning network incentivises mega hubs that know most people. So if facebook made a big hub with all its users it would work smoothly. Also: You can not receive payments if the computer/wallet that hosts your lightning node…

> and hope they know someone The system has routing, and it turns out that it doesn't take much for the probability of a graph to be connected with low average diameter. See: The six degrees of kevin bacon. If lightning doesn't work for a particular payment, you can simply make a payment without using it, potentially by splicing out funds from one of your channels. Yes, Lightning has trade-offs. You have to be online…

> though if you don't like them you're free to not use it.

No true: due to limited block space on the base-layer.

I am not convinced you get any efficiency increase with the LN: just more difficult capacity planning because everything is suddenly so hard to measure.

Sending a payment, whether on the first or second layer, will take a certain amount of: bandwidth, processing and storage.

Even if fewer nodes are involved with each transaction, the LN seems to rely on a lot of message passing; beyond what a simple broadcast on the base layer requires.

Even is we assume the processing and storage requirements are equal: it will be more expensive on the LN. On the base layer, your data is protected from Byzantine faults by having each node verify the transactions as they come in. With the LN, state is local to each node. That implies you need redundant hardware to protect against Byzantine faults. I have been migrating my machines to ECC RAM and redundant storage: it is not cheap. What I save on hardware costs by buying old servers I pay in extra power use.

The above paragraph did not even mention the capital requirements of maintaining a Lightning node.

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

#335

Post by phillipsjk » Thu, Jan 09, 2020, 12:07 AM UTC

nullc wrote: post #321

phillipsjk wrote: post #317

Earlier quoted context omitted.

Compact block were heavily inspired by Bitcoin Unlimited's "Thin Blocks".

It is another untruthful claim. The original design document for compact blocks is was published (and last modified) on Dec 25, 2015. https://people.xiph.org/~greg/efficient.block.xfer.txt The earliest work for Bitcoin Unlimited's "Thin Blocks" was on Jan 10th 2016: https://bitco.in/forum/threads/buip010-passed-xtreme-thinblo... Both were motivated by an earlier effort by Bitcoin developers Matt Corallo and Pieter Wu…

I guess I stand corrected on that one.

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

#336

Post by j23450n » Thu, Jan 09, 2020, 12:20 AM UTC

phillipsjk wrote: post #314

nullc wrote: post #256

Earlier quoted context omitted.

It is literally a rate. It is the rate of bytes added per block (which by the system's design is once per ~10 minutes). Increasing supply above demand radically drops fee rates. That is the logical, predicted, and observed behavior-- both in Bitcoin and in other similar systems.

Of course the fees would drop after raising the blocksize. The current fees are well above the marginal transaction costs of processing and storing those transactions. (I estimated it was 3cents/kB, assuming GB scale blocks on ~1000 4U (36 bay) servers with 10Gbps networking distributed world-wide.) Other analysis I have seen erroneously assumes the POW is a marginal cost: which is only true with a tiny, limited, blo…

Pretty much this. I don't think greg has read any economic theory, let alone introductory microeconomics where you would see the idea of 'marginal analysis'. I mean his reply suggests that demand is entirely static, or inelastic, which would be interesting to study, but certainly shouldn't be assumed, and is likely completely false.

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

#337

Post by phillipsjk » Thu, Jan 09, 2020, 3:14 AM UTC

phillipsjk wrote: post #332

nullc wrote: post #148

Earlier quoted context omitted.

You have no idea what lightning transaction volume is, for all you can tell I'm currently making 1000 transactions per second in a loop between a set of lightning wallets. :) Because lightning is actually relatively scalable it doesn't broadcast every action to everyone.

Researchers have done black-box capacity testing. It can process around 7,000 transactions per day. Even BTC can handle that volume on-chain. https://blog.dshr.org/2020/01/bitcoins-lightning-network.htm...

Correction: that was simulated testing, using scraped channel data and a LNBig blog post (about traffic statistics) to validate the results.

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

#338

Post by I_am_tiberius » Thu, Jan 09, 2020, 7:01 AM UTC

bduerst wrote: post #325

I_am_tiberius wrote: post #48

Earlier quoted context omitted.

Comparing the lightning network with a bank is totally incorrect. Your funds cannot be seized and the middlemen privacy aspect is very similar to the Tor network. I don't think there is a better way of solving a decentralized payment system.

Lightning is the same as writing a check. Until it's verified on the bitcoin network, it's just like a bank in that regard.

But there's no way the bitcoin network doesn't accept the settlement. A bank can just throw checks away if they like.

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

#339

Post by phillipsjk » Thu, Jan 09, 2020, 5:46 PM UTC

etherael wrote: post #268

nullc wrote: post #250

Earlier quoted context omitted.

You claimed on many occasions to have you your possession the keys for the first 9 coinbase outputs. Signing with all of those, particularly block 9 since Hal claimed that it was Satoshi's-- would be exceptionally influential. Sign "Gmax, Wright is Satoshi." with all those and I'll leave Bitcoin forever and never bother you again.

Christ could the real actual Satoshi if you're still out there please do this and get rid of this guy once and for all? It would be so worth it even with the negative side effect of the BSV cult trying to use it as evidence that Wright actually is Satoshi.

I am not holding my breath.

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

#340

Post by bduerst » Thu, Jan 09, 2020, 6:29 PM UTC

I_am_tiberius wrote: post #338

bduerst wrote: post #325

Earlier quoted context omitted.

Lightning is the same as writing a check. Until it's verified on the bitcoin network, it's just like a bank in that regard.

But there's no way the bitcoin network doesn't accept the settlement. A bank can just throw checks away if they like.

Bitcoin will not accept a settlement if the wallet no longer has funds.

Banks throwing away checks is not a problem. Bouncing checks are a fraud problem, which is why most everyone have moved on from using checks is many situations.

Lightning's solution is to just 'watch' everyone you do transactions with, which is a lazy, non-viable solution analagous to continuously watching an anonymous stranger's bank account when they write you a check.