Quote from: TingCoin on September 16, 2014, 09:05:31 PM

Quote from: synechist on September 16, 2014, 03:20:45 PM

Quote from: TingCoin on September 16, 2014, 02:05:18 PM

Hey,

Thanks for the response

. Yeah I've read that doc (multiple times) and basically I just want to know the detailed process of what happens to "private payments". What I need confirming is:

"There might not be enough nodes making private payments at a given time, causing transactions to wait or be cancelled". This leads me to believe that ONLY nodes (node being, online wallet client) making private payments at the same time as you (and XMixers) are involved in forwarding the fragments? Or is every node involved? This definitely needs confirming first and foremost.

Yes, if a user isn't sending XC at a given time then his/her Xnode will not participate in a private transaction.
But if a user runs an Xmixer it will be available to participate whenever there aren't enough normal Xnodes for a given transaction.

Quote

When you send a private payment, what happens to it? Is it broken down in to smaller fragments (how many exactly, a random number depending on the size of the TX or what?) and sent to other online wallets (whose balances cover the size of the fragment of course I assume).

Yes when you send a private payment, it is broken into fragments, which are each sent to other Xnodes (or Xmixers if necessary).
The algorithm for fragmenting randomises the fragment size and the number of fragments.
The balances of Xnodes mixing a transaction will need to be greater than or equal to the sum of some (not all) other fragments in the transaction.

Quote

Then when a node (online wallet) receives a fragment, what happens there?: [/li][/list]
- Do the coins contained in that fragment get "tumbled" with the wallet balance of the node, or just get forwarded to another node?

Neither actually. The mixing is a lot more sophisticated.
- It's roughly a group_sig transaction as implemented in Coinshuffle. Check that out.
- The transaction is between participating nodes, so each node doesn't act on its own.
- When a node initiates a payment, the fragments it creates aren't necessarily part of the same transaction. Each fragment can be on a completely different mixing transaction.
- The forwarding node doesn't get just the fragment; it gets the whole transaction.
- Therefore it doesn't even know which fragment belongs to who, and how much each fragment is.
- It checks the transaction to make sure it includes its own fragment, signs the transaction, and the whole thing goes ahead.
- If any node doesn't sign, the mesh network resyncs (which happens continually btw) and carries on.

Quote

- When the fragment gets forwarded (from the node) to another node, does one fragment get sent to one node or does each fragment get further broken down in to multiple (how many?) smaller fragments which get sent to multiple (how many) other nodes? Basically, does it only split in to fragments when it comes from the sender, or does each node further split it in to smaller fragments?

Each node making a payment will fragment that payment.
This means nodes forwarding fragments are also making their own payments (in fragments).
There's no way of distinguishing between a node's own fragments and the fragments it's forwarding.

Quote

- How many times does this process happen?
* Does each fragment pass through a specific number of nodes or a random number until it finds its destination?
* Is there a minimum number of nodes a fragment has to pass through?

I'm not sure on this point, but I think a single pass is all that's necessary.

Quote

XMixer: I'm assuming only large payments get sent through the XMixer (how large does it have to be to go through there? Does this depend on the size of the currently online nodes wallets compared to the TX size? Or is it "anything above [insertsizehere] goes through mixer?) I'm assuming larger payments get sent to the mixer in order to get broken down in to many small fragments for the nodes to handle? Or do transactions large enough for the mixer simply go "sender > Mixer(tumble) > Receiver"?

Small transactions will end up going through an Xmixer if, at a given time, other Xnodes aren't transacting.
The Xnodes themselves do the fragmenting, not just Xmixers.
Xmixers therefore only receive fragments.
This means that Xmixers (and Xnodes when they forward a tx) won't see large transactions as distinct from small ones. It's all the same to them.

Quote

I could go on and on making assumptions and asking questions here mate.

I won't part with my money if I don't understand how the system works.

If there's some info or a document somewhere I've totally missed please forgive me.

If not, looking forward to hearing how this thing really works.

That's a respectable position, and a low-risk one.

We're going to publish a full scholarly exposition of XC's tech in due course (i.e. probably around Rev 3 when we launch publicly).

Those who think XC is worth investing in now will stand to gain more when it succeeds.

Thanks a lot for this mate and sorry for my late reply.
Would having non-paying nodes forward transactions even be possible?

Sure. Thanks for all the good questions! Quality discourse does everyone a favour.

A non-paying node would have no payment to submit to the mesh, and thus there would be no basis for it to be included in the transaction.