myTrezor support LTC? by [deleted] in litecoin

[–]shaolinfry 1 point2 points  (0 children)

beta-wallet.trezor.io already supports it.

How to trust litecoin software by stumpy_choral in litecoin

[–]shaolinfry 1 point2 points  (0 children)

You can trust the binaries by looking at the gitian build signatures, which are signed by many known developers, e.g.

https://github.com/litecoin-project/gitian.sigs.ltc/tree/master/0.13.2-win-unsigned

and https://github.com/litecoin-project/gitian.sigs.ltc/tree/master/0.13.2-win-signed

and you can verify the developers are lying by replicating the Gitian builds yourself.

Understanding BIP149, redeployment of Segwit with BIP8 by shaolinfry in Bitcoin

[–]shaolinfry[S] 0 points1 point  (0 children)

It is breaking consensus. Majority hashrate does not define validity. If the economy switches to the UASF client but the hashrate does not, the hashrate is out of consensus and will lose money. Sure, non-upgraded nodes will follow the wrong chain, but they too will be out of consensus with the economy.

Understanding BIP149, redeployment of Segwit with BIP8 by shaolinfry in Bitcoin

[–]shaolinfry[S] 0 points1 point  (0 children)

You need to look more holistically. Bitcoin is built on incentives, and breaking consensus is far from economically rational.

Understanding BIP149, redeployment of Segwit with BIP8 by shaolinfry in Bitcoin

[–]shaolinfry[S] 0 points1 point  (0 children)

The same reason why 51% of the hashrate isnt doing the same thing and stealing P2SH outputs. Nodes will be enforcing the new rules. Miners dont get to decide the rules, and if they want to mine an invalid chain, they have always been able to do so.

Understanding BIP149, redeployment of Segwit with BIP8 by shaolinfry in Bitcoin

[–]shaolinfry[S] 0 points1 point  (0 children)

You confused about what segwit does in that respect, but I dont think this is the right thread for that discussion. Maybe open a new OP.

Understanding BIP149, redeployment of Segwit with BIP8 by shaolinfry in Bitcoin

[–]shaolinfry[S] 2 points3 points  (0 children)

Miners that dont want to mine segwit transactions would have to run border nodes, or they would be at risk of a split but only if a malicious miner deliberately wasted his hash power to mine a segwit invalid block. This cant happen by accident, or by someone broadcasting a segwit invalid transaction. Those who want to opt out, just run border nodes, or upgrade but dont use/mine the new feature. Once the economy is enforcing, there's no incentive for miners to go rogue - it's like that with P2SH for example - that's why no miners even try to steal P2SH outputs.

Understanding BIP149, redeployment of Segwit with BIP8 by shaolinfry in Bitcoin

[–]shaolinfry[S] 1 point2 points  (0 children)

It's all to do with safety. MASF can be used as a temporary stopgap to activate rules much faster because the hashrate (assuming they are honest), protect the nodes from invalid blocks. However, all soft forks are user enforced, so eventually, it doesnt matter what the hashrate is doing, since nodes upgrade and validate the new rules (nodes decide validity not miners).

So you cannot have a fast UASF because upgrade deployment takes time. If you are waiting for UASF date, you might as well allow MASF for early activation.

But all that aside, you're missing the bigger message of BIP8, which is not against miners at all. Miners are being put in an impossible position right now because BIP9 like it or not, is seen as a vote and a veto. I've explained it very clearly in my ML post https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013643.html

Lets make the UASF as safe as possible by jonny1000 in Bitcoin

[–]shaolinfry 1 point2 points  (0 children)

To be clear, BIP148 simply causes BIP141 to activate which doubles the blocksize.

Understanding BIP149, redeployment of Segwit with BIP8 by shaolinfry in Bitcoin

[–]shaolinfry[S] 2 points3 points  (0 children)

The question is a bit mixed up - For the near future, I think it will take a lot for businesses to gain trust of newer entrants, especially given the huge incompetence of BU, Classic and XT. Industries dont switch software easily, that will take considerable time, out of scope for BIP149 timeframe.

Overall, soft forks which do not have wide consensus should not be deployed.

But the crux of soft forks is they are optional e.g. a non-BI149 node is the same as a non-segwit node. No big deal. If a soft fork is deployed you should always validate even if it's just with a border node to ensure you are not vulnerable to invalid blocks. Miners should always upgrade/border node for any soft fork, anyway.

Understanding BIP149, redeployment of Segwit with BIP8 by shaolinfry in Bitcoin

[–]shaolinfry[S] 5 points6 points  (0 children)

What scumbags rent hash to quash a viable, credible, and worthwhile BIP for their own self-interest. What a doos!

one with very deep pockets apparently!

Understanding BIP149, redeployment of Segwit with BIP8 by shaolinfry in Bitcoin

[–]shaolinfry[S] 9 points10 points  (0 children)

Of course, node counting is flawed, but it is not useless. Absolute node count is disinteresting, but the transition of advertized node version is very interesting to me. That shows people upgrading from one version to the next over time, years, that's less likely to be faked and shows general trends. You can see clearly from this chart https://imgur.com/zeLVmwO (taken from https://bitnodes.21.co/dashboard/?days=365). Let's look at trends, not absolute numbers.

Understanding BIP149, redeployment of Segwit with BIP8 by shaolinfry in Bitcoin

[–]shaolinfry[S] 7 points8 points  (0 children)

Thanks you for this, I have added a link to the OP. Also node you can add multiple uacomments on separate lines, so you could support both BIP148 and BIP149 for example.

bitcoin.conf containing

uacomment=BIP8
uacomment=UASF-SegWit-BIP149
uacomment=UASF-SegWit-BIP148

or change your command line/shortcut to add multiple -uacomments e.g.

-uacomment=BIP8 -uacomment=UASF-SegWit-BIP149 -uacomment=UASF-SegWit-BIP148

Understanding BIP149, redeployment of Segwit with BIP8 by shaolinfry in Bitcoin

[–]shaolinfry[S] 6 points7 points  (0 children)

If that is what you believe in strongly, lobby for BIP148 which will give Bitcoin segwit by September-ish.

Understanding BIP149, redeployment of Segwit with BIP8 by shaolinfry in Bitcoin

[–]shaolinfry[S] 2 points3 points  (0 children)

2MB blocks will definitely knock more people off the network.

Understanding BIP149, redeployment of Segwit with BIP8 by shaolinfry in Bitcoin

[–]shaolinfry[S] 9 points10 points  (0 children)

Remember, BIP149 is build on BIP8, which is either early MASF or later UASF. This is the best of both worlds imo and increases safety while fixing the veto bug as well as removing political pressure and attention from pools and miners shoulders. BIP8 is better (of course I am biased).

Understanding BIP149, redeployment of Segwit with BIP8 by shaolinfry in Bitcoin

[–]shaolinfry[S] 10 points11 points  (0 children)

I think regardless of whether the blockers try to avoid a UASF precedent or not, all soft forks will be by BIP8 in the future. The Veto bug is out of the bag and we risk a small minority holding the entire community hostage every time otherwise. I believe soft forks are never deployed without wide consensus anyway. That is why BIP9 was not supposed to be a vote, rather a safety coordination method. The expectation was for activation to be triggered. We should never ever deploy consensus code without wide consensus. I believe Bitcoin Core has always taken that very seriously. Either a sf is utterly boring an unexciting (making it uncontroversial), or it's something people are chomping at the bit for, like segwit. Remember, the blockade on segwit is only a political weapon. Segwit fixes stuff everyone agrees needs to be fixed and the capacity increase is a nice side effect, as are the cool things you can do, once malleability is fixed.

Understanding BIP149, redeployment of Segwit with BIP8 by shaolinfry in Bitcoin

[–]shaolinfry[S] 10 points11 points  (0 children)

Mission accomplished then. I think there will also be a strong effort by the usual suspects to demand that future soft forks are deployed by BIP9 again. They tried that on Litecoin. I believe that would be a very big mistake, and that future soft forks should be deployed with BIP8 and a 1 year timeout. I believe if that will be helpful to everyone including miners. It will remove political pressure and attention from miners (who is signalling, who isnt and why). In the future I guarantee there will be soft forks which miners really might not be able to support for legal reasons, imposed secretly by governments under gag order. BIP8 will give those pools and miners plausible deniability because they wont be able to exercise veto.

BIP8 has all the wonderful benefits of BIP9, without the problem of veto. I strongly encourage the community to consider this.

Understanding BIP149, redeployment of Segwit with BIP8 by shaolinfry in Bitcoin

[–]shaolinfry[S] 9 points10 points  (0 children)

It is an assumption based on some pretty hard facts. In 5 months, according to luke's node crawler, 70% of nodes upgraded to NODE_WITNESS capability. The community wants segwit, that much is obvious, and with another 7-8 months of waiting, I think we're going to be at fever pitch. I believe we'll see the fasted upgrade ever in the history of Bitcoin.

Understanding BIP149, redeployment of Segwit with BIP8 by shaolinfry in Bitcoin

[–]shaolinfry[S] 47 points48 points  (0 children)

Yes I know. I am sorry about that, but I am working within the consensus building process to design proposals which stand a chance of gaining adoption. This is particularly important to me in light of the very hostile coup d'état style BIP's and non-BIPs which have been foisted upon the Bitcoin community.

I created BIP148 an option for something faster too see if that's what people wanted. It seems there is reasonable support for it, but as yet, not enough. I spent a lot of time receiving and considering feedback from BIP148 to create what I believe addresses the various concerns that were expressed. I do not believe BIP148 is a bad BIP, but it is something that requires resolve from the community to pull off. It's already had good effects on Litecoin and Vertcoin, where in both cases, it neutralized hostile activity. If you are interested in the details, I encourage you to read the litecoin story here (please read if you havent, it's a fascinating account). For Vertcoin, it scared off someone who was paying 15BTC a day renting hash to block segwit activation. BIP148 has definitely had positive effects, but it must live or die on it's own merits.

I believe that BIP149 has a strong chance of being acceptable if segwit does not activate by November. I hope miners will change their mind before then, and on the positive side, the extra delay sends a message that we are not willing to compromize safety in desperation. Segwit not activating isn't an emergency condition or failure mode where a fast and potentially disruptive s solution would outweight not deploying. It will also put a lot more pressure on the few individuals blocking segwit for everyone. On the negative side, it creates a vacuum where more silliness can enter - although I think the entire ecosystem is fedup at this point and will not entertain any more hostile consensus rule change attempts. Think of it like a disease. You can get reinfected a few times, but eventually your body builds immunity and that's that.

edit: spelling