Topic: Output fragmentation (Read 1616 times)

No.
The node (referal client at least) stores t2 as orphan tx in temporary pool. When t1 arrives, node checks orphan pool for "next-to-t1-transactions" and relays t1 + t2 in right order.


Do not forget about malleability. This problem still exists.

@matthis - million addresses in BitcoinJ
That list isn't real. It's been out for months. It was a joke. It uses the page number as a seed to generate those keys and addresses, they then get caught in your cache so it allows you to go back and fourth. Page one had some old wallets to make it look real.

If you don't know what I'm talking about, I apologize, but any time anyone asks the question that you just asked at the end of your post,  everybody knows what your thinking and it can't be done at the present time or in the near future. Don't get me wrong, it's an interesting thought and a fun fact finding mission.

Someone else has already done the math on downloading/indexing a file that size:

A private key is a 256-bit value, meaning there are approximately 1.1579e77 possible keys (There are about 1.2288e66 invalid values, but subtracting them from the full set of values goes beyond the precision we're working with here). 1 trillion = 1e12
1.1579e77 values / 1e12 values per second = 1.1579e65 seconds
60 seconds in a minute, 60 minutes in an hour, 24 hours in a day, approximately 365 days in a year gives us 3.1536e7 seconds per year.
1.1579e65 seconds / 3.1536e7 seconds per year = 3.6717e57 years.
But wait, there's more!
Each of those 1.1579e77 values will occupy 32 bytes of storage space.
1.1579e77 values * 1.1579e77 bytes per value = 3.7053e78 bytes of data.
According to WolframAlpha, there are approximately 1e50 atoms on Earth. Even if you could store 1 byte of data per atom:
3.7053e78 atoms / 1e50 atoms per Earth = 3.7053e28 Earths worth of atoms
Beyond even that: According to Landeauer's principle, at room temperature, the absolute minimum amount of energy required to store one bit of information is 2.85e-21 joules.
The mass of the sun is approximately 1.988435e30 kg. According to general relativity, 1kg of mass will provide you with approximately 1.7867e17 joules of energy (look for a mass-to-energy calculator if you want to double check this).
So we're storing:
3.7053e78 bytes * 8 bits per byte = 2.9643e79 bits of data
Which requires:
2.9643e79 bits * 2.85e-21 joules per bit = 8.44822e58 joules of energy
The sun will provide us with
1.988435e30 kg * 1.7867e17 joules per kilogram = 3.5527e47 joules of energy
Meaning we would need:
8.44822e58 joules / 3.5527e47 joules per sun = 2.3779e11 suns
So, if you could use the entire planet as a hard drive, storing 1 byte per atom, using stars as fuel, and cycling through 1 trillion keys per second, you'd need 37 octillion Earths to store it, and 237 billion suns to power the device capable of doing it, all of which would take you 3.6717 octodecillion years.

Haha, true dat!
Anyway, all this was just me playing around with the system and being curious
I was messing with you just for the sake of the argument I'm not actually going to implement this.

Well actually... doing some output fragmentation (with fresh addresses of course ) could help me solving some issues I had with a cold storage system I developed. But that's another story.

Side question, do you happen to know how well BitcoinJ scale with a growing number of addresses? What happen if I'm using 10,000 addresses? or a million?

I'll take a look at the BitcoinJ documentation, maybe Mike specified that somewhere...

I agree, however it is also important to take into consideration the design of the protocol you are using and its intended use.


There are other ways to reveal identity if necessary.  You don't expect an idividual to be identified solely by a single output, and you shouldn't expect an individual to be identified solely by a single address.  Addresses are not user identifiers.  As a matter of fact, at the protocol level addresses (and bitcoins) don't even exist.  Instead what exists is only a script that encumbers an output with a specific requirement that must be met in order to use the value from the output to fund a transaction.


Then you aren't doing it right.  Addresses are not "user identifiers".  Addresses are a short hand way of saying "in order to use this output in a transaction, you must supply an ECDSA signature from the private key that is associated with the public key that hashes to the following value."


Vanity addresses are generally a bad idea.  They encourage behavior that leads to loss of security, fungibility, and privacy.  If you feel a need to use vanity addresses and a need to store multiple outputs at the same address, then I would challenge you to re-think your design, "think outside the box", and consider other ways to accomplish your end-goal.

Thank you so much for all those answers. I think I'm done with all my questions

One piece of advice about all this though:


It's usually not a good idea to be that absolute when evaluating a design, especially when not knowing much about the constraints of the environment.

• What if I was designing a system where privacy is not only not important, but actually very bad?
• What if I have an imperative need to identify one user with only one address?
• What if creating a new address is actually extremely ressource intensive? Maybe one of my constraint is to only manipulate vanity addresses that are extremely hard to generate?

Keeping an open mind and thinking out of the box is usually a good thing, especially in the Bitcoin world where there is so many things possible to build.
(Don't get me wrong, I know that you were just trying to help )

Anyway, thanks again for helping me and my annoying questions!

Generally, no.


Correct.


Correct.


That would create quite a mess for yourself.


This is a good reason to wait for the first transaction to get at least on confirmation before spending any of its change.


No.


Typically, yes. It's a bad idea.


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.


This is generally a bad idea.  It reduces security, it reduces fungibility, and it reduces privacy.



Use multiple addresses.  If you aren't doing that, then you aren't doing it correctly.


This can be done, just make sure that each fragment goes to its own address.


Then it isn't designed properly.


I think this is possible with raw transactions, but it's generally a bad idea.


bitcoind is designed with the assumption that a new address should be used for every transaction.


Use multiple addresses, and re-think your design.

First, thank you guys for taking the time to answer all my questions. I appreciate.
Now here's more. 


Isn't that a problem? Looks like one should never try to use an UTXO even if coming from his own address...
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. What if there is not 2 transactions, but a dozens? I can't afford having a hundred transactions rejected just because the first one saw its transaction id altered.

Am I missing something or trying to use my own UTXO is a really bad idea?


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.


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.

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?
My solution was to implement some kind of "output fragmentation". But if a system has a "only one bitcoin address" requirement, the destination of the "output fragments" needs to be one address.

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).

Any ideas?

Yes.


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.


It is a common assumption from people who think of addresses as "accounts" instead of thinking of them as a way to identify an output.




I'm not sure what you are suggesting.


You lose privacy and you lose a bit of security.

Hmmmmmm, then I have some more questions!

Let's say you've created 2 transactions t1 and t2.

• t1 is usual transaction with an output for the change.
• t2 is a transaction that spend this change

What happen if a node is seeing t2 before t1, it should reject it right?


Well, I would say that the less bitcoin addresses you have to manage, the better. But it might be a stupid assumption from me.
We could maybe imagine a system where having only one address to manage is a hard requirement?


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"?

I believe that Bitcoin Core allows spending of unconfirmed change providing it's 'your' change (i.e. it originates from a transaction which you created).

Regardless; so you want to split outputs, to ensure that you have some small ones available.
Why must these outputs be assigned to the same address rather than multiple addresses? What do you gain? (You lose a fair amount).

My bad, I should have been more clear and add an example.

Here's a use case:

You have 0.5 BTC available on a specific address. This 0.5 BTC is coming from a unique output from a previous transaction.
This means that if you want to pay 0.005 BTC for a cup of coffee, you will create a transaction with two outputs.

• One output of 0.005
• A second output of 0.4949 for the change

Now your "confirmed balance" is 0, and you "have to" wait until the next block to actually be able to spend the unconfirmed change.

Bloating the chain pointlessly, and additionally defeating part of the reason behind using an address in the first place.

Fun for testnet, but why would you ever want to do such a thing on mainnet?

Hey all

I see that the original bitcoin client is not allowing to MANUALLY create a transaction with multiple outputs to the same bitcoin address.
I was wondering what was the reasoning behind this restriction.

Obviously this is not something we want as the default behavior, but why not allowing it when creating a transaction manually?

Thanks!