v12.3 Testing

codablock

Active Member
Core Developer
Mar 29, 2017
100
154
93
36
Hello everyone,

UPDATE: 0.12.3.0-rc5 has been uploaded to Github:
https://github.com/dashpay/dash/releases/tag/v0.12.3.0-rc5
I've also updated the links in this post.

Please upgrade to the new version and issue mn-start on your masternodes.

RC5 should fix the forking issues currently seen on testnet.

Detailed changes: https://github.com/dashpay/dash/compare/v0.12.3.0-rc4...v0.12.3.0-rc5

-------

After a lot of unfortunate things happening one after another and getting into our way of releasing 12.3, we are finally at a point were we can go to public testing on testnet. For this, we created a 12.3 release candidate (v0.12.3.0-rc2) which can now be downloaded from the Github release page.

Github release candidate: https://github.com/dashpay/dash/releases/tag/v0.12.3.0-rc5
Release notes can be found here: https://github.com/dashpay/dash/blob/v0.12.3.0-rc5/doc/release-notes.md

One of the efforts we did in the last days was to fix and re-establish Gitian building and signing. This is not fully done yet, as there seems to be some non-determinism when the final windows setup.exe is built. We will investigate/fix this in the future. The actual binaries however (which are inside the setup.exe) match between Gitian builds and are signed as well. Gitian sigs can be found here: https://github.com/dashpay/gitian.sigs

Before testing:
Make sure you made a backup of you mainnet datadir somewhere or at least a backup of wallet.dat/dash.conf/masternode.conf;
Or use the -datadir and -conf parameters to use completely different directories.

What/how to test:
- Check if normal transactions are still working, perform some automated load testing if you want
- There were improvements in the governance system, please create a few proposals and check if everything looks correct and that you get proper payouts (or no payouts when votes are missing). Make a note in this thread if you need votes for a proposal.
- There were improvements in PrivateSend, please test if mixing still works for you
- Check if InstantSend is still working (it might fail in the beginning as not enough MNs are available/upgraded atm)
- Run a masternode or two, make sure it is paid;
- Generally, this release does not include so many new things, but instead includes a large list of improvements, refactorings and bug fixes. So the testing should ensure that everything old still works as expected.

What else you can do:
- Report serious issues (crashes/hangs/GUI glitches) : https://github.com/dashpay/dash/issues/new

Testnet tools (explorers, faucets, pools): https://www.dash.org/forum/threads/testnet-tools-resources.1768/
NOTE: Most faucets were dry recently, but a few devs now started to automatically fund these faucets. At the moment, at least http://test.faucet.masternode.io/ should have enough tDASH for everyone.

MNOs:
Wiki: https://dashpay.atlassian.net/wiki/spaces/DOC/pages/118162190/Masternodes+under+testnet
Sentinel : https://github.com/dashpay/sentinel/tree/develop

NOTE: Make sure you pulled Sentinel from `develop` branch and changed network to `testnet` in `sentinel.conf`. If you already have a mainnet masternode on the same server, do NOT run testnet masternode in the same datadir as your mainnet masternode (i.e. `.dashcore`). Create new folder specifically for testing (e.g. `.dashcore_test`) and make sure you use `-datadir=<yourtestnetdatadirhere>` cmd-line parameter for dashd and dash-cli. You'll also need a separate crontab line for testnet Sentinel. If you are not 100% sure what you are doing, I'd recommend setting up a new machine/instance for testing purposes only instead of reusing your mainnet server.

