Right, and all BTC in segwit addresses on the original blockchain will be protected.


The blockchain must fork for this attack to work, so it's simple really: anyone can create a fork anytime with rules that permit stealing outputs. There's nothing special about choosing a "Segwit booty" approach, any fork can choose to redistribute BTC in any way the creators of the fork see fit. You're trying to say this is somehow a weakness in segwit, it's not.

So, now you've popularised this idea of a "steal from Segwit addresses" fork, what's the reason to do it? Do you have one? Why don't you want to steal from vanity addresses, or Satoshi's coins? All are equally possible when you fork, so why not some other target

Annoymint doesn't like the implications of proof of work; he's been claiming for 5-6 years that he's working on a "blockchain breakthrough", but never proves he's working on anything


@Annoymint, you need to start a new Bitcointalk user called "Proof of everything other than work"

What's stopping some incendiary event from causing either a huge pump or huge dump, tomorrow, next week, in August or in the next 5 minutes? All predictions tend to make the "all things being equal" assumption, but there's no good reason not to expect surprises that completely derail any prevalent trends. Saying "we've been here before" in respect of long term trends is no less true than saying "we've been here before" in respect of sudden shocks.

Maybe the Chinese government will reintroduce crypto trading next week. Or maybe the EU will ban crypto exchanges tomorrow. No-one knows, but let's not forget that simple market cycles aren't the only factor.

Oh I get it now, tromp was saying "if that were true", explaining his edit

This has no basis in fact.

All blocks must have a hash lower than the threshold, there is no logic in Bitcoin block validation that behaves in any way differently depending on how low the hash value is of a new block. Either a block is the lowest hash value for the next block solution, or it's not. "Unexpectedly low" is therefore completely meaningless. The only logic that exists in Bitcoin block validation is "lowest", not "how low".


Let's remove this "problem" you've identified lol, only the longest chain wins. We then have a "new" problem; how to resolve chain forks when 2 blocks are found before either block has 100% acceptance, and so different parts of the network accept either block. This problem was solved in Bitcoin back in 2009 or 2010, and now you're saying that the solution is causing the problem. Those who merited your post should ask for the merit points to be returned.



But you were wrong, so it actually makes zero difference

Edit: I misinterpreted, sorry tromp

Where's yours?

"Liar, liar" was your reply, and unfortunately you failed to identify a lie, or provide reasoning. That's not a request as such btw, I think your reply speaks for itself

The flexibility of a programming or scripting language is always a trade-off against how insecure or buggy it will be. If more complexity is permitted, then there is a much wider range of possible test cases, this is a direct reflection of the higher diversity of expression allowed by a complex language. Trying to imagine everything that's possible, and hence everything that could go wrong is simply alot of work. That's why a layered approach to complexity is sensible; discovering problems in the base layer is easier to reason about, which makes designing upper layers both easier and safer. Because the upper layers function using well tested & well understood primitives from the lower layers, it's easier to design the upper layers in a way that's more predictable and fails more safely.

It's good exercise to refute Annoymint's claims, it consolidates the way one understands Bitcoin.

OTOH, I had Annoymint and his alias accounts (TPTB_need_war, iamnotback, dinofelis etc) in mind when I suggested adding a pay per post feature to the forum. I was wrong, I hereby propose "pay-per-character"

(seriously, imagine if you earned enough merit to get a cut of the paid-posters? Annoymint would be paying you every time he unleashes his rainbows of effluent)

Only pre-Segwit nodes (about 2% of the network, none of which are miners) interpret Segwit tx's as ANYONECANPAY. It's the soft-forking logic that keeps pre-Segwit nodes from rejecting Segwit blocks, every other node (the other 98%) knows that Segwit transactions need a valid signature (hence why 95% of miners was the activation threshold for Segwit). Remember how it got activated: miners essentially began to threaten each other with orphaning non-Segwit signalling blocks to force the others to enforce the Segwit soft fork. But apparently, according to your logic, miners will wait until Segwit addresses are in majority use, then roll back the Segwit soft fork and steal everyone's BTC, mwuhahahhahaha!

Here's a little issue with your theory: Segwit buried deployment, which maintains Segwit's activation since block number 1.

And there's always going to be enough independent miners to keep the chain going from attack block -1, any miners contemplating such an attack know this in advance. So it's not a functional attack at all, and certainly won't be after Segwit deployment is permanently enforced.



This is last year's FUD, and you've been forced to scrape this one up off the floor after the biggest clown trolls in existence barfed it up when they couldn't get it to stick.

You've not got much imagination, your only gift seems to be that you believe if you can just keep talking, then everyone will accept your babbling. But what happens in reality? You stop talking

Annoymint is essentially saying that the miners can follow any rules they like, the users must follow their choice of consensus rules. Which isn't what's happening in reality of course, but it's a clever argument nonetheless.

