Szilard Gabor LADANYI - 2024

Bitcoin Payment Solution

Introduction

Our company, — sziller.eu — offers a bitcoin-based Solution for productive capital growth, tax optimization, and achieving continuous bitcoin liquidity, eliminating the effects of price inflation. We provide a comprehensive solution for accepting bitcoin payments in our clients' stores.
Additionally, we create the opportunity to generate direct, sovereign, capital-based profits from the bitcoin held in the business. Our solution covers everything from receiving bitcoin, payments, invoicing, to accounting and clarifying secure storage details.

Our solution is built on the following five principles
Note
  1. The long-term appreciation of bitcoin provides reliable protection against inflationary effects.

  2. A business’s bitcoin-accounted income is tax-free until the profit made in bitcoin is realized.

  3. Bitcoin assets - within the business, without external parties - can be capitalized, generating bitcoin revenue, providing additional income for the business - within a secondary business model.

  4. Due to the nature of our client’s commercial activities, without additional effort - they enjoy a competitive advantage in the mentioned secondary business activity.

  5. The secondary activity is inherently given as a result of bitcoin acceptance; it can be increased gradually, organically, and scalably.

In summary

Using the tax-free income(!) kept in the business, we generate income in a continuously appreciating asset through a secondary business activity (where our client has an increased competitive advantage). We do this in a way that the unfavorable exchange rate fluctuations do not affect the secondary business activity, so we never have to realize a loss due to exchange rates.

Our presentation details the key aspects of the bitcoin-based payment solution provided by our company — sziller.eu — to retailers, along with the necessary technological background for understanding. In designing and implementing the Solution, we consider three fundamental convenience goals in addition to the numerous advantages discussed in the remainder of the document:

  • We solve all issues arising during acceptance (receipt, invoicing, payment) for the Client…​

  • …​and during income management (settlement, accounting, storage, conversion, transfer).

  • We offer a seamless payment option in bitcoin for the customer of our client.

Our Clients

Our solution is designed for retail units or chains in Hungary that are required by law to use cash registers. The typical goal is to process small, instant payments using bitcoin and then make reasonable use of the income generated. We build the presented solution modularly. We also develop tailored additions for individual stores upon request.

Note

Our client is the retailer who accepts bitcoin, thereby enabling their own customers to pay in bitcoin.

We are aware of the novelty of bitcoin, so we seek out our clients in targeted geographical areas - mainly in university areas or environments inhabited by young families for the following reasons.

Our Clients' Customers

Bitcoin, as the only truly decentralized and global currency and network, is an open-source technology. Its popularity and value are continuously rising. The technology built around Bitcoin is developing at a breakneck pace due to its open environment. Today’s teenagers and young adults are familiar with using it for trading, investing, payments, or speculating, or they develop bitcoin-based software and applications. Second-layer developments built on bitcoin now offer solutions accessible from everyday browsers.

Within one or two years, bitcoin’s database will also serve as the basis for traditional currencies without the end-user even being aware of it. The first examples are already emerging: Twitter and Strike already use Bitcoin as the backbone for traditional transfers, and El Salvador is the first country to officially recognize it as a legal tender.

Bitcoin in Hungary appeals to the younger generation from several directions:

  • technological interest

  • autonomous financial decision-making

  • desire for self-determination

  • novel and stable investment opportunities

  • the romantic, rebellious, and at the same time inevitable need to rethink the global economic system.

This age group is not only curious but also willing to make an effort to use new technology. Bitcoin payment options offered in retail units around universities may be used for their novelty, or even for the demonstrative representation of users' principles. And there’s a bunch of geeks who use bitcoin because they’re geeks. In a university town, we can expect a willingness to pay with bitcoin:

Because it’s cool, it’s fun, it’s youthful, and it’s educational. And because the banks can go to hell…​

Among the 40-somethings with higher education, the number of those with bitcoin income is increasing. Their disposable bitcoin income can also potentially be spent in our clients' stores.

These two groups are worth targeting. What our customers gain from using bitcoin is detailed in a later chapter: Why is it good for the customer?

→ jump to the beginning: Bitcoin Payment Solution

What is our goal with bitcoin acceptance?

Our Solution pays off for the Client based on two interrelated logics, so it’s worth separating the goals according to these two aspects.

Note

