<p>The issue has nothing to do with node density. You are getting the error <code>can't broadcast immediately, no witness yet</code> 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 <code>NODE_WITNESS</code> service bit set does not matter; segwit is a consensus rule and the service bit is meaningless without the consensus rule being active.</p>

CC BY-SA 4.0
2018-06-25T21:51:19.200Z
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
CC BY-SA 4.0
2018-06-25T21:52:24.353Z
And you shouldn't see any change in the deployment status of segwit until at least the miner confirmation window, correct?
apt-getschwifty
CC BY-SA 4.0
2018-06-25T21:53:42.510Z
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.
Ava Chow
CC BY-SA 4.0
2018-06-25T21:54:36.767Z
The status changes based upon the previous window, so if you have not fully mined a window yet, the status will not change.
Ava Chow
CC BY-SA 4.0
2018-06-25T22:09:45.170Z
Okay okay, that makes sense. I understand the status changing based upon the previous window, and that I may end up spending segwit outputs later.. so does that mean that in theory if I waited until segwit was fully deployed I should have no issue? Also, does that mean if I could ensure that I was sending coins that aren't associated with any segwit outputs I should have no issue?
apt-getschwifty
CC BY-SA 4.0
2018-06-25T22:12:05.503Z
Also, you're the man, just so you know.
apt-getschwifty
CC BY-SA 4.0
2018-06-25T23:06:28.920Z
Yes, to both questions.
Ava Chow
CC BY-SA 4.0
2018-06-25T21:36:50.897Z
2018-06-25T21:36:50.897Z
Ava Chow
<p>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.</p>

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

<p>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.</p>

<ul>
<li>Schwifty</li>
</ul>

CC BY-SA 4.0
2018-06-25T07:19:03.687Z
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?
Ava Chow
CC BY-SA 4.0
2018-06-25T21:31:20.000Z
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
CC BY-SA 4.0
2018-06-25T21:34:43.587Z
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
<wallet><altcoin><altcoin-development><scrypt>
Altcoin: Send/receive transactions between nodes have high failure rate
apt-getschwifty
# Altcoin: Send/receive transactions between nodes have high failure rate

(Asked by: username_0 on 2018-06-22)

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

**Tags:** wallet, altcoin, altcoin-development, scrypt

> **Comments:**
> **username_1**: 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?  
> **username_0**: 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  
> **username_0**: 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!  

---

## 1 answers

### Answer by username_1 on 2018-06-25. Score: 2 | Accepted answer

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.

> **Comments:**
> **username_0**: 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..  
> **username_0**: And you shouldn't see any change in the deployment status of segwit until at least the miner confirmation window, correct?  
> **username_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.  
> **username_1**: The status changes based upon the previous window, so if you have not fully mined a window yet, the status will not change.  
> **username_0**: Okay okay, that makes sense. I understand the status changing based upon the previous window, and that I may end up spending segwit outputs later.. so does that mean that in theory if I waited until segwit was fully deployed I should have no issue? Also, does that mean if I could ensure that I was sending coins that aren't associated with any segwit outputs I should have no issue?  
> **username_0**: Also, you're the man, just so you know.  
> **username_1**: Yes, to both questions.  

---

