Pages:
Author

Topic: NOT Upgrading to SegWit who's with me?! - page 2. (Read 7217 times)

legendary
Activity: 3038
Merit: 1660
lose: unfind ... loose: untight
January 02, 2017, 04:48:01 PM
even Andreas Antonopoulos is advising people to adopt segwit before raising the blocksize because doing otherwise is a mistake

Got a link to AA actually saying that? Thanks.

https://twitter.com/aantonop/status/792436751901921280

Perhaps twitter gives different views to different people? There is nothing in there where Andreas "is advising people to adopt segwit before raising the blocksize because doing otherwise is a mistake".

Maybe you meant to post a different link?
hv_
legendary
Activity: 2534
Merit: 1055
Clean Code and Scale
January 02, 2017, 04:25:26 PM
Mm , can't find

Step 0:  Fixing scalability ( by simplifying code e.g. drop the line that has the 1MB ) that would be most recommended and the nobrainer all could agree on.


 Huh
legendary
Activity: 3430
Merit: 3080
January 02, 2017, 04:23:34 PM
I stopped reading once malleability becomes a problem. (see the underlined portion). 

Neither of those steps depend on the transaction hash. I think you may be confused about the notation, but I don't have time to convince you.
newbie
Activity: 55
Merit: 0
January 02, 2017, 04:15:59 PM
Ok, here's bitcointalk's TierNolan explaining it for you:

https://bitcointalksearch.org/topic/m.17148441




Original text from TierNolan:

This is a protocol for opening a permanent lightning channel even if malleability is not fixed.  It only requires check locktime and check sequence verify.

Both sides put down a deposit to eliminate the hold-out risk.  If either of the parties refuses to proceed either the other party is compensated or both get a full refund.

Step 1

Alice picks A1 and sends HA1, Hash(A1), to Bob.
Bob picks B1 and sends HB1, Hash(B1), to Alice.

They can both create this transaction.

Code:
TX1:
0) Pays 3x: (Alice + HA1 after T1) or (Bob after T1 + T2) or (2 of 2 Alice + Bob)
1) Pays x: (HB1 + Alice) or (2 of 2 Alice + Bob)
2) Pays x: (HA1 + Bob) or (2 of 2 Alice + Bob)
3) Pays 3x: (Bob + HB1 after T1) or (Alice after T1 + T2) or (2 of 2 Alice + Bob)
4) Pays Alice's change: (Alice)
5) Pays Bob's change: (Bob)

Alice and Bob create the transaction and sign and broadcast it.

Abort during step 1

If one party signs the transaction and then the other refuses, then the signer should send at least one of the inputs to another address.  This invalidates the transaction.

Abort after step 1

Alice can wait T1 and then reclaim output 0.  This automatically gives Bob HA1, which allows him claim output 2.

Likewise, Bob can wait T1 and then reclaim output 3.  This automatically gives Alice HB1, which allows her claim output 1.


This is a full refund all parties.
I stopped reading once malleability becomes a problem. (see the underlined portion).  
legendary
Activity: 3430
Merit: 3080
January 02, 2017, 04:03:12 PM
Ok, here's bitcointalk's TierNolan explaining it for you:

https://bitcointalksearch.org/topic/m.17148441




Original text from TierNolan:

This is a protocol for opening a permanent lightning channel even if malleability is not fixed.  It only requires check locktime and check sequence verify.

Both sides put down a deposit to eliminate the hold-out risk.  If either of the parties refuses to proceed either the other party is compensated or both get a full refund.

Step 1

Alice picks A1 and sends HA1, Hash(A1), to Bob.
Bob picks B1 and sends HB1, Hash(B1), to Alice.

They can both create this transaction.

Code:
TX1:
0) Pays 3x: (Alice + HA1 after T1) or (Bob after T1 + T2) or (2 of 2 Alice + Bob)
1) Pays x: (HB1 + Alice) or (2 of 2 Alice + Bob)
2) Pays x: (HA1 + Bob) or (2 of 2 Alice + Bob)
3) Pays 3x: (Bob + HB1 after T1) or (Alice after T1 + T2) or (2 of 2 Alice + Bob)
4) Pays Alice's change: (Alice)
5) Pays Bob's change: (Bob)

Alice and Bob create the transaction and sign and broadcast it.

Abort during step 1

