[Passed] Motion to provide seed funding for B&C Exchange - a decentralized exchange built on the Peershares platform

[sigmike]

The seed nodes I manage have 35-40 connections and are at height 40750. You may be connected to bad nodes. Try shutting down the client, removing addr.dat and starting it again.

[tomjoad]

We are in the process of building a block explorer which will hopefully help make problem-solving in the future easier too. It should be ready in the near future.

[mhps]

Please make a client with coincontrol. From reading debug.log I got the impression that the BKS in the wallet re not in many 1 BKS outputs in the address. (NSR are in many 10k NSR outputs)

[sigmike]

Please make a client with coincontrol.

The client has coincontrol.

From reading debug.log I got the impression that the BKS in the wallet re not in many 1 BKS outputs in the address.

The initial distribution may have been done with a larger splitshareoutputs. But the outputs should be split as they find new blocks.

[mhps]

The client has coincontrol.

My bad. I forgot I had to enable it.

But the outputs should be split as they find new blocks.

I see lines like this in debug.log after a block is found

WalletUpdateSpent found spent unit 6.1189shares …

Shouldn’t the 6.1189 in this case be something like 1.01 ?

[sigmike]

Shouldn’t the 6.1189 in this case be something like 1.01 ?

It takes some time, you may still have larger outputs. When new blocks are created the output split is limited to 5 output to avoid generating too large CoinStakes.

[mhps]

When new blocks are created the output split is limited to 5 output to avoid generating too large CoinStakes.

I just checked with coincontrol and see there is no output greater than 2 shares in my wallet. Does this mean from now on the debug line above should have the “unit xxxshares” number no greater than 2? Just trying to understand …

[sigmike]

Actually this message uses the GetCredit method on the transaction which returns the sum of all the outputs considered yours. So the message is wrong because what was found spent is a specific output, not the entire transaction. It’s legacy code from bitcoin (where receiving more than one output in a single transaction is much less common) that has probably been fixed since the peercoin fork.

[mhps]

Thanks for the explanation. I do also see 1.01 in many cases (I don’t have an address of 1 bks).
I don’t remember seeing sum of all outputs in an address in this situation in nu debug.log.

[mhps]

It’s legacy code from bitcoin (where receiving more than one output in a single transaction is much less common) that has probably been fixed since the peercoin fork.

I can confirm that the problem is still there, and in te particular case which I just checked, the amount is the original amount before any minting happened (there have already been 20 in that address).

[sigmike]

I don’t remember seeing sum of all outputs in an address in this situation in nu debug.log.

It’s not the sum of all outputs of an address, but the sum of all outputs of a transaction.

I can confirm that the problem is still there

Yes it’s still there. I meant it’s also in Peercoin and this code is actually from Bitcoin (and I guess it’s been fixed in bitcoin since then, but I haven’t cheked).

[crypto_coiner]

Yes it’s still there. I meant it’s also in Peercoin and this code is actually from Bitcoin (and I guess it’s been fixed in bitcoin since then, but I haven’t cheked).

How can we have it fixed immediately for Nu?

[mhps]

How can we have it fixed immediately for Nu?

Nu doesn’t seem to have the problem. I only see bcexchange has it. If it’s only a message problem it perhaps does not have very high priority to fix.

[crypto_coiner]

Bcexchange is a fork of Nu which is a fork of Peercoin and Bitcoin - I have noticed several technical glitches (from the conversations on discuss.nubits.com) on the client (balance) coming from the bitcoin code (not really a bug, as sigmike said)
Was wondering when and how best to fix that.

[sigmike]

I also think it’s low priority so I won’t spend time on it for now. But the fix is very easy and the code is open, so feel free to create a pull request.

[crypto_coiner]

Will try -

[cryptog]

Another question:

here ( https://bitcointalk.org/index.php?topic=1033773.msg11603021#msg11603021 ), JL says " I have discussed how B&C can be used to guarantee Nu liquidity for a period of time and that is not part of the initial implementation."

Can someone detail what it would take to guarantee Nu Liquidity in B&C in terms of software and how much funding it would require in terms development budget?

[JordanLee]

Another question:

here ( https://bitcointalk.org/index.php?topic=1033773.msg11603021#msg11603021 ), JL says " I have discussed how B&C can be used to guarantee Nu liquidity for a period of time and that is not part of the initial implementation."

Can someone detail what it would take to guarantee Nu Liquidity in B&C in terms of software and how much funding it would require in terms development budget?

I haven’t spent the time to refine the design, but it would be something like this:

1. Create a new message type, which we might call a proxy lock. This is a message signed from a BKC address (aka B&C Exchange account) which has one or more deposit addresses associated with it. It would contain the following info: deposit address to be locked, the duration of the lock, and the proxy address designated to control the funds (most likely a multisig address). In practice, when providing liquidity, two deposit addresses will have a proxy lock placed on them, one for each side of the trade pair.

2. Implement a protocol rule that invalidates order and withdrawal messages signed by the owner of an account in regard to a deposit address that has an active proxy lock on it. This means that an owner of funds intended for liquidity can choose to irrevocably have them locked (unresponsive to messages from him to move the funds) for a configurable period of time.

3. Implement another protocol rule giving the proxy address chosen by the account holder in his proxy lock address message control over the funds. The holders of the multisig address given control over placing orders may be reputed signers or they may not. They will follow rules for entering liquidity providing orders using an enhanced version of NuBot. If an event occurs that makes providing liquidity more risky so that liquidity providers would prefer to withdraw their funds from liquidity operations, these funds will continue providing liquidity. The multisig signers don’t care about a risk of loss of funds if the peg looks shaky, because they aren’t their funds. They have promised to and are getting paid to place liquidity providing orders, and it is in their interest to continue doing so even in the presence of a liquidity or network crisis.

I’m not sure what this would cost to implement at the moment. I would need to work out more detailed plans. I do feel comfortable saying it would cost tens of thousands of NuBits. We could probably create the protocol changes for 10k or 20k, but then I would need to defer to @desrever or @woolly_sammoth to determine exactly what changes will need to be made to NuBot and how much that might cost. Also, a method to coordinate signing of orders among multisig members must be provided. There are several options that need additional evaluation.

For clarity, I will repeat this feature is not currently funded, so it is not promised.

This is a specific type of escrow service B&C Exchange could offer. I suspect the potential for B&C Exchange to provide escrow services (including reversible transactions) is generally under appreciated by shareholders at this time.

[crypto_coiner]

This is a specific type of escrow service B&C Exchange could offer.

We could probably create the protocol changes for 10k or 20k,

Could it be covered by the ongoing fund raising if that reaches the budget for it?

[cryptog]

Tks for detailing what you are envisioning about how B&C could be used to contribute substantially to a steady, large and secure liquidity regarding NuBits.

I understand that such B&C’s protocol refinement’s implementation will not be done before the basic version is released…which will not be the case for several months from no, but how many months?

I know you cannot specify any concrete figures but my feeling is that we would be able to see the first version of B&C be released before the end of the year.

Here, you say the B&C is simpler to implement than Nu whose development took 8 months.
I feel I can speculate that you would take less than 6 month to implement B&C, starting from beginning of July.