Unmoderated XC thread

[chaeplin]

Let me clear

Redbboxed is mixer tx 2 attemps. 2coin, after 3coin


I use this


this is first 2coin tx


This is the block tx included




2 coins didn't get in.



Maybe this is my problem only.

But something is gone bad. I lost my coin.

Dev said it is still beta, can happen.

[1715084942]

1715084942

[4420866]

https://bitcointalk.org/index.php?topic=641178.40
Here is some words  from a bitcoin core dev

http://img03.taobaocdn.com/imgextra/i3/888367355/TB2po2SXXXXXXbWXFXXXXXXXXXX_!!888367355.png

Ozziecoin, Your pump and dump dance would probably be more effective if you were less transparently dishonest in your approach.  I'm normally happy to ignore the nonsense in the altcoin subform, but since you saw fit to go distrupt the coinjoin thread with some offtopic insult hurling I thought I'd bring the extensive response back here where its topical.

CoinJoin is trustless— which is orthogonal with centralized or decentralized, it could be implemented several ways (though trustlessness is usually a prerequisite to a decenteralized implementation). Post 5 in the CoinJoin thread writes in depth about implementing it in a decenteralized way, none of which appears to have been implemented by the darkcoin developers as far as I can tell— from what I've heard it seems that they're not even able to understand it. (This is a disappointment to me, since I was trying to describe these ideas clearly so others could understand them.)

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.

As I've said before CoinJoin is interesting because it's inherently part of Bitcoin already— it just needed better tools (and now there are some, e.g. darkwallet) to make it available to people.  It's a privacy improvement over not having it, but it isn't perfect, but it also didn't require any changes to Bitcoin (much less a whole altcoin) to deploy it.  In an incompatible system much better is possible as is proposed by ZeroCash and much better is actually _realized_ by Bytecoin (and its forks... Monero, Fantomcoin, etc.), the later are actually working (if immature, due reinventing many wheels) implementations of much stronger privacy, decenteralized in their implementation, all released under a good open source license.

From what I can tell the only purpose DarkCoin serves is to depress me about the state of humanity.

Now who is doing the pumping for his coin?

I haven't promoted anything here, except arguably the Bytecoin/etc. ones which aren't mine by any means.

As I see it coinjoin as it stands is highly centralised and subject to being co-opted.

You're asserting this but you haven't justified it. I can't counter an assertion because I don't even know what you're saying is centeralized or how you believe it could be co-opted.

Why would you attack Darkcoin?

Because it's closed source stuff of dubious quality which appears to being deceptively marketed.

Afterall, the devs themselves have said they will make the code available soon.

This isn't how cryptosystem development works. History supports taking the position that is closed should be automatically assumed to be snake-oil if not an outright trojan until proven otherwise. It's highly suspect. Systems which are good do not need to hide their operation, not if you're going to ask other people to use it.

It seems to me you are prejudiced against Darkcoin.  Why? I cannot fathom nor am I interested.

Why do you ask why and then claim disinterest? I am prejudiced against vaporware, closed source, and pump and dump nonsense. I am prejudice against things which exploit the technical work I've done, trade on it's name (as Darkcoin did at first, until I started blasting it it), to the apparent purpose of extracting funds from people who are less technically sophisticated. Beyond the basic immorality of it, I worry that this fundraising style will remove people's willingness to support real improvements that aren't scams, since its hard for them to tell them apart.

than your 1 centralised coinmixing server.

What are you talking about here?  Nothing I've ever described involved a singular "coinmixing" server.

As for you saying that CoinJoin is inherently part of Bitcoin; how so? It is not part of the protocol.  I do not see many people use it on a day to day basis. It is not part of computer wallets. Which part of it is actually "inherent".  Why cannot Litecoin use it "inherently" tomorrow if they wanted to? I see nothing inherent about it at all.

I'm now suspecting that you've never read the CoinJoin post at all— pointing out that it was part of the protocol was the point. It's also inherently a part of Litecoin or anything else that copied the bitcoin code slavishly. It's a result of how signatures work in Bitcoin. Getting wallet interfaces and such developed for it was the motivation for the CoinJoin post, and now there has been good movement on that front.

Please, Zerocash is totally closed source right now so how would you know it is better?

Closed source? It's not actually implemented yet, but unlike "DarkCoin" they've extensively described their approach in their academic publications and subjected it to extensive peer review. I'm not a fan of the security assumptions it makes, but the privacy properties the system should achieve are basically perfect.

And bytecoin and its various forks have problems with blockchain bloat.

All cryptographically strongly-private decenteralized cryptocurrencies are going to be unprunable to some degree, which is an unfortunate scalability tradeoff— but considering that no Bitcoin implementation in production today implements pruning anyways, it's hardly a fatal one— at least in the medium term. The tradeoff here is fundamental: if you don't know what coin has been spent, you can't forget any of them.  Of course, a system could have less privacy and things forever out of the anonymity set could be forgotten but thats the tradeoff you get.

[/quote]

[anva]

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.

Truth - XC coin transfers the actual coins to the xnode! Xnode decides to keep the coins, there's no way to stop the process. I raised this very early on!

DRK on the other hand works alot differently and doesnt have this problem Truly decentralized!

From what i read in the xc forum, The communication is encrypted so xnode cant steal coins. I am not sure if multi path handles other scenarios like power failure, windows crash etc

[chaeplin]

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.

Truth - XC coin transfers the actual coins to the xnode! Xnode decides to keep the coins, there's no way to stop the process. I raised this very early on!

DRK on the other hand works alot differently and doesnt have this problem Truly decentralized!

From what i read in the xc forum, The communication is encrypted so xnode cant steal coins. I am not sure if multi path handles other scenarios like power failure, windows crash etc

encrypted communication is used to conceal real payee which mixer use it to send coins.

Payment to real payee is mixer wallet's role.
Wallet(mixer) should send coins..
 

xnode is useless.
When you use xnode, you risk your coins.
xnode can steal your coins.

What actually xnode is doing ?

A/you --> xnode --> B

When you send coins using xnode, it's written to blockchain with xnode address.
Real payee address B is transfered to xnode with hoping xnode to deliver coins to B.


To avoid double spending, xnode need to wait at least 2 ~ n confirmation.

xode is Time/Block delayed postbox/transporter.

As coins sent to xnode address, not real payee B, coins are belong to xnode.
xnode should send coins to B.

Receiving coins and Sending coins are not occurred simultaneously.




 

https://bitcoin.org/en/how-it-works
http://www.zerohedge.com/sites/default/files/images/user3303/imageroot/2013/05/20130512_BTC.jpg

[synechist]

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:

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?

[chaeplin]

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:

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.

[synechist]

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:

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.

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.

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

I am also awaiting the white paper.

[chaeplin]

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.

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

I am also awaiting the white paper.

[synechist]

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:

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.

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.

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.

[chaeplin]

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 doesn'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

[synechist]

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:

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.

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.

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?

[chaeplin]

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?

Conceal sender : can
Xnode : can't


Please read this : https://en.bitcoin.it/wiki/Transaction_fees

Just numbers are different.

Code:

A transaction may be safely sent without fees if these conditions are met:

It is smaller than 1,000 bytes.
All outputs are 0.01 BTC or larger.
Its priority is large enough (see the Technical Info section below)
Otherwise, the reference implementation will round up the transaction size to the next thousand bytes and add a fee of 0.1 mBTC (0.0001 BTC) per thousand bytes[1]. As an example, a fee of 0.1 mBTC (0.0001 BTC) would be added to a 746 byte transaction, and a fee of 0.2 mBTC (0.0002 BTC) would be added to a 1001 byte transaction. Users may increase the default 0.0001 BTC/kB fee setting, but cannot control transaction fees for each transaction. Bitcoin-Qt does prompt the user to accept the fee before the transaction is sent (they may cancel the transaction if they are not willing to pay the fee).

Note that a typical transaction is 500 bytes, so the typical transaction fee for low-priority transactions is 0.1 mBTC (0.0001 BTC), regardless of the number of bitcoins sent.

[synechist]

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?

Conceal sender : can
Xnode : can't


Please read this : https://en.bitcoin.it/wiki/Transaction_fees

Just numbers are different.

Code:

A transaction may be safely sent without fees if these conditions are met:

It is smaller than 1,000 bytes.
All outputs are 0.01 BTC or larger.
Its priority is large enough (see the Technical Info section below)
Otherwise, the reference implementation will round up the transaction size to the next thousand bytes and add a fee of 0.1 mBTC (0.0001 BTC) per thousand bytes[1]. As an example, a fee of 0.1 mBTC (0.0001 BTC) would be added to a 746 byte transaction, and a fee of 0.2 mBTC (0.0002 BTC) would be added to a 1001 byte transaction. Users may increase the default 0.0001 BTC/kB fee setting, but cannot control transaction fees for each transaction. Bitcoin-Qt does prompt the user to accept the fee before the transaction is sent (they may cancel the transaction if they are not willing to pay the fee).

Note that a typical transaction is 500 bytes, so the typical transaction fee for low-priority transactions is 0.1 mBTC (0.0001 BTC), regardless of the number of bitcoins sent.

Thanks. Interesting. How would you conceal the sender?

[chaeplin]

https://bitcointalk.org/index.php?topic=618377.0

http://cryptco.org/Cryptcoin-CryptCast-Anonymous-Whitepaper.pdf


Crypt.


Here is catch.

1) Is encrypted msg written to blockchain ?
    probably not.
    ==> need to be online both.

2) Mixer without real payee.
    Xnode announce itself to network, Crypt do reversal.
    Crypt payer announce to payee, where coins to go ?


O ho...

Hello.

I was invited to check the implementation of XC compared to FedoraCoin's codebase in order to find possible similarities between them.
First of all, I visited FedoraCoin's repository and checked the specific file mentioned (mixerann.cpp and the header file).
Then, I was invited to Developer's station with a Teamviewer session and saw the code that implements the specific feature.

The code is in no way similar between the two coins.
But, I believe that one must trusts his own eyes (and compiler). Just download the source code from FedoraCoin and create a working wallet that has all the features of XC enabled. That would prove whether the claim is correct or false.

