Ticket Fee

Discussion in 'Tickets' started by raphaelsoares, Apr 23, 2016.

  1. 2017/12/15 - Decred v1.1.2 released! → Release Notes  → Downloads
  1. raphaelsoares

    raphaelsoares New Member

    Jan 30, 2016
    38
    11
    Male
    Good Morning,

    I adjusted the ticket purchase fee to a higher value 0.1 with the command:

    --wallet setticketfee 0.1
    true

    --wallet walletinfo
    {
    "daemonconnected": true,
    "unlocked": true,
    "txfee": 0.01,
    "ticketfee": 0.1,
    "ticketmaxprice": 6.5,
    "balancetomaintain": 1,
    "stakemining": true
    }

    However , when running the ticket purchase manually with the command:

    --wallet purchaseticket default 8.5


    This fee of 0.1 is not being applied. All are with fee 0.03. Follow the txid :

    https://mainnet.decred.org/tx/a31d314c1132017de36944503ab769b8b05f8234c7f9c08ed8817508c6754cae
    https://mainnet.decred.org/tx/addf82a3071eb4820eb392e1bf533327bdf1d264e0f4bac81598502ee7f4bdef
    https://mainnet.decred.org/tx/368e7498301527cb9703170f10254edc0c32908a667369826bd6bb2d5f64456a


    I'm using the 0.1.0 version.


    Any solution?

    Thank's.
     
    goofoff likes this.
  2. ceejep

    ceejep Sr. Member
    Developer

    Dec 14, 2015
    192
    220
    The latest version correctly sets fee per KB. Your tickets are ~300 B in size, so the fee is correct (0.1*0.3 ~= 0.03).
     
    goofoff likes this.
  3. raphaelsoares

    raphaelsoares New Member

    Jan 30, 2016
    38
    11
    Male
    So , for a fee next 0.1 should run the command :

    --wallet setticketfee 0.4

    (0.4*0.3 ~= 0,12).


    Right?
     
  4. ceejep

    ceejep Sr. Member
    Developer

    Dec 14, 2015
    192
    220
    Yes. The mining code sorts by fees per KB right now.
     
    raphaelsoares likes this.
  5. raphaelsoares

    raphaelsoares New Member

    Jan 30, 2016
    38
    11
    Male
    Taking advantage of the post, I bought 19 tickes manually and some transaction are not located in MainNet , but the balance of the transaction are unavailable . This balance will only return in the next price adjustment ?

    --wallet getstakeinfo
    {
    "poolsize": 43052,
    "difficulty": 8.40110128,
    "allmempooltix": 2827,
    "ownmempooltix": 19,
    "immature": 0,
    "live": 41,
    "proportionlive": 0.000952336709095977,
    "voted": 18,
    "totalsubsidy": 32.75513184,
    "missed": 0,
    "proportionmissed": 0,
    "revoked": 0
    }


    Txids:

    https://mainnet.decred.org/tx/a31d314c1132017de36944503ab769b8b05f8234c7f9c08ed8817508c6754cae ok
    https://mainnet.decred.org/tx/89d431df63be3220041c69f29a8e7040bd4bc036cac33207251f04b0a6b5d463 not found
    https://mainnet.decred.org/tx/d5c29031dc36bf7dc9231de52463e0ed03009aabb4538cc3e117dd3e62a0d5d0 not found
    https://mainnet.decred.org/tx/addf82a3071eb4820eb392e1bf533327bdf1d264e0f4bac81598502ee7f4bdef ok
    https://mainnet.decred.org/tx/691c51e5483b03633a07ec3e0156b5f36677e2914433220ba6461cf43631a101 not found
    https://mainnet.decred.org/tx/368e7498301527cb9703170f10254edc0c32908a667369826bd6bb2d5f64456a ok
    https://mainnet.decred.org/tx/8466670d782a3875624c79255c6f15b83324d35f991f14d47bcfaf541081c1fb ok
    https://mainnet.decred.org/tx/96520c11615a98dca19035295669f9334c76ce59d2cb712bcc53e24971ff362a ok
    https://mainnet.decred.org/tx/cf8bdc39cb8d688a6a67e540379acc6c21db82fa63471ee18f9d373948331599 not found
    https://mainnet.decred.org/tx/bb084a6983c344f8879edac2060b016d09b3b80e30c0dee72021bfa8ec328396 ok
    https://mainnet.decred.org/tx/e6fba2474c313647bef35c8b74ef95c35de5d1d8e2b7c7f060e8e7304c8299d9 ok
    https://mainnet.decred.org/tx/75e22f5dcac575bd89464b7c7252e989c30d9cb005fb107fd4c12b0246a9dbed not found
    https://mainnet.decred.org/tx/b9870e39b69a6ce4a75ae2326c5478b171123edd4f068ad9ac0dcadb6059b3f2 not found
    https://mainnet.decred.org/tx/1f275966aac84765f9654527c5f0214c5cf5e0e39a3c1193aac74b38c4adafa3 ok
    https://mainnet.decred.org/tx/7ca074403b95c27c6a9438ea68e841b224820680a42563850fd777de5c30bac0 ok
    https://mainnet.decred.org/tx/ec2eb68dc637b0939bc55d626a9da5d0a54a13e18418b444eebc7e2eccf562aa ok
    https://mainnet.decred.org/tx/c3a2d5da406006aca15636d759185ba949515954a675c6ae5ea3099e2bf5c6d5 not found
    https://mainnet.decred.org/tx/0b89fdf6e79ece6d552b9bd65b4caca2870489e0a2bbfa1b8d9d43056ad3c938 not found
    https://mainnet.decred.org/tx/1783bb593e6f0236c155afd35014638e887e545193bbfefaa0adab2c3135e354 OK
     
  6. ceejep

    ceejep Sr. Member
    Developer

    Dec 14, 2015
    192
    220
    They show up in my mempool.
     
  7. raphaelsoares

    raphaelsoares New Member

    Jan 30, 2016
    38
    11
    Male
    How do you check ?
     
  8. ceejep

    ceejep Sr. Member
    Developer

    Dec 14, 2015
    192
    220
    getrawtransaction or getstakeinfo

    Code:
    > getrawtransaction 691c51e5483b03633a07ec3e0156b5f36677e2914433220ba6461cf43631
    a101 1 
    {
      "hex": "0100000001c1271ace9875123bb81dbb5a04af182b2a80aa95efb1888a27db4e8f29ed602b0000000000ffffffff03301013320000000000001aba76a9149881e608a122cd13cc7b738ffc7eb668ef2f5f8b88ac00000000000000000000206a1eb594a6b5817d2679910f27f63264bc844dd62585f0d64032000000000058000000000000000000001abd76a914000000000000000000000000000000000000000088ac000000000000000001ffffffffffffffff00000000ffffffff6a47304402201434555f640073cb79c7ac35347e7d59e973fd0d29b91b08a95cfb121b5223ec02203b25a0b8c9f472a7dd9d4d28bc34699ec6b17f80c6aa73f1b08398eec5c668a8012103c6eb0f8c8875186200171ad5371a413ca2ab071c98eb3d9a36d988850d6555be",
      "txid": "691c51e5483b03633a07ec3e0156b5f36677e2914433220ba6461cf43631a101",
      "version": 1,
      "locktime": 0,
      "expiry": 0,
      "vin": [
        {
          "txid": "2b60ed298f4edb278a88b1ef95aa802a2b18af045abb1db83b127598ce1a27c1",
          "vout": 0,
          "tree": 0,
          "sequence": 4294967295,
          "amountin": -1,
          "blockheight": 0,
          "blockindex": 4294967295,
          "scriptSig": {
            "asm": "304402201434555f640073cb79c7ac35347e7d59e973fd0d29b91b08a95cfb121b5223ec02203b25a0b8c9f472a7dd9d4d28bc34699ec6b17f80c6aa73f1b08398eec5c668a801 03c6eb0f8c8875186200171ad5371a413ca2ab071c98eb3d9a36d988850d6555be",
            "hex": "47304402201434555f640073cb79c7ac35347e7d59e973fd0d29b91b08a95cfb121b5223ec02203b25a0b8c9f472a7dd9d4d28bc34699ec6b17f80c6aa73f1b08398eec5c668a8012103c6eb0f8c8875186200171ad5371a413ca2ab071c98eb3d9a36d988850d6555be"
          }
        }
      ],
      "vout": [
        {
          "value": 8.40110128,
          "n": 0,
          "version": 0,
          "scriptPubKey": {
            "asm": "OP_SSTX OP_DUP OP_HASH160 9881e608a122cd13cc7b738ffc7eb668ef2f5f8b OP_EQUALVERIFY OP_CHECKSIG",
            "hex": "ba76a9149881e608a122cd13cc7b738ffc7eb668ef2f5f8b88ac",
            "reqSigs": 1,
            "type": "stakesubmission",
            "addresses": [
              "DsesHp6j5P9VjubU19j5c6HcY4PMton62Kd"
            ]
          }
        },
        {
          "value": 0,
          "n": 1,
          "version": 0,
          "scriptPubKey": {
            "asm": "OP_RETURN b594a6b5817d2679910f27f63264bc844dd62585f0d64032000000000058",
            "hex": "6a1eb594a6b5817d2679910f27f63264bc844dd62585f0d64032000000000058",
            "type": "sstxcommitment",
            "addresses": [
              "DshX1scqgTGVwZ6JnoRDsLX28Y1nirVCB5S"
            ],
            "commitamt": 8.43110128
          }
        },
        {
          "value": 0,
          "n": 2,
          "version": 0,
          "scriptPubKey": {
            "asm": "OP_SSTXCHANGE OP_DUP OP_HASH160 0000000000000000000000000000000000000000 OP_EQUALVERIFY OP_CHECKSIG",
            "hex": "bd76a914000000000000000000000000000000000000000088ac",
            "reqSigs": 1,
            "type": "sstxchange",
            "addresses": [
              "DsQxuVRvS4eaJ42dhQEsCXauMWjvopWgrVg"
            ]
          }
        }
      ],
      "blockheight": 0,
      "blockindex": 0
    }
     
    raphaelsoares likes this.
  9. raphaelsoares

    raphaelsoares New Member

    Jan 30, 2016
    38
    11
    Male
    What remains is to wait to see if the transaction on your own is confirmed due to the large number of purchase . Thank you for your help. Sorry to use the translator !
     
  10. zero

    zero Full Member

    Jan 1, 2016
    288
    121
    Male
    #10 zero, Apr 23, 2016
    Last edited: Apr 23, 2016
    So that's why I don't see the fee I set anywhere. But how can we pre-calculate the fee value that way? Will the ticket size always be around 300 bytes so it will always be ~ ticketfee * 0.3 ?
     
  11. Kandiru

    Kandiru Member

    Feb 21, 2016
    206
    87
    Shouldn't miners sort by absolute fee rather than fee per KB? If I'm mining a block, I want to include the highest 20 fees, not the highest 20 fees-per-KB which would get me less reward.
     
  12. ceejep

    ceejep Sr. Member
    Developer

    Dec 14, 2015
    192
    220
    New ticket sizes are smaller because they are generated more efficiently. The old ticket generation code needlessly wasted fees, so we should no longer have very large fee-rich tickets. You could maybe optimize again and take the bigger pool tickets, but right now the codebase doesn't.
     
  13. ceejep

    ceejep Sr. Member
    Developer

    Dec 14, 2015
    192
    220
    They are usually 290-292 bytes each, and about 550 bytes if they are for a stake pool.
     
    zero likes this.
  14. Kandiru

    Kandiru Member

    Feb 21, 2016
    206
    87
    The new code makes two transactions, which creates a fee-rich non-ticket, and a fee-light ticked transaction. This is great if your ticket is mined, but if you are at a point of over-subscription, then you run the risk of your ticket not being mined. This leaves you with an output which is exactly the right size for buying a ticket which is no longer available, and wastes your fee, and a new few to get it turned into a new output to buy a ticket at the new price. Even if you use the feature to expire your transaction and try again with a higher fee, you can't increase the fee with the same inputs, since your input is now the exact size of the ticket+old fee.

    What's wrong with the method of PoS miners consolidating the outputs into the ticket transaction, creating a large ticket with the combined fee. This should then be given priority for miners, since it has a large fee (even if the fee-per-KB is low, PoW miners should rank tickets according to absolute fee, since that's how their reward works. Why get 20*0.001DCR when you can have 20*0.02DCR?)

    If the ticket isn't included in a block, then you haven't actually spent any fees, so you can try again at the new price. This leaves the PoS miner in more control over their transactions. It's a pretty horrible feeling to try to buy 10 tickets, but instead get 0 tickets and pa
     
  15. ceejep

    ceejep Sr. Member
    Developer

    Dec 14, 2015
    192
    220
    Unnecessarily large tickets create larger votes that propagate more slowly throughout the network and take longer to validate. The price of fee per input for a ticket is larger than that of a regular transaction.

    The more "ideal" method would be consolidating and then chaining tickets end to end using their change. But this is not yet allowable in the mempool. When the mempool is fixed for this the code will be updated to use that path instead. The problem with this is that it can cause your change to get stuck for long periods of time if the ticket never enters a block, especially without expiry.

    In the meantime the ticketbuyer dynamically updates fees and waits to see if transactions enter the mempool, which is an OK halfway point until mempool issues are worked out.
     
  16. Kandiru

    Kandiru Member

    Feb 21, 2016
    206
    87
    Right, larger votes is an issue for causing missed votes down the line. I wonder if there is a way to allow small votes with large tickets, using the scripting OP codes and assigning voting rights to a separate address? I need to go read on some more on precisely how voting transactions are generated.
     

Share This Page