BitShares Forum
Main => General Discussion => Topic started by: bytemaster on July 22, 2015, 09:33:23 pm
-
https://github.com/cryptonomex/graphene/commit/be65c277c96b96cfa6e31773cce9805d3d51be87
No wallet support yet, but that is relatively easy.
-
+5%
Though I know nothing of coding :P
Will this get implemented into the initial 2.0 release by chance?
-
Well done! :)
-
+5%
But I thought you said the privacy solution was not going to be 'that' easy. Is there a catch?
-
+5%
But I thought you said the privacy solution was not going to be 'that' easy. Is there a catch?
sometimes in software thr tallest mountains have the easiest paths up and the shorter ones are taller than they first seem. Besides after blinded signatures were figured out (bounty?) then i think rest fell inplace
-
Besides after blinded signatures were figured out (bounty?) then i think rest fell inplace
Just to clarify, confidential transactions (aka blinded amounts) don't really have much to do with the blinded signature algorithm that a bounty was offered for (aka Oleg Andreev's algorithm). The former hides the amount of stake an account holds or transfers. The latter allows for multisig / two-factor authentication where the third-party is unable to tell which transaction they signed. The latter is useful in stealth transactions because it allows the recipient to use multisig without revealing to anyone (including the signing third-party) the metadata of which balance belongs to which user (even if they still couldn't tell the actual amount of the balance since it would be blinded using the confidential transactions algorithm).
No wallet support yet, but that is relatively easy.
We still need libsecp256k1-zkp ported to Javascript for the web wallet. Have you looked into emscripten for that? I suppose one of the advantages of the Qt lightweight wallet that Nathan is working over the web wallet is that it can directly link with the C code.
-
We still need libsecp256k1-zkp ported to Javascript for the web wallet. Have you looked into emscripten for that? I suppose one of the advantages of the Qt lightweight wallet that Nathan is working over the web wallet is that it can directly link with the C code.
What would it cost to have YOU do it right away?
I feel you know the graphene code well already and am pretty damn certain the devs can need your assistance almost everywhere!!
-
Good to know privacy protection is (or going to be) back. +5%
-
Good to know privacy protection is (or going to be) back. +5%
Amen.
-
Well done BM, good effort to bring that together.
-
We still need libsecp256k1-zkp ported to Javascript for the web wallet. Have you looked into emscripten for that? I suppose one of the advantages of the Qt lightweight wallet that Nathan is working over the web wallet is that it can directly link with the C code.
What would it cost to have YOU do it right away?
I feel you know the graphene code well already and am pretty damn certain the devs can need your assistance almost everywhere!!
Ahh.... Yes please! +5%
-
great news!! +5%
-
We still need libsecp256k1-zkp ported to Javascript for the web wallet. Have you looked into emscripten for that? I suppose one of the advantages of the Qt lightweight wallet that Nathan is working over the web wallet is that it can directly link with the C code.
What would it cost to have YOU do it right away?
I feel you know the graphene code well already and am pretty damn certain the devs can need your assistance almost everywhere!!
https://arhag.github.io/libsecp256k1-demo/ (https://arhag.github.io/libsecp256k1-demo/)
Bam! ;)
Well, it is only an initial demonstration of just the signing and verification. But the hard part (took me about 25 to 30 hours) was getting the framework of the wrapping code to work well and debugging all kinds of build system issues with Emscripten (the Closure compiler variable renaming drove me nuts). Adding the additional C functions to the API should be relatively easy.
It isn't very well documented but the code can be accessed from here: https://github.com/arhag/crypto-experiments/tree/emscripten/emscripten/libsecp256k1-demo (https://github.com/arhag/crypto-experiments/tree/emscripten/emscripten/libsecp256k1-demo)
Still lots to be done with the code, and I should put up a better README explaining how to build it. But for now a skilled user should be able to figure it out.
First, you need to install the Emscripten SDK. Get and compile the portable SDK from the website. The one in the Ubuntu repos is older and wasn't able to compile the code because of a lack of __int128 support. Then with the PATH setup, you can simply enter the libsecp256k1.js-build folder and run
./configure
make
And it should hopefully compile everything and even install the built libsecp256k1.js into the parent folder. I already included a pre-built version in the GitHub repo, so if you want to make your life easier and you don't need to change any of the Javascript on the library side, you should be able to use that. Then you can just serve the static content in the parent folder (libsecp256k1-demo folder) using whatever web server tool you want. If you have Emscripten already installed, you can simply run
emrun secp256k1-test.html
from the folder and it should even launch your default browser loaded to that page.
If you want a un-optimized debug build (without all that minification and variable renaming by the Closure compiler), just set the DEBUG environment variable to 1 before calling configure. So, for example:
DEBUG=1 ./configure
make
I should note that I have only tested this on a Linux machine and on the Chrome browser. So your mileage may vary. Let me know if it doesn't work on certain machines and browsers. I can tell you already that the build scripts are *nix specific, so they won't work out of the box on Windows. Also, I know that older versions of IE won't be able to even run the pre-compiled version.
One other thing I should mention is that a lot of the code complexity in the wrapper comes from the fact that I am loading the Emscripten-generated code in a Web Worker. This requires all kinds serializing and deserializing of the arguments and return values of the API calls so they can be sent through postMessage. The reason for this is because I noticed that the initial generation of the context takes a long time (several seconds). I thought it would be unacceptable to have the GUI freeze while it was loading. Also, in theory some of the other functions could take a long time too. It is much better to have that computation occur on a separate thread to keep the GUI fast and responsive.
This however does mean the API is a little bit more difficult to use because it is asynchronous. But Javascript users are used to that already. I make use of Promises to avoid callback hell and get code that looks very similar to synchronous code. Finally, it should be noted that though the entire Emscripten-generated code is running in parallel in its own thread (in its own Web Worker), the code is still inherently single-threaded. Emscripten does not (yet) support compiling threaded code. For that reason I have some checks to make sure that the API can only be called one at a time. You must receive the return value from your previous call before you are allowed to make a new call.
-
We still need libsecp256k1-zkp ported to Javascript for the web wallet. Have you looked into emscripten for that? I suppose one of the advantages of the Qt lightweight wallet that Nathan is working over the web wallet is that it can directly link with the C code.
What would it cost to have YOU do it right away?
I feel you know the graphene code well already and am pretty damn certain the devs can need your assistance almost everywhere!!
https://arhag.github.io/libsecp256k1-demo/ (https://arhag.github.io/libsecp256k1-demo/)
Bam! ;)
Bam
and this
I feel you know the graphene code well already and am pretty damn certain the devs can need your assistance almost everywhere!!
+5%
-
WOW!! +5 arhag .. let's flood this guys with some brownie(.pt)s :P
-
WOW!! +5 arhag .. let's flood this guys with some brownie(.pt)s :P
exactly this +5% @bytemaster
-
WOW!! +5 arhag .. let's flood this guys with some brownie(.pt)s :P
this, brownies sent :D +5%
-
We still need libsecp256k1-zkp ported to Javascript for the web wallet. Have you looked into emscripten for that? I suppose one of the advantages of the Qt lightweight wallet that Nathan is working over the web wallet is that it can directly link with the C code.
What would it cost to have YOU do it right away?
I feel you know the graphene code well already and am pretty damn certain the devs can need your assistance almost everywhere!!
https://arhag.github.io/libsecp256k1-demo/ (https://arhag.github.io/libsecp256k1-demo/)
Bam! ;)
Well, it is only an initial demonstration of just the signing and verification. But the hard part (took me about 25 to 30 hours) was getting the framework of the wrapping code to work well and debugging all kinds of build system issues with Emscripten (the Closure compiler variable renaming drove me nuts). Adding the additional C functions to the API should be relatively easy.
It isn't very well documented but the code can be accessed from here: https://github.com/arhag/crypto-experiments/tree/emscripten/emscripten/libsecp256k1-demo (https://github.com/arhag/crypto-experiments/tree/emscripten/emscripten/libsecp256k1-demo)
Still lots to be done with the code, and I should put up a better README explaining how to build it. But for now a skilled user should be able to figure it out.
First, you need to install the Emscripten SDK. Get and compile the portable SDK from the website. The one in the Ubuntu repos is older and wasn't able to compile the code because of a lack of __int128 support. Then with the PATH setup, you can simply enter the libsecp256k1.js-build folder and run
./configure
make
And it should hopefully compile everything and even install the built libsecp256k1.js into the parent folder. I already included a pre-built version in the GitHub repo, so if you want to make your life easier and you don't need to change any of the Javascript on the library side, you should be able to use that. Then you can just serve the static content in the parent folder (libsecp256k1-demo folder) using whatever web server tool you want. If you have Emscripten already installed, you can simply run
emrun secp256k1-test.html
from the folder and it should even launch your default browser loaded to that page.
If you want a un-optimized debug build (without all that minification and variable renaming by the Closure compiler), just set the DEBUG environment variable to 1 before calling configure. So, for example:
DEBUG=1 ./configure
make
I should note that I have only tested this on a Linux machine and on the Chrome browser. So your mileage may vary. Let me know if it doesn't work on certain machines and browsers. I can tell you already that the build scripts are *nix specific, so they won't work out of the box on Windows. Also, I know that older versions of IE won't be able to even run the pre-compiled version.
One other thing I should mention is that a lot of the code complexity in the wrapper comes from the fact that I am loading the Emscripten-generated code in a Web Worker. This requires all kinds serializing and deserializing of the arguments and return values of the API calls so they can be sent through postMessage. The reason for this is because I noticed that the initial generation of the context takes a long time (several seconds). I thought it would be unacceptable to have the GUI freeze while it was loading. Also, in theory some of the other functions could take a long time too. It is much better to have that computation occur on a separate thread to keep the GUI fast and responsive.
This however does mean the API is a little bit more difficult to use because it is asynchronous. But Javascript users are used to that already. I make use of Promises to avoid callback hell and get code that looks very similar to synchronous code. Finally, it should be noted that though the entire Emscripten-generated code is running in parallel in its own thread (in its own Web Worker), the code is still inherently single-threaded. Emscripten does not (yet) support compiling threaded code. For that reason I have some checks to make sure that the API can only be called one at a time. You must receive the return value from your previous call before you are allowed to make a new call.
+5% stealth sending is an important sales argument
-
Thanks so much arhag for your awesome contribution! +5%
-
Thanks so much arhag for your awesome contribution! +5%
a humble little wonder he is :)
-
We still need libsecp256k1-zkp ported to Javascript for the web wallet. Have you looked into emscripten for that? I suppose one of the advantages of the Qt lightweight wallet that Nathan is working over the web wallet is that it can directly link with the C code.
What would it cost to have YOU do it right away?
I feel you know the graphene code well already and am pretty damn certain the devs can need your assistance almost everywhere!!
https://arhag.github.io/libsecp256k1-demo/ (https://arhag.github.io/libsecp256k1-demo/)
Bam! ;)
Well, it is only an initial demonstration of just the signing and verification. But the hard part (took me about 25 to 30 hours) was getting the framework of the wrapping code to work well and debugging all kinds of build system issues with Emscripten (the Closure compiler variable renaming drove me nuts). Adding the additional C functions to the API should be relatively easy.
It isn't very well documented but the code can be accessed from here: https://github.com/arhag/crypto-experiments/tree/emscripten/emscripten/libsecp256k1-demo (https://github.com/arhag/crypto-experiments/tree/emscripten/emscripten/libsecp256k1-demo)
Still lots to be done with the code, and I should put up a better README explaining how to build it. But for now a skilled user should be able to figure it out.
First, you need to install the Emscripten SDK. Get and compile the portable SDK from the website. The one in the Ubuntu repos is older and wasn't able to compile the code because of a lack of __int128 support. Then with the PATH setup, you can simply enter the libsecp256k1.js-build folder and run
./configure
make
And it should hopefully compile everything and even install the built libsecp256k1.js into the parent folder. I already included a pre-built version in the GitHub repo, so if you want to make your life easier and you don't need to change any of the Javascript on the library side, you should be able to use that. Then you can just serve the static content in the parent folder (libsecp256k1-demo folder) using whatever web server tool you want. If you have Emscripten already installed, you can simply run
emrun secp256k1-test.html
from the folder and it should even launch your default browser loaded to that page.
If you want a un-optimized debug build (without all that minification and variable renaming by the Closure compiler), just set the DEBUG environment variable to 1 before calling configure. So, for example:
DEBUG=1 ./configure
make
I should note that I have only tested this on a Linux machine and on the Chrome browser. So your mileage may vary. Let me know if it doesn't work on certain machines and browsers. I can tell you already that the build scripts are *nix specific, so they won't work out of the box on Windows. Also, I know that older versions of IE won't be able to even run the pre-compiled version.
One other thing I should mention is that a lot of the code complexity in the wrapper comes from the fact that I am loading the Emscripten-generated code in a Web Worker. This requires all kinds serializing and deserializing of the arguments and return values of the API calls so they can be sent through postMessage. The reason for this is because I noticed that the initial generation of the context takes a long time (several seconds). I thought it would be unacceptable to have the GUI freeze while it was loading. Also, in theory some of the other functions could take a long time too. It is much better to have that computation occur on a separate thread to keep the GUI fast and responsive.
This however does mean the API is a little bit more difficult to use because it is asynchronous. But Javascript users are used to that already. I make use of Promises to avoid callback hell and get code that looks very similar to synchronous code. Finally, it should be noted that though the entire Emscripten-generated code is running in parallel in its own thread (in its own Web Worker), the code is still inherently single-threaded. Emscripten does not (yet) support compiling threaded code. For that reason I have some checks to make sure that the API can only be called one at a time. You must receive the return value from your previous call before you are allowed to make a new call.
Amazing work! I would have thought that it would take much longer to do that! I just sent you some major brownie points for that work!
Now we just need to integrate it with the main wallet! On Friday I got the cli_wallet working with confidential transactions. Shouldn't be too hard to get it working in the web wallet given the progress you have already made!
-
Forgive my ignorance, but technically, what functionality does this allow?
It allows to use confidential transactions in the web-wallet which is written in javascript ..
-
So this means that anyone can see that I sent or received a transaction, but not now much or what it was?
That's what I understood .. yep ..
-
Thanks everyone.
-
So this means that anyone can see that I sent or received a transaction, but not now much or what it was?
That's what I understood .. yep ..
So with a tumbler we would have some kind of pseudo-privacy? Others would know I made a transaction to that tumbler account but that's all they would know since - assuming a large number of people uses it - the receiver and sender of all transactions would be that tumbler right? All transactions would pass through. Could that be automated with some kind of contract? Some kind of automated account would be created though I dunno how to make it inaccessible to everyone (maybe multi sig between a huge number of ppl?) and all we had to do would be sending a transaction to that account with the true recipient of the transaction and a time delay -for when we want the automated account to re-send the $ to the true recipient so that one wouldn't be traced through timestamps - on the memo (I assume that info wouldn't be available). Would that be possible or am I just complicating things? The source of all transactions would be that automated account and with no amounts shown or useful timestamps, transaction tracking would be pretty much useless? I'm just brainstorming, I guess something like this has already been thought about?
-
https://beyondbitcoin.org/bitshares-dev-hangout-bytemaster-stealth-confidential-transactions/ (https://beyondbitcoin.org/bitshares-dev-hangout-bytemaster-stealth-confidential-transactions/)
-
So this means that anyone can see that I sent or received a transaction, but not now much or what it was?
That's what I understood .. yep ..
Hmm, the original post seems to be deleted for some reason. But I just want to clarify that you can still tell what asset it was just not the amount. For example if account A sends 100 BTS to account B, the public will be able to tell that account A sent some unknown amount of BTS to some account (if it is a blinded but not stealth transacton then the public can also know with certainty that the receiving account is account B). On the other hand if account A sends 100 BitUSD to account B, the public will be able to tell that account A sent some unknown amount of BitUSD to some account.
Edit: You could in theory obfuscate the asset sent as well by simply sending a wide variety of assets with each transaction, where all but one are of a zero amount. But first you would need to have plausibly received that asset as a blinded transaction to the account that will be doing the sending. Also, you need to make sure that the receiver merges in all the assets (including the zero amount ones) into their account to not leak information about which was the non-zero one. Also, the transaction size (and thus fees) scales with the number of assets you want to hide in. So because of that and the added complexity on both sender and receiver to avoid leaking information, I think it quickly become not worth the added privacy.
-
WOW!! +5 arhag .. let's flood this guys with some brownie(.pt)s :P
hodor!
-
Hmm, the original post seems to be deleted for some reason. But I just want to clarify that you can still tell what asset it was just not the amount. For example if account A sends 100 BTS to account B, the public will be able to tell that account A sent some unknown amount of BTS to some account (if it is a blinded but not stealth transacton then the public can also know with certainty that the receiving account is account B). On the other hand if account A sends 100 BitUSD to account B, the public will be able to tell that account A sent some unknown amount of BitUSD to some account.
Edit: You could in theory obfuscate the asset sent as well by simply sending a wide variety of assets with each transaction, where all but one are of a zero amount. But first you would need to have plausibly received that asset as a blinded transaction to the account that will be doing the sending. Also, you need to make sure that the receiver merges in all the assets (including the zero amount ones) into their account to not leak information about which was the non-zero one. Also, the transaction size (and thus fees) scales with the number of assets you want to hide in. So because of that and the added complexity on both sender and receiver to avoid leaking information, I think it quickly become not worth the added privacy.
Thanks you very much for the explanation ..
-
So this means that anyone can see that I sent or received a transaction, but not now much or what it was?
That's what I understood .. yep ..
Hmm, the original post seems to be deleted for some reason. But I just want to clarify that you can still tell what asset it was just not the amount. For example if account A sends 100 BTS to account B, the public will be able to tell that account A sent some unknown amount of BTS to some account (if it is a blinded but not stealth transacton then the public can also know with certainty that the receiving account is account B). On the other hand if account A sends 100 BitUSD to account B, the public will be able to tell that account A sent some unknown amount of BitUSD to some account.
Edit: You could in theory obfuscate the asset sent as well by simply sending a wide variety of assets with each transaction, where all but one are of a zero amount. But first you would need to have plausibly received that asset as a blinded transaction to the account that will be doing the sending. Also, you need to make sure that the receiver merges in all the assets (including the zero amount ones) into their account to not leak information about which was the non-zero one. Also, the transaction size (and thus fees) scales with the number of assets you want to hide in. So because of that and the added complexity on both sender and receiver to avoid leaking information, I think it quickly become not worth the added privacy.
Is there no way to make the sender and receiver unknown while still preserving the public record of the asset and amount transacted?
-
Is there a difference between privacy use here vs zerocoin? Is this implementation better for exchange and market type transactions and zerocoin is better for uniform type currency transacting? I guess the root of my question is why are we going for this, rather than zerocoin?
-
Is there a difference between privacy use here vs zerocoin? Is this implementation better for exchange and market type transactions and zerocoin is better for uniform type currency transacting? I guess the root of my question is why are we going for this, rather than zerocoin?
Zerocoin hides sender/receiver but does not hide amounts. The ring signatures of CryptoNote also hide sender/receiver but not amounts. (Technically, when I say doesn't hide amounts, I mean that these work on fixed-denomination assets. You could have a collection of related assets of different denominations, e.g. a $1 bill, $5 bill, $10 bill, etc., and send an appropriate combination of them privately to the receiver to effectively hide the amount. There is then the added complication of converting one asset to a combination of other ones and vice versa to implement "getting change".)
The ring signatures of CryptoNote grow in size proportional to the number of balances the user wants to hide in. (Technically, Chandran signatures can be used to have the signature grow with the square root of the number of balances. However, their applicability for cryptocurrency has been contested (http://digitalmoneytimes.com/crypto-news/stealthcoin-shadowcash-chandran-signatures-bitcoin-wizards-what-really-happened-and-why-there-is-a-reason-for-concern/). And apparently they require a trusted setup, so that makes me immediately consider it a non-starter.) For that reason, users need to compromise privacy a little and choose a small set of balances to hide in for the sake of reducing transaction size. (This compromise is also beneficial in making it easier on lightweight clients. But they would still need to request from a full node the balances of a few candidate blocks, one of which holds the balance they want to spend, to then filter down to the handful of balances, one of which must include their spending balance, that they wish to generate the ring signature on.)
On the other hand, I believe Zerocoin's spend signatures (really just the serial number and the zero-knowledge proof) are fixed size regardless of the privacy level wanted. (Zerocoin uses a one-way accumulator that needs to be computed by all nodes in the network. This can be done incrementally by the nodes for each new stealth transfer transaction. However, to generate a signature, the spender needs access to the accumulator by the end of the block just prior to the block in which their spending balance exists and the commitments of all balances in blocks that come after the block just prior to the block containing the spending balance, which seems to me to be a major problem for lightweight clients.) Despite being fixed size, the zero-knowledge proofs of Zerocoin are pretty large and take a while to verify.
Besides not hiding the amounts, the CryptoNote and Zerocoin methods suffer from the fact that they make full blockchain pruning impossible. (Actually, I may be wrong about this. Blockchain pruning might be possible, I just haven't yet figured out the details of how it would work. In any case, I would imagine blockchain pruning would require some time limit for users to redeem/update their balances before they are lost forever.) The blockchain needs to store all serial numbers that have been used to redeem the tokens to prevent double-spends. So it grows in size without bound over time.
Zerocash hides both the sender/receiver and the amounts. It uses a special zero-knowledge proof called Succinct Non-interactive ARguments of Knowledge (zk-SNARK), which allows for a much smaller proof than Zerocoin. It would seem to be the ideal system, but the problem is that zk-SNARK are very new cryptography so there is some uncertainty regarding whether it is appropriate to trust it yet for this purpose, and more importantly it requires a trusted entity to setup the initial parameters needed to make the proofs work. If this entity cannot be trusted, they could produce free tokens out of thin air. I also don't know what limitations it poses on lightweight clients.
Confidential transactions allows the amount to be blinded but by itself not the sender/receiver. This blinding process is really efficient: it is easy to compute the blinded values and to verify that sums add up, and even the range proof construction/verification isn't too bad; since it doesn't hide metadata of sender and receiver, it is easy on the lightweight clients since they don't need any other information from the blockchain that isn't relevant to their balances/transactions; the cryptography is mostly straightforward and better understood than zk-SNARKs, and doesn't require any trusted setup; and even though the size of the range proofs are somewhat large, they aren't too bad (an order of magnitude better than size of Zerocoin's zero-knowledge proofs) and with this new Compact Confidential Transactions (http://bitsharestalk.org/index.php/topic,17697.0.html), the size of the range proofs become very small (approximately the same size of zk-SNARKs of Zerocash and smaller than a CryptoNote ring signature that hides within at least 8 balances). Adding stealth transfers on top of blinded amounts allows both the amount and the recipient to be hidden from the public (although for the recipient to remain hidden they need to not do things with the received balance that links it to their real account). Tumblers and CoinJoin (which have augmented privacy because of blinded amounts) can then provide users with the added privacy they need to move tokens from one account to another without linking the together.
Finally, I should mention that all of these techniques are to provide privacy for simple transfer operations. Market operations and smart contracts (generally) require knowing the plain-text amounts.
-
Wow that was great. Someone should give you BROWNS. Is this method Bitshares pursuing the best option out there right now?
-
Wow that was great. Someone should give you BROWNS. Is this method Bitshares pursuing the best option out there right now?
The best that I know of that has a working implementation and has been vetted by top Bitcoin cryptographers.
-
Adding stealth transfers on top of blinded amounts allows both the amount and the recipient to be hidden from the public (for asset transfers only)
So, you're saying that we will be at least as dark as DASH, Bytecoin/Monero, and Shadowcash?
Bytecoin/Monero and Shadowcash all use the CryptoNote mechanism I described above. So they protect sender/receiver metadata better than BitShares will but come with disadvantages I listed in my previous post.
DASH is frankly not very interesting. Their main feature are stealth transfers that BitShares already has (TITAN) and will reimplement in BitShares 2.0 but in a better way (stealth transfer with blinded amounts via Confidential Transactions). They also conveniently integrate a CoinJoin protocol into the network with their Masternodes (I briefly discussed Masternodes in a different context in this thread (http://bitsharestalk.org/index.php/topic,14187.15.html)). I'm not sure if it makes sense to integrate the CoinJoin protocol so closely with the blockchain protocol or just have that be a separate service provided by wallet hosts, but if it does make sense and there aren't better ways of doing it, it is something that can easily also be implemented in BitShares. Plus thanks to blinded amounts, the CoinJoin protocol would be even more private.
-
Could somebody add some info about this on the technology page (https://bitshares.org/technology/) on the website? This is so important that this absolutely should be promoted in there.
-
Could somebody add some info about this on the technology page (https://bitshares.org/technology/) on the website? This is so important that this absolutely should be promoted in there.
Anybody?
If it's not sure yet that this will be implemented when 2.0 comes out, a blog post might be better than technology page. But anyway, some kind of "official" statement/explanation would be great. There are lot of people who want anonymous cryptocurrencies so we need to get their attention.
I'd love to have site/post that I can link anytime there's discussion about anonymous cryptos.
-
Could somebody add some info about this on the technology page (https://bitshares.org/technology/) on the website? This is so important that this absolutely should be promoted in there.
Anybody?
If it's not sure yet that this will be implemented when 2.0 comes out, a blog post might be better than technology page. But anyway, some kind of "official" statement/explanation would be great. There are lot of people who want anonymous cryptocurrencies so we need to get their attention.
I'd love to have site/post that I can link anytime there's discussion about anonymous cryptos.
Yes!
https://bitshares.org/
Now we can finally fill in the missing square :-*
-
https://github.com/cryptonomex/graphene/commit/be65c277c96b96cfa6e31773cce9805d3d51be87
No wallet support yet, but that is relatively easy.
yay! +5%
-
https://github.com/cryptonomex/graphene/commit/be65c277c96b96cfa6e31773cce9805d3d51be87
No wallet support yet, but that is relatively easy.
yay! +5%
It would be nice to see that topic covered here:
https://bitshares.org/technology/
in a nice, bold typeset too:
Stealth Transfers with Blinded Amounts via Confidential Transactions
-
Could somebody add some info about this on the technology page (https://bitshares.org/technology/) on the website? This is so important that this absolutely should be promoted in there.
Anybody?
If it's not sure yet that this will be implemented when 2.0 comes out, a blog post might be better than technology page. But anyway, some kind of "official" statement/explanation would be great. There are lot of people who want anonymous cryptocurrencies so we need to get their attention.
I'd love to have site/post that I can link anytime there's discussion about anonymous cryptos.
As soon as there is a GUI implementation, this should be added to bitshares.org/technology/ (https://bitshares.org/technology/). There are always conversations going on about anonymous coins and having a page to link to that explains our implementation would be very helpful.