Author Topic: [ANN] BlockPay -Your favorite store can now accept any crypto thanx to Bitshares  (Read 99745 times)

0 Members and 1 Guest are viewing this topic.

Offline serejandmyself

  • Sr. Member
  • ****
  • Posts: 358
    • View Profile
btsx - bitsharesrussia

Offline kenCode

  • Hero Member
  • *****
  • Posts: 2283
    • View Profile
    • Agorise
Lots of updates this week:
https://github.com/kenCode-de?tab=repositories
 
I am very sick tho. First my girls got it, then my wife got it, now I have it. Going back to bed now. Will try to post a more thorough update for you in a couple days.
kenCode - Decentraliser @ Agorise
Matrix/Keybase/Hive/Commun/Github: @Agorise
www.PalmPay.chat

Offline bilthon

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.

I wonder if block time could be just calculated from: Head block time,  number of block with transaction and average block production per second. If that average keeps tight result could be accurate enough.

Interesting point. I actually don't know how the bitshares, being a distributed network manages to keep producing blocks in such a precise 3 seconds interval. But regardless of that, I guess the real question here would be how precise the block production is. I did some quick comparisons and produced this preadsheet https://docs.google.com/spreadsheets/d/13H4qqgMosIb_ON3dbBqBIKna_3Z1SLLIRCRZgC2X7sk/edit?usp=sharing.

As you can see if the block are closely spaced the error is low. For market data I suppose we don't need extremely high time accuracy, but anything that deviates more than an hour from its "real" trading time might be too much.
« Last Edit: January 05, 2017, 02:32:18 am by bilthon »

Offline nmywn

  • Sr. Member
  • ****
  • Posts: 266
    • View Profile
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.

I wonder if block time could be just calculated from: Head block time,  number of block with transaction and average block production per second. If that average keeps tight result could be accurate enough.

Offline kenCode

  • Hero Member
  • *****
  • Posts: 2283
    • View Profile
    • Agorise
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.
kenCode - Decentraliser @ Agorise
Matrix/Keybase/Hive/Commun/Github: @Agorise
www.PalmPay.chat

Offline kenCode

  • Hero Member
  • *****
  • Posts: 2283
    • View Profile
    • Agorise
stealth by February all I care about! I'm not a criminal. thanks.
 
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...
« Last Edit: December 30, 2016, 09:08:11 am by kenCode »
kenCode - Decentraliser @ Agorise
Matrix/Keybase/Hive/Commun/Github: @Agorise
www.PalmPay.chat

Offline ag

  • Full Member
  • ***
  • Posts: 132
    • View Profile
stealth by February all I care about! I'm not a criminal. thanks.

Offline ebit

  • Committee member
  • Hero Member
  • *
  • Posts: 1905
    • View Profile
  • BitShares: ebit
« Last Edit: December 24, 2016, 03:17:03 pm by ebit »
telegram:ebit521
https://weibo.com/ebiter

Offline kenCode

  • Hero Member
  • *****
  • Posts: 2283
    • View Profile
    • Agorise
Not sure Thom, you'd have to ask Chris. I love that flic though, have it in my favorites:
https://www.youtube.com/watch?v=lEV5AFFcZ-s
kenCode - Decentraliser @ Agorise
Matrix/Keybase/Hive/Commun/Github: @Agorise
www.PalmPay.chat

Offline Thom

RE: BlockPay - Chris, Rodrigo and Sylvia at Thrive Int'l:
https://vimeo.com/196627019

Is this the very same "Thrive" movement as in the 2012 movie of the same name created by Foster Gamble?

I think that was an  A W E S O M E  flick, and totally believe in it's thrust, especially the free energy movement on which I have experimented and confirmed actual phenomena, like magnetic monopoles which I confirmed by building this:

Injustice anywhere is a threat to justice everywhere - MLK |  Verbaltech2 Witness Reports: https://bitsharestalk.org/index.php/topic,23902.0.html

Offline kenCode

  • Hero Member
  • *****
  • Posts: 2283
    • View Profile
    • Agorise
Another mountain of commits:
https://github.com/kenCode-de?tab=repositories
 
C-IPFS and BlockPay related:
 