If one party signs the transaction and then the other refuses, then the signer should send at least one of the inputs to another address.  This invalidates the transaction.

Abort after step 1

Alice can wait T1 and then reclaim output 0.  This automatically gives Bob HA1, which allows him claim output 2.

Likewise, Bob can wait T1 and then reclaim output 3.  This automatically gives Alice HB1, which allows her claim output 1.

This is a full refund all parties.

If Alice refuses to claim output 0, then Bob can claim it after [T1 + T2] (and output 3), which gives him 6x and Alice nothing.  

Likewise, if Bob refuses to claim output 3, then Alice gets 6x and Bob nothing.

Both parties are incentivized to comply with the abort at this stage.

Step 2

Alice and Bob create the initial channel state transaction.  This supports a channel close that gives x to Alice and x to Bob and spends outputs 1 and 2.

The initial state transaction is different for Bob and Alice due to the way Lightning works.  Only Alice has both signatures for her version and only Bob has both signatures for his version.

Step 2a

Alice signs Bob's version of the transaction and sends the signature to Bob.

Abort after step 2a

If Bob broadcasts his initial state transaction, then that counts as him closing the channel.  Alice gets her x refund and then can reclaim output 0 (after T1).

If he doesn't broadcast it, then she can just follow the same abort procedure from step 1.

Bob can abort using the procedure from step 1 or broadcasting the initial state transaction.

In all cases, Alice and Bob get their money back.

Step 2b

Bob signs Alice's version of the transaction and sends the signature to Alice.

Abort after step 2b

Alice (or Bob) can simply close the channel so that both get x each from outputs 1 and 2.

Once the channel is closed, she can then claim output 0 safely (after 1 week).

Likewise, Bob gets x when the channel is closed (he can close it himself too) and then claims output 3 safely.

This gives both parties a full refund.

Step 3

Alice and Bob create a transaction which sends outputs 0 and 3 back to them.  This requires both outputs to be 2 of 2 signed (so 2 signatures each).

This transaction is broadcast.  If either party refuses to sign, then it counts as an abort after step 2b.

Once step 3 is finished, they now have established an initial lightning channel state with unlimited duration.

It is important that neither reveal their hash lock as that allows the other to spend the funding output.
newbie
Activity: 55
Merit: 0
January 02, 2017, 04:00:34 PM
I know it is claimed by BTC Core that LN is possible without SegWit, but I am not so sure

There's a simple cure for that. Find out how it works. Simply asserting "I don't get it" doesn't magically make something impossible, it just means you don't get it
Why don't you explain it if it is in fact possible?

It should be very easy to explain that something is possible, but it is very difficult to prove something is impossible Smiley
legendary
Activity: 3430
Merit: 3080
January 02, 2017, 03:56:31 PM
I know it is claimed by BTC Core that LN is possible without SegWit, but I am not so sure

There's a simple cure for that. Find out how it works. Simply asserting "I don't get it" doesn't magically make something impossible, it just means you don't get it
legendary
Activity: 1066
Merit: 1098
January 02, 2017, 03:55:08 PM
even Andreas Antonopoulos is advising people to adopt segwit before raising the blocksize because doing otherwise is a mistake

Got a link to AA actually saying that? Thanks.

https://twitter.com/aantonop/status/792436751901921280
newbie
Activity: 55
Merit: 0
January 02, 2017, 03:46:43 PM
2a - One selling point of segwit is that it is effectively increasing the block size. If this is not 'something that needs to be fixed', then why is segwit being sold this way?


Segwit only real purpose is to enable the way for Lightening Network (Offchain Transactions),
even thru it is possible to implement a version of LN without segwit.
Using LN with Segwit , will move the power from the Miners to the ones controlling LN.
Without segwit, miners will still be the stronger force.
Power Grab by BTC core , pure & simple.
Yes, I was pointing out the hypocrisy behind how SegWit is being sold.

I know it is claimed by BTC Core that LN is possible without SegWit, but I am not so sure, especially not with the features that LN has in it's current planned form. I simply do not see how two parties could generate chained dependent unconfirmed transactions that are both guaranteed to contain valid signatures without malleability being addressed.  

you can always spot the blockstream sheep

