forked from cheng/wallet
Started work on the SWIFT plan. Lot of whitespace fixes, hence so manny
many files updated with trivial fixes. modified: docs/design/TCP.md modified: docs/design/peer_socket.md modified: docs/design/proof_of_share.md modified: docs/estimating_frequencies_from_small_samples.md modified: docs/libraries.md modified: docs/libraries/scripting.md modified: docs/manifesto/May_scale_of_monetary_hardness.md modified: docs/manifesto/bitcoin.md modified: docs/manifesto/consensus.md modified: docs/manifesto/lightning.md modified: docs/manifesto/scalability.md modified: docs/manifesto/social_networking.md modified: docs/manifesto/sox_accounting.md modified: docs/manifesto/triple_entry_accounting.md modified: docs/manifesto/white_paper_YarvinAppendix.md modified: docs/names/multisignature.md modified: docs/names/petnames.md modified: docs/names/zookos_triangle.md modified: docs/notes/big_cirle_notation.md modified: docs/number_encoding.md modified: docs/scale_clients_trust.md modified: docs/setup/contributor_code_of_conduct.md modified: docs/setup/core_lightning_in_debian.md modified: docs/setup/set_up_build_environments.md modified: docs/setup/wireguard.md modified: docs/writing_and_editing_documentation.md
This commit is contained in:
reaction.la
parent
5f47c5b35a
commit
7674b879eb
@ -151,10 +151,26 @@ $$P_{new}(ρ) = \frac{ρ × Ρ_{prior}(ρ)}{P_X}$$
|
||||
|
||||
# Beta Distribution
|
||||
|
||||
Here I discuss the Beta distribution for a zero dimensional observable.
|
||||
The observable is either true or false, green or not green, and $α$ and $β$
|
||||
are continuous quantities, real numbers.
|
||||
|
||||
If the observable is a real number, then $α$ and $β$ are size two vectors, points
|
||||
in a two dimensional spac, and this is is known as the gamma distribution.
|
||||
If the observable is a two dimensional vector,
|
||||
a point in a two dimensionals space, then $α$ and $β$ are size three vectors,
|
||||
points in a three dimensional space, and this is known as the delta distribution
|
||||
|
||||
The Beta distribution is
|
||||
$$P_{αβ}(ρ) = \frac{ρ^{α-1} × (1-ρ)^{β-1}}{B(α,β)}$$
|
||||
where
|
||||
$$B(α,β) = \frac{Γ(α) × Γ(β)}{Γ(α + β)}$$
|
||||
$ρ$ is the *real* probability that the ball will be green, and $α$ and $β$
|
||||
represent our prior for the likely probability of this probability.
|
||||
In the delta distribution, the probability not of true or false, but
|
||||
of a poisson distribution, which itself the probabilility of a value,
|
||||
so we have another level of recursion.
|
||||
|
||||
|
||||
$Γ(α) = (α − 1)!$ for positive integer α\
|
||||
$Γ(1) = 1 =0!$\
|
||||
@ -211,7 +227,7 @@ counts as evidence. To apply, we need to take into account *all*
|
||||
evidence, and everything in the universe has some relevance.
|
||||
|
||||
Thus to answer the question “what proportion of men are mortal” the
|
||||
principle of maximum entropy, naiely applied, leads to the conclusion
|
||||
principle of maximum entropy, naively applied, leads to the conclusion
|
||||
that we cannot be sure that all men are mortal until we have first checked
|
||||
all men. If, however, we include amongst our priors the fact that
|
||||
all men are kin, then that all men are X, or no men are X has to have a
|
||||
@ -229,7 +245,7 @@ factor, so that what was once known with extremly high probability, is now
|
||||
only known with reasonably high probability. There is always some
|
||||
unknown, but finite, substantial, and growing, probability of a large
|
||||
change in the state of the network, rendering past evidence
|
||||
irrelevant.
|
||||
irrelevant.
|
||||
|
||||
Thus any adequately flexible representation of the state of the network
|
||||
has to be complex, a fairly large body of data, more akin to a spam filter
|
||||
@ -237,7 +253,9 @@ than a boolean.
|
||||
|
||||
# A more realistic prior
|
||||
|
||||
## The beta distribution
|
||||
## The beta distribution corrected
|
||||
|
||||
Corrected for the expectation that our universe is orderly and predictable
|
||||
|
||||
The Beta distribution has the interesting property that for each new test,
|
||||
the Baysian update of the Beta distribution is also a Beta distribution.
|
||||
@ -245,7 +263,10 @@ the Baysian update of the Beta distribution is also a Beta distribution.
|
||||
Suppose our prior, before we take any samples from the urn, is that the probability that the proportion of samples in the urn that are X is ρ is
|
||||
$$\frac{1}{3}P_{11} (ρ) + \frac{1}{3}δ(ρ) + \frac{1}{3}δ(1-ρ)$$
|
||||
|
||||
We are allowing for a substantial likelihood of all X, or all not X.
|
||||
We are allowing for a substantial likelihood of all X, or all not X,
|
||||
whereas the ordinary beta prior is the absence of information is that
|
||||
the likelihood of all X or no X is infinitesimal. Realistically, it
|
||||
is substantial.
|
||||
|
||||
If we draw out $m + n$ samples, and find that $m$ of them are X, and $n$ of
|
||||
them are not X, then the $δ$ terms drop out, and our prior is, as usual the
|
||||
@ -291,6 +312,11 @@ Which corresponds to our intuition on the question “all men are mortal” If w
|
||||
|
||||
In contrast, if we assume the beta distribution, this implies that the likelihood of the run continuing forever is zero.
|
||||
|
||||
Similarly, to correct the delta distribution, we have to add the assumption that the likelihood of certain trivial poisson distributions that have infinitesimal likelihood in delta distribution have finite likelihood. Though in many realistic
|
||||
cases this is not going to be the cases, for a real is usually going to have some
|
||||
finite distribution, and thus it is more likely to be OK to use the uncorrected
|
||||
delta distribution
|
||||
|
||||
## the metalog (metalogistic) distribution
|
||||
|
||||
The metalogistic distribution is like the Beta distribution in that
|
||||
|
||||
@ -11,6 +11,25 @@ It should be treated as a bunch of hints likely to point the reader
|
||||
in the correct direction, so that the reader can do his homework
|
||||
on the appropriate library. It should not be taken as gospel.
|
||||
|
||||
# Rust blockchain related libraries
|
||||
|
||||
Most important work in blockchains these days appears to be on rust.
|
||||
|
||||
I am behind the times.
|
||||
|
||||
[Awesome Blockchain Rust](https://rustinblockchain.org/awesome-blockchain-rust/#layer2){target="_blank"}
|
||||
|
||||
Rust is most ways the best system for large projects that can be worked on by many people and
|
||||
installed easily by many people, but it has the huge defect of a almost endless learning curve,
|
||||
and that its compile on very large programs takes a very long time. With C++, if you change one
|
||||
file, it recompiles very quickly. Since Rust link basically does not work, it has to recompile
|
||||
everything, which makes coding on large programs very slow. This is a killer if you are generating
|
||||
an executable that does a lot of things. And anything with a gui *does* do a lot of things.
|
||||
|
||||
So if you try to create a gui program in Rust you wind up using a rust wrapper
|
||||
around a gui written in some other language, which results in a gui that sucks.
|
||||
Rust however, is best for a daemon running in the background that does networking.
|
||||
|
||||
# Recursive snarks
|
||||
|
||||
A horde of libraries are rapidly appearing on GitHub,
|
||||
@ -18,15 +37,96 @@ most of which have stupendously slow performance,
|
||||
can only generate proofs for absolutely trivial things,
|
||||
and take a very long time to do so.
|
||||
|
||||
[Blog full of the latest hot stuff](https://giapppp.github.io/posts/){target="_blank"}
|
||||
|
||||
|
||||
[An Analysis of Polynomial Commitment Schemes: KZG10, IPA, FRI, and DARKS]
|
||||
(https://medium.com/@ola_zkzkvm/an-analysis-of-polynomial-commitment-schemes-kzg10-ipa-fri-and-darks-a8f806bd3e12){target="_blank"}
|
||||
|
||||
[Inner Product Arguments](https://dankradfeist.de/ethereum/2021/07/27/inner-product-arguments.html){target="_blank"}
|
||||
A basic explanation of polynomial commitments on ordinary curves
|
||||
|
||||
Verification is linear in the length of the polynomial, and logarithmic in the number of polynomials, so you want a commitment that is to quite a lot of short fixed length polynomials. All the polynomials are of the same fixed length
|
||||
defined by the protocol, but the number of polynomials can
|
||||
be variable. Halo 2 can reference relative fields -- you can have a proof that a value committed by N polynomials bears some relationship to the value in polynomial N+d
|
||||
|
||||
[most efficient pairing curves still standing]:https://arxiv.org/pdf/2212.01855
|
||||
|
||||
|
||||
A whole lot of pairing curves have fallen to recent attacks.
|
||||
|
||||
The [most efficient pairing curves still standing] at the time that this paper was written are the BLS 12-381 curves. (126 bits security)
|
||||
|
||||
ZCash, Ethereum, Chia Netork, and Algorand, have all gone with BLS 12-381, so these probably have the best developed libraries.
|
||||
|
||||
[IETF pairing curve paper]:https://www.ietf.org/archive/id/draft-irtf-cfrg-pairing-friendly-curves-10.ht
|
||||
|
||||
The [IETF pairing curve paper] has a list of libraries
|
||||
|
||||
## Dory
|
||||
|
||||
[192 bit polynomial commits]:https://eprint.iacr.org/2020/1274.pdf
|
||||
|
||||
[192 bit polynomial commits].
|
||||
|
||||
> Dory is also concretely efficient: Using one core and
|
||||
setting $n = 2^{20}$, commitments are 192 bytes.
|
||||
Evaluation proofs are 18 kB, requiring
|
||||
3 s to generate and 25 ms to verify.
|
||||
For batches at $n = 2^{20}$, the marginal
|
||||
cost per evaluation is <1 kB communication,
|
||||
300 ms for the Prover and 1 ms for the Verifier.
|
||||
|
||||
Seems to generate a verkle tree of polynomial commits (a verkle trie being
|
||||
the polynomial commitment equivalent of a merkle trie,
|
||||
and prove something about the preimage of the root
|
||||
-- which sounds like exactly what doctor ordered.
|
||||
You prove the preimage of each vertex on the path,
|
||||
and then prove the things about leaf part of the pre-image.
|
||||
|
||||
## Nova
|
||||
|
||||
[Nova]:https://github.com/microsoft/Nova
|
||||
{target="_blank"}
|
||||
|
||||
[Nova] claims to be fast, is being frequently updated, needs no trusted setup, and other people are writing toy programs using [Nova].
|
||||
[Nova white paper](https://eprint.iacr.org/2021/370.pdf){target="_blank"}
|
||||
|
||||
The folded proof has to contain an additional proof that the folding was done docrrectly.
|
||||
|
||||
Plonk, or Groff16 can be used as a proof system inside Nova. Recursion is a very low cost,
|
||||
but its native language is inherently relaxed R1CS and plonkish and Groff16 gets
|
||||
translated back and forth to relaxedR1CS
|
||||
|
||||
[Nova] claims to be fast, is being frequently updated, needs no trusted setup,
|
||||
and other people are writing toy programs using [Nova]. You tube videos report some
|
||||
real programs going into Nova -- to reduce the horrific cost of snarks and recursive snarks.
|
||||
|
||||
[Nova] claims you can plug in other elliptic curves, though it sounds like you
|
||||
might need alarmingly considerable knowledge of elliptic curves in order to
|
||||
do so.
|
||||
|
||||
Noval can be used, is intended to be used, and is being used as a preprocessing step to
|
||||
give you the best possible snark, but should be considered as standalone,
|
||||
as mimblewimble used polynomial commits alone.
|
||||
|
||||
The standard usage is incrementally verifiable computation, a linear chain,
|
||||
but to get full trie computation, you have man instances doing the heavy lifting,
|
||||
which communicate by "proof carrying data"
|
||||
|
||||
[You tube video](https://www.youtube.com/watch?v=SwonTtOQzAk) says nova,
|
||||
bulletproofs *modified from R1CS to relaxed R1CS*,
|
||||
and we can have a trie of provers. Well, if we have a trie of provers,
|
||||
why should not anyone who wants to inject a transaction be a prover?
|
||||
And if everyone is a prover, we need no snarks.
|
||||
|
||||
Everyone shares proving that he alone has done and only he needs encrypted a form
|
||||
that only he can read among thirty two or so neighbors,
|
||||
and similarly stuff that only two of them can read,
|
||||
only four of them can read, in case he crashes, goes offline,
|
||||
and loses his state.
|
||||
|
||||
Nova requires the vm to be standardized and repetitious.
|
||||
|
||||
Plonky had a special purpose hash, such that it was
|
||||
easy to produce recursive proofs about Merkle trees.
|
||||
I don't know if Nova can do hashes with useful speed, or hashes at all,
|
||||
@ -83,6 +183,14 @@ That is procedural, but expressing the relationships is not.
|
||||
Since your fold is the size of the largest hamiltonian circuit so far,
|
||||
you want the steps to be all of similar size.
|
||||
|
||||
## Halo 2
|
||||
|
||||
Halo 2 is a general purpose snark library created for ZCash,
|
||||
replacing their earlier library and using a different curve.
|
||||
It directly supports performing an SHA2 hash inside the proof and verification.
|
||||
I don't know how fast that is, and I did not immediately find
|
||||
any examples recursing over an SHA merkle tree and merkle chain.
|
||||
|
||||
This suggests a functional language (sql). There are, in reality,
|
||||
no purely functional languages for Turing machines.
|
||||
Haskell has its monads, sql has update, insert, and delete.
|
||||
|
||||
@ -5,7 +5,16 @@ title: How to move Bitcoin to recursive snarks
|
||||
|
||||
::: myabstract
|
||||
[abstract:]{.bigbold}
|
||||
Crypto currencies based on recursive snarks are the future. Polygon's aggregated blockchains are a proposal to move the Ethereum ecosystem to recursive snarks, and if the Ethereum ecosystem moves to recursive snarks, and Bitcoin does not, Bitcoin will die.
|
||||
Crypto currencies based on recursive snarks are the future. Polygon's aggregated blockchains
|
||||
are a proposal to move the Ethereum ecosystem to recursive snarks,
|
||||
and if the Ethereum ecosystem moves to recursive snarks, and Bitcoin does not, Bitcoin will die,
|
||||
for Bitcoin is struggling with big scaling problems,
|
||||
while Polygon's aggregated blockchain will completely and permanently
|
||||
solve Ethereum's scaling problems.
|
||||
|
||||
However BitcoinOS's Grail Bridge brings snarks, sharding,
|
||||
and potentially recursive snarks to Bitcoin.
|
||||
|
||||
:::
|
||||
|
||||
# Step one
|
||||
|
||||
@ -6,4 +6,3 @@ sidebar: true
|
||||
notmine: false
|
||||
abstract: >-
|
||||
Consensus is a hard problem, and gets harder when you have shards
|
||||
---
|
||||
|
||||
@ -14,7 +14,7 @@ abstract: >-
|
||||
|
||||
Bitcoin's initial rise was meteroric. As the scaling limit bites, that rise is topping out.
|
||||
|
||||
To get continued substantial rises in the value of bitcoin, we have to replace SWIFT and the petrodollar
|
||||
To get continued substantial rises in the value of bitcoin, we have to replace SWIFT and the petrodollar.
|
||||
For future growth, it is medium of exchange time. Without medium of exchange, store of value is running out of puff.
|
||||
China is hoarding gold and the fiat of its major international trading partners.
|
||||
If we can get SWIFT or the petrobitcoin or both, they will hoard bitcoin instead. If we don't, they won't.
|
||||
@ -51,7 +51,7 @@ Mutiny wallet and electrum is non custodial,
|
||||
but their profit model that made it possible to pay people to produce nice software
|
||||
relies on rather more quiet centralization that is admitted.
|
||||
|
||||
Someone who owns a lot more bitcoin than I do should fund development
|
||||
Someone who owns a lot of bitcoin should fund development
|
||||
of a lightning wallet done right in order to increase the value of Bitcoin.
|
||||
|
||||
The easiest and fastest way to bring up software that only runs on your computer
|
||||
@ -63,7 +63,7 @@ for other people to bring up a development system that emulates your system exac
|
||||
Python software is just not suitable for a program that you expect
|
||||
thousands and eventually hundreds of millions of people to use.
|
||||
An open source program intended for deployment on an enormous scale has to be
|
||||
C, C++, or rust. Typescript and Go also works.
|
||||
C, C++, or rust. Typescript and Go also work.
|
||||
|
||||
The trouble with the existing non custodial liquid lightning wallet is that it is substantially
|
||||
written in python, and therefore the install is appallingly difficult, an arcane emulation of
|
||||
@ -81,7 +81,7 @@ which should be as easy as sending a text from a phone -- a text that can contai
|
||||
## in person
|
||||
|
||||
The way an in person lightning payment should work is that you touch phones,
|
||||
and it sends a message by NFC, or you scan a QR code displayed on the other guys phone,
|
||||
and it sends a message by NFC, or you scan a QR code displayed on the other guy's phone,
|
||||
and up comes a human readable bill on your phone that will typically look something like
|
||||
a supermarket receipt, you click OK, and after a second or two both phones show the bill paid.
|
||||
And both phones record the human readable receipt forever.
|
||||
@ -92,9 +92,10 @@ You click on a link, which can be a link in the browser, which brings up not a b
|
||||
but your wallet gui, and which causes your lightning wallet to initiate end to end encrypted communications
|
||||
(using its own private key and the other wallet's public key, not certificate authority https keys,
|
||||
using lightning channels, not web channels) with the wallet that created that link,
|
||||
nd human readable text should appear in your wallet from that other wallet,
|
||||
and human readable text should appear in your wallet from that other wallet,
|
||||
human readable text containing buttons, buttons that cause events in the wallet, not in the browser.
|
||||
And one the things that can come up in one of the wallets is a human readable bill with an OK button.
|
||||
And one of the things that can come up in one of the wallets is a human readable bill, similar
|
||||
to a supermarket receipt or an Ebay shopping cart with an OK button.
|
||||
|
||||
And anyone you have a channel with, or have made a payment to, or received a payment from,
|
||||
should be automatically buddy listed in your wallet,
|
||||
@ -102,7 +103,7 @@ so that he can send you wallet to wallet end-to-end encrypted messages.
|
||||
You will probably get wallet spam from people you have purchased stuff from,
|
||||
so you will need a spam button to unbuddy them.
|
||||
|
||||
The wallet should be a browser and chat app that can send and receive money --
|
||||
The wallet should be a chat app and a browser that can send and receive money --
|
||||
a Nostr specialized for medium of exchange and two party private conversations.
|
||||
|
||||
Mutiny wallet and Alby are Nostr bitcoin lightning wallets,
|
||||
@ -120,7 +121,9 @@ We need to be able to restore from the master secret, the seed phrase, alone.
|
||||
|
||||
The big point and big value proposition of cryptocurrency is that
|
||||
you don’t have to suffer client status, with all its grave costs, dangers, and inconveniences.
|
||||
It is client status that is the problem that bitcoin was originally created to fix.
|
||||
|
||||
It is client status, that someone else has power over your money and transactions,
|
||||
that is the problem that bitcoin was originally created to fix.
|
||||
|
||||
To recover your lightning wallet you need both the master secret
|
||||
*and* the current state of your lightning wallet.
|
||||
@ -140,7 +143,7 @@ is watchtowers plus some new functionality.
|
||||
A watchtower receives (almost) all the data you need to restore a channel. Why then, not all?
|
||||
The stuff that they do not need to know, send encrypted so that only the
|
||||
possessor of the master secret, the seed phrase, can read it.
|
||||
and have at least one watchtower for every channel,
|
||||
and have at least one watchtower for every channel,
|
||||
plus each watchtower gets, encrypted, a list of some of the other watchowers,
|
||||
so that if you can find one watchtower from seed phrase, you can find them all.
|
||||
|
||||
@ -152,9 +155,9 @@ from its seed phrase, and that watchtower keeps a collection of lists of watchto
|
||||
so that it cannot read it. We implement DHT reciprocal storing incentives. If you want to be sure
|
||||
other people's watchtowers keep your list, better make sure your watchtowers keep other people's lists.
|
||||
|
||||
So the way it should work is that is that whenever Bob sets up a channel with Dave,
|
||||
So the way it should work is that whenever Bob sets up a channel with Dave,
|
||||
they agree to set up a couple of watchtowers for a couple of other channels —
|
||||
Dave sets up a couple of watch towers to watch a couple of Bob’s other channels,
|
||||
Dave sets up a couple of watchtowers to watch a couple of Bob’s other channels,
|
||||
and Bob sets up a couple of watchtowers to watch a couple of Dave’s other channels.
|
||||
And from time to time Bob sends to the watchtowers watching his channels
|
||||
a list of watchtowers watching his channels, in encrypted form
|
||||
@ -175,20 +178,20 @@ lightning wallet is very hard.
|
||||
|
||||
At present the only way to create channels is to create a unilateral single channel with zero incoming liquidity.
|
||||
Creating incoming liquidity is very hard, almost impossible. You have to hope that someone else
|
||||
will uniltarally initiate a channel to you, in which case you have all incoming liquidity in that
|
||||
will unilterally initiate a channel to you, in which case you have all incoming liquidity in that
|
||||
channel and no outgoing liquidity, and he has all outcoing liquidity in the channel and zero
|
||||
incoming liquidity. And unless you are already a major routing node with lots of incoming and outgoing
|
||||
liquidity no one is noging to unilaterally initiate a channel to you.
|
||||
liquidity no one is going to unilaterally initiate a channel to you.
|
||||
|
||||
## Polygon channels.
|
||||
|
||||
A channeel is a shared utxo on the basechain. It needs to be possible to create a polygon channel.
|
||||
A channel is a shared utxo on the basechain. It needs to be possible to create a polygon channel.
|
||||
|
||||
For example six self custodial wallets create a transaction on the base chain
|
||||
that creates six channel outputs and six change outputs --
|
||||
the wallets are the vertices (corners) of a six sided polygon, a hexagon,
|
||||
and the channels are the edges (sides) of a six sided polygon, the sides of the hexagon.
|
||||
Each channel has half incoming liquidity, and half outgoing liquidity
|
||||
Each channel has half incoming liquidity, and half outgoing liquidity.
|
||||
|
||||
The transaction either succeeds completely for everyone,
|
||||
or if one of the participants fails or backs out for some reason,
|
||||
@ -214,7 +217,7 @@ than the older P2SH channels that lightning is still using.)
|
||||
|
||||
If we implement PTLC lightning transactions, these are fully onion wrapped, so no one
|
||||
can tell who you are transacting with, nor what you are communicating with them about.
|
||||
We will have the privacy Satoship hoped for, and failed to provide.
|
||||
We will have the privacy Satoshi hoped for, and failed to provide.
|
||||
|
||||
# end users want their local fiat
|
||||
|
||||
@ -222,14 +225,16 @@ We want one person to be able to send dollars and the recipient receive pesos, a
|
||||
|
||||
## atomic transactions between blockchains
|
||||
|
||||
[point locked]:https://voltage.cloud/blog/lightning-network-faq/point-time-locked-contracts/{target="_blank"}
|
||||
[point locked]:https://voltage.cloud/blog/lightning-network-faq/point-time-locked-contracts/
|
||||
{target="_blank"}
|
||||
|
||||
such as between bitcoin, and stablecoins representing wrapped local fiat, are possible if the lightning network uses [point locked] contracts, as some lightning developers have been advocating for many years.
|
||||
such as between bitcoin, and stablecoins representing wrapped local fiat, are possible if the lightning network uses [point locked] contracts, as some lightning developers have been advocating for many years. Point locked contracts were impossible when lightning was
|
||||
written, but taproot has made them possible. Lightning -- and indeed everything -- should
|
||||
use taproot. Taproot has obsoleted existing lightning contracts and it is well past time for
|
||||
an update.
|
||||
|
||||
Any lightning network on one blockchain can in principle do atomic lightning exchanges with a lightning nework on another blockchain if both blockchains support Schnorr signatures and both lightning networks employ [point locked] contracts, but this extremely difficult if they use different signature algorithms, because differences in signature algorithms obstruct scriptless scripts. and an advanced research topic in elliptic curve cryptography if they use non prime elliptic curves.
|
||||
Any lightning network on one blockchain can in principle do atomic lightning exchanges with a lightning network on another blockchain if both blockchains support Schnorr signatures and both lightning networks employ [point locked] contracts, but this is difficult if they use different signature algorithms, because differences in signature algorithms obstruct scriptless scripts. and an advanced research topic in elliptic curve cryptography if they use non prime elliptic curves.
|
||||
|
||||
At present, lightning transactions are hash locked, which makes contracts over lightning difficult, and thus conversions difficult without a trusted third party. For four years some developers have been advocating point locks, which would make enable many lightning applications -- dollar lightning to bitcoin lightning to peso lightning among them.
|
||||
|
||||
The liquid lightning network already supports atomic swaps between tether, a US dollar stablecoin, liquid lightning, and bitcoin lightning, but the sotware is such that this is not likely many people are going to use it. One can, with some effort and linux administration skills, atomically swap bitcoin lightning for liquid lightning, then liquid lightning for tether, today. These capabilities need to have go on the bitcoin lightning blockchain, and be given an interface more suitable for normies.
|
||||
|
||||
s
|
||||
The liquid lightning network already supports atomic swaps between tether, a US dollar stablecoin, liquid lightning, and bitcoin lightning, but the software is such that this is not likely many people are going to use it. One can, with some effort and linux administration skills, atomically swap bitcoin lightning for liquid lightning, then liquid lightning for tether, today. These capabilities need to have go on the bitcoin lightning blockchain, and be given an interface more suitable for normies.
|
||||
|
||||
@ -273,6 +273,23 @@ transaction, but more efficent for the peer trying to get agreement between
|
||||
all peers, on the total state of the blockchain,
|
||||
which is apt to be the slow and expensive part.
|
||||
|
||||
Most efficient way for fast consensus is to first generate a total order over transaction inputs,
|
||||
blacklisting double spends in the process,
|
||||
which gives the recipient fast confidence that his money has come through,
|
||||
then generate a proof of validity of the transactions referenced,
|
||||
then introduce the outputs and proof of the outputs,
|
||||
which the recipient does not need in a hurry,
|
||||
He needs that so that he can spend the output,
|
||||
but does not need that to know he will be able to spend the output,
|
||||
so will not mind if that takes a while.
|
||||
But this faster and more efficient process requires
|
||||
some additional complexity to make sure that transaction outputs do not get lost.
|
||||
It is considerably simpler, though slower, less efficient, and less private,
|
||||
to keep the transactions and outputs together.
|
||||
But keeping them together means that the recipient does not know
|
||||
he has received the money until he can actuallly spend the money.
|
||||
Which is going to take longer.
|
||||
|
||||
Which sharding requires the prover to have a proof of the properties of the preimage of a hash,
|
||||
without needing the keep the preimage around outside of the address range he is working on.
|
||||
|
||||
|
||||
@ -318,7 +318,8 @@ payment using cryptography, but cannot create secure delivery of goods
|
||||
and services using cryptography. The other side of the transaction needs
|
||||
reputation.
|
||||
|
||||
[sovereign corporations]:../social_networking.html#many-sovereign-corporations-on-the-blockchain
|
||||
[sovereign corporations]:../manifesto/social_networking.html#many-sovereign-corporations-on-the-blockchain
|
||||
{target="_blank"}
|
||||
|
||||
So the other side of the transaction needs to be authenticated by a secret
|
||||
that *he* controls, not a secret controlled by registrars and certificate
|
||||
|
||||
Loading…
Reference in New Issue
Block a user