Beyond the fact that the two different logics independently provide benefits to the business, they are organically built on each other:
the ongoing realization of the secondary goal facilitates achieving the primary, more significant profit-driven goal.

Primary goal: Capital accumulation and tax optimization

How do we achieve the Primary goal, outlined in the introduction?
 — How do we keep our income in the business tax-free, while generating additional income using it in a continuously appreciating global currency?

Let’s accept bitcoin, place the bitcoin liquidity into revenue-generating payment channels that we control, where the advantage is that we continuously generate bitcoin income as merchants, possibly even in these channels.

The advantages of achieving the Primary goal include
  • The Client generates income in bitcoin, which:

    • as long as it remains within the business, is tax-free

    • They effortlessly access a global currency, accepted without geographical or legal jurisdiction.

  • Bitcoin income is fast and final:

    • The transfer is final. There is no risk of retroactive settlement, it is impossible to reverse: payment risk decreases.

    • There’s no need to rely on banks or credit card companies for direct payment: dependence on external parties decreases.

  • They acquire an asset in bitcoin:

    • Properly stored bitcoin defies even the most creative minds.

    • Bitcoin has been the best-performing asset of the last ten years. Based on what we have seen so far, significant price appreciation is likely for value stored in bitcoin.

    • It provides protection against inflation, countering the exchange rate risk of the local currency.

    • It diversifies the company’s cash reserves - its assets.

    • It reduces the merchant’s Fiat cash exposure.

    • They can directly, confidentially, and in a non-traceable manner acquire bitcoin.

  • They can generate revenue on the Lightning Network, independent of the primary business model:

    • thereby diversifying their business model and cash flow,

    • justifying keeping bitcoin revenue within the business (beyond tax optimization)

    • all with minimal added effort.

  • They become part of a rapidly growing global decentralized network, during its build-out phase, gaining an advantage over those who join later.

What does the business need to enjoy these benefits and achieve its Primary goals? - primarily continuous bitcoin liquidity. I detail this very important aspect under the Liquidity point.

Supplementary goal: Continuous liquidity

  • How do we ensure continuous liquidity in bitcoin to achieve our Primary goal?

By continuing to sell goods as merchants.
Bitcoin acceptance generates income on its own,
while also creating the necessary liquidity, which is a prerequisite for achieving the Primary goal.

Note

Conversely:
we purchase continuous bitcoin liquidity from our customers in exchange for our goods.

Other advantages of achieving the Supplementary goal
  • The Client generates income in bitcoin, thus:

    • the number of customers increases,

    • they diversify their customer base with a completely new currency.

  • The Lightning Channel payment encourages customer loyalty. Due to the nature of the payment, a loyal customer mentality develops.

  • Bitcoin income is fast and final:

    • without the need for additional devices, they can accept instant payments with a simple mobile phone and a running application. Processing the payment is no different from contactless bank payments, but - unlike bank payments - it offers unlimited innovation potential.

    • Banks or credit card companies cannot unilaterally change costs.

  • Internet payments become possible without intermediaries. An established bitcoin acceptance point can smoothly implement web payments.

    • Bitcoin payments can be seamlessly integrated into any web interface, and there is no need to consult with an external company or bank.

    • It can be freely integrated into any IT development.

    • Due to the primary business model, they start on the Lightning Network with a significant competitive advantage. see: Liquidity

  • Our solution allows for the automation of accounting and the digital tracking of payments.

What is this secondary business activity?

As I will explain in detail in the technical chapter of my writing, the retailer’s activity provides a huge advantage in operating a Lightning Network Node.

By secondary business activity I mean maintaining and operating a profitable, revenue-generating Lightning Network Node. Such a Node will already be installed due to bitcoin payment acceptance. When a customer pays in bitcoin, this income generates further constant revenue: The liquidity left on the Node is valuable to the participants of the Lightning Network (it has an opportunity cost), for which these participants pay transaction fees. Thus, our Client can engage in a secondary business activity independent of their commercial activity but enjoying a competitive advantage due to its revenue. The opportunity cost of their liquidity is low: remember, due to tax rules, it is better for them to leave the revenue from their primary activity within the business. I explain this competitive advantage in the liquidity chapter: Liquidity

By keeping the revenue tax-free within the company and using it directly and automatically, we generate additional income in a continuously appreciating asset. We do not need to realize unfavorable exchange rate fluctuations because our Node generates profit even at low exchange rates.

