Bitcoin Forum
December 04, 2016, 10:16:01 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Transaction that expires if not included in next block  (Read 932 times)
unabridged
Jr. Member
*
Offline Offline

Activity: 31


View Profile
December 07, 2011, 09:58:49 PM
 #1

Is there a way to make a transaction that has to occur in the next block or it becomes invalid? Would you need a new transaction script opcode that gives the previous block hash so you can compare it?

My idea is once this is available clients can keep their own list of trusted addresses and if they see a transaction sent from these addresses in a block they can use it to weight the blockheight count of different forks so they can pick a shorter more trusted branch over a longer untrusted branch, reducing a chance of a 51% attack. If certain transactions can be locked directly behind a specific block it keeps the attacker from including these transactions in their fork and using that transaction's trust.

Then trusted members of the community can make these transactions every few blocks and users can subscribe to them by adding their address to their trust list. You can have the weighting grow large depending how far back the last trusted transaction occurred starting with, for example (n is current block height):

1 block back = normal weight
2 blocks back = 2x weight, so now a new fork would require a chain of height  >n+1 to orphan this block
3 blocks back = 3x weight, fork requires height >n+2 to orphan this block

As long as the weights are not too high it still makes it possible for the client to eventually get back onto the full network in the case of a legitimate fork, but makes it impossible for an attacker to grow a large chain in private. Also by not worry about the weighting until there is a risk of orphaning more than one block, the client only begins using extra resources to check for trusted transactions in rare occasions.

BTC: 1FMzTWoaKyQjFg2tJn7TkVT4aSAQgKbCpj
LTC: LUwWqUt93QJFxHxkfehn73sqfvhbUSQ4qt
NMC: My3QKLe17Xc9D1tVUzkE7vxUqRMsQfAGSR
1480846561
Hero Member
*
Offline Offline

Posts: 1480846561

View Profile Personal Message (Offline)

Ignore
1480846561
Reply with quote  #2

1480846561
Report to moderator
1480846561
Hero Member
*
Offline Offline

Posts: 1480846561

View Profile Personal Message (Offline)

Ignore
1480846561
Reply with quote  #2

1480846561
Report to moderator
1480846561
Hero Member
*
Offline Offline

Posts: 1480846561

View Profile Personal Message (Offline)

Ignore
1480846561
Reply with quote  #2

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

Posts: 1480846561

View Profile Personal Message (Offline)

Ignore
1480846561
Reply with quote  #2

1480846561
Report to moderator
1480846561
Hero Member
*
Offline Offline

Posts: 1480846561

View Profile Personal Message (Offline)

Ignore
1480846561
Reply with quote  #2

1480846561
Report to moderator
ByteCoin
Sr. Member
****
expert
Offline Offline

Activity: 416


View Profile
December 09, 2011, 03:16:28 AM
 #2

No and yes respectively.

A number of mechanisms have been proposed to implement this, notably OP_BLOCKNUMBER however all parties accept that implementing it would break a number of important invariants.

I think it's safe to say that no such functionality will be implemented for the foreseeable future.

To address the thrust of your post - I'm confident that such a trust scheme will never be implemented in Bitcoin as it is more complex and prone to manipulation than the current system. I also believe that no Bitcoin-like scheme which "builds" trust in this fashion will ever succeed for roughly the same reasons.

ByteCoin
makomk
Hero Member
*****
Offline Offline

Activity: 686


View Profile
December 11, 2011, 04:23:04 PM
 #3

No. There's intentionally no way of tying transactions to blocks, because block chain reorganisations or even just blocks arriving sooner than expected would cause payments to simply disappear. Solidcoin 2 has a trusted block scheme based on trusted parties inserting transactions into the block chain and it failed exactly because transactions can't be tied to blocks. Your suggested method also opens up a whole bunch of new 51% attacks.

Quad XC6SLX150 Board: 860 MHash/s or so.
SIGS ABOUT BUTTERFLY LABS ARE PAID ADS
unabridged
Jr. Member
*
Offline Offline

Activity: 31


View Profile
December 11, 2011, 06:56:42 PM
 #4

No. There's intentionally no way of tying transactions to blocks, because block chain reorganisations or even just blocks arriving sooner than expected would cause payments to simply disappear. Solidcoin 2 has a trusted block scheme based on trusted parties inserting transactions into the block chain and it failed exactly because transactions can't be tied to blocks. Your suggested method also opens up a whole bunch of new 51% attacks.

These transactions would not be used for payments for that reason, they would just be a way for an account to sign a specific block chain by sending a small token amount (probably to another account they own). We could even force these transactions to have no output (money sent to miner) or output only to the same address to prevent using them for payment.

This is entirely unrelated to anything that solidcoin2 does, sc2 does not insert transactions into a normal block chain it just allows "trusted" nodes to create extremely low difficulty blocks after a normal block.

It would open up new attacks based on social engineering, but trust could be quickly removed by the user at any time.  The decentralized nature of how each user chooses which addresses to trust would make it difficult to perform. Each user choosing small set of addresses from a few prominent forum posters and exchanges would make it extremely difficult for an outside attacker to 51% the chain. And users who choose no trusted addresses would function exactly the same as the current client. While this may not be an issue with bitcoin because 51% is not a significant threat due to the size of the network, for a smaller chain I think this type of distributed voluntary trust would reduce 51% risk greatly.

BTC: 1FMzTWoaKyQjFg2tJn7TkVT4aSAQgKbCpj
LTC: LUwWqUt93QJFxHxkfehn73sqfvhbUSQ4qt
NMC: My3QKLe17Xc9D1tVUzkE7vxUqRMsQfAGSR
pc
Sr. Member
****
Offline Offline

Activity: 253


View Profile
December 12, 2011, 05:11:30 PM
 #5

If all you're trying to do is have users sign off on which they think is the "most correct" blockchain, I think it'd be easier to just have accounts signing hashes of blocks they think are correct, and distributing those hashes separately, rather than trying to embed them in the blockchain somehow.
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
December 12, 2011, 06:48:04 PM
 #6

If all you're trying to do is have users sign off on which they think is the "most correct" blockchain, I think it'd be easier to just have accounts signing hashes of blocks they think are correct, and distributing those hashes separately, rather than trying to embed them in the blockchain somehow.

+1

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

Activity: 31


View Profile
December 12, 2011, 10:34:18 PM
 #7

If all you're trying to do is have users sign off on which they think is the "most correct" blockchain, I think it'd be easier to just have accounts signing hashes of blocks they think are correct, and distributing those hashes separately, rather than trying to embed them in the blockchain somehow.

I like this idea, would it be possible to distribute these signed hashes through the client protocol, similar to how tx are shared?

BTC: 1FMzTWoaKyQjFg2tJn7TkVT4aSAQgKbCpj
LTC: LUwWqUt93QJFxHxkfehn73sqfvhbUSQ4qt
NMC: My3QKLe17Xc9D1tVUzkE7vxUqRMsQfAGSR
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!