Unmoderated XC thread

[phosphorush]

Yep, constructive You guys are too much.

[1715526699]

1715526699

[AlexGR]

In that regards, DRK seems to have the same problems as XC

Wake up. DRK is trustless. It does not forward coins. It simply asks parties to sign transactions. A transaction is either signed or it is not. If it is, the coins change ownership. The node can't steal.

That's not what BTC core dev seems to think of DRK

More amusingly, what DarkCoin does is highly centralized because the software is closed— you can't get more centralized than closed source. What the actual behavior is, is anyone's guess— it's impossible to review due to it being closed— though "masternodes" does not sound like something decenteralized, it sounds like something that creates a small chokepoint which could be used to deanonymize its users, like a server based CoinJoin but worse since you have to hold a huge pile of coins to run a server.

True.

When DRK open sources then you'll only have to trust the current master node isn't logging the data. Evan is promising an improved anonymity after he fixes master nodes, although this is just a promise and is entirely vaporware at the moment. He hasn't indicated what the method would be. He was promising ring signatures before that, which would have annihilated master node spying, however it would have also annihilated the point of master nodes. Time will tell.

With XC you have to trust the mixer isn't logging the data and that the mixer won't steal your coins. Giving control of your coins to another entity is just asking for trouble.

Trust and trustless here, as I meant it, is in the context of transactions, not anonymity.

Trustless transactions = Satoshi's model.
Trusted transactions = the normal mode of 3rd party that is trusted to not tamper the transaction / run away with the money etc.

Anonymity is another issue altogether. XC is fundamentally flawed at the transaction level. The fact that its anonymity is broken is secondary.

[humanitee]

Trust and trustless here, as I meant it, is in the context of transactions, not anonymity.

Trustless transactions = Satoshi's model.
Trusted transactions = the normal mode of 3rd party that is trusted to not tamper the transaction / run away with the money etc.

Anonymity is another issue altogether. XC is fundamentally flawed at the transaction level. The fact that its anonymity is broken is secondary.

Yeah but there is so much more to 'trust' then just the transactions when it comes to anonymity so I segued into that. Phos isn't wrong, and neither are you.

[AlexGR]

Trust and trustless here, as I meant it, is in the context of transactions, not anonymity.

Trustless transactions = Satoshi's model.
Trusted transactions = the normal mode of 3rd party that is trusted to not tamper the transaction / run away with the money etc.

Anonymity is another issue altogether. XC is fundamentally flawed at the transaction level. The fact that its anonymity is broken is secondary.

Yeah but there is so much more to 'trust' then just the transactions when it comes to anonymity so I segued into that. Phos isn't wrong, and neither are you.

A monetary system that can't be trusted for its primary function (movement of money) is inherently problematic.

The anonymity part for DRK and the trust issue is more like percentages. If you DarkSend the money 5 times, and a bad actor controls like 30% of the network, it's like 0.3 x 0.3 x 0.3 x 0.3 x 0.3 = 0.25% => 99.75% that he'll miss the money flow. You play with probabilities. As you do when you use an IP obfuscation network that might reveal you anyway, whether you use DRK, or MRO.

[humanitee]

A monetary system that can't be trusted for its primary function (movement of money) is inherently problematic.

The anonymity part for DRK and the trust issue is more like percentages. If you DarkSend the money 5 times, and a bad actor controls like 30% of the network, it's like 0.3 x 0.3 x 0.3 x 0.3 x 0.3 = 0.25% => 99.75% that he'll miss the money flow. You play with probabilities. As you do when you use an IP obfuscation network that might reveal you anyway, whether you use DRK, or MRO.

DRK still doesn't handle change correctly though, which makes it super flawed at the moment (unless I missed the implementation of change denomination pools).

IMO all current implementations of anonymous coins suck. DRK has the most promise IMO, purely because of incentivized nodes, which is why I have money in it.

[slapper]

I do care.

I don't. It's clear that DRK is NOT based on anything Fedora related. Anybody with 2 brain cells and some programming experience could see that. I still think XC is a giant scam because of the dev's history and the way he grasps at straws. But if people want to throw money at it, whatever. So long as the DRK thread stays clear of them, I really don't care. I'm going to try and map their blockchain if I get some time, just for the lols. It looks like it wouldn't be too hard to do.

