Yeah, you lot are hilarious. The only thing that's an actual conversation is what's quoted in my original post. You might want to re-read it to remind yourself.

I'm surprised you people haven't figured out that I 100% think the right approach is to do everything we can to ensure that at a technical level Bitcoin can't be regulated.

Don't they teach rhetoric in highschool anymore? Arguing your opponents position to show how wrong they are is a pretty basic technique.

Reposting http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02159.html


It has been previously(1) proposed that hashcash using the same PoW
function as the Bitcoin block hashing algorithm be used to create
hashcash whose value is denominated in Bitcoins. This poses two problems
however: widespread use of such hashcash would harm overall network
security and determining the value of the hashcash requires knowing the
revenue miners can gain from transaction fees at a given block height -
a non-computable function. However, with some modifications we can
extend the idea to directly denominate the hashcash in Bitcoins at the
cost of a small increase in proof size.

Recall that the fundemental problem is the need to do some work to make
digest D have value V, resulting in a proof that can be given to a third
party. We want V to be denominated in Bitcoins, and we want the actual
economic cost to create P to be as close as possible to the face-value
V. Finally should computing P result in a valid Bitcoin block header,
the creator of the proof should have a strong incentive to publish their
header to the P2P network and extend the current best chain.


# Proof structure

Lets look at the elements of the proof from the block header to the
digest.


## PoW Block Header

This must be a valid block header. It is particularly important to
ensure that the header can be linked to the actual blockchain, although
the header itself does not need to be a part of the chain, and hence the
block hash does not need to meet the difficulty requirements.


### Previous Block Headers

The proof may optionally include one or more previous block headers in
the event that the PoW block header's previous block is an orphan.
Unlike the PoW block header, these block headers MUST meet the
difficulty requirements although an implementation MAY skip actually
checking the difficulty if a difficulty retarget has not happened or the
PoW is timestamped. (see below)


## Partial Transaction and Merkle Path

The partial transaction consists of a SHA256 midstate followed by
exactly one transaction output. The merkle path to the PoW block header
MUST prove the transaction was the coinbase transaction and not any
other transaction.


## Transaction Output

The last transaction output must have a scriptPubKey consisting of
exactly one PUSHDATA op which pushes H(D | N) to the stack. Its value,
V', is the basis for determining the value of the proof of work. V' must
satisfy V' < k*Vi(h) where Vi is the inflation reward for the PoW block
height and k < 1 For a number of reasons, including making sure there
are strong incentives for broadcasting succesful PoW solutions, the
value of k should be chosen fairly conservatively; the author suggests k
=3D 1/10 as a ballpark figure. Finally N is some fixed value specific to
hashcash of this form to ensure the txout proof can-not be reused.

Vi can also be calculated as the median of the last n "anyone-can-spend"
outputs seen in coinbases when the value of the inflation reward falls
low enough that using the inflation reward is impractical.


## Timestamp

If the proof-of-work is used after a difficulty retarget the PoW needs
to be timestamped in the block chain with a merkle path leading to a
valid block header. The difficulty used for calculating the value of the
PoW then becomes the minimum of the difficulties of the PoW previous
block and the timestamp.


# Determining the actual value of the PoW

The proof proves that work was done to find a valid block header. That
block header, had it met the difficulty threshhold, could have created a
valid block worth at least the inflationary reward Vi(h) to the miner.

The coinbase transaction output and merkle path shows that were such a
block found, the miner would have then given away V' to whomever managed
to create a transaction spending it when the coinbase matured. The
coinbase takes 100 block to mature, so the chance of any one miner
collecting it is proportional to the hashing power they control.(*)

*) As with fidelity bonds we make the assumption that no party controls
more than 50% of the hashing power - the assumption underlying Bitcoin's
security anyway. If this assumption is proven incorrect or
insufficiently strong, possibly due to a cartel of miners banding
together to create low-cost PoW's, the output can use the provably
unspendable/prunable OP_RETURN <digest> scriptPubKey instead with a
non-zero value.

With P(block hash, target), the expected probability of a valid PoW
being found given the work required to create the block hash with the
given difficulty target, we can finally calculate the value of the PoW
in terms of expected cost: V =3D P(hash, target) * V'


# Pool implementation and 51% attack security

