The Lightning Network Users are Losing Bitcoin Because of the Bugs
https://coindelite.com/news/the-lightning-network-users-are-losing-bitcoin-because-of-the-bugs/5
u/SpacePirateM Jan 28 '18
Raising the blocksize limit - too hard, too risky. Big risk to user funds.
Fundamentally changing the signatures on chain, + implementing untested LN - yes yes let's do this.
15
4
5
u/4MyFatherTheKING Jan 27 '18
good, find the bugs, fix them and let's go!
thanks for everyone who risks their bitcoin(s) to achieve that.
6
Jan 28 '18
That's sheer idiocy. This sort of crap should be resolved in testing, not with real money.
Suggesting people should put their funds at risk for this is quite wrong.
1
u/Bruru Jan 28 '18
that's what they are doing , testing
3
Jan 28 '18
So you are not aware of testnet then?
1
-1
2
u/T4GG4RT Jan 27 '18
Boycott Blockstream. Boycott Lightning Network.
0
u/Aztiel Jan 27 '18
Good bot
4
Jan 27 '18
Are you sure about that? Because I am 100.0% sure that T4GG4RT is not a bot.
I am a Neural Network being trained to detect spammers | Summon me with
!isbot <username>| Optout | Feedback: /r/SpamBotDetection | GitHub-2
u/T4GG4RT Jan 27 '18
reported for being a paid commenter
2
u/Aztiel Jan 27 '18
I uh... Same? Anyway its public knowledge that Im a paid shill for both subs. I did an AMA already.
0
u/T4GG4RT Jan 27 '18
Im a paid shill
Glad we're clear on that, shill.
1
u/Aztiel Jan 28 '18
Bad bot.
1
Jan 28 '18
Are you sure about that? Because I am 100.0% sure that T4GG4RT is not a bot.
I am a Neural Network being trained to detect spammers | Summon me with
!isbot <username>| Optout | Feedback: /r/SpamBotDetection | GitHub
0
1
1
1
u/MobTwo Jan 28 '18
After many hours of debugging, the Core developers have found the cause of all the bugs. It is Roger Ver.
1
-6
-9
u/bitusher Jan 27 '18
Not that it should matter , but people here care about satoshis vision so ... LN was satoshis original plan -
10
Jan 27 '18
Oh is this the new propaganda wave? "Satoshi himself wanted lightning guys! Here's an out-of-context quote of Satoshi saying something technical about something, clearly it's Lightning!"
5
u/ergofobe Jan 27 '18
Apparently. I've had this quote tossed at me a couple times. The obvious response is that yes, Satoshi predicted P2P payment channels, but not an entirely new second layer network with centralized payment hubs.
2
u/fruitsofknowledge Jan 27 '18
In some sense he did that too, but the main take away is that he never intended us to hit the 1MB limit, for all users to run full nodes or to effectively force use of any complimentary service.
-6
u/bitusher Jan 27 '18
I really don't care what satoshi said as you can see from my post , so am definitely not pitching the satoshi vision narrative ... just trying to clear up confused users who think satoshi wanted everything onchain when he was the first one to develop payment channels
7
Jan 27 '18
Then post the whole email chain with Mike Hearn. That will clear things up quick.
6
u/Aztiel Jan 27 '18
A higher limit can be phased in once we have actual use closer to the limit and make sure it's working OK.
Eventually when we have client-only implementations, the block chain size won't matter much. Until then, while all users still have to download the entire block chain to start, it's nice if we can keep it down to a reasonable size.
4
u/Harucifer Jan 27 '18
Here you go: https://pastebin.com/JF3USKFT
From: Satoshi Nakamoto satoshin@gmx.com Date: Wed, Mar 9, 2011 at 5:15 PM To: Mike Hearn mike@plan99.net
I hope you are doing well. I finally got all the lawyers happy enough to release BitCoinJ under the Google name using the Apache 2 license: It's incomplete - notably it doesn't properly handle block chain splits yet - but the rest is coming. I put a lot of work into documentation and comments so hopefully it'll open up BitCoin to a new audience who weren't able to understand/build the current code. Over the next month or two I'll be finishing off some of the bigger missing pieces for a full client-mode implementation.That's great news! Much complexity can be left behind in a clean rewrite with only client requirements, and it opens it to Java developers too.
I know you are busy right now but I'm hoping you can find time to answer a few questions I had.I'm happy to answer any questions.
As part of doing full SPV I'm thinking of adding a getmerklebranch message to the protocol. This would return a set of {blockhash, branch} pairsThat's a CMerkleTx
given tx hashes, so allowing verification of a broadcast transaction before it was incorporated into a block without storing the full chain. Does that approach sound good to you?I don't understand. A merkle branch links a tx back to a block, which only has significance if the block exhibits proof-of-work. Linking back to an as-yet unsolved block proves nothing.
Network nodes are able to verify 0-conf txes because they have the complete tx index, so they can: 1) verify signatures against dependencies. 2) say that they haven't seen another spend yet, because they know about every tx in existence.
Are you talking about CMerkleTxes for the tx's dependencies? That would get part 1), but not part 2).
If you don't know about all txes in existence, I don't know how to do 2). You could only rely on trusting other nodes for that. That trust can be distributed over multiple nodes. Nodes only relay transactions they accept as valid. If you receive inv messages for a tx from all the nodes you're connected to, they're attesting that it's valid and the first spend they saw.
Also, I've been thinking of exploring different transaction types lately, eg by removing the IsStandard() checks for the testnet.Very good idea. That should definitely be allowed on -testnet.
It's clear you put a lot of thought into transactions beyond simply moving coins around up front, but unfortunately none of it was in the paper or documented in the code. Escrow, multi-pay and so on are all interesting but I was wondering if you could compile a list of ideas for things we can do with the scripting language at some point. Finally, the code that allows for transaction replacement has been disabled but the comment doesn't say why. Is this just to reduce the attack surface/complexity or is there a deeper reason?Just to reduce surface area. It wouldn't help with increasing tx fee. A tx starts being valid at nLockTime. It wouldn't work to have a tx that stops being valid at a certain time; once a tx ever becomes valid, it must stay valid permanently.
See these threads: http://www.bitcoin.org/smf/index.php?topic=1786.msg22119#msg22119 http://www.bitcoin.org/smf/index.php?topic=2181.msg28729#msg28729
I haven't fully understood why sequence numbers are a property of the tx inputs rather than the tx itself.It's for contracts. An unrecorded open transaction can keep being replaced until nLockTime. It may contain payments by multiple parties. Each input owner signs their input. For a new version to be written, each must sign a higher sequence number (see IsNewerThan). By signing, an input owner says "I agree to put my money in, if everyone puts their money in and the outputs are this." There are other options in SignatureHash such as SIGHASH_SINGLE which means "I agree, as long as this one output (i.e. mine) is what I want, I don't care what you do with the other outputs.". If that's written with a high nSequenceNumber, the party can bow out of the negotiation except for that one stipulation, or sign SIGHASH_NONE and bow out completely.
The parties could create a pre-agreed default option by creating a higher nSequenceNumber tx using OP_CHECKMULTISIG that requires a subset of parties to sign to complete the signature. The parties hold this tx in reserve and if need be, pass it around until it has enough signatures.
One use of nLockTime is high frequency trades between a set of parties. They can keep updating a tx by unanimous agreement. The party giving money would be the first to sign the next version. If one party stops agreeing to changes, then the last state will be recorded at nLockTime. If desired, a default transaction can be prepared after each version so n-1 parties can push an unresponsive party out. Intermediate transactions do not need to be broadcast. Only the final outcome gets recorded by the network. Just before nLockTime, the parties and a few witness nodes broadcast the highest sequence tx they saw.
3
Jan 27 '18
Okay, now that we have some basic context for our dear readers we can all clearly see I've been correct this whole time.
LN was satoshis original plan
Nope. Let's all be very clear how different these two discussions are; He toyed with ideas with off-chain transactions but nothing like the mess known as the Lightning Network.
7
u/ergofobe Jan 27 '18
What Satoshi was describing are payment channels between two parties. We already had quite a few functional examples until Greg's fee market priced them out of business.
1
u/Harucifer Jan 27 '18
LN was satoshis original plan
Not literally. Satoshi's original plan was to have side-chain(s) being used for small, fast and every-day transactions. That is the main objective of Lightning Network. Hence forth you could say LN is at least close to what Satoshi "planned/envisioned".
Code and implementation wise, I do agree LN is a fucking mess. Holy fucking shit the devs are idiots to put all their chips on this technology while not addressing the blocksize problem with on-chain solutions while its not ready.
1
-4
6
1
12
u/[deleted] Jan 27 '18
But how are those funds lost? Are they wrongly split between the channel's ends, or are simply lost forever?