From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Introcing a side memory network to bitcoin for ads
Date: Wed, 18 Sep 2019 04:41:15 +0000 [thread overview]
Message-ID: <G3t3sIUqn2w2RiAhZaWnDLkTinq2PGDVlywBno4TYiy8YL4HnuoP9XiuwZcvGgCx4nmFkVLnS-OFzp0AnDt4BeSrQNbDSw4UDFSbKI3VlAo=@protonmail.com> (raw)
In-Reply-To: <0HN1H7TAZu7EQVML0UfntRj5-dlF8-oP7swl7LrUtCzZ7F6o7tLaPmAdBIw9AQCQ8i9AllzYHWXlv47gsl1d7w3vVeD6MvklgUAg_gIdTp8=@protonmail.com>
Good morning list,
In case it is not obvious how this mechanism can be used, let me give me some short discussion.
Many decentralized coin-mixing services require some concept of "maker", which serves as a temporary centralization in order to allow clients of the mixing service to find each other.
Such makers might advertise themselves, backing their advertisements with locked coins.
The text of the advertisement may very well be a machine-readable description, such as JSON, including information about the maker in the coin-mixing service.
Escrow services for decentralized real-good-to-digital-good marketplaces (e.g. decentralized exchanges) might advertise themselves over this mechanism also.
The actual advertising of marketplace offers might also be done via this mechanism.
Again, machine-readable descriptions might be transported over the advertisement text mechanism, in order to allow programs to present the "most natural" interface to end-users.
Regards,
ZmnSCPxj
> Good morning Tamas,
>
> Thank you for taking the time to implement my idea.
>
> I filed an issue proposing a feature to add a "contact point" fixed-length field to all advertisements.
> https://github.com/defiads/defiads/issues/1
> I believe this gives me the right to say: First post.
>
> I will try to take a look at building some kind of UI at some point in the next few months or years.
>
> Regards,
> ZmnSCPxj
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Tuesday, September 17, 2019 8:04 AM, Tamas Blummer via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote:
>
> > I introduced you to the pattern of a side memory to bitcoin in [1] and
> > promised an implementation of it.
> > Here you are.
> > defiads is a side memory network to bitcoin, implemented in Rust, built
> > on top of rust-bitcoin, murmel, hammersbald, rust-bitcoinconsenus,
> > rust-wallet, all Rust open source free to grab at
> > https://github.com/defiads/defiads
> > defiads builds a peer-to-peer network to distribute textual ads, as
> > first suggested by ZmnSCPxj[4]. I hope that it will serve
> > decentralized finance applications with an infrastructure to distribute
> > ads, order books, coinjoin proposals etc.
> > Every defiads node maintains a copy of a network-wide shared 1GB memory
> > pool of current ads.
> > An ad is replicated to other nodes as long as there is some bitcoin
> > locked to it on the bitcoin network. Locking means someone transferred
> > some sats to an address that is associated with the ad using the
> > pay-to-contract protocol[2]. The address does not release the bitcoins
> > until a predefined time span that is the duration of the advertizement,
> > this is accomplished with OP_CSV. The ad will be evicted from the pool
> > as soon as the coins locked to it are spendable again.
> > defiads ranks advertizements by the ratio of used space divided by
> > bitcoins locked and will only replicate the top 1GB of this ranked list.
> > You may read the ads by starting a defiads process of your own and
> > the query the content through its JSON-RPC API.
> > You may place ads by performing the following steps, with its JSON-RPC API
> >
> > 1. deposit some bitcoins into your defiads node's wallet
> >
> > 2. prepare an ad, providing its category, abstract and content
> >
> > 3. fund the ad by locking some of the bitcoins to it for a limited term
> > of the advertizement
> >
> > 4. you may withdraw your coins from the defiads node's wallet after the
> > advertizement expires
> > defiads handles the association with ads, locking and unlocking coins.
> > Implementation notes
> > defiads connects to both the bitcoin and its own peer-to-peer network.
> > You do not need to run a bitcoin node as defiads only needs a small
> > fraction of the information on the bictoin blockchain and retrieves that
> > on its own, as an SPV node.
> > The defiads node's wallet is compatibe with that of TREZOR, Ledger,
> > Greenwallet and many other wallets that support BIP38, BIP44, BIP48,
> > BIP84 key generation and use standards.
> > defiads uses Invertible Bloom Lookup Tables[3] to synchronize the ads
> > pool with its peers.
> > Status
> > It seems to work, but you should not yet use with real bitcoins,
> > therefore by default it connects the bitcoin's test network.
> > There is no discovery for the network yet, so you will have to know some
> > peer in the network to see other than your own ads. Write me a direct
> > email if you'd like to connect to my node.
> > Future developent
> > Should the use become popular then 1GB pool become tight, then people
> > will have to compete for its use. Some might not have enough bitcoin's
> > to lock and might therefore pay others to lock theirs to fund an
> > advertizement. defiads network could match both sides and thereby give
> > rise to bitcoin's first truly risk less interest rate market.
> > defiads is currently downloading, but not storing,
> > the blocks after its birth date. This will no longer be needed once
> > BIP158 filters are served and committed by Bitcoin Core.
> > I hope that someone builds a nice UI on top of the JSON RPC as that is
> > not my area of expertise.
> > Tamas Blummer
> > [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-August/017264.html
> > [2] https://arxiv.org/pdf/1212.3257.pdf
> > [3] https://arxiv.org/pdf/1101.2245.pdf
> > [4] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-July/017083.html
> >
> >
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
prev parent reply other threads:[~2019-09-18 4:41 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-14 13:21 [bitcoin-dev] Introcing a side memory network to bitcoin for ads Tamas Blummer
2019-09-17 1:54 ` ZmnSCPxj
2019-09-18 4:41 ` ZmnSCPxj [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='G3t3sIUqn2w2RiAhZaWnDLkTinq2PGDVlywBno4TYiy8YL4HnuoP9XiuwZcvGgCx4nmFkVLnS-OFzp0AnDt4BeSrQNbDSw4UDFSbKI3VlAo=@protonmail.com' \
--to=zmnscpxj@protonmail.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox