Bitcoin Forum

Bitcoin => Bitcoin Discussion => Topic started by: Gyrsur on May 27, 2017, 02:21:05 PM



Title: Here we go for UASF on 08/01/2017 --> www.uasfguide.com
Post by: Gyrsur on May 27, 2017, 02:21:05 PM
http://www.uasfguide.com (https://www.weusecoins.com/uasf-guide/)

download the UASF node here --> https://bitcoinuasf.org/

is there a BIP148 (https://github.com/bitcoin/bips/blob/master/bip-0148.mediawiki) pool for mining already?

let's ask SlushPool and BitFury to support the UASF chain and some others will follow.

yes, voting option is available on SlushPool --> https://slushpool.com/news/new-voting-option-bip148-has-been-deployed-feel-free-to-vote/


http://uasf.saltylemon.org/uasf_percent_all.png

http://uasf.saltylemon.org/uasf_bips_all.png


EDIT: the UASF hat --> https://denarium.com/product/uasf-hat

EDIT2: A Bitcoin Beginner’s Guide to Surviving the BIP 148 UASF (https://bitcoinmagazine.com/articles/bitcoin-beginners-guide-surviving-bip-148-uasf/)

EDIT3: https://bitcoinmagazine.com/articles/op-ed-heres-why-all-rational-miners-will-activate-segwit-though-bip148/

EDIT4: https://en.bitcoin.it/wiki/Segwit_support


Title: Re: Here we go for UASF on 08/01/2017
Post by: BillyBobZorton on May 27, 2017, 02:46:27 PM
Good guide, but I saw some people pointing out at the fact that it's too long. If we want the average joes that run nodes (yes, not everyone running nodes is technologically literate), it's a good idea to get some videos out.

We need to get as much people involved. If we can get a PR for Core them bitfury will support it, and that can be the first spark that fuels it into a total nuke for Jihad's ass. If the snowball effect its triggered then its game over for anyone that doesn't support UASF.


Title: Re: Here we go for UASF on 08/01/2017
Post by: 1Referee on May 27, 2017, 03:38:36 PM
I am ready for anything that will help push Bitcoin forward. I am currently running 4 Core nodes (will probably add 4 more in the coming weeks) to contribute towards a safer and more decentralized network. Most people here are sick and tired of the barbaric torture that comes from the miners. It's not only that they prevent Segwit from activating, but also that they alongside other entities, are responsible for the insane fees that people are struggling with. They are choking the network with constantly higher numbers of garbage transactions...


Title: Re: Here we go for UASF on 08/01/2017 --> www.uasfguide.com
Post by: Gyrsur on May 27, 2017, 03:48:27 PM
any suggestions for a good (cheap) hoster for Bitcoin full nodes?

EDIT: needs to be tested

https://gist.github.com/romanz/17ff716f13a34df49ff4

http://www.rackulous.com/uk-kvm-vps.php

https://lowendbox.com/blog/joes-datacenter-20month-dual-l5420-w-8gb-ram-500gb-hdd-kansas-city/

https://lowendbox.com/

https://www.linode.com/

https://www.digitalocean.com/

discussion here --> https://www.reddit.com/r/Bitcoin/comments/4xs7mo/need_vps_to_host_a_bitcoin_core_full_node/


Title: Re: Here we go for UASF on 08/01/2017 --> www.uasfguide.com
Post by: Hakkane on May 27, 2017, 03:56:36 PM
EDIT: let's ask SlushPool and BitFury to support the UASF chain and some others will follow.

I am in shock, totally in shock, to see you are still trusting BitFury will support this madness. BitFury signed for the scaling solution of Segwit-bit4 + 2Mb blocks at the Consensus 2017. Along with them, 85% of the hashing pool operators and many important payment processors, exchanges and other actors of this industry.

No big actor is supporting this. Not even Core Devs have said they support this fork.

You are going to force a split in the blockchain, the few following you will most probably be orphaned. Be a bit responsible guys, you are going to inflict a lot of harm to the ecosystem


Title: Re: Here we go for UASF on 08/01/2017 --> www.uasfguide.com
Post by: Gyrsur on May 27, 2017, 04:13:21 PM
No big actor is supporting this. Not even Core Devs have said they support this fork.

https://i.imgur.com/uXWZb9d.jpg

https://i.imgur.com/LTyU7kG.jpg

https://i.imgur.com/85MOVR1.jpg


Title: Re: Here we go for UASF on 08/01/2017
Post by: dinofelis on May 27, 2017, 04:34:13 PM
I am ready for anything that will help push Bitcoin forward. I am currently running 4 Core nodes (will probably add 4 more in the coming weeks) to contribute towards a safer and more decentralized network.

This is very funny  ;D



Title: Re: Here we go for UASF on 08/01/2017
Post by: 1Referee on May 27, 2017, 11:08:36 PM
I am ready for anything that will help push Bitcoin forward. I am currently running 4 Core nodes (will probably add 4 more in the coming weeks) to contribute towards a safer and more decentralized network.

This is very funny  ;D



How is that funny? It may not be a huge deal of support from my side, but at least it's something, and I am happy to contribute. It's obvious to you how many nodes are hosted at data centers, and likely owned by a handful of entities, right?


Title: Re: Here we go for UASF on 08/01/2017 --> www.uasfguide.com
Post by: 25hashcoin on May 28, 2017, 02:57:45 AM
UASF is soon to fail blockstream core small block forever chain. Real bitcoiners support big blocks.


Title: Re: Here we go for UASF on 08/01/2017
Post by: dinofelis on May 28, 2017, 05:12:22 AM
I am ready for anything that will help push Bitcoin forward. I am currently running 4 Core nodes (will probably add 4 more in the coming weeks) to contribute towards a safer and more decentralized network.

This is very funny  ;D



How is that funny? It may not be a huge deal of support from my side, but at least it's something, and I am happy to contribute. It's obvious to you how many nodes are hosted at data centers, and likely owned by a handful of entities, right?

No.  What is funny, is that "decentralization" doesn't increase when you run SEVERAL nodes.  Decentralization is about how many independent "decision entities" that are not colluding over their strategies, are part of the system.  You are ONE such entity.  If you run MANY nodes, you are only doing a Sybil attack, you are not increasing "decentralization", because your 4 nodes are colluding (it's you, each time).

This is like saying "voting is important, I went to cast 4 times a vote with false ID papers, long live democracy !".

I found that funny.

Note that this is even under the false hypothesis that non-mining nodes add anything to decentralization, which it doesn't.  Only starting a mining pool and attracting enough hash rate adds to decentralization.


Title: Re: Here we go for UASF on 08/01/2017 --> www.uasfguide.com
Post by: dinofelis on May 28, 2017, 05:56:48 AM
UASF is soon to fail blockstream core small block forever chain. Real bitcoiners support big blocks.

I fully agree with you here ; and that doesn't even mean that segwit should be avoided - I even think segwit is a good idea ; what is a bad idea is to keep the blocks small.  Now, what's my personal opinion of whether and how bitcoin should upgrade ?  I think I don't care, but I think that bitcoin is an interesting experimental environment to observe different phenomena.

As I said elsewhere, I think bitcoin's design is broken beyond repair if one thinks it is ever going to be a daily currency, and the funny thing is that what is hailed as the most important aspect of bitcoin, namely the 21 M coin limit, is exactly what is killing it as a currency (but which has probably got it off the ground with greed).  Now, this 21 M limit is ALSO what implies difficulties with big blocks and is ALSO what is making mining a centralized business.  In fact, the big failure of bitcoin as a currency comes from this 21 M limit, and I think it is one of the fundamental "contractual propositions" of bitcoin, which is why I say: it is broken beyond repair.   If ever one wanted to repair it, one would need to touch this sacred principle, so the only thing to do is to start all over from scratch.  I'm not saying that bitcoin is going to die, it isn't.  But it cannot become a currency.  

My reasoning is as follows:

a) The limited number of coins turns bitcoin into a collectible, of which a lot of them are created when bitcoin was cheap, and of which it was to be foreseen that they could become very expensive.  This turns bitcoin into a speculative asset, of a similar kind as ancient paintings: very expensive collector (hodler) items, with of course also very unpredictable future value.  Now, a currency needs to be a reliable unit of account, which a speculative item never can be.  But contrary to something like gold that "always existed", bitcoin's recent "printing" has caused HUGE seigniorage for early adopters, which are of course induced to start a greater fool game, which will be imitated by layers and layers of greater fools.  The expectation of price increase in the future will have to break down at a certain point, at which the last layer of greater fools will be very, very disappointed.  This is different with a ancient collectible.  You do not necessarily expect a price rise.  You are careful in your investment and you are satisfied if you find a "same fool".   It KEEPS value, it can increase or decrease somewhat, but you do not expect double digit yearly gains.  Bitcoin's initial seigniorage has delivered multiple digit gains and it is essentially what dominates its market.