Because doing the work required to create coinbase txout hashcash is
sufficient to also create a valid block a pool can safely rent out
hashing power to create hashcash of this form on demand without making
it possible to rent large amounts of hashing power directly on short
notice. (though some extensions to GetBlockTemplate for hashers
verifying it may be required)

Because the anyone-can-spend txout is the basis for the value of the
hashcash the value remains computable even if transaction fees become a
larger proportion of the block reward in the future.

Unlike announce-commit sacrificies(2) proofs with very small values can
be easily created; the pool operator can make a trade-off between the
profit varience - remember that a block header with a valid PoW
represents a loss - and latency by adjusting the proof of work
difficulty and V'.

As an aside, note how the mechanism of a anyone-can-spend txout in a
coinbase can replace the announce portion of an announce-commit
sacrifice; a coinbase transaction is the only case where a single merkle
path proves that the transaction output was possible to spend in a
subsequent block, but was not yet spent; also an argument for allowing
coinbase transaction inputs.


# Application: Paying for additional flood-fill bandwidth

Additional messaging applications built on top of the Bitcoin P2P
network would be useful, yet there needs to be some general mechanism to
make DoS attacks expensive enough that they are impractical. For
instance a useful P2P network feature would be a mechanism to propose
trust-free coin mixes transaction outputs, propose specific txout sets,
and finally a mechanism to broadcast valid ANYONECANPAY signatures so
the inputs and outputs can become a valid transaction. By separating the
txout and signature broadcasts, who is paying for what output is made
very difficult to determine.

Of course such a mechanism will likely come under attack by those trying
to combat anonymity. However with the coinbase txout hashcash mechanism
those attackers are forced to either contribute to the security of the
Bitcoin network or incur much higher opporuntity costs for conducting
their attack than honest nodes pay. (remember how the choice of k =3D 10
makes for a large ratio of maximum V' value to Vi(h) inflation reward)

To reduce amortized proof size one proof can be used for multiple
payments with Rivest PayWords and similar techniques.


# PowPay - Off-chain, anonymous, probabalistic payments

By setting the special txout to a scriptPubKey spendable by the
recipient we can prove to a third party that work was done that with
probability P(hash,target) could have resulted in a txout spendable by
them of value V' Thus the expected value of the payment is V =3D P(h,t)*V'
The recipient needs to make the proof non-reusable, either by recording
all proofs submitted, or by requiring a nonce in the scriptPubKey: (*)

    <nonce> DROP {additional ops}

*) Note the implications for the IsStandardInput() test.

Because the recipient has no way of knowing how the sender paid to have
the hashing done on their behalf the source of the funds is unknown to
them. Additionally the payment can be of any amount less than a full
block reward, and the time varient between actual payments can be
reduced to, in theory, as little as the block interval itself with 100%
miner participation.


## Maximum Payment amount

Unlike coinbase txout hashcash the maximum value of a PowPay transaction
is strictly limited by the inflation reward; the trick of calculating
actual cost by prior sacrifices doesn't work because no honest sacrifice
is involved. In any case it is desirable for the mechanism to account
for a large percentage of total transaction value.

The issue is that should a valid block be found either the miner must
still have a strong incentive to broadcast that block that can be proven
to the recipient, or the miner must not be the one who controls that
decision.

The latter option is possible by inverting the relationship: now the
recipient constructs the block, and the sender simply arranges for a
valid PoW to be created - essentially the recipient acts as a mining
pool with an extremely high minimum work, and the sender provides
hashing power. With the 1MB blocksize the cost to operate the full
validating node required is low and attacks on block propagation are
difficult to successfully pull off.


### Supporting PowPay volume in excess of inflation reward + tx fees

To support overall PowPay volumes that are in excess of the inflation
reward and transaction fees the sender can provide the recipient with
signed transaction inputs subject to the constraint that only blocks
with PoW's generated by the sender can be used to spend them. For
instance a nonce in a well-known place can be provided by the sender and
included in a modified block header. By modifying the block hashing
algorithm so that PoW-withholding is not possible - a significantly more
serious problem in this application - the sender still is forced to send
all potential solutions to the recipient, including possible winning
ones. Provided that attacking block propagation is difficult the sender
can't prevent the reciver from spending their transaction inputs.


## Scalability

