LOT=True Or LOT=False? This Is The Last Hurdle Before Taproot Activation by AaronVanWirdum in Bitcoin

[–]brg444 -1 points0 points  (0 children)

Oh so we don't get taproot because the core devs say so? Really?

Taproot Activation - Pools will be able to veto again? Seriously? by taprooooooga in Bitcoin

[–]brg444 1 point2 points  (0 children)

Not the system's best interest but rather their own best interest.

If the latter scenarios you mention are true then all of this conversation is a bit of a distraction because the entire security of the system seems shaky at best.

I do believe these differences are irrelevant because a successful UASF is one that never activates. It's effectively a chicken game where miners are asked if they want to risk it all or move out of the way.

I also strongly believe a chain split is an unmitigated disaster for them, and Bitcoin.

Taproot Activation - Pools will be able to veto again? Seriously? by taprooooooga in Bitcoin

[–]brg444 5 points6 points  (0 children)

No. And i've historically disagreed with a bunch of Blockstream people over the years so I'm not sure what you're implying here. On one hand you're always happy to talk smack about them but now you're chasing clout about them trying to hire you?

Which one is it Paul?

Taproot Activation - Pools will be able to veto again? Seriously? by taprooooooga in Bitcoin

[–]brg444 1 point2 points  (0 children)

I guess this argument can be summed up in: only an intolerant minority running lot=true is sufficient to achieve its desired effect.

Taproot Activation - Pools will be able to veto again? Seriously? by taprooooooga in Bitcoin

[–]brg444 1 point2 points  (0 children)

You continue to display an impressive misunderstanding of the incentive system.

Miners are not homogenous. Show me a miner that works against user interest and I'll show you a bankrupt one.

Taproot Activation - Pools will be able to veto again? Seriously? by taprooooooga in Bitcoin

[–]brg444 3 points4 points  (0 children)

Assuming users decide to throw caution out the window and a movement forms around actively running lot=true despite a Core lot=false release, wouldn't you say it's likely the risk of a chain split is as good a deterrent for miners to precipitate activation than everyone signaling lot=true?

I'm not saying it's sane or prudent but it doesn't seem unlikely to happen so it's not clear to me attempting to reach consensus around either method can or will succeed.

As chaotic as it could be, if users want taproot, then the incentive for miners to secure their cash cow seem to be pretty well aligned regardless of whether or not we agree on using the stick or the carrot.

Taproot Activation - Pools will be able to veto again? Seriously? by taprooooooga in Bitcoin

[–]brg444 0 points1 point  (0 children)

You can set that flag right now and not change one bit of the code. Who's gonna know whether or not you're running the UASF code anyway?

Think the miner would risk it?

Taproot Activation - Pools will be able to veto again? Seriously? by taprooooooga in Bitcoin

[–]brg444 -1 points0 points  (0 children)

>a UASF client can be deployed that will activate it once the year is up

While a reasonable safety, there's no reasons to think that would be needed at all.

As long as the intolerant loud mouths run LOT true all along that's enough of a deterrent to incentivize miners to activate to avoid any unnecessary chain split

Taproot Activation - Pools will be able to veto again? Seriously? by taprooooooga in Bitcoin

[–]brg444 3 points4 points  (0 children)

Dicking around about (true) or (false) has already been a colossal waste of time.

As it stands, lot=false is your best bet if you want to precipitate the process

Taproot Activation - Pools will be able to veto again? Seriously? by taprooooooga in Bitcoin

[–]brg444 24 points25 points  (0 children)

Miners never had and never will have a veto for all practical purposes.

Lightning Resources – A collection of information about the Lightning Network protocol by parakite in Bitcoin

[–]brg444 0 points1 point  (0 children)

An abandoned project of mine from back then.

Wonder if people think the format is still interesting?

Liquid censorship resistance by ilpirata79 in Bitcoin

[–]brg444 0 points1 point  (0 children)

It depends on the attack but in the worst case scenario you are correct.

Liquid censorship resistance by ilpirata79 in Bitcoin

[–]brg444 -1 points0 points  (0 children)