==> a collectible with huge initial seigniorage becomes a speculator's asset, not a currency.

b) The limited number of coins induces a lowering of the block reward.  The block reward is needed because it is the "spend value" on security: anyone willing to spend more than the block reward on proof of work, can rewrite history.  This is the somewhat silly cryptographic protection of proof of work: your protection is the amount of value you spend on it.  If an attacker is willing to spend more, he can break the protection and re-write history.  This becomes interesting if many transactions in blocks become much larger than the block reward.  Because of the limited number of coins, the block reward has to go down.  So fees are needed.   Hence, transactions need to be scarce for fees to be important, or the system becomes insecure.  This induces friction on transactions, which will hinder its usage as a currency even more, but doesn't mind for relatively rare transactions of "old paintings".

==> transactions need to be scarce, for the fees to pay for the security.  The induced friction hinders the asset to become a competitive currency.

c) The relative slowness of the transactions and its friction makes that for day-trading, clearing houses are better: most volume of trading will hence not be done on-chain, but will be using IOU on clearing houses (exchanges).  This will end up requiring legal protection and these clearing houses will become new "banks" ; their centralized systems are much lighter and quicker than any decentralized network and will be much more performing.  As such, bitcoin will be just a "backing" of these bank IOU.  Note that these clearing houses came essentially into existence because of the speculative nature of bitcoin.  They are not "sales points of coins" as they were intended, but they are trading clearing houses because of its highly speculative nature.

