Author Topic: GRAPHENE_DEFAULT_MAX_TIME_UNTIL_EXPIRATION and transaction expiration  (Read 5353 times)

0 Members and 1 Guest are viewing this topic.

Offline abit

  • Committee member
  • Hero Member
  • *
  • Posts: 4664
    • View Profile
    • Abit's Hive Blog
  • BitShares: abit
  • GitHub: abitmore
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.
BitShares committee member: abit
BitShares witness: in.abit

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
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) ...

Offline zhangweis

  • Sr. Member
  • ****
  • Posts: 305
    • View Profile
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?
Weibo:http://weibo.com/zhangweis

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
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.

Offline zhangweis

  • Sr. Member
  • ****
  • Posts: 305
    • View Profile
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.
Weibo:http://weibo.com/zhangweis

Offline pc

  • Hero Member
  • *****
  • Posts: 1530
    • View Profile
    • Bitcoin - Perspektive oder Risiko?
  • BitShares: cyrano
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.
Bitcoin - Perspektive oder Risiko? ISBN 978-3-8442-6568-2 http://bitcoin.quisquis.de

Offline zhangweis

  • Sr. Member
  • ****
  • Posts: 305
    • View Profile
Why not just make GRAPHENE_DEFAULT_MAX_TIME_UNTIL_EXPIRATION long enough like the same 4 weeks as proposal max time until expiration?
Weibo:http://weibo.com/zhangweis

Offline zhangweis

  • Sr. Member
  • ****
  • Posts: 305
    • View Profile
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. 
Weibo:http://weibo.com/zhangweis

Offline pc

  • Hero Member
  • *****
  • Posts: 1530
    • View Profile
    • Bitcoin - Perspektive oder Risiko?
  • BitShares: cyrano
Bitcoin - Perspektive oder Risiko? ISBN 978-3-8442-6568-2 http://bitcoin.quisquis.de

Offline zhangweis

  • Sr. Member
  • ****
  • Posts: 305
    • View Profile
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?
Weibo:http://weibo.com/zhangweis