We're very sorry for the delay, and we'll try to change a few things so this doesn't happen again. For example, we'll now distribute knowledge/experience about the release process a little bit more. This is one of the reasons you see me instead of @UdjinM6 doing this post now (another reason is that his internet connection is horribly limited since a few days/weeks). Another thing we did now is to remove the dependency on Bamboo for doing releases. It has gone down a few weeks ago and left us in a state were we could not do a proper Gitian release anymore...add this together with missing time of multiple team members, missing experience in the release process, bad internet connections, ASICs on testnet (which shouldn't be a problem anymore after a few fixes we did) and you get the perfect mix of circumstances to get to the delay we got. We learned a few things about our weak spots here, let's try to fix them.
 
Last edited:

TanteStefana

Grizzled Member
Foundation Member
Mar 9, 2014
2,861
1,854
1,283
Can you give us an IP address? My wallet isn't finding a chain :)` no peers to connect to? should we put devnet=??? in the dash.conf file?

OK, for some reason my wallet just wouldn't find a peer. If you're having this problem, thephez just had me put the following in the console and it started to sync:

addnode 108.61.192.47 add

And suddenly I have 8 peers :D


I started from scratch, and just in case this helps locate an issue, here is a snippet from the debug log:


2018-06-03 02:06:32 CMasternodeSync:: processTick -- nTick 1 nRequestedMasternodeAssets 0 nRequestedMasternodeAttempt 0 nSyncProgress -0.250000 2018-06-03 02:06:36 38 addresses found from DNS seeds 2018-06-03 02:06:36 dnsseed thread exit
 
Last edited:

AjM

Well-known Member
Foundation Member
Jun 23, 2014
1,341
575
283
Finland
Hello everyone,

After a lot of unfortunate things happening one after another and getting into our way of releasing 12.3, we are finally at a point were we can go to public testing on testnet. For this, we created a 12.3 release candidate (v0.12.3.0-rc2) which can now be downloaded from the Github release page.

Github release candidate: https://github.com/dashpay/dash/releases/tag/v0.12.3.0-rc2
Release notes can be found here: https://github.com/dashpay/dash/blob/v0.12.3.0-rc2/doc/release-notes.md

One of the efforts we did in the last days was to fix and re-establish Gitian building and signing. This is not fully done yet, as there seems to be some non-determinism when the final windows setup.exe is built. We will investigate/fix this in the future. The actual binaries however (which are inside the setup.exe) match between Gitian builds and are signed as well. Gitian sigs can be found here: https://github.com/dashpay/gitian.sigs

Before testing:
Make sure you made a backup of you mainnet datadir somewhere or at least a backup of wallet.dat/dash.conf/masternode.conf;
Or use the -datadir and -conf parameters to use completely different directories.

What/how to test:
- Check if normal transactions are still working, perform some automated load testing if you want
- There were improvements in the governance system, please create a few proposals and check if everything looks correct and that you get proper payouts (or no payouts when votes are missing). Make a note in this thread if you need votes for a proposal.
- There were improvements in PrivateSend, please test if mixing still works for you
- Check if InstantSend is still working (it might fail in the beginning as not enough MNs are available/upgraded atm)
- Run a masternode or two, make sure it is paid;
- Generally, this release does not include so many new things, but instead includes a large list of improvements, refactorings and bug fixes. So the testing should ensure that everything old still works as expected.

What else you can do:
- Report serious issues (crashes/hangs/GUI glitches) : https://github.com/dashpay/dash/issues/new

Testnet tools (explorers, faucets, pools): https://www.dash.org/forum/threads/testnet-tools-resources.1768/
NOTE: Most faucets were dry recently, but a few devs now started to automatically fund these faucets. At the moment, at least http://test.faucet.masternode.io/ should have enough tDASH for everyone.

MNOs:
Wiki: https://dashpay.atlassian.net/wiki/spaces/DOC/pages/118162190/Masternodes+under+testnet
Sentinel : https://github.com/dashpay/sentinel/tree/develop

NOTE: Make sure you pulled Sentinel from `develop` branch and changed network to `testnet` in `sentinel.conf`. If you already have a mainnet masternode on the same server, do NOT run testnet masternode in the same datadir as your mainnet masternode (i.e. `.dashcore`). Create new folder specifically for testing (e.g. `.dashcore_test`) and make sure you use `-datadir=<yourtestnetdatadirhere>` cmd-line parameter for dashd and dash-cli. You'll also need a separate crontab line for testnet Sentinel. If you are not 100% sure what you are doing, I'd recommend setting up a new machine/instance for testing purposes only instead of reusing your mainnet server.

We're very sorry for the delay, and we'll try to change a few things so this doesn't happen again. For example, we'll now distribute knowledge/experience about the release process a little bit more. This is one of the reasons you see me instead of @UdjinM6 doing this post now (another reason is that his internet connection is horribly limited since a few days/weeks). Another thing we did now is to remove the dependency on Bamboo for doing releases. It has gone down a few weeks ago and left us in a state were we could not do a proper Gitian release anymore...add this together with missing time of multiple team members, missing experience in the release process, bad internet connections, ASICs on testnet (which shouldn't be a problem anymore after a few fixes we did) and you get the perfect mix of circumstances to get to the delay we got. We learned a few things about our weak spots here, let's try to fix them.
Win7 64bit - Dash Core v0.12.3.0-rc2

@codablock what is that 3 seconds count down in the sending dialog OK button?
It does not do anything, seems.

And command-line options blockreconstructionextratxn info is not translated.

-blockreconstructionextratxn=<n>
Extra transactions to keep in memory for compact block reconstructions (default: 100)
 

GNULinuxGuy

Member
Jul 22, 2014
112
68
78
Dash Address
XjkXfrYTSvdYe4738DtNVX5XfUz7qU9HnY
Updated my dedicated tMN. Looking good so far! Very exciting! Will continue to bring more testnet nodes online and do additional tests as I have time. :)
 
  • Like
Reactions: tungfa

codablock

Active Member
Core Developer
Mar 29, 2017
100
154
93
36
Can you give us an IP address? My wallet isn't finding a chain :)` no peers to connect to? should we put devnet=??? in the dash.conf file?

OK, for some reason my wallet just wouldn't find a peer. If you're having this problem, thephez just had me put the following in the console and it started to sync:

addnode 108.61.192.47 add

And suddenly I have 8 peers :D
Do I understand you correct that everything is ok now?

And command-line options blockreconstructionextratxn info is not translated.
This is most likely because translations were already done and imported/merged before these features were merged. I would consider this a minor problem and assume that we're going to fix it with one of the future translation imports.
 

AjM

Well-known Member
Foundation Member
Jun 23, 2014
1,341
575
283
Finland
This is most likely because translations were already done and imported/merged before these features were merged. I would consider this a minor problem and assume that we're going to fix it with one of the future translation imports.
@codablock Ok, and that OK button 3 sec count down?
 

codablock

Active Member
Core Developer
Mar 29, 2017
100
154
93
36
@codablock Ok, and that OK button 3 sec count down?
That's from the Bitcoin backports and acts as a protection against trigger fingers. It kind of forces you to double check your TX or at least think 3 more seconds. I personally find it ok this way...never forget, in Crypto there is no "reverse my erroneous transaction" ;)
 

AjM

Well-known Member
Foundation Member
Jun 23, 2014
1,341
575
283
Finland
That's from the Bitcoin backports and acts as a protection against trigger fingers. It kind of forces you to double check your TX or at least think 3 more seconds. I personally find it ok this way...never forget, in Crypto there is no "reverse my erroneous transaction" ;)
So, ok button does not work on first 3 seconds, thats ok.
 

akhavr

Active Member
Oct 11, 2014
767
384
133
Testnet synchronization stuck again:

Code:
  "blocks": 99743,
What I'm doing wrong?
 

codablock

Active Member
Core Developer
Mar 29, 2017
100
154
93
36
Sync issue might happen if you got unlucky and your first connection was to a node which has forked away. These are most likely non-upgraded nodes which still run 12.2.x, which does not include the fixes we did after the ASICs were turned on on testnet.
To fix it, disconnect the first node you see in the peers list in the debug window. To get to it, click on the "connections" icon on the bottom right.
 

akhavr

Active Member
Oct 11, 2014
767
384
133
Well, I've banned all non-/Dash Core:0.12.3/ nodes connections. Still stuck at block 99743. (Linux, command line)
 

codablock

Active Member
Core Developer
Mar 29, 2017
100
154
93
36
Well, I've banned all non-/Dash Core:0.12.3/ nodes connections. Still stuck at block 99743. (Linux, command line)
What does "Starting Block" of the first node that you're connected to say? And maybe the nodes after the first one?
 
Last edited:
Apr 9, 2018
44
20
48
I'm running 3 nodes
1) On all 3 nodes mixing of 10.0001 denomination doesn't work. Message in log "CPrivateSendClient::JoinExistingQueue -- Couldn't match 0 denominations 0 1 (10.0001)". And as I can see nobody can mix 10.0001. Other denominations - ok.