==> the nature of bitcoin (speculative and friction of relatively slow transactions) induces the existence of highly regulated clearing houses in which bitcoin IOU are the true "currency" and bitcoin is just its backing asset.

d) the throat-cut competition in PoW and its lottery aspect makes for mutualising the lottery-risk, hence gives rise to at most a few tens of pools (the Poisson statistics and the 10 minute blocks make that many more pools would not make sense as they wouldn't win enough blocks for the lottery statistics to smooth out quickly).  As PoW is not only used for coin creation, but also for consensus (over everything), this turns these pools into the real powerhouses of bitcoin.  They have a huge stake in making mining profitable, which is finding the right balance that squeezes out the maximum of fees the market will bear.

==> the idea of using PoW not only for coin creation, but also for consensus finding, makes that bitcoin will end up in the hands of an oligarchy of a few tens of people at best.

PoW has become cut-throat, and it is a slow lottery, because of the difficulty adjustment, which was needed to keep the coin emission rate limited.  If the coin emission would have been flexible, that is, with a value-limit on it, that would actually solve about all problems bitcoin is facing.

So, my "proposition" (which is impossible, I know) to repair bitcoin would rather be:

a) separate coin creation with PoW from consensus (with PoS).  This keeps the power in the hands of the owners.

b) put a limit on difficulty, which fixes the *value* of the coin, and not the number of coins.  This takes out most of the speculation, because the value of the coin is capped.  This will turn coin creation into a non-competitive game, and hence take out the pools, take out the cut throat competition and take out the lottery aspect ==> no more oligarchy

