0

I've noticed that an unusually high number of my attempted send transactions between my nodes (which is currently only 6 at most, but never less than 4) will not broadcast regardless of the amount of time I wait. I end up having to eventually abandon them to return the funds from the wallet I am trying to send them from. I have noticed no specific correlation between sender and recipient (like a single node always being unable to send or receive) and have noticed that every successful transaction is broadcast and appears in the memory pool pretty much immediately after sending.

Is there any specific cause for this? Maybe the fact that I'm currently limited to such a small # of nodes?

Have used getnewaddress to generate every address that has successfully and unsuccessfully received coins so I find it difficult to believe the actual addresses can be the problem as they should all have been derived from valid keys.

  • Schwifty
| improve this question | |
  • How are you creating your transactions? Do they include a sufficient transaction fee? In your debug.log file, do you see any error messages related to your transaction when you send? – Andrew Chow♦ Jun 25 '18 at 7:19
  • I have been using the recommended fee (per the core without smart fee calculation) which is 0.02 coins/KB. They have varied in size from a few dozen to a few thousand coins, with the largest successful transaction being 15k coins. Debug log: "can't broadcast immediately, no witness yet" but all the nodes are running network, witness and bloom services. I am working with very limited resources and will ultimately be scrapping this coin to apply the seemingly innumerable lessons I've learned to another, but I would like to be able to confirm this is only being caused by insufficient node density – apt-getschwifty Jun 25 '18 at 21:31
  • Also, I am creating the transactions simply by using the send function within a qt-wallet, and I am sending them to a newly generated address. I ran out of room to put that in my initial response, my apologies! – apt-getschwifty Jun 25 '18 at 21:34
2

The issue has nothing to do with node density. You are getting the error can't broadcast immediately, no witness yet which means that segwit is not active on your coin yet so the spends of segwit outputs will not be broadcast. You must activate segwit by mining enough blocks which signal for Segwit. Having the NODE_WITNESS service bit set does not matter; segwit is a consensus rule and the service bit is meaningless without the consensus rule being active.

| improve this answer | |
  • Why have other transactions sent successfully WELL before segwit then? Because I was first able to successfully send coins at around 500 blocks. And my rule change activation threshold is set at 4320 blocks, 75% of the miner confirmation window which is at 5760 blocks.. – apt-getschwifty Jun 25 '18 at 21:51
  • And you shouldn't see any change in the deployment status of segwit until at least the miner confirmation window, correct? – apt-getschwifty Jun 25 '18 at 21:52
  • 1
    When you mine blocks, the outputs are non-segwit. So when you first are sending transactions, you are sending non-segwit transactions because all of the inputs are spends of the non-segwit coin generation outputs. However those transactions are likely creating segwit outputs (both as change and normally) which you end up spending later. – Andrew Chow♦ Jun 25 '18 at 21:53
  • The status changes based upon the previous window, so if you have not fully mined a window yet, the status will not change. – Andrew Chow♦ Jun 25 '18 at 21:54
  • 1
    Yes, to both questions. – Andrew Chow♦ Jun 25 '18 at 23:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.