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.
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)
The client has coincontrol.
The initial distribution may have been done with a larger splitshareoutputs
. But the outputs should be split as they find new blocks.
My bad. I forgot I had to enable it.
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 ?
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.
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 âŚ
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.
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.
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).
Itâs not the sum of all outputs of an address, but the sum of all outputs of a transaction.
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?
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.
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.
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.
Will try -
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:
-
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.
-
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.
-
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.
Could it be covered by the ongoing fund raising if that reaches the budget for it?
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.
IMPORTANT
Another thief is attempting to conduct fraudulent fundraising using the B&C Exchange name: https://www.reddit.com/r/CryptoCurrency/comments/3ge98h/bitcointalk_decentralized_exchange_ipo/
They have also listed the fake announcement in these other subreddits:
https://www.reddit.com/r/BitcoinMining/comments/3geahj/bitcointalk_decentralized_exchange_ipo/
https://www.reddit.com/r/BitcoinBeginners/comments/3gebt9/bitcointalk_decentralized_exchange_ipo/
https://www.reddit.com/r/BitcoinMarkets/comments/3gemzr/bitcointalk_decentralized_exchange_ipo_offering/
Please downvote and report these threads. Theyâve renamed it the âBitcointalk Decentralized Exchangeâ at the top but neglected to delete âB&C Exchangeâ from the body of the message.
We will stress again and again: we will only sell BlockShares through the BitMessage and email address listed in our original announcement on Bitcointalk.