Topic: What is actually use of SegWit? (Read 1769 times)

To anyone actually wanting to know more about Segwit, read the 1st page of this topic and make up your own minds.
These guys on the 2nd page , pure waste of my time.  


 

FYI:
In the end the Miners will determine whether or not SegWit is even activated.
Odds are all of these concerns over segwit & LN will be blocked by the Mining Pools anyway.

You are probably correct that it is not necessary for me to attempt to engage with you on this topic, and I think that I already stated my reasons and you stated your reasons and we seem to disagree about things.

By the way, even though you seem inclined to want to disqualify me from this topic, it does not seem to be necessary to know all technical aspects of seg wit in order to know things about bitcoin and/or segwit and to contribute to this kind of thread from whatever level, and as a bonus, it seems to me that the OP of this thread attempts to approach this seg wit topic from a non-technical perspective.

@Temp_JayJuanGee,

You basically admitted you don't know jack , so you have no information to actually talk about except your little soap opera attacks,
which are devoid of everything except your feelings. I could give a rat's ass about your feelings.
If you want to argue a technical point then post it, but keep throwing out those whiny I feel attacks, and you keep getting more of the same,
because that is all they deserve in response.  
Your call.

 

And they are wrong. I have spoken to Rusty about this and we both reached the same conclusion that it is in fact possible to create a lightweight lightning client without segwit, it just is a little more complex.

Then Tell them to Update their Lying Website, until then , I will believe the website over you.  

Again, it is not something specific to LN but rather something that is possible regardless of LN being used or not

Reading Comprehension is not your strong suit,
Collusion between LN Nodes & Miners , would most definitely be specific to LN  

First of all, it is not option. What you are suggesting is not even mentioned in the paper at all, just some theory that you made up from some statements in the paper about the RISKS of LN. Those were part of the RISKS and they were listing all of the possible RISKS. These are RISKS not OPTIONS.

@Temp_JayJuanGee

Your own words are the best reply to you. 


 

I don't claim to be any kind of expert either or even to know if important points are being left out of any kind of explanation...
snip*

Your trying to taint my posts as misinformation is strictly Bullshit.

I post my conclusions along with the Links to the Whitepapers and articles that help me form those conclusions.
Which people can read those links and form their own personal conclusion.

Where as you are the only one throwing unsubstantiated slander toward me to cover up your lack of actual information.
Where is your detailed analyzes with links to articles & whitepapers or is a 3rd grade propaganda tactic all you have?  

 

FYI :
This Post says all I need to know about you, newbie.
You yourself admit you don't know Jack about SegWit.  

That little tidbit of info comes from Bitcore

It is a Valid Theory of Possible Danger of Collusion between LN Nodes & Miners.
The original thought confirms the possibility of the reverse.  

Until LN has been up and running for a year or so , You don't really know what additional feature could be installed.  
They are including an option so the miner can induce an option to ignore a block, so it does not affect the time lock, under certain attack conditions.
Adding a rotating passcode so LN knows to only include it's transactions in a Block from a specific miner , is also not out of the realm of possibility.
Would they do it , hopefully not,  but would it be possible, yes it would, which is why I said Theory and not fact.

Yes, another sign of a misinformation campaign is attacking the person rather than the argument.   And, by the way, I am not a newbie.. just having some issues with my regular account, as might be inferred by my username.

Substantively, I have trouble with quite a few of the seg wit naysayers, because in part, when seg wit was first proposed in December 2015, there was nearly unanimous agreement that it was a good thing for bitcoin.  And, overall, there really is no major technical criticism against it - except for attempts at FUD spreading (in other words misinformation campaigns that play to emotions rather than logic).

Surely it would be a good thing to get seg wit activated in the coming 6 months in order that Bitcoin developers will be able to take advantage of some of the features and to build upon it and to bring more to end-users, such as myself (and maybe a large segment of the population that does not want to get into technicalities, as long as their value remains decentralized immutable and securely able to store and transfer).

I don't claim to be any kind of expert either or even to know if important points are being left out of any kind of explanation...
snip*

Thanks Newbie,   
There is a lot of something being spread, don't step in it.

 

I don't think that it is necessary for lightning to be a full node. It can still work without being a full node but with some additional complexity. Where in the lightning paper does it say that a full node is required?

That little tidbit of info comes from Bitcore
https://bitcoincore.org/en/2016/01/26/segwit-benefits/
The Lightning Network conducts transactions by creating Bitcoin transactions that can be broadcast onto the Bitcoin network at any time. There are no IOUs being traded, what is happening is that transactions are being created but not broadcast. Again, there is no separate thing where Bitcoin is being converted into some sort of IOU on lightning.

LN is OFFCHAIN, unless it is ONCHAIN, it is LITERALLY IMPOSSIBLE for BTC to be on it , meaning you have BTC IOUs on LN.
In other words , since BTC can not exist Offchain, What LN lists as a BTC is merely a debt for BTC, which is paid upon completion of contracts.
IOU => is usually an informal document acknowledging debt

That risk is based on miner collusion. The reverse would also require miner collusion, not some technical aspect of LN that makes it possible for only specific miners to mine those transactions. This is not just something related to LN but rather an issue that can already happen with Bitcoin as it is because it is just miner collusion and requiring human intervention in order for that to be possible.

