Topic: The Barry Silbert segwit2x agreement with >80% miner support. - page 53. (Read 120014 times)

OK, now I see what you're getting at. (However, I still maintain that this is no different than a standard Bitcoin transaction where having a given address that has 32 mBTC, sending me 2 mBTC, and the remaining 30 mBTC goes to your change address; you still can't spend the remaining 30 mBTC until it hits a block.)

Again, that's getting into the use-case merits level of LN, which I think is moot to this thread and to Bitcoin in general.

That being said, I find that adding an opcode (or even a couple opcodes) to the protocol so that people can willfully engage in something like that is not a "bad" thing, in and of itself. The merits of a specific use-case of an extension to a protocol aside, it's generally a "good thing" to add potential use-cases that have minor overhead cost to the protocol itself.
I'm not sure you and I will find "common ground" on LN, because we look at it differently. You're focused in on the "worse case scenarios" of a particular use-case, whereas I look it from a pragmatic perspective of "will this extension to the protocol have a net gain to the protocol?" (and in my mind the answer is "Yes", and that answer doesn't specifically involve LN). I think that the change to the protocol will allow other "things" beyond LN to potentially expand the usage of Bitcoin as a protocol in the future.

This can only illustrate their inconsistent stance, then.  A UASF only makes sense if there is a genuine chain split.  We've been hearing the stories about the need of consensus, and the "danger of hard forks" because, goodness me, that could cause a chain split.  But now they are in favour of forcing a chain split, even though with what technically is a soft fork.  They seem to admit that their whole argument for "soft forks only" was just an inconsistent stance with a hollow argument.

A consensus hard fork is much less dangerous than a forced split with a soft fork.

Yes, but the coins committed in that channel will not become spendable before the waiting period.  So you cannot commit them in another channel, and you cannot use them in a classical transaction, before that period.  They are unspendable UTXO before the end of the waiting period (that's exactly what the waiting period is made for !).  Contrary to banks, bitcoin does look at dates.

So, if I was planning to buy 16 hot dogs with you, I have to commit right now the price of 16 hot dogs (say, 32 mBTC) in a channel with you.  If I buy one hot dog, I send you a LN transaction in that channel so that you are now the owner of 2 mBTC, but my other 30 mBTC are still committed in that channel.  If I find the hot dog you sold me, disgusting, I will change my mind, and want to buy my 15 other hot dogs elsewhere, but my 30 mBTC are still locked up in that channel with you.  

I can do 2 possible things:
a) use the LN to pay another hot dog provider through you ; but I'm depending on you to ALLOW me to do that payment.  You can always refuse/delay/.... any LN payment that goes through a channel with you.  If you refuse to transmit my payment, the other hot dog seller will not be paid.  You might have an incentive to not process transactions for your competitor.  And I can't do anything else with my 30 mBTC in the channel with you as long as I keep that channel.

b) settle the channel with you, to get my 30 mBTC free.  But then I have to pay an on-chain fee, I have to hope that my transaction will get included in the chain, and I won't be able to spend these 30 mBTC before the waiting period.

So once my 30 mBTC are locked up in the channel with you, and you don't give me the permission to spend them with your competitor, I have no way to pay my hot dog with your competitor using my 30 mBTC within the waiting period.

That's about the most intelligent sentence I've read in the whole 34 pages of this thread. 

I will be honest the bolded portion concerns me. Forcing a chain split should be utterly off of the table. It is anathema to the very concept of consensus based management. I personally see very little difference between a split forced by a mining consortium over the objections of the larger community and a split forced by a majority of USAF nodes over the objections of the mining community and big block supporters.

The core developers have taken the role of intellectual leaders/stewards of bitcoin. A prime if not the prime duty of this job is to guide development in such a way that overall consensus is maintained. I fail to see how UASF is anything other then a lazy attempt to use force because compromise and consensus are "just to hard".

In the next week or two I will have my node up and running. Not it makes much difference but I will be using that node to oppose whichever party is first to try to "force" this issue. If that is BIP148 I will be running a non UASF node. If it is a contentions miner hardfork then I will support of whatever proof-of-work change or other countermeasures are deployed in response.

The status quo expensive transactions and all is far better than a bitcoin that breaks into pieces.

Indeed. Veruca 'core' Salt has decreed.

In the simplest terms, yes there is a "waiting period", however, that period (to the best of my understanding) comes before the transaction is finalized.

