CoinMarketCap API is offline and needs to be replaced.

• Create Dockerfile / docker-compose.yml to quickly start up development environment with monerod and monero-wallet-rpc running on testnet.
  This should somehow always be on master somehow, so there will need to be a way to download the latest successful build from https://build.getmonero.org/
• Derived from the above (or the other way round), a setup to run a permanent testnet node. Startup scripts for monerod and monero-wallet-rpc and cronjob for downloading and running latest build.
• Suggestions for a production setup, possibly different security levels:
  • Fool!
  • Default
  • Paranoid

Add an option to require the transaction being mined when the payment exceeds a configurable amount.

Instead of showing "Payment done", Kasisto will show that the transaction is incoming, but unconfirmed. It will then keep polling at a lower frequency until the transaction is mined.

The screen notifying of the unconfirmed transaction can be dismissed so the next payment can be processed. In that case, polling will continue in the background and a system notification will be shown when the transaction gets mined into a block.

Related: #30 #31

I request payment and pressed 15% by accident. Cant un-select it now. Would it be possible to add some button to remove the tip from the amount?

From the README:

To be fast (confirmation within seconds), Kasisto will accept unconfirmed transactions. Combined with the current transaction fees of around $0.25, the targeted payment amounts should be between $10 and $100. I don't know how likely it is that a transaction will not get mined, so every seller will have to find their own pain barrier. Similarly, buyers will have to find their own personal lower limit in regards to current transaction fees.

Regardless of current fees, I'd be interesting if anyone could comment on their personal maximum fee they're willing to pay, as a percentage of total amount being paid.

Is Kasisto built so that it can be connected to other Cryptonote coins?

I keep sending txs to https://amiuhle.github.io/kasisto/, but nothing is happening.

• Show / hide certain input fields
• Add more currencies / exchange rate providers
• Implicit decimal point

Hi there here is ArqTras from ArQmA team, can You send email witch contact details to [email protected] ;) telegram / discord

u/snrumph on Reddit:

Great job, but FYI there is already a financial-related software package and company called Kasisto. A name change while your project is young might save you some grief down the road.

http://kasisto.com/

The company is called Kasisto, based in NY City.
Their product is called MyKAI, it's some sort of messaging bot that connects to your bank and you can ask it stuff like how much you've spent on travel last month etc. So definitely finance related.

What should I do?

Currently only transactions from the mempool are considered when looking for relevant transactions.

Context (r/Monero)

• Better phone & tablet compatibility

Do you have demo running on v7 testnet? I think current demo https://amiuhle.github.io/kasisto/#/ is for v6 testnet only?

Here is my process so far @Lemonado114 @amiuhle . I am not sure if I can call it "wireframe" since I already styled it a bit

I only had time to do one view and that is BUYER on a IPAD and I made it so simple as possible for the buyer.

IPAD DESIGN
Changes

• I ditched the two columns idea since I want to make it so simple as possible
• The bill is minimized in a button that pop ups as overlay
• Big fat buttons, so you can use your fingers properly ;)
• I designed just centre everything and used no grid or template, let me know what kind of frame work we are building this in.
  

Discussion

• Do we need a seller view?, can it be hidden, do the buyer need to know the view..here is something we can discuss if the split view is optimal for this kind of transactions.
• Anything you see missing or have opinion let me know

Keep in touch!

Who will use this?

As stated in the README, the only requirement is an internet connection, but there are constraints regarding payment amounts and there's some technical knowledge required at the moment.

I can think of bars, cafes, restaurants and shops as potential users, but I'm sure there are many more.

Please comment below if

• You are someone who might use Kasisto. What kind of place, are there any special requirements?
• You know someone who might want to use Kasisto, and are able to help him set things up
• I forgot any obvious use cases above

It might be possible for a bad actor to submit a transaction to the network that never has a chance of being mined. Currently, a transaction that has too low of a ringsize is still relayed through the network, so it will look like a valid transaction waiting in the txpool to get mined into a block. However, it will never get mined into a block.

