Topic: Official Anoncoin chat thread (including history) - page 228. (Read 530599 times)

Proportional? Let the pool hopping scam begin!

HashFaster's Crypto Mining Network has opened its AnonCoin pool!

Please come support us!

2%Fee PPLNS Payout.
Stratum only
VARDIFF 16-265
NY, CA, Amsterdam stratum servers

http://anc.hashfaster.com

Thanks!
ZC

Peerbet.org now works with Anoncoin! You can play Wheel & Dice!

I have an idea that would make transaction amounts anonymous and the receiver address completely hidden.

[Edit, clearified PGP use]

First of all much of this will use PGP in reverse so the key Public key will be kept secret and the key Private key will be given out.
Therefore I will call the Public key the "Encryption key," and the Private key the "Decryption key" in the rest of this post.

Imagine two types of transactions in the block chain, one visible and one secret:
The visible one would include:
- the sender in plain text
- the receiver in plain text
- the amount in plain text

The secret one would include:
- sender in plain text
- The receiver id hashed with a salt, then encrypted with senders encryption PGP key (unique PGP pair for every transaction)
- The amount encrypted with senders encryption PGP key
- Parent transfer ID in plain text (transfer where the sender received the money he now wishes to spend)

Example
Let’s say we want to transfer coins we received in Transaction 1 (visible), to Bob in Transaction 2 (secret). Bob would take his id together with a salt and hash it and give us the hash. Now we take the hash and use our PGP encryption key to encrypt it together with the amount. We also give Bob our decryption key so he can privately verify the transaction when it goes out on the block chain, but we don’t give it to anyone else. Giving it out, would be the same as making the transaction visible. Of course any of the two parties now can make the transaction visible should they want to, by giving out the decryption key, but this is not a problem that can be fixed, as they are both aware of the transfer and could just tell people about it in any case.
Anyway Bob uses our decryption key to see on the block chain that it is his hash that is encrypted in the transfer, he sees the amount is right and he looks up the ID of the parent transfer and sees that we indeed have enough money from Transaction 1, that means it is verified. Also no one, not even we know Bobs real sender ID and only we and Bob know how much we actually send him.
But now Charlie doesn't know that we actually don’t have any money left, let’s try and buy something from him with money we already spent (Transaction 3). How can he know if we have the money? Well he gets our decryption key, otherwise he will think it is very weird and assume our payment is bogus. Then he looks at this new Transaction 3, he sees the reference to Transaction 1 where we got the money from, so that checks out. But he then searches for other transactions with references to Transaction 1 and he finds Transaction 2 that we made with Bob. But since he has our decryption key, he also can read the amount we sent to Bob, and subtract it from the money we had and sees that we actually don’t have enough coin for the transaction to be valid. The rule is that older transfers take priority over new ones, so even if we “overspend” in Transaction 3, everyone agrees that Transaction 2 is still valid. Only Transaction 3 is to be ignored. Now Charlie knows Transaction 3 is invalid and doesn't hand over the goods we tried to purchase!
Later transactions can always verify by the receiver in this way, so if Charlie always verify it properly he can be 100% of the coin he receives. Charlie can also see Bob’s receiver hash of course, but that doesn't reveal Bobs sender ID and he can’t “dictionary attack” with the senders on the block chain, since Charlie doesn't know the salt.
But say Bob now wants to send some of the money we gave him to David, how can David verify that Bob has the money when our Transaction 2 was secret? Well since it was secret, Bob has to make it to David, by sending our decryption key and the salt he used in that transaction to him. David now verifies Transaction 2 and that we were in fact the receivers and he can then verify Transaction 4 too and is happy that he received the coin.

