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

October 2015 Budget Proposal

First of all, regardless of how exactly the winner is chosen or how often one is declared, I think we have to make sure what exactly we incentivize and how we can avoid incentiviztation of things we do not want (like more bloat).
I Think the expected return needs to be less than 1. So for every 1 DASH that averagely gets paid as a collateral while mixing, there needs to be less (max. the equal amount of) DASH in the winner pool.
That way, there would be no incentive to game the system, because you cannot win anything. Sure, you could still try your luck, but there other, more enjoying games in the crypto-space to do just that.
The problem would be that one had to track the mixing attempts that are eligible for potential collateral payment. Thats a lot harder than just looking at the transactions, yet I think it's necessary in order to not make the expected profit go above 1.



Regarding unlinkability... well, theres always something an output can be linked to, and often that completely irrelevant for anonymity. I think the important thing is that the funds cannot be traced back to the original source, which I generally refer to as traceability. Maybe we mean the same thing though :)
I am going to assume the algorithm used for the lottery cannot trace coins through multiple DS rounds (because that would break DS in itself).
So we'll have to look at every output and determine for it separately if it is eligible for the jackpot or not. The winner will get the funds to the corresponding address.
That address is now containing the DS denomination and the lottery reward. If this was the last DS-round, the DS denom will remain there in order to eventually be spend and so does the lottery reward.
This can lead to problems if the lottery reward is spend somewhere for shopping (it cannot be used in a DS Tx anyway before mixing), while the DS denom is used somewhere else via Darksend.
Now my first idea was to reset the DS dounds of the denomination in question and just do some additional rounds. While this would work if the reward was already paid, in this proposal, the reward isn't paid right away. Say the DS denom has already been used and now the lottery reward gets paid and the user uses it for shopping, then whatever info he enters at wherever he is shoping is linked to the DS Tx he did BEFORE the reward was paid.

This, btw, is also an attack that can be used to de-anonymize DS Transactions. I explain:
Person A uses mixed coins to pay for something. The receiver of the Coins, Person B (or anyone else observing the Tx)B now sends an amount X to one of the input addresses of the DS-Tx in question.
Person A receives those funds as non-DS funds and in case he doesnt mix again but just use it somewhere, person B can now trade the Coins of which he knows they belong to the same person that made the DS-Tx in question.


And since the thread currently seems to be all about faster mixing, I got several proposals that might speed things up:

First of all, we take so much effort splitting our coins into different denominations and mix them just to eventually recombine them for a payment. But why? Technically, we do not have to recombine them for a payment.
For the DS Transaction, instead of just sending a single receiving address, the receiver could send a unlimited amount of addresses of the form of a public key seed similar to what hierarchical deterministic wallets use for watch-only copies that do not have any private keys or seeds thereof, but can calculate any amount of receiving addresses to which the private keys can be generated by the same private seed.
For now, i will call this an "HDPS", Hierarchical Deterministic Payment Stream.
How this would work in practice:
The receiver sends the sender the required payment information, which the sender enters into the client and then sends the money (via DS Tx). The difference is that instead of sending a receiving address, and HDPS public seed is sent (which will look similar to an address, a bunch of seemingly random numbers and letters).
Just as with addresses, the receiver would have the corresponding HDPS private seed, which can create all the private keys associated with all the addresses that are generated from all the public keys generated by the public seed.

The pros of this:
- the seeds would never show up on the blockchain
- an outside observer could, in most cases, not tell if this is a mixing round or a Payment, which makes tracing even harder
- the client could be programmed to make it even harder to tell the difference between Payment Tx or DS Tx pretty easily, making is almost always impossible to tell the difference.
- DS denominations won't have to be recombined in order to do a payment
- when mixing the incoming funds, no initial denomination creation transaction is required (therefore reducing bloat)
- there wouldn't be any leftovers when when starting the mixing process with HDPS-received funds
- the overpayment that is common with DS Transactions would go to the receiver instead of the miners. This is good because if incentivizes DASH acceptance (you will almost always get a little extra) [I admit this is not a huge pro, just listing it :)]


The cons:
I honestly don't see any besides the work required to implement it.

So how can this speed up DS mixing?
Well, it's possible to use HDPS' in an actual DS Tx, combining the 2. This would make is impossible for an outside observer to sell which funds are being mixed and which funds and being used for a payment in that one Tx.
It would provide extra liquidity for mixing and extra traceability protection for payments.

And I got another one... with HDPS making in unnecessary to every have non-denominated outputs and it being basically a big sea of denominations, one could mix coins with itself. Just imaging you make several denominations and a few are mixing at a time. So instead of always doing it via a masternode, the client could sometimes just throw in an extra round with a few of ones own coins. No other people needed, once your own coins are reasonably mixed, mixing them just with themselves wont look any different than an actual mixing round. The difference being that it takes close to no time to do it.
If you want to do 8 rounds and do 2 self-mixing rounds and 6 normal ones, thats already an about 25% speed increase. With only a single one thats already an around 12,5% increase.


Alright, this got longer than expected... again :)

Oh, and sorry for not having been that active in the DASH community within the last few months.
Wow! Thank you for such an extended response!

Regarding HDPS: sounds a lot like https://github.com/bitcoin/bips/blob/master/bip-0047.mediawiki + denominations if I got you idea, right?
 
Since I haven't been that active in this community the last few months, can you update me regarding the DS replacement?

