v12.3 Testing

akhavr said:
So far, the only 0.12.3 node, I'm connected to, has just 46229 blocks:
Click to expand...
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.

AjM said:
Doesnt that startingheight mean that the blocks start from there?
Click to expand...
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
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
 
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.
 
@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
Click to expand...


EDIT: But receiving end says it does work.

Status: 8 confirmations (verified via InstantSend)
Click to expand...
 
Last edited:
codablock said:
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).
Click to expand...
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?
 
Antti Kaikkonen said:
What risk does this reduce? Someone accidentally doing a double spend transaction?
Click to expand...
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).

Antti Kaikkonen said:
Also the RC4 still doesn't appear to use HD wallet by default. Will this be implemented in the final release or not?
Click to expand...
There are still some parts missing here, especially in the UI.
 
codablock said:
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.
Click to expand...
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?
 
@codablock
AjM said:
Win7 64bit - v0.12.3.0-rc4

Now InstantSend works ok.
Click to expand...

Also PrivateSend mixing works ok.

But Privatesend with Instantsend option did not worked, instantsend verifcation failed,
so it was only a normal send with 6 confirmations.
 
So my wallet isn't mixing, and I'm wondering if it's because nobody is mixing on the network? Been a while :)....
 
codablock said:
v0.12.3.0-rc5 has just been uploaded to Github.
Click to expand...

Win7 x64 - v0.12.3.0-rc5

Privatesend with Instantsend option did not worked, instantsend verifcation failed,
so it was only a normal send with 6 confirmations.

privinstfailed.png
 
Help! I need some test coins. After using it, I will give it back to the tap and let it help more people. Thank you, this is my address. yVQsJwAEneRATJzBmi4Ckt5KVGewp4SJn1
 
You must log in or register to reply here.
Back
Top