Tons of work finishing up the data storage algo. The storage components are now importing files and raw data, as well as retrieving what was stored.
  • config file "ipfs init" is done
  • cli is done (not robust, but it's enough for our needs) and usable for end users (or anyone who wants to start playing around with c-ipfs now)
  • "ipfs add [filename]" done, still need "ipfs add -r [directory]"
  • "ipfs object get [hash]" done, still need "ipfs object get [path]"
They all work today, but the hashes that you add are not perfectly compatible with the existing Golang ipfs implementation. By the end of this coming week, you should be able to do those commands, plus..
  • “ipfs add [directory]” and “ipfs add -r [directory]” and the hashes will match the Go version.
  • In IPNS, DNS is now implemented with the "ipfs dns" cli command completed as well.
  • libp2p-routing is near completion, just a few more days on this one.
The goal for this last week was to get something installable. While an end user could install the application and use it, I do not feel the goal was reached. I feel that at a minimum, the following 3 items must be completed:
  • Storing of files (done) and directories (almost done)
  • Go versions and C versions should perfectly generate and share the same hashes for the same file.
  • Connecting and retrieving / sending data over a network. Not necessarily bitsharing, but the ability to get and share a file from/to peers.
What is planned for this coming week:
 
In order to share files between the C version of ipfs and other versions, the hashes must match perfectly. We are a lot closer to making that happen, but not yet. I am hoping this will be perfect in about a week. As well, the ability to import directories needs to be finished. That's almost done too.
 
Just a few of this week's IPNS commits:
https://github.com/kenCode-de/c-ipfs/commit/b914745b476926a5bd0d4c254aed8bec51707b5c
https://github.com/kenCode-de/c-ipfs/commit/a94aa609b968ffe4ad6bad0c7366212c4104a383
https://github.com/kenCode-de/c-ipfs/commit/41b7579f21b9ccdb10dc407d2055fa6e43fa8335
https://github.com/kenCode-de/c-ipfs/commit/6b9d205ef2c3b09c4e0511d10303d83259fedcc6
https://github.com/kenCode-de/c-ipfs/commit/b17403b61acbea5cf87a55f560705e30be11a243
https://github.com/kenCode-de/c-ipfs/commit/049078effcd5468c750292162dc9577ffe54ea86
https://github.com/kenCode-de/c-ipfs/commit/7691fe0dc223b42db415a1e7b7cf6ffadac9bb15
https://github.com/kenCode-de/c-ipfs/commit/5f22be643cfd50b7390778397a911fcedef32796
https://github.com/kenCode-de/c-ipfs/commit/a569159cc2355b9c04b97083575040a4e62ee0b6
 
So, the cli is ready if you would like to grab it from my github, and a download with the 3 remaining things above will be published in a week or so with the Release here:
https://github.com/kenCode-de/c-ipfs/releases
 
Android Smartcoins Wallet and security audits:
 
The automatic key update was deemed too dangerous and thus was replaced by a new more detailed walk through process, with more information about which accounts are being updated and the results.
 
The PIN/lock dialog as it was implemented, was very easily bypassed, so a more robust scheme has been introduced and applied over every activity in the app. At some point that introduced a bug that displayed the dialog when it was not supposed to, but that too has been fixed.
 
The support for memo encoding/decoding in our new graphenej library (https://github.com/kenCode-de/graphenej) was broken, in the sense that it was not following exactly the same procedure the network expected. As a result, memos sent and received by the app were not being properly encoded/decoded, sometimes displaying some garbage (like "**") instead. This was fixed and memo information was also introduced in the database schema. So now they appear properly in the list of transactions on the homescreen.
 
Also the support for the 'get_market_history' API call was added to graphenej. With this in place we'll be able to query the market historical data and get equivalent values for past transactions. This will be done only once upon app install, and kept locally in the database. Minor bugs and problems were fixed.
 
One user reports not being able to send the bitUSD out of his mobile wallet, so we are looking into that this week after the holiday.
 
eReceipts, Export features based on timeframe, and Equivalentvalue display has also been upgraded to use graphenej. Lots of speed improvements added throughout the app.
 
Regarding adding support for real Bitcoins:
  • Implementing CryptoCore Design (in progress). Since the Smartcoins Wallet will support 7 different blockchains, we are modularizing the code quite a bit more, streamlining where possible.
  • Creating Bitcoin Account on testnet (done)
  • Getting Balance from testnet (done)
Other than that, it's mainly just UI fixes at this point to take advantage of our graphenej and all the new backend security work that has been done. Plus, we now have interoperability with the web wallets and light client wallets.
 
Swapping out the keys on your accounts (if you desire) costs 0.2 BTS so make sure you have at least a little bit of BTS in the accounts that you want to leverage the new upgraded security model.
 
As always, never store more funds in your wallet than you can afford to lose. With your understanding of that disclaimer, the latest version of the Smartcoins Wallet can be downloaded from here:
https://play.google.com/store/apps/details?id=de.bitsharesmunich.smartcoinswallet
 
Stealth related:
 
All functionality for Stealth transactions consists of 3 layers: base crypto mech, joinsplit itself, and the graphene integration (https://github.com/kenCode-de/graphene/tree/stealth). First layer is completed and tested, the second is mostly completed, and the third is not ready yet (waiting on c-ipfs above). My guess, the way we are going, we might be able to have Stealth ready for launch by end of february (no promises). This includes public beta testing time on our testnet too. So, cross your fingers for us, we're rockin this hard.
 
The Stealth api emulator is running on our testnet already which is what the UI guys are working with, but the final api can be launched once the c-ipfs stuff (above) is completed. In other words, about a week.
 
Other items finished:
  • joinsplit implementation
  • Stealth api emulator in wallet, interface, emulation, debug
  • Installed local testnet to debug stealth wallet api
We've got some decent work done on the UI, but now the UI is on hold for a few days until the c-ipfs stuff (for Auto-Backup) is ready next week. At that point, the UI work can resume again and I can start uploading more of the screenshots.
kenCode - Decentraliser @ Agorise
Matrix/Keybase/Hive/Commun/Github: @Agorise
www.PalmPay.chat

Offline kenCode

  • Hero Member
  • *****
  • Posts: 2283
    • View Profile
    • Agorise
« Last Edit: December 23, 2016, 11:39:48 am by kenCode »
kenCode - Decentraliser @ Agorise
Matrix/Keybase/Hive/Commun/Github: @Agorise
www.PalmPay.chat

Offline Chris4210

  • Sr. Member
  • ****
  • Posts: 431
  • Keep Building!
    • View Profile
    • www.payger.com
  • BitShares: chris4210
I just listened to Christoph's Blockpay update on Beyond Bitcoin (E185 2016-12-09).  He mentioned a Stealth transaction would be fully invisible except for the time stamp.  It would be able to compete w/ the likes of Monero and Dash.  A full stealth transaction would cost roughly 40 cents.  His stealth talk starts around the 01:42:00 hour mark.

I wasn't aware of all this and think this is a huge development.  I thought stealth would only hide the transaction amounts.  Considering all the hype from Monero and Zcash, I would've thought everyone would be pumping BTS.  Are we going to see any of this info coming from the new Social Media Manager and Content Manager hired at Blockpay?

And how does the $0.40/txn compares to Monero or Dash?  This amount seems a bit high.


Yes, stealth will hide all sensitive information and just show "unknown send to the unkown unknown amount" . Plus a timestamp on the blockchain. We will share more news about our development over our social media channels soon too. However, stealth is another product of BitShares Munich and will be added to our products in 2017. It has been developed for our supermarket clients who want to gain more privacy in their daily business.

$0.40 USD/txn seems high at the beginning, however, I am convinced that stealth should be used more for high-value transaction and not micropayments. Also adding a higher price for privacy will keep black market money away because they can launder their money cheaper elsewhere. We are not interested in any illegal activities nor do we support black market trades. There is enough white market business for all of us.
Vote Chris4210 for Committee Member http://bit.ly/1WKC03B! | www.Payger.com - Payments + Messenger | www.BitShareshub.io - Community based fanpage for the BitShares Blockchain

Offline ebit

  • Committee member
  • Hero Member
  • *
  • Posts: 1905
    • View Profile
  • BitShares: ebit
telegram:ebit521
https://weibo.com/ebiter

Offline kingslanding

  • Full Member
  • ***
  • Posts: 90
    • View Profile
I just listened to Christoph's Blockpay update on Beyond Bitcoin (E185 2016-12-09).  He mentioned a Stealth transaction would be fully invisible except for the time stamp.  It would be able to compete w/ the likes of Monero and Dash.  A full stealth transaction would cost roughly 40 cents.  His stealth talk starts around the 01:42:00 hour mark.

I wasn't aware of all this and think this is a huge development.  I thought stealth would only hide the transaction amounts.  Considering all the hype from Monero and Zcash, I would've thought everyone would be pumping BTS.  Are we going to see any of this info coming from the new Social Media Manager and Content Manager hired at Blockpay?

And how does the $0.40/txn compares to Monero or Dash?  This amount seems a bit high.
BTS username/address:   kingslanding9999