Space issue:
Of course if David wants to spend the money from Transaction 4 he now must send both our and Bob’s decryption key and salt, together with his own and so on. In order for space for saved decryption keys and salts not to grow out of control long term, you could include a fix where senders would be forced to make old secret transactions visible by giving out the decryption keys and salts from those transactions. The network would not accept transfers unless outdated transactions become revealed at the same time. Information of this revealed old Transactions are added to the block chain and supersede the older ones (that can be removed using a method that doesn't compromising the security of the block chain. I won’t go into this now). And since our coin now only have 10 secret transactions back to the nearest visible one, we only have to store those 10 decryption keys and salts.

Receiver address:
Your receiver address is a hash of your sender salted address, you can generate as many receiving addresses as you want for each sender address, just by changing the salt. This also means you can keep your sender address hidden to the person sending to you and you can have him send to you multiple times, without him even knowing he is sending to the same sending address.

What do you guys think about this? It is not easy to explain, do you understand it? Have you found any flaws/mistakes?

Seems BS for the little I've seen.. Saw nothing special in the code that could do it, which means they mix it in a sentralized server and you then have to trust them on it, which is ... bad IMO. (I like decentralization, and no-trust ideas). But I'm gonna take a closer look and report back if I was misstaken

What are you thoughts on stablecoin's "mixer"?  Seems like BS to me, do you think it has any merit?  https://bitcointalk.org/index.php?topic=353971

ugh, thats ugly! you can specify the version at the WUI and also set it as parameter

With pywallet you probably need to edit the address prefix to get the right output.

In the pywallet script around line 72 you should find;

Please change that to:

To display anoncoin private keys and addresses right. (This will remove the compatibility with bitcoin, so you need to set it back to 0 afterwards to get it to work with bitcoin again)

Thanks. That clears things up. I remember upgrading to db5 around that time.

If I can't fix it, I'll get your help on IRC.

yes, pywallet is the right way to go. start it with --web and then browse to localhost:8989. if the wallet has a passphrase, you need to unlock it first in the WUI, after that you can dump your privkeys. if you need asistance i can help you, im on #anoncoin @ freenode, also you find me of course in your projects irc channel

these problems happens if you mix db4.8 (or lower) wallets with db5 (or higher), as its not backward nor forward compatible. if you compiled from source, maybe you now used libdb5 and no longer libdb4.8 so if you can, get the libdb4.8 (in case you run ubuntu/linux (if not ubuntu, get source + compile), the official bitcoin PPA has the libdb4.8 included) and your problem should be gone. be sure to stick either to libdb5 or  to libdb4.8 as mixing creates exactly these problems.

Some time ago, when I upgraded anoncoin, it said my old wallet.dat was corrupt.

How do I recover the private keys from the old wallet?

I tried running older versions of the daemon, but when I put the old wallet.dat in .anoncoin, they all crash with:

************************
EXCEPTION: 11DbException
Db::open: Invalid argument
anoncoin in AppInit()

terminate called after throwing an instance of 'DbException'
  what():  Db::open: Invalid argument
Aborted (core dumped)


I also tried pywallet, but I'm not sure what "otherversion" will work, if any.

Any help would be appreciated. Maybe there's a way to look for the private key manually, in a hex editor?

Hello there,

Reddit ALTcointip bot has just announced its 2nd round of signups for a list of supported cryptocurrencies.

Please see the announcement for details. Thanks!

-- vindimy

Thanks, Keep up the good work!

Same as litecoin (0.01). However you can configure this in both the GUI and with parameters with coind.



Awaiting whitepapers version 2, where the size of proof is shrinked. Meanwhile we're working on ideas
to remove the trust issue from zerocoin, and some "extensions" to it.

Check the protocol version in RPC. 70007 is the right one. And to say it like this, if you still recieve blocks you're probably on the right version

We're working on a new release, hoping it's finished to the weekend.

I am using client: v0.6.1-1999-g313123c-dirty-beta
Is this version fine or would you recommend another?  Thanks.

Looks like ANC is breaking through .01BTC for the first time. Next stop 0.1BTC

I don't think this is unrealistic as there will only ever be 4 million produced. Also keep in mind Novacoin, which does not have the innovation of Anoncoin, is worth double while the same quantity is in circulation (500K each so far).

Btw, how's the Zerocoin implementation going?

Step by step

I don't think it's underevaluated but I hope that prices will rise...

Anoncoin is about to pop off.  It's still way undervalued for having such innovative features, such as i2p and tor support.

https://www.youtube.com/watch?v=hVAVaZqNeak

Hey guys.

Today we have formally announced that one of the crypto-security markets we are creating under CipherTrade will use Anoncoin as a based. For more info please see this thread.

Kate.