Hi,

I've checked that I followed the instructions and I have Googled for this error, but none of the results seem conclusive or apply.

It's my first time with the Arduino IDE, but it seems to have found and I've installed the libraries required, and though I'm still waiting for the hardware, thought I'd get about preparing for its arrival by verifying, by compilation, the set up.

If there's any additional information required, please advise.

This isn’t an issue. Just not sure if I can send messages in GitHub. Really just wanted to say thank you for such a cool project. You’re doing such cool stuff and it’s so cool that you’re being open about it and letting everyone have the code and even show them in a video how it all works. So cool!

I had a pet project a few years back related to Ninja Warrior-type timing for a local business. It was such a fun hobby and seeing your work makes me get back that excitement. Now my mind is racing thinking about doing something with your project with something like an arcade, vending machine, art-piece, etc. Those things have been hampered in my mind due to lack of internet connection in some locations (and paying for cell access was not worth it).

I think with your system the vendor has to look at a customer’s phone to see the pin code, right? Could that pin code be replaced by a QR code and then the arcade/vending-machine has a camera that confirms the code? That way everything could be totally unmanned, right?

Anyway, now I have to think up a project. My wife will probably be mad at you. :)

Thanks again!

Love your work Ben...

The link to the TTGO actually has 4 options (2 different chips and memory choices)