2) This appears in log on all 3 nodes (on 1 rarely, on other 2 very common):
2018-06-04 16:43:59 ProcessMessages(dsq, 115 bytes): Exception 'CDataStream::read(): end of data' caught, normally caused by a message being shorter than its stated length
2018-06-04 16:43:59 ProcessMessages(dsq, 115 bytes) FAILED peer=37
Caught nodes who send these dsq (all 12.3): 108.61.199.31:19999, 104.207.147.135:19999, 217.61.221.9:19999 (I caught these 3 nodes at the moment of writing - can be more, idk...)

3) This appears in log on 2 nodes:
2018-06-04 16:44:19 DSQUEUE -- nDenom=1, nInputCount=0, nTime=1528130658, fReady=false, fTried=false, masternode=fd864089dc3ff13ab4fb4161486826cc6f0b35e93f156d06efe6d9ec16e4dd3f-0 new
2018-06-04 16:44:19 DSQUEUE -- nLastDsq: 5020 threshold: 5049 nDsqCount: 5066
2018-06-04 16:44:19 DSQUEUE -- new PrivateSend queue (nDenom=1, nInputCount=0, nTime=1528130658, fReady=false, fTried=false, masternode=fd864089dc3ff13ab4fb4161486826cc6f0b35e93f156d06efe6d9ec16e4dd3f-0) from masternode 18.237.240.73:19029
2018-06-04 16:44:19 DSQUEUE -- nDenom=1, nInputCount=384097599, nTime=-4027553973496971264, fReady=true, fTried=false, masternode=00000000fd864089dc3ff13ab4fb4161486826cc6f0b35e93f156d06efe6d9ec-1528130658 new
2018-06-04 16:44:19 DSQUEUE -- nDenom=1, nInputCount=384097599, nTime=-4027553973496971264, fReady=true, fTried=false, masternode=00000000fd864089dc3ff13ab4fb4161486826cc6f0b35e93f156d06efe6d9ec-1528130658 new
2018-06-04 16:44:19 DSQUEUE -- nDenom=1, nInputCount=384097599, nTime=-4027553973496971264, fReady=true, fTried=false, masternode=00000000fd864089dc3ff13ab4fb4161486826cc6f0b35e93f156d06efe6d9ec-1528130658 new

