Bitcoin Forum
May 06, 2024, 01:20:41 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1] 2 »  All
  Print  
Author Topic: [bitcoin-dev] I do not support the BIP 148 UASF  (Read 3468 times)
praxeology (OP)
Newbie
*
Offline Offline

Activity: 18
Merit: 2


View Profile
April 15, 2017, 08:27:30 PM
 #1

Starting this thread in response to Gregory Maxwell's post on the bitcoin developer mailing list:

"I do not support the BIP 148 UASF"
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/014152.html

For people who would like to comment, but cannot due to tighter moderation restrictions on the dev mailing list.
1715001641
Hero Member
*
Offline Offline

Posts: 1715001641

View Profile Personal Message (Offline)

Ignore
1715001641
Reply with quote  #2

1715001641
Report to moderator
Each block is stacked on top of the previous one. Adding another block to the top makes all lower blocks more difficult to remove: there is more "weight" above each block. A transaction in a block 6 blocks deep (6 confirmations) will be very difficult to remove.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1715001641
Hero Member
*
Offline Offline

Posts: 1715001641

View Profile Personal Message (Offline)

Ignore
1715001641
Reply with quote  #2

1715001641
Report to moderator
1715001641
Hero Member
*
Offline Offline

Posts: 1715001641

View Profile Personal Message (Offline)

Ignore
1715001641
Reply with quote  #2

1715001641
Report to moderator
1715001641
Hero Member
*
Offline Offline

Posts: 1715001641

View Profile Personal Message (Offline)

Ignore
1715001641
Reply with quote  #2

1715001641
Report to moderator
praxeology (OP)
Newbie
*
Offline Offline

Activity: 18
Merit: 2


View Profile
April 15, 2017, 08:35:53 PM
 #2

Gregory Maxwell,

> If the goal is user activation I would think that the
> expectation would be that the overwhelming majority of users would be
> upgrading to do it, if that isn't the case, then it isn't really a user
> activated softfork-- it's something else.

Oh... so _that_ comes out.  I do not care what the majority wants.  The majority of people are thieves if they could get away with it.  Consider this: Lets propose a policy where the world can vote on taking half of the current Bitcoin owner's coins away and evenly distributing them to each world citizen.  Screw that, I've had enough of that.  Distributed money doesn't have to be that way.

Lets stop with the whole soft/hard fork designation when there are two disparate groups with conflicting preferences on a policy change.  Soft/Hard doesn't matter anymore.  Its just a fork.

I want SegWit.  I'm perfectly happy w/ forking the money supply I use from the people who don't want SegWit.  I just want replay attack prevention.

To all of you out there who want sound money, this is our song:
Green Day - Minority
https://www.youtube.com/watch?v=cDBlqu6KF4k

Cheers,
Praxeology Guy
jonald_fyookball
Legendary
*
Offline Offline

Activity: 1302
Merit: 1004


Core dev leaves me neg feedback #abuse #political


View Profile
April 16, 2017, 05:12:18 AM
 #3

I do not understand the distinction:

Quote
There have been some other UASF proposals that avoid the forced
disruption-- by just defining a new witness bit and allowing
non-upgraded-to-uasf miners and nodes to continue as non-upgraded

Any rollout of segwit must include majority hash power
to avoid a network split and that seems to be the overarching
factor here.  For that reason, I don't see how any UASF
makes sense.  If you want less than 95% consensus from
miners, then just do that.  No need to tap dance around it
with spoofable metrics and vague descriptions of "broad support".
 


praxeology (OP)
Newbie
*
Offline Offline

Activity: 18
Merit: 2


View Profile
April 16, 2017, 04:08:33 PM
 #4

jonald_fyookball,

Potentially the non-SegWit supporting miners could filter their blocks with a SegWit node... if they actually wanted to avoid a fork.  Its really hard to say what Bitcoin Unlimited signalling miners would do after SegWit validation rules were activated.
jonald_fyookball
Legendary
*
Offline Offline

Activity: 1302
Merit: 1004


Core dev leaves me neg feedback #abuse #political


View Profile
April 16, 2017, 05:47:58 PM
 #5

jonald_fyookball,

Potentially the non-SegWit supporting miners could filter their blocks with a SegWit node... if they actually wanted to avoid a fork.  Its really hard to say what Bitcoin Unlimited signalling miners would do after SegWit validation rules were activated.

Sorry I don't follow you.  Filtering the blocks doesn't prevent the fork at all if other miners support Segwit.