Can you advise which one is needed (or if it doesn't matter). Thanks

Options are

• ch9102f chip (4 & 16 mb)
• ch340k chip (4 & 16 mb)

Overview

In this PR I suggest a few changes in the encoding format of the lnurl data:

• pack nonce together with encrypted data and HMAC
• extend HMAC size to 8 bytes and cover everything with it
• use base64url encoding instead of hex for shorter urls
• make the whole thing more extendable (see below)

Other changes:

• improves nonce randomness (it was using random(9) for every byte, now it's random(256))
• updates uBitcoin to the latest version that now includes base64 urlsafe encoding

Encoding format

Suggested data encoding has the following format:

• first byte tells what encryption scheme is used - it's set to 0x01 for XOR-encryption (that is ok for data smaller than the key size), later we can extend it with other encryption formats like AES-CBC-HMAC and what not.
• next we encode the nonce in the form <len><nonce>, in this implementation we use 8-byte nonce but it can be extended if required.
• next we have the encrypted payload in the form <len><payload>
• finally we have 8-byte HMAC (or more if needed). HMAC covers all the data before.

Keys

Keys are derived from a shared secret. There are two keys - for encryption and for authentication. Round secret for encryption is calculated as hmac(key, "Round secret:" | nonce), HMAC at the end is calculated as hmac(key, "Data:" | payload).

Payload

Payload is a simple XOR of the round key with actual data contains the following items:

• PIN encoded as varint
• Currency byte ($ for USD cents, can be extended to other currencies as well)
• amount in cents encoded as varint Nice thing about varints is that it can encode any number between 0 and 2^64 with 1-byte overhead. For values up to 252 it takes only 1 byte. See https://en.bitcoin.it/wiki/Protocol_documentation#Variable_length_integer

Python decoding implementation

Resulting LNURL can be decoded with the following python script (using embit library here, but can be easily adopted to any other bitcoin library):

from embit import bech32
from embit import compact
import base64
from io import BytesIO
import hmac

def bech32_decode(bech):
    """tweaked version of bech32_decode that ignores length limitations"""
    if ((any(ord(x) < 33 or ord(x) > 126 for x in bech)) or
            (bech.lower() != bech and bech.upper() != bech)):
        return
    bech = bech.lower()
    pos = bech.rfind('1')
    if pos < 1 or pos + 7 > len(bech):
        return
    if not all(x in bech32.CHARSET for x in bech[pos+1:]):
        return
    hrp = bech[:pos]
    data = [bech32.CHARSET.find(x) for x in bech[pos+1:]]
    encoding = bech32.bech32_verify_checksum(hrp, data)
    if encoding is None:
        return
    return bytes(bech32.convertbits(data[:-6], 5, 8, False))

USD_CENTS = b'$'

def xor_decrypt(key, blob):
    s = BytesIO(blob)
    variant = s.read(1)[0]
    if variant != 1:
        raise RuntimeError("Not implemented")
    # reading nonce
    l = s.read(1)[0]
    nonce = s.read(l)
    if len(nonce) != l:
        raise RuntimeError("Missing nonce bytes")
    if l < 8:
        raise RuntimeError("Nonce is too short")
    # reading payload
    l = s.read(1)[0]
    payload = s.read(l)
    if len(payload) > 32:
        raise RuntimeError("Payload is too long for this encryption method")
    if len(payload) != l:
        raise RuntimeError("Missing payload bytes")
    hmacval = s.read()
    expected = hmac.new(key, b"Data:" + blob[:-len(hmacval)], digestmod="sha256").digest()
    if len(hmacval) < 8:
        raise RuntimeError("HMAC is too short")
    if hmacval != expected[:len(hmacval)]:
        raise RuntimeError("HMAC is invalid")
    secret = hmac.new(key, b"Round secret:" + nonce, digestmod="sha256").digest()
    payload = bytearray(payload)
    for i in range(len(payload)):
        payload[i] = payload[i] ^ secret[i]
    s = BytesIO(payload)
    pin = compact.read_from(s)
    # currency
    currency = s.read(1)
    if currency != USD_CENTS:
        raise RuntimeError("Unsupported currency: %s" % currency)
    amount_in_cent = compact.read_from(s)
    if s.read():
        raise RuntimeError("Unexpected data")
    return pin, amount_in_cent

def extract_pin_and_amount(key, lnurl):
    # get normal url from lnurl
    url = bech32_decode(lnurl).decode()
    # get payload part
    payload = url.split("?p=")[1]
    # add padding
    if len(payload) % 4 > 0:
        payload += "="*(4-(len(payload)%4))
    # decode from urlsafe
    data = base64.urlsafe_b64decode(payload)
    pin, amount_in_cent = xor_decrypt(key, data)
    return pin, amount_in_cent/100

if __name__ == "__main__":
    # shared key
    key = b"Enrt4QzajadmSu6hbwTxFz"

    # two example LNURLs
    lnurlarr = [
        "LNURL1DP68GURN8GHJ7MR9VAJKUEPWD3HXY6T5WVHXXMMD9AKXUATJD3CX7UE0V9CXJTMKXGHKCMN4WFKZ7JJCF4595EPCD9G5V46K895KU4RNVGM8VJMR8ACR6S23VA58QMR0VER4Q335F3G4VCTCDFQKUS242C6XXCN88PF9WE66PAN3K5",
        "LNURL1DP68GURN8GHJ7MR9VAJKUEPWD3HXY6T5WVHXXMMD9AKXUATJD3CX7UE0V9CXJTMKXGHKCMN4WFKZ7JJCF4595EPCD9G5V46K895KU4RNVGM8VJMR8ACR6S23D999YNN4FAV5KJJ8WFQK2D332F2NVTTND4RY7425DUC97KRSX5MKKA89JNW",
    ]
    for lnurl in lnurlarr:
        pin, amount_in_usd = extract_pin_and_amount(key, lnurl)
        print(f"Pin: {pin}, amount: ${amount_in_usd}")

The PoS have been working just fine, but recently, when I wanted to do another, this new one doesn't work. Everything is fine, the keypad woks, the display works, but there's seems to be a problem with the QRcode. The display shows the QRcode but when I scanned it with a LN wallet it shows this error: ¨An error occurred while attempting to retrieve an invoice from demo.lnbits.com! Reason: Invalid character '<' This is in Breez but the same happens with other wallets, they say "invalid character '<' ". And when you try to pay with Muun wallet it doesn't even let you pay, it says: "This seems like a LNURL code. It allows you to receive bitcoin via lightning, instead of sending it. Do you want to use it?" But I think that's a different issue. If someone knows what that character means or how to fix it, please let me know. I really wanna use this PoS for accepting Bitcoin payments in my business.

I have an idea of how to make this even cheaper by replacing the display with a clock chip (a cheap RTC).

Let the URL contain an encrypted secret, and let the server add a timestamp to that secret using the current time and some simple maths (xor or similar). Other information may be encoded in as well. The result is returned as a PIN. User enters PIN, timestamp is removed by XOR with the device's time (use 30 second or minute intervals and check values for a few minutes back and forth) and compare the resulting PIN with the fixed PIN on the device. The device can even correct it's own time if it consistently gets PINs based on time in advance or in the past.

Other information may be coded in as well.

Example, a very simple slow car charger. Price is 100 sat per hour, maximum 8 hours:

1. User scans fixed QR code with LNURLp and encrypted secret s.
2. User pays 200 sat for 2 hours.
3. Server decrypt s and xor decrypted s with encoded current time and 2 for 200 sat.
4. Server returns PIN.
5. User enters PIN.
6. PoS terminal removes time and secret and check the result for valid values (1-8).
7. In the first or few attempts it will get the valid value 2 and close the relay powering the charger for 2 hours.
8. If all the 10 past PINs indicated a time in the future or past, advance or revert the RTC by one minute.

The time and amount must be encoded in a way that minimizes the chance of a wrong amount becoming valid within a reasonable time scope.

Interesting work. I think it's a good step towards offline payments, but it still requires the customer to have connectivity. I'm looking for a system that enables payments in the case of an emergency, such as a large-scale blackout. LoRaWAN networks (e.g. Helium) would be a perfect technology to create a fail-safe method for connecting, since these devices don't require much power and can easily be kept online by emergency generators.

So my idea would be a PoS that is connected to LoRaWAN and does not require the customer to have connectivity. The payment workflow would then look like this:

1. The merchant enters the payment amount and creates a LN invoice.
2. The merchant sends the invoice to the customer, who signs it and sends the signed message back to the PoS.
3. The PoS uses its LoRaWAN connectivity to send the signed message off.

I'm wondering if this is somehow possible?

Reset default LNURLPoS endpoint details to satoshigo.app

Updated defaults for sleep timer - 30 seconds Battery display disabled by default until battery level code is fully tested on multiple devices.

The device does not appear to automatically go into PretendSleeping if the device is in a deep sleep mode. This means that if the device is sleeping and it is then plugged in, the device does not charge (according to Blackcofee). If it is possible, I believe we should trigger PretendSleeping as soon as a charging voltage is detected - although that might be a challenge since the device is in deep sleep and may not be able to execute those instructions from that state.

Similarly, the device does not appear to go into a normal deep sleep automatically from a PretendSleeping state. Meaning, if I am charging the device and it is in the Pretend Sleeping state, but then I unplug it without waking it up, it seems to remain in the PretendSleeping state which likely will cause severe battery drain.

While in normal deep sleep all keys in column 1 will wake the device. While in PretendSleeping state, only the reset (*) key will wake the device. This can be confusing for the user if there are different waking rules depending on the state.

• I had problems with the compiler with the qrcode directory, I had to put it in a new director called qrhelper to get it to compile
• there were two versions of the hmac_256 method in Bitcoin, causing a link error
• Also update uBitcoin to 1.2