Sorry, I wasn't writing with conspiracy theorists in mind— a grave error on this forum—, they were already asking them months ago. The people involved were already the nearest approximations of authorizes some reporters could find.

I hate to lend credibility to this thread by responding to it— but there is another point to make here:

The reporters are already asking the people involved in the foundation this crap— at least sometimes, sometimes they ask _worse_ people—  but a key difference is that when they just ask them normally they're getting their personal/company positions. If the community doesn't like what they say? "It's my Opinion. Fuck you." When people speak on behalf of the foundation there will at least be some accountability to the community of people who have chosen to become members— and pressure to hold a consistent, considered position, which is tempered somewhat from their personal and professional 'color'.  I think this moderating effect can be as improvement an important as the reduction in talking to the wrong people.

There are several BTC guild blocks in there, also 50btc.

Jesus. Why does everyone freak out stupidly every time someone notices an instance of a bunch of misreported blocks on blockchain.info. The blockchain.info relayed from fields are frequently wrong and if you understand how it works you won't be surprised by this.

I've locked this thread. The relaying activity of 82.130.102.160 is interesting; but it's almost certainly not mining blocks at all. Start a new thread that doesn't begin with the erroneous assumption that the blockchain.info relayed by field means anything reliable please.

Blockchain.info's block source identification is frequently wrong. Try not to panic over it.

Please link the edits you think are naive. I didn't intentionally remove any discussion of the risk. IIRC, I only removed the statements that it was safe to accept zero confirm transactions so long as you listen for conflicts— advice that was particularly horrific since conflicts aren't forwarded (something which was well known long before the paper), but isn't fixed by conflicts being forwarded.

Of course, situations where you have recourse externally to Bitcoin— often the case for offline buyer present transactions— are another matter; but thats independent of the propagation of conflicts.

…
No, you misunderstand the Finney attack.

The finney attack is:
(1) I mine a block with a containing a spend of one of my coins to myself, but I don't instantly announce it.
(2) Instantly after that I hand you a unconfirmed transaction spending the same coin.
(3) You do all the network sniffing and probing and checking with miners you like, seeing no double-spends you give up the goods.
(4) I announce the block. You lose. (probably) And if lose you don't know I tried, so I'll just get you next time.

In other words, I make the zero conf you accepted invalid by being absolutely sure that the conflicting txn will win— on account of already having it mined at my expense/risk.

The value I lose depends on how long I delay the block. Modest delays don't cost much— and this cost, in terms of bitcoin at least, will soon be halving.

Sniffing, checking, double spend propagation, and whatever can't avoid this... and it can be scaled by attacking many vulnerable things in parallel.

Of course, zero-confirmation transactions are unsafe absent a finney attack too; as the attacker can announce conflicts to miners and roll the dice on which version will get confirmed. Various somewhat complicated things can be done to reduce the risk in the non-Finney case by noticing a double spend (and one way of making propagated double spend alerts not be a huge DOS vulnerability was posted to bitcoin-dev about a year ago), but because they don't do anything for the Finney case, I'm skeptical that they're really worth implementing: Even with them the advice really needs to be that you should not accept zero confirmation transactions when you don't have any bitcoin external recourse or assurance, or you're at least rate limited in a way that you can't be robbed blind.  For digital goods transactions this is a bit unfortunate... but in a some other cases you have some other recourse and even if it's limited it's probably enough to mitigate.

"Real" well, it's real if you don't follow the advice widely propagated and embedded into the reference client: Don't accept zero confirmation transactions, unless you have some way of being secure against reversal externally to bitcoin.  They even underestimate the risk of it because they were unaware of how easy it is to buy hash-power to perform finney attacks now (and the cost is only going down, esp. with the upcoming reward halving).

I disagree with calling improved double-spend notices _a fix_, as finney attacks _can't_ be fixed. And while double-spend notification could be greatly improved, I don't think it matters because all that does is create false security against finney attacks. The fix that that came out of this was removing all the text on the bitcoin wiki that you added which suggested that accepting zero-confirmations were safe so long as you listened for conflicts... text I don't think most people knew was there until the paper pointed it out.

Why not just drop messages you're too burdened to handle? ... Bitcoin doesn't need reliable delivery.  That would avoid adding tracking code and complexity and changing the protocol. And message acceptance could be fairly distributed among peers/netgroups.

Doesn't stop someone from outright flooding you, but you can't stop that even if you ban them.


Right now? Two reasons: Just haven't been implemented yet, and because we don't have load-balancing in the initial block download and peer rotation:  Getting a highly rate limited peer could totally kill your performance.

I think it might be interesting to ask: Why are you interested in distinguishing these cases?

There is no voting. Just do nothing— your node will happily ignore idiots who made a totally worthless fork, no matter how many of them there are.

This post might as well say, "Will you quit bitcoin if some people install on their own computers a web interface to paypal called bitcoin?"

The pruned blockchain gets smaller. Which is relevant.

Also, looking at the poll question again..., the distribution schedule isn't even discussed in the whitepaper.