they want to avoid onchain scaling.
they think offchain is the only way.
they love the idea of a fee war onchain
they love bloating onchain transactions by kilobytes via confidential payment commitments
I have noticed that many of the blockstream fanboys like to echo eachother, almost uniformly
legendary
Activity: 4410
Merit: 4788
January 02, 2017, 03:40:36 PM
you can always spot the blockstream sheep

they want to avoid onchain scaling.
they think offchain is the only way.
they love the idea of a fee war onchain
they love bloating onchain transactions by kilobytes via confidential payment commitments
legendary
Activity: 3038
Merit: 1660
lose: unfind ... loose: untight
January 02, 2017, 01:26:53 PM
even Andreas Antonopoulos is advising people to adopt segwit before raising the blocksize because doing otherwise is a mistake

Got a link to AA actually saying that? Thanks.
legendary
Activity: 1372
Merit: 1252
January 02, 2017, 12:10:55 PM
Segwit's been out now, what, six weeks?  And still 70% of block solvers are voting to keep block size at 1MB. 

What  a revelation.



they will be forced at some point to go with the 2MB hard fork, we can't remain forever at 1MB this is a 100% sure thing

i want to ask what is the exact reason why miners are aginst segwit now?
Everyone in Core team wants to go 2mb eventually, except 1 developer which i cant remember right now, so im pretty sure we will eventually go to 2mb, but not before we see segwit, since segwit is a fundamental requirement to see a blocksize increase, even Andreas Antonopoulos is advising people to adopt segwit before raising the blocksize because doing otherwise is a mistake. No one that knows how bitcoin works is against segwit.
hv_
legendary
Activity: 2534
Merit: 1055
Clean Code and Scale
January 02, 2017, 10:56:27 AM
Segwit's been out now, what, six weeks?  And still 70% of block solvers are voting to keep block size at 1MB.  

What  a revelation.



they will be forced at some point to go with the 2MB hard fork, we can't remain forever at 1MB this is a 100% sure thing

i want to ask what is the exact reason why miners are aginst segwit now?

Hard fork with larger blocksize can be done without segwit, segwit is not needed at all to go to a larger blocksize.
(That is the myth spread by BTC core.)

Segwit will allow LN, to run Offchain Transactions, with more control over onchain transactions placement.
Miners will not receive any transaction fees for Offchain Transactions.