It’s worth earning bitcoin revenue

As seen above, it is not only advisable to accept bitcoin from the perspective of the primary business model, but the combination of value storage, exchange rate gains, tax benefits, and the implementation of a potential secondary business model is the key to perfect resource management.

The Merchant can thus rightfully consider offering the following benefits to their customers entering the store:

  • discounted pricing for bitcoin payments (due to the tax advantage, we have a fair buffer)

  • volume discounts for on-chain payments

  • two-way money movement - Lightning network service - in liquidity offered to customers

  • loyalty schemes

  • other Lightning network - i.e., secondary business model - services (circular rebalancing, looping…​)

Why is it good for the customer?

We have already outlined the profile of our customer paying in bitcoin: Our Clients' Customers
Our Client can gladly recommend bitcoin payment to their customers because:

  • The customer can spend their bitcoin in exchange for real value.

  • Due to spending in bitcoin, the customer is exempt from tax obligations.

  • The customer can open a Lightning channel toward the merchant, opening the way to operating their own Node.

  • The customer makes their assets liquid with a Lightning transaction.

  • It enables fast payment.

  • If we accept that our Client can incentivize the customer for bitcoin liquidity, then the customer’s motivation can be increased in one fell swoop:

    • the customer can buy at a discount,

    • make group purchases.

    • receive loyalty discounts.

    • Purchase a Lightning channel for themselves or external liquidity from the merchant.

    • Buy secondary services on the Lightning Network.

    • …​and the list goes on. The only limit to motivating the customer is our Client’s imagination.

What happens during payment?

In this chapter, we will show the payment process from the perspective of both participants.

Payment from the customer’s perspective

Before the customer pays for the purchased/consumed/used product/service, they check the current HUF/BTC exchange rate on a prominently displayed screen. If applicable, they inform the seller of their intention to pay in bitcoin and the method of doing so. For low-value payments - when the on-chain payment cost is relatively high - the customer chooses Lightning payment Lightning Network as the bitcoin payment method, as appropriate. Through one of the following three methods:

  1. Paying with a Lightning wallet, using a lightning transfer on the network

  2. Opening a new, direct channel toward the merchant’s Node with a chosen amount of liquidity

  3. Paying through an existing direct channel previously opened toward the merchant.

By scanning the QR code presented by the merchant, they pay the amount in bitcoin, then receive the provided receipt. (If desired, they can also receive a VAT invoice. Exactly like with regular payments.) In the second case, they must decide how much to allocate for maintaining the newly opened channel.

Afterward, they leave the store with a satisfied, sly smile on their face.

Payment from the merchant-client’s perspective

In the store, they display the current bitcoin-to-forint exchange rate in a prominent location. (ideally: X satoshi = 1 HUF) Before paying at the cash register, the customer informs the seller of their intention to pay with bitcoin. On a device provided and/or configured by us, the invoice appears in the form of a QR code. Once the customer scans it, the transaction is recorded at the cash register. The merchant hands over the receipt to the customer.

If the customer wishes to open a new channel, it may be worth discussing loyalty habits or a potential secondary business model, as the amount of liquidity released largely depends on these factors.

After the customer leaves the store, there are several options for bitcoin accounting. Each of these is a well-planned operation. Our solution covers both accounting and tax consulting.

On-chain or Off-chain payment methods

High-security, and therefore higher-value bitcoin payments are settled on the bitcoin Blockchain. Lower-value, instantly settled - but Blockchain-delayed transactions - are processed on the Lightning Network. The different methods are briefly explained below:

  1. This is the first-layer - traditional - settlement. The transfer is recorded in blocks finalized every 10 minutes on the blockchain. This is the known and everyday solution for the average bitcoin user. Globally, however, the system’s properties only allow up to 7 transactions per second. This is far from sufficient for retail traffic and - in relation - low-value transactions, as the market continually enforces increasing fees, which does not favor small-value on-chain transactions.

  2. The second-layer settlement. The instant transfer network built on top of the blockchain, developed for small payments by the Bitcoin community. Instant transfers using the Lightning Network Lightning Network reach their destination. The customer can choose between two different routes. Both result in instant and final transfers:

    1. Lightning Network transfer, if the customer has a suitable wallet

    2. Direct Lightning Channel opening, if the customer also has a Node