Since everyone seems to be fond of the traditional banking examples, the best way to term it is that LN is like writing post-dated checks.
Over-simplified, but:
You write the post-dated check with the understanding that it will not be cashed before that time. With LN, that post-date allows you both the chance to "rip up" the check and write a different check for a different amount (and the 1st check no longer exists). Much like with real post-dated checks, the holder can, at any time, deposit the check and the date becomes irrelevant (because banks stopped looking at dates long ago). LN allows both sides to "walk away" at any given time (I want no more hot dogs or you don't want to sell me any more) and thus "finalizing" the most recent transaction.

There is no "one sided" to it (or any commercial transaction), because it is a valid transaction.

I thought that every form of one-sided settling ALWAYS included a waiting period.  I don't see how it can work without.  Because the "settlement" of today, is the "scamming broadcast" of tomorrow.   If I had the possibility to settle one-sided and have my stash available IMMEDIATELY, the security in the LN channel would be gone, no ?  I don't see how a one-sided (honest) settlement can NOT include a waiting time.

Am I alone in the belief that: piece by piece, the all of the code that Core wants will eventually be added (no matter what the rest of the world wants), Core will never give up on segwit (even if acceptance was under 1%), and it's all just a issue/matter of timing of implementation?

Actually, no. It's a opcode issue that would require a small code change. To change the protocol to allow LN has nothing to do with BU, segwit, or any other scheme (other than the fact that the change for segwit includes the "proper" opcode change to enable the use of LN). The fact that segwit has the opcode change has not a basis, in fact, for the mistaken belief that one has anything to do with the other.

Please do try to understand what you're on about before you try to correct me.

You dont know what they stand for and how to make Bitcoin mainstream.


You cannot troll me with youre cheap mind-game, you aint that smart enough.


PS - In case you missed it; It looks great on paper but in reality it only works on Segwitt the other solution like BU is bugged.

Out of order, but that's how my trains of thought work...

I'm not sure if that last bit is you talking about LN or Bitcoin. If you're talking about Bitcoin, that's precisely not how Bitcoin works. If address 1dakjfhkjkhjsadf has 10,000 BTC and wants to spend 2 mBTC, the entire 10,000 BTC is committed to the transaction (2 mBTC to the receiver and the rest [9999.998 BTC] either back to 1dakjfhkjkhjsadf or to a new "change address" [most usually the latter, depending on software]). With Bitcoin, you are, in fact, committing all of your BTC (from a given address) to each, and every, transaction.

If I buy one hot dog with a normal bitcoin transaction, I have to "commit" the price of ONE hot dog (that is to say, 2 mBTC in our example).  All the rest of my stash is uncommitted and I can use it how I want.  If I plan to buy *potentially* 16 hot dogs with a LN channel, I have to commit at least 16 times the price of a single hot dog, even if right now, I only buy one.  In your example, we had a direct LN channel between buyer of hot dogs and seller of hot dogs, so I have already to commit 32 mBTC even if right now, I only buy one, in order for them to be in my channel already.  That means, I only spend them to you, or *through* you in as much as you give me permission to do so.


100 blocks was, I think, the proposed "time lock" on settlements, so that you can send your "punishment transaction" on chain when your partner sent a scamming settlement before he can move the coins.

https://en.bitcoin.it/wiki/Lightning_Network

Obviously the biggest risk of BIP148 is a chain split, but it could be avoided with a split protection soft fork, BIP9 and most importantly this would then lower the SegWit lock-in percentage to 65% from 95%, plus this BIP provides a method for rapid miner activation of SegWit mandatory signalling ahead of the BIP148 activation date, August 1. Obviously, at the end everything depends on majority, but this option seems much safer.

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014508.html

Well, I had a thing worked out about hookers, but I'm trying to keep it all PG.

With any Bitcoin transaction, you must "commit all of your stash", so I'm not sure why this is even a mention.

As for the rest, it seems that you and I are working on different base information. I'm curious as to where you got this "100 blocks" from; could you link me to this....

It was vending machine.
Then coffee.
Now hot dog.
What next?

UASF is an interesting and very aggressive move towards forcing a split. I think the most pushed-for UASF in the form of BIP148 is far too aggressive too soon and is doomed. August 1 is very close and gives the compromisers very little time to formulate a meaningful and safe middle ground (read segwit + 2MB) to keep miners on board and avoid any splits. Should no compromise occur before that time, those signalling BIP148 will be left feeling very cold with almost no hashrate to support them, and a dead slow blockchain going nowhere. The proponents of BIP148 say there is nothing to lose and that those who are on the main chain will be the ones to lose when a reorganisation happens in the future and the uasf chain becomes the only active chain. I think this is fanciful given the absolutely minuscule miner support it currently has to create such a chain. The only realistic chance it has is if it is also coupled with the ridiculously destabilising move of changing proof of work since it will no longer need existing miner support. This of course then turns it into a hard fork as well...

What I think will happen is UASF will continue to be perceived as a threat that will make the existing players more likely to accept a compromise. The Silbert agreement was doomed from the start without any code or developers or core support but then again it was an overwhelming display of what the miners would agree to. UASF and specifically BIP148 has forced core developers to try and find that compromise point before any significant split could occur. In fact should this eventuate, and I believe it will, those who mine true UASF blocks from August1 before a compromise soft fork will be the only ones left on a dead end fork with a block chain that joins no one.

A large number of core developers are against BIP148 while most are for UASF in principle. UASF could in fact work without such an aggressive short time frame and core support but BIP148 is forcing the issue too soon with too little support.

UASF still doesn't appear to be gaining much in the way of traction.  Its supporters keep alluding to this 'snowball effect' to put pressure on miners but, apart from the odd spike which looks somewhat artificial, the node count is still only ~800 signalling BIP148.  But equally, things seem to have gone a little quiet on the SegWit+2MB side too.  It almost feels like there's no real impetus to be found anywhere.

If both ideas completely fail to break the deadlock (and extension blocks never even got off the ground), my hope is that people will take another look at SegWit+Variable and try to reach some sort of compromise around that.

Either...I've no clue in this cluster...just curious if it is gonna break the log jam in some manner for some real movement
or just die a slow death like the other options tossed around and being blocked by either party.

WE probably need a good dump in price back to 1k just to scare these dev whales of whatever flavor to suck it up and comprimise

but again, clueless on the coding arguements etc on what is best...doubtful eiher camp miners or bitcoin core ..in that anyone having

twiter wars is not serious about a solution

anyway just curious ..about the USAF angle