Confidential / Stealth Transfer Support Implemented and Passing Tests

[Tuck Fheman]

https://beyondbitcoin.org/bitshares-dev-hangout-bytemaster-stealth-confidential-transactions/

[Akado]

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?

[arhag]

Thanks everyone.

[xeroc]

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

[xeroc]

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

[bytemaster]

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/

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

Code: [Select]

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

Code: [Select]

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:

Code: [Select]

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!

[santaclause102]

Thanks so much arhag for your awesome contribution! 

a humble little wonder he is

[BunkerChainLabs-DataSecurityNode]

Thanks so much arhag for your awesome contribution! 

[38PTSWarrior]

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/

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

Code: [Select]

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

Code: [Select]

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:

Code: [Select]

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.

stealth sending is an important sales argument

[fav]

WOW!! +5 arhag .. let's flood this guys with some brownie(.pt)s

this, brownies sent  

[cass]

WOW!! +5 arhag .. let's flood this guys with some brownie(.pt)s

exactly this  @bytemaster

[xeroc]

WOW!! +5 arhag .. let's flood this guys with some brownie(.pt)s

[cass]

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/

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!!

 

[arhag]

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/

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

Code: [Select]

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

Code: [Select]

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:

Code: [Select]

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.
 

[CLains]

great news!!