What happen if a node is seeing t2 before t1, it should reject it right?
Yes.
Isn't that a problem?
Generally, no.
Looks like one should never try to use an UTXO even if coming from his own address...
Correct.
Now that I think about it, there is actually other issues coming with that. What happen it the transaction id is altered before being integrated it in a block. That would basically make the second transaction invalid.
Correct.
What if there is not 2 transactions, but a dozens?
That would create quite a mess for yourself.
I can't afford having a hundred transactions rejected just because the first one saw its transaction id altered.
This is a good reason to wait for the first transaction to get at least on confirmation before spending any of its change.
Am I missing something
No.
trying to use my own UTXO is a really bad idea?
Typically, yes. It's a bad idea.
Why must these outputs be assigned to the same address rather than multiple addresses? What do you gain?
Well, I would say that the less bitcoin addresses you have to manage, the better.
That's why you use wallet software. The wallet keeps track of the addresses for you, so you don't have to. As Satoshi recommended in the original whitepaper, a new bitcoin address should be used for EVERY transaction. When used properly, to maximize security and privacy, you should never receive more than one output at any address.
(You lose a fair amount).
Oh! Interesting... Would you mind providing more information on this part?
I'm not quite sure how using the same address will make me lose more money compared to using different addresses.
Or were you talking about money when saying "You lose a fair amount"?
You lose privacy and you lose a bit of security.
You mention twice the fact that using a different change address every time will result in a security improvement.
Could you provide more detail about this? Even though the privacy improvement is obvious to me, I don't see how doing it would improve security.
The loss of security is VERY SMALL, and right now it really doesn't matter much for any real world purposes, however it is still TECHNICALLY a small loss of security.
When a a transaction creates an output assigning value to a brand new bitcoin address that has never before been seen, there are three layers of cryptography between the private key and the bitcoin address. The first layer is ECDSA used to generate a pubilc key from the private key. The second layer is SHA-256 used to generate a hash of the public key. The third layer is RIPEMD-160 used to generate a hash of the SHA256 hash. All three of these layers are one-way functions. Given nothing but a bitcoin address it is impossible to determine what the SHA256 hash was. Given the SHA-256 hash, it is impossible to determine what the public key was. Given the public key, it is impossible to tell what the private key was.
This means that if in the near future there were to be a weakness discovered in any 2 of those algorithms, your bitcoins would still be secure. The protocol could be updated to use a new signature algorithm or new hashing algorithms, and you could send your bitcoins from the less secure address to the new secure address.
Once an output that was received at an address is spent for the first time, the public key becomes permanently stored in the blockchain. From the public key, ANYBODY can calculate the SHA-256 hash. This means the moment a transaction is broadcast that spends an output that was received at an address, the address immediately loses to protection of both SHA-256 and RIPEMD-160. The only layer of protection that remains is ECDSA. If a weakness is discovered in the near future in the ECDSA algorithm and you aren't aware of it, it could be possible for an attacker to use that weakness to steal your bitcoins.
We could maybe imagine a system where having only one address to manage is a hard requirement?
I'm not sure what you are suggesting.
My bad I wasn't clear... I sometimes forget that people can't read my mind
My point was that a random user using the bitcoin client to manage his bitcoins is not the only way to use it (the client). We could imagine some systems built on top of the bitcoin client that have other requirements/restrictions than a classic user would have. One of this requirement could be the need of using only one bitcoin address.
This is generally a bad idea. It reduces security, it reduces fungibility, and it reduces privacy.
So my question is, given a system that can only use one bitcoin address but have a constant flow of transactions to create/send, how to manage the fact that I can't safely use the change of one of my transaction until it's part of a block?
Use multiple addresses. If you aren't doing that, then you aren't doing it correctly.
My solution was to implement some kind of "output fragmentation".
This can be done, just make sure that each fragment goes to its own address.
But if a system has a "only one bitcoin address" requirement,
Then it isn't designed properly.
the destination of the "output fragments" needs to be one address.
I think this is possible with raw transactions, but it's generally a bad idea.
So I tried to create a transaction with several outputs sharing the same destination address and got rejected by bitcoind.
I was wondering why bitcoind was behaving like this given that having a transaction with 5 outputs to the same address or 5 outputs to different addresses is basically the same thing (from a transaction size/complexity standpoint).
bitcoind is designed with the assumption that a new address should be used for every transaction.
Any ideas?
Use multiple addresses, and re-think your design.