I don't blame you for caring though since they are such raging dicks to you over there. I thought the DRK thread was a vast echo chamber, but the XC thread is serious lols.

Yup, I have those two posts bookmarked as well and have posted about it earlier in the thread. XC is somehow a victim all of a sudden when they are forgetting that their trolling started way earlier in the DRK thread. Not surprising given the above screenshots.

[AlexGR]

A monetary system that can't be trusted for its primary function (movement of money) is inherently problematic.

The anonymity part for DRK and the trust issue is more like percentages. If you DarkSend the money 5 times, and a bad actor controls like 30% of the network, it's like 0.3 x 0.3 x 0.3 x 0.3 x 0.3 = 0.25% => 99.75% that he'll miss the money flow. You play with probabilities. As you do when you use an IP obfuscation network that might reveal you anyway, whether you use DRK, or MRO.

DRK still doesn't handle change correctly though, which makes it super flawed at the moment (unless I missed the implementation of change denomination pools).

RC4+ IIRC.

[chaeplin]

A monetary system that can't be trusted for its primary function (movement of money) is inherently problematic.

The anonymity part for DRK and the trust issue is more like percentages. If you DarkSend the money 5 times, and a bad actor controls like 30% of the network, it's like 0.3 x 0.3 x 0.3 x 0.3 x 0.3 = 0.25% => 99.75% that he'll miss the money flow. You play with probabilities. As you do when you use an IP obfuscation network that might reveal you anyway, whether you use DRK, or MRO.

DRK still doesn't handle change correctly though, which makes it super flawed at the moment (unless I missed the implementation of change denomination pools).

Correct Sir.

RC4 will fix the change issue and be pretty much untracable.

[humanitee]

A monetary system that can't be trusted for its primary function (movement of money) is inherently problematic.

The anonymity part for DRK and the trust issue is more like percentages. If you DarkSend the money 5 times, and a bad actor controls like 30% of the network, it's like 0.3 x 0.3 x 0.3 x 0.3 x 0.3 = 0.25% => 99.75% that he'll miss the money flow. You play with probabilities. As you do when you use an IP obfuscation network that might reveal you anyway, whether you use DRK, or MRO.

DRK still doesn't handle change correctly though, which makes it super flawed at the moment (unless I missed the implementation of change denomination pools).

RC4+ IIRC.

I knew it was coming, but currently it's not there. We can't act completely superior if we aren't completely superior. 
What good is DRK if you can't spend your change?

I believe chaeplin showed earlier that XC suffers from the same problem, I'd need to revisit his post but it appeared that way.

[chaeplin]

ref:

Here, I am done - I think this makes sense.

Read this while reviewing the flow chaeplin posted:
The transactions sent from the mixer (C) to the end address is of a set size (his example was 10). This is D.

He can then search the blockchain for possible candidates (value 10) via a script. Which gets us to block 28531 - this matches the 10.00 XC value. This can be linked at blocked 28533 with the mixer C - we already know C (output 9.99999).
This allows him to trace back to 28531 in the blockchain - to find the values that == 10.00 and match to a specific address - in this case: XQdBjeQtH1JGrkd2MWcXbtsRVeKHWZbnqa which is B.

You can then take all the transactions for this address B - review them and find two matching amounts that == 10 which belong to one single address. This address is A. Since this address B has never been used before this transaction - this is easy to do - and - even if it had multiple transactions - they would not all related back to one single point with one single value (10).


Just for the record, - I think this is right.
Again - I'm participating to participate - nothing else.
If my logic is flawed, let me know please, this is vexing me - because this looks right and all I get is nothing constructive back.

Thanks, this is a helpful description of what Chaeplin did.

However it does not adequately express what ATCsecure wanted tested. He wanted *proof* of a direct link, not just interestingly coincidental amounts sent and received. This is because he's testing the mixer and xnode functionality, not the multi-path feature which is yet to be implemented.

For more information, read page 356 of this thread, and also the following quotation:

I'd like to see somebody match input/outputs on the last transaction I posted...

http://cryptexplorer.com/block/1f986c7643436e328456252db9d0def76a97f9c2bae10e3ee73a9d427f8f149f