Any comments on how your sudden reappearance in the Bitcoin world is coinciding with other general market FUD, Annoymint? Oh, and please tell us about the latest developments in your satanism-resistant cryptocurrency, I'm really, really interested What's new since when you started ? (we've been waiting to hear even a little news about your big plans since... what, 2013?)

Tax is wrong, so ruthbabe may be a little hazy on the details of the written law, but morally, not paying is the right thing to do. Taxes were always stealing, they've been normalised because of government propaganda that one is paying for services (the reality is you are paying-decades old debt) and overwhelming force (i.e. police violence) simply takes what is due, or kidnaps the transgressor.

Bitcoin is a change as big to preventing tax theft as Bittorrent was to copyright: everyone has copyright now, so the concept is meaningless. And when everyone has Bitcoin, they will slowly begin to refuse to pay taxes. It's impossible to take Bitcoin with force: Bitcoin is resistant to violence, there's nothing that can be done to force you to pay BTC to anyone

I'm happy to pay for what I use, with the money going directly to the person I'm paying. There's no reason why I have to pay the government, so that they pay old unpaid bills then borrow money to pay for the actual service I need. I'm not paying off 60-70 year old government debts so that people 100 years in the future can pay for the government services I was using today. That's one bullshit unethical theft based system, and you've got no business telling other people what they must and must not do with their own BTC, pay the extortion charges levied against you if you choose (lest you piss your pants in fear, of course)

This is not true. Bitcoin might not have the same contract programming flexibility as Ethereum, but that is widely considered to be flaw in Ethereum's design methodology (the most prevalent opinion among developers is that more complex contracts should be implemented as additional network layers to Bitcoin, and/or as separate sidechains). Transaction privacy is much the same, better as a separate protocol layer (and the practialities of Ethereum and Monero prove why; both have very fast growing blockchains, which is a decentralisation compromise).

Additionally, Bitcoin source code is constantly borrowed by the (much smaller) developer teams working on other cryptocurrencies even after the new coin is launched (this is sometimes referenced directly on the webpages of pull requests in the Bitcoin git repository). A large number (~20 regulars, plus many many more occasional contributors) work on Bitcoin, whereas most other coins have maybe 3-5 developers at the max. The development focus is on Bitcoin, and maybe that does have an element of 1st mover advantage to it, but that can only be maintained if the development is of a consistent high quality (and there's been nearly 10 years of this kind of impetus with Bitcoin development, no other coin matches that). A large number of talented programmers work on Bitcoin, and that's what makes the Bitcoin network function so well and attract users, not incumbency.

RIght, but I'm asking about python-trezor, not the wallet.trezor.io service, or Electrum. My plan is to use the device with some privacy, you can't get that unless you use python-trezor. You can already generate bech32 / bc1 addresses with python-trezor, but it's not obvious that spending works with python-trezor yet (the documentation at https://github.com/trezor/python-trezor/blob/master/docs/EXAMPLES.rst implies you might be able to, but it's not clear you definitely can spend from bech32)

2 words: Lightning network



It's impossible to regulate. That was always the point of Satoshi's design, and so far it's working pretty well. The reason regulation is only ever spoken of in relation to the points where cryptocurrency interfaces with fiat is because that's the only possible way. If people use cryptocurrency p2p, there's nothing that can be done, unless you're one of these people that thinks it's cool to pay money to mass-murdering gangs of thieves when you don't actually have to.

Telegram is also somewhat centralised, it requires connection to a Telegram server to find users on the network (Skype is the same of course)


Tox is the only video/messenger protocol that works p2p right now (also end-to-end encrypted). It's only 3-4 years old, though

so I found this info about using bech32 addresses with python-trezor: https://github.com/trezor/python-trezor/blob/master/docs/EXAMPLES.rst#bitcoin-examples



But in the tx signing section following, there's no mention of bech32. Anyone have any experience or knowledge of whether a Trezor will sign transactions spending outputs from bc1/bech32 addresses?

so I found this info about using bech32 addresses with python-trezor: https://github.com/trezor/python-trezor/blob/master/docs/EXAMPLES.rst#bitcoin-examples



But in the tx signing section following, there's no mention of bech32. Anyone have any experience or knowledge of whether a Trezor will sign transactions spending outputs from bc1/bech32 addresses?

You didn't read what marcus said either (nothing about what Microsoft might do to change Github, which was your apparently pertinent question).


I have a radical tip for you (again): read the thread (and the replies of anyone you attempt to employ as argument)

Bitcoin Cash didn't exactly succeed in hard forking either


Bitcoin Cash did a 2nd hard fork very quickly after the split from Bitcoin, as there was not enough mining capacity to produce more than a few blocks per day. This obviously undermined the "faster than Bitcoin" marketing that Bcash still employs (and demonstrates how little planning went into the first hardfork). This wasn't the end of the episode; the Emergency Difficulty Adjustment logic introduced as the 2nd Bitcoin Cash hardfork was later abandoned by a 3rd hardfork (which reinstated Bitcoin's diffculty adjustment logic) once Bitcoin Cash's difficulty was matched with it's small hashrate.

Even after that, Bitcoin Cash's original hardfork didn't function correctly. I used version 16 of the Bitcoin Cash client to dump all my BCH last winter. When it was caught up to block 478548 (the 1st hardforked Bitcoin Cash block on August 1st 2017), the software refused to follow it's own fork! (the debug log suggested that the Bitcoin Cash software considered the Bitcoin Cash blockchain to be invalid)


So, over 3 months after their original hard fork, Bitcoin Cash failed at least twice to correctly perform their 1st hard fork. They needed 2 additional hardforks to correct the problems of the 1st, and it still didn't work after fork number 3. Does anyone know whether their recent 4th hardfork (or was it the 5th?) actually worked? Has anyone dared to mine a 32 MB block yet? Or even a 1MB block!

I have a radical tip for you two: read the thread

Microsoft are a problem to Github because they are a computing & tech business that have a history of making progressively worse tech; either by buying other companies and regressing functionality/performance, or doing the same with in-house products they've owned for years. More news: Bitcoin is a technology too, it helps a little if you know something about how the technology world works, instead of writing arrogant polemics that can be easily dismissed using information from the same page you posted to.