PowPay can provide much greater scalability than Bitcoin itself, in
terms of payments per second, however it is still limited in terms of
actual fund transfers to recipients per second. A naive implementation
would give a actual transfer every ten minutes maximum, and a highly
sophisticated solution 7/second. (albeit probably requiring a hardfork
to solve PoW withholding and/or use of third parties)

At the same time the proofs required become large with an increased
blocksize, and in the case of the inverted "recipient builds blocks"
mode the recipients either incur large costs running full nodes, or
greatly disrupt transaction flow for on-chain users by mining blocks
with no transactions in them at all. (remember that a recipient who
trusts someone else to construct the blocks for them is trusting that
third-party to do so correctly)

The latter is especially problematic because as the blocksize is
increased a higher percentage of the cost of mining goes to the overhead
required to run a validating node, rather than hashing, which has the
perverse effect of decreasing the cost of mining blocks with no
transactions in them at all. (or transactions that the miner knows have
not been revealed to other miners)

The analysis of this strange mixed bag of incentives is highly complex.


# Paying for mining

TxOut HashCash and PayPow both require the sender to somehow get someone
to mine on their behalf. The exact nature of these relationships will
vary and are beyond the scope of this paper.


# Eliminating PoW withholding

While the above examples have used economic incentives possible within
the existing Bitcoin system a structural incentive is possible as well.
A nonce N is chosen by the party paying for the PoW, such as a pool or
PowPay recipient, and H(n) is included in the block header.(*) The PoW
function is then modified to consider the PoW valid if the sum of the
expected hashes required to find H(B) and H(B | n) exceeds the current
difficulty target.

*) Note how the block header can be extended, while remaining fairly compat=
ible
with existing ASIC mining hardware, by taking advantage of the fact that
ASIC's use the SHA256 midstate at a starting point for their PoW
calculations.(3)




1) "Re: [Bitcoin-development] Discovery/addr packets (was: Service bits
for pruned nodes)" - 2013-06-06 - Peter Todd <pete@petertodd.org> -
bitcoin-development email list

2) "Purchasing fidelity bonds by provably throwing away bitcoins" -
https://bitcointalk.org/index.php?topic=3D134827.0 - Peter Todd

3) "Re: 32 vs 64-bit timestamp fields" - 2013-06-09 - John Dillon
<john.dillon892@gmail.com> - bitcoin-development email list

The fact that usually it works because most of the outputs were recently created is incredibly dangerous. If the ratio of best case to worst case performance gets bad enough the attacker just has to come along with a block spending outputs that weren't recently created, or otherwise picked in a way where retrieval happens to be slow, to knock slower miners offline. Even worse is if they can come up with two blocks where each of those blocks trigger performance problems on one implementation but not the other they can split the network. They don't even have to mine those blocks themselves if the transactions in them are standard enough that they can get someone else to mine them.

In Bitcoin any performance problem can become a serious security problem. We only get away with it now because computers are so fast in comparison to the transaction volume and 10 minute target, but if we start needing to "optimize" things, including solutions like aggressively passing around transaction hashes rather than transactions themselves when a new block is propagated, we open ourselves up to serious security problems.

You let people backup their private key to multiple secure hardware devices. The devices authenticate each other and they key is copied over encrypted. The need to prevent double-spends means this process becomes a bit more complex but there's nothing hard about it.

Secondly even if there is only one copy of the private key you can sign nLockTime'd transactions that send the coins to an address the user does control, but some time in the future. If the hardware breaks the user just waits until the lock expires and they can get their coins back. That interval can be fairly short, a day is probably fine for a lot of use-cases.

Thanks! My version is a pretty agressive mempool rewrite, so a simpler alternative would definitely be appreciated and valuable.

Exactly. Basically when TX1 is removed, every transaction that depends on it gets removed too.


Yeah, it's unfortunate there aren't any easy answers here. Had Satoshi done this from the start we would already have various solutions implemented, but now it will take some time to do so, and frankly there just won't be the consensus required to make any of those solutions without making the need clear first.

Having said that, if replace-by-fee is widely adopted many sites, particularly gambling, have an interesting option: withhold large winning payouts until the input transaction confirms, and if the customer tries to cancel the transaction the moment they see they have lost, create a "counter" double-spend that takes their full bet and sends it to fees. A rational miner will see your "punishment" transaction and mine that rather than the customers attempt at canceling the transaction.

