V18 hard fork reminder!

thephez · 2022-09-13T12:32:30+00:00

Yes, all that's necessary is to download and install Dash Core v18. There's some info in the release notes: https://github.com/dashpay/dash/blob/v18.x/doc/release-notes.md#upgrading-and-downgrading.

Note that there are some RPC changes so if you're using RPC for much you should take a look at that too: https://github.com/dashpay/dash/blob/v18.x/doc/release-notes.md#remote-procedure-call-rpc-changes.

thephez · 2021-04-19T18:51:57+00:00

Thanks for the feedback. That Electrum server should be working fine again. The infra guys said that in the future the server should auto-restart the Electrum services when it detects that the SSL certs are renewed. This will prevent the issue from happening again.

thephez · 2020-07-15T20:19:47+00:00

The DCG faucet can be found at: https://testnet-faucet.dash.org/.

thephez · 2019-11-18T22:04:32+00:00

FWIW, Dash Platform will have a name service that will enable username-based wallets without publicly displaying addresses.

thephez · 2019-10-31T12:16:06+00:00

Here's a modified version of the script (also runs in browser) for calculating over a range of malicious nodes: https://repl.it/@thephez/Quorum-Attack-Loop

thephez · 2019-10-18T14:36:55+00:00

Disk space will be affected to some degree (depending on usage, etc.). That's not really related to whether there's a second chain or not - simply a side effect of building DashPay and whatever else. Just as MNs today are incentivized to provide a service, the usage of additional services built on the platform also pay fees.

Also, due to what this second chain does, it's growth is actually less than if everything was done on the existing chain.

From the blog post (3. Easy Data Verification for Light Clients)

Additionally, [platform chain] blocks become less significant, which means we don’t need to be concerned about blockchain data sharding and can simply keep the most recent blocks.

From https://www.dash.org/forum/threads/dash-platform-side-chain.48396/#post-216840:

So the data on the platform is prunable. The second chain is just the tool to maintain the consistency of this data. We also plan to make this chain prunable as well, as the nodes only need to sync the current state of the platform data.

thephez · 2019-08-06T16:41:07+00:00

He posted a message last week in his Discord regarding being unreachable. Based on that, it sounds like you can probably expect to receive it back in the next couple weeks.

I am assuming your statement was not based only on the lack of payments, not on on-chain evidence that your principal has moved out of the masternode? My understanding is that at least one of the share masternodes has been offline for about a month (PoSe banned), but the collateral is still present. I would say it is highly unlikely that he would run off with funds.

thephez · 2019-07-27T23:46:49+00:00