→ jump to the beginning: Bitcoin Payment Solution

Lightning Network

The Lightning Network is built as a second layer on top of and relying on the Bitcoin Blockchain. The fundamental building block is the consensual relationship established between two parties:

Lightning Channel

Two parties create a Blockchain-secured payment channel between each other with autonomous and local security measures, using a special blockchain transaction. This transaction and the rules enforced by the parties' respective software guarantee consensus between the two. With the establishment of the channel, the two parties can initiate arbitrarily small transactions towards each other within the limits of the released liquidity as often as they wish. The transactions exchanged in this manner - known only to the two parties - continuously update their respective balances, which can be settled on the Bitcoin Blockchain at any time. The parties essentially send checks to each other, any of which can be cashed on the Blockchain at any time. The transactions exchanged between them that do not touch the Bitcoin Blockchain have no cost.

A multitude of channels creates the network:

Lightning Network

The Lightning Network is made up of machines that can connect with each other through at least one chain of arbitrarily long channels. This network enables two parties to send bitcoin to each other without a direct channel between them - via intermediary Network nodes (from now on referred to as Nodes). Since the transactions sent in this manner do not touch the Bitcoin Blockchain, there are no size limits on these transactions, so they can be sent with virtually unlimited frequency. The fee for a transaction worth 1000 HUF currently sent over the Lightning Network is approximately 3 fillers.

Liquidity

Bitcoin is a full-reserve system, meaning it doesn’t know credit. It’s useful to imagine a channel as the rod of an abacus. The left side of the rod is my liquidity, and the right side belongs to my current partner. Without credit, only as much bitcoin can move along a rod as was loaded onto it at the time of the initial transaction.

my                external
1  |ooo----------oooooo|   Antal
2  |---------------oooo|   Bea
3  |ooooo----------oooo|   Csaba
4  |oo----------------o|   Dezső
5  |ooo----------------|   Emma
6  |ooo--------------oo|   Fanni

Either party can only pay if they have sufficient liquidity on their side of a channel. This - the own-side liquidity - is something every member of the network has direct control over. More importantly, what depends on the partners is the external liquidity. Participants can only receive payments if there is enough external liquidity on the other side of a channel.

Note

External liquidity is a rare commodity!
However, it is a given for a merchant accepting bitcoin!

Examples of liquidity management and payment forwarding

Let’s assume that my partners are not connected to each other and wish to handle their payments to each other through me.

  • Antal wants to pay Bea 2 satoshis: we cannot solve this, because while he can transfer to me, I don’t have liquidity towards Bea.

  • Bea wants to pay Antal 2 satoshis: she transfers 2 satoshis to me, changing the balance between us to (2-2), and I forward it to Antal, so our new balance is (1-8).

  • Emma cannot transfer to anyone, as she has no liquidity on her side of the channel towards me, but she can receive transfers from anyone except Bea, up to 3 satoshis, because I cannot forward more towards her.

  • Emma can, for example, send me 3 satoshis in an on-chain transaction, and I forward the liquidity off-chain through our channel. Emma will then be able to make payments again through our channel.

  • If Fanni wants to spend all her money, she can send it to anyone except Bea.

  • Initially, I have 3 + 0 + 5 + 2 + 3 + 3 = 16 satoshis, and this remains the same as long as I only forward transactions. This is my liquidity. I can transfer this amount to the Blockchain anytime by closing the channels.

  • If I decide to charge a transaction fee, I announce it when route searching. From then on, it will be reflected in the transferred amounts: Antal wants to send 4 satoshis to Csaba. If I charge a 20% fee, Antal will have to send 5 satoshis to me, and I will forward 4 to Csaba.

  • If Fanni wants to send 2 satoshis to Csaba, she can only do so through me if my Node does not charge a fee.

Problem

If I want to make a transaction profit, i.e., forward transfers, I need channels where partners are willing to place external liquidity on the channel from their side - which I consider external liquidity. However, it is difficult to motivate someone to direct their liquidity toward me when they would rather direct it toward well-functioning Nodes. A Node with high external liquidity can process more transactions. I can easily control my own-side liquidity. External liquidity, on the other hand, is controlled by the partner, and I have to "purchase" it from them. For example, in exchange for goods.

Competitive Advantage