There will be a window where not enough miners have adopted replace-by-fee to make this work reliably enough to be useful, but if adoption is high it's a pretty good solution. Just make sure you record every transaction so you can prove the customers fraud after the fact, and be careful to only create the punishment transaction if the txout to you, rather than the change txout, is modified. You'll also have to think a bit about how the winning number is calculated.

In any case for your site as always make sure you can detect double-spends so you can limit your losses when they start happening in large numbers.

That service may not be at all what you'd expect either: the bitcoin-otc.com P2P exchange provides a P2P reputations system. You could combine that with a simple "payment protocol" of just PGP signing your trades, and a mechanism to retrieve double-spent transactions from your wallet to make it easy to prove to others that you were defrauded. The initial implementation doesn't have to be fancy, just something an expert could use to verify someone else's claims, but it'd still be significantly better than what bitcoin-otc has right now.


In fact I've already got most of a recursive fee calculation implementation written, including unit tests. But because recursive fee calc is required to make the patch robust against certain types of DoS attacks, I want to hold off on making that code available to give people time to experiment with tx replacement, in particular how they're merchant code handles it, while still discouraging miners from using it on mainnet. Similarly that vector-vs-set bug you found was a very nice catch, but again, I'm going to hold off fixing it for another two or three weeks.


The "service" layered on top doesn't need to be an account tied to one vendor. I mentioned bitcoin-otc above; another approach is to purchase a fidelity bond tied to a pseudonym, and use that bond to vouch that you will not double-spend some given payment. Break that promise and the recipient can publish the fraud, invalidating the bond.

Yeah, the user-interface aspects will be tricky to communicate. For instance if an undo button is implemented, it probably should actually be called something like "Attempt to cancel", and at least initially be hidden off in the RPC interface anyway.

Increasing the fee isn't such a big problem, although a dialog box that points out you have the option after some reasonable delay is a good idea. It should probably be called "Offer a higher fee" so users aren't as surprised if the lower fee version goes through anyway.

Yup.

Also, if the network doesn't operate on this principle, it will be because we've implemented ways to punish those who do otherwise, and all the ways to do that involve ad-hoc secondary consensus mechanisms that make the network more fragile, and make it harder to run a profitable mining pool on a limited budget. Remember that there is no magic way to know if a transaction is a double-spend - you're limited network bandwidth can easily mean you just don't see the original transaction where a bigger, more centralized mining pool with a fast network connection will maintain a more view of the mempool that is more consistent with other large pools.


Indeed. Part of the reason why I decided I'd write the patch and collect the reward was because I knew if I did so I would have some control over how it was "released into the wild" - someone else might just want to for the money and not bother to do responsible disclosure. Heck, I was thinking of turning down the reward, but with John also donating to my blocksize video... well, Bitcoins are fungible. In any case I'm pretty sure his intentions are honorable after the discussions I've had with him.

Yes, evoorhees is well aware of that and has been contacted.

They will be introducing off-chain betting in the near future so it won't be an issue for them soon. I and John are discouraging mainnet miners from making use of this patch immediately through a variety of methods to give people time to respond.

Nope. This is pure replace-by-fee, under any circumstance where two transactions would spend the same inputs. For instance I could have a transaction with a whole bunch of inputs and outputs, and another one that spends only one of those inputs and has one output. If the fee-per-KB of the second was higher than the first, and the total fee paid by the second was also higher, then the first transaction and all dependents would be removed from the mempool and the second added in it's place.

Among other things, I intend to implement an "undo" button that simply creates a transaction spending one of the inputs of an unconfirmed transaction in your wallet with a higher fee, sending the remainder back to your wallet.

Yup. The reward was initially $500 and increased to $1000 after I pointed out to jdillon that replace-by-fee needed recursive fee evaluation, IE Luke's child-pays-for-parent concept, or it would be susceptible to DoS attacks. That code is easily $500 of engineering time for a prototype.

To be clear, replace by fee was initially something I proposed, and jdillon decided to offer a reward to actually implement it a few days later. Like myself he has strong feelings about ensuring mining remains decentralized and free from regulations.

Yup. I've spoken with evoorhees about this issue and while I don't know what their plans are exactly they had no objections. In fact, out of the roughly half dozen people running services I have either contacted, or who have contacted myself or John Dillon, nobody has actually asked us not to implement replace-by-fee. I don't want to pretend I'm speaking for them, but I suspect the few merchants that actually need zero-conf security would like to see a genuinely secure solutions be implemented like trusted computing, fidelity bonds w/ double-spend fraud proofs and off-chain mechanisms rather than the current half-measure of hoping everyone follows a de-facto standard.