2018-06-04 16:49:57 DSQUEUE -- nDenom=1, nInputCount=0, nTime=1528130997, fReady=false, fTried=false, masternode=46d413b903d058c9360bf15476eba262fb634d7ee4d7266f90364a7a35452292-0 new
2018-06-04 16:49:57 DSQUEUE -- nLastDsq: 4829 threshold: 4858 nDsqCount: 5085
2018-06-04 16:49:57 DSQUEUE -- new PrivateSend queue (nDenom=1, nInputCount=0, nTime=1528130997, fReady=false, fTried=false, masternode=46d413b903d058c9360bf15476eba262fb634d7ee4d7266f90364a7a35452292-0) from masternode 18.237.240.73:19057
2018-06-04 16:49:57 DSQUEUE -- nDenom=1, nInputCount=893723282, nTime=1304707985309696000, fReady=true, fTried=false, masternode=0000000046d413b903d058c9360bf15476eba262fb634d7ee4d7266f90364a7a-1528130997 new
2018-06-04 16:49:57 DSQUEUE -- nDenom=1, nInputCount=893723282, nTime=1304707985309696000, fReady=true, fTried=false, masternode=0000000046d413b903d058c9360bf15476eba262fb634d7ee4d7266f90364a7a-1528130997 new
2018-06-04 16:49:57 DSQUEUE -- nDenom=1, nInputCount=893723282, nTime=1304707985309696000, fReady=true, fTried=false, masternode=0000000046d413b903d058c9360bf15476eba262fb634d7ee4d7266f90364a7a-1528130997 new

