2024-06-15 22:30:52 -04:00
|
|
|
|
---
|
|
|
|
|
# katex
|
|
|
|
|
title: >-
|
|
|
|
|
Lets eat SWIFT's lunch.
|
|
|
|
|
sidebar: true
|
|
|
|
|
notmine: false
|
|
|
|
|
abstract: >-
|
|
|
|
|
SWIFT transactions are slow, expensive, and unreliable. And there are a lot of them,
|
|
|
|
|
a mountain of money to be made. SWIFT is being weaponized and shooting itself in the feet.
|
|
|
|
|
Everyone wants to move into the vacuum that has opened up,
|
|
|
|
|
but what moves into the vacuum will be Bitcoin,
|
|
|
|
|
*if* we can handle the scaling problem.
|
|
|
|
|
|
|
|
|
|
SWIFT merely provides an infrastructure for exchanging messages.
|
|
|
|
|
Double spends are resolved by databases of the entities receiving the messages.
|
|
|
|
|
The grotesque profits are made by the banks that use it.
|
|
|
|
|
And the profits for its crypto currency replacement are going to be made
|
|
|
|
|
by the cexs, dexes daos and wallets that use it.
|
|
|
|
|
With a lions share of the profits made by first dao of the first dex,
|
|
|
|
|
because of first mover advantage.
|
|
|
|
|
|
|
|
|
|
A replacement of SWIFT will not make money.
|
|
|
|
|
It will be a neutral environment in which people can make money.
|
|
|
|
|
So the replacement needs to be funded by software bounties.
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
# Opportunity.
|
|
|
|
|
|
|
|
|
|
People are spending an enormous amount of money on SWIFT transfers.
|
|
|
|
|
How much is hard to know, because the profits are made by the participant banks,
|
|
|
|
|
not by SWIFT, which is a neutral platform and neutral protocol,
|
|
|
|
|
that does not in itself transfer any money, but enables transfers,
|
|
|
|
|
but something in the ballpark of a billion dollars a day.
|
|
|
|
|
If people who create the infrastructure that repaces SWIFT can
|
|
|
|
|
capture a tiny sliver of that, they all get very rich.
|
|
|
|
|
|
|
|
|
|
Incoming international wire transfer fees may range from $10–$30,
|
|
|
|
|
while outgoing fees can be up to $50 or more.
|
|
|
|
|
SWIFT reported an average of 42 million payments and securities transactions per day in 2022,
|
|
|
|
|
indicating a about a billion dollars a day in fees.
|
|
|
|
|
|
|
|
|
|
The World Bank estimates that the average cost of an international bank transfer
|
|
|
|
|
is around 6% of the amount transferred,
|
|
|
|
|
which also indicates about a billion dollars a day in fees.
|
|
|
|
|
|
|
|
|
|
It is difficult for Bitcoin to replace gold as a store of value because of Metcalfe's law.
|
|
|
|
|
Central banks keep gold and do not keep bitcoin,
|
|
|
|
|
because all the other central banks keep gold and do not keep bitcoin.
|
|
|
|
|
If Bitcoin level two replaces SWIFT, then the central banks will need bitcoin,
|
|
|
|
|
and soon enough bitcoin will replace gold.
|
|
|
|
|
This will raise the market cap of Bitcoin to something like ten times its current value,
|
|
|
|
|
but that is small potatoes compared to capturing a tiny sliver of SWIFT fees.
|
|
|
|
|
|
|
|
|
|
# Outline of what needs to exist.
|
|
|
|
|
|
|
|
|
|
SWIFT is a messaging system that handles about five hundred standardized structured messages per second
|
|
|
|
|
(many messages of many types) between a few hundred banks, with certain special security guarantees,
|
|
|
|
|
in particular reliable and provable delivery. To eat SWIFT's lunch,
|
2024-07-28 07:12:35 -04:00
|
|
|
|
need a sharded total order broadcast channel with open entry, without centralization.
|
2024-06-15 22:30:52 -04:00
|
|
|
|
|
2024-07-28 07:12:35 -04:00
|
|
|
|
I am using “total order broadcast channel” in the cryptographic sense.
|
2024-06-15 22:30:52 -04:00
|
|
|
|
It will not be reliable in the ordinary sense, since you may attempt to put a message on it,
|
|
|
|
|
and the message may not get on it, and you have to try again.
|
|
|
|
|
It will not be broadcast in the ordinary sense,
|
|
|
|
|
since most messages are end to end encrypted so that only the two parties can read them.
|
2024-07-28 07:12:35 -04:00
|
|
|
|
What makes it a total order broadcast channel in the cryptographic sense,
|
2024-06-15 22:30:52 -04:00
|
|
|
|
is that if Bob sends a message to Carol over it,
|
|
|
|
|
as part of a protocol where Bob has to send a message,
|
|
|
|
|
and Carol has to send a reply, then if the protocol fails because of Bob, Carol can prove it,
|
|
|
|
|
and if the protocol fails because of Carol, Bob can prove it.
|
|
|
|
|
And both can prove what messages they received,
|
|
|
|
|
and what messages they sent that the counterparty should have received.
|
|
|
|
|
|
2024-07-28 07:12:35 -04:00
|
|
|
|
This more or less corresponds to the Celestia blockchain --
|
|
|
|
|
atomic broadcast and data availability without a massively
|
|
|
|
|
replicated state machine. Transactions being somehow achieved somewhere else.
|
|
|
|
|
|
|
|
|
|
Celestia is an Ethereum data availability layer, which is in some respects the
|
|
|
|
|
opposite of what we want to achieve -- we want a privacy layer so that people
|
|
|
|
|
can communicate and transact without revealing network addresses where valuable
|
|
|
|
|
secrets that could be stolen reside, but the underlying technological problems
|
|
|
|
|
that need to be solved are the same.
|
|
|
|
|
|
|
|
|
|
Celestia uses erasure coding to achieve scaling.
|
|
|
|
|
|
2024-06-15 22:30:52 -04:00
|
|
|
|
Being sharded, can handle unlimited volume.
|
|
|
|
|
And once that exists as a neutral protocol with open entry and no central control,
|
2024-07-28 07:12:35 -04:00
|
|
|
|
can put dexes on it, daos on it,
|
2024-06-15 22:30:52 -04:00
|
|
|
|
uncensored social media on it, web 3.0 on it, and coins on it.
|
|
|
|
|
|
|
|
|
|
And the first thing that should go on it is a dex that can exchange
|
|
|
|
|
Bitcoin, Liquid Bitcoin, Liquid Tether, Lightning, and Liquid Lightning.
|
|
|
|
|
And the next thing that should go on is the Aqua wallet.
|
|
|
|
|
But it needs to be a neutral open protocol, not owned by anyone,
|
|
|
|
|
and especially not owned by Blockstream.
|
|
|
|
|
Because Blockstream will gain value by being able to send or receive
|
|
|
|
|
a money bearing message to anyone.
|
|
|
|
|
|
|
|
|
|
At present each dex has its own messaging platform that does not talk to any of the others.
|
|
|
|
|
Bisq has a custom platform that runs on Tor, while Particl uses a fork of Bitmessage.
|
|
|
|
|
And each platform lacks some of the features a dex needs,
|
|
|
|
|
for which the dao of each dex has ad-hoc workarounds requiring frequent human intervention,
|
|
|
|
|
such as Bisq's painfully slow and unreliable mediation and arbitration system, which most
|
|
|
|
|
of the time winds up resolving issues that computers can and should solve automatically.
|
|
|
|
|
|
|
|
|
|
If one party goes down and stays down in the middle of a Bisq transaction, it gets
|
|
|
|
|
resolved by humans to the disadvantage of the unresponsive party, a simple rule
|
|
|
|
|
that machines should execute automatically.
|
|
|
|
|
|
|
|
|
|
Such a channel needs a distributed consensus as to what messages went on it.
|
|
|
|
|
Consensus is a hard problem, that gets a whole lot harder when you have sharding.
|
|
|
|
|
But a whole lot easier when the platform does not have to resolve double spends,
|
|
|
|
|
but merely provide a total order that enables other systems to
|
|
|
|
|
communicate about their resolution.
|
|
|
|
|
|
|
|
|
|
In existing dex communication platforms messages have value because of their relationship to other blockchains,
|
|
|
|
|
and it is those other blockchains that resolve double spends.
|
|
|
|
|
This is the equivalent of the way SWIFT does it.
|
|
|
|
|
|
|
|
|
|
And Bob can prove it even if his message is supposed to appear on one shard,
|
|
|
|
|
and Carol’s response on a different shard
|
|
|
|
|
|
|
|
|
|
Because SWIFT does not carry money, sharding its cryptocurrency equivalent
|
|
|
|
|
is a much easier problem than sharding a blockchain.
|
|
|
|
|
If two incompatible messages are sent over Swift,
|
|
|
|
|
the equivalent of a double spend on Bitcoin, the conflict is resolved outside of Swift,
|
|
|
|
|
and then messages resolving the conflict are sent within Swift.
|
|
|
|
|
|
|
|
|
|
# Scaling
|
|
|
|
|
|
|
|
|
|
Bitcoin hit its scaling limit in 2016-2017. Lightning still has capacity,
|
|
|
|
|
but high level one fees have ended growth in the number of lightning channels,
|
|
|
|
|
so it is going to hit its scaling limit soon.
|
|
|
|
|
And we are very soon going to be facing vastly increased demand for transactions.
|
|
|
|
|
|
|
|
|
|
Blockstream’s plan is to use the layer two bitcoin blockchain,
|
|
|
|
|
Liquid, to take over from SWIFT. Liquid can handle a lot of transactions per second,
|
|
|
|
|
but to really take over from Swift, we are going to be taking Visa’s role in international transaction,
|
|
|
|
|
and that will need Liquid Lightning, a layer three.
|
|
|
|
|
Which theoretically exists, but has no useful consumer wallet and has no useful Liquid lightning network,
|
|
|
|
|
because its command line wallet is only barely usable by a linux guru
|
|
|
|
|
who is running exactly the right version of linux.
|
|
|
|
|
Which is OK, if you have half a dozen linux systems running on
|
|
|
|
|
your private network and several shelves full of computers
|
|
|
|
|
with no keyboards or video screens running in your basement,
|
|
|
|
|
which you interact with over ssh and xrdp.
|
|
|
|
|
|
|
|
|
|
The collapse of SWIFT is happening now, and Blockstream’s replacement for it is happening now.
|
|
|
|
|
The internal collapse of the US$ is a few years off,
|
|
|
|
|
and we need to have crypto currency ready to replace it.
|
|
|
|
|
And I don’t think that even liquid lightning Bitcoin can handle that.
|
|
|
|
|
Going to need recursive snarks with snark based sharding.
|
|
|
|
|
BitcoinOS are addressing that. When last I looked their solution was far from ready,
|
|
|
|
|
but it does not yet urgently need to be ready.
|
|
|
|
|
|
|
|
|
|
To take over from SWIFT, lightning is unlikely to suffice.
|
2024-07-28 07:12:35 -04:00
|
|
|
|
Going to need Liquid. Since Liquid uses polynomial commits, it
|
2024-06-15 22:30:52 -04:00
|
|
|
|
might be possible to shard it, but the path to that is unclear,
|
|
|
|
|
in which case replacing SWIFT is going to need to need Liquid Lightning.
|
|
|
|
|
|
|
|
|
|
For Liquid Lightning to be any use, going to need more than Boltz
|
|
|
|
|
for exchange between lightning and liquid lightning.
|
|
|
|
|
Third parties will not want to build on a network wholly owned by a single party,
|
|
|
|
|
for fear that once that party gets Metcalfe law network lockin,
|
|
|
|
|
it will, like SWIFT, enshitify the network, as so many beneficiaries of Metcalfe's law have done.
|
|
|
|
|
To replace SWIFT will need liquid lightning, and liquid lightning
|
|
|
|
|
will need to be exchangeable on a dex,
|
|
|
|
|
a dex on which Boltz may well be the largest single liquidity provider,
|
|
|
|
|
but only one liquidity provider of many.
|
|
|
|
|
|
|
|
|
|
To take over from Visa in international transactions,
|
|
|
|
|
Lightning and Liquid are unlikely to suffice, due to scaling limits,
|
|
|
|
|
going need Liquid Lightning, which theoretically exists, but not really.
|
|
|
|
|
|
|
|
|
|
To take over in internal transactions when the US$ collapses,
|
|
|
|
|
Liquid Lightning is unlikely to suffice. Going to need recursive snarks,
|
|
|
|
|
which allow a sharded blockchain. Bitsnark's plan is
|
|
|
|
|
[Grail](https://assets-global.website-files.com/661e3b1622f7c56970b07a4c/662a7a89ce097389c876db57_BitSNARK__Grail.pdf),
|
|
|
|
|
a bridge between level one Bitcoin and a shardable level two bitcoin based on recursive snarks.
|
|
|
|
|
|
|
|
|
|
# Existing messaging systems
|
|
|
|
|
|
|
|
|
|
Every interchange blockchain bridge and every dex has its own ad hoc,
|
|
|
|
|
incomplete, and unsatisfactory messaging system,
|
|
|
|
|
and the design for this swift killer was primarily motivated by
|
|
|
|
|
the messaging systems of Particl and Bisq, and in particular by
|
|
|
|
|
Particl's adoption of Bitmessage for its purpose.
|
|
|
|
|
If there was something much better, and more scalable, than Bitmessage, everyone could use it.
|
|
|
|
|
So the first step is to create a better, and more blockchain friendly, Bitmessage.
|
|
|
|
|
|
|
|
|
|
We need something like Particl to enable a dex that exchanges
|
|
|
|
|
bitcoin, lightning, liquid bitcoin, liquid tether, liquid lightning bitcoin,
|
|
|
|
|
and liquid lightning tether,
|
|
|
|
|
for SWIFT is a nexus of third parties and third parties are not going to build on a cex.
|
|
|
|
|
A major reason that Particl is not very satisfactory is that Bitmessage is not very satisfactory.
|
|
|
|
|
|
|
|
|
|
# misc unorganized fragments
|
|
|
|
|
|
|
|
|
|
## consensus
|
|
|
|
|
|
|
|
|
|
> why do you hate POW? Because of resource waste? I thought it was the
|
|
|
|
|
> reason for success of BTC. With proof of share, or proof of stake,
|
|
|
|
|
> there will be always discussions of pre-mine, centralization etc.
|
|
|
|
|
> Would it be the case?
|
|
|
|
|
|
|
|
|
|
Hate the resource waste. It offends me. Plus a system that does
|
|
|
|
|
not directly handle money, that is a a messaging system between
|
|
|
|
|
systems that do handle money, cannot incentivise the
|
|
|
|
|
necessary resource waste.
|
|
|
|
|
|
|
|
|
|
It could bill people for messaging, and the payments could go to the block winner, but then
|
|
|
|
|
it would be a dao or yet another crypto currency, and not a neutral platform that other daos
|
|
|
|
|
and crypto currencies could use.
|
|
|
|
|
|
|
|
|
|
Suppose we have a filecoin style proof of spacetime .
|
|
|
|
|
Which also wastes resources, but identifies those
|
|
|
|
|
peers that are contributing to the network by storing
|
|
|
|
|
information and are capable of passing it around,
|
|
|
|
|
and have lots of connections to other peers.
|
|
|
|
|
All peers that pass the proof of space test become
|
|
|
|
|
authorized consensus makers for
|
|
|
|
|
a certain number of blocks, say 8192 blocks.
|
|
|
|
|
The test is not too hard. Most peers are authorized.
|
|
|
|
|
|
|
|
|
|
We harvest randomness, possibly from the fact that parties
|
|
|
|
|
do not know each other's secret keys, possibly from the
|
|
|
|
|
proof of space time test, so that each round, or each group of rounds,
|
|
|
|
|
a peer gets a random weight, such that the inverse of the weight is uniformly
|
|
|
|
|
distributed between one and two to the fifty sixth
|
|
|
|
|
|
|
|
|
|
Which means the weight is non uniformly distributed, with a very few peers
|
|
|
|
|
having most of the weight.
|
|
|
|
|
|
|
|
|
|
Each peer goes with the consensus block that has the highest chain of weights that it knows of.
|
|
|
|
|
|
|
|
|
|
Actually that algorithm has pathologies that could lead to suprising chain re-organisations
|
|
|
|
|
-- a slightly more complex algorithm is needed.
|
|
|
|
|
|
|
|
|
|
Every time a proposed block consensus is shared, it now has addiitional support.\
|
|
|
|
|
The weights of the two peers that have that consensus
|
|
|
|
|
and have the highest weight of all peers having that consensus is propagated
|
|
|
|
|
among all the peers that have that consensus, and the weight of the consensus is the weight of
|
|
|
|
|
the lesser of the two peers, plus the weight of the lesser of the two peers of the block it
|
|
|
|
|
was built upon that were known to the peer that built upon it at the time he built upon it,
|
|
|
|
|
plus the weight of the block that block was built upon, and so on and so forth.
|
|
|
|
|
|
|
|
|
|
Thus the most well known chain is propagated, becoming more well known. The more
|
|
|
|
|
peers that know of a block, the greater the weight of the block.
|
|
|
|
|
|
|
|
|
|
It is a better algorithm, but a whole lot more work to implement than RandomX POW.
|
|
|
|
|
|
|
|
|
|
## plan
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
> > But there is a perfectly respectable case for a social net that
|
|
|
|
|
> > allows end to end encrypted conversations and allows
|
|
|
|
|
> > pseudonymous identitities to conceal their network address, since if
|
|
|
|
|
> > one is doing trades of blockchain currencies on
|
|
|
|
|
> > a dex, one has make public offers without revealing the network
|
|
|
|
|
> > address of a computer that could be stolen, or
|
|
|
|
|
> > a person who could be subjected to rubber hose cryptography, and
|
|
|
|
|
> > engage in securely private conversations
|
|
|
|
|
> > about the resulting transactions, also without revealing one's
|
|
|
|
|
> > network address.
|
|
|
|
|
> >
|
|
|
|
|
> > For liquid lightning to work, needs an exchange between level one
|
|
|
|
|
> > lightning, liquid lightning,
|
|
|
|
|
> > tether lightning, bitcoin, liquid bitcoin, and tether.
|
|
|
|
|
> >
|
|
|
|
|
> > And the early adopters are not going to get aboard if the wallet is
|
|
|
|
|
> > locked to a cex, locked to Boltz, fearing
|
|
|
|
|
> > that once Boltz gets Metcalfe's law on its side, it is going to
|
|
|
|
|
> > enshitify the network.
|
|
|
|
|
> >
|
|
|
|
|
> > Early adopters will want a dex, on which Blockz happens to be the
|
|
|
|
|
> > major, but entirely replaceable, supplier
|
|
|
|
|
> > of liquidity, so that if it turns evil, as corporations that have a
|
|
|
|
|
> > Metcalfe's law lockin tend to do, the
|
|
|
|
|
> > dex will become dominated by less evil alternatives.
|
|
|
|
|
> >
|
|
|
|
|
> > And a dex, a dex that exists for the perfectly respectable purpose
|
|
|
|
|
> > of exchanging level one bitcoin
|
|
|
|
|
> > for level two (lightning and liquid) bitcoin, tether, and level
|
|
|
|
|
> > three (liquid lightning) bitcoin needs a
|
|
|
|
|
> > privacy social net.
|
|
|
|
|
|
|
|
|
|
> It makes sense.
|
|
|
|
|
|
|
|
|
|
> > If they decide they want a liquid lightning network to exist, they
|
|
|
|
|
> > need a dex, and they need a privacy social net for it
|
|
|
|
|
> > (Though I need a name less likely to give corporate officers the
|
|
|
|
|
> > hebee jeebies than privacy social net.
|
|
|
|
|
|
|
|
|
|
> Special social net. :)
|
|
|
|
|
|
|
|
|
|
Maybe I will just long windedly call it a social net designed to support
|
|
|
|
|
humanand and machine communications in a way suitable for cryptographic currency
|
|
|
|
|
purposes and especially a dex, that is a superset of the capabilities of Particl and
|
|
|
|
|
Bisq human to human communication protocol, particl's system being Bitmessage,
|
|
|
|
|
and Bitmessage being out of support.
|
|
|
|
|
|
|
|
|
|
> > My plan is to tell them they need a liquid lightning network to
|
|
|
|
|
> > exist, for it to exist there has to be
|
|
|
|
|
> > a liquid lightning dex, and it needs a mechanism for communicating
|
|
|
|
|
> > publicly and privately
|
|
|
|
|
> > without revealing one's network address.
|
|
|
|
|
> >
|
|
|
|
|
> > Therefore, fund a privacy protocol that is an update to bitmessage,
|
|
|
|
|
> > with additional capability of
|
2024-07-28 07:12:35 -04:00
|
|
|
|
> > zooko names and total order broadcast, reliable in the cryptographic
|
2024-06-15 22:30:52 -04:00
|
|
|
|
> > sense.
|
|
|
|
|
> >
|
2024-07-28 07:12:35 -04:00
|
|
|
|
> > total order broadcast in the cryptographic sense being that if one has
|
2024-06-15 22:30:52 -04:00
|
|
|
|
> > a transaction protocol in which Bob is supposed
|
|
|
|
|
> > to send a message to Carol, and Carol supposed to send a
|
|
|
|
|
> > corresponding response to Bob, the blockchain
|
|
|
|
|
> > can prove who dropped the ball -- so one can have contracts on the
|
|
|
|
|
> > blockchain that have one outcome if Bob failed to
|
|
|
|
|
> > send the message, and a different outcome if Carol failed to reply.
|
|
|
|
|
> >
|
|
|
|
|
> > This makes possible a whole lot of useful dex capabilities, which do
|
|
|
|
|
> > not yet exist on any dex, but could.
|
|
|
|
|
> > I need to write them up as part of a totally bland proposal for a
|
|
|
|
|
> > totally bland privacy social net that
|
|
|
|
|
> > enables arbitrary dexes and daos, among them a totally bland dex
|
|
|
|
|
> > that enables exchange of things near and dear to
|
|
|
|
|
> > Blockstream's heart.
|
|
|
|
|
|
|
|
|
|
> Ok, if you want me to pass your proposal, I'm ready to do it. I'm
|
|
|
|
|
> sure I can contact Adam, and at least get a response. I'm not sure
|
|
|
|
|
> how it should be proposed though. "Someone I messaged on BitMessage
|
|
|
|
|
> sharing this proposal, I'm sure you'll like it." :) But I think we
|
|
|
|
|
> can work it out.
|
|
|
|
|
|
|
|
|
|
I want to read what Adam has been writing, before I prepare the proposal.
|
|
|
|
|
|
|
|
|
|
I think he has been on some you tube channels, or something like that --
|
|
|
|
|
some kind of conference.
|
|
|
|
|
|
|
|
|
|
The proposal is going to be long and technical -- a white paper explaining what
|
|
|
|
|
Bitmessage is, that it is being used in the Particl dex, and explaining what
|
|
|
|
|
additional capabilities a dex needs, that Bisq and Particl lack.
|
|
|
|
|
|
|
|
|
|
## Python rant
|
|
|
|
|
|
|
|
|
|
Wouldn't it be an start to use existing code to experiment some p2p
|
|
|
|
|
> payments using bitmessage protocol?
|
|
|
|
|
|
|
|
|
|
Python is the best language in the world for code you intend will only be used by yourself,
|
|
|
|
|
used only a few times, then thrown away. It also works great for small trivial programs,
|
|
|
|
|
because these are apt to remain reasonably portable.
|
|
|
|
|
|
|
|
|
|
But the bigger it gets, the more it traps you into code that is only going to run
|
|
|
|
|
correctly on your one particular development system and that no one else is
|
|
|
|
|
going to be able to modify and add to, so investing in python
|
|
|
|
|
in anything you intend to be widely used is a trap. Open source
|
|
|
|
|
python is also a trap, because no one else is going to be able
|
|
|
|
|
to modify and add to it.
|
|
|
|
|
|
|
|
|
|
If I try to start modifying Bitmessage, I will surely fail. It is a bigger python
|
|
|
|
|
program than anyone except the original developer can maintain and modify.
|
|
|
|
|
|
|
|
|
|
In this sense, no large open source python program is truly open source. PHP
|
|
|
|
|
has the same problem, though to lesser degree. Javascript likewise. Has
|
|
|
|
|
improved considerably, but still sucks. But typescript which is compiled to javascript is OK.
|
|
|
|
|
so all big projects with many developers use typescript rather than javascript.
|
|
|
|
|
Or they die before they get big.
|
|
|
|
|
|
|
|
|
|
## mixer plan
|
|
|
|
|
|
|
|
|
|
(Which I am sure blockstream does not want)
|
|
|
|
|
|
|
|
|
|
> > Get early adopters to use it. One obvious use case is bitcoin
|
|
|
|
|
> > mixing. We have mixers, but the social environments that made them
|
|
|
|
|
> > usable have all been shut down.
|
|
|
|
|
|
|
|
|
|
> Or maybe integratate Samourai wallet into current BitMessage client?
|
|
|
|
|
|
|
|
|
|
Samourai wallet migrated to centralisation, which directly led to them getting
|
|
|
|
|
busted. That codebase is poisoned with communications that the FBI
|
|
|
|
|
has flagged as actionable. And integrating anything into current
|
|
|
|
|
Bitmessage is impossible except for the original developer. No
|
|
|
|
|
big Python program is truly open source.
|
|
|
|
|
|
|
|
|
|
The correct design for a mixer is as follows. One has a social net,
|
|
|
|
|
on which anyone can offer to coordinate a single mixing transaction.
|
|
|
|
|
for a mix that will produce mixed coins (utxos )of a particular
|
|
|
|
|
round number, 10mBTC, 20mBTC, 50mBTC, or 100mBTC,
|
|
|
|
|
plus unmixed changed coins.
|
|
|
|
|
|
|
|
|
|
All the mixed coins are of equal value, for example all 100mBTC.
|
|
|
|
|
|
|
|
|
|
Not some funny value highly identifiable value like 99.9872384mBTC
|
|
|
|
|
|
|
|
|
|
People offer to contribute utxos to this mix transaction - revealing
|
|
|
|
|
to the coordinater the public keys, the address, of the utxos,and
|
|
|
|
|
revealing to the coordinator that these utxos have a common owner.
|
|
|
|
|
|
|
|
|
|
They also give him the blinded addresses of coins they want to
|
|
|
|
|
receive. He blindsigns those addresses. They then reveal the unblinded
|
|
|
|
|
addresses, and his unblinded signature, which proves he signed those
|
|
|
|
|
addresses, but does not reveal to him which of the addresses he blindsigned it
|
|
|
|
|
is -- he does not learn the relation between the utxos that will be contributed
|
|
|
|
|
to the mix transaction, and the mixed or the change utxos that it will replace
|
|
|
|
|
them. (Though he and anyone doing blockchain analysis can trace the
|
|
|
|
|
change coins by the sudoko attack. But the sudoko attack is irrelevant to
|
|
|
|
|
coins that are all the same round number of bitcoin, such as 10mBTC)
|
|
|
|
|
|
|
|
|
|
He then creates the transaction, and everyone signs it. If not everyone
|
|
|
|
|
signs, everyone can see what the missing utxos were, the ones that
|
|
|
|
|
were promised, and not delivered, and blacklist them,
|
|
|
|
|
then try again.
|
|
|
|
|
|
|
|
|
|
People contributing already mixed utxos do not have to pay transaction fees
|
|
|
|
|
so get back exactly what they contributed.
|
|
|
|
|
|
|
|
|
|
People contributing as yet unmixed bitcoin have to pay a portion of the transaction
|
|
|
|
|
fee proportional to the number of utxos contributed and received. This is good for
|
|
|
|
|
them because the free of charge remixed utxos are enlarging their anonymity pool.
|
|
|
|
|
making each mixing transaction part of one enormous anonymity pool instead of many
|
|
|
|
|
tiny anonymity pools.
|
|
|
|
|
|
|
|
|
|
If mixing does not work like this, then someone has fucked it up in order to profit from
|
|
|
|
|
it, their users will be traced, and *they* will be traced, then arrested.
|
|
|
|
|
|
|
|
|
|
> > The core of my plan has always been Web 3.0, a privacy social net,
|
|
|
|
|
> > and everything else is just monetization, because software never
|
|
|
|
|
> > gets done properly or properly maintained without someone making
|
|
|
|
|
> > money off it.
|
|
|
|
|
|
|
|
|
|
> I got what you mean now. Once you reach a point that's indeed a good
|
|
|
|
|
> strategy to reinforce value of the network. You offer those
|
|
|
|
|
> integrate your service to beat metcalfe's law, your network becomes
|
|
|
|
|
> much more stronger. Facebook and some other social networks all
|
|
|
|
|
> followed this path via. 'applications' within them.
|
|
|
|
|
|
|
|
|
|
> > I have been trying to do that, but it is hard to get to the front of
|
|
|
|
|
> > the line of all the people who want to tell blockstream why
|
|
|
|
|
> > blockstream should fund them and their projects.
|
|
|
|
|
|
|
|
|
|
> Have you really tried? Adam must have had some fidelity to
|
|
|
|
|
> cypherpunks.
|
|
|
|
|
|
|
|
|
|
I have not tried, but I have been looking for entry points, and
|
|
|
|
|
have come up empty. One has to have an in, and one has
|
|
|
|
|
to listen before one speaks.
|
|
|
|
|
|
|
|
|
|
## the big problem
|
|
|
|
|
|
|
|
|
|
The urgent important problem that crypto currency has to solve is privacy and scaliing.
|
|
|
|
|
|
|
|
|
|
But cannot solve it just by creating a currency that is private and scales,
|
|
|
|
|
because scaling is not a competitive advantage over ten thousand scamcoins,
|
|
|
|
|
five thousand shitcoins, and two dozen altcoins,
|
|
|
|
|
until you reach a market capitalization of thirty billion dollars,
|
|
|
|
|
which is when scaling started to bite bitcoin in 2016-2017
|
|
|
|
|
|
|
|
|
|
Further, all the recursive snark libraries are rough around the edges.
|
|
|
|
|
Polygon's Poly2 is OK, but though theoretically open source,
|
|
|
|
|
it is not exactly open source, there are complications and gotchas.
|
|
|
|
|
|
|
|
|
|
So, the path is to create a privacy social net tool first.
|
|
|
|
|
A tool where you can securely have public and private conversations
|
|
|
|
|
without your IP being discoverable. Bitmessage done right.
|
|
|
|
|
|
|
|
|
|
A Dao that facilitates stuff done wth crypto currency,
|
|
|
|
|
such as Bisq and Particl, needs such a social tool,
|
|
|
|
|
and what they have is rather broken.
|
|
|
|
|
|
|
|
|
|
A Dao can organize over such a tool in ways that flagrantly fail the Howey test.
|
|
|
|
|
Which is to say, it can openly organise in a way that is
|
|
|
|
|
efficient and transparent to investors, a sovereign corporation,
|
|
|
|
|
while existing daos are dancing around the Howey test,
|
|
|
|
|
and so are opaque and disorderly.
|
|
|
|
|
|
|
|
|
|
So, create, not a crypto currency, but an environment for such Daos.
|
|
|
|
|
Among them daos for trading crypto currency.
|
|
|
|
|
A Dao that facilitates crypto currency transactions needs a trade currency
|
|
|
|
|
and dao ownership currency (substitute for shares).
|
|
|
|
|
These are apt to be one and the same, to obfuscate the Howey test,
|
|
|
|
|
but they need not be and probably should not be.
|
|
|
|
|
|
|
|
|
|
There are a whole lot of capabilities that a crypto coin needs
|
|
|
|
|
-- and we see that even in things that are well funded by many large corporations,
|
|
|
|
|
these things are geneally missing.
|
|
|
|
|
|
|
|
|
|
Blockstream does not have a satisfactory lightning wallet,
|
|
|
|
|
and their business plan depends on the existence of a satisfactory lightning wallet.
|
|
|
|
|
Litecoin has demonstrated atomic exchange between
|
|
|
|
|
Bitcoin, bitcoin lightning, Litecoin, and litecoin lightning,
|
|
|
|
|
but does not have a dao in which to do it. Particl is not quite working,
|
|
|
|
|
and Bisq lacks important things and still, after all these years,
|
|
|
|
|
has known major bugs which can cause the loss of lots of money.
|
|
|
|
|
|
|
|
|
|
Blockstream's aqua is sort of a lightning wallet, and sort of not.
|
|
|
|
|
It is not quite what they need, and lack. And very few people are using it.
|
|
|
|
|
It is not really a proper connection to the lightning network.
|
|
|
|
|
It is what they could come up with in a hurry.
|
|
|
|
|
|
|
|
|
|
This stuff is hard and takes a long time to write.
|
|
|
|
|
|
|
|
|
|
My initial business plan was: Plan A: Issue a private and scalable currency --> ????? --> profit
|
|
|
|
|
|
|
|
|
|
Revised business plan. Plan B: Issue a privacy social net that conceals IP addresses.
|
|
|
|
|
Bitmessage does this OK, but it is abandonware and mighty rough around the edges,
|
|
|
|
|
and being written in python, really cannot be fixed.
|
|
|
|
|
Large python projects accumulate such technical debt that only the original programmer
|
|
|
|
|
can fix them, and become ever more fragile to minor,
|
|
|
|
|
obscure, and seemingly irrelevant changes in their environment.
|
|
|
|
|
|
|
|
|
|
Get early adopters to use it. One obvious use case is bitcoin mixing.
|
|
|
|
|
We have mixers, but the social environments that made them usable have all been shut down.
|
|
|
|
|
|
|
|
|
|
An important use case for bitmessage was selling services for crypto currency
|
|
|
|
|
to people who did not want to reveal their IP address.
|
|
|
|
|
This use case becomes a lot more conveniient if we can lift crypto transactions on existing privacy currencies
|
|
|
|
|
(Litecoin and Monero) and semi secure currencies (lightning) into the communication channel,
|
|
|
|
|
as Nostr does a sort of mostly OK job of lifting lightning
|
|
|
|
|
into the communication channel.
|
|
|
|
|
First such use, following the footsteps of nostr tips.
|
|
|
|
|
|
|
|
|
|
Get existing Daos to use it
|
|
|
|
|
|
|
|
|
|
Get new Daos to use it. A Dao that wants to openly organise in an efficient manner transparent
|
|
|
|
|
to investors is going to want a very private privacy blockchain on which to issue its shares.
|
|
|
|
|
|
|
|
|
|
And now, it is back to plan A. (almost) A privacy blockchain
|
|
|
|
|
on which anyone can issue a Daocoin. Or a shitcoin or scamcoin.
|
|
|
|
|
|
|
|
|
|
But the privacy blockchain does not need to be fully scalable.
|
|
|
|
|
It does, however need to be future compatible with the technologies
|
|
|
|
|
that make full scalability possible. But we delay in the hope that by currency time,
|
|
|
|
|
recursive snarks libraries do not have quite so many rough edges
|
|
|
|
|
|
|
|
|
|
> > The size of this project is illustrated by how many other big
|
|
|
|
|
> > projects need some key element of this project, and do not have it.
|
|
|
|
|
|
|
|
|
|
> I'm not sure if I understood that to be honest.
|
|
|
|
|
|
|
|
|
|
The core of my plan has always been Web 3.0, a privacy social net,
|
|
|
|
|
and everything else is just monetization,
|
|
|
|
|
because software never gets done properly
|
|
|
|
|
or properly maintained without someone making money off it.
|
|
|
|
|
|
|
|
|
|
And I look at all these people doing Web 3.0 stuff,
|
|
|
|
|
or doing projects like particl that really require Web 3.0,
|
|
|
|
|
and they are not done.
|
|
|
|
|
|
|
|
|
|
> Can you double check Keet/Pear.. Holepunch thing? I belive a good
|
|
|
|
|
> part of Blockstream funding is coming from Tether. And Tether (and
|
|
|
|
|
> their CEO) loves Keet (like his brainchild). Problem is they don't
|
|
|
|
|
> have any good use case. I believe a project somehow leveraging would
|
|
|
|
|
> easily get funding from Blockstream hence Tether.
|
|
|
|
|
|
|
|
|
|
I have been trying to do that, but it is hard to get to the front of
|
|
|
|
|
the line of all the people who want to tell blockstream why
|
|
|
|
|
blockstream should fund them and their projects.
|
|
|
|
|
|
|
|
|
|
Also, I need to find the keywords needed to get the proposal
|
|
|
|
|
past the layer of idiot no men whose job is to protect them
|
|
|
|
|
from all those people with bright ideas as to why blockstream should fund them.
|
|
|
|
|
|
|
|
|
|
What words are they internally using for stuff that really needs to be done?
|
|
|
|
|
|
|
|
|
|
But some of the stuff I want done, they really need done.
|
|
|
|
|
>
|
|
|
|
|
> Also excuse me but how it would work if you stays anonymous and pay
|
|
|
|
|
> devs to work on it. How can they fund, doesn't it require
|
|
|
|
|
> psedenomous organization? Or do you think some can work in psedonmy
|
|
|
|
|
> but some can be non-anonymous while working on it?
|
|
|
|
|
|
|
|
|
|
I think they should promise an L-BTC bounty or lightning Bitcoin bounty
|
|
|
|
|
for someone who accomplishes certain goals.
|
|
|
|
|
Other people have used this funding model, albeit lightning Bitcoin.
|
|
|
|
|
|
|
|
|
|
> Even if you have the funding, it is not easy to bring talent on the
|
|
|
|
|
> table. What's your plan to find to hire the talent even if you can
|
|
|
|
|
> pay them?
|
|
|
|
|
|
|
|
|
|
Litecoin bounties for contributions that get included in the repository.
|
|
|
|
|
(Litecoin being arguably the best existing privacy currency -- at least when you use mweb addresses.
|
|
|
|
|
|
|
|
|
|
> > And so, all the larger moving parts that have to be part of the
|
|
|
|
|
> > ultimate coin, have to be part of something that has more immediate
|
|
|
|
|
> > utility, and is part of a business plan that will bring the project
|
|
|
|
|
> > closer to completion, and product of that completion closer to
|
|
|
|
|
> > getting past the cold start problem
|
|
|
|
|
> 100%
|
|
|
|
|
>
|
|
|
|
|
|
|
|
|
|
## collapse and cryptocurrency
|
|
|
|
|
|
|
|
|
|
>
|
|
|
|
|
> Or, do you think it will replace the Gold, nobody would need or want
|
|
|
|
|
> to use it.
|
|
|
|
|
>
|
|
|
|
|
> Today, if you ask me to accept Gold vs. Bitcoin, leaving aside the
|
|
|
|
|
> speculative part, I'd go 100% for gold. I'm not sure that would
|
|
|
|
|
> change in the future. But also maybe that's because I think I'm
|
|
|
|
|
> emotional about it. I always thought Gold is a godly thing, a "gift"
|
|
|
|
|
> of god to us punish or reward. No question fiat is a scam, or even
|
|
|
|
|
> in a good intent it is an opiod of an ecomy, however I'm really not
|
|
|
|
|
> convinced about Gold.
|
|
|
|
|
|
|
|
|
|
Obviously over the past few years, Bitcoin has risen enormously more than gold.
|
|
|
|
|
|
|
|
|
|
When it looked like full scale war might break out, bitcoin fell a little,
|
|
|
|
|
and gold rose considerably.
|
|
|
|
|
|
|
|
|
|
If the crisis is nuclear war, Gold, 22 LR rifle ammo, whiskey, tobacco,
|
|
|
|
|
and coffee are likely to be considerably more valuable investments than bitcoin.
|
|
|
|
|
|
|
|
|
|
If, on the other hand, the crisis is state internal collapse and red terror
|
|
|
|
|
against whites, straight males, and Christians, bitcoin because you can carry it through an airport,
|
|
|
|
|
while gold will be fairly useless
|
|
|
|
|
|
|
|
|
|
If the crisis is that you are likely to get conscripted to die in Eastern Europe or the middle east or Taiwan,
|
|
|
|
|
or all of them simultaneously, bitcoin will be useful, and gold fairly useless.
|
|
|
|
|
|
|
|
|
|
If the crisis is hyperinflation and collapse of the US dollar,
|
|
|
|
|
Gold and Bitcoin both work, but Bitcoin is better because
|
|
|
|
|
the primary problem will be transactions over distance.
|
|
|
|
|
|
|
|
|
|
If the problem is all of the above, simultaneously or in rapid succession, Bitcoin.
|