somebody is trying to make a link AFTER the fact LOL

sending 0.03 to both address's doesn't count as a LINK


but thanks for the XC's

So read page 356 and you will see that XC's implementation is successful and that Chaeplin was trying to test for the wrong thing. He returned later when ATCSECURE was gone and make his case again - yet concealed the fact that what he presents is not what's at stake here.

You have missed one thing.
I have spammed two address to create multiple input which should not occur.
Have you heard satoshi spamming ?

Anyway Xnode owner should not send any coins from Xnode.
It will create multiple input.

So:

Original address-->Mixer

Fresh Mixer address--Payee

If the Mixer owner moves coins Mixer and Fresh Mixer address can be used as inputs tying them together.

But then why earn coins if you can't use them?

Also can the  Mixer = Fresh Mixer address link be made without spamming or owner moving coins? By looking at amounts?

If a newly issued address is not holding any amount, you can move.

Mixer works like this.


Mixer issue a new address(B) to sender(A).

Sender(A) spend coins with multiple input or single input to address(B).

Mixer spend coins with multiple input or single input(C) to real payee(D).

The amounts for multiple input or single input(C) is came from Xnode wallet except address(B).


Do you remember path-through Xnode ?

Current normal bitcoin design can't control input.

http://bitcoin.stackexchange.com/questions/2527/how-can-i-control-which-coins-to-spend-in-a-transaction.


Address(B) is holding some coins. This will be used for other payee.


If there are lots of transactions, Xnode will hold lots of Address(B) thing.


If you spend it, lots of Address(B) thing will be used as multiple input.

Hard link created.

EDIT:

Code:

sendfrom <fromaccount> <toX11Coinaddress> <amount> [minconf=1] [comment] [comment-to]
sendmany <fromaccount> {address:amount,...} [minconf=1] [comment]
sendtoaddress <X11Coinaddress> <amount> [comment] [comment-to]

EDIT:
https://en.bitcoin.it/wiki/Accounts_explained

Code:

Sending
The sendfrom method sends coins and debits the specified account. 
It does **not** change Bitcoin's algorithm for selecting which coins in the wallet are sent
-- you should think of the coins in the wallet as being mixed together when they are received. 
There is no way to ask Bitcoin to "create a payment transaction 
using the coins received from these previously received transactions" 
without using the raw transactions API(which is not part of the account system.)

The sendtoaddress method works like sendfrom, but always debits the default account.

The send will fail if the account has insufficient funds, with two exceptions:

 - 'sendtoaddress' always succeeds if there are sufficient funds in the
   server's wallet.  For example, if your wallet account balances were 100 BTC in account
   'foo' and 0 BTC in the default account, then the balances after sendtoaddress
   1PC9aZC4hNX2rmmrt7uHTfYAS3hRbph4UN 10.00 would be 100 in account 'foo' and -10.00 in
   the default account (and the overall server balance would go from 100 to 90 BTC).  On
   the other hand, using 'sendfrom' to send from the default account with a zero balance
   will fail with message "Account has insufficient funds".

 - The check for sufficient funds is done before paying transaction fees (if any); if a
   transaction fee is needed, and there are sufficient funds in the wallet, then the
   transaction fee will be paid and debited from the account.  For example, if account
   'foo' contains 10 bitcoins, you sendfrom foo 15VjRaDX9zpbA8LVnbrCAFzrVzN7ixHNsC 10,
   and the transaction costs 0.01, 'foo's balance will be -0.01 bitcoins.

[ballzdeep]

So much dark clowns, like hyenas...

[child_harold]

https://i.imgur.com/l653XP1.png

https://i.imgur.com/P4s9zCy.png

I do care.

I don't. It's clear that DRK is NOT based on anything Fedora related. Anybody with 2 brain cells and some programming experience could see that. I still think XC is a giant scam because of the dev's history and the way he grasps at straws. But if people want to throw money at it, whatever. So long as the DRK thread stays clear of them, I really don't care. I'm going to try and map their blockchain if I get some time, just for the lols. It looks like it wouldn't be too hard to do.

I don't blame you for caring though since they are such raging dicks to you over there. I thought the DRK thread was a vast echo chamber, but the XC thread is serious lols.