2018-06-04 16:53:48 DSQUEUE -- nDenom=4, nInputCount=0, nTime=1528131228, fReady=false, fTried=false, masternode=d1983c6a794fe615fee629431c5b7ee27970aa28328482aa8bcd91d6761c99ab-1 new
2018-06-04 16:53:48 DSQUEUE -- nLastDsq: 5052 threshold: 5081 nDsqCount: 5099
2018-06-04 16:53:48 DSQUEUE -- new PrivateSend queue (nDenom=4, nInputCount=0, nTime=1528131228, fReady=false, fTried=false, masternode=d1983c6a794fe615fee629431c5b7ee27970aa28328482aa8bcd91d6761c99ab-1) from masternode 145.239.235.24:39999
2018-06-04 16:53:48 DSQUEUE -- nDenom=4, nInputCount=1981585835, nTime=-8711016110985576448, fReady=true, fTried=false, masternode=00000001d1983c6a794fe615fee629431c5b7ee27970aa28328482aa8bcd91d6-1528131228 new
2018-06-04 16:53:48 DSQUEUE -- nDenom=4, nInputCount=1981585835, nTime=-8711016110985576448, fReady=true, fTried=false, masternode=00000001d1983c6a794fe615fee629431c5b7ee27970aa28328482aa8bcd91d6-1528131228 new
2018-06-04 16:53:48 DSQUEUE -- nDenom=4, nInputCount=1981585835, nTime=-8711016110985576448, fReady=true, fTried=false, masternode=00000001d1983c6a794fe615fee629431c5b7ee27970aa28328482aa8bcd91d6-1528131228 new
In corrupted messages:
- in nInputCount - last 32bits of masternode txid
- in masternode index - last 32bits of nTime
and so on.
Clearly there is no nInputCount field in the dsq message and other fields are moved
 

UdjinM6

Official Dash Dev
Dash Core Team
Moderator
May 20, 2014
3,638
3,538
1,183
I'm running 3 nodes
1) On all 3 nodes mixing of 10.0001 denomination doesn't work. Message in log "CPrivateSendClient::JoinExistingQueue -- Couldn't match 0 denominations 0 1 (10.0001)". And as I can see nobody can mix 10.0001. Other denominations - ok.

2) This appears in log on all 3 nodes (on 1 rarely, on other 2 very common):

Caught nodes who send these dsq (all 12.3): 108.61.199.31:19999, 104.207.147.135:19999, 217.61.221.9:19999 (I caught these 3 nodes at the moment of writing - can be more, idk...)

3) This appears in log on 2 nodes:

In corrupted messages:
- in nInputCount - last 32bits of masternode txid
- in masternode index - last 32bits of nTime
and so on.
Clearly there is no nInputCount field in the dsq message and other fields are moved
That is most likely related to the fact that we are having slightly different 12.3/70209 nodes on the testnet, should fix itself once more people/nodes are upgraded.
 

akhavr

