Topic: Post your SegWit questions here - open discussion - big week for Bitcoin! - page 22. (Read 84845 times)

It's only been 2 months in BTC, so far.  quite a bit more can happen in 10 months, no?

Call it 'embarrassing then" if it does so before BTC. Not like the 2 parties of Devs in BTC land imho are ever gonna agree....stalemate with Core having the advantage
of a bit more land in this stalemate..but still a stalemate imho

But yeah would probably pump LTC a bit and just for a bit.

Just saying humans being humans ...looks like this imho

That was a soft fork; the post you cite even says so in no uncertain terms, and it also explains the difference between soft forks and hard forks. Are we supposed to think that you are illiterate?

You were making all kinds of points to attempt to normalize the idea about the greatness of hardforks as compared with softforks and attempting to assert that bitcoin had done it a lot in it's history, therefore, no big deal blah blah blah and some more bullshit characterizations.

Then Gmaxwell apparently concedes with you about the fact that ONE hardfork had actually taken place, but left it up to you to attempt to describe that even if you had gotten one fact correct, how getting that one fact correct would make any one of your other points to being close to correct - which apparently, you are having difficulties with achieving with either logic or additional facts.

And, further in this subsequent post, you go on some kind of additional tangent to again attempt to bring greater credence to the fact that you may have gotten one fact correct (that one successful hard fork had already occurred with bitcoin).  In the end, so fucking what. ... we all can agree that a hardfork had taken place under a certain set of circumstances historically, but those same certain circumstances do not necessary exist today or justify that a hardfork today would either be a necessary or prudent course of action.

In other words, the burden is still on you to describe with facts and/or logic concerning how a hardfork today would be a prudent or necessary course of action in bitcoin  in spite the conceded fact that a hardfork had occurred one time in the past under a specific set of circumstances that do not seem to be the circumstances of today, right?

what would you like to see interesting?
Except of speculation about exchange rates, there will be nothing "interesting" there.

My source is cited (blockchain blog, LOL)


I suppose now we can argue about the semantics of a hard fork versus soft fork? I'm not interested in that discussion, for the reasons cited above... Furthermore, I'm fine with being wrong on this trivial topic if that is the case. I don't feel being wrong about this would undermine my other comments, although it might distract some from them...
 

It looks likely LTC will incorporate seg witness first. That will be interesting indeed.

That is totally untrue.     What should people think of the rest of your comments?

Thanks for the reply. Mostly your critique is semantic in nature. I can't quibble about minor details.

When I say "devs in general" I mean "software developers", and I'm simply stating what I believe is common knowledge. I didn't say anything about what Bitcoin Core devs believe. However, you are a Core dev, and you are in fact engaging in semantic and technical arguments in this very thread... This is often where "devs" can lose sight of the bigger picture, which IMHO is: Segwit won't be adopted, a post-mortem reflection on what went wrong would perhaps be a good idea, the simplest path forward if we can drop the egos and the anger is a one-line code fix to increase blocksize, etc.

I think you're making assumptions.


nullc was trolling critics pretty hard on this forum and reddit. Mostly I agreed with his criticisms, but did not agree that Segwit was the way forward.


I'm not sure what is FUD about the statement "bitcoin has hard forked several times before"? Also, an unintentional hard fork is much more dangerous than a planned one.

Bitcoin hard forks happened on On August 15, 2010, and March 12, 2013. https://blog.blockchain.com/2016/02/26/a-brief-history-of-bitcoin-forks/

Segwit signalling did not peak at all. It went up and plateaued at ~26%, very different from peaking.

Getting around the malleability problem is far harder than you think, and implementing segwit is far easier than you think. Segwit is very well documented and the Core devs are very responsive to questions regarding segwit.

You are not one of the devs nor do you seem to have participated in anything related to discussion with the devs. You cannot make these statements about what the devs believe because you are not them. Do not state your own opinions as if it were fact.