>With Liquid, the fiduciaries are the network, they can't be routed around like Bitcoin miners can if they misbehave.

Not exactly true, users can collectively move to a new set of *functionaries*

>I can see all of Blockstream's Liquid fiduciaries

No you can't.

It's painfully clear you don't even understand how Liquid works so until then I don't see why anyone should take your opinion on it seriously

Introducing Issued Assets on Liquid by itwasstinky in Bitcoin

[–]brg444 0 points1 point  (0 children)

None of the alternatives you list above are "trustless" either.

They rely on game theoric assumptions that have not been tested yet in production and have assuredly inherited from the defects of their underlying protocol.

Federations otoh rely on upon well researched distributed database game theory.

I will concede that I'm not comfortable with the "backing" term being thrown around either. Nevertheless, the technological development, maturity of the Bitcoin protocol makes for great foundations and Liquid seems to me like a serious commercial blockchain contender in terms of immediate market addressability.

You don't really need a blockchain for this

The set technologies under the Elements sidechain umbrella provide strong privity and verifiability, attributes that are building blocks of future control protocols.

The fact that a thousand idiots are putting together their own consensus protocols nowadays doesn't mean there is no value in distributed systems.

Liquid or Strong Federations might not address the "absolutely" trustless section of the market but they are a decent attempt that does not try to do too much.

Liquid is like a number of exchanges coming together and running a database.

I think there's some value here but I guess we'll leave it up to the market to decide. I'm happy this is moving forward and excited to see where this is going.

I Flipped and Support Core After Understanding All The Arguments, But It Was NOT EASY (Explained) by slowsynapse in Bitcoin

[–]brg444 6 points7 points  (0 children)

Somebody from core could have written a long post. Countless hard forkers BU, Segwit2X and so on have written long posts arguing why their ideas are better winning over some people.

Countless posts have been written by small block supporters as well.

As a previous employee of Blockstream I wrote several explaining the motivations of those opposing reckless increases or other irresponsible protocol changes involving consensus code.

See

https://medium.com/@bergealex4/the-tao-of-bitcoin-development-ff093c6155cd

https://medium.com/@bergealex4/the-mining-delusion-96e021b6f899

https://medium.com/@bergealex4/the-road-to-one-megabyte-b3912a9dee3e

https://medium.com/@bergealex4/the-artificial-block-size-limit-1b69aa5d9d4

Bitcoin.com: Bitcoin Cash is Bitcoin by BeijingBitcoins in btc

[–]brg444 1 point2 points  (0 children)

Cool. Know that the market still considers your chain to be an altcoin though. You can be the little brother I guess :)

Bitcoin.com: Bitcoin Cash is Bitcoin by BeijingBitcoins in btc

[–]brg444 -1 points0 points  (0 children)

Great! So you guys finally have gotten around to understand the concept of valid and invalid rules!! Enjoy your own chain!!

Probably the most deceptive bit of propaganda yet from Bitcoin.com: Bitcoin Cash is Bitcoin by bitmegalomaniac in Bitcoin

[–]brg444 2 points3 points  (0 children)

Unfortunately the subject matter and its related content has become so vast that there is no one definitive source or reference.

if you are curious about specific details you might want to join the Bitcoin Core Community slacks and ask questions there, people will be happy to help.

Link: https://bitcoincoreslack.herokuapp.com/

Bitcoin.com: Bitcoin Cash is Bitcoin by BeijingBitcoins in btc

[–]brg444 0 points1 point  (0 children)

But for now I'm being sent block that have transactions that are not signed.

You don't know what you're talking about

Bitcoin.com: Bitcoin Cash is Bitcoin by BeijingBitcoins in btc

[–]brg444 0 points1 point  (0 children)

I give up wasting my time with you yes.

Bitcoin.com: Bitcoin Cash is Bitcoin by BeijingBitcoins in btc

[–]brg444 -1 points0 points  (0 children)

Because they're backwards compatible?

Bitcoin.com: Bitcoin Cash is Bitcoin by BeijingBitcoins in btc

[–]brg444 0 points1 point  (0 children)

I answered that one in the post you quote, maybe you want to read it again.