Also, kasisto should have a way of verifying that a transaction has been relayed to some other nodes - a quorum of random nodes. Just because a transaction is in the kasisto's daemon's txpool doesn't mean it will relay - I'm imagining a scenario where the customer uses the kasisto's daemon as a remote node to push a transaction. A transaction with too low of a fee will just get stuck on the kasisto's daemon, so it looks like a 0 conf, but it will never get mined.

from README.md:

# Download latest Monero release
curl https://downloads.getmonero.org/cli/monero-linux-x64-v0.10.2.1.tar.bz2 > /tmp/monero.tar.bz2
# Validate file
echo "9edba6ca91c35c6c2eb6816f9342931c88648de5beb471943ea63d0b16c9a2e4 /tmp/monero.tar.bz2" | sha256sum -c
# Extract binanries
tar -xf /tmp/monero.tar.bz2 -C /tmp && mv /tmp/monero-v0.10.2.1/* /usr/local/bin/

1. use --location argument for curl instead of >
2. use enviroment variable to store version (such as '0.10.2.1') and use it instead of hardcoded value.
3. don't use static filename in /tmp , see: "Safely Creating Temporary Files in Shell Scripts"
   http://www.linuxsecurity.com/content/view/115462/151/
   use mktemp command instead for temp file/dir.
4. remove the archive file after extract operation.

Generating a payment QR (on https://amiuhle.github.io/kasisto) creates a QR code with the integrated address instead of the "normal" address + payment id.

According to the monero QR spec the address should be the raw address and not the integrated address.

The application https://github.com/amiuhle/kasisto says Testnet when you request payment. But in fact its on stagenet. Its confusing, and can lead many ppl to try sending testnet xmr into it, instead of stagenet.

What's necessary to meet legal requirements? I'm thinking about taxes, but there might be more to consider.

Kasisto will expect some existing receipt from another system, most likely printed. When a seller creates a payment request with Kasisto, they will be able to enter an associated receipt id. This could be via keyboard input, taking a picture of the receipt or scanning a barcode containing the receipt id.

Considering the seller can print a payment confirmation for the buyer and can export or print a transaction history for themselves, would this be sufficient to meet legal requirements?

If it's some specific issue, e.g. a certain country, please provide details.

The exchange should contain information about the lowest floating exchange rate. From the point of view of the store owner, who will want to replace the crypto for fiat, it can not be lost on the exchange rate differences and the commission of a currency exchange office. The code shows only the current exchange rate.

https://stackoverflow.com/a/3439981/500999

I'm using your project. Very good. But it would be great if there was an ablility to copy the integrated address, so that I can copy and paste it into, for example, command line wallet, gui wallet, open monero wallet, send by email, post in chat, etc. Having QR code only is very limiting.

If there's more than one incoming transaction, the amounts should be accumulated. Needs monero-project/monero#1822

• Offline / Service Worker
• Add to homescreen

PIN/password protection to sensitive information/configuration

Let's have an attacker with modified wallet trying to purchase goods from a merchant using Kasisto. The attacker's wallet is modified in a such way, that while apparently sending the transaction, it does as follows:

1. Prepares the real transaction R to the merchant.
2. Prepares false transaction F, sending the same inputs to a wallet controlled by the attacker.
3. Simultaneously injects these transactions into the network through different nodes.

The results are:

4. Both transactions spread across the network.
5. Once a node has received either R or F, it rejects the other transaction as double spend.
6. The network divides in two groups. One holds R in the mempool, the other holds F.
7. When a block is mined, one of those transactions gets included, depending on which group the lucky miner was in.
8. The other transaction either gets purged from the mempool or stays there as invalid until it times out (I don't know which one will happen, that depends on daemon's behavior).

What scenarios can we expect?

• A: the node used by the merchant receives R but actually F is mined: in 0-conf mode this is the worst scenario. The merchant thinks he received the money but actually he doesn't.
• B: merchant's node receives R and R is mined: the attack fails, the scammer actually pays for the merchandise.
• C: merchant's node receives F and R is mined: because F is illegible for merchant's wallet (is encrypted with a different key) nothing happens until R has been mined, and the real payment succeeds then. The attack fails.
• D: merchant's node receives F and F is mined: merchant doesn't see any incoming payment

By rough statistics, the attacker has 25% of success, however:

• if case D occurs, the attack can be easily repeated at no other cost for the attacker than another tx fee,
• if the attacker knows which node the merchant is using, he may inject R there directly (if merchant uses a public node) or to its peer, dramatically increasing the possibility (100% or close) that the real payment shows up on POS
• if the attacker has knowledge on hashrate distribution among nodes, he may inject F to the nodes having powerful hashrate at their disposal, dramatically increasing chance of F being mined.

Preliminary conclusions:

• 0-conf mode should be described with a big red warning recommending to wait for at least 1 conf at payments of significant value,
• it should be recommended to the users to run their own node,
• Kasisto should detect when variant A happens and warn about scam, (I'm very curious how the standard wallet behaves here, too)
• it's important to check how actually daemon deals in situation from step 8 - having a double spend in the mempool when a block with the other tx arrives

I think I could help with staging such attack scenario on the testnet, if you decide it's worth investigating.

Chrome 57, Firefox 52 and Safari 10.1 support CSS Grid Layout now. Safari 10.1 also brings some more cool stuff, but iOS doesn't support this, yet.

When are those features expected to land in iOS?

By making a very simple modification to the monero-wallet-rpc, one can generate a valid low priority transaction that is small enough to be relayed, but large enough to never be confirmed by the network. After looking through the code. I looked through the code and I didn't see a protection against this kind of attack.

After 24 hours this transaction will drop from the mempool and the sender will be able to use the Monero again.

Sitemap/ User Flowchart 1.0

(Download it to zoom)

Since I am visual guy I need this kind of map to understand both technical and how the experience is for a user. Still not sure what kind of feature is possible, correct me @amiuhle Timo if something is not possible, wrong and want to add. What I understand this is a web app.

COMMENTS __________________________________

• Add to homescreen @ between LOGIN and MAIN SCREEN is a neat feature and could encourage the user to do it for easy access.

• Main screen could be hamburger menu or a screen. That depends whats the best for user, needs more exploring. I think we could squeeze most of it in ONE screen for easy access, hamburger menu could be for settings and other feature that dont need quick actions.

QUESTIONS __________________________________

• SIGN UP, what do we need from the user, email and pincode? Or additional password?

• SETTINGS @main SCREEN, not sure what kind of settings there could be available, need more info.

• Forgot pincode @ALL ENTER PIN BOX is this possible to have as a feature?

• ENTER TIP AMOUNT @Buyer VIEW I recall there is a problem with the QR code if the amount was changed, reference: #9 . Add a refresh button perhaps near the QR code after a tip amount is entered?

Hope you get use for this also when building it
cc @amiuhle

End user documentation with screenshots

Show & export a list of requested / received payments

• Show list of payments with status
• Import / export payment history (JSON)
• Payment detail view
• Filters for display / download

Settings view

• Jest UI / Snapshot testing setup
• Configurationn options for
  • Endpoint URL
  • Authentication
  • Receipt input

On my LG X Charge Android phone, if I input 500 into the payment amount the 5 is partially cutoff on the left side of the screen. Using more digits than that, the learing digits are completely off screen/under an invisible margin. Is phone not designed use case it is this bug?

There are some unique opportunities appearing where Kasisto, XMR hardware, Monerujo, and Globee can interface together. Doing this properly showcases the added value of each project working together.

Please contact Monero Hardware [email protected] so that we can arrange a meeting of some sort, to discover the best way to implement such a system. I'm really enthusiastic about this kind of new service.

Cheers,
Michael

Do you have an option to use sub-addresses, or plan to support them, instead of integrated_addresses?