SERIOUSLY - where the F*CK do u get off saying shit like this?

Prove it or get ready for a defamation case brosef

[Propulsion]

https://i.imgur.com/l653XP1.png

https://i.imgur.com/P4s9zCy.png

I do care.

I don't. It's clear that DRK is NOT based on anything Fedora related. Anybody with 2 brain cells and some programming experience could see that. I still think XC is a giant scam because of the dev's history and the way he grasps at straws. But if people want to throw money at it, whatever. So long as the DRK thread stays clear of them, I really don't care. I'm going to try and map their blockchain if I get some time, just for the lols. It looks like it wouldn't be too hard to do.

I don't blame you for caring though since they are such raging dicks to you over there. I thought the DRK thread was a vast echo chamber, but the XC thread is serious lols.

SERIOUSLY - where the F*CK do u get off saying shit like this?

Prove it or get ready for a defamation case brosef

That sounds like a personal threat. Someone should report the above comment.

[child_harold]

https://i.imgur.com/l653XP1.png

https://i.imgur.com/P4s9zCy.png

I do care.

I don't. It's clear that DRK is NOT based on anything Fedora related. Anybody with 2 brain cells and some programming experience could see that. I still think XC is a giant scam because of the dev's history and the way he grasps at straws. But if people want to throw money at it, whatever. So long as the DRK thread stays clear of them, I really don't care. I'm going to try and map their blockchain if I get some time, just for the lols. It looks like it wouldn't be too hard to do.

I don't blame you for caring though since they are such raging dicks to you over there. I thought the DRK thread was a vast echo chamber, but the XC thread is serious lols.

SERIOUSLY - where the F*CK do u get off saying shit like this?

Prove it or get ready for a defamation case brosef

That sounds like a personal threat. Someone should report the above comment.

It is not my place to make this threat. I am not HE who is being defamed.
LOL - yeah - report it u piece of smeg

[adhitthana]

With XC you have to trust the mixer isn't logging the data and that the mixer won't steal your coins. Giving control of your coins to another entity is just asking for trouble.

Thansk I appreciate your (and others input here)
So..with DRK the nodes merely witness the change of ownership and verify it?
But with a mixer the coins pass into the mixer (rather than merely being witnessed) and then have to be "allowed" out the other end?
Can you expand?

1.Where exactly is the "mixer"?

2.If the source is open, then would that mean coins could not be stolen?

3.The developer of XC stated "mixers don't steal coins".....but you seem to think they can? So how would a mixer steal coins?

[chaeplin]

With XC you have to trust the mixer isn't logging the data and that the mixer won't steal your coins. Giving control of your coins to another entity is just asking for trouble.

Thansk I appreciate your (and others input here)
So..with DRK the nodes merely witness the change of ownership and verify it?
But with a mixer the coins pass into the mixer (rather than merely being witnessed) and then have to be "allowed" out the other end?
Can you expand?

1.Where exactly is the "mixer"?

2.If the source is open, then would that mean coins could not be stolen?

3.The developer of XC stated "mixers don't steal coins".....but you seem to think they can? So how would a mixer steal coins?

It's simple.

You send coins to a address issued by mixer and mixer has private key of the address issued.

[benthach]

With XC you have to trust the mixer isn't logging the data and that the mixer won't steal your coins. Giving control of your coins to another entity is just asking for trouble.

Thansk I appreciate your (and others input here)
So..with DRK the nodes merely witness the change of ownership and verify it?
But with a mixer the coins pass into the mixer (rather than merely being witnessed) and then have to be "allowed" out the other end?
Can you expand?

1.Where exactly is the "mixer"?

2.If the source is open, then would that mean coins could not be stolen?

3.The developer of XC stated "mixers don't steal coins".....but you seem to think they can? So how would a mixer steal coins?

It's simple.

You send coins to a address issued by mixer and mixer has private key of the address issued.

so how mixer steal it? isn't the mixer program to mix/forward the coins? from what i understand you think mixer can just keep/steal the coin or perhaps forwards to different address? but how?

[chaeplin]

With XC you have to trust the mixer isn't logging the data and that the mixer won't steal your coins. Giving control of your coins to another entity is just asking for trouble.