c) PoS without rewards is something that can work very fast, is cryptographically much more secure, doesn't waste resources, and can work with essentially unlimited blocks ; we don't care about orphaning some.  This takes out the friction of payment and the slowness of payments, and ensures true decentralisation.

d) the value regulation instead of the number-of-coins regulation brings bitcoin much closer to Nash's "ideal money".

There can be a limit on block size, because the SPEED of block generation is arbitrary (with non-remunerated PoS).  Nothing would stop building a LN type of network on top of it, because of the unlimited settlement capacity of the underlying system which is needed to keep LN permissionless.



Title: Re: Here we go for UASF on 08/01/2017 --> www.uasfguide.com
Post by: aarturka on May 28, 2017, 06:49:32 AM
UASF is soon to fail blockstream core small block forever chain. Real bitcoiners support big blocks.
who are you calling real bitcoiners? gavin andressen supports big blocks Ver supports big blocks, Craig and other enemies of bitcoin but not one real bitcoiner


Title: Re: Here we go for UASF on 08/01/2017 --> www.uasfguide.com
Post by: Gyrsur on May 28, 2017, 09:28:40 AM
look at the percentage of nodes which are signaling for UASF! WOW!!

http://uasf.saltylemon.org/uasf_percent_all.png


Title: Re: Here we go for UASF on 08/01/2017 --> www.uasfguide.com
Post by: 7788bitcoin on May 28, 2017, 09:42:59 AM
Any possible reason for the sudden increase in the number of UASF node? It does look a bit fishy- I do support UASF but was expecting the number of node to gradually increase over time and not a sudden spike.


Title: Re: Here we go for UASF on 08/01/2017
Post by: xhiggy on May 28, 2017, 09:46:43 AM
I am ready for anything that will help push Bitcoin forward. I am currently running 4 Core nodes (will probably add 4 more in the coming weeks) to contribute towards a safer and more decentralized network.

This is very funny  ;D



How is that funny? It may not be a huge deal of support from my side, but at least it's something, and I am happy to contribute. It's obvious to you how many nodes are hosted at data centers, and likely owned by a handful of entities, right?

The solution is to let more of those entities use the network by increasing the blocksize, so there are hundreds of entities owning nodes at datacenters.


Title: Re: Here we go for UASF on 08/01/2017 --> www.uasfguide.com
Post by: Gyrsur on May 28, 2017, 09:49:18 AM
Any possible reason for the sudden increase in the number of UASF node? It does look a bit fishy- I do support UASF but was expecting the number of node to gradually increase over time and not a sudden spike.

it's so easy to signal for UASF if you run a full node already. guess a lot of node operators signal now for UASF because the total amount of the nodes didn't increase.

https://bitnodes.21.co/dashboard/?days=90


How do I signal support?

If you operate a full-node then you can signal support with your current software. This is a way you can show support without actually upgrading to enforcing BIP 148 rules.

To signal #BIP148 on Linux or Mac on your node before binaries are released go to Help --> Debug Window --> Console:

echo "uacomment=UASF-SegWit-BIP148" >> ~/.bitcoin/bitcoin.conf && bitcoin-cli stop && sleep 5 && bitcoind

To signal #BIP148 on Windows, you can edit the shortcut for Bitcoin as follows:

https://i.imgur.com/kh0AfS1.png

EDIT: after the 08/01/2017 only full nodes which are supports BIP148 will refuse blocks from miners which are not signaling for the SegWit activation. this means we have then in this BIP148 chain 100% blocks which are signaling for SegWit and are able to activate SegWit in this new Bitcoin chain. this new Bitcoin chain will be listed on exchanges as an own SegWitBitcoin which will increase in value over time because the amount of processed transactions in a block is higher than in the old Bitcoin chain (1MB limit).

