The Barry Silbert segwit2x agreement with >80% miner support.

[mindrust]

UASF is not just about upgrading to segwit.

UASF is a civil movement to remind those big companies that they don't mean shit if we users don't support their services. We can remind them they don't own bitcoin, but we users do. (that's what P2P is about)

Do you really think most users are caring about the details about Segwit? They want Bitcoin to work, period.

But you got something wrong there... bitcoin don't work

If you call min 5$ rip-off fee per transaction or from 20 hours to infinite hours of delay as "working", then yes it is working. (not as intended™)

A chain split is nothing near dangerous compared to what can have with Jihan in the future.

[ComputerGenie]

...BUT it seems the only way to hit the "greedy" miners and harm them...

Setting aside the fact that isn't how supply/demand works, another alternative is for everyone to just not pay "high" fees. If everyone stopped paying 300 then 100 would go back to being the new average. Users have raised the average fees, not miners, and the "greed" is designed into Core (i.e., the wallet already mostly scrapes the most profitable transactions first).

[ComputerGenie]

...If you call min 5$ rip-off fee per transaction or from 20 hours to infinite hours of delay as "working", then yes it is working. (not as intended™)..

See above, Core did that.

[Gyrsur]

...BUT it seems the only way to hit the "greedy" miners and harm them...

Setting aside the fact that isn't how supply/demand works, ...

i'm not talking about fees but talking about healthy markets. and China has no healthy market with this corrupt background.

[ComputerGenie]

i'm not talking about fees but talking about healthy markets. and China has no healthy market with this corrupt background.

So, in other words, you're all about spreading FUD. 

[mindrust]

i'm not talking about fees but talking about healthy markets. and China has no healthy market with this corrupt background.

You can't have a healthy conversation with that Chinese retard. He is probably working at Bitmain or smth. Just ignore him and don't answer.

He don't even something to say, all he does posting stupid smileys or writing one sentence bullshit which has no meaning and no contribuiton to the subject. > troll

[ComputerGenie]

I'm so over FUD and unsubstantiated "shill" claims from people that can't validate their own beliefs with facts and logic.

[d5000]

...Most support Segwit because it would reduce transaction fees...

Can we, please, stop peddling that myth?

Why is that a myth? In the short term, Segwit would almost surely reduce fees, with >2x the capacity of the old 1MB chain. Or what do you mean?

Do you really think most users are caring about the details about Segwit? They want Bitcoin to work, period.

If you call min 5$ rip-off fee per transaction or from 20 hours to infinite hours of delay as "working", then yes it is working. (not as intended™)

You didn't get my point.

Segwit+2MB solves the transaction fee problem the same way than SegwitUASF does, at least in the short term. Transaction fees with Segwit2x would even be smaller in the mid-term if after an hypothetical UASF there is no 2MB adjustment in one or another way.

That's why I don't think your assumption that the majority users are insisting on "Segwit alone" and are against "Segwit2x", is true. The majority support Segwit, that's clear for me, and not the BU approach. But the details - bit 1 or bit 4 and so on - are really insignificant.

Segwit2x, for me, is not ideal because it involves a hard fork and that should be avoided if possible. But with a large support by economy & miners I think the hard fork would go smooth.

[ComputerGenie]

...Most support Segwit because it would reduce transaction fees...

Can we, please, stop peddling that myth?

Why is that a myth? In the short term, Segwit would almost surely reduce fees, with >2x the capacity of the old 1MB chain. Or what do you mean?
....

You seem to be missing a "reality factor" in your process of thinking about this.
Will segwit reduce the weight of a fee calculation for a given transaction? Yes.
Will segwit reduce the fees someone is willing to pay for a given transaction? Maybe.
Will segwit reduce the average fee when people manually set "high" fees to be at the "top of the list"? No.

Fees haven't "magically" gone up. Each time someone sets a higher than average fee for their transaction, and it gets put into a block, the average moves upward. Segwit isn't going to change logic or human behavior.


Edit:Even if we had 10PB sized blocks, if 1000 people set transaction fees to pay 0.1BTC per byte, the new average fee would be ~0.1BTC per byte. Block size and fees aren't 100% related outside of propaganda.

[The One]

...Most support Segwit because it would reduce transaction fees...

Can we, please, stop peddling that myth?

Why is that a myth? In the short term, Segwit would almost surely reduce fees, with >2x the capacity of the old 1MB chain. Or what do you mean?
....

You seem to be missing a "reality factor" in your process of thinking about this.
Will segwit reduce the weight of a fee calculation for a given transaction? Yes.
Will segwit reduce the fees someone is willing to pay for a given transaction? Maybe.
Will segwit reduce the average fee when people manually set "high" fees to be at the "top of the list"? No.

Fees haven't "magically" gone up. Each time someone sets a higher than average fee for their transaction, and it gets put into a block, the average moves upward. Segwit isn't going to change logic or human behavior.

Capacity will only go up if all users use segwit. If they don't then capacity will remain the same and the fees will not go down.

[ComputerGenie]

Capacity will only go up if all users use segwit. If they don't then capacity will remain the same and the fees will not go down.

Can you support the claim that fees are proportionally related to size with an equation?

[dinofelis]

at the moment it's just a vote and on 08/01/2017 it will become a separated blockchain.

Technically, it will  not become a "separate" chain until the 1st segwit signaling block is found on/after 08/01/2017 (it becomes a "stopchain" instead of a blockchain). If no such segwit signaling block is found on/after 08/01/2017, it just stops at the point where the existing chain was and "orphans" all of the new non-segwit signaling blocks in it's own mind.

if the first UASF/BIP148 block is found on SlushPool on/after 08/01/2017 the chain will spilt. with this low hash power and the high difficulty the next UASF/BIP148 block will take a long time until the "wrong" difficulty is adjusted. but chain spilt will happen in every case on/after 08/01/2017.

But will this second block be a direct successor to the first block (a different prong) or will it just be, say, the 50th block on the unique chain, but the node not taking into account the 49 non-UASF blocks in between, but accept nevertheless the header chain ?

the second UASF/BIP148 block will be a direct sucessor to the first UASF/BIP148 and it will take a long time to find it because the difficulty is to high for this particular hash power on this UASF/BIP148 chain. --> this is the miner part with a UASF/BIP148 node.

the full node part with UASF/BIP148 will just see transactions in the UASF/BIP148 blocks on/after 08/01/2017.   

So the requirement is that some miners start making a DIFFERENT chain from 8/1/2017 onward ?  I thought it was only from 15/11/2017 onward.

[dinofelis]

at the moment it's just a vote and on 08/01/2017 it will become a separated blockchain.

Technically, it will  not become a "separate" chain until the 1st segwit signaling block is found on/after 08/01/2017 (it becomes a "stopchain" instead of a blockchain). If no such segwit signaling block is found on/after 08/01/2017, it just stops at the point where the existing chain was and "orphans" all of the new non-segwit signaling blocks in it's own mind.

Well, as I understood, some minority fraction of miners was supposed to fork away on a pure-segwit chain on 15/11.  In fact, the 8/1/2017, nothing particular will happen if I understood well.  I think one explained to me that the UASF nodes will not STOP on a non-segwit block, but will simply "not count" it in their percentage of segwit signalling, tricking themselves in thinking there's 100% segwit support, even though they accept non-segwit blocks too in the chain.

What was less clear to me was whether these nodes will also not consider *transactions* in these non-segwit blocks, or whether they will pretend that those transactions never occurred.

At the "switch-over point" (August 1st 2017 (epoch time 1501545600)), "Blocks that do not signal as required will be rejected".  So if the next 10 blocks do not signal "according to the existing segwit deployment", the UASF chain just "stops" until the 1st such signaling block.

Well, there remains something unclear about this, and when I ask, I get alternating answers

The explanations I heard before were these:

explanation 1:
---------------

