Bitcoin Forum
December 05, 2016, 12:54:45 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Why was this transaction structured this way?  (Read 2110 times)
BeeCee1
Member
**
Offline Offline

Activity: 116


View Profile
February 23, 2011, 01:29:41 AM
 #1

I was looking on block explorer and I saw this:
http://blockexplorer.com/tx/1dc3384e7ffedf0036b0fd269f3fe46fb08e8c1436bb11f9d083e236cd0f620f

Two inputs, one 5.87BTC and one 10BTC.  Then, two outputs, one for  10BTC and one for 5.87BTC.  Obviously, this transaction could have been a single input and a single output.  Is there any reason why it would be better to have two inputs instead of one, or is it just a bit of brain-deadness on the part of bitcoin?
1480942485
Hero Member
*
Offline Offline

Posts: 1480942485

View Profile Personal Message (Offline)

Ignore
1480942485
Reply with quote  #2

1480942485
Report to moderator
1480942485
Hero Member
*
Offline Offline

Posts: 1480942485

View Profile Personal Message (Offline)

Ignore
1480942485
Reply with quote  #2

1480942485
Report to moderator
1480942485
Hero Member
*
Offline Offline

Posts: 1480942485

View Profile Personal Message (Offline)

Ignore
1480942485
Reply with quote  #2

1480942485
Report to moderator
No Gods or Kings. Only Bitcoin
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
February 23, 2011, 01:35:51 AM
 #2

Looks like somebody's playing with a tweaked bitcoin-- if you trace back the inputs they're from a previous block that has the same odd pattern.

The standard coin selection algorithm in bitcoin would generate a one input / one output transaction.


Hal and theymos are right-- I misremembered how the coin selection algorithm works.

How often do you get the chance to work on a potentially world-changing project?
BeeCee1
Member
**
Offline Offline

Activity: 116


View Profile
February 23, 2011, 02:19:49 AM
 #3

Here's a couple more transactions of the same nature:
http://blockexplorer.com/t/9Z4YgzGqgT   IN: 0.5 and 0.5 OUT: 0.5 and 0.5 (block 109801)
http://blockexplorer.com/t/4B3i2NQWNM  IN: 0.02 and 1.02 OUT: 0.02 and 1.02 (block 109779)
Hal
VIP
Sr. Member
*
expert
Offline Offline

Activity: 314



View Profile
February 23, 2011, 03:56:50 AM
 #4

I don't think it's happening here, but I had something similar happen when I paid myself.

Suppose you have a wallet funded only with one 15.87 btc transaction, and you pay yourself (ie one of your wallet addresses) 10. Then you will have two funded addresses in your wallet, the 10 you paid, and one with 5.87 for change. Now suppose you pay someone else 10. You'd think it would just use the 10 btc address as input. But it won't.

The client will choose both the 10 and 5.87 addresses as input, and have two outputs, 10 btc to the address you are paying, and 5.87 back to you as change. The reason is the client's coin-choosing algorithm is transaction based. If you have transaction where both outputs go to you, as when you pay yourself, then if the client payscwith that transaction, it will always use both addresses.

So this is a way you can get transactions like what you saw, with two inputs and two outputs, and values that match.

Hal Finney
Hal
VIP
Sr. Member
*
expert
Offline Offline

Activity: 314



View Profile
February 23, 2011, 04:03:47 AM
 #5

Actually I was wrong, this is exactly what is happening here. You see that both inputs come from the same transaction. In these cases, the pay-yourself cycle was repeated, and you again end up with two addresses in the same wallet, funded by the same transaction, which must be used together.

Hal Finney
caveden
Legendary
*
Offline Offline

Activity: 1106



View Profile
February 23, 2011, 09:05:16 AM
 #6

Wouldn't it be better for the network if the client tried to minimize transaction sizes? (for the network and for the user, as soon as we have to pay for transactions...)

Actually, talking about it, why does the change mechanism exists? Is it to improve anonymity? It's not very clear to me how does the change improves anonymity, but anyway, if that's the case, I'd suggest to make it optional, and disabled by default. Only those really worried with anonymity would activate it. That would make transactions smaller.

18rZYyWcafwD86xvLrfuxWG5xEMMWUtVkL
Cdecker
Hero Member
*****
Offline Offline

Activity: 487



View Profile WWW
February 23, 2011, 10:56:27 AM
 #7