A Node operated by a merchant has a huge competitive advantage because, due to their primary business, they can easily acquire external liquidity. If a customer regularly pays in bitcoin at my bakery, they may want to open a channel toward me:

  • because they will have a direct and live channel

  • because their transfers toward me will be fee-free

  • and because I have a vested interest in generating bitcoin revenue, they can expect incentives from me.

I generate external liquidity on the Lightning Network due to bitcoin payments. Thus, the customer - or anyone through them - can use my Node, leaving the transaction fee behind.

Note

A well-managed Lightning Node with sufficient liquidity is expected to generate significant revenues as the Lightning Network inevitably grows. As networks grow, early adopters can profit significantly more from the network’s growth.

Lightning Network as a revenue source

Based on the operator’s priorities, it is worth distinguishing between two types of Nodes. From a profitability perspective, these Nodes are considered different, although technologically they are perfectly equal, and their network-topological distinction is incidental. There is free movement between them, and it is ultimately up to the user’s decision and investment how they operate their Node.

A - Payment Point

Those Lightning Nodes that primarily operate as the background for a specific wallet generally maintain only a few channels, explicitly for the purpose of making or receiving payments. These Nodes typically do not handle routing, as they serve as the starting or ending points of the owner’s transactions. In many cases, they are directly connected to the Nodes they pay or expect payments from. As mentioned, these payments (which do not use intermediate Nodes) are completely free since they only use the resources of the two endpoints. There is no point in discussing fees between the two endpoints. Of course, they can also initiate payments toward non-directly connected Nodes on the Network, in which case fees apply.

B - Network Node

If a Node has a sufficient number of channels with well-chosen directions and adequate liquidity, it can potentially serve the system’s routing needs on a large scale. When a Node forwards external liquidity, it can charge a transaction fee. Since the original sender is aware of the fees of certain routes in advance, an open market competition arises among Nodes based on forwarding fees. In this market, well-established Nodes with sufficient liquidity and direction are at an advantage and can expect higher revenues. These network nodes are also payment points since they can serve as endpoints for transactions.

The expected direction of development

The Lightning Network is currently growing at a hyper-exponential speed, meaning the number of channels is increasing by a higher percentage each month. Currently, there are nearly 30,000 Lightning Nodes worldwide, operating approximately 80,000 channels. Since software solutions built on the Lightning Network are also continuously being developed, it is reasonable to assume that the network will step out of its development phase this year and into the user adoption phase.

The exponential increase in the number of transactions also means that demand for Network Nodes is rising, with the system trying to process increasingly higher sums and more transactions.

Our company’s goals and revenues

Our mission

sziller.eu aims to continuously increase the number of bitcoin acceptance points and, through this, the number of second-layer - Lightning Network - Node machines in the country by involving an increasing number of retail units, as well as the amount of liquidity released locally in the Lightning Network.

Our company’s services
  • Building and customizing the bitcoin payment solution presented in this document for our Clients.

  • Setting up, supervising, and managing the Node, the building block of the Lightning Network.

  • Developing and implementing further specialized Bitcoin-related solutions: from planning, implementation, and testing to documentation.

  • Tailored expert consulting for Clients: in Hungarian, English, and German.

  • Operating our own Routing-Node, serving the potential secondary business model of our clients.

  • Creating and operating a key Node.

  • …​numerous other possible innovations and Bitcoin-related services, software development.

Our website: sziller.eu

→ jump to the beginning: Bitcoin Payment Solution

Development Levels

Introduction

The purpose of the document…​

…​is to present the scalable steps of accepting payments in bitcoin. Each step-action presented here results in a functional bitcoin acceptance system.
The important characteristics of these steps:

  • They build on each other, using the previous solutions

  • When completing a module, we only do work that can also be used for subsequent modules.

In this way, we can progress with small steps, well-planned and optimally scheduled, towards a system of any complexity, while continuously verifying the results of the implemented Modules under real-world conditions.

Modules

The following building blocks, in the specified order, can be used to build a complex and potentially profitable Solution on its own, with each Module completion resulting in a well-functioning package.

An important analogy to bank (card payment) income collection is the verification of the amount received in the wallet. That is, during inspection, this balance (the relevant balance of the wallet) must be verifiable.

Two basic conditions should be met for every solution:

  • Before payment, the Ft-btc or Ft-sat exchange rate should be clearly displayed in the business premises (clearly understandable).

  • The customer must ALWAYS receive a receipt after purchase - this forms the basis of verifiable income collection.

idea

Every transaction saved on the Blockchain also appears in an additional ledger, creating triple-entry accounting. Thus, Onchain Transactions are authenticated beyond any doubt: the inspector does not need to trust the Client’s software either. Furthermore, transactions performed on the Lightning Network are also recorded in guaranteed and independent double-entry accounting since the payment is also registered in the customer’s database along with the amount paid.

tip

In the case of a VAT invoice request, I would not recommend bitcoin payment. For now.

Table 1. Module logic
level: order settlement: between parties income: regulatory supervision storage: client verification: client

0.

On-Chain

exchange - cash

Wallet

Handled by the wallet

1.a

-

as an alternative currency

-

-

1.b

-

card payment analogy

-

-

1.c

Off-Chain

-

Lightning Wallet

Handled by the wallet

1.c+

Off-Chain

-

sziller.eu-LN Node

sziller.eu - Node

2.

-

-

-

own Btc - Node

3.

Off-Chain

-

Own LN Node + W

Own Btc+LN - Node

4.

Off-Chain - direct channel

-

Own LN Node + W

Own Btc+LN - Node

The logical order and hierarchy of the modules
4   \                           These modules build on each other:
3    >                          Lower-level ones are prerequisites
2   /                           for the higher-level ones!
| <--   1.a  \    in any combination
| <--   1.b   >   and sequence
| <--   1.c  /    can be developed
| <--   1.d /
0   >                           Basic module, minimal requirement

0. Module

The most basic payment solution. For cases when my Client wants to enable bitcoin payments for their customers in the easiest, least cumbersome way possible.
During the purchase, we perform two actions:

  1. we convert the customer’s bitcoin to forints

  2. we collect the income in forints

We run a bitcoin wallet (Wallet) on a separate device (tablet, discarded mobile device) – an available, free wallet in the market. This wallet only needs to handle incoming On-chain payments. The device will not be programmed, the wallet doesn’t need to initiate payments, and it is not necessary to store private keys on the wallet. The less the device can do, the lower the risk.

In extreme cases, even a static QR code can function as a wallet! In this way, the protection of incoming funds can be guaranteed beyond all limits! Even direct Cold-Storage storage is possible.

Advantages
  • Simple

  • Final after On-chain settlement

  • Instantly visible

  • It can be stated that the customer can pay with bitcoin – thus fulfilling the minimal marketing goal.

  • It forms the basis of all subsequent development points, so there is no unnecessary effort.

  • If only an income-collecting wallet is used, even in the case of theft or loss, it is protected. Employees cannot access it.

  • Using a static QR code, security can be provided literally for pennies.

Disadvantages
  • It has On-chain transaction fees, which can make it unusable at certain times.

  • There is no instant and final settlement (it can be delayed by hours depending on the transaction fee).

  • Determining the transaction fee can be cumbersome and often not customer-friendly.

  • The transaction fee affects the speed of final settlement.

  • Until final settlement as desired, a trust relationship with the customer is required.

  • We either need to keep cash from previous income at the counter to deposit into the register upon receipt…​

  • …​or bring in external sources for conversion.

1. Module selection

The developments presented here can be implemented independently, based on level 0.

1.a Module

Compared to the previous (0.) level, we improve income collection. Using the analogy of accepting foreign currency, we enable new currency acceptance in the cash register. This "currency" is then accounted for by our wallet in a closed system, allowing it to be presented for inspection at any time. The fact of income collection can also be confirmed with a currency receipt for income. These receipts do not need to be issued every time, they can be completed in batches.

Advantages
  • more convenient income collection

  • more transparent cash register

  • bulletproof solution during NAV inspections - at any given moment

Disadvantages
  • we need a one-time setup of the cash register

  • if we want to use income receipts, we need to deal with them and think about their replenishment in time.

1.b Module

Compared to the previous (0.) level, we improve income collection. Using the analogy of card payment, we enable handling a new external terminal in the cash register. The bitcoin received through the "card reader device" is accounted for by our wallet in a closed system, making it presentable for inspection at any time. In this analogy, there is no need for an income receipt.

Advantages
  • more convenient income collection

  • precise accounting with the wallet during NAV inspections - at any given moment

