Evan, is it correct what your other developers, like Vertoe, say? They claim this was a unilateral decision made without their input and now Vertoe has left the team.
Also, how do you respond to Vertoe leaving? It seems like a mighty setback to the overall project.
Thanks,
JL
Nope. I approached nearly everyone internally and most were for the rebranding. I missed Vertoe, but I already knew what he thought from public comments. |
|
|
|
Honestly, I always liked the DRK technology but I never invested in it just because of the name. Anything DARK, I don't want to be associated with it. This morning when I saw a change, I have put 1,5 BTC into it. You have just gotten another person on board.
I don't understand the moaning. Why not have the best of both worlds? Wider adoption that will be associated with the normal name and also underground transaction thanks to its anonymity.
People that want to use anonymous coin will use it no matter if the name is Dark, Dash or Tomato coin.
Just my 2 cents.
+1 Tomato Coin |
|
|
|
|
There seems to be some misunderstanding about the re-branding effort that I would like to clear up.
We've been watching the various conversations pop up about re-branding since the inception of the foundation. When the name "Dash" was recommended by the community, we saw there was a decent amount of support for the name. It also represented what we're attempting to accomplish with Darkcoin, something fast and private as cash. It also sounds very friendly and works as a verb.
After this the foundation started doing some research and found a patent application for the name "Dash". If this patent application was approved it means we couldn't use the name at all. Instead of approaching the community at this point and saying we were thinking about rebranding, we decided to hire a patent attorney to challenge this. We were hoping that we would be able to clear up all of the legal work before approaching the community about the name.
To challenge the patent application required that we purchase the rights to Dashcoin. We need to be able to show prior use of the name "Dash" in order to be able to challenge the application. At this point we could have approached the community with what we were doing and asked the community to fund it, but this would have created a good deal of uncertainty in the market. Instead, I funded the purchase of Dashcoin out of my own pocket, which cost a substantial amount of money. The purpose of this was incase the trademark challenge didn't work, we just would bury the project and leave it be.
If it wasn't for the patent application, this would have been much more transparent. But we were trying to protect the interests of the investors of the coin and not create unnecessary uncertainty.
|
|
|
|
If the re-branding is going to coincide with a shift away from anonymity I think the DASH dev knows something we don't, perhaps some flaw not yet disclosed to general public was discovered which is so fatal to anonymity that only re-purposing and re-braning the whole project makes sense.
Absolutely not!! Evan has been quite open since the beginning that DRK was NEVER created to serve the dark markets and illegal activity. He created Xcoin with X11, and very intelligently changed to a snappier Darkcoin - which made perfect sense at the time BTC LTC DRK It was the logical progression and a smart name change!! A year in cryptos is more than dog years. Mt.Gox seems decades ago, but in reality it was just about 1 year ago. Darkcoin has evolved into something MUCH bigger than its original premise! And the name is holding us down. Things have changed considerably, and with so much bullshit scamming/silk roads/Ulbrichs/Karpeles/Green a.k.a. Kennedy/Shreems etc etc etc... "dark" is not going to help one bit. That does NOT MEAN that a name change will change the fundamental "mission statement" made when he created XCoin originally. +1 There is NO issue with Darksend, in fact the new masternode blinding system is quite impressive. The mission statement will remain the same with the addition that we want to challenge the monopoly that Bitcoin has on the space. I think it's quite unhealthy if it grows to be the only game in town. |
|
|
|
Huge respect to crowning and snogcel for their latest git pull request... I think they must have borrowed Thor's hammer to beat that one into the QT client.  It's absolutely beautiful! Great work crowning & snogcel. For anyone wondering what we're talking about: https://github.com/darkcoin/darkcoin/pull/234 |
|
|
|
I wish there was a way to use it in conjunction with starting masternodes from cold wallets for the ultimate protection.
I agree. Currently the "cold" wallet masternode start requires exposing a 1000DRK private key to an internet connected computer. With Electrum, it is possible to use a computer with zero internet connectivity to sign transactions with a private key, then go to an online computer with a "private key-less" Electrum to broadcast them. Once we have Electrum-DRK, it might be easy to implement a masternode start in a similar fashion (and for the extra-paranoid, use a hardware wallet like Trezor on the offline computer). Given the frequency of mandatory coldwallet starts and the ever-increasing $/BTC value of those 1000DRK private keys, offline masternode starting/signing (by means of a HW wallet or an offline computer) should be a high priority, IMO. I agree too. I think this can be an important improvement to the system. I think Evan posted something like that to be implemented in the next releases. Can you Evan or someone confirm this? tnks, bump Confirmed. Offline starting of masternodes will be supported. Thanks alot for the info. This will be really useful for the community to maintain Masternodes when we are abroad, far away of our beloved cold wallets I was going to just hack start-many and start-alias to have an option to dump encoded hex with the masternode broadcast. So your cold-wallet could be a non-internet connected computer, you would just boot it up and run "masternode start-many-offline "password", then you would just take the hex dump and paste it into the online computer, like "masternode broadcast-raw encoded-message". So you'll still need physical access to the box, but it'll be a million times more secure |
|
|
|
I wish there was a way to use it in conjunction with starting masternodes from cold wallets for the ultimate protection.
I agree. Currently the "cold" wallet masternode start requires exposing a 1000DRK private key to an internet connected computer. With Electrum, it is possible to use a computer with zero internet connectivity to sign transactions with a private key, then go to an online computer with a "private key-less" Electrum to broadcast them. Once we have Electrum-DRK, it might be easy to implement a masternode start in a similar fashion (and for the extra-paranoid, use a hardware wallet like Trezor on the offline computer). Given the frequency of mandatory coldwallet starts and the ever-increasing $/BTC value of those 1000DRK private keys, offline masternode starting/signing (by means of a HW wallet or an offline computer) should be a high priority, IMO. I agree too. I think this can be an important improvement to the system. I think Evan posted something like that to be implemented in the next releases. Can you Evan or someone confirm this? tnks, bump Confirmed. Offline starting of masternodes will be supported. |
|
|
|
Okay, agreed on this.
However, as you have provided the original outputs sent by the clients we see that we at least have the correct order of them.
And the point is that I do not think that it is important to know whether it is 1,2 or 3 people. As long as we have the correct order, all three trails will eventually lead to the originator.
I am pretty sure that a transaction deanonymizer, which does this order reversal, could walk his way all the way back to the transactions where people started to denominating their funds, and get the # of users from the change outputs.
Also, what I just thought, you can surely know which outputs belong together. Its just a little bit of bruteforce work from now on.
As you said, those input belong together:
0 396016fb9d...:19 0.100001 XmEdFdQi99xwqn4SvZ47GQTgGWrwr8wGCj 72:3045...ad81 33:0322...86ef
1 7fdd4b736c...:45 1.00001 Xrw1JYmX2DgQ3GZ6g4EzpqigWrN7PFgmre 71:3044...ac81 33:039e...cee5
2 396016fb9d...:21 0.100001 XhyqpyLSRFWQrP2LuZup5XqZQ7o5qP4jvq 71:3044...8c81 33:0261...21a2
3 aa87251f58...:12 10.0001 Xg9cD2y8UVviaFLst3xESqt1gNPzfHxq25 72:3045...e881 33:02a8...6d95
4 7098889f50...:50 0.100001 XqKzxHmJT1V2p4mUFQVp4tRMoKuiY5ooTU 72:3045...ed81 33:02fe...8220
5 50ce277e21...:35 0.100001 Xged1P2SQ9Ntdb4yFxpiMHmuDCUkFbcwwS 71:3044...f881 33:02bf...eda9
6 b46f161497...:13 0.100001 Xyrz9y6J7633ZMRdsh7r5gY9ZVjQLRr9UL 72:3045...e981 33:023e...07d2
7 4a067e00c7...:59 0.100001 XgVS4zvMm4ikZDtN2DSFgSgrrTrD2w5pq5 71:3044...8081 33:03f3...d69d
8 4a067e00c7...:11 1.00001 XmAEq7k7n2spMATZbN2CpyPT6U4hNiefbr 72:3045...b981 33:03c4...ab69
9 4a067e00c7...:41 1.00001 XmnDvUgBM8kQze5RATyozfkA9bazyWQ1W3 71:3044...2181 33:021a...a289
10 b4534361c8...:23 1.00001 Xmi5ZRQUhV5eBicMYg3kLeVtgUYFtdPuco 72:3045...0381 33:0364...0ed3
11 b4534361c8...:11 0.100001 XvjDt1hjmNeX8Te2BSHMMrx794S3RW2UBh 72:3045...5681 33:03fb...f75f
12 4a067e00c7...:55 1.00001 XvaXzvnWTwHRMfzLricVyxa3FtMqJvohRR 72:3045...8881 33:02b1...33f4
13 4a067e00c7...:20 0.100001 XmHZ4DvHbBLmrHTHWCXYahp4n2SfnxWugt 72:3045...f081 33:02dd...b541
The blocks of the same color are in the correct order.
The only open question is which of the blocks comes first, which second.
For this we have 10*9*8*7*6*5*4*3*2 possibilities,
SO TO CHECK HOW THE OUTPUTS WERE ORDERED IN THE PREVIOUS TRANSACTION
... we have to think.
If the first input in the last transaction had a value of 0.10, only 5 of these blocks are candidates to come first.
... and so on!
It is really easy and in a simple python test most transactions could be uncovered this way.
You should try to build the python deanonymizer. I'd like to see what kind of results you get. |
|
|
|
It's possible that 1-3 participants are submitting funds from 4a067e00c76ccb554638c0d14d20e8f501f094ce9093fbf598c358c0835d77e5,
it's impossible to tell otherwise.
Then I just made the impossible possible, I know that these are exactly 2 people. When looking at http://explorer.darkcoin.io/tx/b649ff67a9863a9757049e6d6acc722043030b386d052f75839410f1f32bf3e5There are exactly two sorted blocks from the 4a06 transaction appearing in the sorted input list of b649ff... which do not appear directly under each other They must have been submitted from two different people at two different times. 7 4a067e00c7...:59 0.100001 XgVS4zvMm4ikZDtN2DSFgSgrrTrD2w5pq5 71:3044...8081 33:03f3...d69d
8 4a067e00c7...:11 1.00001 XmAEq7k7n2spMATZbN2CpyPT6U4hNiefbr 72:3045...b981 33:03c4...ab69
9 4a067e00c7...:41 1.00001 XmnDvUgBM8kQze5RATyozfkA9bazyWQ1W3 71:3044...2181 33:021a...a289 and 12 4a067e00c7...:55 1.00001 XvaXzvnWTwHRMfzLricVyxa3FtMqJvohRR 72:3045...8881 33:02b1...33f4
13 4a067e00c7...:20 0.100001 XmHZ4DvHbBLmrHTHWCXYahp4n2SfnxWugt 72:3045...f081 33:02dd...b541
14 4a067e00c7...:50 1.00001 XbXrsJLGZSeW839LEHQh4K8HS7AvDRXjr6 71:3044...2d81 33:0231...538f
15 4a067e00c7...:7 0.100001 XxdCZkeNWnUzkQfG13greKNXEzzQFwzxx9 72:3045...5681 33:0358...d9ea
16 4a067e00c7...:3 0.100001 XqvRbqBQMtxRdQMpJCCY3qYT62USrZtAqw 72:3045...ef81 33:0271...3602 I think you're misunderstanding the random behavior of the client. It takes multiple transactions and submits them like this. Masternode blinding makes this whole conversation meaningless though, inputs will be random. Something like this: (This isn't deanonymizing the TX, I don't know who submitted what, it's just an example) Client 1: 0 396016fb9d...:19 0.100001 XmEdFdQi99xwqn4SvZ47GQTgGWrwr8wGCj 72:3045...ad81 33:0322...86ef
1 7fdd4b736c...:45 1.00001 Xrw1JYmX2DgQ3GZ6g4EzpqigWrN7PFgmre 71:3044...ac81 33:039e...cee5
2 396016fb9d...:21 0.100001 XhyqpyLSRFWQrP2LuZup5XqZQ7o5qP4jvq 71:3044...8c81 33:0261...21a2
3 aa87251f58...:12 10.0001 Xg9cD2y8UVviaFLst3xESqt1gNPzfHxq25 72:3045...e881 33:02a8...6d95
4 7098889f50...:50 0.100001 XqKzxHmJT1V2p4mUFQVp4tRMoKuiY5ooTU 72:3045...ed81 33:02fe...8220
5 50ce277e21...:35 0.100001 Xged1P2SQ9Ntdb4yFxpiMHmuDCUkFbcwwS 71:3044...f881 33:02bf...eda9
6 b46f161497...:13 0.100001 Xyrz9y6J7633ZMRdsh7r5gY9ZVjQLRr9UL 72:3045...e981 33:023e...07d2
7 4a067e00c7...:59 0.100001 XgVS4zvMm4ikZDtN2DSFgSgrrTrD2w5pq5 71:3044...8081 33:03f3...d69d
8 4a067e00c7...:11 1.00001 XmAEq7k7n2spMATZbN2CpyPT6U4hNiefbr 72:3045...b981 33:03c4...ab69
9 4a067e00c7...:41 1.00001 XmnDvUgBM8kQze5RATyozfkA9bazyWQ1W3 71:3044...2181 33:021a...a289
10 b4534361c8...:23 1.00001 Xmi5ZRQUhV5eBicMYg3kLeVtgUYFtdPuco 72:3045...0381 33:0364...0ed3
11 b4534361c8...:11 0.100001 XvjDt1hjmNeX8Te2BSHMMrx794S3RW2UBh 72:3045...5681 33:03fb...f75f
12 4a067e00c7...:55 1.00001 XvaXzvnWTwHRMfzLricVyxa3FtMqJvohRR 72:3045...8881 33:02b1...33f4
13 4a067e00c7...:20 0.100001 XmHZ4DvHbBLmrHTHWCXYahp4n2SfnxWugt 72:3045...f081 33:02dd...b541
Client 2 14 4a067e00c7...:50 1.00001 XbXrsJLGZSeW839LEHQh4K8HS7AvDRXjr6 71:3044...2d81 33:0231...538f
15 4a067e00c7...:7 0.100001 XxdCZkeNWnUzkQfG13greKNXEzzQFwzxx9 72:3045...5681 33:0358...d9ea
16 4a067e00c7...:3 0.100001 XqvRbqBQMtxRdQMpJCCY3qYT62USrZtAqw 72:3045...ef81 33:0271...3602
17 b4534361c8...:30 10.0001 XfKGmCRBgC7ihLjyLhu3yjcvyobZNXof96 71:3044...6281 33:0317...a427
18 e0891c5fbe...:8 0.100001 XjvmB3XF6tfQW4TpZHFmmb5VpSdJfz63VU 71:3044...3881 33:0342...8b7b
19 9d96213345...:22 1.00001 XwUav8pZke2CJCBwZNQJwQVqcsVfLT9J13 71:3044...1981 33:0303...94ca
20 9d96213345...:27 10.0001 XcCvifmjfKvqNSpF83k61QyEosAQaWTRAg 72:3045...d981 33:0206...99ac
Client 3 21 8410744e1a...:57 0.100001 Xkj7CsXf9umYCTGSXH36UMV15Uyb4bFR1Z 71:3044...b981 33:0357...185e
22 e0891c5fbe...:1 0.100001 XbNQNmpa7ewvXkx6hrZH6bnJd7u5wNxB6S 71:3044...e081 33:020e...afa2
23 8410744e1a...:37 0.100001 XtDvF85gLNht6hKJpTFqgttYLimp3QfTti 71:3044...9381 33:03dc...7413
24 396016fb9d...:49 0.100001 Xs677i24pRnNFDdTXJNdwRiD9Vxx9HqUsb 72:3045...3f81 33:0313...0491
25 e0891c5fbe...:4 1.00001 XvUis97P6tRiWKCwF7cKf2DdsNfhGhEELg 72:3045...2881 33:032d...386c
Example 2: Client 1: 0 396016fb9d...:19 0.100001 XmEdFdQi99xwqn4SvZ47GQTgGWrwr8wGCj 72:3045...ad81 33:0322...86ef
1 7fdd4b736c...:45 1.00001 Xrw1JYmX2DgQ3GZ6g4EzpqigWrN7PFgmre 71:3044...ac81 33:039e...cee5
2 396016fb9d...:21 0.100001 XhyqpyLSRFWQrP2LuZup5XqZQ7o5qP4jvq 71:3044...8c81 33:0261...21a2
3 aa87251f58...:12 10.0001 Xg9cD2y8UVviaFLst3xESqt1gNPzfHxq25 72:3045...e881 33:02a8...6d95
4 7098889f50...:50 0.100001 XqKzxHmJT1V2p4mUFQVp4tRMoKuiY5ooTU 72:3045...ed81 33:02fe...8220
5 50ce277e21...:35 0.100001 Xged1P2SQ9Ntdb4yFxpiMHmuDCUkFbcwwS 71:3044...f881 33:02bf...eda9
6 b46f161497...:13 0.100001 Xyrz9y6J7633ZMRdsh7r5gY9ZVjQLRr9UL 72:3045...e981 33:023e...07d2
7 4a067e00c7...:59 0.100001 XgVS4zvMm4ikZDtN2DSFgSgrrTrD2w5pq5 71:3044...8081 33:03f3...d69d
8 4a067e00c7...:11 1.00001 XmAEq7k7n2spMATZbN2CpyPT6U4hNiefbr 72:3045...b981 33:03c4...ab69
Client 2 9 4a067e00c7...:41 1.00001 XmnDvUgBM8kQze5RATyozfkA9bazyWQ1W3 71:3044...2181 33:021a...a289
10 b4534361c8...:23 1.00001 Xmi5ZRQUhV5eBicMYg3kLeVtgUYFtdPuco 72:3045...0381 33:0364...0ed3
11 b4534361c8...:11 0.100001 XvjDt1hjmNeX8Te2BSHMMrx794S3RW2UBh 72:3045...5681 33:03fb...f75f
12 4a067e00c7...:55 1.00001 XvaXzvnWTwHRMfzLricVyxa3FtMqJvohRR 72:3045...8881 33:02b1...33f4
13 4a067e00c7...:20 0.100001 XmHZ4DvHbBLmrHTHWCXYahp4n2SfnxWugt 72:3045...f081 33:02dd...b541
14 4a067e00c7...:50 1.00001 XbXrsJLGZSeW839LEHQh4K8HS7AvDRXjr6 71:3044...2d81 33:0231...538f
15 4a067e00c7...:7 0.100001 XxdCZkeNWnUzkQfG13greKNXEzzQFwzxx9 72:3045...5681 33:0358...d9ea
16 4a067e00c7...:3 0.100001 XqvRbqBQMtxRdQMpJCCY3qYT62USrZtAqw 72:3045...ef81 33:0271...3602
17 b4534361c8...:30 10.0001 XfKGmCRBgC7ihLjyLhu3yjcvyobZNXof96 71:3044...6281 33:0317...a427
Client 3 18 e0891c5fbe...:8 0.100001 XjvmB3XF6tfQW4TpZHFmmb5VpSdJfz63VU 71:3044...3881 33:0342...8b7b
19 9d96213345...:22 1.00001 XwUav8pZke2CJCBwZNQJwQVqcsVfLT9J13 71:3044...1981 33:0303...94ca
20 9d96213345...:27 10.0001 XcCvifmjfKvqNSpF83k61QyEosAQaWTRAg 72:3045...d981 33:0206...99ac
21 8410744e1a...:57 0.100001 Xkj7CsXf9umYCTGSXH36UMV15Uyb4bFR1Z 71:3044...b981 33:0357...185e
22 e0891c5fbe...:1 0.100001 XbNQNmpa7ewvXkx6hrZH6bnJd7u5wNxB6S 71:3044...e081 33:020e...afa2
23 8410744e1a...:37 0.100001 XtDvF85gLNht6hKJpTFqgttYLimp3QfTti 71:3044...9381 33:03dc...7413
24 396016fb9d...:49 0.100001 Xs677i24pRnNFDdTXJNdwRiD9Vxx9HqUsb 72:3045...3f81 33:0313...0491
25 e0891c5fbe...:4 1.00001 XvUis97P6tRiWKCwF7cKf2DdsNfhGhEELg 72:3045...2881 33:032d...386c
Example 3: Client 1: 0 396016fb9d...:19 0.100001 XmEdFdQi99xwqn4SvZ47GQTgGWrwr8wGCj 72:3045...ad81 33:0322...86ef
1 7fdd4b736c...:45 1.00001 Xrw1JYmX2DgQ3GZ6g4EzpqigWrN7PFgmre 71:3044...ac81 33:039e...cee5
2 396016fb9d...:21 0.100001 XhyqpyLSRFWQrP2LuZup5XqZQ7o5qP4jvq 71:3044...8c81 33:0261...21a2
3 aa87251f58...:12 10.0001 Xg9cD2y8UVviaFLst3xESqt1gNPzfHxq25 72:3045...e881 33:02a8...6d95
Client 2 4 7098889f50...:50 0.100001 XqKzxHmJT1V2p4mUFQVp4tRMoKuiY5ooTU 72:3045...ed81 33:02fe...8220
5 50ce277e21...:35 0.100001 Xged1P2SQ9Ntdb4yFxpiMHmuDCUkFbcwwS 71:3044...f881 33:02bf...eda9
6 b46f161497...:13 0.100001 Xyrz9y6J7633ZMRdsh7r5gY9ZVjQLRr9UL 72:3045...e981 33:023e...07d2
7 4a067e00c7...:59 0.100001 XgVS4zvMm4ikZDtN2DSFgSgrrTrD2w5pq5 71:3044...8081 33:03f3...d69d
8 4a067e00c7...:11 1.00001 XmAEq7k7n2spMATZbN2CpyPT6U4hNiefbr 72:3045...b981 33:03c4...ab69
9 4a067e00c7...:41 1.00001 XmnDvUgBM8kQze5RATyozfkA9bazyWQ1W3 71:3044...2181 33:021a...a289
10 b4534361c8...:23 1.00001 Xmi5ZRQUhV5eBicMYg3kLeVtgUYFtdPuco 72:3045...0381 33:0364...0ed3
Client 3 11 b4534361c8...:11 0.100001 XvjDt1hjmNeX8Te2BSHMMrx794S3RW2UBh 72:3045...5681 33:03fb...f75f
12 4a067e00c7...:55 1.00001 XvaXzvnWTwHRMfzLricVyxa3FtMqJvohRR 72:3045...8881 33:02b1...33f4
13 4a067e00c7...:20 0.100001 XmHZ4DvHbBLmrHTHWCXYahp4n2SfnxWugt 72:3045...f081 33:02dd...b541
14 4a067e00c7...:50 1.00001 XbXrsJLGZSeW839LEHQh4K8HS7AvDRXjr6 71:3044...2d81 33:0231...538f
15 4a067e00c7...:7 0.100001 XxdCZkeNWnUzkQfG13greKNXEzzQFwzxx9 72:3045...5681 33:0358...d9ea
16 4a067e00c7...:3 0.100001 XqvRbqBQMtxRdQMpJCCY3qYT62USrZtAqw 72:3045...ef81 33:0271...3602
17 b4534361c8...:30 10.0001 XfKGmCRBgC7ihLjyLhu3yjcvyobZNXof96 71:3044...6281 33:0317...a427
18 e0891c5fbe...:8 0.100001 XjvmB3XF6tfQW4TpZHFmmb5VpSdJfz63VU 71:3044...3881 33:0342...8b7b
19 9d96213345...:22 1.00001 XwUav8pZke2CJCBwZNQJwQVqcsVfLT9J13 71:3044...1981 33:0303...94ca
20 9d96213345...:27 10.0001 XcCvifmjfKvqNSpF83k61QyEosAQaWTRAg 72:3045...d981 33:0206...99ac
21 8410744e1a...:57 0.100001 Xkj7CsXf9umYCTGSXH36UMV15Uyb4bFR1Z 71:3044...b981 33:0357...185e
22 e0891c5fbe...:1 0.100001 XbNQNmpa7ewvXkx6hrZH6bnJd7u5wNxB6S 71:3044...e081 33:020e...afa2
23 8410744e1a...:37 0.100001 XtDvF85gLNht6hKJpTFqgttYLimp3QfTti 71:3044...9381 33:03dc...7413
24 396016fb9d...:49 0.100001 Xs677i24pRnNFDdTXJNdwRiD9Vxx9HqUsb 72:3045...3f81 33:0313...0491
25 e0891c5fbe...:4 1.00001 XvUis97P6tRiWKCwF7cKf2DdsNfhGhEELg 72:3045...2881 33:032d...386c
|
|
|
|
I have not get a single payment on one of my nodes since the 1st of feb?
I thought an enforcement cycle lasts 4days at most, anyone facing the same?
Send me your masternode addresses and I'll check it out. |
|
|
|
How can one say they are 100x more secure now, or 90x? I mean, where is this number coming from? Probability of following Darksend through - 4 non-blinded rounds with 10 masternodes* is (10/2300)^4 == 3.5734577849564574e-10 - 4 blinded rounds with 10 masternodes is ((10/2300.0)^20)**4 == 1.1528508353537067e-189 Each round uses 20 random masternodes of 2300, so you must control 20 of 2300 four times in a row. It's super secure . Here's the new probablities for each successive round: - 1 rounds with 10 masternodes is ((10/2300.0)^20)^1 == 5.826976675086318e-48 - 2 rounds with 10 masternodes is ((10/2300.0)^20)^2 == 3.3953657171999996e-95 - 3 rounds with 10 masternodes is ((10/2300.0)^20)^3 == 1.9784716837512123e-142 - 4 rounds with 1000 masternodes is ((1000/2300.0)^20)^4 == 1.1528508353537028e-29 * attacker controlled |
|
|
|
Is everything ok with enforcement?
I have just built a new masternode and it immediately received a payment of 2.60072 DRK (around 3 hours since the start)
Everything seems to be working great, did you fund the masternode more than a few days ago? |
|
|
|
http://www.ecb.europa.eu/pub/pdf/other/virtualcurrencyschemesen.pdf"Different algorithms, i.e. the mathematical procedure for calculating and processing data (it determines the speed at which the next “block” – set of transactions – is generated, how coins are released, etc.).13 Despite being a very changeable attribute, two major algorithms can currently be identified: SHA-256 (e.g. Bitcoin, Peercoin, Namecoin, Mastercoin) and Scrypt (e.g. Litecoin, Dogecoin, Auroracoin), which could be described as an extension of the SHA-256 algorithm but requiring more physical memory. In contrast to the former, for which specialised equipment for “mining” was developed, deployed and therefore also needed to still be successful as “miner”, the latter allowed “miners” to perform their activities with regular hardware. Currently, efforts are put into using the X11 algorithm for reasons of higher cryptographic security and lower processing costs, so it is quite possible that the algorithms mentioned above will be replaced shortly. " Apparently X11 is going to replace SHA-256 and Scrypt 
|
|
|
|
|
Show Posts
