unabridged (OP)
Newbie
 Offline
Activity: 31
Merit: 0
|
 |
December 07, 2011, 06:09:18 AM |
|
Currently is there a way to force a transaction to occur only after a specific block, so if it is not included in the very next block it becomes invalid? Or will this require a new opcode in the transaction script that gives the hash of the previous block?
|
|
|
|
|
|
|
|
|
|
|
|
The trust scores you see are subjective; they will change depending on who you have in your trust list. |
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
|
|
|
|
unabridged (OP)
Newbie
Offline
Activity: 31
Merit: 0
|
|
December 07, 2011, 06:24:49 AM |
|
My idea is once this is available clients can keep a list of trusted addresses (including all that are in their wallet) and if they see a transactions from these addresses in a block they can use it to weight the blockheight count of different forks so they will pick a shorter more trusted branch over a longer untrusted branch, reducing a chance of a 51% attack. If transactions can be locked directly behind a specific block it keeps the attacker from including the transactions in their fork and using their trust.
|
|
|
|
|
deepceleron
Legendary
Offline
Activity: 1512
Merit: 1025
|
|
December 08, 2011, 01:35:27 PM |
|
1. You do not have a guarantee that your transaction will be included in the next block mined, it might take several generated blocks for someone to include your transaction,
2. Your transaction will be retained as a pending transaction by mining nodes until it is included in the blockchain. It won't be discarded just because it was included in a block that was orphaned.
I think your questions allude to a perceived issue that is not present.
|
|
|
|
|
MoonShadow
Legendary
Offline
Activity: 1708
Merit: 1007
|
|
December 08, 2011, 01:48:49 PM |
|
What you intend to do is possible with the scripting mechanism, but that is not presently implimented. Creating a client that does not favor the fork branch with the longest proof of work is very dangerous, and is more likely to introduce another attack vector than solve any perceived problem with the basic proof of work problem. There exist more security checks in the protocol (some in the present client, others only proposed) than just the proof-of-work itself, so it's unlikely that your concerns are not already addressed. However, I don't really understand your concern.
|
"The powers of financial capitalism had another far-reaching aim, nothing less than to create a world system of financial control in private hands able to dominate the political system of each country and the economy of the world as a whole. This system was to be controlled in a feudalist fashion by the central banks of the world acting in concert, by secret agreements arrived at in frequent meetings and conferences. The apex of the systems was to be the Bank for International Settlements in Basel, Switzerland, a private bank owned and controlled by the world's central banks which were themselves private corporations. Each central bank...sought to dominate its government by its ability to control Treasury loans, to manipulate foreign exchanges, to influence the level of economic activity in the country, and to influence cooperative politicians by subsequent economic rewards in the business world."
- Carroll Quigley, CFR member, mentor to Bill Clinton, from 'Tragedy And Hope'
|
|
|
unabridged (OP)
Newbie
Offline
Activity: 31
Merit: 0
|
|
December 08, 2011, 05:44:37 PM |
|
1. You do not have a guarantee that your transaction will be included in the next block mined, it might take several generated blocks for someone to include your transaction,
2. Your transaction will be retained as a pending transaction by mining nodes until it is included in the blockchain. It won't be discarded just because it was included in a block that was orphaned.
I think your questions allude to a perceived issue that is not present.
I understand that currently transactions will still be propagated if the block is orphaned and get added back into the new chain, but I want a way to make a special transaction that expires if it does not get included in the next block. This is not a bug report, this is a feature request. |
|
|
|
|
unabridged (OP)
Newbie
Offline
Activity: 31
Merit: 0
|
|
December 08, 2011, 05:54:44 PM |
|
What you intend to do is possible with the scripting mechanism, but that is not presently implimented. could you explain? |
|
|
|
|
MoonShadow
Legendary
Offline
Activity: 1708
Merit: 1007
|
|
December 08, 2011, 06:52:45 PM |
|
What you intend to do is possible with the scripting mechanism, but that is not presently implimented. could you explain? The whitepaper describes a rudimentary scripting system, wherein transactions are requesting that the miners run a simple script. This scripting mechanism allows many other forms of complex transactions to occur, such as coins that can be claimed by more than one party, or that require signatures from more than one party, in order to be valid. Conditional transactions that can be delayed until such-n-such block number, and can be revoked or replaced prior to that block number; or even coins that can be claimed by any address that can produce the right keycode. Such transactions just languish in the transaction queue until they can be satisfied as valid by their own internal script. Currently, this scripting mechanism isn't implimented in the current client, and it doesn't look like it will be for some time. |
"The powers of financial capitalism had another far-reaching aim, nothing less than to create a world system of financial control in private hands able to dominate the political system of each country and the economy of the world as a whole. This system was to be controlled in a feudalist fashion by the central banks of the world acting in concert, by secret agreements arrived at in frequent meetings and conferences. The apex of the systems was to be the Bank for International Settlements in Basel, Switzerland, a private bank owned and controlled by the world's central banks which were themselves private corporations. Each central bank...sought to dominate its government by its ability to control Treasury loans, to manipulate foreign exchanges, to influence the level of economic activity in the country, and to influence cooperative politicians by subsequent economic rewards in the business world."
- Carroll Quigley, CFR member, mentor to Bill Clinton, from 'Tragedy And Hope'
|
|
|
unabridged (OP)
Newbie
Offline
Activity: 31
Merit: 0
|
|
December 08, 2011, 08:14:22 PM |
|
What you intend to do is possible with the scripting mechanism, but that is not presently implimented. could you explain? The whitepaper describes a rudimentary scripting system, wherein transactions are requesting that the miners run a simple script. This scripting mechanism allows many other forms of complex transactions to occur, such as coins that can be claimed by more than one party, or that require signatures from more than one party, in order to be valid. Conditional transactions that can be delayed until such-n-such block number, and can be revoked or replaced prior to that block number; or even coins that can be claimed by any address that can produce the right keycode. Such transactions just languish in the transaction queue until they can be satisfied as valid by their own internal script. Currently, this scripting mechanism isn't implimented in the current client, and it doesn't look like it will be for some time. within the scripting mechanism, how do you retrieve current block number or hash of previous block? from what I have read there are no constants like OP_PREVHASH or OP_BLOCKNUM. Transactions being delayed from being locked until block n is handled by lock_time which is not part of the scripting. I'm just going by the commands listed on https://en.bitcoin.it/wiki/Script, and as far as I understand even if all of these commands were implemented in the client transactions scripts still cannot in any way reference the current block number or the previous block hash which would be required to create a transaction that expires in not included in the block. |
|
|
|
|
MoonShadow
Legendary
Offline
Activity: 1708
Merit: 1007
|
|
December 08, 2011, 09:51:04 PM |
|
What you intend to do is possible with the scripting mechanism, but that is not presently implimented. could you explain? The whitepaper describes a rudimentary scripting system, wherein transactions are requesting that the miners run a simple script. This scripting mechanism allows many other forms of complex transactions to occur, such as coins that can be claimed by more than one party, or that require signatures from more than one party, in order to be valid. Conditional transactions that can be delayed until such-n-such block number, and can be revoked or replaced prior to that block number; or even coins that can be claimed by any address that can produce the right keycode. Such transactions just languish in the transaction queue until they can be satisfied as valid by their own internal script. Currently, this scripting mechanism isn't implimented in the current client, and it doesn't look like it will be for some time. within the scripting mechanism, how do you retrieve current block number or hash of previous block? from what I have read there are no constants like OP_PREVHASH or OP_BLOCKNUM. Transactions being delayed from being locked until block n is handled by lock_time which is not part of the scripting. I'm just going by the commands listed on https://en.bitcoin.it/wiki/Script, and as far as I understand even if all of these commands were implemented in the client transactions scripts still cannot in any way reference the current block number or the previous block hash which would be required to create a transaction that expires in not included in the block. You now know more about it than I do. |
"The powers of financial capitalism had another far-reaching aim, nothing less than to create a world system of financial control in private hands able to dominate the political system of each country and the economy of the world as a whole. This system was to be controlled in a feudalist fashion by the central banks of the world acting in concert, by secret agreements arrived at in frequent meetings and conferences. The apex of the systems was to be the Bank for International Settlements in Basel, Switzerland, a private bank owned and controlled by the world's central banks which were themselves private corporations. Each central bank...sought to dominate its government by its ability to control Treasury loans, to manipulate foreign exchanges, to influence the level of economic activity in the country, and to influence cooperative politicians by subsequent economic rewards in the business world."
- Carroll Quigley, CFR member, mentor to Bill Clinton, from 'Tragedy And Hope'
|
|
|
theymos
Administrator
Legendary
Offline
Activity: 5166
Merit: 12864
|
|
December 09, 2011, 04:31:22 AM |
|
That will probably never be implemented because it's too dangerous. Search for OP_BLOCKNUMBER.
|
1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
|
|
|
|
