Quote from: Profetu on June 12, 2014, 03:57:11 PM

Quote from: chaeplin on June 12, 2014, 03:47:45 PM

Quote from: synechist on June 12, 2014, 03:34:35 PM

Quote from: sukottosan_d on June 12, 2014, 01:17:45 PM

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:

Quote from: atcsecure on June 11, 2014, 09:44:11 PM

Quote from: atcsecure on June 11, 2014, 09:42:17 PM

Quote from: atcsecure on June 11, 2014, 09:13:28 PM

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 [minconf=1] [comment] [comment-to]
sendmany {address:amount,...} [minconf=1] [comment]
sendtoaddress [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.