There has not been a hard fork to the protocol. (Unless you're talking about the blockchain irrelevant checksumming of the p2p messages). I run several very old nodes in isolation in order to detect attacks that only work against old nodes.

On the subject of the thread: The bitcoin distribution system is brilliant. And even if it was moronic, it can't be changed. Changing it would rightfully undermine every ounce of trust in the system, it would rightfully destroy the value of bitcoin completely. If you want money that can be inflated on a whim, there are plenty of robust government issued currencies.

... and this thread should be deleted because the OP didn't have the curtsey to offer a "No, and the OP is nuts" option. OP, do you still beat your wife?

an actual system implemented in our universe.

After all… an asteroid could hit you. Crazy simultaneously bitflips could ruin any level of redundancy in any system. etc.

Pure mathematics can be deterministic, implemented systems can't be completely.  The functional question is does it converge fast enough to high enough probability that its risk that the convergence was false is minor and burred under all the externalities?

It may be easier to explain something when its platonic ideal is deterministic, but since the actual implementation can't be completely those explanations are inherently misleading.

You don't have to store the signatures you have to store the signatures OR the txid, ultraprune stores the TXID but not the signatures in its coins database (which is the only thing it uses for validation, so not just possible, but implemented).   Because maximally efficient pruning always instantly prunes the signatures and does pruning per txout instead of per transaction you're going to have to store the txid anyways.

This is why I was loudly beating the drum up-thread about saying any OP_DROP stuff, if it exists at all should be in the scriptsig, and not the scriptpubkey... scriptsigs are always instantly prunable.

Unless you were talking about the data you need to initialize another node that doesn't trust you completely, in which case you can't discard the signatures no matter what is hashed.

I haven't yet read about about these other protocols, but I'm really disappointed to see more protocol proliferation. Getblocktemplate is well established, peer reviewed, and is good for bitcoin's decentralized security. I hope GBT gains whatever features its missing so it can subsume these things.  Having yet another protocol to cope with is a bummer.

Your claim is objectively false. If it were that important at all there would have been _someone_ to step up and maintain it. But there was none although we begged and begged and warned that it wouldn't go in without one.  Complain all you like about "deal breakers", — actions speak much louder than words.

You can achieve the same level of control using the console and listaddressgroupings / listunspent / createrawtransaction / signrawtransaction / sendtrawtransaction.  (Listaddressgroupings was part of the coincontrol patch, and I was willing to maintain it because it's all I needed to get the level of coincontrol functionality I wanted... I don't use the GUI)

This is a poor idea currently because only /actual developed/ demand for it are things like instant messaging, transaction source deanonymization, and timestamping— things which are would be done better without creating an immortal burden on all future users of Bitcoin by instead using payment protcols or an overlay messaging network (or both) (or in the case of timestamping O(1) cost for infinite use by doing it via the coinbase).  The applications where it would make sense are few, speculative, and perhaps won't ever be developed much less used.

It's not like its impossible to write non-standard txn now, you just have to get a miner to mine them— so please, if I'm mistaken point me to the virtuous usage of OP_DROP in the chain. Additions to the standard set should be based on established trial usage, not speculation.

As far as mitigation goes, if you were to propose that they only be standard in scriptsigs (allowing fast pruning) or P2SH, that they have a maximum of 32 bytes (as you did), and that SHA256(data) begins with 32 zero bits, and that they have a fee which is >= the mean in the last N blocks, you'd probably cut it down to harmlessness... because you would have successfully taken it away from most of the applications where it doesn't belong (except timestamping, which is probably the least bad especially if limited to scriptsigs), but I think that would be pointless because doing so also only leaves it for applications which are currently undemanded and non-existant.

Perhaps you need to speak more concretely then. What rule?
Any rule you can imagine could be met by a natural block gap. E.g. you set it to two hours. Then a natural two hour gap happens, and an attacker can create a chain killer fork that covers that gap.

No. They wouldn't. Nodes only propagate what they believe to be the best chain.

He would cut back one week, and create a fork with a bunch of consecutive timestamps.  e.g. 1 1 1 1 1 1 2 2 2 2 2 2 3 3 3 ....

Then a new bootstrapping node would startup and see "1 1 1 1 1 1 2 2 2 2 2 2 3 3 3". Then it would hear the valid chain, and see "1 600 1200..." and think that it jumped.

Then any bugfix that changes the typical network behavior is a 'protocol change'. Not really a useful distinction, in my view. We're just arguing over defintions, which is a waste of time. The important point is that a fixed node is fixed without upgrading any of its peers.  Call that whatever you like.

Of course there would be, otherwise it would be a config option and not an RPC.

We do not have any 'dynamic risk' "last resort" mechanisms anymore: no safemode alerts. Checkpoints only get changed by updating the software.
Your reject-txn sounds like sipa's fork-mode patch.
0_o I don't consider that a midpoint at all. We'd first have to rename Gavin "Bitcoin Bernanke", but fortunately I know he's smart enough to not accept that job.  I don't quite see how making it possible for anyone who kidnaps Gavin to shut down bitcoin is an improvement over your million dollar scale attack, as I expect it would cost much less than a million dollars to do so...

You're imagining a honest shorter chain, and a dishonest longer fork that has a big timestamp gap. Lets reverse that:

Imagine the network is following your rules. There is an honest longest chain. Now I construct a dishonest fork timestamped such that the true longest chain looks like it jumped forward in time relative to to my fork. Either the whole network now rejects the honest chain on seeing my fork (bad),  or they only apply your rule only one way on reorg decision (e.g. only demand it when switching from a 'better timestamped' shorter fork to a longer fork) which would mean that a newly bootstraped node's chain decision depends on which chain he heard first (because the dishonest fork may have been the longest from his perspective until he heard the longer one) and as a result network can't reliably converge (bad).

I'm skeptical about the extra work comment... The amount of work needed to overtake the longest chain from a given cut point is _constant_: its the amount of work in the longest chain after that cut. Difficulty doesn't come into play.  Ignoring the timewarp issue, there isn't much advantage that can be gained by lying about the timestamps, and most you could get 4x per 8 weeks you cut. Go too far back and you need a really significant super majority to get ahead in a reasonable time... and the advantage is just the inflation you could create for as a factor of log4(your rate/network rate) from undercorrection with your correct timestamps during the point where your chain is 'catching up'.


When I initially read your message I misread it as asserting that sufficiently old stamped blocks should not be considered. I realize now I misread it, but since someone else might have: