Topic: Scaling Bitcoin. Is consensus achievable? - page 2. (Read 4041 times)

Nope. They would get outhashed.

False. Requires 95% for any reasonable design.

Nobody in their right mind gives a damn about some shitcoins hard forking 100 times a year.

That service is as useful as your trolling attempts.

Hard forks are inherently dangerous in a widely deployed infrastructure (which no shitcoin, e.g. ZEIT, is).

ok clear the matter up.

at any majority. the orphan game will eventually sort it self out.
at a low majority say 55%. it might take a many blockheights where half is disagreeing and the orphan rate is say 65 blocks of 144 have a corresponding orphan..
headache nightmare .. headache nightmare .. headache nightmare
mining pools will be screaming. nodes will be syncing and losing sync.. bad for everyone.. but deemed temporary drama as eventually it leads to one chain and the minority left unsynced.
retailer merchant guidance: wait upto say 100 confirms before fully trusting a tx

at a low say 70%. it might take a many blockheights where a third is disagreeing and the orphan rate is say 42 blocks of 144 have a corresponding orphan..
blah blah same thing. a bit less screaming, but lots of crying still while the orphan drama sorts itself out
retailer merchant guidance: wait upto say 70 confirms before fully trusting a tx

at say 85%. it might take a few dozen blockheights where inder a quarter  is disagreeing and the orphan rate is say 20 blocks of 144 have a corresponding orphan..
blah blah same thing. not screaming, but not much crying while the orphan drama sorts itself out, but not happy
retailer merchant guidance: wait upto say 45 confirms before fully trusting a tx

at say 95%. it might take a a couple blockheights where a few is disagreeing and the orphan rate is say 7 blocks of 144 have a corresponding orphan..
not as bad and miners could live with a slight risk elevation compared to the usual 1-2% a day they usually put up with.
retailer merchant guidance: wait upto 10 confirms before fully trusting a tx

usual daily 1-2% risk advises waiting upto 6 confirms

Sure, when parties want to update the channel, the following happens:


You can read this series of articles. I learned this design from there.

I made bold part of the quote which is closely related to your concerns.

you do know that multisigs needs 2 signatures.
you do know that to agree to what you call a "commitment" both parties need to see and agree to it.

so if your saying Y cannot transmit X's preferred tx because Y has never seen it, been handed it or knows of its existance.. then im guessing whatever LN concept you are viewing has far more weaknesses.

i made the bits bold that you mention.. first bold bit.. an old state.. im assuming for practical reasons Y did infact see that state earlier in the day/weeks when it was relevant. so by seeing it, would have (lik any malicious user) kept a copy of it. then as shown by the second bold part its assumed Y is involved to signing the commitments by seeing the commitments..

reason being both SHOULD be signing together.. so my last paragraph is highlighting even your scenario assumes this to be true..
so im not sure why last post says Y never had first state

Y can't broadcast that transaction because he doesn't have it. He instead has another transaction corresponding to the same state, which immediately pays 9 BTC to X and 1 BTC to similar fancy output which can be spent in 2 different ways. If he broadcasts his version of that obsolete state, X will immediately take all 10 BTC from the channel.

^ wrote to try showing how X cant attack but reveals Y is now the attacker
which is another attack vector.

cant you see the attack vector..
dont think about X doing the 9btc.. for X to gain.. thats then everted by Y(your hope of scenario outcome)

think about Y broadcasting th X9Y1... triggering X so Y can then get 10btc
lets say Y broadcasts X's 9btc. to then allow Y to broadcast the tx that gives Y the whole 10btc

anyway theres many concepts throwing about. and many attack vectors in each.
the bip u quoted is not strong enough on its own and actually makes one person gain.

not really a moral/equal paradigm like some other concepts i have seen

The concept I'm talking about works the following way:
Let's say current channel state is: 5 BTC belong to X, 5 BTC belong to Y. But among previous states there is one where 9 BTC belong to X and only 1 BTC belong to Y. X likes the older state much more. So he broadcasts it. The transaction that he broadcasts spends the original 2 of 2 output and creates 2 new outputs: 1 BTC immediately goes to Y, and another output is created, let's call it o2. o2 can be spent in 2 different ways. First: X can spend it after 1000 blocks are mined on top of the block where o2 was created. Second: Y can spend it at any moment if, besides signature, he also provides preimage of a certain hash. Since Y already has this preimage, otherwise he would refuse to update state of the channel, he can immediately spend o2, thus taking all 10 BTC from the channel. Friendly pool can't help X, because it takes 1000 blocks before o2 can be spent in way preferable for X.

