A second mtgox is just a matter of time. However what an exchange does is not the determining factor of value. People will just move their money in and out when they need to instead of using exchanges as "banks".

One of the side effects of masternodes is the incentive to pull money out of exchanges. It will therefore prevent fractional practices, reduce short-selling potential (when short-selling is activated) as well as allow DRK to be more stable in case of an MtGox scenario of a big altcoin exchange, compared to other altcoins (less DRKs stored for hacking, due to many DRKs being assigned to masternodes).

I asked you to show me where the FUD is.

Quote the FUD and show me.

I only stated facts.

Bitcoin=trustless (can't lose coins)
Darkcoin=trustless (can't lose coins)
XC=trusted (can lose coins - the dev of XC himself admits it... perhaps he is a FUDder)

Is this FUD?

No, it's reality.

I quoted some correct and some erroneous information and set the record straight. What's so bad about it?

Naming the way of transaction as X(C)Send?

Any preview on the news?

Spread FUD? Where is the FUD in what I wrote about trusted and trustless transactions?

FUD is when you say DRK can lose coins when it's trustless.

So you got it backwards.

Please continue your cinni thread (unless provoked to respond).

I'm just setting a misconception straight. Why all the insults about infections, trolls, etc? Not that I'm offended - mind you.

Bitcoin = trustless transactions where money can't be stolen when a transaction occurs. (uses signatures)

Darkcoin = trustless transactions where money can't be stolen when a transaction occurs. (uses signatures just as Bitcoin's coinjoin)

XC = trusted transactions where money is forwarded from node to node with the potential to steal money. It uses coin forwarding.

So you are correct in that xnodes can steal coins, but wrong on darknodes being able to steal coins. Darknodes don't receive or forward coins. They are trustless and only process the signing of transactions.

Bitcoin?

Can somebody make a script to test 100 or 1000 transactions and see what percentage of the money go to the destination? For example if 995 transactions go through, it's 99.5% reliability.

It would also be good to measure the impact of multipath in terms of bloat.

Are coins in danger with the beta release?

I think we'll avoid random forking this time as it has been tested extensively on testnet for ~20 days under various scenarios, with multiple bugs fixed.

From what I understand some minor bugs / non-gamestopping issues seem to remain though, which should be fixed in next forks (rc4/rc5+). After all it still remains a complex affair as it introduces a new layer of consensus that the BTC protocol wasn't designed to support.

The price before the prior fork was like 0.025 or something so it's already much lower right now - it can't get much cheaper. The primary buying force behind the coin seems to be on "cautious stand-by" after the fork issues, sweeping low-cost coins when the opportunity presents itself by panic sellers, cost averaging his position to lower levels and price-correcting the coin to preserve its high coinmarketcap position which, in itself, took the coin to another level in terms of media exposure, market acceptance etc. The "pumper" did a great job in how he used coinmarketcap to boost the coin.

At the same time, this same buyer probably initiated the XC pump as well as a diversification option. The volume and buying power were almost the same level and that was not by coincidence. With the info we had at the start XC seemed like a nice addition / a nice prospect but the dev took the wrong course with trusted transactions, effectively undoing what the Bitcoin protocol does (trustless transactions). It's kind of salvage operation there, investment wise.

It's interesting how so many "anonymous" coins have been presented so far (based on bitcoin-blockchain) and yet despite the credentials or ideas of the devs, which in some cases are marketed as better than DRK's, it's still a load of crap in terms of tech. Central mixers, exchange laundering (lol), coin-forwarding from wallet-to-wallet, I mean you can't make this stuff up. And half of them (or more) are scamcoins - with some even being criminal coins, like honorcoin which used people's credentials to rob them off their exchange accounts.

Anyway, let's see how it works out with the fork and move on with improving the "core business" part (anonymity).


If you pay 25% more, you've lost the annual ROI (supposing a large number of nodes are operational).

Understood...

There is no need to be defensive like I'm "challenging" the entire system. My money is on the system that we have, so... take that as a vote of confidence.

As for the ideal system - in the context of transactions - well, it would be more straightforward in the sense that I have 10 BTCs, I give you 7.3 BTCs and I'm left with 2.7 BTCs. Can I code a fork of Bitcoin and make it work? No because I haven't coded in like 15-20 years and thus I suck at it.

As for the ideal system - in a broader sense - I think it would have to be something that is both trustless and decentralized, yet doesn't suffer from the 51% vector. The only way that I can think of, to do that, is the AI route: A trustless solution in the form of a self-aware supra-human AI network taking care of the transactions instead of a "dumb" if-then-else network. The reliability would be higher in the sense that it would still be a computer algorithm in charge, but it would be free of the human politics and bias + it would eliminate the need for 51% miner consensus or 51% stake consensus.

But it wouldn't only take care of transactions, it would be like a personal banker, but at the same time an efficient network administrator that prevents DOS attacks and manages the network load + distributing the storage requirements of the network to its nodes + ensuring the anonymity and privacy of its users by autonomously taking decisions that break pattern recognition and analysis by other AI software. It would also need to have QC-resistance and forking self-awareness when parts of the network go down (the AI would be decentralized - so, say, if Syria went offline, the AI part of the network would understand that transactions with the outside world would be problematic and the other AI part of the network residing in the global fork would understand Syria is "cut-off").

Authentication on said network could probably be done with ways that are unavailable today, like the network "operator" (AI) directly interfacing with the user and checking him out for his face, voice characteristics etc - instead of using keys. Keys could co-exist but they would be optional for the most part as people would interact with the AI.

Human-machine integration could also allow for authentication by producing keys that are unique to the individual, through external devices attached to one's body or internal implants. That's the part I don't like, but by the time suprahuman AI is available, human-machine integration will be a reality anyway in some degree or the other.

Escrow capabilities would be easy for that type of network and the potential for running other type of services on it (due to the supra-human intelligence associated with its operation) would be significant.

Decentralized mining is the only answer... Masternodes get their income from the miners (in a sense), they are not 20% of the real mining power.

I don't "buy" that part - but I'm not necessarily implying you are "selling" it. The fact that Bitcoin is trustless is related to the PoW that makes it possible for the algorithm to determine the validity of transactions through network consensus - not because it uses change addresses.

I haven't done extensive research on other types of blockchains (PoW / PoS) that are written from scratch - perhaps someone that has a greater familiarity with such blockchains can tell us whether they are emulating Bitcoin's choice or if it is unique in Bitcoin.


The first part seems slightly futile when you do a common spend and things get linked. But it is a slight increase, I agree.

The second part, IMO, can be a small factor or a large factor, depending the point of time. In other words: Has a QC been developed (whether the public knows it or not) at a specific time? If the answer is yes, then money are far better protected.

The third part would be ok in theory but it creates more confusion for the average user due to all those tiny amounts that end up being an entire list. A visual representation tool would be, IMO, better for that purpose.

As mentioned earlier, max coins mean nothing if the coin generation formula stops earlier. There is no magic way for the dev to create coins out of thin air and if it was a case of doing it with a hard fork, he could update the number of coins as well.

However, it is the right of an exchange to list whatever coins they want and not list those that look shady to them for whatever reason. It is also their right to say why they reject a coin - no matter if it "hurts" the market or not. If a coin is vulnerable to critique of this kind, perhaps it's not so good of a coin anyway.

"could" ?

Are the specifications public or is this speculation?

Nice analogy. Thank you for your time answering this... I still have a problem digesting the "why can't I simply cut the gold bar in half and pay with half of it and keep the rest" instead of remelting it / recasting it into new bars.

I think I understand why it happens as it happens (because obviously it was designed to be performed that way) but I still have questions on why it was designed that way when it could have been designed in a more straightforward manner. Maybe this is a multi-layered redundancy against a QC-attack-vector.

There are at least 2 "convenient" coincidences regarding quantum-computing protection...

1) the use of addresses as a hash of the public key (a quantum computer can't extrapolate the private key based on the hash of the public key, but it can do so with the public key itself - so as far as there is no spending, the money are safe from QC-attacks)

2) the use of change => destroying prior input and creating change. Thus the remains are not vulnerable to a QC attack to the public key (neither should the main output if the recipient follows best practices on how he uses his addresses).

The design doesn't seem arbitrary. The fact that Satoshi didn't go for a quantum-resistant algorithm for public/private keys is the only troubling aspect - unless we presume there wasn't an adequate solution at his time or the solutions he considered were probably deemed problematic in some other way that we don't know of. But he sure made his best to secure the system anyway despite the lack of QC-resistant algo.

Key question: Are change addresses *needed* for this splitting and recombination? Can't they just be performed on a transaction basis?

"What is needed is an electronic payment system based on cryptographic proof instead of trust,
allowing any two willing parties to transact directly with each other without the need for a trusted
third party."

--Satoshi (whitepaper)