The One
Legendary
*
Offline Offline

Activity: 924
Merit: 1000



View Profile
April 17, 2017, 05:07:08 PM
 #6

I want SegWit.

Then what?

..C..
.....................
........What is C?.........
..............
...........ICO            Dec 1st – Dec 30th............
       ............Open            Dec 1st- Dec 30th............
...................ANN thread      Bounty....................

praxeology (OP)
Newbie
*
Offline Offline

Activity: 18
Merit: 2


View Profile
April 18, 2017, 04:04:43 AM
 #7

jonald_fyookball,

Above in my reply I propose a way that non-upgrading miners could continue to mine non-segwit blocks while still verifying SegWit blocks, which would avoid a chain split.  You claimed that such was not possible, I showed how it was possible.

=============

The One,

Policy: Rules that a node performs on block candidates in order to decide whether a block should be accepted into their block "tree", and then more rules that decide which branch tip describes the current ledger.

Soft Fork: A change to policy that is more constraining.

The purpose of BIP9 is to activate a Soft Fork that almost every miner wants without risk of a chain split (fork).  If a significant portion of miners (maybe 5% or more) do not want the policy change, then BIP9 fails.  Then we decide if we want to propose something new, or if we should cause a fork (via user activated policy change).

The next step is to User Activated Soft Fork.  I'm not too particular on which method is used to get SegWit activated.  Whatever (reasonable) option BitFury goes with, I'm in.

Cheers,
Praxeology Guy
cryptoanarchist
Legendary
*
Offline Offline

Activity: 1120
Merit: 1003



View Profile
April 18, 2017, 04:15:29 AM
 #8

People clamoring for UASF don't understand how PoW works.

I'm grumpy!!
jonald_fyookball
Legendary
*
Offline Offline

Activity: 1302
Merit: 1004


Core dev leaves me neg feedback #abuse #political


View Profile
April 18, 2017, 04:34:04 AM
 #9

jonald_fyookball,

Above in my reply I propose a way that non-upgrading miners could continue to mine non-segwit blocks while still verifying SegWit blocks, which would avoid a chain split.  You claimed that such was not possible, I showed how it was possible.
 


You are misinformed.

Even with majority hashpower behind segwit, a non segwit miner cannot verify segwit blocks.

From bitcoincore.org:

Quote
so you may continue producing non-segwit blocks indefinitely. However, once segwit activates, it will be possible for other miners to produce blocks that you consider to be valid but which every segwit-enforcing node rejects; if you build any of your blocks upon those invalid blocks, your blocks will be considered invalid too.

The implicit assumption here is that the minority non-segwit miner will rejoin the main chain and not split off.  If the segwit chain is the minority hashpower chain, they will either have to abandon segwit, or split off.

Segwit transaction types are meant to be backwards compatible, so the first block will validate, but later on, the outputs and inputs will be different.  As soon as a transaction is sent from an address with an insufficient balance, that's when the split will occur.




praxeology (OP)
Newbie
*
Offline Offline

Activity: 18
Merit: 2


View Profile
April 18, 2017, 05:17:23 AM
Last edit: April 18, 2017, 08:03:01 AM by praxeology
 #10

jonald_fyookball,

Potentially the non-SegWit supporting miners could filter their blocks with a SegWit node.

I don't know how you can go and call me "misinformed" when you fail to read my post.  bitcoincore.org is not divine truth.  I came up with a solution that they didn't consider.

Sorry for my frustration with you.  Have a nice day.

cryptoanarchist,

Each Bitcoin Node has a Policy chosen by its operator.  Anybody can produce block candidates that conform to a node's policy.  A node will look for the chain of blocks with the greatest PoW THAT MEETS ITS POLICY.  Differences in node policy can result in chain splits.  There is nothing stopping long lasting chain splits, where each is its own separate money supply/ledger.

In fact, alt coins can be considered Bitcoin nodes that adopted a different Policy, who forked at or before the Bitcoin genesis block.

Miners are motivated to increase their mining work on a coin until the following equation equalizes:

Energy Cost + Capital Rent + Labor ~= block bonus + transaction fees

So as long as a branch's coins are worth something to somebody... they will be mined.

Cheers,
Praxeology Guy
gmaxwell
Moderator
Legendary
*
expert
Offline Offline

Activity: 4158
Merit: 8382



View Profile WWW
April 18, 2017, 07:41:57 AM
 #11