Active Member
Oct 11, 2014
767
384
133
What does "Starting Block" of the first node that you're connected to say? And maybe the nodes after the first one?
So far, the only 0.12.3 node, I'm connected to, has just 46229 blocks:

Code:
'version', 'subver', 'startingheight'
[(70208, u'/Dash Core:0.12.2.3/', 135647),
 (70208, u'/Dash Core:0.12.2/', 101855),
 (70208, u'/Dash Core:0.12.2.3/', 135647),
 (70209, u'/Dash Core:0.12.3/', 46229),
 (70208, u'/Dash Core:0.12.2.2/', 102503),
 (70208, u'/Dash Core:0.12.2.3/', 136235)]
 

AjM

Well-known Member
Foundation Member
Jun 23, 2014
1,341
575
283
Finland
So far, the only 0.12.3 node, I'm connected to, has just 46229 blocks:

Code:
'version', 'subver', 'startingheight'
[(70208, u'/Dash Core:0.12.2.3/', 135647),
 (70208, u'/Dash Core:0.12.2/', 101855),
 (70208, u'/Dash Core:0.12.2.3/', 135647),
 (70209, u'/Dash Core:0.12.3/', 46229),
 (70208, u'/Dash Core:0.12.2.2/', 102503),
 (70208, u'/Dash Core:0.12.2.3/', 136235)]
Doesnt that startingheight mean that the blocks start from there?
 

codablock

Active Member
Core Developer
Mar 29, 2017
100
154
93
36
So far, the only 0.12.3 node, I'm connected to, has just 46229 blocks:
Can you try to disconnect one node after another until you get one on top that has a correct starting block height. All the nodes you are connected to are forked or on a too old version.

Doesnt that startingheight mean that the blocks start from there?
startingheight is the block height reported by the node at the time of connecting to it. It's a good indicator to see if you are connected to forked (master) nodes, because if this number is too low, the other nodes seems to think that it is at the correct chain tip. This at least applies to masternodes you have connected to, as they will disconnect you immediately if they believe that they're not at the chain tip, not sure about regular nodes.
 
  • Like
Reactions: AjM

t0dd

Active Member
Mar 21, 2016
150
132
103
keybase.io
Dash Address
XyxQq4qgp9B53QWQgSqSxJb4xddhzk5Zhh
For Fedora/CentOS/RHEL folks that are comfortable with systemd (managing a node like a sys-admin)... my builds of 12.3 are updated and available in the test repos. Starting point: https://github.com/taw00/dashcore-rpm and then read the README.binaries.md document, which will then lead you to the .../documentation tree.

Just install the toddpkgs-dashcore-repo.fedora.rpm or toddpkgs-dashcore-repo.centos.rpm package to enable the repos (as described on that page). You'll then have to switch to the test repos...

```
# Fedora...
sudo dnf config-manager --set-disabled dashcore-stable
sudo dnf config-manager --set-enabled dashcore-testing
sudo dnf list --refresh|grep dashcore

```

```
# CentOS/RHEL
sudo yum-config-manager --disable dashcore-stable
sudo yum-config-manager --enable dashcore-testing
sudo yum clean expire-cache
sudo yum list|grep dashcore

```

Disclaimer: These builds are not fully endorsed by dash core group, though I have been building, using, and supporting them (as a community member) for years (there is even instruction how to build the RPMs yourself if you like). Ping me if you have any questions. -t0dd
 

UdjinM6

Official Dash Dev
Dash Core Team
Moderator
May 20, 2014
3,638
3,538
1,183
Please update to rc3 even if you are already running some older 12.3 node - it includes final min protocol bump i.e. you are going to fork off once spork10 is ON again. This update is mandatory for all nodes (MNs, mining and regular nodes). If you are still running 12.2 MNs, make sure to issue "masternode start-all" command from 12.3 wallet after upgrading both local and remote nodes.
 

AjM