EDIT2: the next step is to create a pool with the BIP148 node running and let pool miners to connect on. pool fee should be 0%. other incentives too?


Title: Re: Here we go for UASF on 08/01/2017 --> www.uasfguide.com
Post by: dinofelis on May 28, 2017, 11:56:54 AM
EDIT: after the 08/01/2017 only full nodes which are supports BIP148 will refuse blocks from miners which are not signaling for the SegWit activation. this means we have then in this BIP148 chain 100% blocks which are signaling for SegWit and are able to activate SegWit in this new Bitcoin chain. this new Bitcoin chain will be listed on exchanges as an own SegWitBitcoin which will increase in value over time because the amount of processed transactions in a block is higher than in the old Bitcoin chain (1MB limit).  

I have a technical question here:

do these UASF full nodes consider the "normal bitcoin chain" but only consider *transactions* in segwit-signalling blocks, or do these full nodes consider only a segwit-signalling-only fork of the bitcoin chain ?

I mean: case A:

Only chain out there, let us assume that 7/31/2017 at midnight block 500 000 is reached for sake of argument:

suppose that the (only) chain out there is:

500 000 (segwit) - 500 001 (segwit) - 500 002 (non segwit) - 500 003 (non segwit) - 500 004 (segwit) - ....  - 503 005 (segwit) - 503 006 (non segwit) .....

Does your node accept this chain (a), but only considers transactions that happen to be in blocks 500 000, 500 001, 500 003, .... 503 005, ...

Or does your node stop at 500 002 because it is an invalid (non segwit) block (b) , and doesn't accept 500 004, because it is not the successor to the last valid block, 500 002 ?

case B:

Suppose that miners fork, and there are two chains out there, splitting at 500 001:

chain 1: 500 000 (segwit) - 500 001 (segwit) - 500 002 (non segwit) - 500 003 (non segwit) - 500 004 (segwit) - ....  - 503 005 (segwit) - 503 006 (non segwit) .....

chain 2: 500 000 (segwit) - 500 001' (segwit) - 500 002' (segwit) - 500 003' (segwit) - ....

500 000 (segwit) being the last common block to both prongs.

Will your software read only chain 2, considering 500 001 orphaned ?

Is the UASF node going to follow Aa, or

depending on whether the miners don't split, or split: Ab, or B ?


Title: Re: Here we go for UASF on 08/01/2017 --> www.uasfguide.com
Post by: Gyrsur on May 28, 2017, 12:09:10 PM
EDIT: after the 08/01/2017 only full nodes which are supports BIP148 will refuse blocks from miners which are not signaling for the SegWit activation. this means we have then in this BIP148 chain 100% blocks which are signaling for SegWit and are able to activate SegWit in this new Bitcoin chain. this new Bitcoin chain will be listed on exchanges as an own SegWitBitcoin which will increase in value over time because the amount of processed transactions in a block is higher than in the old Bitcoin chain (1MB limit).  

I have a technical question here:

do these UASF full nodes consider the "normal bitcoin chain" but only consider *transactions* in segwit-signalling blocks, or do these full nodes consider only a segwit-signalling-only fork of the bitcoin chain ?

all blocks which have the signal for the SegWit activition will be considered in the BIP148 full nodes. all other blocks not. transactions in the mem pool will be included in BIP148 mining nodes again even if they are already included in non-SegWit signaled blocks. --> double spend in both chains is possible.

EDIT: understand now what you trying to explain. the fork will happen with the first block which are not signal for SegWit because it is an orphaned block.

EDIT2: Reference implementation of BIP148 --> https://github.com/bitcoin/bitcoin/compare/master...shaolinfry:bip-segwit-flagday
Code:
// Check if Segregated Witness is Locked In
bool IsWitnessLockedIn(const CBlockIndex* pindexPrev, const Consensus::Params& params)
{
    LOCK(cs_main);
    return (VersionBitsState(pindexPrev, params, Consensus::DEPLOYMENT_SEGWIT, versionbitscache) == THRESHOLD_LOCKED_IN);
}

// BIP148 mandatory segwit signalling.
int64_t nMedianTimePast = pindex->GetMedianTimePast();
if ( (nMedianTimePast >= 1501545600) &&  // Tue 01 Aug 2017 00:00:00 UTC
     (nMedianTimePast <= 1510704000) &&  // Wed 15 Nov 2017 00:00:00 UTC
     (!IsWitnessLockedIn(pindex->pprev, chainparams.GetConsensus()) &&  // Segwit is not locked in
      !IsWitnessEnabled(pindex->pprev, chainparams.GetConsensus())) )   // and is not active.
{
    bool fVersionBits = (pindex->nVersion & VERSIONBITS_TOP_MASK) == VERSIONBITS_TOP_BITS;
    bool fSegbit = (pindex->nVersion & VersionBitsMask(chainparams.GetConsensus(), Consensus::DEPLOYMENT_SEGWIT)) != 0;
    if (!(fVersionBits && fSegbit)) {
        return state.DoS(0, error("ConnectBlock(): relayed block must signal for segwit, please upgrade"), REJECT_INVALID, "bad-no-segwit");
    }
}


Title: Re: Here we go for UASF on 08/01/2017 --> www.uasfguide.com
Post by: dinofelis on May 28, 2017, 12:58:52 PM
EDIT: after the 08/01/2017 only full nodes which are supports BIP148 will refuse blocks from miners which are not signaling for the SegWit activation. this means we have then in this BIP148 chain 100% blocks which are signaling for SegWit and are able to activate SegWit in this new Bitcoin chain. this new Bitcoin chain will be listed on exchanges as an own SegWitBitcoin which will increase in value over time because the amount of processed transactions in a block is higher than in the old Bitcoin chain (1MB limit).  

I have a technical question here:

do these UASF full nodes consider the "normal bitcoin chain" but only consider *transactions* in segwit-signalling blocks, or do these full nodes consider only a segwit-signalling-only fork of the bitcoin chain ?

all blocks which are have the signal for the SegWit activition will be considered in the BIP148 full nodes. all other blocks not. transactions in the mem pool will be included in BIP148 mining nodes again even if they are already included in non-SegWit signaled blocks.  

Yes, but in my case A, you mean you consider a "chain" where there are holes in it ?  That is, you have a succession of blocks that are not linked together ?  I'm not talking about mining pools, I'm talking about the case when there's only one block chain out there (like there is today), but not all blocks in it, signal for segwit.

In other words, suppose that the "firing up" date was this morning.  What is your node going to do, if there's no segwit-only fork out there ?  Only pick the segwit signalling blocks (non-consecutive) in the actual chain, or stop ?

Do you NEED actually a segwit-only fork made by miners forking away from the original chain ?  If no such forked chain is being build, this node stops ?  (this is what I understand from your edit...)



Title: Re: Here we go for UASF on 08/01/2017 --> www.uasfguide.com
Post by: Gyrsur on May 28, 2017, 01:37:14 PM
EDIT: after the 08/01/2017 only full nodes which are supports BIP148 will refuse blocks from miners which are not signaling for the SegWit activation. this means we have then in this BIP148 chain 100% blocks which are signaling for SegWit and are able to activate SegWit in this new Bitcoin chain. this new Bitcoin chain will be listed on exchanges as an own SegWitBitcoin which will increase in value over time because the amount of processed transactions in a block is higher than in the old Bitcoin chain (1MB limit).  

I have a technical question here:

do these UASF full nodes consider the "normal bitcoin chain" but only consider *transactions* in segwit-signalling blocks, or do these full nodes consider only a segwit-signalling-only fork of the bitcoin chain ?

all blocks which are have the signal for the SegWit activition will be considered in the BIP148 full nodes. all other blocks not. transactions in the mem pool will be included in BIP148 mining nodes again even if they are already included in non-SegWit signaled blocks.  