not some technical aspect of LN that makes it possible for only specific miners to mine those transactions.

Pretty much when anyone tries to redefine FUD spreading as if it were some form of higher but necessary truth, then most of the time, that person is engaged in such a practice of disinformation.  (by the way, FUD spreading = the posting of information (usually misinformation) that is meant to cause Fear, Uncertainty, Doubt in the reader of such)

In by Case , By FUD
F  = FACTS
U  = UNSUNG
D   = DEBUNK
 

In what way? The way that inputs and outputs work are still exactly the same.

Reference : https://bitcoincore.org/en/2016/01/26/segwit-benefits/[/color]

he Lightning Network: with third-party and scriptSig malleability fixed, the Lightning Network is less complicated to implement and significantly more efficient in its use of space on the blockchain. With scriptSig malleability removed, it also becomes possible to run lightweight Lightning clients that outsource monitoring the blockchain, instead of each Lightning client needing to also be a full Bitcoin node.

Do you not understand the Word OFFCHAIN , BTC is only Locked on the ONLINE BLOCKCHAIN, it is not and can not be moved onto LN's network,
So you are trading BTC IOUs when you use LN.

Now that is just FUD. How would LN only allow certain miners to confirm those transactions? That is just completely false.

One of the Concerns in the LN Network Whitepaper is that ,
Miners may Decline Certain LN transactions so their Locks timeout and the BTC can be Stolen.
If the above is possible, the reverse is also possible which makes what I said a Valid Theory.

In what way? The way that inputs and outputs work are still exactly the same.

Reference : https://bitcoincore.org/en/2016/01/26/segwit-benefits/
How so? An LN Node doesn't need to be a full Bitcoin node already. They can work fine as SPV wallets now and after Segwit. Segwit does not change that at all.

Reference: https://bitcoincore.org/en/2016/01/26/segwit-benefits/
The Lightning Network: with third-party and scriptSig malleability fixed, the Lightning Network is less complicated to implement and significantly more efficient in its use of space on the blockchain. With scriptSig malleability removed, it also becomes possible to run lightweight Lightning clients that outsource monitoring the blockchain, instead of each Lightning client needing to also be a full Bitcoin node.

What requires a Lightning client to be a full node? As I understand it, it doesn't matter, and segwit does not change that.

Yo Dum Dum , same answer as above.  
Reference: https://bitcoincore.org/en/2016/01/26/segwit-benefits/
The Lightning Network: with third-party and scriptSig malleability fixed, the Lightning Network is less complicated to implement and significantly more efficient in its use of space on the blockchain. With scriptSig malleability removed, it also becomes possible to run lightweight Lightning clients that outsource monitoring the blockchain, instead of each Lightning client needing to also be a full Bitcoin node.

I don't think you understand how LN works. LN does not issue IOUs. It creates very real, valid, and broadcastable Bitcoin transactions. There are no IOUs involved.

Do you not understand the Word OFFCHAIN , BTC is only Locked on the ONLINE BLOCKCHAIN, it is not and can not be moved onto LN's network,
So you are trading BTC IOUs when you use LN.

Not necessarily. LN is not for every type of transaction. It is really only good for small, repeated transactions like faucet payments.

LN will cost the Miners money , that is why less than 30% have been dumb enough to agree to it.

Now that is just FUD. How would LN only allow certain miners to confirm those transactions? That is just completely false.

One of the Concerns in the LN Network Whitepaper is that ,
Miners may Decline Certain LN transactions so their Locks timeout and the BTC can be Stolen.
If the above is possible, the reverse is also possible which makes what I said a Valid Theory.

---

You are demonstrating and extreme lack of knowledge on subjects you are arguing against. I highly suggest that you actually do some research before posting.

Please stop spreading FUD.

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

Segwit makes it easier to track your Transactions.

SegWit : Makes it So a LN Node does not have to run a full Bitcoin node

The Lightning Network: with third-party and scriptSig malleability fixed, the Lightning Network is less complicated to implement and significantly more efficient in its use of space on the blockchain. With scriptSig malleability removed, it also becomes possible to run lightweight Lightning clients that outsource monitoring the blockchain, instead of each Lightning client needing to also be a full Bitcoin node.

Simply put SegWit will make it possible to Steal BTC Value to use in LN Alternative Payment System using BTC IOUs .

Miners will lose money because LN can decrease the number of OnChain Transactions.

(In Theory : Using advanced features LN may even allow only certain miners to process the transaction Fees when Onchain BTC Transactions are required.)
(Giving LN Nodes the ability to starve miners not in Collusion with them of transaction fees. )  

The only thing LN does is limit fees for miners and give those fees to owners of Lightning Network (Blockstream)

Simply put SegWit will make it possible to Steal BTC Value to use in LN Alternative Payment System using BTC IOUs .
Miners will lose money because LN can decrease the number of OnChain Transactions.
(In Theory : Using advanced features LN may even allow only certain miners to process the transaction Fees when Onchain BTC Transactions are required.)

Furthermore segwit is more than just a fix for Lightning. It provides much more uses and fixes which have already been discussed in this thread and elsewhere.