NuBurn: An Automatic Binary Stabilization System to Maintain NuBits at $1.00 Under All Market Conditions

[rodchi]

Hello everyone. My NuBurn white paper is here:
https://dl.dropboxusercontent.com/u/49303523/NuBurn.pdf

Abstract:
This paper proposes a solution to the problems of NuBits and NuShares inflation by the introduction a dual-sided coin destruction mechanism known as NuBurn.

During times where NuBits price diverged from $1.00, the NuBits protocol would temporarily allow a one direction exchange of NuBits for NuShares, or vice versa, directly within the NuBits client. NuBits or NuShares would be destroyed by sending them to a dummy address within the NuBits client software. The dummy addresses would be randomly generated, but they would have no private keys associated with them. The values held at the dummy addresses would be viewable by the NuBits network, but they could never be spent. The exchange rate would be set dynamically, and automatically, by the NuBits protocol by polling the average NuBits price on the remote exchanges (e.g. Bter), via exchange APIs. The direction of the allowed transfer would depend on whether the price of NuBits needed to be raised or lowered. The protocol would also limit the percentage of one’s wallet that he or she could exchange at one time. This would help to prevent systematic abuse.

Keywords: binary self-stabilizing system, crypto-currency, NuBits, NuShares, NuBurn, coin destruction

[masterOfDisaster]

The idea sounds good. But how do you prevent people from adjusting their client in a way that there are private keys for the dummy addresses available?
You can’t prove the absence of such private keys by protocol, right?

Once the code is open source this attack vector would be available: you send NBT or NSR to a dummy address (with a modified client that generates a private key for that address) and receive an appropriate amount of NSR or NBT.
Then you transfer the NBT or NSR from the dummy address with your private key.
Now you have NBT and NSR.

[rodchi]

The dummy address must be an invalid address, and the network would verify this as soon as the client connected. For example, If a real NuShares address has to start with an S, then a dummy NuShares address MUST NOT start with an S. If a bad actor tried to use a real NuShares address with a private key, then the network would not let him connect, and it definitely would not let him exchange NuShares for NuBits. When he or she tried to destroy NuShares or NuBits by sending them to a dummy address, the network would verify that the dummy address was an invalid address. If the address were valid, then the network would reject the transaction.

The Bitcoin network works this way right now. Valid Bitcoin addresses start with a 1 or a 3. You could make up a Bitcoin address that started with a 7, but there could be no valid private key associated with it on the Bitcoin network. You could send coins to the invalid address, but you could never spend them because they would have no valid private key. However, if you looked up the invalid Bitcoin address in a block explorer, it would correctly show the unspendable balance at the invalid address.

The client could randomly generate dummy addresses, but these dummy addresses must be invalidated by starting them with characters that are invalid for authentic addresses.

[Cybnate]

I responded to this idea here: https://www.reddit.com/r/NuBits/comments/2iznqz/nuburn_an_automatic_binary_stabilization_system/

Don’t like to cross-post

[sigmike]

We can easily burn coins or shares and add data like the address in the other currency that should be credited. We already do something similar in the parking process.

But we cannot rely on external data in the protocol, so we cannot use remote exchange prices. See my other post here: [Proposal] Solution to the problems of Asymmetrical control in NuBits