Quote from: chaeplin on June 06, 2014, 01:07:55 PM

Quote from: synechist on June 06, 2014, 01:04:56 PM

Quote from: chaeplin on June 06, 2014, 12:53:05 PM

Quote from: synechist on June 06, 2014, 12:47:45 PM

Quote from: chaeplin on June 06, 2014, 12:28:09 PM

Quote from: synechist on June 06, 2014, 12:06:05 PM

Quote from: chaeplin on June 06, 2014, 02:09:19 AM

Quote from: chaeplin on June 06, 2014, 01:58:42 AM

Quote from: phosphorush on June 06, 2014, 01:53:00 AM

doesn't the network have to agree on what was the initial transaction? Therefore knowing that a bad xnode didn't do what was supposed to do?

xnode owner can change mind.
xnode can suffer Windows crash.
xnode can suffer power failure.
xnode can suffer network interruption.

if any one of this happen, coins are gone, belongs to xnode.

Truth or FUD?

Say.

Chaeplin, thanks for your ongoing work on XC. However you appear to not be aware of some crucial details of how xnodes will work.

I posted the following on the official thread:

Quote

ATCsecure shall we discuss how Gmaxwell's post might apply to XC? I imagine it'd be a matter of whether the multi-path paradigm can be implemented without a dynamic trust system, while still preserving XC's ability to avoid blockchain bloat.

Multi-path has incredible possibilities; how about removing/reducing the need for trust with the following (which in all likelihood you've thought of already):

- your specification includes that each xnode only passes on fragments of transactions; this means each fragment will be a small (non-risky) amount.

- what if xnodes have to compete to relay a given fragment? This builds in redundancy, so that if one node attempts to steal the fragment, the others will pass it on. The fastest node gets the transaction fee.

- what if xnodes also can only pass on a single fragment at a time? This way a node would only ever have one fragment, and therefore could never amass enough money for it to be worth stealing.

- Xnodes would then compete for transaction fees by processing transactions faster than other nodes. This way the network would organically improve its capacity.

- At some cost to network speed, the protocol could also set a maximum fragment size to ensure the incentive to become a bad actor is always low regardless of the size of a given payment.

The effect of the above is that xnodes have two options:
- steal a fragment and (a) derive minimal reward, and (b) get booted off the network via the trust system
- or pass on (a) as many fragments as possible in the shortest time and (b) get multiple tiny rewards.
The second of these is prima facie preferable.

However this idea would still be vulnerable to the following attack:
- set up thousands of xnodes
- find a way to steal fragments (I understand this is only a speculative possibility and that there'll be a way of making this exceedingly difficult... however I can't think further about this without more information)
- steal thousands of fragments, delete nodes, create new ones, build up trust, steal more fragments.

I'm unsure whether this attack will be more profitable than just being an honest node; its feasibility will come down to the details. And, fortunately, you decide what the details are.

The security of the network could well depend on this balance of incentives, which is ok I suppose, but its precariousness is analogous to that of mining competition in bitcoin. A systemic solution to the problem would be preferable.

Any suggestions?

I'd like your opinion on this. Can you think of a way to make XC completely secure?

ATCsecure said current design is single-path.
What is the meaning of single-path ? One xnode recipient address ?
If multiple recipient address is used(one xnode or multiple xnode), I can find who is sender, who is receiver.

And possibility of bad actor still exist.

I am waiting white paper.

Quote

Yes, the current design is single-path. But I'm discussing the design as it will be when fully implemented.

Yes, single-path passes through only one xnode, if I'm not mistaken.

If a wallet sends fragments of a payment to multiple xnodes, which are all sending fragments to thousands of wallets, I do not think you will be able to find the receiver. But you are welcome to prove that you can.

Useless, thousands multiplied tx fee. Have to limit.
Tx is written to blockchain.
Have you heard dust threshold ?

You said thousands of wallets, payment to payee should be consolidated.
Payee will not tolerate with that.

Quote

My scenario above implies that a bad actor will have insufficient incentive. This is arguably ok.

I am also awaiting the white paper.

Transaction fees will remain the same if they are a percentage of the amount transferred.

However the fees would need to be sufficient to justify the expense of running a node, therefore the code would have to be very fast.

Yes, transactions will be written to the blockchain. Bigger transactions will probably be split into more fragments; therefore more blockchain bloat for bigger payments. But the blockchain will still be prunable, and transaction size is much smaller than zerocoin. So XC is still a promising design.

I meant thousands of wallets other than the recipient's wallet.

Yes I know about the dust threshold. It's important to prevent blockchain bloat. I imagine XC will have a dust threshold.

Nope. It don't work like that. Each tx should pay tx fee.

tx fee is not related to xnode fee.
There are two type of fees.
1) Transaction fees
2) Xnode fee

https://github.com/atcsecure/X11COIN/blob/master/src/main.h#L32-L41

Code:

static const unsigned int MAX_BLOCK_SIZE = 1000000;
static const unsigned int MAX_BLOCK_SIZE_GEN = MAX_BLOCK_SIZE/2;
static const unsigned int MAX_BLOCK_SIGOPS = MAX_BLOCK_SIZE/50;
static const unsigned int MAX_ORPHAN_TRANSACTIONS = MAX_BLOCK_SIZE/100;
static const unsigned int MAX_INV_SZ = 30000;
static const int64 MIN_TX_FEE = .00001 * COIN;
static const int64 MIN_RELAY_TX_FEE = .00001 * COIN;
static const int64 MAX_MONEY = 60000000 * COIN;
static const int64 MAX_MONEY2 = 60000000 * COIN; // 60 mil
static const int64 MAX_MINT_PROOF_OF_STAKE = 0.0333 * COIN; // 3.33% annual interest

Yes you are correct about this. But I am not talking about the current code. I'm talking about the final implementation. There will be changes.

To get back to where I started, I asked you if you can think of ways to make XC work perfectly. Can you think of a way to resolve XC's challenges here?