Disadvantages
  • we need to connect to the cash register – compatibility issue

1.c Module

Compared to the previous (0.) level, we improve settlement. We use a wallet (Wallet) that connects to and can handle the Lightning Network. The Speed-Cost-Risk profile of payments made on the Lightning Network is significantly different from On-Chain payments. On the LN, we provide settlement that is practically instant and nearly final. At the same time, transaction fees are orders of magnitude lower, much smaller than exchange rate differences.

Advantages
  • more realistic income collection – this will likely be widely needed – soon

  • lower transaction costs

  • instant, almost final settlement

  • instantly visible

  • we can charge per product (specific customer, specific order).

Disadvantages
  • Lightning payments need to be understood for risk transparency

  • Wallets available on the market are less user-friendly

  • Challenges may arise depending on the embedding of the parties

  • CONSTANT online presence is required!!!

  • the bonus third ledger is not given (but income collection is still verifiable)

1.c+ Module

Compared to the 1.c Module, we change the verifiability. The Lightning Node is provided by my company — sziller.eu. The Client’s wallet functions as the front-end of my company’s Node, performing Transactions on the Node operated by sziller.eu.

Advantages compared to 1.c
  • no need for constant online presence, my company’s Node replaces this.

  • organic network embedding, geographically speaking.

  • lower transaction fees.

  • The Client can automatically use the supplementary functions of the sziller.eu Node.

2. Module

The necessary condition for the sovereign (Client-supervised) auditing of the system and the introduction of higher-level modules is the operation of a personal Bitcoin Node.

Advantages
  • perfect and sovereign system knowledge

  • independence from wallet Node connections

  • No data leakage when querying metadata

  • We can assert our interests within the entire Bitcoin system.

  • The embodiment of the Bitcoin ethos.

  • It forms the basis of all subsequent solutions, so there is no unnecessary effort. Operation requires about 10W – negligible.

  • Hardware is customizable and programmable.

  • Client-tailored solutions can be widely developed.

Disadvantages
  • practically none. Just assemble it, and it runs.

3. Module

Compared to the previous level, we improve settlement. By operating a direct Lightning Node, we act as a sovereign participant in the LN. We create channels through our Node. These channels can be established at any time, allowing customers to pay through different routes with lightning speed and instant settlement. In this Module, our sovereignty increases by orders of magnitude, while opening the possibility for forwarding external, independent Lightning payments and collecting transaction fees (not from our customers).

Advantages
  • We have a sovereign Lightning Network Node.

  • Direct Channel opening opportunities

  • Independence from Lightning service providers

Disadvantages
  • The Lightning Node must be online constantly.

  • Understanding Lightning Node operation is beneficial.

4. Module

Compared to the previous level, we change our relationship with the customer – our settlement with them: we establish an Off-chain - Lightning - channel with them, or more precisely, the customer opens a direct channel towards us, in which the appropriate liquidity is moved to our side during payment.

Advantages
  • We enable the customer to pay instantly, directly, and completely fee-free

  • We acquire external liquidity, significantly improving our situation on the LN: Liquidity forwarded through the customer reaches its destination via us, generating transaction income for us.

  • From the customer’s perspective, it may be advantageous that compared to an On-Chain transfer, they can create external liquidity on our Node for a minimal premium. Thus, even with a single payment, they are encouraged to open a Channel.

Disadvantages
  • There is an On-Chain (transaction) cost for opening the channel.

  • The one-time, first-time opening of the channel is time-consuming: you have to wait for a sufficient number of blocks. Conventionally 3, which is about half an hour!

tip

This module can also be implemented through the Node supervised and managed by sziller.eu.

Our Prices

We only issue invoices for work in areas where we are competent. For example, we offer the method of income collection as a tip.
If we perform any hardware procurement, installation, software installation, development, writing, configuration, troubleshooting, testing – in short, any hardware or software-related performance – we charge it at a rate of €80/hour. For any Bitcoin-related consultancy, I, as the business manager, charge €150/hour. Naturally, this is not about friendly conversations, but in-depth, substantive consultancy. Well documented and traceable, ideally illustrated.

In reality, the pricing always looks like this: knowing the required performance, we calculate a precise price in advance, for the given specific situation. In such cases, we work with the above values, and we communicate the result in advance, before the performance begins. There will be no surprise performances or invoices.