Topic: [ANN]🌀 Blur Network(BLUR) 🌀 | PoW Cryptonight-Dynamic | CPU/Solo Mining | DPoW - page 4. (Read 41328 times)

Implementation of addresses with non-deterministic view/spend key pairs is complete.  See the README.md at https://github.com/blur-network/dpow-blur for details on how to use the notary-server-rpc to generate an address.  These addresses are LIVE and will be able to spend/receive funds.  Only do so if you are an experienced user.

Another update on the state of DPoW integrations: (Repost from Komodo Discord)

1.) Notary Node  addresses & wallet building is underway. You can see the beginnings of the address work  here: (https://github.com/blur-network/dpow-blur/commit/1d4397c4da4b70eb3a66a911c4e3c78b1c138b53).

Understanding how this will work with NN pubkeys, requires a little background on XMR addresses.  In monero's ecosystem, each wallet address consists of two separate keypairs (4 keys in total, 2 public, 2 private). These consist of a viewkey pair, and a spendkey pair.  If keys are truly independent (they are deterministic in XMR, but will not be for notary nodes), the private viewkey can be used by third parties to transparently view the transactions. This is possible without the viewer having any way to actually compromise the funds of the wallet in question.

 jl777 and I spoke about about ways to employ the existing BTC pubkeys that notary nodes currently use, and avoid requiring submission of private keys of any kind... What we settled on was repurposing the current btc pubkeys as private viewkeys for  notary nodes on BLUR.  For the other keypair (spendkey), a new crypto library, built on Ed25519 and GIMLI permutations, called libhydrogen will be used to generate a high entropy secret spendkey.

This means that NN operators will only have  to provide their pubkey on startup of blur-notary-server-rpc, and a unique wallet address will then be generated.

2.) An extra parameter for dpowconfs has been added to the wallet, and notary wallets: (https://github.com/blur-network/dpow-blur/commit/38d8a482302a57479d1b4e174d6b74145171e6d7).

3.) All of the types, classes, etc necessary from bitcoin have been consolidated into the directory external/bitcoin (which compiles as a static library).

 I've also added a couple helper functions in src/common/hex_str.cpp for conversions between the two codebases. Converting from BTC style uint256 to cryptonote's crypto::hash is pretty simple this way, and we don't have to do any crazy type-punning.

4.) Unique ntz_txn tags & fields in the extra have been added, and have preliminarily been given a buffer of 4kB or so. (https://github.com/blur-network/dpow-blur/commit/f6deef44d41847c7e8125e40c606379cc325af27 & https://github.com/blur-network/dpow-blur/commit/6ade53a6548c983dae100ef24159548ba188c999)

5.) komodo-related DPoW functions have been built with main lines into cryptonote::core via the komodo_core class.  This class has a constructor that initializes m_core and m_p2p as references to cryptonote::core and node_server.  These are the two handlers that dictate consensus, effectively.

 - Here, core will allow us to load in state files, checkpoints, etc.  There are already placeholder functions (without bodies) for this.  You'll find all of komodo_core located in src/komodo/komodo_validation.cpp & .h

In BLUR consensus decisions begin in core and p2p as far as network communication goes.  These decisions are then finalized in src/cryptonote_core/blockchain.cpp where they are added to the blockchain, or rejected based on verification & hard fork rules

Voting for the next coin to be listed on qtrade.io has begun!

If you want to see us listed on qtrade -- vote for Blur, here: https://qtrade.io/listings

Qtrade only lists innovative projects, so they would be a great exchange to get onto, if we can muster the community support.  Voting requires an e-mail verified account.

GUI wallets have also been released for all platforms.  Grab those on the GitHub releases page as well, or via links on the website.

Blur v0.1.9.8.1 'Radiance' has been released!

Grab it here: https://github.com/blur-network/blur/releases or via the links on the website.

Please update as soon as possible, as the update patched a critical wallet vulnerability.  Please see changelog for relevant information, as well as the picture attached below.  Opening old wallet files on the new wallet will mean that your mined rewards will not show up in your wallet balance until the steps below are followed:

An update on the state of DPoW integrations for BLUR:

Porting all of the BTC-derived code is taking a while, but things are moving along smoothly... particularly as of late.  Things finally beginning to click between XMR-BTC, mentally speaking.

At the following repo you'll see some recent changes (not all have been pushed yet, as I am trying to keep that repository in a state that actually builds without treating warnings as errors): https://github.com/blur-network/dpow-blur

Among those changes that have been pushed are:

- There is now a binary that builds with the set of blur-specific bins that is titled `blur-notary-server-rpc`.  This will become the binary that will create the notarization transactions on BLUR's chain, once  the data has been written to into a raw btc transaction.
- That raw BTC data is going to be affixed to the 'extra' field of an BLUR transaction.  This subfield in the `tx_extra` will be prefixed by a leading byte of `0x05` which will be unique to notarization transactions.  I am going to attempt to keep that an authenticated field, meaning only NN secret keys will be able to create this type of transaction (ideally).
- Can't promise the authentication, since this field is not verified for content by any node (as far as consensus goes). But since we are making changes to consensus anyway, I figure its worth a shot (really just mitigates performance hit from verification happening too often).
- If you wish to compile that repo on your own you can also use the JSON-RPC calls for `notarization_data`, `height_MoM`, and `calc_MoM` to make a call to each of those three methods on the daemon.  I'll be adding documentation for these later on.
- The above RPC calls will eventually be populated with data from the komodo state files, iguana's methods for merkle tree calculations, and all that good stuff.
- The backbone of the RPC calls and the notarization server are built.  So, what's left is a matter of actually plugging these functions into the RPC calls and making sure they work properly once that's complete.