Yes, but in my case A, you mean you consider a "chain" where there are holes in it ?  That is, you have a succession of blocks that are not linked together ?  I'm not talking about mining pools, I'm talking about the case when there's only one block chain out there (like there is today), but not all blocks in it, signal for segwit.

In other words, suppose that the "firing up" date was this morning.  What is your node going to do, if there's no segwit-only fork out there ?  Only pick the segwit signalling blocks (non-consecutive) in the actual chain, or stop ?

Do you NEED actually a segwit-only fork made by miners forking away from the original chain ?  If no such forked chain is being build, this node stops ?  (this is what I understand from your edit...)

the code tells: only pick the segwit signalling blocks (non-consecutive) in the actual chain. and then apply the segwit activation logic on it which has 100% consensus.


Title: Re: Here we go for UASF on 08/01/2017 --> www.uasfguide.com
Post by: European Central Bank on May 28, 2017, 02:04:12 PM
look at the percentage of nodes which are signaling for UASF! WOW!!

just as fake as the bitcoin unlimited nodes, hundreds of which would crash and then come back online at the same time. they're not achieving anything other than looking a bit silly.


Title: Re: Here we go for UASF on 08/01/2017 --> www.uasfguide.com
Post by: dinofelis on May 28, 2017, 02:06:25 PM
the code tells: only pick the segwit signalling blocks (non-consecutive) in the actual chain. and then apply the segwit activation logic on it which has 100% consensus.

Ah, it is then different that what I thought it did.  

So it accepts a mixed segwit signalling/non segwit signalling block chain in the same way that a normal node does, but only considers transactions (?) in those blocks that have segwit signalling ? In other words, it pretends not to see the non-segwit blocks, except for the fact that they have block headers in between segwit signalling blocks ?  In doing so, it tricks itself in believing that segwit has 100% signalling, will lock in soon and will trigger segwit on the 15th of November.  In the mean time, you don't consider any transaction that is not in a non-segwit signalling block, is that it ?

So it is only on the 15th of November that this node will stop, if the mixed segwit/non-segwit chain continues ? I thought that segwit was by default already activated from the 1st of August ; what I thought was going to happen on the 1st of august, will only happen then on the 15th of November.

Your node will hence run, between the 1st of August, and the 15th of November, but only show you those transactions that happen to be in segwit-signalling blocks ?  I guess that from a certain point on, none of these transactions will start making sense, because some of the UTXO are in non-segwit signalling blocks ?

Or do I also misunderstand this ?

Suppose Joe pays Alice, and his transaction gets included in a segwit-signalling block.  Alice spends those coins to Jack, and her transaction gets included in a non-segwit signalling block.  Now Jack wants to pay to you, but he can't because his transaction, whether included in a segwit signalling or non-segwit signalling block will have an UTXO that you don't want to consider, so his transaction is considered invalid ?

Or do you also accept those transactions, in the same way you accept blocks that don't have accepted predecessors but are OK because they signal segwit ?

In other words, can Jack pay you ?  But you will only see his transaction if it happens to get included in a segwit signalling block ?  And if not, then you don't consider that Jack paid you (but he did send his coins, only, his transaction is in an intermediate non-segwit signalling block and you don't consider those) ?   Or can't Jack pay you, because Alice's transaction was already in a non-segwit signalling block ?


Title: Re: Here we go for UASF on 08/01/2017 --> www.uasfguide.com
Post by: classicsucks on May 28, 2017, 02:45:09 PM
http://www.uasfguide.com (https://www.weusecoins.com/uasf-guide/)

let's ask SlushPool and BitFury to support the UASF chain and some others will follow.

So you're admitting that UASF is really just an altcoin, and a sh*tty one at that?

Quote
EDIT: the UASF hat --> https://denarium.com/product/uasf-hat


I love the hats - they will probably be collectible after the User Activated Soft Fail.

But seriously, nice job on the website and the suspicious-looking GNUplot graphs. I like the link to the vulnerability you added, nothing to do with Segwit, nice FUD touch.