Well-known Member
Foundation Member
Jun 23, 2014
1,341
575
283
Finland
@UdjinM6 @codablock

Win7 64bit - v0.12.3.0-rc3

Instantsend does not work.

Status: 0/unconfirmed, in memory pool (InstantSend verification failed), broadcast through 9 nodes

EDIT: But receiving end says it does work.

Status: 8 confirmations (verified via InstantSend)
 
Last edited:

codablock

Active Member
Core Developer
Mar 29, 2017
100
154
93
36
0.12.3.0-rc4 has been released, please see the UPDATE in the top post.
 

Antti Kaikkonen

Active Member
Jun 20, 2017
257
167
103
dashradar.com
Dash Address
XnZdwT1w2kGeH6RujwoyJ7BBNrukdyTBRB
It also includes a change in the sendrawtransaction RPC to reduce the risks behind the 0-conf double spend that was recently shown by Vin Armani. The double spend shown by him is actually known since a long time and not a Dash only problem but affects many other coins. And even though it's not even a real bug/vulnerability (merchants should never trust in simple 0-conf transactions...that's why we have InstantSend), we decided to reduce the risk by disallowing 0-conf transactions in sendrawtransaction by default (can be allowed through a parameter).
What risk does this reduce? Someone accidentally doing a double spend transaction?

Also the RC4 still doesn't appear to use HD wallet by default. Will this be implemented in the final release or not?
 

codablock

Active Member
Core Developer
Mar 29, 2017
100
154
93
36
What risk does this reduce? Someone accidentally doing a double spend transaction?
Sorry, forget to mention one crucial thing for the double spend: It only applies to 0-conf+0-fee (actually, low-fee) transactions. Currently, when calling sendrawtransaction your node will accept low-fee transaction into the local mempool but then very likely fail to relay it. This is because other nodes probably won't accept/relay 0-fee transactions. If at the same time a conflicting transaction is sent to the network, it will be fully propagated and at some point arrive on your own node...which will then drop that TX because it already has the 0-fee TX in the local mempool (first seen relay policy). So, your node won't notice that every other node in the network doesn't even know about the original TX and eventually the conflicting TX will be mined.
With sendrawtransaction rejecting low-fee TXs by default, this at least shouldn't happen by accident...for example when a block explorer blindly forwards raw transactions entered into some text field on a web page (that's what happened in the video).

Also the RC4 still doesn't appear to use HD wallet by default. Will this be implemented in the final release or not?
There are still some parts missing here, especially in the UI.
 
  • Like
Reactions: tungfa

Antti Kaikkonen

Active Member
Jun 20, 2017
257
167
103
dashradar.com
Dash Address
XnZdwT1w2kGeH6RujwoyJ7BBNrukdyTBRB
Sorry, forget to mention one crucial thing for the double spend: It only applies to 0-conf+0-fee (actually, low-fee) transactions. Currently, when calling sendrawtransaction your node will accept low-fee transaction into the local mempool but then very likely fail to relay it. This is because other nodes probably won't accept/relay 0-fee transactions. If at the same time a conflicting transaction is sent to the network, it will be fully propagated and at some point arrive on your own node...which will then drop that TX because it already has the 0-fee TX in the local mempool (first seen relay policy). So, your node won't notice that every other node in the network doesn't even know about the original TX and eventually the conflicting TX will be mined.
With sendrawtransaction rejecting low-fee TXs by default, this at least shouldn't happen by accident...for example when a block explorer blindly forwards raw transactions entered into some text field on a web page (that's what happened in the video).


There are still some parts missing here, especially in the UI.
Thanks for explaining.

A few months ago I succesfully send a 0-fee transaction using the standard GUI. It was included in block after a few blocks. I thought that 0-fee transactions are relayed if all of the inputs are old enough to prevent spam. Am I wrong or has this behavior been changed recently? If I'm correct then shouldn't createrawtransaction only prevent you from creating a 0-fee transaction if the inputs are too recent?