BitShares Forum
Main => Technical Support => Topic started by: zhangweis on January 22, 2018, 07:42:51 am
-
I'm working on a multi-sig related function and found it too limited for transaction expiration.
I checked the code and found GRAPHENE_DEFAULT_MAX_TIME_UNTIL_EXPIRATION is set to 1 day. This is way too short for me as the two parties in multi-sig need more than 1 day to cooperate on transaction signature.
How can I bypass this limitation?
-
Use a proposal instead.
-
Use a proposal instead.
Thanks. I've had a look at proposal and seems it's more complex and costs more if I understand correctly. Please correct me if I'm wrong.
Say I have a "multisig" account which is controlled in 2/3 way with active and owners PkA,PkB and PkC. What I want is simply transfer fund from "multisig" account to "someone".
To my understanding,
1. I need a transaction which contains proposal_create_operation. I don't even know who will pay the fee as I have only the multisig account.
2. I need PkA to sign a transaction containing proposal_update_operation to add his/her approval, again I don't know which account to pay the fee.
3. I need PkB to sign a transaction containing proposal_update_operation to add his/her approval, again where can PkB pay the fee.
4. The proposal executes.
As I understand, this will be more complex and fee is about <0.0277 BTS for proposal create + 2*0.00092 BTS for proposal update> where as simple transfer costs about 0.0033 BTS. The proposal way will cost about 10x of simple transfer.
-
Why not just make GRAPHENE_DEFAULT_MAX_TIME_UNTIL_EXPIRATION long enough like the same 4 weeks as proposal max time until expiration?
-
Thanks. I've had a look at proposal and seems it's more complex and costs more if I understand correctly. Please correct me if I'm wrong.
Say I have a "multisig" account which is controlled in 2/3 way with active and owners PkA,PkB and PkC. What I want is simply transfer fund from "multisig" account to "someone".
To my understanding,
1. I need a transaction which contains proposal_create_operation. I don't even know who will pay the fee as I have only the multisig account.
2. I need PkA to sign a transaction containing proposal_update_operation to add his/her approval, again I don't know which account to pay the fee.
3. I need PkB to sign a transaction containing proposal_update_operation to add his/her approval, again where can PkB pay the fee.
4. The proposal executes.
As I understand, this will be more complex and fee is about <0.0277 BTS for proposal create + 2*0.00092 BTS for proposal update> where as simple transfer costs about 0.0033 BTS. The proposal way will cost about 10x of simple transfer.
Yes, it is more complex, because what you're trying to do is more complex. You want to coordinate multiple independent signers. That's what proposals are made for.
Fees are paid by the party who creates the respective transaction. I. e. whoever creates the proposal has to pay the creation fee, whoever updates it has to pay the update fee.
Why not just make GRAPHENE_DEFAULT_MAX_TIME_UNTIL_EXPIRATION long enough like the same 4 weeks as proposal max time until expiration?
Nodes must remember all unexpired transactions to prevent replay attacks. Increasing the allowed expiration time means higher resource usage on all nodes.
-
Thanks for the explanation. I think I can bypass this limit by having the first signer sign several transactions with different expiration and the 2nd signer choose which transaction to use based on expiration to add signature on. This way it's a bit easier and cheaper.
-
Nodes must remember all unexpired transactions to prevent replay attacks. Increasing the allowed expiration time means higher resource usage on all nodes.
There is another reason too: The TaPOS parameters make use of a truncated block number which is so short that it only covers about 2.4 days of blocks.
-
Nodes must remember all unexpired transactions to prevent replay attacks. Increasing the allowed expiration time means higher resource usage on all nodes.
There is another reason too: The TaPOS parameters make use of a truncated block number which is so short that it only covers about 2.4 days of blocks.
What if tx.ref_block_prefix does not match ref_block_num? Will the tx be rejected or it's just a ref. as name implies?
-
Nodes must remember all unexpired transactions to prevent replay attacks. Increasing the allowed expiration time means higher resource usage on all nodes.
There is another reason too: The TaPOS parameters make use of a truncated block number which is so short that it only covers about 2.4 days of blocks.
What if tx.ref_block_prefix does not match ref_block_num? Will the tx be rejected or it's just a ref. as name implies?
ref_block_num identifies a block from the last 2.4 days .. from that block a truncated version of the block id is used as block_prefix.
That way, every transaction has to 'link' an existing block on the blockchain. That is TaPOS (Transactions as proof of stake) ...
-
Nodes must remember all unexpired transactions to prevent replay attacks. Increasing the allowed expiration time means higher resource usage on all nodes.
There is another reason too: The TaPOS parameters make use of a truncated block number which is so short that it only covers about 2.4 days of blocks.
What if tx.ref_block_prefix does not match ref_block_num? Will the tx be rejected or it's just a ref. as name implies?
It will be rejected.