Bitcoin Forum
December 07, 2016, 02:52:40 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: Need help understanding a transaction case  (Read 1160 times)
JollyGreen
Jr. Member
*
Offline Offline

Activity: 42


View Profile
March 17, 2011, 05:05:19 AM
 #1

So, I'm working on adding code to bitcoin that allows users to send from specific addresses.  I have it flushed out but running into some issues.  It has takin me a while to properly form the question for the problem I'm running into which relates to understanding how bitcoin handles the below situation:

In the un-modified bitcoin, I'm not sure how the below is handled

*** transaction 1 ***
Say you have 50 BTC in your account from 1 generation
you use "sendfrom" to send 1 BTC to another account you own
this creates a transaction with 1 input and two outputs
50 btc as the input, call this address A
49 btc as change (from a somewhat random address or group of addresses you own to a hidden address) call this address U
1 btc to the address you specified, call this address B

When transaction 1 is commited, I believe the input transaction is marked as spent, in this case, it's fine because 50btc was the only output of a previous transaction that is connected to the input of my "Transaction 1"

*** transaction 2 ***
So now I want to spend say 0.5 BTC.
The software only has two addresses it can possibly select 0.5BTC from, "U" and "B".
So it selects one of these outputs from Transaction 1 as the input for Transaction 2
creates a change output for transaction 2 called U2
sends 0.5BTC to my desired address C

This is where I think I'm missing something, because it seems to me that when transaction 2 is commited, it would mark transaction 1 as spent, but transaction 1 still has an unused output that is ours and is not spent.  I've looked thru the code I don't know how many times and I can't figure out how this case is handled.  Can someone point out my flaw? Smiley


Want to donate?
1H6WepEWuJkicvfki8PSrEaT8SUnUHAJKs
1481122360
Hero Member
*
Offline Offline

Posts: 1481122360

View Profile Personal Message (Offline)

Ignore
1481122360
Reply with quote  #2

1481122360
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481122360
Hero Member
*
Offline Offline

Posts: 1481122360

View Profile Personal Message (Offline)

Ignore
1481122360
Reply with quote  #2

1481122360
Report to moderator
1481122360
Hero Member
*
Offline Offline

Posts: 1481122360

View Profile Personal Message (Offline)

Ignore
1481122360
Reply with quote  #2

1481122360
Report to moderator
1481122360
Hero Member
*
Offline Offline

Posts: 1481122360

View Profile Personal Message (Offline)

Ignore
1481122360
Reply with quote  #2

1481122360
Report to moderator
theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 2492


View Profile
March 17, 2011, 05:22:13 AM
 #2

Right. See:
http://bitcointalk.org/index.php?topic=3759.0

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
Hal
VIP
Sr. Member
*
expert
Offline Offline

Activity: 314



View Profile
March 17, 2011, 05:25:20 AM
 #3

It's an artifact of the coin choice algorithm, not an inherent property of transactions. Sipa offered a patch in that thread, but I don't know what it does.

Hal Finney
theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 2492


View Profile
March 17, 2011, 05:31:32 AM
 #4

The wallet database marks entire transactions as spent? That would explain why SelectCoins chooses coins like that...

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
caveden
Legendary
*
Offline Offline

Activity: 1106



View Profile
March 17, 2011, 08:39:25 AM
 #5

The wallet database marks entire transactions as spent? That would explain why SelectCoins chooses coins like that...

Yeah, it seems wallet database does mark entire transactions as spent, should we consider updating the database code to mark outputs as spent rather than transactions?

Even that sounds too much... I mean, why can't you spend part of an output today an another part of it tomorrow?
This would be a way of stop using this change thing (which I never really understood the reason to exist), and minimizing transaction sizes...

18rZYyWcafwD86xvLrfuxWG5xEMMWUtVkL
Pieter Wuille
Legendary
*
qt
Offline Offline

Activity: 1036


View Profile WWW
March 17, 2011, 09:45:32 AM
 #6

The wallet database marks entire transactions as spent? That would explain why SelectCoins chooses coins like that...

