Topic: [ANN - Pre-ICO] BlockPay - Zero Cost, digital currency Point-Of-Sale systems - page 10. (Read 44555 times)

 
Stealth transactions (in my opinion) are imperative to the survival of Liberty. February is my goal for the formal Stealth launch, but this has to be perfect, via the cryptography that we have to work with right now. Zero Knowledge ("zk") transactions are the holy grail of financial privacy, and I want this to be impenetrable. Besides completion of the UI for Stealth, there was one final issue with Stealth that we had to tackle, called "trusted setup".
 
What is trusted setup?

zkSNARK allows us to implement the perfect anonymity, the only issue is the fact that verification of the proof requires some interaction among Prover and Verifier. They should generate some kind of “shared secret”,  after that the Prover can prove something without disclosing any additional info. But this way is not acceptable in cryptocurrencies for transaction verification,  because it's impossible to interact with the transaction issuer every time somebody verifies the transaction. The workaround for this issue is pre-generation of this “shared secret” (usually it is called public parameters, or "pp") for all transactions and Verifiers at the very beginning. Very roughly speaking this pp is the constant value in the zkSNARK library code. The problem is that if somebody knows some data (let’s call it “toxic waste”) that was used during this pp generation, he can counterfeit any proof that was generated with using this pp. Library authors didn’t include this pp in the original zkSNARK implementation code because it is difficult to prove that they didn’t know this toxic waste for this predefined pp. So every zkSNARK client app should invent the way to generate this pp and prove to the community the fact that they are not storing the toxic waste for this pp. If they can do that, then it is safe to use the same pp in every other app that uses zkSNARK in the future. Zcash was the first client app with the zkSNARK library and that’s why they should generate this pp. If this pp generation is safe, then we can use the same pp value. If we think this generation is not safe, then we can generate it one more time in another, safer way. If zkSNARK has the pp generated one time in a safe manner, then all the other apps that use it don’t need any trusted setup or something like this anymore.
 
What is wrong with Zcash trusted setup?
 
The only weak place in Zcash cryptography is in the pp generation, usually called the trusted setup. They found the way to generate it in a safe enough manner, but were criticized because it's still the weakest place in their system (but it’s still safer than many other cryptocurrency weak places are). They can generate this pp by several participants so that if at least one of the participants will not save his part of the toxic waste and share it with other trusted setup participants, pp generation will be safe and nobody can counterfeit the generated proofs. Their error was that they use a predefined small number of participants, so it's possible that the 6 participants weren’t honest and modified the pp generator code and saved their toxic waste parts. All other procedures were safe; there are several participants, if only one of the participants is honest then the generation is safe, and there are participants that are not associated with Zcash.
 
How can we improve upon their trusted setup?
 
Our main idea is to allow anyone/everyone to participate in the trusted setup who's interested in security. These participants should not only be the members of the Bitshares community, but there are at least several Zcash forks that need zkSNARK pp too. So we are preparing a generator (open source of course), that every web user can install and start it on a predefined date, and the network of these generators will generate safe pp for zkSNARK. If only one of these users will be honest and will not save his part of the toxic waste, the pp is safe and can be used (not only by Bitshares, but by any other zkSNARK client too (Zcash forks, for example)). So if you don’t want to trust anybody in trusted setup you can just participate in this setup and be sure it was honest by destroying your part of the toxic waste (you don’t need to do something special for this, just build the source code without modification and start up the generator).
 
The main risk in this case is performance (the more participants, the more generation rounds), so in the worst case we should limit the number of participants. We think it’s ok however, because Bitshares already has a set of trusted members (thanx to DPOS). It can be any number of Committee members, Witnesses, or Stakeholders, for example. We hope to create the algo without any participation limits and should be finished with it very soon.
 
We have kept the new algo (more or less) the same in our libsnark implementation (github.com/kenCode-de/libsnark), and mainly edited the build scripts to facilitate this “trustless” setup redesign. This procedure should be started only once and after that, its result will be hardcoded into the code. Stealth transactions will not require any additional actions from any Bitshares system participants.
 
BlockPay of course, will soon include this extra layer of privacy via Stealth transactions as an option in the Settings screen.
edit: ps: I will post my normal weekly update in just a few hours...

Tons of code uploaded to my github this week:
https://github.com/kenCode-de?tab=repositories
 
C-IPFS and BlockPay related:
 
To align the hashes with what is stored in the Go version of IPFS, the hashes must match. That was the purpose of these commits this week:
https://github.com/kenCode-de/c-ipfs/commit/914d3caaeda5cfbdcb2a9f5cf80012768b496262
https://github.com/kenCode-de/c-ipfs/commit/8d2aeab0167a7e5145d07659c6d0e5a03ef9fd41
https://github.com/kenCode-de/c-ipfs/commit/15b432c70e977b9682b35c9690e6a10b49f42b03
https://github.com/kenCode-de/c-ipfs/commit/1dcbf8962e14d490ee331668966b3dff2bc54754
https://github.com/kenCode-de/c-ipfs/commit/3004f1411a121c9e7a085e6945a6de93c452a8b4
https://github.com/kenCode-de/c-ipfs/commit/8f44c857db04812267928f69b69177ab8597949c
 
After that, we began working on importing of directories...
https://github.com/kenCode-de/c-ipfs/commit/9d77b2709f6e59b7dc388b7136466dd35b9e65df
https://github.com/kenCode-de/c-ipfs/commit/fa3dd77e96544863c238096a23442ddc28dd4263
 
..and making the directory hash match the Go version:
https://github.com/kenCode-de/c-ipfs/commit/396dfc6abc45d664c5240e002a3295fe991b0b67
 
We have now added the code to retrieve a file based on the hash of the directory and the path to the file:
https://github.com/kenCode-de/c-ipfs/commit/addb5ba302cdb102a6ec2362d64adb2a5655ed42
 
The storage system is now to a point where it is functional and installable. It is not perfectly tested, but a damn good number of use cases work.
 
What is planned for the coming week:
More testing / commenting / docs (the IPFS community will be helping us with this)
Error handling around user input and better responses to the user
Resolving files across networks
More c-ipfs and c-ipns(lots of speed improvements thanx to our protobuf completion) commits:
https://github.com/kenCode-de/c-ipfs/commit/00bf29b0fafc37e7e058c8cfa2d43d6b5c891fe9
https://github.com/kenCode-de/c-ipfs/commit/37bab54a5c7d7cb4015ec97bb0e9515f4f9c952e
https://github.com/kenCode-de/c-ipfs/commit/d9774095d3948afd4abd537ea8d80d42e77b96ea
https://github.com/kenCode-de/c-ipfs/commit/ef380f2a6915e978bbd9f28fb7a7a1b495c6e94d
https://github.com/kenCode-de/c-ipfs/commit/9d194ad484a540cad515c015ca203f8abb847200
https://github.com/kenCode-de/c-ipfs/commit/f7a029ade3422fe636373df721925d265bedcc16
 
..and more:
"ipfs add [filename]" and "ipfs add -r [directory]" are now both functional
"ipfs object get [hash]" and "ipfs object get [path]" are now both functional
namesys-protobuf, c-ipfs-node and CJDNS basic support are also complete
Early next week we will finish pin, routing, libp2p-routing and c-ipns.
 
The CLI was released right before Christmas, and we now have Pre-Releases ready for Linux and Mac here:
https://github.com/kenCode-de/c-ipfs/releases
 
We should also have a Windows, and first formal Release for all platforms ready by next week at the link above.
 
Android Smartcoins Wallet and security audits:
 
We found a very rare bug that was preventing the storage of newly created keys to persistent storage. The previous procedure was storing them in memory and just promoting them to the shared preferences once we got the response back from the network and the account update procedure was deemed successful. This of course leaves a small breach that would happen if something were to happen in case the account update was successful, but the network response failed to reach the user. The situation described before never actually happened, but it could be emulated by purposely crashing the thread at a very specific point. Most users are not going to try to crash a thread on purpose.
 