Integrations are looking like they’ll be done around the end of June. Possibly a week or two into July.

Whether coins are successful or not, people are far away and trading volume is close to zero, which makes it difficult to arouse interest.

You can follow the progress on DPoW integrations here: https://github.com/blur-network/dpow-blur. And on the projects board here: https://github.com/orgs/blur-network/projects/1

I just finished implementing the RPC calls that will enable (eventually) things like cross-chain clusters and interactions with other assetchains in komodo’s network. All of the bitcoin compatibility dependencies have been integrated and placed in a separate  “bitcoin” library.  The goal when DPoW is launched, we’re shooting for full interoperability between XMR-based chains, and KMD’s ecosystem.

The exciting part, outside of the security that will be gained with KMD’s work: This means that BTC-based and XMR-based chains will be able to communicate by simply porting the changes. Still a lot to do, but things are taking shape.

Some are accumulating, and prefer not to have too much attention on BLUR until they finish.

dPoW will be big news if it succeeds

Where did the people go?

If you missed it this past week: we have started development efforts on integrating chain security from Komodo’s DPoW, which will allow for securing BLUR with BTC through notarized transactions.

You can read about the beginnings of this collaboration here: https://komodoplatform.com/tt2019-16-synthetic-positions-prices-blockchain-financial-instruments

Please see the procedure here: https://github.com/blur-network/blur/issues/24 ...

alternatively, you will be able to open that wallet with the v0.1.7.5 release or below.  However, you need to connect to the network by using the daemon from v0.1.9.1 or newer.  Old wallets connect just fine with new daemons. It's the password handling that changed in a non-backward compatible way. When you get the wallet open using v0.1.7.5's blur-wallet-cli, you will need to type the following command:


then your daemon should connect to the wallet, and you can send the funds to a wallet created using v0.1.9.1 or newer.

Yes, on the website, under CLI Wallets. (Lock symbol)

Is there a paper wallet generator?

hello,
    please help me ,My wallet can be opened on both 0.17 and 0.175, but after updating to 0.19.5, I can't open the wallet file. I am prompted that the password is wrong. I am sure the password is correct. What do I need to do?

How to import coins from old wallets into new graphic wallets

Yes, we do. Link: https://github.com/blur-network/blur/releases/download/v0.1.9.5/blur-blockchain-bootstrap.zip

There are also instructions here: https://github.com/blur-network/blur/releases#bootstrap

Hi! Do you have a bootstrap for the old blocks? thanks

As far as the most recent changes go, the two patches of concern are within:
1.) Handling of additional tx public keys, and their (lack of) inclusion in a transaction.
2.) P2P protocols allowing transmission of any peer's host OS, along with other info, that collectively or separately could make memory timing attacks a lot easier.

Both of these have now been patched in v0.1.9.5. Prior to this, additional transaction keys were not always included in a transaction, in all scenarios where they should have been. Now, if they are present, and the boolean need_additional_txkeys is not evaluated as true, they are included as well.  This is a bit overly conservative, but we will shave the logic down to an XNOR-case in the next release.

The second fix seems to have been necessary due to what appears to be a leftover from Bytecoin.  However, it was commented out in XMR's original code.  That changed in XMR, 5 years ago, and the flag for ALLOW_DEBUG_COMMANDS appears to have been set by default ever since.  This is a bit of an issue, as the P2P commands involved with that flag are not secure, and give up a decent amount of information about the node's host computer

Some background on memory-timing attacks...  Worth noting that these are nearly impossible to defend against, but some things make them much easier, if they are known about the host computer.

Spectre and Meltdown were two recent vulnerabilities that made use of this.  Intel and AMD had to completely rethink their architecture design to mitigate.
Dan Bernstein's paper which proved these attacks' feasibility: https://cr.yp.to/antiforgery/cachetiming-20050414.pdf



Prior to their removal, the conditional flag, and associated P2P pubkey:


And the associated conditional (in one place, anyway)


Why this is dangerous:
That P2P_REMOTE_TRUSTED_DEBUG_PUB_KEY is the same as a known cipher text, that gets hashed by every daemon who connects and performs a handshake, prior to our latest update. Such is the case currently in XMR, and every fork of it, excluding BLUR.


Nodes on v0.1.9.5 no longer include this functionality.
The relevant function doing this can be found here: https://github.com/blur-network/blur/commit/482631942c187d47c02d3cd42651ad87801ccebe#diff-c02157891426370c008d7076b723128cL1416 and is called proof_of_trust

Posting here since I forgot to do so when it was initially released:

A new release for Blur v0.1.9.5 'Radiant Flux Primed' has been uploaded to github. This update is STRONGLY recommended for all nodes, as it includes privacy updates (to protect from timing attacks allowed in XMR's code, by default), as well as patching the the most recent vulnerabilities found in XMR.

The v0.1.9.5 release is backwards-compatible with nodes running v0.1.9.1.  However, nodes running v0.1.9.1 will drop connections to v0.1.9.5, if the daemon from v0.1.9.1 is the one who initiates the connection.  Otherwise, the connection is allowed if v0.1.9.5 initiates the connection.  However, an update is recommended due to old daemons not being protected against the cache-timing vector, and a couple other bugs.   Please update as soon as possible. 

You can find the changelog for the new release on the CLI tools release page.  Updated GUI's are also available here.

Note:  There is known bug in the GUI that requires starting the daemon (blurd in Mac/Linux, blurd.exe on Windows) externally for syncing.   Launching from the "Start Daemon" link in the GUI will not work.