Mind expanding a bit on what you mean by non-determinism?

Peter Todd

Absolutely, and such transactions have much better privacy than on-chain transactions ever will, not to mention they can be instant. There is a fair bit of complexity involved in mitigating risk given that no trusted computing hardware is totally secure against an attack, but it's easy to make any attack far too expensive to be feasible. You wouldn't want to trust it for, say, buying a house, but it's plenty secure enough to buy your morning coffee.

I'll be talking about that exact idea at the Bitcoin conference next week.


Take a look at the wiki: https://en.bitcoin.it/wiki/Funding_network_security

Mike Hearn has some interesting ideas with assurance contracts and other schemes that in the long run can probably replace miners fee rewards. In any case the inflation subsidy will remain quite large for a long time to come; it hits 1% of the face value of all Bitcoins out there in 2024 or so for instance.

Yeah, coins are closer, but there are even efforts to have every individual coin serialized.

Right now the serial numbers on dollar bills aren't too much of a worry but there are a lot of efforts underway to incorporate bill scanners into ATM's and even cash registers (with RFID) combined with massive databases to track the movement of every last bill. It might not be many more years where even if you could pay cash, if you did so at most places a RFID scanner in the till would cause an alarm had your bill come from a blacklisted transaction.

Bitcoin doesn't have to go this route if we don't want it too. Provably anonymous trust free mixing is possible among many other solutions: https://bitcointalk.org/index.php?topic=172047.msg1790026#msg1790026 It's actually possible for every single transaction you make to participate in a trust-free mix, and doing so is actually a bit cheaper because making multiple payments in one transaction costs less in transaction fees than doing one payment per transaction.

(emphasis mine)

If you want your Bitcoins to remain fungible, not just not, but also in the future when a crime is detected long after it was committed you are better off ensuring it isn't possible to know where they came from.

I'm reminded a bit of John Dillon's pull request, particularly the replies by Mark Karpeles (MtGox) and Gavin Andresen. Neither sees anonymity as valuable or something the Foundation should push for, particularly Mark, yet if you receive Bitcoins that you know are anonymous and/or know you can spend anonymously you have a very solid guarantee that you will be able to spend them later without having to worry that a theft may be discovered after the fact, retroactively causing them to be blacklisted.

If Bitcoin wants to be the electronic cash of the internet, it has to be possible to break the inherent lack of anonymity the blockchain implies, or a Bitcoin will never be as fungible as a dollar bill.

Be careful with making assumptions that it takes a "super-hacker" to use a bus sniffer; if people start depending on that I fully expect to soon see mod chips become available, just like they did for game consoles, that incorporate a specialized bus sniffer/recorder so some software can easily hack the system with very little actual user understanding.

The thing is, punishing double-spend fraud after the fact is very easy because proving it to others is trivial. You have some identity - which can be a pseudonym - commit to not double-spending fraudulently(1) and if they are found to have done so a short fraud proof can be easily constructed destroying that identity. The identity then just has to be expensive to obtain, like the keypair built into your remote attestation hardware, or one you have purchased a fidelity bond for, or both for that matter. A promised backed by hardware that takes a hundred dollars worth of labour to break is one that can be trusted that much more for your morning coffee.

The advantage of this approach is as a side-effect it nicely provides for a blacklist of compromised TC hardware, and provides infrastructure to detect such compromises in the first place.

Mycellium will be at the conference apparently showing off their bitcoincard product. They claim it has hardware double-spend prevention in it - I'll be very curious to see what they've actually accomplished. Unfortunately it'll also be interesting to see how FinCEN decides to regulate intermediaries like them, and indeed all secure remote attestation capable hardware.


1) Keep in mind a double-spend isn't fraudulent if the merchant still gets the same or more funds. Double-spending to change transaction fees after the fact, or to combine multiple payments in a mix with others, simply changes how they were paid, not that they were paid.

In general you have to understand that what trusted computing provides is a way to trust the execution environment and not much else. It won't magically make your code less buggy; if anything the brittleness of most TC environments can wind up increasing risk by making it harder to apply patches and perform backups.

For instance, Hal implemented a very nice time-based spending limit using the Trusted Platform Module (TPM) support common in consumer computers these days. It works because that TPM, in conjunction with the Flicker software and Intel's Trusted Execution Technology, (TXT) provides a trusted execution environment for the wallet code to operate in. That code then only allows you to spend Bitcoins at a limited rate. It could be a useful thing for, say, the hot wallet of a pool or something.

The thing is you can get the exact same functionality with no special software or hardware by simply keeping a server in a physically secure location - maybe the pool operators closet - running the exact same code. Just firewall that server so everything but the single port used to communicate with the wallet software is blocked and you're good to go. It's not as cool, but it works. That hot wallet operators don't bother with those measures just shows how the incentives aren't really there if it's someone else's money, and all that is at stake is your reputation; you know, it's kinda sad how most of the off-chain transaction stuff I've been thinking about has nothing to do with off-chain transactions and everything to do with making Bitcoin-related services more secure in general...

For some applications knowing that your private keys are secure is useful. Amazon recently started offering a service called CloudHSM where they operate a Luna SA Hardware Security Module at their data center on your behalf. The hardware keeps the private keys safe, so you know even though Amazon has physical access to the HSM they can't get them. Sounds great right? Well, support you stored the private keys to a Bitcoin wallet in a HSM. A hacker who has gained access to your server just has to ask the HSM to sign transactions sending the coins in the wallet to him; the HSM is just a dumb box and has no idea what it is signing. If you are a certificate authority it might be valuable to know you can use the same private keys after an attack as the attacker can't create fraudulent certificates after the fact, but very few Bitcoin-related applications need to be able to use the same addresses after a hack. Unsurprisingly Amazon markets CloudHSM as a tool to meet regulatory requirements rather than a tool to actually make your servers more secure.

Going back to the idea of offering TC/TPM capable servers remotely as a business, if you can't trust the hardware with remote attestation, there really isn't much point. Granted, sometimes you can: apparently all of Akamai's edge servers supporting SSL run hardware that has been securely purchased and built, outfitted with anti-tamper sensors, and then shipped as sealed (not locked!) units to the ISP's they are installed in. They remotely interrogate the server after installation to ensure it has not been tampered with, load the SSL keys into memory, and it's ready to go. If some curious tech at the ISP wanders along and opens the door sensors immediately shutdown the unit, wipe the SSL keys from memory, and log the tamper event. I haven't seen any more public information on exactly how it works, if it actually uses TPM technology or just relies on custom anti-tamper sensors, but it's sounds like it could be a decent system.

The discrete TPM chips like the ones Infineon sells that often get incorporated into motherboards make for some pretty awful overall systems. They communicate with the rest of the system via an unauthenticated 33MHz bus. All you have to do to attack one is use a cheap logic analyzer to record the state the TPM chip is put into as system runs, and then replay that state later to get it into the configuration required to get it to sign/decrypt things using the secret keys inside. The North Bridge integrated versions are a bit better, but again, there are lots of ways to crack them without much cost if you have physical access. In short, the hardware isn't good enough to sell secure remote access, even with a certificate chain vouching for the TPM device, and AFAIK there isn't anything off-the-shelf that you can purchase and ship to the server farm without it being vulnerable to tampering. But it's feasible to build the missing parts yourself as Akamai apparently has.

With regard to DRM, keep in mind that what was planned by Microsoft's Palladium technology would have made for a very effective DRM - the concerns about it were completely justified. But in the end I think the company didn't think pursuing it was really worth it given the outrage and the technical complexity. It's much easier and cheaper to just rely on making copying difficult and using legal means for the remaining holes than it is to actually make a conventional OS TPM capable and make conventional hardware secure. The sealed storage model that has been implemented is extremely brittle with regard to software changes and updates - it's just not very practical for anything complex, hence Intel TXT and Flicker.


I agree it'd be really good to get Mt. Gox and other exchanges to start signing and timestamping their price data. You should raise the issue at the conference - it'd help a whole lot of applications.

Remember that to create an actual ordering of blocks between two different chains, just use timestamps. Take the block header of chain #1 and get it timestamped in chain #2 and vice-versa. Now it's not official because unless you have the most tightly constrained possible timestamp you never know if someone will reveal a more tight constraint later, but for many purposes that unofficial ordering might be enough.