Bitcoin Forum
December 03, 2016, 07:50:21 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 [2]  All
  Print  
Author Topic: Refereed Transactions  (Read 4631 times)
gim
Member
**
Offline Offline

Activity: 90


View Profile
May 01, 2011, 09:56:17 PM
 #21

The block in which the script is meant to be included into can't be known by people verifying the transaction.

You mean miners? They know the number of the block they (try to) generate or the number of the block they verify, as far as I know?
1480794621
Hero Member
*
Offline Offline

Posts: 1480794621

View Profile Personal Message (Offline)

Ignore
1480794621
Reply with quote  #2

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

Activity: 416


View Profile
May 01, 2011, 11:16:53 PM
 #22

Clients currently need to verify all transactions before they are relayed.

Because clients don't know what block a OP_BLOCKNUMBER transaction will get into, they can't easily verify the transaction.

Workaround: Verify the transaction with the current blocknumber. When a new block arrives, kick the verified transaction back into the just received queue. Forbid OP_BLOCKNUMBER transactions from being spent with zero confirmations. To speed up reverification, the results of checking signatures could be cached.

Obviously miners know what the block number is when they try to incorporate the transaction into a block.

Any script opcodes that import state from outside can be used to fork the block chain.

It's not obvious to me that this is true. I presume that the forking mechanism relies on the clients disagreeing among themselves about the state and the transaction being structured so that this disagreement changes who gets the coins. If everyone is forever in agreement about what the outside state was when the transaction was included in the block chain then I don't see the problem. Please explain if a problem remains.

Also scripting isn't really disabled. You just have to get your new script into the whitelist and then convince some miners to upgrade. All clients will understand that new script type afterwards.

The point of scripting is to allow primitive operations to be combined in various ways to produce a predictable overall behaviour which possibly has never been seen before. Alternatively, transaction types could be hard coded to conform to specific behaviour which is well known and understood. The current behaviour is much more like the latter than the former so I think it's true to say that scripting is disabled.

ByteCoin
Mike Hearn
Legendary
*
expert
Offline Offline

Activity: 1526


View Profile
May 02, 2011, 09:25:13 AM
 #23

Quote
I presume that the forking mechanism relies on the clients disagreeing among themselves about the state and the transaction being structured so that this disagreement changes who gets the coins. If everyone is forever in agreement about what the outside state was when the transaction was included in the block chain then I don't see the problem. Please explain if a problem remains.

It's safe if the scripts can't import anything which changes (like the time or the current block number). For instance nothing stops somebody from signing the current block index, and then having that index and the signature put into a script as constants.

If a script can access outside state then look at Theymos' example. You can make a script that is valid, included into the chain and then suddenly becomes invalid. Everyone would begin building a new chain starting at that point - but as the attacker you knew that would happen, so you already made a longer chain yourself. You can now reverse transactions at will, defeating the point of BitCoins security.

theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 2492


View Profile
May 02, 2011, 03:09:39 PM
 #24

It's safe if the scripts can't import anything which changes (like the time or the current block number). For instance nothing stops somebody from signing the current block index, and then having that index and the signature put into a script as constants.

If OP_BLOCKNUMBER expanded into "the block this transaction is in" rather than "the current block" (when the transaction is in a block), and these transactions had a maturation time, wouldn't that be OK? The block number of the transaction can't be changed without a reorg, and we assume reorgs won't be longer than ~100 blocks.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
ByteCoin
Sr. Member
****
expert
Offline Offline

Activity: 416


View Profile
May 03, 2011, 01:22:46 AM
 #25

If a script can access outside state then look at Theymos' example. You can make a script that is valid, included into the chain and then suddenly becomes invalid.

As Theymos indicates above, OP_BLOCKNUMBER pushes on the stack the block number which the transaction occupies (or is likely to occupy) in the block chain.

Miners know what the block number is going to be when they are trying to mine blocks and hence they check that the OP_BLOCKNUMBER transaction is valid for that block.

Given a block chain containing OP_BLOCKNUMBER transactions, if the OP_BLOCKNUMBER transaction was ever valid then it will remain valid as (apart from reorgs) transactions don't change block numbers.

Please post whether you think a problem remains with OP_BLOCKNUMBER now that this point has been clarified.

ByteCoin
Mike Hearn
Legendary
*
expert
Offline Offline

Activity: 1526


View Profile
May 03, 2011, 09:45:37 AM
 #26

I don't know. It sounds OK if there is also a maturation time. I'll ask Satoshi next time I send him a bunch of questions.
Pages: « 1 [2]  All
  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!