Then you make a self moderated thread?

In any case... I'd say stick a fork in it,  but it sounds like Bitmain is now planning on doing just that.  They've announced their intention to fork off onto a new and incompatible direction,  (also publicly announced that they plan to do a 72-hour selfish mine on their fork, which is ... odd to announce).

In my view, that after the near unanimous rejection of segwit2x by active developers (even BU) Bitmain announcing they're gonna do a spinoff is the final killing blow on that absurd agreement.


uh, those things are not dealing with "code" features they're limitations in the Bitcoin protocol which are fixed by segwit. Segwit is the fix and it was needed because the protocol design Satoshi had a few limitations.  There have been many softforks in the past to fix other limitations in the original design-- some performed by Satoshi himself, some performed by the current folks that maintain the software.

I agree.

The only argument that the USAF can't fail by design is just that it's "failure" is to become an altcoin...  but it's fairly dumb way to construct an altcoin.

For 99% of developers if we wanted to construct an altcoin that isn't how we'd go about it, and for 99% of users if you want to use an altcoin there are already many choices.

This is simply untrue.

Unless your internet connection is very slow the vast majority of time is spent in validation and data handling even on a 24 core host.  

If you download separately you cannot overlap the download and validation.  So unless your download is nearly infinitely fast it must be slower.

This experiment is conducted regularly in real conditions at least with every release (since we benchmark for synchronization performance regressions).

Orphaned blocks are about 1% -- who cares if there is 1% of overhead in the files?  The linearize tool in the contribs directory will create block files without them-- sure, but they're not a big deal. The main reason to exclude them is to get a reproducible file.  The wallet _never_ has any effect on the content of the block files.

The risk with copying a chainstate, beyond the risk of being tricked onto a fork where the attacker has created a bunch of coins out of thin air is that the leveldb database files are not a safe external interface and it may well be possible to get remote code execution with a specially crafted database.  BDB (used for the wallets) can easily be caused to crash with out of bounds memory accesses from crafted database files, for example.

I'm pretty sure that that a UTXO assume-valid type sync will be supported (even a default) in the future-- but that doesn't mean that copying database files from third parties is safe-- personally I'd never do it.

Sure but they can do that themselves.

Pretty good when they're half the reachable "nodes" out there....

It doesn't effect anything.  The only time those addresses are used is by by the peer when it generates an address broadcast message back to the specific peer that gave it that address.

I believe those same IPs were advertising classic for months before and XT before that.   I think many people have blocked them or even all of amazon from their node for a long time.


No such advantage.  You don't advertise that other nodes IP to anyone else except potentially that peer itself.

Anything prior to 0.10 will run so slow it might not catch up--  you can keep on with what you're doing but if it gets stuck, don't worry, just upgrade.  To play it maximally safe, make sure you have multiple good backups of the wallet.dat made while Bitcoin is not running.

Cheers.

Did any of you even read the comment you are supposedly outraged over?


Someone complains about the fee their wallet is assessing for a 71 input transaction-- one as large as 40 or so median sized transactions.

Luke suggests that they'd get charged more if they used fiat instead.

You can happily debate if Luke is write or wrong there (esp. if you consider the value preservation of the currency... ), but it's incorrect to say that he's just telling someone to use fiat.

This directly contradicts the text of the whitepaper-- which specifically talks about an attacker overpowering with invalid blocks:


But more importantly, it contradicts the behavior of every version of Bitcoin ever released, including all those released by Satoshi. It also contradicts the behavior of every blockchain like altcoin that I'm aware of.

No one has any idea what coins are Satoshi's -- except for the coins paid the the block 0 address and those left over from block 9.

People speculate about a lot of things-- but most of these speculations are provably false or are at least completely unsupported.--- they just get spread around to justify the super massive and unethical premines in systems like Ethereum.

For all we know Satoshi might only own a small amount of Bitcoin.

Regardless, you're sure as hell not going to take anyone's Bitcoin's from them.

The integrated tor hidden service support could be pretty helpful here...

AgentofCoin, Thanks. I agree with basically every point made in your last two posts.


Precisely, in fact getting many people to agree to a capacity increase at all given the current environment was very difficult.  The primary selling points was that segwit was risk reduced in many ways (e.g. lowering sighashing cost), that we had other scaling tools planned (BIP152 for example), ... and that it was worth taking some risks to satisify the demands and end the drama.  Oops.