Thansk I appreciate your (and others input here)
So..with DRK the nodes merely witness the change of ownership and verify it?
But with a mixer the coins pass into the mixer (rather than merely being witnessed) and then have to be "allowed" out the other end?
Can you expand?

1.Where exactly is the "mixer"?

2.If the source is open, then would that mean coins could not be stolen?

3.The developer of XC stated "mixers don't steal coins".....but you seem to think they can? So how would a mixer steal coins?

It's simple.

You send coins to a address issued by mixer and mixer has private key of the address issued.

so how mixer steal it? isn't the mixer program to mix/forward the coins? from what i understand you think mixer can just keep/steal the coin or perhaps forwards to different address? but how?

Shutdown computer, lock wallet, diconnect network, power failure.

Mixer program should/will mix/forward the coins.

Owner of the mixer is problem..

Do you know that mixer takes input/coins and waits at least 2 ~ 3 more blocks confirmation before forwards the coins.

3.The developer of XC stated "mixers don't steal coins".....but you seem to think they can? So how would a mixer steal coins?

True, People steal coins.

[benthach]

With XC you have to trust the mixer isn't logging the data and that the mixer won't steal your coins. Giving control of your coins to another entity is just asking for trouble.

Thansk I appreciate your (and others input here)
So..with DRK the nodes merely witness the change of ownership and verify it?
But with a mixer the coins pass into the mixer (rather than merely being witnessed) and then have to be "allowed" out the other end?
Can you expand?

1.Where exactly is the "mixer"?

2.If the source is open, then would that mean coins could not be stolen?

3.The developer of XC stated "mixers don't steal coins".....but you seem to think they can? So how would a mixer steal coins?

It's simple.

You send coins to a address issued by mixer and mixer has private key of the address issued.

so how mixer steal it? isn't the mixer program to mix/forward the coins? from what i understand you think mixer can just keep/steal the coin or perhaps forwards to different address? but how?

Shutdown computer, lock wallet, diconnect network, power failure.

Mixer program should/will mix/forward the coins.

Owner of the mixer is problem..

Do you know that mixer takes input/coins and waits at least 2 ~ 3 more blocks confirmation before forwards the coins.

3.The developer of XC stated "mixers don't steal coins".....but you seem to think they can? So how would a mixer steal coins?

True, People steal coins.

you sound like mixer could take minutes or even days to mix coins. i though this done instantly? it just pass through when wallet is on then pass it to blockchain? i used to think there is no time to even turn off computer during this instant mix. but hey perhaps mixers take minutes or even days like you though?

[chaeplin]

With XC you have to trust the mixer isn't logging the data and that the mixer won't steal your coins. Giving control of your coins to another entity is just asking for trouble.

Thansk I appreciate your (and others input here)
So..with DRK the nodes merely witness the change of ownership and verify it?
But with a mixer the coins pass into the mixer (rather than merely being witnessed) and then have to be "allowed" out the other end?
Can you expand?

1.Where exactly is the "mixer"?

2.If the source is open, then would that mean coins could not be stolen?

3.The developer of XC stated "mixers don't steal coins".....but you seem to think they can? So how would a mixer steal coins?

It's simple.

You send coins to a address issued by mixer and mixer has private key of the address issued.

so how mixer steal it? isn't the mixer program to mix/forward the coins? from what i understand you think mixer can just keep/steal the coin or perhaps forwards to different address? but how?

Shutdown computer, lock wallet, diconnect network, power failure.

Mixer program should/will mix/forward the coins.

Owner of the mixer is problem..

Do you know that mixer takes input/coins and waits at least 2 ~ 3 more blocks confirmation before forwards the coins.

3.The developer of XC stated "mixers don't steal coins".....but you seem to think they can? So how would a mixer steal coins?

True, People steal coins.

you sound like mixer could take minutes or even days to mix coins. i though this done instantly? it just pass through when wallet is on then pass it to blockchain?

Check my analysis.
There are always 2 ~ 3 blocks difference.
(oh even 11 ~ 15 blocks difference, this one cause path-through. patched, how, once again 2 ~3 blocks.....)
(at first 5 ~ 6 blocks)

Why ? to prevent double spending. Can't be instantly.
Mixer risks - balance situation.
If a block is orphaned, sender spend the coins again.