Well,  there may be several optimization targets. One is what you described to minimize the number of inputs to reduce the transaction size. Another may be to use the smallest possible inputs which increases transaction size but also reduces the number of inputs we have to track (long term optimization). And finally we could try to use the oldest inputs which would allow the network to Stub off old blocks since the only useful information we can get from it is its hash which has been confirmed.

I'm not sure yet which one is best

Want to see what developers are chatting about? http://bitcoinstats.com/irc/bitcoin-dev/logs/
Bitcoin-OTC Rating
theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 2492


View Profile
February 23, 2011, 11:05:11 AM
 #8

The standard coin selection algorithm in bitcoin would generate a one input / one output transaction.

Not true. Bitcoin does this sort of thing all the time. Here's a Bitcoin Faucet transaction that does it:
http://blockexplorer.com/tx/863d906463c3b5c24e76ebc04539f7ae33e3e55efab9affb15eb4379487d9e3c

I've noticed that Faucet transactions are especially prone to this, so it might be more likely with small amounts.

(Edit: Hal's explanation fits. People must be sending Faucet coins to the Faucet.)

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
caveden
Legendary
*
Offline Offline

Activity: 1106



View Profile
February 23, 2011, 12:32:24 PM
 #9

Well,  there may be several optimization targets. One is what you described to minimize the number of inputs to reduce the transaction size. Another may be to use the smallest possible inputs which increases transaction size but also reduces the number of inputs we have to track (long term optimization).

I'm not sure I understood this "long term optimization". By smallest I believe you mean in BTC amount, right? The goal would be to spend smaller addresses quicker in order to have less addresses with money in it, is that it?
Besides shrinking people's wallets, what optimization could this bring? These addresses would remain in the block chain anyway...

And finally we could try to use the oldest inputs which would allow the network to Stub off old blocks since the only useful information we can get from it is its hash which has been confirmed.

Can old transactions be really forgotten like this? I've seen people saying this around here before, but it sounds a bit dangerous to me. (deleting data is always a dangerous decision)
I mean, isn't it a problem at all to have a missing link in the chain? Suppose every miner does it, there would be no proof left that certain bitcoins are really linked to its generation block...

I'm not sure yet which one is best

Well, I think - I might be wrong - that bandwidth is a scarcer resource than disk space. So, to me, it sounds more reasonable trying to focus on reducing the bandwidth necessary to be a miner. So maybe minimizing transaction size is more interesting...
By the way, it will probably be on transaction size that fees will be charged anyway.

18rZYyWcafwD86xvLrfuxWG5xEMMWUtVkL
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
February 23, 2011, 02:34:37 PM
 #10

(Edit: Hal's explanation fits. People must be sending Faucet coins to the Faucet.)

"people" is me-- when I tweak the Faucet's code I erase my IP address from its database and then have it send coins to itself as a sanity test.

And Hal's right, Bitcoin chooses transactions to spend, not specific outputs (which only matters for sends-to-self, where you own both outputs of a transaction).

How often do you get the chance to work on a potentially world-changing project?
casascius
Mike Caldwell
VIP
Legendary
*
Offline Offline

Activity: 1344


The Casascius 1oz 10BTC Silver Round (w/ Gold B)


View Profile WWW
March 12, 2011, 08:32:42 PM
 #11

Well,  there may be several optimization targets. One is what you described to minimize the number of inputs to reduce the transaction size. Another may be to use the smallest possible inputs which increases transaction size but also reduces the number of inputs we have to track (long term optimization).

I'm not sure I understood this "long term optimization". By smallest I believe you mean in BTC amount, right? The goal would be to spend smaller addresses quicker in order to have less addresses with money in it, is that it?
Besides shrinking people's wallets, what optimization could this bring? These addresses would remain in the block chain anyway...

I was thinking about this recently - this doesn't seem like such a bad idea.  It's not so much to shrink people's wallets, it's to shrink the block chain - or more specifically, to shrink the total number of bytes one must store in order to only have a record of unspent transactions.  It might also be a good idea to favor spending coins from transactions that are large (in bytes) so the sooner those transactions can be pruned.

Aggregating small inputs has an anonymity consequence: it publicly links the owner of all those small inputs, providing far more useful information to someone trying to follow coins on the chain.

And finally we could try to use the oldest inputs which would allow the network to Stub off old blocks since the only useful information we can get from it is its hash which has been confirmed.

Can old transactions be really forgotten like this? I've seen people saying this around here before, but it sounds a bit dangerous to me. (deleting data is always a dangerous decision)
I mean, isn't it a problem at all to have a missing link in the chain? Suppose every miner does it, there would be no proof left that certain bitcoins are really linked to its generation block...

I am not sure that old transactions could or should ever be truly forgotten by everybody, but forgotten by most would be fine - it would be a per-user choice.  When transaction pruning is properly implemented, the total size of downloading ALL transactions versus only unspent ones will diverge infinitely.  Users could choose between a minimal block chain, or a multi terabyte version under the pretense of "donating your disk space and bandwidth resources to the network" for the purpose of preserving all history.  A user could select whether they wanted full or pruned blocks and this preference would be sent via the P2P protocol.

I'm not sure yet which one is best

Well, I think - I might be wrong - that bandwidth is a scarcer resource than disk space. So, to me, it sounds more reasonable trying to focus on reducing the bandwidth necessary to be a miner. So maybe minimizing transaction size is more interesting...
By the way, it will probably be on transaction size that fees will be charged anyway.

By properly pruning blocks and taking actions to reduce size of past blocks, both can be reduced.  If blocks aren't pruned, they must continue to be passed around in full.  I would propose that it's a reasonable endeavor to focus on reducing the bandwidth of being a casual user, less so a miner.

Even so, being a miner requires no more bandwidth than being a non-miner.  Either you are running a client that listens for all current transaction activity and maintains a block chain, or you do not.  Mining should be equally possible with a pruned versus non-pruned block chain.

Companies claiming they got hacked and lost your coins sounds like fraud so perfect it could be called fashionable.  I never believe them.  If I ever experience the misfortune of a real intrusion, I declare I have been honest about the way I have managed the keys in Casascius Coins.  I maintain no ability to recover or reproduce the keys, not even under limitless duress or total intrusion.  Remember that trusting strangers with your coins without any recourse is, as a matter of principle, not a best practice.  Don't keep coins online. Use paper wallets instead.
Pieter Wuille
Legendary
*
qt
Offline Offline

Activity: 1036


View Profile WWW
March 14, 2011, 12:28:08 PM
 #12

And Hal's right, Bitcoin chooses transactions to spend, not specific outputs (which only matters for sends-to-self, where you own both outputs of a transaction).

This pull request should fix this issue: https://github.com/bitcoin/bitcoin/pull/116

aka sipa, core dev team

Tips and donations: 1KwDYMJMS4xq3ZEWYfdBRwYG2fHwhZsipa
theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 2492


View Profile
March 17, 2011, 06:11:26 AM
 #13

The new "sendmulti" RPC command might cause this problem a lot, since services will not-too-rarely be paying twice (or more) to the same person at different addresses.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
JollyGreen
Jr. Member
*
Offline Offline

Activity: 42


View Profile
March 17, 2011, 06:22:04 AM
 #14

And Hal's right, Bitcoin chooses transactions to spend, not specific outputs (which only matters for sends-to-self, where you own both outputs of a transaction).

This pull request should fix this issue: https://github.com/bitcoin/bitcoin/pull/116


This sounds like a good patch to implement, is there a next step to getting it commited into the root of bitcoin?  Is this pending code review?

Want to donate?
1H6WepEWuJkicvfki8PSrEaT8SUnUHAJKs
JollyGreen
Jr. Member
*
Offline Offline

Activity: 42


View Profile
March 17, 2011, 08:20:05 AM
 #15

I built and ran sipa's code and was just testing it out with the testbox [mike] created,

here is the result of listtransactions after making a few sends thru the gui
{
    "" : 3725.00000000,
    "Test" : 10.00000000,
    "Test2" : 5.00000000,
    "Your Address" : 10.00000000
}

Next I transferred 3726.0 to "Your Address"
{
    "" : -1.00000000,
    "Test" : 10.00000000,
    "Test2" : 5.00000000,
    "Your Address" : 3736.00000000
}

Should a balance be able to be negative?

Want to donate?
1H6WepEWuJkicvfki8PSrEaT8SUnUHAJKs
theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 2492


View Profile
March 17, 2011, 12:41:26 PM
 #16

Should a balance be able to be negative?

That's normal. The blank account's balance goes negative when you send more BTC than is unallocated to accounts.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!