As soon as a transaction is sent from an address with an insufficient balance, that's when the split will occur.
This is a profound misunderstanding of how Bitcoin works, there are no 'balances' in the system.

And unmodified non-segwit miners will not initiate a split under any condition.

Quote
Any rollout of segwit must include majority hash power
No, that is one sufficient condition, it can instead include basically all of the users (in particular, economically significant users). Either are sufficient alone.  The users define what are the miners and if the user define mining to include segwit, it does... from their perspective it is impossible to violate the rules, and any miner that tries just stops existing-- just as litecoin miners do not exist as far as Bitcoin users (and their nodes) are concerned today.
tomtomtom7
Jr. Member
*
Offline Offline

Activity: 38
Merit: 18


View Profile
April 18, 2017, 08:35:58 AM
Last edit: April 18, 2017, 11:31:41 AM by tomtomtom7
 #12


And unmodified non-segwit miners will not initiate a split under any condition.


I was under the impression that the concept of standard vs non-standard transaction was a matter of local policy, to - among other things - simplify softfork upgrades.

Every miner is still free to accept any non-standard transactions, and can safely accept and include them as a service for example to collect higher fees.

Do I understand that you consider rejecting non-standard transactions a requirement for compliance?

Tomas
Bitcrust
jonald_fyookball
Legendary
*
Offline Offline

Activity: 1302
Merit: 1004


Core dev leaves me neg feedback #abuse #political


View Profile
April 18, 2017, 12:49:26 PM
 #13

As soon as a transaction is sent from an address with an insufficient balance, that's when the split will occur.
This is a profound misunderstanding of how Bitcoin works, there are no 'balances' in the system.


I am aware that are no actual balances.  I was abstracting this out of the conversation just like a wallet
can calculate a balance to display to the user. The point is still valid:  Non-segwit chain vs segwit chain
can show different "balances" on an address, or spent/unspent outputs if you want to be more precise.

Quote
And unmodified non-segwit miners will not initiate a split under any condition.

Yes, because "blocks that you consider to be valid but which every segwit-enforcing node rejects"
will be orphaned as the longest chain prevails. 


Quote
Quote
Any rollout of segwit must include majority hash power
No, that is one sufficient condition, it can instead include basically all of the users (in particular, economically significant users). Either are sufficient alone.  The users define what are the miners and if the user define mining to include segwit, it does... from their perspective it is impossible to violate the rules, and any miner that tries just stops existing-- just as litecoin miners do not exist as far as Bitcoin users (and their nodes) are concerned today.

You chopped the part of my quote where I said "to avoid a network split".  I understand the distinction you make, but many non technical people may not.  If all the 'economic users' loved Segwit but a majority group of miners refused to go along with them, there would be a split.




achow101
Moderator
Legendary
*
expert
Offline Offline

Activity: 3388
Merit: 6581


Just writing some code


View Profile WWW
April 18, 2017, 01:41:57 PM
 #14

Yes, because "blocks that you consider to be valid but which every segwit-enforcing node rejects"
will be orphaned as the longest chain prevails. 
No, unmodified non-segwit miners will be producing valid blocks and their blocks will still be accepted. Segwit transactions are considered by non-segwit nodes as being non-standard. An unmodified non-segwit miner means that they have not changed any of the local node policy rules, which include the standardness rules. As long as they are following the standardness rules, they will not be mining segwit transactions and thus their blocks will not be invalid. These miners will not have their blocks orphaned unless they mine a segwit transaction, but that will only happen if they modify their standardness rules.

jonald_fyookball
Legendary
*
Offline Offline

Activity: 1302
Merit: 1004


Core dev leaves me neg feedback #abuse #political


View Profile
April 18, 2017, 01:56:58 PM
 #15

Yes, because "blocks that you consider to be valid but which every segwit-enforcing node rejects"
will be orphaned as the longest chain prevails. 
No, unmodified non-segwit miners will be producing valid blocks and their blocks will still be accepted. Segwit transactions are considered by non-segwit nodes as being non-standard. An unmodified non-segwit miner means that they have not changed any of the local node policy rules, which include the standardness rules. As long as they are following the standardness rules, they will not be mining segwit transactions and thus their blocks will not be invalid. These miners will not have their blocks orphaned unless they mine a segwit transaction, but that will only happen if they modify their standardness rules.


You're not making sense.  If blocks are rejected (per bitcoincore.org) then either they get orphaned, or there's a split.


