+1
I'm curious to know which criteria are used to define a coinjoin tx (fingerprint, entropy, ...)

Here's the CVE page.
CVE-2011-4447 might be a good candidate but it's just a guess.

The Payment Protocol (BIP70) can be extended with additional fields. This mechanism could be used to send customer information with the payment.

WRT digital goods which don't require personal information (movies, games, ...), we have a draft proposal for an extension of BIP70 with the BitId authentication protocol.

Main benefits: Better privacy & security. No more need to put at risk your personal information on a server (name, email, password, credit card info...) when you want to consume a digital product.

SPOILER. Don't read this post if you don't want to know the answer.











These 4 transactions look like classic payments:
- several inputs controlled by a payer are merged
- an amount is sent to an address controlled by a payee
- change is sent to an address controlled by the payer

Actually, it's possible (likely ?) that these transactions were classic payments, but they might be something else: "steganographic transactions"

Let's see the 3rd transaction:
- The 1st output (19z5fD6LhhiRupqezw7vi3fuumt5jCS9LU - 0.01 BTC) seems deterministically linked* to the 2nd input (1P3RfYxRTkTLdwXAVYzh41sfyMgzppELZA - 0.01 BTC)
- The 2nd output seems deterministically linked* to the others inputs

It means that this transaction might be:
- a classic payment transaction built by a single user
- a manually crafted transaction merging a txo controlled by a user A (the 2nd input) with txos controlled by a user B (the others inputs). No payment is done. The transaction just sends the coins to others addresses controlled by the users.
- ... (more weird scenarii)

This second interpretation has some "fun" properties:
- detection of this pattern is quite hard for human eyes
- it breaks the "merged inputs" heuristic used by some tools in order to clusterize addresses in wallets


A few remarks:
- The 4th transaction is similar to the 3rd transaction (no fee)
- The 1st and 2nd transactions have the same property but they pay a fee and the pattern is even more difficult to detect.
  Example: In the 1st transaction, the 3rd input (14okJQwaHJ3xHBtdU3LxqUEuXcsHhz9gtE - 0.01301568 BTC) seems deterministically linked to the 1st output (1Njw6FuxuVk293LwYREHxvUVUhx5MfzJLf - 0.01251568 BTC)


It remains a "mystery" for the 3rd and 4th transactions:
If they're classic payments, I don't know why the wallet has added an additional input/output. Hypotheses:
- a feature of the wallet, ensuring that there's always a minimum of 2 outputs ?
- a bug in the algorithm selecting the inputs ?
- manually crafted transactions ?


I wouldn't be surprised if someone already discussed this pattern. On my side, I've spotted the transactions this morning, while doing some tests, and found it was a funny coincidence (because, you know...easter eggs).


*: "deterministically linked" means the input and the output are linked whatever the correct interpretation of the transaction. I wrote "seems" because, with some more advanced scenarii, this statement might be proven wrong.

The rationale is that something which isn't connected to the network is less risky (malware, virus, keyloggers...). But note that even an usb device temporarily connected to a cold wallet computer might be considered as a risk.

A paper wallet has a big advantage : you can't connect it to the network  
But paper wallets come with their own challenges: you must store them in a secure place (thieves, water, fire, ...).

I guess this is why so many people are excited by hardware wallets which are a good compromise between security & convenience (but you still have to store the "seed" in a secure place).

It's not about the size.

Another hint: steganography (...but don't lose your time with a message hidden in the transactions)

Another hint: it's not bad for privacy

Your version is better 

More security is always better but you're right on one point: if the financial cost of security is greater than the value you want to secure, there's something wrong.
If you just have a few cents, no need for a cold wallet.
If you have thousands dollars, it's better to secure your btc with a cold wallet or an hardware wallet like Ledger, Trezor, ...

Short answer: No

As you wrote, stealing a wallet requires knowledge of the private key.
Finding the private key when you only know the address is "impossible" (understand "secured by cryptographic algorithms")
Therefore, nobody can steal your btc without access to your private key (let's forget a potential flaw in random number generators).

You're right. No coin is sent to cold storage. This is just a misleading metaphor.
It only means that your private key isn't (and has never been) in contact with internet (stored on a computer connected to internet network)

Hope it helps.

It's not related to change addresses.

Another hint: the title of the post may help 

Just a little game.

Will you find the common denominator of these transactions ?
https://blockchain.info/tx/01b5fc9c33633af82f01eaf2ef94cce21077066a01f05293a64f936ba75bb2a0
https://blockchain.info/tx/2ecc6a57dec613272adbd2bebc3a78259de1ecf964e099a3d5c2765785c606a0

No clue ? Two more examples:
https://blockchain.info/tx/1892c498a9af56157c50ce62ccfb462afe987f3f29d31c36ee3b37f7c688ca3e
https://blockchain.info/tx/b91719b0cf09a119ee052ecf93fb83128168f3f3f309a7d9f60514e7a6cccb7f

Hint: privacy, merged inputs

EDIT 07/03: Answer added into the title of the post

@23g: For a complete overview of the mechanism, I recommend you this chapter of the excellent developer guide.

A scriptPubKey (with pubKeyHash) is associated to the output of a transaction (let's say Tx1).
A scriptSig (with pubkey) is associated to the input of a transaction (let's say Tx2).

Pubkey is revealed when the user wants to spend an utxo previously received (example: Tx2 consumes an output of Tx1).

<pubkeyHash> (appearing in Tx1) is the hash of <pubkey> (appearing in Tx2)

To summarize: All receiver will become a sender (except hardcore hodlers )

Yup. Tor should prevent the issue with ip addresses.
This kind of attack might also have been used to clusterize bitcoin addresses and, if I'm right, it should work even if the node is connected with Tor.
It's less concerning than leaked ip addresses but it's still a leak.

Thanks for the info ! I assume that Cryddit talks about txos already mined (ref. to 1 satoshi txs spamming the blockchain) but better to let him confirm.

I hope so but I'm not sure why fix deployment is stuck at 97%

Actually, it seems the vulnerability has already been identified in 2013:
- vulnerability description
- vulnerability description on the wiki
- related bitcointalk post

@Cryddit: If your theory is correct, we have a huge privacy problem...
Also note that dust spamming is only required to link "zero balance" addresses to ip addresses since the same method could be applied to current utxos.

The legend says that if you repeat five times "Candyman" while facing a mirror, Satoshi will come back. 

I would add this one: Snapshot of network topology. Check if we still have the expected decentralized topology or if we have some hubs which may become future points of fragility (wrt data propagation).

Thanks. It's bookmarked !

Yep !

It is. I've linked this thread because I thought you might be interested by formats used in older blocks (before BIP34). It was just an inference from your previous post about nonces & hash values. My apologies if I was wrong.