LN with Segwit, will probably give LN the ability to actually choose which block their very few onchain transactions is included in,
meaning they would be able to cut the Chinese miners completely out of all fees from LN.
(LN onchain Transactions will be only included in one of their 30% controlled BTC miner's Blocks.)

LN without segwit will not have that capability, which leaves the Chinese Miners in control of which block includes a transaction.
Segwit is a Power Grab by BTC core to control the transaction fees, nothing more nothing less.

 Cool

BTC core is in the driver seat and have done lots of good things and now they look failing to provide such a nobrainer solution everybody must accept.

This might be the issue of a king loosing the ground after winning endless battles.

They are on own logics now and spread fear for the hardfork of the blockchain, code and bitcoin but this has lead to the even worse hardfork in the community.

Who can fix that and how?
legendary
Activity: 1092
Merit: 1000
January 01, 2017, 07:23:13 PM
Segwit's been out now, what, six weeks?  And still 70% of block solvers are voting to keep block size at 1MB.  

What  a revelation.



they will be forced at some point to go with the 2MB hard fork, we can't remain forever at 1MB this is a 100% sure thing

i want to ask what is the exact reason why miners are aginst segwit now?

Hard fork with larger blocksize can be done without segwit, segwit is not needed at all to go to a larger blocksize.
(That is the myth spread by BTC core.)

Segwit will allow LN, to run Offchain Transactions, with more control over onchain transactions placement.
Miners will not receive any transaction fees for Offchain Transactions.

LN with Segwit, will probably give LN the ability to actually choose which block their very few onchain transactions is included in,
meaning they would be able to cut the Chinese miners completely out of all fees from LN.
(LN onchain Transactions will be only included in one of their 30% controlled BTC miner's Blocks.)

LN without segwit will not have that capability, which leaves the Chinese Miners in control of which block includes a transaction.
Segwit is a Power Grab by BTC core to control the transaction fees, nothing more nothing less.

 Cool
legendary
Activity: 3248
Merit: 1070
January 01, 2017, 02:49:22 AM
Segwit's been out now, what, six weeks?  And still 70% of block solvers are voting to keep block size at 1MB. 

What  a revelation.



they will be forced at some point to go with the 2MB hard fork, we can't remain forever at 1MB this is a 100% sure thing

i want to ask what is the exact reason why miners are aginst segwit now?
legendary
Activity: 3038
Merit: 1660
lose: unfind ... loose: untight
December 31, 2016, 11:46:16 PM
BTC core could have ...

The Bitcoin Foundation at one time seemed to have a certain existence with wide ranging influence as well.

#justsayin'
legendary
Activity: 1092
Merit: 1000
December 31, 2016, 11:43:51 PM
2a - One selling point of segwit is that it is effectively increasing the block size. If this is not 'something that needs to be fixed', then why is segwit being sold this way?


Segwit only real purpose is to enable the way for Lightening Network (Offchain Transactions),
even thru it is possible to implement a version of LN without segwit.
Using LN with Segwit , will move the power from the Miners to the ones controlling LN.
Without segwit, miners will still be the stronger force.
Power Grab by BTC core , pure & simple.

Chinese mining pools agreed to accept up to an 8MB blocksize,
BTC core could have hard forked it and been done for years, because the mining pools would have updated almost overnight.

Instead the shenanigans with pushing segit as a solution was just a trick, to try and get people to activate it so BTC core could assume power with LN.
Chinese Mining Pools did not fall for the trick , which is why segwit will never have more than ~30% ,
last count Chinese Mining Pools totaled were ~67%, which means they are in charge of BTC.
BTC=Better Trust China


 Cool
newbie
Activity: 55
Merit: 0
December 31, 2016, 07:21:32 PM
You keep talking about facts of which none are ever presented. Can you please list your facts below as to why SegWit is necessary?

Have you ever heard the phrase "If it ain't broke don't fix it?"
1) It is broken. TX malleability is a existing vulnerability. I don't expect you to be aware of this though.
2) If we follow that 'phrase', the same can be said for increasing the block size limit.
2.1) The same can be said for anything proposed by Classic (FlexTrans) & BU (random 'improvements').
1 - TX malleability is only a vulnerability for those that take actions on transactions that have not yet confirmed. The simple fix to this is to not rely upon unconfirmed transactions unless the person you are accepting the transaction from can be trusted with at least the amount of the value of the transaction.

To my knowledge, the biggest problem with TX malleability is that it can be annoying when transaction IDs get changed. Can you point to any financial losses that resulted from TX malleability?

2 - Blocks frequently are effectively 1 MB in size, sometimes for days at a time. Even if this was because of "fake" transactions, the attack was possible because of the low block size, and would have been less effective had the maximum allowable block size been greater.

2a - One selling point of segwit is that it is effectively increasing the block size. If this is not 'something that needs to be fixed', then why is segwit being sold this way?
legendary
Activity: 1638
Merit: 1001
December 31, 2016, 01:27:46 PM
Segwit's been out now, what, six weeks?  And still 70% of block solvers are voting to keep block size at 1MB. 

What  a revelation.

legendary
Activity: 4410
Merit: 4788
December 31, 2016, 09:27:51 AM
You keep talking about facts of which none are ever presented. Can you please list your facts below as to why SegWit is necessary?

Have you ever heard the phrase "If it ain't broke don't fix it?"
1) It is broken. TX malleability is a existing vulnerability. I don't expect you to be aware of this though.
2) If we follow that 'phrase', the same can be said for increasing the block size limit.
2.1) The same can be said for anything proposed by Classic (FlexTrans) & BU (random 'improvements').

lauda.. do you even understand malleability.
and how it is not a problem in multisig, and how RFB CPFP are the replacements for double spends. meaning malleability is not a big deal, because solving malleability solves nothing.

its been an 'issue' but not a big deal problem... after all ~2000-2500tx every ten minutes for the last 2 years have had no massive complaints/problems. the only time it was of any drama was a couple years ago when kerpeles used it as a fake reason to embezzle funds and blame bitcoin.

even the latest exchange embezzlings, which fake cried hacks didnt use the malleability screams of lost funds, because they know people would laugh at them because of the obvious fake excuses if they did blame malleability

wake up and research. learn that people have found work arounds and ways to double check and reduce risk

its time you spend less time being spoin fed on IRC and instead do your own independant research
Pages:
Jump to: