• Forum has been upgraded, all links, images, etc are as they were. Please see Official Announcements for more information

v0.10.12.x RC4 Testing

Status
Not open for further replies.
Also, for the bloat that will come with this I think I can pull off
summary blocks. So every 10,000 blocks the masternodes would create a
summary block, it would be a giant block with every populated output
that still has funds more than dust. That should be pretty robust and
we don't have to worry about the blockchain size.
No need to ever download more than 10k blocks to be current. VERY NICE.
 
Anyone else seeing this message? That'll cause some issues :)

2014-07-23 18:19:25 CDarkSendPool::Sign - My entries are not correct! Refusing to sign. 0 entries 67 target.
Is it theoretically possible that due to a bug in darksend and/or masternode payouts to get payments from other users?

I am asking because i originally injected 21.000 DRK into my transaction spray cluster, and after 5h of forcing denominations the total balance sums up to 28.000DRK, which would mean i earned 7.000DRK through denominations... :confused:

Or someone sent 7.000 DRK to one of my wallets to confuse me... i will check the incoming transactions.
 
Is it theoretically possible that due to a bug in darksend and/or masternode payouts to get payments from other users?

I am asking because i originally injected 21.000 DRK into my transaction spray cluster, and after 5h of forcing denominations the total balance sums up to 28.000DRK, which would mean i earned 7.000DRK through denominations... :confused:

Or someone sent 7.000 DRK to one of my wallets to confuse me... i will check the incoming transactions.
Most definitely impossible.
 
Some progress from a conversation between me and Kristov. I thought it might be useful to understand what's going on behind the scenes:

---------------------------------------------------

I've been doing some more work on this and I'm thinking the client is going to strive to keep X number of each denomination in powers of two in the wallet. After each transaction occurs, it will need to possibly create new ones to replace the ones that are missing. But if you have every power of 2 in denomination form, you can make any amount once.

Something like this:


Denomination-----Pubkey----p2-----p3
0.001---------------1------2-----3
0.002---------------4------5-----6
0.004---------------7------8-----9
0.008---------------10-----11----12
0.016---------------13-----14----15
0.032---------------16-----17----18
0.064---------------19-----20----21
0.128---------------22-----23----24
0.256---------------25-----26----27
0.512---------------28-----29----30
1.024---------------31-----32----33
2.048---------------34-----35----36
4.096---------------37-----38----39

So your client will make 3x of each kind, then construct payments from these:

Payment1 for 1.024+0.004+0.001 = 1.029DRK (32+7+1)

After that your wallet has (it will refill denominations by darksend'ing):

Denomination-------Pubkey------p2------p3
0.001---------------2----------3------40
0.002---------------4----------5------6
0.004---------------8----------9------41
0.008---------------10---------11-----12
0.016---------------13---------14-----15
0.032---------------16---------17-----18
0.064---------------19---------20-----21
0.128---------------22---------23-----24
0.256---------------25---------26-----27
0.512---------------28---------29-----30
1.024---------------31---------33-----42
2.048---------------34---------35-----36
4.096---------------37---------38-----39

Next payment for 4.096+4.096+0.256 = 8.448DRK (39+37+25)

After that your wallet has:

Denomination------Pubkey p2-----p3
0.001---------------2-----3-----40
0.002---------------4-----5-----6
0.004---------------8-----9-----41
0.008---------------10----11----12
0.016---------------13----14----15
0.032---------------16----17----18
0.064---------------19----20----21
0.128---------------22----23----24
0.256---------------26----27
0.512---------------28----29----30
1.024---------------31----33----42
2.048---------------34----35----36
4.096---------------39

Here's the full list of denominations with this strategy:

1----0.001
2----0.002
3----0.004
4----0.008
5----0.016
6----0.032
7----0.064
8----0.128
9----0.256
10----0.512
11----1.024
12----2.048
13----4.096
14----8.192
15----16.384
16----32.768
17----65.536
18----131.072
19----262.144
20----524.288
21----1048.576

Also, for the bloat that will come with this I think I can pull off
summary blocks. So every 10,000 blocks the masternodes would create a
summary block, it would be a giant block with every populated output
that still has funds more than dust. That should be pretty robust and
we don't have to worry about the blockchain size.

Evan,

What about the idea of using mathmatically optimal denomination sizes? I don't know if you ever saw my post about this, but you can do MUCH MUCH better than simple powers of two to reduce the number of transactions needed (to create the denominations, the total amount required to be stored in the user's wallet, and the transactions needed to send a payment). I posted about it here about halfway down the page... https://darkcointalk.org/threads/development-updates-july-7th.1735/

There is a white paper there https://cs.uwaterloo.ca/~shallit/Papers/change2.pdf that presents the concept. If you want help figuring out the optimal denominations to use, I can easily do it for you if you supply the criteria. For example, smallest amount being 0.001, largest amount being xxx and the number of denomination sizes to optimize for. Let me know if you want a proposal from me and I'm happy to do the work.
 
I have found that my node sv02 select mpuTzSLxMQcSzgdPgs4BHxfCvTSBvWZKF4.

Updated : [07/24 03:13:31]

Code:
Type sv01 sv02 nomp
Checked 07/24 03:13:01 07/24 03:13:01 07/24 03:13:02
Current 211.99.224.173:19999:1 54.202.29.136:1 9999:1 211.99.224.173:19999:1  <--- inconsistency
blockcount 2575 2575 2575
version 91202 101203 91202
connections 14 21 11

mpuTzSLxMQcSzgdPgs4BHxfCvTSBvWZKF4 Amazon_OregonUnited States
us.png
_._.29.136-
off.gif
+
on.gif
-
off.gif
<--- inconsistency

http://tdrk.poolhash.org/blocks/currentmasternodes.txt is current masternode of sv01.
sv01 has same masternode from 2571 to 2590 (20 blocks)
 
Most definitely impossible.
Riddle solved: Someone sent 8000 DRK to my spray addresses from 9:30 to 9:45 which was distorting my balances. My script only sends amounts of 5-15 DRK :smile:

NuJ9rXv.png


Thanks to the unknown stranger :smile:

BTW: Loading and parsing a 28M wallet.dat lasts 5min on my i7 2.2GHz
 
Evan,

What about the idea of using mathmatically optimal denomination sizes? I don't know if you ever saw my post about this, but you can do MUCH MUCH better than simple powers of two to reduce the number of transactions needed (to create the denominations, the total amount required to be stored in the user's wallet, and the transactions needed to send a payment). I posted about it here about halfway down the page... https://darkcointalk.org/threads/development-updates-july-7th.1735/

There is a white paper there https://cs.uwaterloo.ca/~shallit/Papers/change2.pdf that presents the concept. If you want help figuring out the optimal denominations to use, I can easily do it for you if you supply the criteria. For example, smallest amount being 0.001, largest amount being xxx and the number of denomination sizes to optimize for. Let me know if you want a proposal from me and I'm happy to do the work.
I couldn't help myself... just did some research into optimal denominations and came to a few interesting conclusions that should be considered in the design of Darksend+:

1) Given an unlimited number of denominations, the optimal denominations to minimize the number of transactions/denominations for a system in which change is given and each denomination is used only once per transaction is exponents of three (e.g., 1, 3, 9, 27, etc.), however, this is incompatible with Darksend+, because we need a system for exact payments without making change back to the sender

2) The optimal system in which each denomination is only used once and without the use of change is in fact exponents of two (e.g., 1, 2, 4, 8, etc.), so it seems that we are on the right track with our powers of two approach.

3) However, there are some considerable downsides to using this approach
- In order to have even one set of the 21 denominations, it takes 2,097.151 DRK... an amount few are likely to ever hope to have in their wallets let alone the 6,291.453 DRK that it would take to create three full sets of denominations as proposed (thus allowing three consecutive transactions to be sent without having to wait for redenominating coins)
- Using an approach based on powers of three would drastically reduce the amount needed to create a full set (because you would need fewer denominations), but the issue would remain that almost all users will not be able to make three full sets...
- Therefore, we should use powers of two (as Kristov proposed), but this generates some real trade-offs in the way this could work practically... Consider the following scenario:

Let's say that you have a wallet with less than the needed 6,291.453 coins. Since it cannot create three copies of each denomination, the system needs to make some trade-offs. You must either keep fewer copies of the full set of denominations, or you can keep three copies, but only up to a lower figure. Let's say for example you have 2,650 DRK... you could do one of the following. In option 1, the system completes one full set of denominations before creating as much of the second set as possible, and lastly as much of the third set as possible (always starting with the lowest denomination first). In option 2, it creates three sets of coins at each denomination until it can't create the next denomination up.
EDIT: Redid the table so that it is legible.
Option 1 Option 2
Denomination Number Amount Denomination Number Amount
0.001..............3............0.003.....0.001..............3............0.003
0.002..............3............0.006.....0.002..............3............0.006
0.004..............3............0.012.....0.004..............3............0.012
0.008..............3...........0.024......0.008..............3...........0.024
0.016..............3...........0.048......0.016..............3...........0.048
0.032..............3...........0.096......0.032..............3...........0.096
0.064..............3...........0.192......0.064..............3...........0.192
0.128..............3...........0.384......0.128..............3...........0.384
0.256..............3...........0.768......0.256..............3...........0.768
0.512..............3...........1.536......0.512..............3...........1.536
1.024..............3...........3.072......1.024..............3...........3.072
2.048..............3...........6.144......2.048..............3...........6.144
4.096..............3.........12.288......4.096..............3.........12.288
8.192..............3.........24.576......8.192..............3.........24.576
16.384.............2........32.768....16.384..............3.........49.152
32.768.............2........65.536....32.768...............3........98.304
65.536.............2.......131.072...65.536...............3......196.608
131.072...........2.......262.144...131.072.............3.......393.216
262.144............2......524.288..262.144..............3.......786.432
524.288............1......534.288..524.288..............2.....1048.576
1048.576..........1....1048.576..1048.576............0...........0.000
Total......................2,637.821...................................2621.437
Non-denominated.......12.179.......................................28.563
Sending 2500 DRK ..10 coins...................................48 coins

The advantages to Option 1 are a) you can send higher-value transactions using fewer blockchain transactions (as evidenced by the example of sending 2500 DRK), b) it can denominate a higher share of the 2,650 DRK... enabling the capability to send slightly larger amounts (though depending on the exact numbers used, this can become substantial in some circumstances), and c) you can still enable three successive transactions, albeit on a smaller set of possible amounts than Option 2.

The only real advantage I see to Option 2 is that you are guaranteed to be able to send three transactions in quick succession as long as they are all below 524.288 vs. three guaranteed transactions below 16.384 for Option 1.

To me, the advantages of denominating following the approach of Option 1 far outweigh the advantages of Option 2. In fact, the only scenario in this example where option 2 is better is when you are sending three successive transactions that all fall within the range of 16.384 - 524.288.

My conclusion is that the example Evan provided, which appears to prioritize denominating 3 sets of each denomination, should be replaced with an approach that prioritizes creating as much of a first set of coins as possible before starting on the next one.
 
Last edited by a moderator:
Riddle solved: Someone sent 8000 DRK to my spray addresses from 9:30 to 9:45 which was distorting my balances. My script only sends amounts of 5-15 DRK :smile:

NuJ9rXv.png


Thanks to the unknown stranger :smile:

BTW: Loading and parsing a 28M wallet.dat lasts 5min on my i7 2.2GHz
Ah that was me, sorry for the confusion.
 
