First of all I think it is too much to call such a simple model offline transaction it is just confusing, using a non-ip relay network to send your transactions doesn't make bitcoin or its transaction processing offline.
No one said that it was offline transaction processing. What he did was offline transaction
relay. Relay and processing are two different things.
Offline processing is already a thing. You don't need an internet connection to process the blockchain if you already have it.
It was the article's title I objected to. As of
offline processing, it is about transaction (and not block) processing, I mean before it has been included and confirmed by blocks.
{you mis-quoted in your original reply on @khaled's id}
To be a bit more specific by off-chain bitcoin transaction processing I mean a technology that allows wallets to exchange bitcoin txns, just like paper money/bills, multiple times with multiple parties engaged without leaving any trace on the blockchain other than circumstances that one of the parties, decides to deposit it.
That is not "offline". Off chain does not mean it is offline, and vice versa. E.g., Lighting can be done offline, but it is still kind of on-chain (as it relies on funding and closing on chain). Likewise, you could say Lightning is off-chain (The actual transactions are off chain) but not offline.
LN transactions are done off-chain, channel-setup/flush transactions are irrelevant, they are obviously on-chain but are not counterparts of daily LN transactions, most of LN transactions are processed off-chain but it would be very hard to have LN transactions being processed offline because nodes which are in charge of this processing need online access to blockchain to check for possible flush requests from the peer.
LN and side-chains include intermediary entities and typically require online access to blockchain to process off-chain transactions completely.
Alternatively Suppose:
-1) Bob asks Alice for some assets/goods/services he is offering to pay him m satoshis. He sends a secret shared key,
SSK, to Alice (or has an already established one with her) and claims the coins.
0) Alice approves. For the sake of simplicity, suppose she got n utxos with a total of M=(m+txfee)satoshis balance. To do the cash transfer, she generates a pub/priv key pair,
pubkey and
privkey, and RIPEMd-160 hashes
pubkey to generate a new valid bitcoin address, let's call it Deposit Address,
DA.
step #1): Alice generates a transaction, again let's call it Deposit Transaction,
DTxn with n inputs and
DA as a single output, providing every secret/signature necessary to make it a valid txn, ready to be published to the network.
step #2): Instead of publishing
DTxn, Alice assembles a raw message:
{
"Total Inputs Value": M,
"Total Outputs Value": m,
"output public key": "<pubkey>",
"output private key": "<privkey>",
"Deposit Transaction: "<Dtxn>"
}
let's call it a Disclosed Digital Bill,
DDB, she encrypts this message using
SSK to generate an Encrypted Digital Bill,
EDB then Alice sends it (being encrypted) using any available medium to Bob.
step #3): Upon reception of EDB Bob decrypts to DDB and starts verifying it to be consistent and valid:
- m amount matches,
- M-m (fee) is not too low,
- pubkey and privkey adhere to bitcoin ECDSA implementation.
- Dtxn is a well formed p2kh type with M in and m out values and has a single pubkey_hash output(DA),
- Dtxn is properly signed and running input scripts is a success,
- RIPEMD160(pubkey)= DA,
Conclusively Bob becomes convinced he can claim DTxn output (m satoshis)
whenever he wishes, given he is somehow assured that:
- Alice never ever commits double-spending or any other fraudulent behavior,
- DDB is not compromised and won't be compromised ever e.g. by adversaries getting access to EDB by eavesdropping the communication medium or by theft and then managing to decrypt it somehow(unauthorized access to SSK, brute-forcing the message, ...),
I call this two basic conditions Assurance Basic Conditions, ABC.
If ABC is hold, Bob would conveniently choose to keep the DTxn confidential and re-use it with other third parties and they would follow this practice as well, thereafter we would have a series of transaction processing that happen completely offline and off-chain, essentially by repeating last 3 steps each time.
Given ABC is hold, above process is off-chain and easily could be managed offline and is superior to LN and other 2nd layer technologies for:
-Ease of use,
-Pure p2p nature,
-Full privacy and anonymity,
- Zero cost (besides tx fee paid by Alice, other parties do not pay fees)
- ...
The technology I'm trying to present is about holding ABC true up to a measurable level.
It is completely offline/off-chain and free from any form of mediation or arbitration, as long as DDB is not publicized and included in the blockchain, no matter how many times it has been circulated around and
used as a medium of exchange.
It is kinda competing with blockchain and cryptocurrency initiative, I understand, but what else it could be?
Bitcoin and blockchain technology is an alternative to banking system because what they do is maintaining a ledger and providing a solid mechanism to keep it immutable and secure against unauthorised/fraudulent banking transactions and double-spending by means of a public, permissionless, decentralized network.
Cash is not exactly what bitcoin is, in spite of the title Satoshi used for his whitepaper, cash is not a balance of an account kept safe by banks or blockchains , cash is what you hold somewhere and could pass it to a peer without leaving any trace anywhere or reconciling with any third party. You interact with banks to deposit/withdraw cash and replacing banks with a decentralized crypto system like bitcoin doesn't change the whole picture.
But how exactly we would hold ABC true for potential receivers of DDBs? I think it is more important to understand and define the problem thoroughly, first.