I don't think that you have followed Bitcoin development nor spoken with the devs before. At no point has Core called any critics invalid. They invite constructive criticism and will explain why someone's criticism is incorrect or how they addresses the issues.

Those who just shout and make noise but don't do anything constructive are dismissed because they are not being constructive but rather just a nuisance preventing work from actually being done.

Segwit is not obscure. All of the details of segwit are very well documented and you can find out any of the details by just asking the devs. Segwit is also not very complicated. There is a lot of documentation because there is a lot to it, but that does not mean that it is complicated. In fact, if you know how Bitcoin works technically, you can very easily understand how segwit works.

Not really. Previous soft forks have taken much longer to activate than has already passed for segwit.

This is simply incorrect. Bitcoin has never hard forked before intentionally. There has been one singular hard fork that occurred in 2013 due to a bug. That was completely accidental. Bitcoin has never hard forked before, but it has had multiple soft forks.

This is the kind of FUD and misinformation that people spread and it really needs to stop.

I don't think it's feasible that Segwit adoption will reach past 30%, given that it peaked at 25% a few months ago. Consensus won't be reached, and the soft fork won't happen.

I think it's fair to say that refactoring hundreds of thousands of lines of bitcoin support code and then fixing the inevitable bugs is far more work than continuing to work around the well-defined malleability problem.

Devs in general act arrogantly about technical issues for a number of reasons:
* because the best solution must be argued decisively to win
* because they know their sh*t
* because it's their primary way of asserting their manhood.

Before Segwit, Core devs had never released code that wasn't adopted. This caused them to believe that they represented the de facto consensus of the bitcoin community, despite loud screaming that they didn't. To core's credit, much of the screeching WAS technically misinformed, FUD, trolling, and possibly sabotage. However, they may have overstepped the line in labeling all critics invalid. Now it's clear to everyone that the masses won't simply follow Core to the end of the earth with an obscure and complicated soft fork.
 
The Core team is technically far superior to any (known) rivals, but they are only somewhat correct about what issues exist in the entire bitcoin landscape (and there may well be issues that may not be spoken of, but are influential in the decision-making process...). Core was INCORRECT about what remedies the issues require and what priorities they occupy. All of this has been demonstrated in the failed Segwit push. Merely 25% adoption is a resounding defeat and a clear rejection of this soft fork. That said, I'm very sorry for the wasted effort from the team, and very much appreciate Core's continuing commitment to development.  I hope devs were able to sell some coin this month!



Sorry, I may have the versions wrong.

Hard forking is very simple technically, although somewhat problematic logistically. However, in this day and age of rapid communication and the sheer mass of geeks at the ready to handle the task, I believe we can accomplish it in just a few days of pain. Bitcoin has hard forked several times in the past, and it will again in the near future. Everyone just needs to swallow their prides, manage their emotions appropriately, and DO IT. I suspect the BTC price would soar after a successful 2MB blocksize increase hard fork.

Thanks for the dialogue,

Yes. This is because Segwit is a soft fork.


No...... Segwit is a soft fork. Not a hard fork.



Horse power is not required. There is currently no propulsion tech in Bitcoin, I'm not convinced it needs it. You will have a difficult job convincing anyone.

I was just reviewing the release notes for v0.13.2 released about a week ago, and noticed a 'feature' where it would not be mandatory to use the SegWit addition even if enabled (if I understood that correctly).

Is this a very shrewd move to allow both SegWit and BU parties to climb down a couple of pegs to make negotiations easier and possibly get SegWit active without opposition having their hand forced to participate?  If so I'm very impressed with BitcoinCore.

It doesn't prevent the possibility of a hard fork of course, but at least it allows for people to watch and see how it works and add some more fixes (malleability for example) and push back the date for blocks becoming full to an extremely uncomfortable level, which may allow a new approach to reaching consensus.