Yeah, it seems wallet database does mark entire transactions as spent, should we consider updating the database code to mark outputs as spent rather than transactions?

That is exactly what my patch does (I needed spent-per-txout for another purpose, but as it enabled better selection of imputs for transactions, it's implemented too): https://github.com/bitcoin/bitcoin/pull/116

aka sipa, core dev team

Tips and donations: 1KwDYMJMS4xq3ZEWYfdBRwYG2fHwhZsipa
Hal
VIP
Sr. Member
*
expert
Offline Offline

Activity: 314



View Profile
March 17, 2011, 09:00:14 PM
 #7

Quote
Even that sounds too much... I mean, why can't you spend part of an output today an another part of it tomorrow?
The unit of spending in Bitcoin is the output of a transaction. That's the closest thing in the system to a "coin".

Hal Finney
Jim Hyslop
Member
**
Offline Offline

Activity: 98


View Profile
March 18, 2011, 05:32:52 AM
 #8

A transaction is the collection of all input bitcoins and all output bitcoins. So a transaction never gets spent - only the bitcoin outputs get spent, when they are used as an input to a new transaction.

Re-using your first example: if you have a bitcoin worth 50BTC and want to give me 1 BTC, the transaction consists of a total of three bitcoins: one 50BTC in, one 1BTC out and one 49BTC out. At that point, the 50BTC coin has been spent. I can then spend my 1BTC, but your 49BTC is unaffected.

Now, refresh my memory - why do you care exactly which bitcoin gets spent? I mean, if I have a bunch of dollar bills in my physical wallet, I don't select one based on its serial number, I just pick one and use it. ISTR there is a discussion on this topic, so feel free to just point me to the discussion.

Like my answer? Did I help? Tips gratefully accepted here: 1H6wM8Xj8GNrhqWBrnDugd8Vf3nAfZgMnq
Jim Hyslop
Member
**
Offline Offline

Activity: 98


View Profile
March 18, 2011, 05:43:56 AM
 #9

Even that sounds too much... I mean, why can't you spend part of an output today an another part of it tomorrow?
This would be a way of stop using this change thing (which I never really understood the reason to exist), and minimizing transaction sizes...
OK, and how would that system work? You have a token (a bundle of bytes, maybe a Bitcoin, maybe some other system) that is worth 50 units. You want to give me one unit and keep 49 units. How do you make that work? I can't, offhand, think of any system that would even approach the simplicity and resistance to attacks that Bitcoin does.

Like my answer? Did I help? Tips gratefully accepted here: 1H6wM8Xj8GNrhqWBrnDugd8Vf3nAfZgMnq
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
March 18, 2011, 01:55:09 PM
 #10

Now, refresh my memory - why do you care exactly which bitcoin gets spent? I mean, if I have a bunch of dollar bills in my physical wallet, I don't select one based on its serial number, I just pick one and use it.

You might care if you got the dollar bill from somebody you suspect is working for the Secret Police, you think think the Secret Police might be trying to trace payments by recording bill serial numbers, and you're spending the dollar to pay a local print shop to produce some illegal Subversive Propaganda.

That's roughly similar to tracing bitcoin transactions.

How often do you get the chance to work on a potentially world-changing project?
Hal
VIP
Sr. Member
*
expert
Offline Offline

Activity: 314



View Profile
March 18, 2011, 09:29:07 PM
 #11

One case to consider is when you have addresses A and B in your wallet but don't want them linked. Jollygreen's code will allow making sure you never spend from A and B together, I think, so that's good.

But suppose someone uses the multipay patch to send to both A and B together, because they suspect that the addresses are linked. There are a few ways this could go wrong. Suppose he told you he was sending 10 to A, but also includes 1 to B in the transaction. I'm not sure what the client would do, but it might show you receiving 11. Then you'd be like, dude, you sent me 11 not 10. And he'd be like, you're busted.

Another way it could go wrong is that you could spend them together, and again, you're busted. I think Jollygreen is protecting against this.

Yet another failure mode would make it impossible to spend the funds, because it would break the rules. So sipa's patch needs to be part of this, allowing the outputs to be split.

Hal Finney
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!