The code written to treat this very rare situation also took special care of checking if the stored key actually does match the public address of the "active" role of the account, and only then it proceeds to replace it. The described changes can be inspected in this commit (https://github.com/kenCode-de/smartcoins-wallet/commit/4ea07e741223680363225c5a038769988927a95f).
 
After having added support for the 'get_market_history' API call in our new graphenej library (https://github.com/kenCode-de/graphenej), this was introduced in the Smartcoins Wallet and used to obtain the historical market data, which in turn is useful to calculate the equivalent fiat values of past transactions. This was previously being done on-demand every time the app was restarted, a solution which was very inefficient and actually wrong, because the equivalent values were being calculated with current values, not past ones.
 
With the new changes introduced, after a batch of transactions is loaded and stored into the database, the app will perform a query looking for historical transactions that don't have an equivalent fiat value. With this in hand, the aforementioned 'get_market_history' API call is used to obtain historical market data and calculate the equivalent value.
 
Because not every token might have a very active market with the user desired Smartcoin, we make a 2-step equivalent value calculation. First calculating the historical relationship of the token with the BTS, and then in turn finding out how much that amount of BTS would have been in bitUSD or bitEUR (or the desired Smartcoin) at that point in time.
 
If the transaction was already made in BTS the first step was avoided, and if it was already a Smartcoin no conversion is needed of course. Every one of these special cases was treated and upgraded.
 
Also a mapping was created to match the location of the user with a set of Smartcoins. If no Smartcoin exists for a specific country (a situation that applies for most countries actually) then bitUSD is now used as a default.
 
The relevant commits for this work are:
https://github.com/kenCode-de/smartcoins-wallet/commit/0decd87e1f8160d98e7d77b458cae698072b67d0
https://github.com/kenCode-de/smartcoins-wallet/commit/ee7ac88eb45dd21fb19353d44f9e8f92bc029a51
https://github.com/kenCode-de/smartcoins-wallet/commit/39b581d17a36e230b779bd7e9451f5018bb1c060
 
And a more detailed description of the specific details about this procedure:
 
Transactions loading (on the home screen) - The procedure to load the database with historical transfers is somewhat complex due to the fact that what we want to display and what the API gives us is slightly different. Namely time and equivalent value information is missing. There is of course ways to obtain this data, but more on the specifics of this later. Let us first focus on obtaining the list of transactions and display whatever it already gives us.
 
The list of historical transactions is obtained by using the ‘get_relative_account_history’ API call. And even though this call has a hard limit on 100 operations per request, we can easily schedule a new request in case we note the user might have more than 100 transactions already. It is not really a problem to chain operations like this, since this procedure is only performed once upon installation to initially fill the database with operations performed prior to the apps' (Smartcoins Wallet and BlockPay both) install.
 
With this in place, we can already display information about what was sent, and if it was an incoming or outgoing transaction. A quick search to this newly loaded database can also give us the list of assets used and that information is used to obtain more information about each one of them. Specifically we would like to know each asset’s symbol and precision, in order to properly format them to the user. So that we can display USD 1.00 to the user instead of its raw value of 1000 for instance.
 
The first complication arises from the fact that the list of operations retrieved by this API call doesn’t explicitly have the time information in it. Instead each operation does indicate the block number in which it was included in the blockchain.
 
By taking the block number information however, we can then use the ‘get_block_header’ API call to get the UTC time for that specific block. The downside of this API call is that it doesn’t support batched calls. That is, a request has to be made specifically for every missing block header. This can be time-consuming, especially if we decide to load all historical transfer’s time information and then proceed to calculate equivalent values.
 
Since the user is more likely to be interested in the most recent transactions first, and recalling that this operation is only performed ONCE upon app install, it was decided to split the timestamp query and equivalent value calculations into batches. So this way the app will load all transactions first, and display the information about every transfer without any date and time or equivalent value first.
 
Then we’ll proceed to load date time information from top to bottom, but not going all the way down the list. But instead stopping at a specific batch size, and then proceed with the equivalent value calculation. In other words, don't annoy the user.
 
Please note that the equivalent value calculation depends on us having the specific date and time for every operation, since we’re using the ‘get_market_history’ API call, which takes a timestamp information instead of block number.
 
The timestamp query and the equivalent values thus are performed going from most recent to older transactions, which will appear low in the list anyways. Once this operation is finished, the app will just query the local database.
 
This initial database loading operation can take a while to conclude, but since it is done in the background by threads filling in the database the user doesn’t have to wait for it to conclude and is free to use the app. He can even interrupt the procedure by pressing the home button, and it will just resume from where it left when the app is reopened.
 
With the information about historical equivalent values in the databse, it was now possible to re-enable the "export to PDF/CSV" and "eReceipt" functionalities (which will be included in v1.5.6). This was done here:
https://github.com/kenCode-de/smartcoins-wallet/commit/a341882bb4e96c567be545be5c8641b2eb73b116
https://github.com/kenCode-de/smartcoins-wallet/commit/6e4325bfd6a51bc912a70b80879946e10c9e7c28
 
More features updated:
Caching for getAssets (more speed improvements)
Changing BalanceFragment Structure (Separating the view from the logic for the future c-ipfs integration)
As always, never keep more money in your wallet than you can afford to lose. Latest release can be downloaded from google play:
https://play.google.com/store/apps/details?id=de.bitsharesmunich.smartcoinswallet
 
Stealth related:
 
Finishing the "trustless" setup algo now, see my details on that in the forum post just above.
UI now being worked on, will upload more screenshots soon.

We are hiring and need your Help Bitcointalk!

We are looking for a Expert C programmer with some trading experience
Please find the job description here https://www.xbtfreelancer.com/project.php?id=2494
We only pay in BTC and per milestones. If you think you can take the job, contact us!

We are looking forward to your application

Is this thing even going to be traded anywhere?
What's going on with it?

C-IPFS and BlockPay related:
 
C-IPFS merkledag and data storage is under heavy development. Working with the "protobuf" protocol from google (data stream called Marshal and Unmarshal) was a requirement for storage (and probably networking in the near future), and we completed a very basic implementation of this late last night. We also added roll your own encode/decode, with helpers to make it easier. More features will need to be added as the use cases evolve, but this will be enough for now, for our needs.
 
Storage is a bear. At times it feels as if we're walking in mud. But then things start coming together on it. We're trying to be careful to not waste time on things we won’t be using.
 
Nodes with links will be finished up this coming week. Once nodes are a bit more finalized, namespaces (aka: directories) will need to be handled. These are not easy tasks, and are time-consuming. This coming week more of the storage "todos" are completed and we can move forward with the new BlockPay Core integrations.
 
More c-ipfs and c-ipns(lots of speed improvements thanx to the protobuf work) commits:
https://github.com/kenCode-de/c-ipfs/commit/496ae3ec6c13d1aaab1a630d8e7e8c425175d907
https://github.com/kenCode-de/c-ipfs/commit/f8723eb8c741a02dab3e7cc2096e989c27cb3425
https://github.com/kenCode-de/c-ipfs/commit/84f24797f4485b7b3eff14a99501a50a40f1fe9b
https://github.com/kenCode-de/c-ipfs/commit/7a3d0c5e0bf241d6126a125fc19fa8b3460b9af5
https://github.com/kenCode-de/c-ipfs/commit/73a76907258b1842dc77428f8cf756b3f7037b0a
https://github.com/kenCode-de/c-ipfs/commit/786bd5d80b729f33f0a97f331e0cdecfc8a87b49
 
C-IPFS to CJDNS protocol will be finished this week for our meshnet support. Everything becomes a node. Will reveal more on this later. The cryptography and IPv6 stuff should be done by tuesday. Tamper-resistance is built-in to C-IPFS, so this turned out to be the perfect marriage. If someone tries to hurt or stop BlockPay via http, ssl, dns, ddos or even killing the ISP itself, BlockPay now has its Plan B ready to go. (yeah, I have a lot of tinfoil)
 
Sealed up memory leaks and finished dnslink. Tons of additional work being performed/finished up this week on c-ipld (linked data), c-ipns, namesys, path and the command line interpreter.
 
We are also speeding up the Bridge (for shifting bitcoins/altcoins into Smartcoins, account creation etc) and I hired a UX girl to give the look a bit of a facelift in the next major version release, and make my dream of a 1-step setup a reality.
 
Android Smartcoins Wallet and security audits:
 
Added support for the 'account_update_operation' into our graphenej library being developed to enclose all graphene-related functionalities that might be re-used in other android (or java powered) projects. With this operation, it will now be possible to change permissions of any given account. The most relevant classes here are the AccountUpdateOperation, Authority and AccountOptions. I will post our graphenej open source on my github page once it's ready. This weekend I am doing a lot of beta testing first.
 
With this in place in the library it is now possible (and has been fully tested) to swap all keys for the owner, active and memo fields. It should also be possible (however this still has to be tested) to add an account as the authority for another account. For now only key authentication has been fully tested.
 
The immediate use for this newly supported feature is the swap of old keys for fresh new ones. And it will also be possible to give the user the possibility to change the controlling keys any time he/she desires.
 
More features updated:

• Import new .bin (since we are adding support for 6 additional blockchains)
• Export/Import compatibility with old .bin files
• Encode/Decode Memo Operations (this was a living hell)
• Beta testing debug apk's before we relaunch on google play
• Testing new form of websocket for multiple accounts
• The new client-side version-10 QR codes are working perfectly
• BIP39 is now fully supported and will work with the additional 6 chains
• Support added for importing/exporting to/from web wallets and light clients

Hopefully publishing the Smartcoins Wallet to google play tonight or monday.
 
Stealth related:
 
Finished up Stealth memo encryption/decryption, running final tests this week. UI now being worked on, will upload more screenshots soon.

It's all gone quiet.
What's happening? Are the devs on Slack?

TONS of work done this week:
https://github.com/kenCode-de?tab=repositories
 
C-IPFS and BlockPay related:
 
Work continued on the development of c-ipfs, in the area of data storage. Blocks are now written to both the lightningdb database, and the /blocks directory. We also wrote tests to cover more code, and adjusted existing code to clean up memory leaks. Valgrind now runs fairly clean over our tests of c-ipfs.
 
The difference between what is stored in the /blocks directory and what is stored in the database is not totally clear yet, but this week will hopefully uncover the rest of it. While successfully writing to block storage is a big accomplishment, block retrieval isn't finished yet. This task is minor in complexity though. Also, block storage must now be leveraged to take on the MerkleDAG and the unixfs code that runs on top of it. This will allow for files to be placed in namespaces (aka: directories), be broken into pieces, and read/found by local and remote BlockPay or mobile wallet clients.
 
More c-ipfs and c-ipns (was running very slow) commits:
https://github.com/kenCode-de/c-ipfs/commit/8da6e2df690d698067b2cb5615cce12f00a1f3bd
https://github.com/kenCode-de/c-ipfs/commit/0f5964ad3cb6fca94651001b43e76ae0ef3032ec
https://github.com/kenCode-de/c-ipfs/commit/ac4cc8feaaef747295b8705fa7f1b6d43d72f4dd
https://github.com/kenCode-de/c-ipfs/commit/a21330af436c0b9c6e8628f6f15acf1f0e2d37c0
https://github.com/kenCode-de/c-ipfs/commit/47e035e29f8d4870b6a9def0cb1a397cb91ac5bf
https://github.com/kenCode-de/c-ipfs/commit/d761e6062b7e92b69b604d96e42b80d58f7ebad9
https://github.com/kenCode-de/c-ipfs/commit/cba5839f5623af89bd969a959de1a7b0012bf908
https://github.com/kenCode-de/c-ipfs/commit/75f86b4107f87489efcd7b4ebea230cb8e24dd71
https://github.com/kenCode-de/c-ipfs/commit/8f686f6115c613614382e4599d73aa5e8d118bd6
https://github.com/kenCode-de/c-ipfs/commit/e89b5515c24ed32334f7bff04224b79b19257e7e
https://github.com/kenCode-de/c-ipfs/commit/a4b6a14ea524689556e9f9cf927a3519c64c0e24
https://github.com/kenCode-de/c-ipfs/commit/9ba3112b9705d48b7a333f43a4d11a45c5ad5d8f
https://github.com/kenCode-de/c-ipfs/commit/33afac194a0d6e6f153d3408ebacb3a2565ba030
https://github.com/kenCode-de/c-ipfs/commit/316c880bd1354a4649302c4429559c9f681de69e
 
We've been redesigning go-ipld-node + go-ipfs/merkledag/node + go-ipld, etc. to actually work together in C as they can't be preserved in go's form, the languages differ too much. Creating merkledag nodes, which can either be links to other nodes or data nodes, these will process data stored in files in the future (with merkledag done) assure validity of data, etc.
 
Android Smartcoins Wallet and security audits:
 
This week we streamlined a bunch of code and moved more of it to the client side so that now hardly any trips to the server need to be made. By letting the client do more of the work, it has sped the app up a bit and greatly reduced bandwidth utilization. BIP39 support has been added too (real words, instead of brainkey "weird" words). During the security audit, we have also made some other improvements this week:
Improved Websocket communication
Create Account Activity
Debugging Python server-side components
Encrypt/Decrypt AES
Compress/Decompress LZMA library
Export / Import Bin File Library, compatible with old bin files now
Export bin file Activity
Import bin file Activity (in progress)
A bug with the transfer transaction was fixed. The problem happened randomly and because of that was not caught initially. The reason has to do with the strictness of the graphene network on its approval of signatures. Sadly the bitcoinj doesn't provide support for non-deterministic signature generation, so we had to be creative when coming up with a solution. A valid compromise was deemed to slightly change the expiration time of the transaction in order to generate a valid signature. It is important to note however that this has no visible impact whatsoever for the user and the transaction gets processed super fast as always.
 
Improvements were made to the QR-code generation mechanism. The reliance on a server for the QR generation, encoding and compression of the eReceipt data has been dropped. This has had a dramatic improvement in the speed of the generation of a QR-code. And of course to be able to generate the QR-code while off-line is also a major advantage in speed and bandwidth utilization. The corresponding change in the procedure of decompression and decoding the data when reading a QR-code with the camera also had to be adjusted, since a server was being used there too.
 
graphenej in progress, BIP39 support added and now being tested.
 
Stealth related:
 
Libsnark is now fully integrated, replaced libsodium crypto primitives, finished notes encryption/decryption and fully tested. UI now being worked on, will upload more screenshots soon.

Each project needs a crazy visionary leader right

Did you know that we are actually transforming BlockPay with C-IPFS and are now able to install the BlockPay payment function on every hardware device on  the planet?! We could preinstall BlockPay in TV´s, printer, e-plugs, smart locks... micro transaction and multi chain point of sale systems are now coming to IOT thanks to BlockPay... Mindblown

Hi guys, I want to give you a short update about BlockPay and what we have been working on the last few days.

We had to fire our old marketing partners because they did not perform the way we wanted. We now added 2 more people to the core team who will be in charge of all social media channels and keep reporting about our journey. One of the first articles is out already, check out https://steemit.com/blockpay/@bitshares-munich/the-faces-behind-blockpay-christoph-and-rodrigo .

For direct updates please also follow us on Twitter https://twitter.com/BlockPay_ch and on Facebook https://facebook.com/blockpayde and on Steemit https://steemit.com/@bitshares-munich

Latest Development
Let us take a look at the current software development. We are making great process in the IPFS in C development and further decentralizing the BlockPay core and building up the BlockPay engine. This new DAP structure allows us to install BlockPay on any kind of hardware! Not only on Android and iOS but also on a raspberry pi´s and other mainframes. Imagine you could pay with your Bitcoin at vending machines, petrol stations, power sockets, doors, etc.
We are already talking with industry partners for upcoming integration.

On the other side, we are working on a redesign of the current UI/UX to increase merchant adoption. The onboarding process gets redesigned as well as the settings cleaned out. I will soon share some first design mockups to the community.

Meanwhile, we are ramping up development work with stealth transaction on the Bitshares blockchain. We are now able to hide (sender,receiver,amount,memo field, meta data) from blockchain explorers. Only a timestamp will be left. Stealth is a highly requested feature for all merchants who want to move corporate funds on a blockchain. With this feature, we actually build a hybrid between a public and a private blockchain and give the whole industry a new option to store and move funds on a blockchain. Together with a scalable blockchain, stealth transactions gonna be faster, more secure, more private and easier to use than ZCash or Monero. More exciting news about our development here in the following weeks.

cheers chris4210