I was never happy that consensus was set to 95% in the first place, as it in effect gives a minority the ability to block the majority (something we're seeing more and more in Society in general).  I'd prefer elegant design first, and pure horse power (BU) to add to that at a later date.

People like Roger Ver are not proponents of Seg Wit, but currently he doesn't seem to be in such strong opposition to it either.  Maybe something like this could be acceptable to Roger and those that have the same concerns with a preference for bulldozer solutions.

Am I understanding all this correctly or are there some obvious major flaws in my thinking that only I can't see?

Thank you all.

Thanks for taking the time Andrew!

Yes. There is an RPC command called addwitnessaddress. The parameter is an address from the wallet and it will create the necessary witness script and add it to the wallet for tracking. It will create the P2SH-P2WPKH address and return that to you.

Yes.

Hash160 your public key. Take that hash and tack on OP_0 and the length of the hash (20 bytes) to the front of the hash. The redeemscript for your p2sh address is 0x0014{hash160}. Take that redeemscript and make a p2sh address out of it.

I don't think any of the python bitcoin libraries have been updated yet.

I posted this on bitcoin stackexchange with no answer, so I'll try here.

How does one derive the Redeem Script for the new P2WPKH addresses? With existing P2SH it's revealed after providing N number of public keys through a `createmultisig` function in the bitcoin client. Is it the same, just provide a single public key through a `createwitness` or similar function?

Is it currently available for fiddling with on testnet?

I'm currently looking at the dev guide (https://bitcoincore.org/en/segwit_wallet_dev/) but still can't figure it out.


Can someone dumb down step 2 for me?
Is it possible to do currently with a library in python?

In what way has Segwit failed? It still has another 10 months to go before the activation period is up.

Not really. Transaction malleability is still a large problem and not irrelevant. There have been multiple times within the past year where transaction malleability has caused issues. Off the top of my head, I can remember once instance which screwed with a lot of users and wallets.

Dealing with malleability in wallets is still a major pain in the ass for both developers and users.

In what way are they becoming arrogant? In what way do the devs act arrograntly?

As I said earlier, segwit is far from dead. Segwit is moving forward. Hard forking, less so.

The changes since 0.12.1 are not just bug fixes. There have been numerous optimizations and additional features that overall make Core a better wallet and node software. People can use 0.13.0 and get all of those changes without using segwit. Core has already significantly diverged from the 0.12.x versions; we are almost two major releases ahead as 0.14.0 is coming out in a few months.

OK I have a couple more thoughts about the failed Segwit soft fork. Firstly, Segquit was a technical solution for political and human problems. Transaction malleability is a problem, but it's easily mitigated in the current environment and is largely irrelevant in the big picture. Core devs were rightly afraid to increase blocksize because people are spamming the blockchain, manipulating exchange rates through churn, and the blockchain is getting huge. Also devs (and miners) wanted everyone to pay higher fees for transactions. Not only do higher fees cut down on spam, they also get people accustomed to bitcoin not being almost free. This is what Satoshi predicted: as the coin issuance decreases, fees should increase. So core was right to delay the blocksize increase. Block space needed to be a scarce and valuable commodity.

However, Core devs were also becoming increasingly arrogant, because the masses had never rejected one of their releases, and the code forks like XT, Unlimited, and Classic were complete garbage.

This actually marks a very important moment, when core releases are no longer "God's word". That said, core is the only team can be reasonably expected to carry this code forward, as they are highly technically skilled and deeply invested in the technology succeeding.  Also, IMHO they have the right values and ethics that got bitcoin to where it is today - an amazing $10bil+ market cap cryptocurrency. I'm hoping that Core can accept Segwit's defeat, merge the latest bug fixes into the 12.1 code, hard fork the blocksize to 2MB or whatever, and MOVE FORWARD.

The alternative will be people continuining to run the 12.1 release with whatever issues it might have.

Here's to honest and open dialogue so that we may keep improving on this amazing technology!

No, just segwit support for compact blocks; and more compact block tests.

Were there not some Compact Blocks fixes in 13.1? Miners not signalling Segwit could make use of those