So, where is the CODE?


Title: Re: Here we go for UASF on 08/01/2017 --> www.uasfguide.com
Post by: Gyrsur on June 03, 2017, 11:49:35 AM
voting option now available on SLUSHPOOL for UASF/BIP148:

https://slushpool.com/news/new-voting-option-bip148-has-been-deployed-feel-free-to-vote/ (https://slushpool.com/news/new-voting-option-bip148-has-been-deployed-feel-free-to-vote/)


Title: Re: Here we go for UASF on 08/01/2017 --> www.uasfguide.com
Post by: Gyrsur on June 03, 2017, 11:52:09 AM
So, where is the CODE?

Reference implementation of BIP148 --> https://github.com/bitcoin/bitcoin/compare/master...shaolinfry:bip-segwit-flagday
Code:
// Check if Segregated Witness is Locked In
bool IsWitnessLockedIn(const CBlockIndex* pindexPrev, const Consensus::Params& params)
{
    LOCK(cs_main);
    return (VersionBitsState(pindexPrev, params, Consensus::DEPLOYMENT_SEGWIT, versionbitscache) == THRESHOLD_LOCKED_IN);
}

// BIP148 mandatory segwit signalling.
int64_t nMedianTimePast = pindex->GetMedianTimePast();
if ( (nMedianTimePast >= 1501545600) &&  // Tue 01 Aug 2017 00:00:00 UTC
     (nMedianTimePast <= 1510704000) &&  // Wed 15 Nov 2017 00:00:00 UTC
     (!IsWitnessLockedIn(pindex->pprev, chainparams.GetConsensus()) &&  // Segwit is not locked in
      !IsWitnessEnabled(pindex->pprev, chainparams.GetConsensus())) )   // and is not active.
{
    bool fVersionBits = (pindex->nVersion & VERSIONBITS_TOP_MASK) == VERSIONBITS_TOP_BITS;
    bool fSegbit = (pindex->nVersion & VersionBitsMask(chainparams.GetConsensus(), Consensus::DEPLOYMENT_SEGWIT)) != 0;
    if (!(fVersionBits && fSegbit)) {
        return state.DoS(0, error("ConnectBlock(): relayed block must signal for segwit, please upgrade"), REJECT_INVALID, "bad-no-segwit");
    }
}


Title: Re: Here we go for UASF on 08/01/2017 --> www.uasfguide.com
Post by: greenuser on June 16, 2017, 12:00:36 PM
Count me in!
I currently have a BIP148 Full Node up and running in South West UK and miners pointed at Slushpool with a 148 vote. Some of my miners are old kit and are not efficient so, they remain on stand-by and can be used "as and when needed". I also intend to rent hashpower to point at either, my own node or to point at Slushpool. Can anyone recommend a fair cloud mining service?

Currently 25% of Slushpool users are happy to let the pool decide how work is allocated to miners. We need to get Slushpool to favor the BIP148, also Core voters are potential conscripts.

Anyhow, I have experience in contentious hard fork environments, I typed
Code:
appose-doa-fork
at Block 1920000 and mined the old Ethereum chain when Vitalik rolled back and forked off.  We only had 6% of network at that point but it grew to 10% within 48hours. Even with a small percentage of the hashpower we evaded 51% Attack.

Communication will be key in the first 48hours so i am just touching base to find out where those coms will be realized.

We are in a good position to have a positive outcome if the cards are played correctly.



Title: Re: Here we go for UASF on 08/01/2017 --> www.uasfguide.com
Post by: Gyrsur on June 16, 2017, 08:21:22 PM
https://bitcoinmagazine.com/articles/op-ed-heres-why-all-rational-miners-will-activate-segwit-though-bip148/

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


Title: Re: Here we go for UASF on 08/01/2017 --> www.uasfguide.com
Post by: Gyrsur on July 04, 2017, 08:03:18 PM
download the UASF node here --> https://bitcoinuasf.org/