achow101
Moderator
Legendary
*
expert
Offline Offline

Activity: 3388
Merit: 6581


Just writing some code


View Profile WWW
April 18, 2017, 02:07:48 PM
 #16

Yes, because "blocks that you consider to be valid but which every segwit-enforcing node rejects"
will be orphaned as the longest chain prevails. 
No, unmodified non-segwit miners will be producing valid blocks and their blocks will still be accepted. Segwit transactions are considered by non-segwit nodes as being non-standard. An unmodified non-segwit miner means that they have not changed any of the local node policy rules, which include the standardness rules. As long as they are following the standardness rules, they will not be mining segwit transactions and thus their blocks will not be invalid. These miners will not have their blocks orphaned unless they mine a segwit transaction, but that will only happen if they modify their standardness rules.


You're not making sense.  If blocks are rejected (per bitcoincore.org) then either they get orphaned, or there's a split.
Their blocks only get rejected if and only if they include a segwit transaction, but they also consider segwit transactions to be non-standard so they won't include such transactions thus their blocks won't be rejected.

jonald_fyookball
Legendary
*
Offline Offline

Activity: 1302
Merit: 1004


Core dev leaves me neg feedback #abuse #political


View Profile
April 18, 2017, 02:15:16 PM
 #17

Yes, because "blocks that you consider to be valid but which every segwit-enforcing node rejects"
will be orphaned as the longest chain prevails. 
No, unmodified non-segwit miners will be producing valid blocks and their blocks will still be accepted. Segwit transactions are considered by non-segwit nodes as being non-standard. An unmodified non-segwit miner means that they have not changed any of the local node policy rules, which include the standardness rules. As long as they are following the standardness rules, they will not be mining segwit transactions and thus their blocks will not be invalid. These miners will not have their blocks orphaned unless they mine a segwit transaction, but that will only happen if they modify their standardness rules.


You're not making sense.  If blocks are rejected (per bitcoincore.org) then either they get orphaned, or there's a split.
Their blocks only get rejected if and only if they include a segwit transaction, but they also consider segwit transactions to be non-standard so they won't include such transactions thus their blocks won't be rejected.

Non segwit minority miners must still build on top of the longest chain that the rest of the network considers valid.   Do you agree or disagree?

achow101
Moderator
Legendary
*
expert
Offline Offline

Activity: 3388
Merit: 6581


Just writing some code


View Profile WWW
April 18, 2017, 02:26:32 PM
 #18

Non segwit minority miners must still build on top of the longest chain that the rest of the network considers valid.   Do you agree or disagree?
Yes, I agree. What are you trying to argue?

jonald_fyookball
Legendary
*
Offline Offline

Activity: 1302
Merit: 1004


Core dev leaves me neg feedback #abuse #political


View Profile
April 18, 2017, 02:39:01 PM
 #19

Non segwit minority miners must still build on top of the longest chain that the rest of the network considers valid.   Do you agree or disagree?
Yes, I agree. What are you trying to argue?

All of your arguments are in the context of segwit = majority.  Because non segwit minority build on top of the longest chain, there is no longer an issue of different spent/unspent TXO.
But if segwit is the minority and non-segwit is the majority, it is different, hence my original point in this thread.

BruceFenton
Sr. Member
****
Offline Offline

Activity: 404
Merit: 250


View Profile WWW
April 18, 2017, 07:13:13 PM
 #20

This is a well written response that makes some good points.


Gregory Maxwell,

> If the goal is user activation I would think that the
> expectation would be that the overwhelming majority of users would be
> upgrading to do it, if that isn't the case, then it isn't really a user
> activated softfork-- it's something else.

Oh... so _that_ comes out.  I do not care what the majority wants.  The majority of people are thieves if they could get away with it.  Consider this: Lets propose a policy where the world can vote on taking half of the current Bitcoin owner's coins away and evenly distributing them to each world citizen.  Screw that, I've had enough of that.  Distributed money doesn't have to be that way.

Lets stop with the whole soft/hard fork designation when there are two disparate groups with conflicting preferences on a policy change.  Soft/Hard doesn't matter anymore.  Its just a fork.

I want SegWit.  I'm perfectly happy w/ forking the money supply I use from the people who don't want SegWit.  I just want replay attack prevention.

To all of you out there who want sound money, this is our song:
Green Day - Minority
https://www.youtube.com/watch?v=cDBlqu6KF4k

Cheers,
Praxeology Guy
Pages: [1] 2 »  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!