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

hense they both sign to both commit to the same terms. so that that if one of them goes offline they know the other has signed their part on the side they kept...

hense they both sign to both commit to the same terms. so that that if one of them goes offline they know the other has signed their part on the side they kept...

so i combined A(X) lets call her alice xavier..

when its first broadcast its treated as relevant. so a future spender (once maturity expires) would care about this:
Out script1: if relevant(1abcdefghij123456789 A(X) val: 9btc); if irrelevant(1klmnopqrs987654321 B(Y) val: 10btc)
Out script2: if relevant(1klmnopqrs987654321 B(Y) val: 1btc); if irrelevant(1abcdefghij123456789 A(X) val: 0btc)
it ignores the irrelevant part meaning A(X) alice Xavier gets 9btc.  B(y)bob yonker would get 1btc.

however if B(Y) Bob yonker invoked a CSV revoke
when its first broadcast its treated as relevant. but revoke is invoked and so a future spender would care about this:
Out script1: if relevant(1abcdefghij123456789 A(X) val: 9btc); if irrelevant(1klmnopqrs987654321 B(Y) val: 10btc)
Out script2: if relevant(1klmnopqrs987654321 B(Y) val: 1btc); if irrelevant(1abcdefghij123456789 A(X) val: 0btc)
it ignores the relevant part meaning B(y)bob yonker would get 10btc. A(X) alice Xavier gets 0btc.

OR EVEN BETTER
stay uptodate and then know the latest concepts and know what the main guys are trying to build. rather than the flawed out of date stuff

however if you read the stuff core and LN devs are saying. they are overselling LN as a system where channels never need to close.

Somewhy you fail to understand, that both parties sign the same commitment transactions before they can be broadcast.

No, they hold different txes, which however distribute funds in similar ways.

Both parties have seen both commitment transactions. But each party has only one of two commitment transactions with both signatures.

Y can't broadcast that transaction because he doesn't have it. He instead has another transaction corresponding to the same state,

Another hint: commitment transaction that Alice holds was created and signed by Bob. Now Alice holds this transaction, she sees it, she can sign it. Same with Bob's transaction. It was created by Alice. But Alice can't herself broadcast transaction which she created, because this transaction lacks Bob's signature. It's how multisignature works. You need both signatures for a transaction to be valid.[/b] Please bother to carefully read either the articles or my narration (or both). May be I'm bad at explaining, because English isn't my native language?