im trying not to use buzzwords or over complex things so other readers can understand the fundamentals.

as for the individual spends within LN, they too need to do some things.
the 'secret exchange' in practice does not work. hense the need for the locks aswell.

EG (your concept version)
 i could have a direct connection to a pool and have bribed them to put my tx into a block the exact moment the 1000 block lock is released.. so when i send X in the last second, its in.
you spot mine and think your Y would over ride my X. the problem is that your Y transaction has to relay around the network and sit with the other high fee paying blocks in mempool before a pool accepts it into a block.. which after seeing the mempool bloat this week might be 2 hours.
where as mine gets in. making yours invalid(double spend attack).

thats why locktimes are needed too. to delay mine from being acceptable.

the bip you referenced may have exampled a 24 hour revoke time. but in practice.. users wont accept that.
also that can be attacked/abused in atleast 3 ways.

but hey there are many LN concepts, i just hope the one your viewing is not going to ignore using inner locktimes of descending order.. otherwise thats a weakness of that concept.

I'm not sure if I understand you right. But it seems to me that you mean, that each consecutive pair of commitment transactions (those that aren't broadcast under normal circumstances) occurring on the channel must have shorter locktimes, so that later ones could be confirmed sooner than earlier ones?
If so, that's not the case. All commitment transactions produce outputs that may have the same time lock of say 1000 blocks, beginning from the block which includes parent commitment transaction. Commitment transactions are invalidated not thanks to newer commitment transactions have shorter timelock, but through exchanging secrets, whose hashes are exchanged at the beginning of state update. So at any step each party has only 1 commitment transaction that can be safely posted to the network, that's the latest transaction. All previous transactions are invalidated because should say X posts one of those transactions, Y can immediately take all funds form the channel.

yes
i just called it a laymens term of relevant gap/grace period (dont get hung up on my 10minute arbitrary number i used),
the old mechanism "in number of blocks" (as you quoted)
new concepts are using seconds instead. so instead of saying blockheight. or seconds. i for easy explanation for the scenarios said 10 minutes.. but the 10 minutes is not important. its just a demo purpose random number


the point is: gap simply wont be 1 second as that can be abused, much like in paypal everyone waits till the final second to push their bids)

the gap between acceptable bids needs to be more then one second. due to onchain issues about relay-propagation times and other factors
also i factored in that say the gap was 3 seconds. every time a person doesnt use LN for 3 seconds thats one possible lock wasted.
also i factored in that say the gap was 3 seconds. every time a person uses LN in milliseconds that takes away 3 seconds of utility

meaning its not an unlimited amount of transactions right up to the ONCHAIN nlocktime, there are actual limits to LN

to add to this..

in practice.. using say the middle graph (of my last post)
or
"which means if in milliseconds a hub does 259200 tx's  it now has to close within 7 days of opening" (scenario of post previous to that)

even though a onchain timelock wont allow the close session to be allowed/confirmed onchain until:
middle graph agreed tx(close session) reached 2hours 10 minutes
259200tx agreed tx (close session) reached 10 days 10 minutes

it still closes at:
middle graph 40 minutes - but just not confirmed onchain for another 1 hour 30 minutes (after 2 hours from opening due to onchain lock)
259200tx agreed tx 7 days - but just not confirmed onchain for 3 days. (after 10 days from opening due to onchain lock)

in short .. users are waiting hours or days unable to use LN at all, because all (inner LN) locks are used up. where users cant keep spending and the funds are not released onchain.. basically leaving users left in limbo.

meaning practically the channels SHOULD close earlier to not leave users in limbo. hense my gripe that channels should be able to close earlier.


from what i can see is in concept as their 'work around'
while users are in limbo between the LN inner lock being used up and the onchain locktime (scenario1:1h 30mb, scenario2: 3days)
users are persuaded to make a second channel using different funds (while initial funds are locked) to restart using the service while the limbo time of first session expires.

simple illustration


lock= 2 hours
left graph: user spends every 10 minutes
spend at 10th minute - lock release at 1hour 50min
spend at 20th minute - lock release at 1hour 40min
spend at 30th minute - lock release at 1hour 30min
spend at 40th minute - lock release at 1hour 20min
spend at 50th minute - lock release at 1hour 10min
cant use as realtime and locktime release lock is soon
end result lock-in was 2 hours but had to close in an hour - tx processed 5 out of 12