Now, I do not know who claimed that Fedora and XC share the same codebase. If someone claims that some principles are the same, then I'm afraid that someone hasn't heard of Bitcoin and the blockchain concept (or the transaction concept, or the pubkey->wallet address concept, or... the list goes on forever).

Hi everyone.

This is my first post in here (actually I should never really have to post ) but I feel obligated to do so, in order to make some clarifications

First of all, excuse my English, as it is not my native.

The pdf document that has been published, is just a rough draft to describe the process in a very simple manner so everyone can understand.
It was not originally meant to be a "Whitepaper".
It is not a protocol description, nor the logic flaw of the application fully detailed.
As it has already been mentioned, it is work in progress.

For those who are familiar with developing cycles, when a product is designed and hits the development department, the final product from the original design many times have lots of differences. And that's to overcome original design flaws, dead ends in the logic or other problems that are part of the development process and needs to be addressed, so that final product meets original specifications.

Saying that, I welcome the comments made to that draft and most of them are valid points and have already been acknowledged and has being or will be addressed.
Remember, it's still work in progress.

If I may comment regarding the best way to do things (for example hard-to-trace transactions), I do not believe that there is an objective "best" way to do it. If there are more than one ways, there will be preference according to specific needs. Every solution will have pros and cons. Some are affected more and others less. It all depends and it's a matter of which solutions works best for each individual.

I respect everyone's work and I am not afraid to admit that I am trying to learn from other ideas and extend them. Isn't that the purpose of open source projects?
I do not believe into "I know it all" people and I never said I am one. Nor any of the team members, from my interaction with them.
Mistakes will be made and be corrected as fast as they are spotted. So it's good to have more eyes to spot them for me and let me know of any error or flaw in my implementation. It speeds things up and also helps me learn more.
So, I always believed that a mixture of ideas can get the best possible result, as long as there's cooperation and good will. That's how this team works and I really believe that we will give the best possible results on each development cycle and on each version release.

From my reading of the whitepaper, it appears the recipient wallet must be online (i.e. running the wallet software) in order to receive coins anonymously. If so, this isn't a workable anonymity solution. Can the dev please clarify?

In order for the transaction to take place, in this initial draft, the wallet has to come online and give "directions" to the sender regarding the destination addresses. The "trigger message" will be valid for some time before it times out. I am testing various scenarios on how to make it work with the best possible (to my knowledge) way.
Now, whether it's workable or not, I guess one must weight the pros and cons. As another developer said (and he's right all the way): there are no true passwords, nor true encryption. Everything can be broken with enough computational power.
So I make myself this question: who do I trust to deliver my coins?

As I said previously, it's a matter of preference. Also, I'm sure that more ideas will come from this, as there's always room for improvement to every design

[chaeplin]

Update - I just ran a TX through the mixer

http://cryptexplorer.com/address/XDNHMSD2Feex8bDHz9yiLtadHz4LGABQWE




the only thing I'm looking for now is proof of direct link from the source wallet address to the destination wallet on block chain


Since this is single path at this time (not multi-path) that is the only concern with this release, is there a DIRECT LINK..

thanks,

ATCSECURE

Didn't we already prove that?  Nobody was able to provide a direct link last time either.

I was told that there was a lot confusion around this, so I did another test with a minor update to the code. but as REV2 is a priority w/ multi-path, I can't spend time on an issue that isn't an issue..  

ae3c0644b030ccf7bf4941f32748354c

http://www.md5.net/md5-generator/

logged.

!_=XMHmvtXiJKG9aa7WcxBLQMcD3pYQ4wK6Ye=_!

[cinnamon_carter]

somewhat related, a short pdf on why it is not so easy to hide or mix transactions as some would lead you to believe http://www.scribd.com/doc/227369807/Bitcoin-Coinjoin-Not-Anonymous-v01

[chaeplin]

~~~

Random FUD

The problems addressed in this were handled hundreds of pages ago. Darksend isn't finished yet and was never promised to be 100% anonymous unless you use great care. Plus RC4 will have great improvements to the anonymity offered.

[chaeplin]

i have more than 10 other wallets and none require me to add .conf file.
XC is the first ever coin to require this and it will never work to the mass. it used to work before, no need .conf

Seriously? This is so trivial. This coin is breaking restraint from DRK FUD and moving forward with something great and you are complaining about a fucking .conf file?

Instead, you need bat.

[chaeplin]

Here is my wallet showing the xnode transactions that came through over night and the fees I collected from the transactions



in my config I just added the east and west nodes and ran the xnode-mainnet.bat

Just out of interest, how fees did you collect?

The fees I collected overnight are as follows:
0.037423
0.028602
0.00996
0.024015

That's not fee.

Your xnode steal coins.



http://chainz.cryptoid.info/xc/address.dws?XM9Bt9j46JUZ9JMGNVfg7R6mvMePJhMpNs.htm

http://chainz.cryptoid.info/xc/block.dws?27429.htm

[ballzdeep]

Guess this turned into DRK people bashing XC uncensored, haha such a bunch of sad jokers...

Go play in your coinjoin thread and f*** urself !