My conclusion is that the example Evan provided, which appears to prioritize denominating 3 sets of each denomination, should be replaced with an approach that prioritizes creating as much of a first set of coins as possible before starting on the next one.
Impressive work babygiraffe.

Which option do you think would work best for folks who might only keep a few hundred DRK or less in their wallet? Assuming we want to use DRK for frequent smaller transactions (shopping online etc) and keep the bulk of our DRK in masternodes or cold strorage.
 
Impressive work babygiraffe.

Which option do you think would work best for folks who might only keep a few hundred DRK or less in their wallet? Assuming we want to use DRK for frequent smaller transactions (shopping online etc) and keep the bulk of our DRK in masternodes or cold strorage.
I think the preferred option is always going to be the same, no matter how many denominations we want to support and no matter how low the person's balance. Here is what the 100 DRK scenario would look like under the two options (and assuming you were sending 75 DRK):
Denomination Number Amount Denomination Number Amount
0.001..............3............0.003.....0.001..............3............0.003
0.002..............3............0.006.....0.002..............3............0.006
0.004..............3............0.012.....0.004..............3............0.012
0.008..............3...........0.024......0.008..............3...........0.024
0.016..............3...........0.048......0.016..............3...........0.048
0.032..............3...........0.096......0.032..............3...........0.096
0.064..............3...........0.192......0.064..............3...........0.192
0.128..............3...........0.384......0.128..............3...........0.384
0.256..............3...........0.768......0.256..............3...........0.768
0.512..............3...........1.536......0.512..............3...........1.536
1.024..............2...........2.048......1.024..............3...........3.072
2.048..............2...........4.096......2.048..............3...........6.144
4.096..............2...........8.192......4.096..............3.........12.288
8.192..............2.........16.384......8.192..............3.........24.576
16.384.............2........32.768....16.384..............3.........49.152
32.768.............1........32.768....32.768...............0..........0.000
65.536.............0...........0.000...65.536...............0..........0.000
131.072...........0...........0.000...131.072.............0...........0.000
262.144............0..........0.000..262.144..............0...........0.000
524.288............0..........0.000..524.288..............0..........0.000
1048.576..........0..........0.000..1048.576............0...........0.000
Total...........................99.325......................................98.301
Non-denominated..........0.675.......................................1.699
Sending 75 DRK ..10 coins...................................12 coins

Here, the only scenario in this example where option 2 is better is when you are sending three successive transactions that all fall within the range of 1.024 - 32.768. You can easily see in scenario after scenario that the only way option 2 is better is for fairly narrow ranges of three successive transactions.
 
Last edited by a moderator:
****** PLEASE UPDATE TO 9.12.4 OR 10.12.4 *******

This is a pretty large update to the RC client.

- New column "Darksend Rounds" in coincontrol to show how secure a given input is
- Fixed a few issues causing darksend to fail. We should see many more darksends occuring now if it's fixed.
- Redid denominations to 1, 10, 100, and 500. Maybe this is too simple, but it seems effective, all change from transactions will de denominated automatically again through darksend for the next transactions. We'll see how it works.
- usemasternode option, will override active masternode (only in RC, just for testing)

Binaries (stable)
http://www.darkcoin.io/downloads/master-rc4/darkcoin-qt
http://www.darkcoin.io/downloads/master-rc4/darkcoind

RC4 Binaries ( masternodes )
http://www.darkcoin.io/downloads/rc4/darkcoin-qt
http://www.darkcoin.io/downloads/rc4/darkcoind
 
Not seeing a new Darksend Rounds column in 9.12.4 qt client? edit: my lifelong blonde moment continues - never used a non-RC version before and they've never had darksend...

Will chuck up a new MN from scratch now.
 
Last edited by a moderator:
  • Like
Reactions: jpr
Status
Not open for further replies.
Back
Top