On 1. August 2017, UASF only CONSIDER segwit-signaling forks on the main chain (but for one or other reason, they don't mind them being successors to non-segwit blocks).  In other words, there is still only ONE CHAIN, but the UASF node "picks out" only the segwit signalling blocks.
This gives the *impression* to the node, that all blocks are segwit-signalling, and hence ACTIVATES segwit on 11/15/2017.  From that point on, it wants a REAL SEGWIT-ONLY chain, and maybe some miners will fork off to make one, different from the main chain.  So the real forking only happens in November.

explanation 2:
---------------

On 1. August 2017, UASF activates segwit, and doesn't accept non-segwit blocks.  The only chain it can receive at that point, is a segwit-only chain, so maybe some miners will make one forking off on 1. August 2017.   (in other words, what is happening on 11/15/2017 in explanation 1, is already happening on 8/1/2017 in explanation 2.

I don't know which one corresponds to what is BIP148.

[Gyrsur]

https://bitcoinmagazine.com/articles/bitcoin-beginners-guide-surviving-bip-148-uasf/

[dinofelis]

I'm still hoping for a soft-fork-based 2MB+Segwit solution. That could be the holy grail and I'm sure it could also achieve 80% acceptance - even if some hardliners on the BU side probably wouldn't support it.

You can't have a soft fork and 2 MB.

[The One]

Capacity will only go up if all users use segwit. If they don't then capacity will remain the same and the fees will not go down.

Can you support the claim that fees are proportionally related to size with an equation?

It's simply supply and demand. Supply of capacity lower than the demand of capacity = higher fees. The concept of fee market is retarded, a concept based on devs not understanding economics and/or accountancy. Segwit capacity to accept more transactions can only happen is users use it. If users stick to the current means of transaction, the capacity will be the same.

[BillyBobZorton]

...Most support Segwit because it would reduce transaction fees...

Can we, please, stop peddling that myth?

Why is that a myth? In the short term, Segwit would almost surely reduce fees, with >2x the capacity of the old 1MB chain. Or what do you mean?

Do you really think most users are caring about the details about Segwit? They want Bitcoin to work, period.

If you call min 5$ rip-off fee per transaction or from 20 hours to infinite hours of delay as "working", then yes it is working. (not as intended™)

You didn't get my point.

Segwit+2MB solves the transaction fee problem the same way than SegwitUASF does, at least in the short term. Transaction fees with Segwit2x would even be smaller in the mid-term if after an hypothetical UASF there is no 2MB adjustment in one or another way.

That's why I don't think your assumption that the majority users are insisting on "Segwit alone" and are against "Segwit2x", is true. The majority support Segwit, that's clear for me, and not the BU approach. But the details - bit 1 or bit 4 and so on - are really insignificant.

Segwit2x, for me, is not ideal because it involves a hard fork and that should be avoided if possible. But with a large support by economy & miners I think the hard fork would go smooth.

There is an attempt to properly hard fork to 2MB with some Core devs involved. I would be ok with that as long as we get everyone on board. A HF without Core-backed software is dead on arrival, you also need the entire community to get ready, or else we risk an actual ETH-ETC scenario.

The NYC is bullshit and already failed, so there are attempts now to create something better.

Of course Bitmain bribed agents will not want to get rid of covert ASICBOOST so we'll end up with UASF anyway.

[ComputerGenie]

...Well, there remains something unclear about this, and when I ask, I get alternating answers ...

I don't know which one corresponds to what is BIP148.

When in doubt, read the BIP.

While this BIP is active, all blocks must set the nVersion header top 3 bits to 001 together with bit field (1<<1) (according to the existing segwit deployment). Blocks that do not signal as required will be rejected.

[ComputerGenie]

Can you support the claim that fees are proportionally related to size with an equation?

It's simply supply and demand. Supply of capacity lower than the demand of capacity = higher fees. The concept of fee market is retarded, a concept based on devs not understanding economics and/or accountancy. Segwit capacity to accept more transactions can only happen is users use it. If users stick to the current means of transaction, the capacity will be the same.

So, in other words, "no" you can't support your claim, you're just assuming what will happen (and ignoring the possibility that it will have exactly zero impact on fees).

[The One]

Can you support the claim that fees are proportionally related to size with an equation?

It's simply supply and demand. Supply of capacity lower than the demand of capacity = higher fees. The concept of fee market is retarded, a concept based on devs not understanding economics and/or accountancy. Segwit capacity to accept more transactions can only happen is users use it. If users stick to the current means of transaction, the capacity will be the same.

So, in other words, "no" you can't support your claim, you're just assuming what will happen (and ignoring the possibility that it will have exactly zero impact on fees).

Already have.
No such a thing. Nothing is ever static in economic.