About your scenario. I'm not sure I fully understand it, what do you mean by B(X) for instance? What do you mean by "maturity 1000 blocks"? It's not tx which matures in 1000 blocks, it's one of it's outputs that does so (in fact not even so, it's one of ways the output can be spent which matures in 1000 blocks).

By "out scripts" you mean scripts of 2 outputs which commitment transactions create, Out script1 is for output1, Out script2 is for output2, right?
Then how it's possible
that the same output may result in significantly different amount of BTC spent, depending on a condition?
Not to mention, that commitment transactions in simple bidirectional channels create only 1 conditional output.

We will never achieve full consensus.

1. do you agree that LN uses multisig. where 2 parties co-sign agreed tx data. if yes read on, if not, research and come back later.
hint 2: both signing = both seeing a copy to be able to sign

Out script2: if relevant(1klmnopqrs987654321 B(Y) val: 1btc); if irrelevant(1abcdefghij123456789 A(X) val: 0btc)

9    Risks
The primary risks relate to timelock expiration.  Additionally, for core nodes
and possibly some merchants to be able to route funds, the keys must be
held online for lower latency.  However, end-users and nodes are able to keep
their private keys  rewalled o  in cold storage.
9.1    Improper Timelocks
Participants must choose timelocks with suffcient amounts of time.
If insuffcient time is given, it is possible that timelocked transactions believed to
be invalid will become valid, enabling coin theft by the counterparty.
There is a trade-off  between longer timelocks and the time-value of money.
When writing wallet and Lightning Network application software, it is necessary
to ensure that suffcient time is given and users are able to have their trans-actions
enter into the blockchain when interacting with non-cooperative or malicious channel counterparties.

9.2    Forced Expiration Spam
Forced expiration of many transactions may be the greatest systemic risk when using the Lightning Network.  
If a malicious participant creates many channels and forces them all to expire at once, these may overwhelm block data capacity,
forcing expiration and broadcast to the blockchain.  The re-sult  would  be  mass  spam  on  the  bitcoin  network.  
The  spam  may  delay transactions to the point where other locktimed transactions become valid.
This may be mitigated by permitting one transaction replacement on
all  pending  transactions.   Anti-spam  can  be  used  by  permitting  only  one
transaction replacement of a higher sequence number by the inverse of an
even or odd number.  For example, if an odd sequence number was broad-
cast, permit a replacement to a higher even number only once.  Transactions
would use the sequence number in an orderly way to replace other trans-
actions.   This  mitigates  the  risk  assuming  honest  miners.
This attack  is extremely  high  risk,  as  incorrect  broadcast  of  Commitment  Transactions entail a full penalty of all funds in the channel.
Additionally,
one may attempt to steal HTLC transactions by forcing a timeout transaction to go through when it should not.
This can be easily mitigated by having each transfer inside the channel be lower than the total
transaction fees used.  Since transactions are extremely cheap and do not
hit the blockchain with cooperative channel counterparties, large transfers
of value can be split into many small transfers.  This attempt can only work
if  the  blocks  are  completely  full  for  a  long  time.   While  it  is  possible  to
mitigate it using a longer HTLC timeout duration, variable block sizes may
become common, which may need mitigations.
If this type of transaction becomes the dominant form of transactions which are included on the blockchain,
it may become necessary to increase the  block  size  and  run  a  variable  blocksize  structure  and  timestop   ags as described in the section below.
This can create suffcient penalties and
disincentives  to  be  highly  unpro table  and  unsuccessful  for  attackers,  as
attackers lose all their funds from broadcasting the wrong transaction,  to
the point where it will never occur.

9.4    Data Loss
When one party loses data, it is possible for the counterparty to steal funds.
This can be mitigated by having a third party data storage service where
encrypted data gets sent to this third party service which the party cannot
decrypt.   Additionally,  one  should  choose  channel  counterparties  who  are
responsible  and  willing  to  provide  the  current  state,  with  some  periodic
tests of honesty.
9.5    Forgetting to Broadcast the Transaction in Time
If one does not broadcast a transaction at the correct time, the counterparty may steal funds.
This can be mitigated by having a designated third party
to send funds.  An output fee can be added to create an incentive for this
third party to watch the network.  Further,  this can also be mitigated by
implementing OP CHECKSEQUENCEVERIFY

10    Block Size Increases and Consensus
If we presume that a decentralized payment network exists and one user will
make  3  blockchain  transactions  per  year  on  average,  Bitcoin  will  be  able
to  support  over  35  million  users  with  1MB  blocks  in  ideal  circumstances
(assuming 2000 transactions/MB, or 500 bytes/Tx).

This is quite limited, and an increase of the block size may be necessary to support everyone in the world using Bitcoin.
A simple increase of the block size would be a hard fork,  meaning  all  nodes  will  need  to  update  their  wallets  if  they  wish  to
participate in the network with the larger blocks.

While it may appear as though this system will mitigate the block size increases in the short term,
if it achieves global scale, it will necessitate a block size increase in the long term.

 

FYI: LN means Snidely Whiplash Wins.  

Show, how the system can be tricked.

step 1: two people communicate together and agree to open a multisig to start a channel.

step 2: they both independently fund the multisig with their amounts. ONCHAIN.

step 3: they agree to the terms of who owes what. initially agreeing to whatever they deposit they get back.
hint 1: the funds cannot be spent in a multisig without both signatures
TXID:AB3
In:3abcdeklmn987654321 val:5btc (originally A(X) deposit)
In:3abcdeklmn987654321 val:5btc (originally B(Y) deposit)
Out script1: if relevant(1abcdefghij123456789 A(X) val: 5btc); if irrelevant(1klmnopqrs987654321 B(Y) val: 5btc)
Out script2: if relevant(1klmnopqrs987654321 B(Y) val: 5btc); if irrelevant(1abcdefghij123456789 A(X) val: 5btc)

maturity 1000 blocks

step 4: and both sign the same tx data.
hint 1: the funds cannot be spent in a multisig without both signatures
TXID:AB3
In:3abcdeklmn987654321 val:5btc (originally A(X) deposit)
In:3abcdeklmn987654321 val:5btc (originally B(Y) deposit)
Out script1: if relevant(1abcdefghij123456789 A(X) val: 5btc); if irrelevant(1klmnopqrs987654321 B(Y) val: 5btc)
Out script2: if relevant(1klmnopqrs987654321 B(Y) val: 5btc); if irrelevant(1abcdefghij123456789 A(X) val: 5btc)
Signature (A(X) signed inputs and output to agree)
Signature (B(Y) signed inputs and output to agree)
maturity 1000 blocks

step 5: B(Y) decides to give A(X) say 4BTC, they agree and they BOTH SIGN
hint 1: the funds cannot be spent in a multisig without both signatures
hint 2: both signing = both seeing a copy to be able to sign
hint 2: they both agree there should be a harsh penalty rather then getting what they deposited back
hint 2: in your scenario they now decide to not having matching data. but both sign each others tweaked tx data

A(X) creates and signs this. making A(X) lose out if not moral
TXID:A5
In:3abcdeklmn987654321 val:5btc (originally A(X) deposit)
In:3abcdeklmn987654321 val:5btc (originally B(Y) deposit)
Out script1: if relevant(1abcdefghij123456789 A(X) val: 9btc); if irrelevant(1klmnopqrs987654321 B(Y) val: 10btc)
Out script2: if relevant(1klmnopqrs987654321 B(Y) val: 1btc); if irrelevant(1abcdefghij123456789 A(X) val: 0btc)
Signature (A(X) signed inputs and output to agree)
maturity 1000 blocks

B(Y) creates and signs this. making B(Y) lose out if not moral
TXID:B5
In:3abcdeklmn987654321 val:5btc (originally A(X) deposit)
In:3abcdeklmn987654321 val:5btc (originally B(Y) deposit)
Out script1: if relevant(1abcdefghij123456789 A(X) val: 9btc); if irrelevant(1klmnopqrs987654321 B(Y) val: 0btc)
Out script2: if relevant(1klmnopqrs987654321 B(Y) val: 1btc); if irrelevant(1abcdefghij123456789 A(X) val: 10btc)
Signature (B(Y) signed inputs and output to agree)
maturity 1000 blocks

step 6: they both hand eachother a copy and sign their counterparts version
hint 1: the funds cannot be spent in a multisig without both signatures
hint 2: both signing = both seeing a copy to be able to sign
hint 3: doing this invalidates previous TX (step 4)

A(X) created, now B(Y) signs, B(X) KEEPS aswell as the other one below
TXID:A6
In:3abcdeklmn987654321 val:5btc (originally A(X) deposit)
In:3abcdeklmn987654321 val:5btc (originally B(Y) deposit)
Out script1: if relevant(1abcdefghij123456789 A(X) val: 9btc); if irrelevant(1klmnopqrs987654321 B(Y) val: 10btc)
Out script2: if relevant(1klmnopqrs987654321 B(Y) val: 1btc); if irrelevant(1abcdefghij123456789 A(X) val: 0btc)
Signature (A(X) signed inputs and output to agree)
Signature (B(Y) signed inputs and output to agree)
maturity 1000 blocks

B(Y) created, now A(X) signs
TXID:B6
In:3abcdeklmn987654321 val:5btc (originally A(X) deposit)
In:3abcdeklmn987654321 val:5btc (originally B(Y) deposit)
Out script1: if relevant(1abcdefghij123456789 A(X) val: 9btc); if irrelevant(1klmnopqrs987654321 B(Y) val: 0btc)
Out script2: if relevant(1klmnopqrs987654321 B(Y) val: 1btc); if irrelevant(1abcdefghij123456789 A(X) val: 10btc)
Signature (A(X) signed inputs and output to agree)
Signature (B(Y) signed inputs and output to agree)
maturity 1000 blocks

step 7: many many many trades like steps 5,6 happen where values change hands.. making previous txs irrelevant
hint 1: the funds cannot be spent in a multisig without both signatures
hint 2: both signing = both seeing a copy to be able to sign
hint 3: doing this invalidates previous TX
lets say they are at TXID:A200   TXID:B200 making A4-199  and B4-199irrelevant

step 8: B(Y) kept A6 (step 6), initially you think thats crazy right. but B(Y) broadcasts it

step 9: B(Y) lets it get confirmed

step 10: B(Y) uses the revoke code on the A6 Out script1 to then make the output spendable to him instantly before maturity expires

a system where the other person can trick the system and chargeback in that week........ = same as visa - worse than wire transfer

a system where funds are locked for a week after settling. where they cant be spent....... = worse then merchants/customers get from accepting visa/paypal

Closing the channel.
Both parties know, that they can’t cheat each other. So when they decide to close the channel, one of them (let it be Alice) creates a transaction that spends o1 according to the latest state of the channel, signs it, and sends to Bob. He checks that funds are split fairly, signs it and broadcasts it. This transaction is the second and the last to hit the chain, for the whole lifetime of the channel.

That's not chargebacks, but punishment for theft attempt. One party takes all funds from the channel only if another party tries to use an outdated state to steal funds.

you literally talk about a chargeback method where bob can get funds destined for alice, then suddenly say its impossible

Another output is also recorded on the chain, there no way to spend it except 2 ways defined by it's script.

no "charge backs" are possible

learn multisig.

Building Block #3: Multisig

however if they keep a channel open that surpasses the locktime(onchain) set up when opening the channel EG

they both hold the same relevant tx at the same time.

a tx wont get into a block without both signatures.
so both need to sign the same copy

having a week CSV delay(1000 block) that can be interrupted by another person broadcasting a more relevant tx..

and by going by your scenario. during that week it can be "charged back" to bob (Y) going by your scenario

Here is a Point for those that can think.

If segwit does actually manage to get activated.

And people use LN for the majority of their transactions, and stay off the Blockchain.

Do you think the mining pools have already figured out less transactions on the blockchain means less fees for them to collect.
Especially when they need to survive off of transaction fees only and no more BTC are created. Less than 5 Million BTC left to mine.
LN will take money out of the BTC miners pocket.  

 

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.

CSV, instead, uses relative time. Once a CVS-output is recorded on the blockchain, it takes a specific amount of blocks from that point on before the bitcoins can be spent again.

Nope. They would get outhashed.

Rules say 95 % required for segwith soft fork, unless the others can hold 95% for 2 Weeks , it will fail.

False. Requires 95% for any reasonable design.

Ok, you're just being stupid now.
Reason they went with a pussy ass soft fork is they know the Chinese mining pools would block it now.
They are hoping enough public pressure comes that forces the Chinese mining pools to succumb to their will over the course of a year.
Again the Betting Pools are open.



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

Nobody gives a Damn , that BTC devs are too incompetent to pull off 1 Hard fork in a year.
You should just ask your self why all of the Alt devs you insult are more competent than your BTC devs.
But I can see Thinking is not something you are good at.    

That service is as useful as your trolling attempts.

People smarter than you appreciate it.

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