From my perspective: the community already already compromised on the part that we thought we could compromise on.  Beyond that and it's akin to demanding 'compromise' in the form of sawing a disputed infant in half.

I think it's fine and healthy that it takes a while to sort these things out.  Internet scale protocol development doesn't happen fast-- 4Byte ASNs in BGP took about a decade, and BGP is a easier to evolve than Bitcoin in many ways.

In any case, in my view, the slogan should be:

Bitcoin will not be compromised.

In this thread: people whining that they're unable to force third parties to compromise Bitcoin.

Wow, repeating proven fraudulent claims from the BU folks, good for you.


Those ticks are spider restarts, a data artifact.  There has never been an exploited node crasher for the Bitcoin project (and AFAIR there has only been one potential one, which we fixed before it was exploited-- The BIP37 integer divide by zero bug)

And you still will-- by relaying blocks to the nodes you connect out to.

Right now there is no way to distinguish nodes that can serve blocks near the tip with ones that can't serve blocks at all.

And there are plenty of nodes that can serve everything, so adding more flags hasn't been the highest priority.  Though there has been recent progress on that.

And that the minimum feerate to relay and get into the mempool in the first place will go up.

Smaller blocks reduce memory usage, considerably.

The mempool does not increase memory usage because it has a fixed size and is shared with the dbcache. If blocks were larger the mempool would also need to be larger by an equivalent factor so would many other parts of the system.

Moreover, no matter what the blocksize was someone could inexpensively produce a bunch of transactions between blocks and make your mempool as big as you want.

Yes, Segwit script v0 P2WSH (the p2sh for segwit) uses 256bit SHA2; both boosting the security to 128 bits, and removing ripemd160 from the potential locations of weakness.

There is a 160 bit supported, but only for single key checksig only. Basically so that the very common single key case that gains little from the 256bit hash isn't any longer than non-segwit.

Why do you write "alleged creator" instead of "established fraudster"?

Wright has show himself to be a fraudster beyond any doubt, and even before it there was almost nothing supporting his claims... a significant percentage of this forum has a better claim on being Satoshi than this con-man. True: they're not claiming it and he is, but they haven't been caught lying about it over and over again.

Wright has been fanning the blocksize drama all along-- it's a simple formula for separating less technical business people from competent engineers that could point out the obviousness of his fraud.

Sounds like the funding for this thing is fake too: http://hoaxchain.com/media1.html

This is true for many things but not for consensus systems.

In a consensus system with multiple major implementations if _any_ implementation has an issue everyone has an issue-- and if there is just a "disagreement" but none are objectively wrong, then there is still an issue.

The reason for this is that for a consensus system the primary purpose is to be consistent, so any inconsistency is a failure, regardless of whom is "right" vs "wrong" or even an otherwise harmless difference.  Inconsistency immediately creates an opportunity for funds theft, when you think a state is final but it really isn't and it gets reversed.

An implementation is a _precise_ definition.  A pile of paper is not, or to the extent that it is precise it's still not that relevant: if paper says X and the network does Y, then Y it is, you can't generally just undo Y later without undoing transactions that people thought were final and irreversible.  Good specs are useful to aid understanding and analysis, but cannot define the network because they cannot control its action from moment to moment.

The implications are clear to anyone who has spent a reasonable amount of time doing serious engineering for a distributed consensus system.

You've got it.

You should generally think of birthday problem numbers as approximate in any case,  because to achieve the bound you need lots of storage.  A cost optimized solver will make some time/memory tradeoff and usually end up using a couple times more computation than the birthday number in exchange for little to no storage.  (google floyds cycle finding algorithim)

And yes, thats the risk-- that your counterparties degree of freedom in choosing part of the contract will let them find an alternative contract with only collision like work, rather than with second-preimage like work.

You can mitigate by having multiple rounds of communication with commitments, but few to no one will implement this in practice:  Each communication round is a huge software engineering and UI cost, and most people don't understand this collision vulnerability (or _any_ collision vulnerability) even after having it explained.  The longer hash should also be somewhat more secure against second preimages assuming our hash functions become weakened by attacks in the future.

[Basically _any_ time I've seen a collision come up in discussions about the protocols people-- even people who should know better-- get them wrong. Someone on Reddit just the other day argued that a 64-bit collision would take 2^64 work, so I generated one based on his message.. then he argued that I got really lucky to have managed to produce one using only a 32-bit nonce and couldn't provide another, so I did...   they're highly unintuitive to people)