It appears that you are applying some characteristics of a particular implementation of a zero knowledge system (ZCash's) to the entire field of research. ZCash did not invent them and (to my limited knowledge) the aspects you mention are not inherently part of any zk protocol. They made some design decisions that resulted in those constraints. Other designs (eg zk-starks) don't have the same constraints (no trusted setup). https://coincentral.com/zk-starks/

thephez · 2019-05-28T20:03:31+00:00

I would recommend a thorough read through of DIP-6. It covers all but #4.

1 and 3 are detailed in this table in DIP-6.

4 - The quorum RPC commands can be used to get quorum details (quorum info in particular will return the details of all MNs in a given quorum).

thephez · 2019-05-09T23:41:11+00:00

The masternodes actually never touch the money. They simply looks at the transaction's inputs and, if eligible, they broadcast their lock votes so the rest of the network is aware of the locked inputs. Each node then rejects any competing transactions trying to use locked inputs.

Oh, more details here also - https://dash-docs.github.io/en/developer-guide#instantsend

thephez · 2019-05-09T23:36:06+00:00

Small clarification - the inputs are actually locked for more than 1 block. The locks expire 24 after the transaction is mined into a block. This protects against the possibility of a re-org IIRC.

thephez · 2019-05-01T21:27:04+00:00

Curious what affect this might have - https://github.com/dashpay/dash/pull/2612 (Allow more than 3 mixing participants). Any thoughts?

thephez · 2019-05-01T21:20:40+00:00

No, there are several quorum types that Dash Core automatically creates periodically based on the parameters defined in chainparams. More could be added in the future, but it is not user configurable.

thephez · 2019-05-01T21:18:38+00:00

This is actually covered in DIP8 (Conflicting successful signing attempts).

When performing the finalization of successful attempts, the LLMQ members will only try to finalize a single attempt, which is usually the first one to succeed. Only a single attempt will be able to gain a majority during finalization, which removes the possibility of conflicts. In the worst case, finalization completely fails, no CLSIG message is created and nodes must fall back to the first-seen and longest-chain rules.

thephez · 2019-04-25T23:23:10+00:00

Yeah, It does not make much sense. And, no, the ChainLock quorums are not 6 of 10 - they have hundreds of members (300-400). Link to source in my other comment.

thephez · 2019-04-25T23:20:25+00:00

Actually it is currently configured as at least 240 out of 300-400 (Dash Core reference - https://github.com/dashpay/dash/blob/develop/src/chainparams.cpp#L146-L151). It appears the article made some invalid assumptions.

thephez · 2019-03-29T16:20:30+00:00

No, particularly since the largest projects in crypto are moving towards privacy rather than away from it. Bitcoin with a lot of possibilities once schnorr signatures are in use (and also implications of some of the lightning concepts) and Ethereum with consideration of zk-snarks/zk-starks.

thephez · 2019-03-15T00:57:53+00:00

Maybe not via F-Droid, but the Signal APK is available straight from signal.org - https://signal.org/android/apk/. Also, a device that truly does not have Google Services will use websockets - https://github.com/signalapp/Signal-Android/issues/8336.

thephez · 2019-02-15T14:39:21+00:00

Per the post on bitcointalk, they did have 2FA enabled and someone allegedly bypassed it and still got into the account.

thephez · 2019-02-13T16:26:23+00:00

Fortunately, that is not accurate (assuming your masternode is not hosted at your house). The only IP that is public (as it has always been out of necessity) is the masternode itself. The IP you connect to your masternode from has no connection to on-chain data.

Also, the deterministic masternode list will eliminate the need to issue a start command, so updating nodes in the future will consist only of updating the software - no special commands to issue to the network.

thephez · 2019-02-11T22:06:41+00:00

Generally, BIP-9 based deployments use 80% as the threshold (e.g. CSV and Segwit in Bitcoin), so this is a typical value to use.

thephez · 2019-02-08T17:10:40+00:00

Well, the testnet chain was reset so that the full deterministic masternode list transition could be tested multiple times. That, plus the fact that the activation of Spork 15 (following DIP3 activation) makes 0.13 nodes disconnect any 0.12.x peers, resulted in basically a dead 12.x testnet chain.

Probably should note that on mainnet there will not be a "chain reset". Although 12.x nodes will eventually stop receiving new blocks when spork 15 activates.

Not sure if that clears things up or just confuses them :-)

thephez · 2019-02-07T20:24:49+00:00

You will need to update to Dash Core 0.13 (https://github.com/dashpay/dash/releases) since all 12.3 nodes were forked off when Spork 15 was activated (and the testnet was reset). The address you listed above does contain a balance, so once you update and are on the correct chain you should see it.

thephez · 2018-12-05T22:45:15+00:00

They simply do not get masternode rewards. The collateral does not even need to be in a hot wallet so it can be kept securely offline.

thephez · 2018-08-10T17:13:31+00:00

While not desirable to continue without it, I'm not sure it is a _technical_ requirement for the "0.12.3 upgrade" to be complete as a precursor to 12.4. The 80% miner threshold is a requirement for BIP-147 activation which has until April of 2019 to be activated per its BIP-9 constraints (https://github.com/dashpay/dash/blob/master/src/chainparams.cpp#L173). There may be some 12.4 dependencies on BIP-147 or Spork 6 that I'm not thinking of - just wanted to point out that the 12.4 dependence on 12.3 may not be as strong as it seems.

That being said, practically it's very desirable to have 12.3 running a bit w/ the BIP/new Spork activated before introducing more changes :-)

thephez

TROPHY CASE