Results 1 to 10 of 10

Thread: [beta] faucet

  1. #1
    Junior Member
    Join Date
    Aug 2014
    Posts
    11

    [beta] faucet

    Hi, I am still beta-testing the Fluttercoin Faucet but the daemon creates a lot of double spends and freezes my balance effectively. See below for an example:


    16:43 [1407249821] Request to send 0.070526 FLT; Transaction ID 3bbd7560814e0c8c958d99711ce077b5d1c262847d0d1c79d8 96af54139ba439
    16:46 [1407249989] Block appears and includes the 3bb... Transaction
    17:22 [1407252120] Request to send 0.055363 FLT; Transaction ID 3fb6ac1692949b2fd8b02f3b55fe75899047e9c712c897614d b281355f2774bd
    17:22 [1407252121] Collect all change, dust, etc; Transaction ID 9a8610f207f8452652552aaeb690f096c7c5ed949f34249890 1bc6e73bc2d0b9
    17:22 [1407252137] Block appears but only includes the 3fb... Transaction
    17:22 [1407252158] Request to send 0.056462 FLT; Transaction ID e8fb91523253dc5532a4968d99b4a7548312cc60715c55d059 7f17e774a6567d (double spend conflicting the 9a... Transaction)
    17:22 [1407252160] Collect all change, dust, etc; Transaction ID c5cfc12595b2ef9ee38773b900a88bb4d6114cb66d170c5f7b 16af02220d9b12 (Uses the double spend -> no confirmation)
    17:24 [1407252297] Block appears and includes the 9a... Transaction

    The JSON of the e8f... Transaction clearly shows that it uses the already spent 3fb... as input!
    Code:
    {
       "txid":"e8fb91523253dc5532a4968d99b4a7548312cc60715c55d0597f17e774a6567d",
       "version":1,
       "time":1407252158,
       "locktime":0,
       "vin":[
          {
             "txid":"3fb6ac1692949b2fd8b02f3b55fe75899047e9c712c897614db281355f2774bd",
             "vout":0,
             "scriptSig":{ },
             "sequence":4294967295
          }
       ],
       "vout":[ ],
       "amount":-0.05646200,
       "fee":-0.01000000,
       "confirmations":0,
       "txid":"e8fb91523253dc5532a4968d99b4a7548312cc60715c55d0597f17e774a6567d",
       "time":1407252158,
       "timereceived":1407252158,
       "details":[ ]
    }

    The JSON of the c5c... Transaction clearly shows that it used the "malicious" e8f... Transaction as input
    Code:
    {
       "txid":"c5cfc12595b2ef9ee38773b900a88bb4d6114cb66d170c5f7b16af02220d9b12",
       "version":1,
       "time":1407252160,
       "locktime":0,
       "vin":[
          {
             "txid":"e8fb91523253dc5532a4968d99b4a7548312cc60715c55d0597f17e774a6567d",
             "vout":0,
             "scriptSig":{ },
             "sequence":4294967295
          },
          {
             "txid":"9a8610f207f8452652552aaeb690f096c7c5ed949f342498901bc6e73bc2d0b9",
             "vout":0,
             "scriptSig":{ },
             "sequence":4294967295
          }
       ],
       "vout":[ ],
       "amount":0.00000000,
       "fee":-0.01000000,
       "confirmations":0,
       "txid":"c5cfc12595b2ef9ee38773b900a88bb4d6114cb66d170c5f7b16af02220d9b12",
       "time":1407252160,
       "timereceived":1407252160,
       "details":[ ]
    }

  2. #2
    Junior Member
    Join Date
    Aug 2014
    Posts
    11
    Quote Originally Posted by fau_cat View Post
    The JSON of the e8f... Transaction clearly shows that it uses the already spent 3fb... as input!
    I think the problem is, that the block did not contain the 9a... Transaction and thus confused the daemon. If you are looking at the latest transactions on the site ( http://fauc.at/Index/Fluttercoin ) you can see "null" instead of the e8f... Transaction in the URL to the block explorer. (Indicating that there was some sort of error-response from the daemon)


    One possible explanation is that the client prefers to spend confirmed inputs first (and intentionally creating a double spend) instead of using the "soon to be confirmed but still 0-conf" input. Thoughts? (I will get some sleep now and think about it tomorrow)


    Edit: I already have an idea how to avoid this (if I am right) ... Implementing tomorrow...
    Last edited by fau_cat; 08-05-2014 at 10:21 PM. Reason: idea

  3. #3
    Junior Member
    Join Date
    Aug 2014
    Posts
    11
    I can't think of a working solution on my side. This really sounds like a bug. (I could not reproduce with Bitcoin and Litecoin but with Fluttercoin) The steps to reproduce are:


    1. Split your whole balance into two approx. equal inputs.
    2. Send approx. (amount/4) coins to a new address. (Wait some seconds to publish the transaction)
    3. Pull your internet cable to go offline. (I left the client running)
    4. Send all coins to a new address
    5. Wait for at least one block to appear
    6. Push in back your internet cable and wait for the client so sync
    7. Send approx. (amount/8) coins to a new address (This is the double spent, rejected by the network)

  4. #4
    Senior Member ofeefee's Avatar
    Join Date
    Jun 2014
    Posts
    102
    Quote Originally Posted by fau_cat View Post
    I can't think of a working solution on my side. This really sounds like a bug. (I could not reproduce with Bitcoin and Litecoin but with Fluttercoin) The steps to reproduce are:


    1. Split your whole balance into two approx. equal inputs.
    2. Send approx. (amount/4) coins to a new address. (Wait some seconds to publish the transaction)
    3. Pull your internet cable to go offline. (I left the client running)
    4. Send all coins to a new address
    5. Wait for at least one block to appear
    6. Push in back your internet cable and wait for the client so sync
    7. Send approx. (amount/8) coins to a new address (This is the double spent, rejected by the network)
    I've seen this with other coins, basically you send coins when they can't be sent (no connection). When it comes back online it needs to sync and retransmit these transactions.

    I will see if there's a fix on anotherr coin or something in NVC, we use a fork of nvc for the most part, maybe they had a fix. There is a TX/Rx code changes, not sure these apply but can check. Easiest solution is to sync up and then wait for one more block and then send coins, so you retransmit and then wait for this to confirm once

  5. #5
    Junior Member
    Join Date
    Aug 2014
    Posts
    11
    Quote Originally Posted by ofeefee View Post
    ... then wait for one more block and then send coins
    I guess I will apply your suggestion but I can't queue the transaction so my faucet will just tell the user to try again in a few minutes.

  6. #6
    Senior Member ofeefee's Avatar
    Join Date
    Jun 2014
    Posts
    102
    Quote Originally Posted by fau_cat View Post
    I guess I will apply your suggestion but I can't queue the transaction so my faucet will just tell the user to try again in a few minutes.
    I'm wondering how you lose network connectivity but are still handling transactions? If you lose network connectivity there would not be any request to send coins so how would this happen?

  7. #7
    Junior Member
    Join Date
    Aug 2014
    Posts
    11
    The fluttercoin daemon of the faucet is connected 24/7 to the network and pulling the LAN wire was just a "hack" to reproduce the observed situation described in post #1. (Two transactions exist of which only one gets into the very next block and the other gets into the 2nd next block)
    Last edited by fau_cat; 08-07-2014 at 06:27 PM. Reason: precise

  8. #8
    Junior Member
    Join Date
    Aug 2014
    Posts
    11
    This seems to happen randomly with every unconfirmed transaction now. The most recent example:

    20:01 [1407866519] 0f3862bd2e6d112b6809fec73a85bde1dcabccbedd284c3106 e717c10f39e878
    20:08 [1407866920] 8560421b535f82ecb82a930e25112e193d98dd86a384e1bacc 9fac4f20a211c1
    20:09 [1407866964] block includes the 85...
    20:09 [1407866968] 63c1c1b4cc0094c15ecd0bd7db4c9fee2b08bd239402290a13 27469bde30ebef
    20:10 [1407867041] 55fcc796ce284be357c9daedd9c96e735975ffdbab51177ed5 262412a0ca3a3b (conflicting: Using 85... as vin instead of 63... // see below)
    20:11 [1407867082
    ] block includes the 63...

    Code:
    {  
       "txid":"55fcc796ce284be357c9daedd9c96e735975ffdbab51177ed5262412a0ca3a3b",
       "version":1,
       "time":1407867041,
       "locktime":0,
       "vin":[  
          {  
             "txid":"8560421b535f82ecb82a930e25112e193d98dd86a384e1bacc9fac4f20a211c1",
             "vout":0,
             "scriptSig":{  },
             "sequence":4294967295
          }
       ],
       "vout":[  ],
       "amount":-0.07894800,
       "fee":-0.01000000,
       "confirmations":0,
       "txid":"55fcc796ce284be357c9daedd9c96e735975ffdbab51177ed5262412a0ca3a3b",
       "time":1407867042,
       "timereceived":1407867042,
       "details":[  ]
    }
    Last edited by fau_cat; 08-12-2014 at 06:53 PM. Reason: typo

  9. #9
    Senior Member ofeefee's Avatar
    Join Date
    Jun 2014
    Posts
    102
    How are you getting unconfirmed transactions?, I can understand blocks that are orphans, but transactions are pretty straightforward.

    You can look through nvc, black, HBN, cap and see of there's a commit that reflects it, I will look.

  10. #10
    Senior Member ofeefee's Avatar
    Join Date
    Jun 2014
    Posts
    102
    There's a lot of bug fixing to still do.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •