Unmoderated XC thread

[Rraider]

 


http://cryptolife.net/darkcoin-the-next-big-thing-or-just-another-pump-and-dump/



  w...wh...WHAT !?!?!

[phosphorush]

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?

[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.

[evtrmm]

Both

[chaeplin]

Truth or FUD?
 

FUD

https://darkcointalk.org/threads/the-birth-of-darkcoin.162/

[Joshuar]

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.

+1, There's no way I'm getting into XC now.

[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.

[ballzdeep]

dem drk boyz sqeelin like a worm on a hook <3

[stealth923]

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!

[ballzdeep]

DOnt worry so much, there is time, now taht atsecure can work without you assholes getting his focus expect miracles....

[benthach]

Dont hold DRK bag. Sell all your DRK and get into VRC now! this is a chance of your lifetime.

[AlexGR]

VRC is already pumped... Pink coin ftw

[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.

[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.