middle graph: user spends every 5 minutes
spend at   5th minute - lock release at 1hour 50min
spend at 10th minute - lock release at 1hour 40min
spend at 15th minute - lock release at 1hour 30min
spend at 20th minute - lock release at 1hour 20min
spend at 25th minute - lock release at 1hour 10min
spend at 30th minute - lock release at 1hour
spend at 35th minute - lock release at 50min
cant use as realtime and locktime release lock is soon
end result lock-in was 2 hours but had to close in 40 minutes - tx processed 7 of 12

middle graph: just once
spend at   Xth minute - lock release at 1hour 50min
time passes locktime release lock is soon
end result lock-in was 2 hours but had to close in at 1 hour 50 minutes - tx processed 1 of 12

That's not the case with CSV, which is already adopted on mainnet.

https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki

locktimes
EG say the locktime is  now+864000seconds (10days) 1480244302+864000seconds = 1481108302
LN does not stay active for 10 days
every transaction within LN uses a lock to keep latest relevance
in conception
tx z: unlock 1481108301
tx y: unlock 1481108300
tx x: unlock 1481108299
which means if in milliseconds a hub does 86400 tx's  it now has to close within 9 days of opening
which means if in milliseconds a hub does 172800 tx's  it now has to close within 8 days of opening
which means if in milliseconds a hub does 259200 tx's  it now has to close within 7 days of opening

also the secret is although being conceived that locktime of +864000 seconds means 864000 transactions are possible. its not
firstly. to secure relevance, there needs to be a gap between locks. so that the most relevant(x) doesnt time out and the next irrelevant(y) becomes relevant again due to there not being enough time to broadcast X before Y's time becomes relevant.

its going to end up that locktimes will be 10mins plus, to give a relevance 'grace' period.
eg
tx z: unlock 1481072302
tx y: unlock 1481036302
tx x: unlock 1481000302

meaning only 1440 transactions are possible in 10 days.

i used 10 days as a simple number because it displays limits clearly. but you might be saying well onchain lockin can be set to say 2 years.
i would counter that with the more complicated maths of hubs.. where by in the fantasy land of the 'visa comparable' scenarios or the 'one world currency' scenarios people are propagandising as to why LN is essential. that instead of happily processing just say 500 transactions per channel
for some day trader/gambler in 10 days.. a hub will be processing hundreds of thousands to millions of transactions (visa/oneworld scenario)

so although a 2 year lock effectively means upto 105120 LN tx (with relevance grace) over 2 years.. a hub will use up all of them 105120 locks very very fast.

eg. imagine onchain only copes with 4500 tx.. but at first LN is chosen by 10%. (450 tx)
yes LN free's up 450 tx no longer being onchain.

but now within LN 450 tx are done every 10 minutes instead of onchain. meaning the 2 year locks are used up within a fortnight due to the hub and spoke/multihop model

in short. if lock was set to 2 years. and 105120 were done in lets say 5 minutes. the channel needs to close in 5 minutes of opening and a new channel opened for 2 years

the benefit is obviously 105120tx are aggregated down to a final and single tx onchain. where bitcoins main net does see all the swaps of 105120tx and only sees 1tx of (laymens: final balance outputs)
but requires users to then re open a channel again which becomes a headache in a hub model

Lightning nodes are connected to Bitcoin nodes, from which any inputs can of course be verified. So that can't happen.

What are LN coins and how they could be created out of thin air?

I would imagine it would be to periodically force an audit the value of the coins in the channel by closing out the books, thus making sure no extra LN coins have been created out of thin air. There should be better ways to do this, though.

Mainnet is still needed, even if channels never closed, because without possibility of emergency closing, channels effectively lose state. It's like nuclear deterrence. Nuclear weapons have great impact on international relations, even though never used.

Could you please elaborate. Why LN needs to frequently close channels?

If everyone else accepts it, they will either join them or get outhashed.

No. You need 95%.

This is completely misleading. Such a hard fork would be very dangerous. I highly advise you to stop trolling now, you are very untrustworthy.

A great options is available today, it just requires more awareness and support. Short-term scaling solved.

blockchain.info has a competitor to LN called 'thunder' that I believe can actually be used now, although you should only transact with people that you trust with it because the lack of SegWit means that transactions can become invalid.

I don't think the question about LN is if LN works, I believe the question about LN is if LN is how Bitcoin should be used, and who should receive TX fees.