I think this is ONE of the BIG reveals - might have to wait a bit before we get a lot of details but I'm still putting my trust in Evans judgement on this
- I think he's done pretty good so far....
 
1.) I think we can use trusted members of the community. Actually, of all of the people that have applied to be liquidity providers, many of them are trusted members, so we have our pick of people.
2.) What if we just have 2 liquidity providers instead? Mixing takes 3 participants to begin, therefore they will never be able to just mix with each other.
3.) Is it? If they spend $15-20 a month in fees (which is quite possible) and spend 3 hours a month monitoring it they're making about $10/ho, which is a normal rate in the US
1) Yep, to trust them is the only way (i.e. no way to prove as I said before ;) )
2) running 2 of them should work I guess
3) Even with more aggressive settings (multiple mixing session per block) it was ~2.5 DASH/month but that could be because some large pool :rolleyes: still haven't updated to .53 where we have dstx prioritization. So yeah, these fees can be higher.

Btw, liquidity providers only mix once at every 15 blocks at their best settings, not sure if running them that way will affect mixing speed a lot. Thoughts?
 
1) Yep, to trust them is the only way (i.e. no way to prove as I said before ;) )
2) running 2 of them should work I guess
3) Even with more aggressive settings (multiple mixing session per block) it was ~2.5 DASH/month but that could be because some large pool :rolleyes: still haven't updated to .53 where we have dstx prioritization. So yeah, these fees can be higher.

Btw, liquidity providers only mix once at every 15 blocks at their best settings, not sure if running them that way will affect mixing speed a lot. Thoughts?

Mixing only every 15 blocks would still be an improvement on what I've had with denominations of 100 at times in the past.

If there are only going to be 2 liquidity providers, what would be the optimum amount of Dash for them to have to mix? Will the liquidity providers' names be listed in the public forums? I imagine the community would like to know who the LPs will be, to judge for themselves whether it was a good choice but at the same time potentially a security threat as they may be corruptible.
 
Mixing only every 15 blocks would still be an improvement on what I've had with denominations of 100 at times in the past.

If there are only going to be 2 liquidity providers, what would be the optimum amount of Dash for them to have to mix? Will the liquidity providers' names be listed in the public forums? I imagine the community would like to know who the LPs will be, to judge for themselves whether it was a good choice but at the same time potentially a security threat as they may be corruptible.

No corruption here...
I'll have nearly 1200DASH to run on if chosen...
Not gonna use a PI - I have a stand alone Lappy ready and waiting :-D
(it will do nothing but Mix)


edit: If I can get your support - like this Post
 
Last edited:
Are you refering to the whitepaper presentation in Amsterdam, it is October the 7th, yes ?

the Bitcoin event where Dash will be represented is indeed October the 7th but it will not be exclusively about these two whitepapers. Evan mentioned that the whitepapers will be presented seperately on some undisclosed date.
 
the Bitcoin event where Dash will be represented is indeed October the 7th but it will not be exclusively about these two whitepapers. Evan mentioned that the whitepapers will be presented seperately on some undisclosed date.

Correct, but he also stated he would lay some of the groundwork on this meeting. The White Papers are important (Im actually dying to read them) but I also would like to hear what new direction we will be going in as Evan has signaled we are in a transition phase. I hope he makes those points then,

Pablo.
 
So what else is on, should I know about more dates, I am just about to book a flight!

With regards to 7th of October :

http://www.meetup.com/BitcoinWednesday/events/222357855/

This conference will feature international specialists on:

* Financial Instruments Based on the Blockchain and Distributed Autonomous Applications
* Privacy and Anonymity in Digital Currency Transactions

I think i read somewhere that both Evan and some other members of the Dev Team (Holger ?) are getting the opportunity to talk there about Dash's view on above points.
When the white papers get announced is anyone's guess, only the dev-team knows that.
 
With regards to 7th of October :

http://www.meetup.com/BitcoinWednesday/events/222357855/

This conference will feature international specialists on:

* Financial Instruments Based on the Blockchain and Distributed Autonomous Applications
* Privacy and Anonymity in Digital Currency Transactions

I think i read somewhere that both Evan and some other members of the Dev Team (Holger ?) are getting the opportunity to talk there about Dash's view on above points.
When the white papers get announced is anyone's guess, only the dev-team knows that.
I think the testing comes first before the publishing of the white paper... Probably around the same time of the release of v.13.
 
Hmmm, I distinctly remember Evan saying it would be Amsterdam on Nov. 7th; looks like I was wrong :).

Pablo.
 
Evan said in one of his posts it would be Nov 7th :D
He also said those whitepapers will not be revealed in Amsterdam.
 
Hmmm, I distinctly remember Evan saying it would be Amsterdam on Nov. 7th; looks like I was wrong :).

Pablo.
Evan has since said that there would be simply too much new information to release all at once, a more controlled release of information would be more effective in this situation, and would keep the spotlight on us longer.

A "What's next?" type of deal.
 
Evan said in one of his posts it would be Nov 7th :D
He also said those whitepapers will not be revealed in Amsterdam.
As a tester, i would love to tell you, "BAZINGA!" Because we testers are so used to Evan's mixups of version numbers, dates.... and i'm sure us the long timer testers knew it was another of his mixups... :tongue::tongue::tongue:

upload_2015-9-24_13-12-15.png
 
Back
Top