public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
* [Bitcoin-development] Self-dependency transaction question...
@ 2014-07-13 23:32 Richard Moore
  2014-07-14  2:25 ` Aaron Voisine
                   ` (2 more replies)
  0 siblings, 3 replies; 6+ messages in thread
From: Richard Moore @ 2014-07-13 23:32 UTC (permalink / raw)
  To: Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 1132 bytes --]

Hey all,

I'm working on the UTXO database for my Python implementation of bitcoind and have found a situation I did not realize was valid, but since it seems to be, had a quick question.

If you look at block #546 the 4th transaction's first input uses its own block's 3rd transaction as an input.
https://blockchain.info/block/000000005a4ded781e667e06ceefafb71410b511fe0d5adc3e5a27ecbec34ae6

My question is, would the other way be valid, that is, could the 3rd transaction of a block, use the 4th transaction from the same block as an input? Or are transactions processed strictly top to bottom?

Thanks,
RicMoo

P.S. If it is valid, another question; what would happen if a transaction was self-referencing? I realize it would be very difficult to find one, but if I could find a transaction X whose input was X and had an output Y, would Y be a new valid utxo, without being a generation transaction input?

.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸><(((º>

Richard Moore ~ Founder
Genetic Mistakes Software inc.
phone: (778) 882-6125
email: ricmoo@geneticmistakes•com
www: http://GeneticMistakes.com


[-- Attachment #2: Type: text/html, Size: 1846 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [Bitcoin-development] Self-dependency transaction question...
  2014-07-13 23:32 [Bitcoin-development] Self-dependency transaction question Richard Moore
@ 2014-07-14  2:25 ` Aaron Voisine
  2014-07-14  2:51   ` Jeff Garzik
  2014-07-14 11:18 ` Mike Hearn
  2014-07-14 20:51 ` Matt Whitlock
  2 siblings, 1 reply; 6+ messages in thread
From: Aaron Voisine @ 2014-07-14  2:25 UTC (permalink / raw)
  To: Richard Moore; +Cc: Bitcoin Dev

I believe tx have to be ordered sequentially within a block. Also
since a tx is referenced by it's hash, it's practically impossible to
make a self referential tx.

Aaron Voisine
breadwallet.com


On Sun, Jul 13, 2014 at 4:32 PM, Richard Moore <me@ricmoo•com> wrote:
> Hey all,
>
> I'm working on the UTXO database for my Python implementation of bitcoind
> and have found a situation I did not realize was valid, but since it seems
> to be, had a quick question.
>
> If you look at block #546 the 4th transaction's first input uses its own
> block's 3rd transaction as an input.
> https://blockchain.info/block/000000005a4ded781e667e06ceefafb71410b511fe0d5adc3e5a27ecbec34ae6
>
> My question is, would the other way be valid, that is, could the 3rd
> transaction of a block, use the 4th transaction from the same block as an
> input? Or are transactions processed strictly top to bottom?
>
> Thanks,
> RicMoo
>
> P.S. If it is valid, another question; what would happen if a transaction
> was self-referencing? I realize it would be very difficult to find one, but
> if I could find a transaction X whose input was X and had an output Y, would
> Y be a new valid utxo, without being a generation transaction input?
>
> .·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸><(((º>
>
> Richard Moore ~ Founder
> Genetic Mistakes Software inc.
> phone: (778) 882-6125
> email: ricmoo@geneticmistakes•com
> www: http://GeneticMistakes.com
>
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck&#174;
> Code Sight&#153; - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [Bitcoin-development] Self-dependency transaction question...
  2014-07-14  2:25 ` Aaron Voisine
@ 2014-07-14  2:51   ` Jeff Garzik
  0 siblings, 0 replies; 6+ messages in thread
From: Jeff Garzik @ 2014-07-14  2:51 UTC (permalink / raw)
  To: Aaron Voisine; +Cc: Bitcoin Dev

On Sun, Jul 13, 2014 at 10:25 PM, Aaron Voisine <voisine@gmail•com> wrote:
> I believe tx have to be ordered sequentially within a block. Also
> since a tx is referenced by it's hash, it's practically impossible to
> make a self referential tx.

Correct.  A TX will not reference a later TX in the same block (or itself).

This would be a good invalid-block test to add to the test suite.  Any
volunteers?

-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.      https://bitpay.com/



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [Bitcoin-development] Self-dependency transaction question...
  2014-07-13 23:32 [Bitcoin-development] Self-dependency transaction question Richard Moore
  2014-07-14  2:25 ` Aaron Voisine
@ 2014-07-14 11:18 ` Mike Hearn
  2014-07-15 13:56   ` Paul Lyon
  2014-07-14 20:51 ` Matt Whitlock
  2 siblings, 1 reply; 6+ messages in thread
From: Mike Hearn @ 2014-07-14 11:18 UTC (permalink / raw)
  To: Richard Moore; +Cc: Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 598 bytes --]

Conceptually all transactions in the block chain lie on a single timeline.
The fact that we quantise that timeline into blocks is in many ways neither
here nor there - it's still a strict line.

What *can* happen and you must be aware of is duplicated transactions.
Satoshi sort of assumed this could never happen because everything is hash
based, but forgot that duplicating coinbases is possible and at one point
this did happen. It was banned by a rule change afterwards but you still
must be able to process the older parts of the chain that have this. There
is a BIP that covers the new rule.

[-- Attachment #2: Type: text/html, Size: 748 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [Bitcoin-development] Self-dependency transaction question...
  2014-07-13 23:32 [Bitcoin-development] Self-dependency transaction question Richard Moore
  2014-07-14  2:25 ` Aaron Voisine
  2014-07-14 11:18 ` Mike Hearn
@ 2014-07-14 20:51 ` Matt Whitlock
  2 siblings, 0 replies; 6+ messages in thread
From: Matt Whitlock @ 2014-07-14 20:51 UTC (permalink / raw)
  To: Richard Moore; +Cc: bitcoin-development

On Sunday, 13 July 2014, at 7:32 pm, Richard Moore wrote:
> P.S. If it is valid, another question; what would happen if a transaction was self-referencing? I realize it would be very difficult to find one, but if I could find a transaction X whose input was X and had an output Y, would Y be a new valid utxo, without being a generation transaction input?

Even if you could find such a transaction that contained its own digest, and even if such a transaction were valid, it still couldn't conjure new coins into existence. The sum of the outputs must be less than or equal to the sum of the inputs (except in the case of a coinbase transaction). If a transaction were to spend its own output, then the input would be completely used up by the output, leaving no balance for a second output.



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [Bitcoin-development] Self-dependency transaction question...
  2014-07-14 11:18 ` Mike Hearn
@ 2014-07-15 13:56   ` Paul Lyon
  0 siblings, 0 replies; 6+ messages in thread
From: Paul Lyon @ 2014-07-15 13:56 UTC (permalink / raw)
  To: Mike Hearn, Richard Moore; +Cc: Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 1815 bytes --]

Thankfully those two duplicated transactions were never spent when they first appeared. Because of that, I chose to not not add them to the UTXO at all when they first appear. When the duplicates appear they get added to the UTXO successfully because the earlier, conflicting versions are not present. That way you can carry on assuming that all transaction hashes are unique, and enforce that rule over the entire blockchain.

Date: Mon, 14 Jul 2014 13:18:22 +0200
From: mike@plan99•net
To: me@ricmoo•com
CC: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Self-dependency transaction question...

Conceptually all transactions in the block chain lie on a single timeline. The fact that we quantise that timeline into blocks is in many ways neither here nor there - it's still a strict line. 

What can happen and you must be aware of is duplicated transactions. Satoshi sort of assumed this could never happen because everything is hash based, but forgot that duplicating coinbases is possible and at one point this did happen. It was banned by a rule change afterwards but you still must be able to process the older parts of the chain that have this. There is a BIP that covers the new rule.



------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck®
Code Sight™ - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists•sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development 		 	   		  

[-- Attachment #2: Type: text/html, Size: 2244 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2014-07-15 14:08 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-07-13 23:32 [Bitcoin-development] Self-dependency transaction question Richard Moore
2014-07-14  2:25 ` Aaron Voisine
2014-07-14  2:51   ` Jeff Garzik
2014-07-14 11:18 ` Mike Hearn
2014-07-15 13:56   ` Paul Lyon
2014-07-14 20:51 ` Matt Whitlock

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox