Re: [bitcoin-dev] Block Batch Filters for Light Clients

[Tamas Blummer via bitcoin-dev]

Hi Aleksey,

Yes, BIP158 uses the block hash to seed the hash function, which makes distinct 
block filters non-aggregatable 
for common values. Aggregate fiters on ranges of blocks would have to use some 
other seed and then 
achive significant savings using the same design.

I think that the most likely use of filters is to decide if a newly announced 
block should be downloaded and 
not scanning over the entire chain, where aggregate filters would help. I also 
suspect that whole chain 
scans would be better served with plain sequential reads in map-reduce style.

Typical clients do not care of filters for blocks before the birth date of 
their wallet’s keys, so they skip over the 
majority of history which is a bigger saving than any aggregate filter.

I wish we get a filter committed as commitment would unlock more utility than 
any marginal savings through
more elaborate design.

Tamas Blummer

> On Sep 19, 2019, at 19:20, admin--- via bitcoin-dev 
>  wrote:
> 
> Hello list, 
> 
> Here is a link for a draft of a BIP for  compact probabilistic block filters 
> alternative of BIP 158
> 
> https://docs.google.com/document/d/1jH9tEUyb9w2OZd4-kxfGuyNIIZzmgkEb_z0qSxv80ik/edit?usp=sharing
>  
> 
> 
> Summary:
> 
>  - BIP 158  false positive rate is low, we can achieve lower bandwidth with 
> higher false positive rate filter while sync blockchain
> 
>  - BIP 158 not do not support filter batching by design of used parameters 
> for siphash and Golomb coding optimal parameters
> 
>  - Alternative compression with delta coding and splitting data to 2 bit 
> string  sequences. First for data without prefixes, second one for 
> information about  bit length written to first sequence.
>Second sequence have a lot of duplicates,  compressed with 2 round of 
> Huffman algorithm. (Effectivity about 98% vs Golomb with optimal parameters)
> 
>  - Block filters batching reduce filter size significantly
> 
> - Separation of filters by address type allows lite client not to download 
> redundant information without compromising privacy.
> 
> - Lite client filters download strategy: get biggest filter (smallest 
> blocks/size rate) for blocks range, in case positive test  -> get medium 
> filters to reduce blocks range ->  get block filters for affected range -> 
> download affected blocks over TOR 
> 
> Implementation (python): 
> https://github.com/bitaps-com/pybtc/blob/bugfix/pybtc/functions/filters.py#L172
>  
> 
> 
> Exactly information from mainnet  about size for separated filters by address 
> types and batch size will be added within few days.
> 
> Thanks for any feedback.
>   Aleksey Karpov
> 
> ___
> 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

[bitcoin-dev] Introcing a side memory network to bitcoin for ads

[Tamas Blummer via bitcoin-dev]

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] side memory - Transient memory of an other peer to peer network controlled through the bitcoin utxo set

[Tamas Blummer via bitcoin-dev]

It appears to me that there is a generic design pattern for peer to peer 
networks,
that we might call side memory.

The name is justified with some similarity to side chains. Side memory is 
however
not about a persistent store, but some transient memory of an other peer to 
peer network.

The UTXO set is the shared transient memory of the bitcoin network.

Just like we can link the bitcoin block chain with a side chain, we can link
the transient memory of an other network with the UTXO set of bitcoin.

The other network’s transient memory would hold an item until a uniquelly 
associated
a coin in the UTXO set is unspent. There are many ways to associate data with
an UTXO. How this is done is not a concern here. The method must however allow
the coin to be spent again, so the UTXO set can also trigger eviction of the 
associated
data from the other network’s memory.

The utility of such association is to impose control and the scarcity of 
bitcoin to
some other network’s transient memory.

Since the number of possible UTXOs is huge (21 million * 100million) an
associated peer to peer network will want to raise the bar for UTXOs eligible
to enter its store.

An obvious choice for raising the bar is requiring more satoshis to be 
committed.
The other network may dynamically tailor this requirement or let users compete
for a fixed capacity by committing higher amounts.

Observing the UTXO set is however not a cheap operation. Nodes of the other
network would have to also run a bitcoin node to be sure they do not miss
changes of the UTXO.

There is however a way to significantly simplify this task by using time locks 
and
SPV validation as follows:

The UTXO committing to associated data would have a relative timelock, such that
it can not be spent within n blocks after it entered the UTXO set. (with OP_CSV)

A network node that originally publishes the data would also send an SPV proof
of the inclusion of associated commitment into the bitcoin blockchain to its 
peers.

Other network nodes would therefore only need to observe the progress of
bitcoin’s header chain to validate the proof, which is the commitment 
transaction
and the path to merkle root, before accepting data into their transient store.

The commitment transaction also tells them how long the output can not be spent,
therefore they are relived the burden of watching for UTXO spends. Instead they
can evict the associated data from their transient store as soon as the header
chain they oberve is progressed past the relative locktime.

Nodes that publish new data would have to listen to all blocks after they
broadcast the commitment, until they see it confirmed and can extract the proof.
This could be further optimized if BIP158 filters were available and committed.

The network nodes could use IBLTs (Invertible Bloom Lookup Tables) to distribute
associated data.

Such an associated network would be lightweight since only observing and
storing bitcoin’s header chain and its own peer to peer network.

I will soon release the code of a network that implements this design pattern,
with the SPV optimization and IBLTs, and am looking for help to test it in a
limited deployment, before letting it out into the wild.

Please drop me a mail if you’d like to help there.

Prior art that I summed up as side memory:

The idea of linking names with UTXO goes back to the first fork of Bitcoin and
was significantly upgraded in the numerifides proposal[1] of tyzbit

ZmnSCPxj proposed an advertizement network in which the network's content
is controlled by associated UTXOs in [2].

I observed that time locked commitments would uncover to bitcoin’s internal
riskless interest rate [3].

The pattern is useful as sybill attack protection of coinjoin networks as time 
locked
commitments can act as fidelity bonds [4]

Regards,

Tamas Blummer

[1] 
https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-April/001207.html
[2] 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-July/017083.html
[3] 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-June/017059.html
[4] 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-July/017169.html


signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Improving JoinMarket's resistance to sybil attacks using fidelity bonds

[Tamas Blummer via bitcoin-dev]

In summary I see three mechansims of making use costly:

1. burn
2. time locked funds, locker will incure opportunity cost
3. proven coin age, holder did incure opportunity cost

I dislike burn as usage of a service is infinite while coin supply is finite.

I prefer time locked funds over coin age as locked funds do not need proof of
unspentness, they can not be spent. Therefore time locked funds can be 
sufficiently
proven with SPV. The user of the service could post SPV proof with the request.

Regards,

Tamas Blummer

> On Jul 27, 2019, at 21:34, David A. Harding via bitcoin-dev 
>  wrote:
> 
> On Thu, Jul 25, 2019 at 12:47:54PM +0100, Chris Belcher via bitcoin-dev wrote:
>> A way to create a fidelity bond is to burn an amount of bitcoins by
>> sending to a OP_RETURN output. Another kind is time-locked addresses
>> created using OP_CHECKLOCKTIMEVERIFY where the valuable thing being
>> sacrificed is time rather than money, but the two are related because of
>> the time-value-of-money.
> 
> Timelocking bitcoins, especially for long periods, carries some special
> risks in Bitcoin:
> 
> 1. Inability to sell fork coins, also creating an inability to influence
> the price signals that help determine the outcome of chainsplits.
> 
> 2. Possible inability to transition to new security mechanisms if
> a major weakness is discovered in ECC or a hash function.
> 
> An alternative to timelocks might be coin age---the value of a UTXO
> multiplied by the time since that UTXO was confirmed.  Coin age may be
> even harder for an attacker to acquire given that it is a measure of
> past patience rather than future sacrifice.  It also doesn't require
> using any particular script and so is flexible no matter what policy the
> coin owner wants to use (especially if proof-of-funds signatures are
> generated using something like BIP322).
> 
> Any full node (archival or pruned) can verify coin age using the UTXO
> set.[1]  Unlike script-based timelock (CLTV or CSV), there is no current
> SPV-level secure way to prove to lite clients that an output is still
> unspent, however such verification may be possible within each lite
> client's own security model related to transaction withholding attacks:
> 
> - Electrum-style clients can poll their server to see if a particular
>  UTXO is unspent.
> 
> - BIP158 users who have saved their past filters to disk can use them to
>  determine which blocks subsequent to the one including the UTXO may
>  contain a spend from it.  However, since a UTXO can be spent in the
>  same block, they'd always need to download the block containing the
>  UTXO (alternatively, the script could contain a 1-block CSV delay
>  ensuring any spend occurred in a later block).  If BIP158 filters
>  become committed at some point, this mechanism is upgraded to SPV-level
>  security.
> 
>> Note that a long-term holder (or hodler) of bitcoins can buy time-locked
>> fidelity bonds essentially for free, assuming they never intended to
>> transact with their coins much anyway.
> 
> This is the thing I most like about the proposal.  I suspect most
> honest makers are likely to have only a small portion of their funds
> under JoinMarket control, with the rest sitting idle in a cold wallet.
> Giving makers a way to communicate that they fit that user template
> would indeed seem to provide significant sybil resistance.
> 
> -Dave
> 
> [1] See, bitcoin-cli help gettxout
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev



signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Improving JoinMarket's resistance to sybil attacks using fidelity bonds

[Tamas Blummer via bitcoin-dev]

Hi David,

Aquiring coin age is hard not only for an attacker but for any user that
happened to move his funds lately.

Even if coin age is available, proofs of using it to fund a particular operation
are not sybill resistant. Only a centralized service would know for sure that
proof is only used once and such centralization would defeat the purpose.

In contrast time locking such that it is uniquely linked with the operation
is always possible as funds could also be rented to lock in a decentralized 
manner.

Regards,

Tamas Blummer

> On Jul 27, 2019, at 21:34, David A. Harding via bitcoin-dev 
>  wrote:
> 
> On Thu, Jul 25, 2019 at 12:47:54PM +0100, Chris Belcher via bitcoin-dev wrote:
>> A way to create a fidelity bond is to burn an amount of bitcoins by
>> sending to a OP_RETURN output. Another kind is time-locked addresses
>> created using OP_CHECKLOCKTIMEVERIFY where the valuable thing being
>> sacrificed is time rather than money, but the two are related because of
>> the time-value-of-money.
> 
> Timelocking bitcoins, especially for long periods, carries some special
> risks in Bitcoin:
> 
> 1. Inability to sell fork coins, also creating an inability to influence
> the price signals that help determine the outcome of chainsplits.
> 
> 2. Possible inability to transition to new security mechanisms if
> a major weakness is discovered in ECC or a hash function.
> 
> An alternative to timelocks might be coin age---the value of a UTXO
> multiplied by the time since that UTXO was confirmed.  Coin age may be
> even harder for an attacker to acquire given that it is a measure of
> past patience rather than future sacrifice.  It also doesn't require
> using any particular script and so is flexible no matter what policy the
> coin owner wants to use (especially if proof-of-funds signatures are
> generated using something like BIP322).
> 
> Any full node (archival or pruned) can verify coin age using the UTXO
> set.[1]  Unlike script-based timelock (CLTV or CSV), there is no current
> SPV-level secure way to prove to lite clients that an output is still
> unspent, however such verification may be possible within each lite
> client's own security model related to transaction withholding attacks:
> 
> - Electrum-style clients can poll their server to see if a particular
>  UTXO is unspent.
> 
> - BIP158 users who have saved their past filters to disk can use them to
>  determine which blocks subsequent to the one including the UTXO may
>  contain a spend from it.  However, since a UTXO can be spent in the
>  same block, they'd always need to download the block containing the
>  UTXO (alternatively, the script could contain a 1-block CSV delay
>  ensuring any spend occurred in a later block).  If BIP158 filters
>  become committed at some point, this mechanism is upgraded to SPV-level
>  security.
> 
>> Note that a long-term holder (or hodler) of bitcoins can buy time-locked
>> fidelity bonds essentially for free, assuming they never intended to
>> transact with their coins much anyway.
> 
> This is the thing I most like about the proposal.  I suspect most
> honest makers are likely to have only a small portion of their funds
> under JoinMarket control, with the rest sitting idle in a cold wallet.
> Giving makers a way to communicate that they fit that user template
> would indeed seem to provide significant sybil resistance.
> 
> -Dave
> 
> [1] See, bitcoin-cli help gettxout
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev



signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Improving JoinMarket's resistance to sybil attacks using fidelity bonds

[Tamas Blummer via bitcoin-dev]

Hi Chris,

yes, fidelity bonds can impose cost to make sybill attacks more expensive 
therefore less likely.
I prefer the flavor with CHECKSEQUENCEVERIFY which imposes opportunity cost, 
just as effective
as burning, but is sustainable.

Imposing opportunity costs however requires larger time locked amounts than 
burning and the
user might not have sufficient funds to do so. This is however not a 
restriction but an opportunity
that can give rise to an additional market of locking UTXOs in exchange of a 
payment.

This would give rise to a transparent interest rate market for Bitcoin an 
additional huge benefit.

Regards,

Tamas Blummer

> On Jul 25, 2019, at 13:47, Chris Belcher via bitcoin-dev 
>  wrote:
> 
> JoinMarket[1] can be sybil attacked today at relatively low cost which
> can destroy its privacy. Bitcoins can be sacrificed with burner outputs
> and time-locked addresses (also called fidelity bonds), and this can be
> used to greatly improve JoinMarket's resistance to sybil attacks.
> 
> With real-world data and realistic assumptions we calculate that under
> such a fidelity bond system an adversary would need to lock up
> 30,000-80,000 bitcoins for months, or send 45-120 bitcoins to burner
> addresses to have a good chance of sybil attacking the system if it were
> added to JoinMarket.
> 
> This increased resistance to sybil attacks would most likely cause
> coinjoin fees to rise. I think the added cost is worth it for the
> greatly improved privacy, because today miner fees are the biggest cost
> to JoinMarket takers not coinjoin fees which are very low. Users should
> definitely share their opinion on fees after reading the document.
> 
> ## Introduction
> 
> JoinMarket creates a market for coinjoins, allowing anyone to create
> equal-amount coinjoins for any amount they want at any time they want.
> In return they pay a fee for the liquidity made available to them. The
> project has existed since 2015 and has probably created hundreds of
> thousands of coinjoins since then. Today there is available liquidity
> for creating coinjoins with amounts up to about 400 btc per coinjoin output.
> 
> ### Sybil attacks
> 
> JoinMarket, like many other schemes where participants are free to
> anonymously enter, can be targetted by sybil attacks. In JoinMarket this
> would work by an attacker running lots of maker bots which attempt to be
> all the makers in every coinjoin. If successful the attacker would have
> enough information unmix every coinjoin.
> 
> One way to solve the problem of sybil attacks is centralization. For
> example coinjoins could be constructed on a centralized server. Then
> random anonymous participants cant sybil attack because they can't
> control the coinjoin construction, but this comes at the cost that the
> server can sybil attack very easily. So this solution is probably a bad
> tradeoff.
> 
> In general, sybil attacks are solved by making them expensive. For
> example, bitcoin mining resists sybil attacks because it requires a
> provable sacrifice of electricity to mine. A bitcoin user can calculate
> the actual monetary value that an attacker must spend in order to
> reverse their transaction.
> 
> Likewise in JoinMarket such a sybil attack is not free either as the
> attacker needs to own enough bitcoins to run enough maker bots for all
> the coinjoins.
> 
> ### Today's low cost for sybil attacks
> 
> A paper on JoinMarket [Möser, Malte and Rainer Böhme. “Join Me on a
> Market for Anonymity.” (2016).] calculates the requirement of such a
> sybil attack in 2016 to be just 32,000 USD. According to the paper such
> an attack would succeed 90% of the time and the investment is
> recoverable afterwards so that figure for the requirement isn't even a
> true cost.
> 
> JoinMarket has been improved since 2016 and more makers have joined, so
> the true requirement is perhaps 2x or 3x higher today, but it is still
> relatively low.
> 
> Even with future improvements like fixing issue #693 [2] the requirement
> of a sybil attack would probably only rise another 2x.
> 
> Apart from the cost to sybil attack being low, there is also the odd
> situation that smaller coinjoin amounts receive less sybil protection
> than large ones. It costs 100x less to sybil attack a transaction of 0.1
> btc than one of 10 btc. Why should smaller amounts receive less
> sybil-resistance and therefore less privacy?
> 
> ### Liquidity
> 
> When creating this project, it was expected that many more people would
> enter the market as makers and so the cost of a sybil attack would be
> very high. That has not happened. One reason is that everyone who wants
> to create a coinjoin is able to even for large amounts. The fundamental
> problem is that takers are paying-for and getting liquidity, but not
> necessarily sybil-resistance.
> 
> Another smaller reason for the low cost of sybil attacks is that many
> people don't want to store too many bitcoins on an computer connected to
> the internet.
> 
> What is 

Re: [bitcoin-dev] Bitcoin Core to disable Bloom-based Filtering by default

[Tamas Blummer via bitcoin-dev]

Hi Justus,

It might be helpful to consult the Rust implementation  of BIP158 here:
https://github.com/rust-bitcoin/rust-bitcoin/blob/master/src/util/bip158.rs

It has a cleaner structure than Core or Neutrino, includes server and client 
side
and passes Core's test vectors.

Regards,

Tamas Blummer

> On Jul 22, 2019, at 17:58, Justus Ranvier via bitcoin-dev 
>  wrote:
> 
> Signed PGP part
> On 7/22/19 12:01 AM, Matt Corallo via bitcoin-dev wrote:
>> Finally, regarding alternatives, the filter-generation code for BIP
>> 157/158 has been in Bitcoin Core for some time, though the P2P serving
>> side of things appears to have lost any champions working on it. I
>> presume one of the Lightning folks will eventually, given they appear to
>> be requiring their users connect to a handful of their own servers right
>> now, but if you really need it, its likely not a ton of work to pipe
>> them through.
> 
> If you want projects to adopt BIP-157/158, you'd do well to fix the
> numerous errors in the specification.
> 
> As it stands right now it is impossible to implement the protocol using
> the specification because he code examples are broken to the point of
> appearing intentionally sabotaged.
> 
> 
> 



signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Generalized covenants with taproot enable riskless or risky lending, prevent credit inflation through fractional reserve

[Tamas Blummer via bitcoin-dev]

Good morning ZmnSCPxj,

thank you very much for sharing your BCAN idea and thought process in detail.

I add some thoughs that very likely occured to you, but not formulated 
explicitelly:

1. The unique feature of such advertisement network is that it has no owner, 
just like the Bitcoin network.
If it had an owner, that owner could simply bill for use, but would also be 
forced to restrict access or apply some sort of censorship.
This is why usage costs is imposed through opportunity cost and not billed.

2. Since opportunity cost of one Bitcoin for a short time period is magnitudes 
less than its face value, one would need significant
Bitcoin amounts to impose meaningful costs so they have the chance to be 
included into BCANs purposedly limited bandwidth.
Those who would want to place an ad will often not have sufficient amount of 
Bitcoin holdings which lets them borrow UTXOs.

3. If borrowed Bitcoin is certain to be returned (as in your construction) then 
this offers riskless interest for HODLer.

4. Bitcoin’s most popular use is storing wealth whereby this use currently 
completely relies on the assumption that “the number goes up”.
A service that delivers interest on HODLed coins without exposing the HODLer to 
credit risk of the borrower is a huge game changer.

5.This scheme allows HODLer a concious decision whom or what project they fund.

For above reasons I think that this is a crucial design pattern to build 
censorship resistant networks which also give rise to riskless interest on 
Bitcoin.

My finance examples where abstract and less interesting for this audience but 
the BCAN should ring the bell for many.

As you said BCAN is possible with current Bitcoin, therefore we should no 
longer discuss it under the covenant topic.
The idea of debt covenant will likely resurface as soon as this design pattern 
proves to be useful in practice and one is looking for
a more flexible solution. I am confident we will get there, but not as fast as 
I initially thought.

Regards,

Tamas Blummer

> On Jul 9, 2019, at 12:31, ZmnSCPxj via bitcoin-dev 
>  wrote:
> 
> Good morning all,
> 
> I will attempt to restart my thinking from initial principles regarding my 
> proposed "Bitcoin Classified Ads Network".
> 
> Nodes behave this way:
> 
> * Nodes in this network gossip advertisements.
> * These advertisements refer to a UTXO that must be unspent at the chain tip 
> considered by each node, else they would be rejected.
> * The referred UTXO must contain a commitment to the text of the 
> advertisement, else the advertisement is rejected.
> * Nodes have a maximum limit on the total size of all advertisements they 
> retain and propagate to new nodes, or gossip to their peers.
>  This is a deliberate design decision.
> * If nodes exceed the above limit, they will sort advertisements according to 
> a value-rate, the value of the UTXO divided by the storage size of the 
> advertisement, and prune advertisements with low value-rate until they are 
> within the limit again.
> * Once the backing UTXO is spent, the advertisement is removed by nodes that 
> follow that chaintip.
> * As the name ***Classified Ads*** suggests, each advertisement also 
> indicates a "class" in which they belong to.
> 
> Then, from the above, we derive how a seller might behave.
> 
> * Sellers will attempt to put the minimum possible value into a UTXO 
> committing to an advertisement, to reduce the opportunity cost of using the 
> value elsewhere.
> * Thus the rent of the advertisement in this case is paid to joinmarket 
> makers and LN forwarding nodes, as the value used in a UTXO backing an 
> advertisement is not useable in joinmarket/LN.
> * Sellers remain in full control of their advertising UTXO, and can spend it 
> at any time.
> * Sellers may spend part of the UTXO and put the remaining funds into a 
> change address that is a new advertising UTXO, and re-transmit the 
> advertisement, this time pointing to the new change UTXO.
> * However, if the remaining change becomes too low, then its value-rate may 
> drop below the lowest value-rate that BCAN nodes will retain in their 
> (deliberately limited) storage, thus also deleting their advertisement from 
> the BCAN.
> * Presumably, the reason for advertising at all, is that the seller considers 
> the cost of advertising to be less than the expected gain of actually selling 
> their product.
> * Thus, even if the seller has the ability to spend the UTXO at any time, 
> they run the risk of spending too much and thus removing their advertisement 
> from the BCAN, and losing the expected gain of having the advertisement exist 
> on the BCAN.
> * A utility-maximizing seller would therefore not spend a minimal-value UTXO 
> backing the advertisement until it has gained the advantage of actually 
> selling the product, even if it has the option to do so: it is a forced move.
> * The cost of keeping the minimal-value UTXO unspent is the opportunity cost 
> in that the value may 

Re: [bitcoin-dev] Generalized covenants with taproot enable riskless or risky lending, prevent credit inflation through fractional reserve

[Tamas Blummer via bitcoin-dev]

Hi Eric,

Your cryproeconomic theories may describe correctly Bitcoin as money, but fall 
short of describing a Bitcoin that would also offer reliable memory for other 
uses.

In consequence you miss, that:

1. If the reliable memory that enables money would have more uses then even 
temporary use of the memory would have utility, therefore value. Bitcoin as is, 
does not have consensus rules to enable reliable alternate uses.

2. Finite supply of coins implies a finite memory capacity of Bitcoin. 
Alternate use of the memory requires that units at least temporarily become 
un-fungible, enforced by consensus. Alternate uses would then have to compete 
for units of memory, which would give rise to a price paid to those enabling 
alternate use, even if temoprarily.

3. If giving up control temorarily has a positive price (through 2) and return 
of control is certain (enforced by consenus) then the price paid is riskless 
interest for those giving up temporary control.

4. If a use requires more units of memory then it imposes higher cost to use 
and it since memory units are finite it imposes more severe scarcity.

Further certainly subjective remarks:

Although burning and loss is unavoidable and therefore Bitcoin (as is) is 
unsustainable we should design systems that they sustain it as long as possible 
(as is). Therefore a requirement to burn for any of unlimited number of uses 
should be avoided.

We currently perceive borrowed money just as good as (fungible with) any other 
money. This is a consequence that money actually comes into existence through 
someone borrowing it. Money on your account is a loan you gave the bank and 
even paper cash is a loan you gave the central bank.

Bitcoin is different as it just is, it is not borrowed into existence. 
Therefore it is not fungible with borrowed version of itself. This however does 
not imply that its borrowed version is worthless as it might be worth something 
if there is a use for it.

Tamas Blummer

> On Jul 7, 2019, at 03:30, Eric Voskuil  wrote:
> 
> I have published a summary here:
> 
> https://github.com/libbitcoin/libbitcoin-system/wiki/Risk-Free-Return-Fallacy 
> 
> 
> Barring any new consequential inputs I’ll refrain from further comment.
> 
> e
> 



signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Generalized covenants with taproot enable riskless or risky lending, prevent credit inflation through fractional reserve

[Tamas Blummer via bitcoin-dev]

Hi Eric,

> On Jul 6, 2019, at 03:28, Eric Voskuil  wrote:
> 
> 
> 
>> On Jul 5, 2019, at 17:17, ZmnSCPxj  wrote:
>> 
>> Good morning Eric,
>> 
>>> But it’s worth noting that early recovery of the UTXO entirely eliminates 
>>> the value of the time lock cost to the ad market. The most obvious example 
>>> is one encumbering the coin to himself, then releasing it with his own two 
>>> signatures whenever he wants. In other words, there is no encumbrance at 
>>> all, just a bunch of pointless obscurantion.
>> 
>> You still do not understand.
>> I strongly suggest actually reading the post instead of skimming it.
> 
> I am responding to the cryptoeconomic principles, not the implementation 
> details. Based on your comments here I am not misrepresenting those 
> principles.
> 
> For example, I have shown that the multisig unlock implementation reduces the 
> presumably-encumbered UTXO to simply a UTXO. You have not disputed that. In 
> fact below you have accepted it (more below).
> 
>> The advertisement is broadcast to new nodes on the ad network if and only if 
>> its backing UTXO remains unspent.
>> Once the UTXO is spent, then the advertisement is considered no longer valid 
>> and will be outright deleted by existing nodes, and new nodes will not learn 
>> of them (and would consider it spam if it is forced to them when the UTXO is 
>> already spent, possibly banning the node that pushes the advertisement at 
>> them).
>> 
>> Thus the locked-ness of the UTXO is the lifetime of the advertisement.
> 
> The term “locked” here is misused. A unspent output that can be spent at any 
> time is just an unspent output. The fact that you can “unencumber” your own 
> coins should make this exceedingly obvious:
> 
>> Once you disencumber the coins (whether your own, or rented) then your 
>> advertisement is gone; forever.
> 
> As I have shown, there is no *actual* encumbrance.
> 

If you have to forgo using your money while using a service that encumbers you. 
You incur opportunity cost proportional to time you use the service and the 
amount you waived to use elsewhere.
No crypto is needed to understand this.


>> Your advertisement exists only as long as the UTXO is unspent.
> 
> Exactly, which implies *any* UTXO is sufficient. All that the ad network 
> requires is proof of ownership of any UTXO.
> 

Not any, but one with significant value, so a service with limited bandwith can 
prioritize by that.

> Best,
> Eric
> 
>> Regards.
>> ZmnSCPxj

Best,

Tamas Blummer


signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Generalized covenants with taproot enable riskless or risky lending, prevent credit inflation through fractional reserve

[Tamas Blummer via bitcoin-dev]

> On Jul 6, 2019, at 01:16, ZmnSCPxj  wrote:
> 
> Good morning Eric,
> 
> 
> Sent with ProtonMail Secure Email.
> 
> ‐‐‐ Original Message ‐‐‐
> On Saturday, July 6, 2019 3:27 AM, Eric Voskuil  > wrote:
> 
>>> On Jul 4, 2019, at 21:05, ZmnSCPxj zmnsc...@protonmail.com wrote:
>>> Good morning Eric,
>>> 
 As with Bitcoin mining, it is the consumed cost that matters in this 
 scenario, (i.e., not the hash rate, or in this case the encumbered coin 
 face value). Why would the advertiser not simply be required to burn .1 
 coin for the same privilege, just as miners burn energy? Why would it not 
 make more sense to spend that coin in support of the secondary network 
 (e.g. paying for confirmation security), just as with the burning of 
 energy in Bitcoin mining?
>> 
>> Good morning ZmnSCPxj,
>> 
>>> Using the unspentness-time of a UTXO allows for someone advertising a 
>>> service or producer to "close up shop" by simply spending the advertising 
>>> UTXO.
>>> For instance, if the advertisement is for sale of a limited stock of goods, 
>>> once the stock has been sold, the merchant (assuming the merchant used own 
>>> funds) can simply recover the locked funds, with the potential to reinvest 
>>> them elsewhere.
>>> This allows some time-based hedging for the merchant (they may be willing 
>>> to wait indefinitely for the stock to be sold, but once the stock is sold, 
>>> they can immediately reap the rewards of not having their funds locked 
>>> anymore).
>> 
>> This is a materially different concept than proposed by Tamas.
>> 
>> “...he gives up his control of the coins until maturity, he can not use them 
>> elsewhere until then.”
> 
> Possibly.
> In a way, this is giving up control of the coin, until he no longer needs the 
> advertisement, i.e. dynamically select the maturity age needed.
> 

My proposal would separate the owner of the funds from the one using the 
advertizement service. Yes, the owner lock up until maturity. But those using 
the UTXO for the advertizement service could transfer (sell) the UTXO to 
someone else as soon as they do not need it, so it is dynamic maturity for them 
The new owner could use them for an other advertizement or for an entirely 
different purpose.

Regarding burning: I think burning is unsustainable as usage of services is 
unlimited while coin suply is limited.

>> 
>> And as I have shown above, nor can a “locked-up” coin be unlocked to do the 
>> same.
> 
> You have shown no such thing, merely shown that you have not understood the 
> proposal.
> 
> Regards,
> ZmnSCPxj

I also struggle to communicate to Eric and likely many other reader the generic 
utility of temporary control of an UTXO. Let me try again:

Bitcoin offers a memory with remarkable properties:
- it can be read by anyone anywhere
- anyone anywhere who knows a key controlling an UTXO, and only them, can 
initiate an update to the memory
- global replicas guaranteed to apply updates of the memory within a short time 
period.

This is a utility that is sufficient to implement money.

Such a reliable shared memory could have however more uses than tracking money, 
It could keep track of, and thereby make scarce, arbitary other things.

We can unlock these uses by separating the money use of memory from other uses.

The covenant achives this separation temporarily. A UTXO with a covenant that 
guarantees that current owner re-gains control at a later time means,
that the current owner temporarily forgoes the UTXOs use as money and thereby 
allows its temporary use to keep track of something else.
UTXOs with different covenants or without covenant are not fungible.

Why use UTXOs of significant value to track something that is not money? 
Because the reason the registry is used is to create scarcity and scarcity can 
be tailored to more or
less severe by requiring more or less satoshis to track something.

The current owner of a regular UTXO will want to be paid for temporarily giving 
up control, and that payment represents interest. Riskless, since it is certain 
to re-gain control.

Regards,

Tamas Blummer







signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Generalized covenants with taproot enable riskless or risky lending, prevent credit inflation through fractional reserve

[Tamas Blummer via bitcoin-dev]

Hi Eric,

there are some other ways to impose cost on use without direct billing, e.g.:

- Burn Bitcoins to use the service, as you mentioned. This could work and would 
benefit remaining Bitcoin owner, but is unsustainable.

- Pay high fees in self dealing transactions. This could work and would benefit 
miner.

- Time lock own Bitcoins. This is forgoing control of an UTXO for a time 
period, which implies opportunity cost. This could be done with CLTV (OP_HODL). 
It damages the current owner but benefits no one. The problem is one might not 
have substantial UTXO to  imply high enough opportunity cost.

- Pay someone else to time lock. This is paying someone to lock an UTXO for a 
time span. Payment and time lock could be combined in the same transaction.

- Transferable borrowed Bitcoin.  This needs the covenant. This benefits those 
who consciously give up control for a time span. Its advantage is that since 
transferable it can be sold if no longer needed, thereby shortening the term of 
the original arrangement. It coul be re-rented for a shorter time period.

Tamas Blummer


> On Jul 4, 2019, at 18:43, Eric Voskuil  wrote:
> 
> Hi ZmnSCPxj,
> 
> Generalizing a bit this appears to be the same with one exception. The amount 
> of encumbered coin is relevant to an external observer. Of course the 
> effective dust limit is the maximum necessary encumbrance otherwise.
> 
> In the case of simple tracking, the market value of the coin is not relevant, 
> all that is required is a valid output. Hence the devolution to 1 sat 
> tracking. In your scenario the objective is to establish a meaningful cost 
> for the output.
> 
> A community of people using this as a sort of hashcash spam protection can 
> raise the amount of encumbered coin (i.e. advertising threshold price) 
> required in that context. The cost of this encumberance includes not only at 
> least one tx fee but market cost of the coin rental.
> 
> At a 1 year advertisement term, 10% APR capital cost, and threshold of 1 
> encumbered coin, the same is achieved by burning .1 coin. In other words the 
> renter (advertiser) has actually paid to the coin owner .1 coin to rent 1 
> coin for one year.
> 
> As with Bitcoin mining, it is the consumed cost that matters in this 
> scenario, (i.e., not the hash rate, or in this case the encumbered coin face 
> value). Why would the advertiser not simply be required to burn .1 coin for 
> the same privilege, just as miners burn energy? Why would it not make more 
> sense to spend that coin in support of the secondary network (e.g. paying for 
> confirmation security), just as with the burning of energy in Bitcoin mining?
> 
> e
> 
>> On Jul 3, 2019, at 23:57, ZmnSCPxj  wrote:
>> 
>> Good morning Eric,
>> 
>> 
 and thanks to you and ZmnSCPxj we now have two additional uses cases for 
 UTXOs that are only temporarily accessible to their current owner.
>>> 
>>> Actually you have a single potentially-valid use case, the one I have 
>>> presented. The others I have shown to be invalid (apart from scamming) and 
>>> no additional information to demonstrate errors in my conclusions have been 
>>> offered.
>> 
>> I presented another use case, that of the "Bitcoin Classified Ads Network".
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-July/017083.html
>> 
>> Advertisements are "backed" by an unspent TXO.
>> In order to limit their local resource consumption, nodes of this network 
>> will preferentially keep advertisements that are backed by higher UTXO 
>> values divided by advertisement size, and drop those with too low UTXO value 
>> divided by advertisement size.
>> 
>> Thus, spammers will either need to rent larger UTXO values for their spam, 
>> paying for the higher rent involved, or fall back to pre-Bitcoin spamming 
>> methods.
>> Thus I think I have presented a use-case that is viable for this and does 
>> not simply devolve to "just burn a 1-satoshi output".
>> 
>> I still do not quite support generalized covenants as the use-case is 
>> already possible on current Bitcoin (and given that with just a little more 
>> transaction introspection this enables Turing-completeness), but the basic 
>> concept of "renting a UTXO of substantial value" appears sound to me.
>> 
>> 
>> Regards,
>> ZmnSCPxj



signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Generalized covenants with taproot enable riskless or risky lending, prevent credit inflation through fractional reserve

[Tamas Blummer via bitcoin-dev]

Hello ZmnSCPxj,

> On Jul 2, 2019, at 12:33, ZmnSCPxj  wrote:
> 
> ‐‐‐ Original Message ‐‐‐
> On Tuesday, July 2, 2019 5:30 PM, Tamas Blummer  > wrote:
> 
>> The advertiser would thereby put the funds of the HODLer on risk of his 
>> misbehavior, which means the HODLer would have to trust the advertizing 
>> service.
> 
> No it would not :)


You are right. I noticed after sending my reply and then I sent two other. I 
apologize for being noisy.

Let me consolidate my thinking, here.

If there is a use for UTXOs with temporary control, then those who want that 
use will pay for it.

A user of a service that requires temporary control UTXOs would need to cover:

1. fees required by the service
2. the opportunity cost of temporary ownership paid to the original holder who 
gave up control.

If the service is operated by an entity billing user then it can use UTXOs of 
minimal value for its operation and practically ignore opportunity interest.
This is the case with theater tickets just and other simple colored coin like 
use of Bitcoin. Also in case of the unchained advertizement, if the service 
bills its user
for its internal re-allocation of an UTXO, then why would it need to use 
significant value temorary control UTXOs? Actually why not use plain UTXOs, to 
start with?

If however the service is a common good, a network without owner and therefore 
not billing on behalf of someone, but wants to protect itself from spam, then 
it is could require temporary access to significant value UTXOs and thereby 
induce opportunity cost to user. Alternatively it could require burning 
ordinary UTXOs. Burning indirectly benefits all HODLer, temporary control 
benefits those who consciously gave up control. I dislike burning as it is 
unsustainable.

If the implementation of temporary use is enforced by consenus such that it is 
transitive, then temporary use could be re-rented or sold to recover 
opportunity cost for no longer needed temporary access, making it useable for 
an other service.

Temporary access UTXOs with covenants allows us to build spam limited public 
services that are not owned by an operator and financially benefit HODLer 
offering them riskless interest.

Tamas Blummer


signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Generalized covenants with taproot enable riskless or risky lending, prevent credit inflation through fractional reserve

[Tamas Blummer via bitcoin-dev]

Hello ZmnSCPxj,

To be more precise, the value of the UTXO is severaly damaged that it is 
governed by rules of a de-facto side chain with different rules.
Therefore its value to those renting it from the advertizer is just that of the 
advertizement, which is not neccesarily following the opportunity cost.

The covenant supported temporary access is transitive, therefore anyone who is 
in temporary control of an UTXO can recover its cost by sub-renting.
The opportunity (riskless) interest provides a baseline of value on top of 
which you may have utility that is the advertizement.

Regards,

Tamas Blummer

> On Jul 2, 2019, at 11:30, Tamas Blummer  wrote:
> 
> Hello ZmnSCPxj,
> 
>> On Jul 2, 2019, at 10:12, ZmnSCPxj  wrote:
>> 
>> As a counterargument, I observe that committing to the advertisement on the 
>> UTXO is similar to committing to a SCRIPT on a UTXO.
>> And I observe the Graftroot idea, wherein we commit to a public key on the 
>> UTXO, and admit a SCRIPT that is signed by the public key as a SCRIPT that 
>> unlocks the UTXO for spending.
>> 
>> By analogy, in my "advertising" scheme, instead of committing the 
>> advertisement on the UTXO, I can instead commit a public key (for example, 
>> the hash of the "advertiser pubkey" is used to tweak the onchain public key).
>> Then we use this advertiser pubkey to admit advertisements on the 
>> advertising network.
>> 
>> This advertiser pubkey is used to sign an "advertisement chain", which is a 
>> merklized singly-linked list whose contents are the actual advertisements, 
>> each node being signed using the advertiser pubkey.
>> To ensure that the advertiser does not sign multiple versions of this chain, 
>> we can have the signing nonce be derived from the height of the advertchain, 
>> such that signing the same height multiple times leads to private key 
>> revelation.
> 
> The advertiser would thereby put the funds of the HODLer on risk of his 
> misbehavior, which means the HODLer would have to trust the advertizing 
> service.
> This is not the trustless separation the covenant achives.
> 
> Regards,
> 
> Tamas Blummer
> 



signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Generalized covenants with taproot enable riskless or risky lending, prevent credit inflation through fractional reserve

[Tamas Blummer via bitcoin-dev]

Hello ZmnSCPxj,

I share your goal to move everything possible off-chain.

The discussion of covenant is not an on/off-chain discussion, but if covenant 
is needed to solve problems we currently can not and which unlock significant 
innovation.

Consensus support of the covenant is only needed if an unchained setup using it 
is closed uncooperatively, otherwise there is not even a reason to disclose 
on-chain that a covenant was used.

Regards,

Tamas Blummer

> On Jul 2, 2019, at 11:30, Tamas Blummer  wrote:
> 
> Hello ZmnSCPxj,
> 
>> On Jul 2, 2019, at 10:12, ZmnSCPxj  wrote:
>> 
>> As a counterargument, I observe that committing to the advertisement on the 
>> UTXO is similar to committing to a SCRIPT on a UTXO.
>> And I observe the Graftroot idea, wherein we commit to a public key on the 
>> UTXO, and admit a SCRIPT that is signed by the public key as a SCRIPT that 
>> unlocks the UTXO for spending.
>> 
>> By analogy, in my "advertising" scheme, instead of committing the 
>> advertisement on the UTXO, I can instead commit a public key (for example, 
>> the hash of the "advertiser pubkey" is used to tweak the onchain public key).
>> Then we use this advertiser pubkey to admit advertisements on the 
>> advertising network.
>> 
>> This advertiser pubkey is used to sign an "advertisement chain", which is a 
>> merklized singly-linked list whose contents are the actual advertisements, 
>> each node being signed using the advertiser pubkey.
>> To ensure that the advertiser does not sign multiple versions of this chain, 
>> we can have the signing nonce be derived from the height of the advertchain, 
>> such that signing the same height multiple times leads to private key 
>> revelation.
> 
> The advertiser would thereby put the funds of the HODLer on risk of his 
> misbehavior, which means the HODLer would have to trust the advertizing 
> service.
> This is not the trustless separation the covenant achives.
> 
> Regards,
> 
> Tamas Blummer
> 



signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Generalized covenants with taproot enable riskless or risky lending, prevent credit inflation through fractional reserve

[Tamas Blummer via bitcoin-dev]

Hello ZmnSCPxj,

> On Jul 2, 2019, at 10:12, ZmnSCPxj  wrote:
> 
> As a counterargument, I observe that committing to the advertisement on the 
> UTXO is similar to committing to a SCRIPT on a UTXO.
> And I observe the Graftroot idea, wherein we commit to a public key on the 
> UTXO, and admit a SCRIPT that is signed by the public key as a SCRIPT that 
> unlocks the UTXO for spending.
> 
> By analogy, in my "advertising" scheme, instead of committing the 
> advertisement on the UTXO, I can instead commit a public key (for example, 
> the hash of the "advertiser pubkey" is used to tweak the onchain public key).
> Then we use this advertiser pubkey to admit advertisements on the advertising 
> network.
> 
> This advertiser pubkey is used to sign an "advertisement chain", which is a 
> merklized singly-linked list whose contents are the actual advertisements, 
> each node being signed using the advertiser pubkey.
> To ensure that the advertiser does not sign multiple versions of this chain, 
> we can have the signing nonce be derived from the height of the advertchain, 
> such that signing the same height multiple times leads to private key 
> revelation.

The advertiser would thereby put the funds of the HODLer on risk of his 
misbehavior, which means the HODLer would have to trust the advertizing service.
This is not the trustless separation the covenant achives.

Regards,

Tamas Blummer



signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Generalized covenants with taproot enable riskless or risky lending, prevent credit inflation through fractional reserve

[Tamas Blummer via bitcoin-dev]

Good morning Eric and ZmnSCPxj,

> On Jul 2, 2019, at 05:45, ZmnSCPxj  wrote:
> 
> Good morning Eric, and Tamas,
> 
>> In the case of tracking an asset that becomes worthless at a specific time, 
>> one could value a record of ownership, and the ability to trade ownership of 
>> the asset during the period. Consider colored coin type tracking of a 
>> theater ticket for a specific show, where the ticket is worthless by the end 
>> of the show.
> 
> As it happens, I was playing around with another idea I am developing.
> And it involves something very much similar, but distinct.
> 
> In particular, currencies are worthless unless exchanged for things of value 
> to existent beings.
> And the discovery of things of value is enabled by advertising.
> The idea I am developing, is that of a "Bitcoin Classified Ads Network", 
> wherein ordinary P2PKH UTXOs (or P2WPKH equivalents) embed a commitment to an 
> advertisement.
> A secondary network of nodes (separate from the Bitcoin network) transmits 
> the actual advertisements, as well as the UTXOs being used to commit to them.
> This secondary network would then reject/purge advertisements once the UTXO 
> is spent on the Bitcoin blockchain.
> This makes advertising costly (for the opportunity cost of locking some money 
> in a UTXO until one has acquired actual paying custom) while reducing impact 
> on Bitcoin blockchain space (commitment to the advertisment is in the same 
> space as the ownership of the coin).
> Changing the advertisement one makes is possible, at the cost of paying for a 
> transaction in the Bitcoin blockchain to spend the old UTXO and publish a new 
> UTXO now committing to the new advertisement.
> 
> Of note is that I also derived that it would be beneficial, for some HODLers 
> to offer their funds for the purpose of making these advertisements.

All above aligns with my intuition that: on one side giving up temporary 
control of UTXOs represent opportunity cost and on the receiver side having 
temporary control can unlock utility they would pay for.
If the techical setup is trustless and return of control to those who gave it 
up temporarilty is certain, then this in combination means that HODLer are able 
to earn riskless interest by giving up control of their UTXOs temporarily.


> Some service or product provider would agree with an advertiser to lock some 
> coins of the advertiser for a limited amount of time, in exchange for payment 
> upfront, with the coin address committing to the indicate advertisement of 
> the service or product provider.
> This can be done by paying to a 2p-ECDSA (or with Schnorr, MuSig) public key, 
> with the service/product provider embedding a commitment to its advertisement 
> to its own key, and a pre-signed `nLockTime` transaction that lets the 
> advertiser recover the money.
> 
> This is in fact a similar use to the "theater ticket" case you mentioned, yet 
> distinct.
> In the case of the Bitcoin Classified Ads Network, it is the intermediate 
> addresses used before reclamation by the advertiser that is valuable, as they 
> also serve as commitments to advertisements, attesting to the (probable) 
> validity of the advertisement and making spam have a cost.
> Given that nodes of the Bitcoin Classified Ads Network will have memory 
> limits, advertisements whose "lockup-rate" (i.e. the amount of value of the 
> backing UTXO, divided by the size of the advertisement) are low could be 
> evicted from memory before advertisements with high lockup-rate, and thus be 
> less likely to propagate across the network.
> Thus service/product providers would want to increase their "marketing 
> budget" to be less likely to be evicted from nodes of the Bitcoin Classified 
> Ads Network, which is beneficial as it increases the minimum practical 
> lockup-rate needed to spam the network, thus making spam costly.
> 
> My current plan is that the provider can contact the advertiser in order to 
> effect changes to their advertisement.
> Then the provider and the advertiser sign a new timelocked reclamation 
> transaction, then sign a transaction moving from the old advertisement to the 
> new advertisement (presumably there is some protocol for ensuring the 
> advertiser gets paid for this, such as an HTLC that can be triggered by an 
> onchain payment or by an LN payment; I have the details in my processing 
> space but require some time to serialize to human-readabe format).
> 
> Arguably, this example seems to show that generalized covenants are not 
> needed in fact, if transfers of coin require paying to the issuer/lender of 
> the coin.
> Generalized covenants allows the provider (or ticket-holder in your example) 
> to effect transfers from one advertisement to another (or one ticket-holder 
> to another in your example) without cooperation with the advertiser (or 
> ticket-issuer in your example).
> This would be otherwise needed if we lock using a 2-of-2 address that has a 
> timelocked transaction to 

Re: [bitcoin-dev] Generalized covenants with taproot enable riskless or risky lending, prevent credit inflation through fractional reserve

[Tamas Blummer via bitcoin-dev]

> On Jul 1, 2019, at 20:52, Eric Voskuil  wrote:
> 
> I said that I would make no further comment given the belief that no new 
> ideas were surfacing. However, after giving it some more thought on my own, I 
> believe I have found the one case in which a person could value such 
> encumbered coins.
> 
> In the case of tracking an asset that becomes worthless at a specific time, 
> one could value a record of ownership, and the ability to trade ownership of 
> the asset during the period. Consider colored coin type tracking of a theater 
> ticket for a specific show, where the ticket is worthless by the end of the 
> show.
> 


In other words you now see the utility of a register offered by UTXOs that are 
only temporary availability to current owner. If there is a utility there is 
also a value in it for them.
I am glad we are on the same side on this utility and thanks to you and 
ZmnSCPxj we now have two additional uses cases for UTXOs that are only 
temporarily accessible to their current owner.

Since ZmnSCPxj also raised the question if covenants are needed at all, let me 
continue my thoughts on this in reply to his mail.

Tamas Blummer

> 
> 
>> On Jun 30, 2019, at 13:26, Tamas Blummer  wrote:
>> 
>> My argument does not need the comparison with ICOs.
>> 
>> They were just an example that people pay for the utility of register even 
>> though others think the tokens they keep track of are worthless.
>> 
>> Tamas Blummer
>> 
>> 
>>> On Jun 30, 2019, at 22:13, Eric Voskuil  wrote:
>>> 
>>> ICO tokens can be traded (indefinitely) for other things of value, so the 
>>> comparison isn’t valid. I think we’ve both made our points clearly, so I’ll 
>>> leave it at that.
>>> 
>>> Best,
>>> Eric
>>> 
 On Jun 30, 2019, at 12:55, Tamas Blummer  wrote:
 
 
> On Jun 30, 2019, at 20:54, Eric Voskuil  wrote:
> 
> Could you please explain the meaning and utility of “unforgeable 
> register” as it pertains to such encumbered coins?
 
 I guess we agree that some way of keeping track of ownership is 
 prerequisite for something to aquire value.
 We likely also agree that the security of that ownership register has 
 great influence to the value.
 
 The question remains if a register as utility in itself gives value to the 
 thing needed to use that register.
 I think it does, if people are interested in what it keeps track of, for 
 whatever reason, even for reasons you find bogus.
 
 It was not intentional, but I think I just explained why Ethereum aquired 
 higher market value by being register of ICO tokens.
 
 Now back to the coins encumbered with the debt covenant:
 Transactions moving them constitute a register of covered debt and you 
 need them to update that register.
 Should some people find such a register useful then those coins needed to 
 update this register will aquire value.
 Does not matter if you think the concept of covered debt is just as bogus 
 as ICOs.
 
 Here some good news: If they aquire value then they offer a way to 
 generate income for hodler by temporarily giving up control.
 
 Tamas Blummer
 
> 
> The meaning in terms of Bitcoin is clear - the “owner” of outputs that 
> represent value (i.e. in the ability to trade them for something else) is 
> recorded publicly and, given Bitcoin security assumptions, cannot be 
> faked. What is not clear is the utility of a record of outputs that 
> cannot be traded for something else. You seem to imply that a record is 
> valuable simply because it’s a record.
> 
> e
> 
>> On Jun 30, 2019, at 11:35, Tamas Blummer  wrote:
>> 
>> 
>>> On Jun 30, 2019, at 19:41, Eric Voskuil  wrote:
>>> 
>>> 
 On Jun 30, 2019, at 03:56, Tamas Blummer  
 wrote:
 
 Hi Eric,
 
> On Jun 29, 2019, at 23:21, Eric Voskuil  wrote:
> 
> What loan? Alice has paid Bob for something of no possible utility to 
> her, or anyone else.
 
 Coins encumbered with the described covenant represent temporary 
 control of a scarce resource.
 
 Can this obtain value? That depends on the availability of final 
 control and ability to deal with temporary control.
>>> 
>>> For something to become property (and therefore have marketable value) 
>>> requires that it be both scarce and useful. Bitcoin is useful only to 
>>> the extent that it can be traded for something else that is useful. 
>>> Above you are only dealing with scarcity, ignoring utility.
>> 
>> There is a deeper utility of Bitcoin than it can be traded for something 
>> else. That utility is to use its unforgeable register.
>> We have only one kind of units in this register and by having covenants 
>> we would create other kinds that are while encumbered not fungible with 

Re: [bitcoin-dev] Generalized covenant to implement side chains embedded into the bitcoin block chain

[Tamas Blummer via bitcoin-dev]

he Bitcoin blockchain.
>>> Instead, the `Transfer` signers simply validate some smart contract, most 
>>> likely embedded as a pay-to-contract in the `pk(Alice)`/`pk(Bob)` public 
>>> keys, and ensure that the smart contract is correctly executed.
>>> In that case, it may be useful to consider Smart Contracts Unchained 
>>> instead: https://zmnscpxj.github.io/bitcoin/unchained.html
>>> 
>>> It would be possible, under Smart Contracts Unchained, to keep the 
>>> `Transfer`-signed transactions offchain, until `Exit`-signing.
>>> Then, when this chain of transaction spends is presented to the 
>>> participants, the participants can be convinced to sign a "cut-through" 
>>> transaction that cuts through the offchain transactions, with the resulting 
>>> cut-through being the one confirmed onchain, and signed only the 
>>> participants, without the `Transfer` or `Exit` federation signatures 
>>> appearing onchain.
>>> This hides not only the smart contract being executed, but also the fact 
>>> that a Smart Contracts Unchained technique was at all used.
>>> 
>>> Regards,
>>> ZmnSCPxj
>>> 
>>> 
>>> Sent with ProtonMail Secure Email.
>>> 
>>> ‐‐‐ Original Message ‐‐‐
>>> On Saturday, June 29, 2019 1:53 PM, Tamas Blummer via bitcoin-dev 
>>>  wrote:
>>> 
>>>> I introduced you to gerneralized covenants[1] earlier, but in a domain 
>>>> specific context that de-routed us from technical discussion. Let me 
>>>> demonstrate the concept in a more generic use:
>>>> 
>>>> A covenant
>>>> 
>>>> or(and(pk(Transfer), _) covenant transitive, and(pk(Exit),_) covenant drop)
>>>> 
>>>> would put a coin under the alternative control of a Transfer and Exit keys 
>>>> together with the script in control of the current owner.
>>>> Additional transaction level validations of transactions spending input 
>>>> with covenants apply as in [1]
>>>> 
>>>> Owner of such coins would be able to transfer them to others provided an 
>>>> addtional Transfer signature, in which case the coin remains encumbered 
>>>> with the same covenant.
>>>> If Exit and owner signs the covenant is dropped on the output, it becomes 
>>>> a plain Bitcoin again.
>>>> 
>>>> The Thransfer and Exit signatures could be threshold signatures of a 
>>>> federation, whereby member decide if the proposed transfer transaction 
>>>> complies with whatever unique rules they impose.
>>>> 
>>>> The result is a federated side chain embedded into the Bitcoin block chain.
>>>> 
>>>> Bob could purchase some asset guarded by the federation with a transaction:
>>>> 
>>>> Inputs
>>>> 100.0001 pk(Bob)
>>>> 
>>>> Outputs
>>>> 0.1 or(and(pk(Transfer), pk(Bob)), and(pk(Exit), pk(Bob)) covenant 
>>>> or(and(pk(Transfer), _) covenant transitive, and(pk(Exit),_) covenant drop)
>>>> 99.9 pk(Transfer)
>>>> 
>>>> Transfer to Alice with consent of the transfer validators:
>>>> 
>>>> Inputs
>>>> 0.1 or(and(pk(Transfer), pk(Bob)), and(pk(Exit), pk(Bob)) covenant 
>>>> or(and(pk(Transfer), _) covenant transitive, and(pk(Exit),_) covenant drop)
>>>> 100.001 pk(Alice)
>>>> 
>>>> Outputs
>>>> 0.1 or(and(pk(Transfer), pk(Alice)), and(pk(Exit), pk(Alice)) covenant 
>>>> or(and(pk(Transfer), _) covenant transitive, and(pk(Exit),_) covenant drop)
>>>> 100 pk(Bob)
>>>> 
>>>> Alice might be approved to exit with the exit signature of the federation:
>>>> 
>>>> Inputs
>>>> 0.1 or(and(pk(Transfer), pk(Alice)), and(pk(Exit), pk(Alice)) covenant 
>>>> or(and(pk(Transfer), _) covenant transitive, and(pk(Exit),_) covenant drop)
>>>> 99.9 pk(Transfer)
>>>> 
>>>> Outputs
>>>> 99. pk(Alice)
>>>> 
>>>> Tamas Blummer
>>>> [1] 
>>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-June/017059.html
>>> 
>>> 
>> 
> 



signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Generalized covenants with taproot enable riskless or risky lending, prevent credit inflation through fractional reserve

[Tamas Blummer via bitcoin-dev]

My argument does not need the comparison with ICOs.

They were just an example that people pay for the utility of register even 
though others think the tokens they keep track of are worthless.

Tamas Blummer


> On Jun 30, 2019, at 22:13, Eric Voskuil  wrote:
> 
> ICO tokens can be traded (indefinitely) for other things of value, so the 
> comparison isn’t valid. I think we’ve both made our points clearly, so I’ll 
> leave it at that.
> 
> Best,
> Eric
> 
>> On Jun 30, 2019, at 12:55, Tamas Blummer  wrote:
>> 
>> 
>>> On Jun 30, 2019, at 20:54, Eric Voskuil  wrote:
>>> 
>>> Could you please explain the meaning and utility of “unforgeable register” 
>>> as it pertains to such encumbered coins?
>> 
>> I guess we agree that some way of keeping track of ownership is prerequisite 
>> for something to aquire value.
>> We likely also agree that the security of that ownership register has great 
>> influence to the value.
>> 
>> The question remains if a register as utility in itself gives value to the 
>> thing needed to use that register.
>> I think it does, if people are interested in what it keeps track of, for 
>> whatever reason, even for reasons you find bogus.
>> 
>> It was not intentional, but I think I just explained why Ethereum aquired 
>> higher market value by being register of ICO tokens.
>> 
>> Now back to the coins encumbered with the debt covenant:
>> Transactions moving them constitute a register of covered debt and you need 
>> them to update that register.
>> Should some people find such a register useful then those coins needed to 
>> update this register will aquire value.
>> Does not matter if you think the concept of covered debt is just as bogus as 
>> ICOs.
>> 
>> Here some good news: If they aquire value then they offer a way to generate 
>> income for hodler by temporarily giving up control.
>> 
>> Tamas Blummer
>> 
>>> 
>>> The meaning in terms of Bitcoin is clear - the “owner” of outputs that 
>>> represent value (i.e. in the ability to trade them for something else) is 
>>> recorded publicly and, given Bitcoin security assumptions, cannot be faked. 
>>> What is not clear is the utility of a record of outputs that cannot be 
>>> traded for something else. You seem to imply that a record is valuable 
>>> simply because it’s a record.
>>> 
>>> e
>>> 
 On Jun 30, 2019, at 11:35, Tamas Blummer  wrote:
 
 
> On Jun 30, 2019, at 19:41, Eric Voskuil  wrote:
> 
> 
>> On Jun 30, 2019, at 03:56, Tamas Blummer  wrote:
>> 
>> Hi Eric,
>> 
>>> On Jun 29, 2019, at 23:21, Eric Voskuil  wrote:
>>> 
>>> What loan? Alice has paid Bob for something of no possible utility to 
>>> her, or anyone else.
>>> 
>> 
>> Coins encumbered with the described covenant represent temporary control 
>> of a scarce resource.
>> 
>> Can this obtain value? That depends on the availability of final control 
>> and ability to deal with temporary control.
> 
> For something to become property (and therefore have marketable value) 
> requires that it be both scarce and useful. Bitcoin is useful only to the 
> extent that it can be traded for something else that is useful. Above you 
> are only dealing with scarcity, ignoring utility.
 
 There is a deeper utility of Bitcoin than it can be traded for something 
 else. That utility is to use its unforgeable register.
 We have only one kind of units in this register and by having covenants we 
 would create other kinds that are while encumbered not fungible with the 
 common ones.
 
 Units are certainly less desirable if encumbered with a debt covenant. You 
 say no one would assign them any value.
 
 I am not that sure as they still offer the utility of using the 
 unforgeable register, in this case a register of debt covered by reserves.
 You also doubt forcing debt to be covered by reserves is a good idea, I 
 got that, but suppose we do not discuss this here.
 If there are people who think it is a good idea, then they would find 
 having an unforgeable register of it useful and therefore units needed to 
 maintain that register valuable to some extent.
 
> 
>> I think you do not show the neccesary respect of the market.
> 
> I’m not sure what is meant here by respect, or how much of it is 
> necessary. I am merely explaining the market.
> 
 
 You are not explaining an existing market but claim that market that is 
 not yet there will follow your arguments.
 
>> Your rant reminds me of renowed economists who still argue final control 
>> Bitcoin can not have value, you do the same proclaiming that temporary 
>> control of Bitcoin can not have value.
> 
> It seems to me you have reversed the meaning of temporary and final. 
> Bitcoin is useful because of the presumption that there is no finality of 
> control. One presumes an ability 

Re: [bitcoin-dev] Generalized covenants with taproot enable riskless or risky lending, prevent credit inflation through fractional reserve

[Tamas Blummer via bitcoin-dev]

> On Jun 30, 2019, at 20:54, Eric Voskuil  wrote:
> 
> Could you please explain the meaning and utility of “unforgeable register” as 
> it pertains to such encumbered coins?

I guess we agree that some way of keeping track of ownership is prerequisite 
for something to aquire value.
We likely also agree that the security of that ownership register has great 
influence to the value.

The question remains if a register as utility in itself gives value to the 
thing needed to use that register.
I think it does, if people are interested in what it keeps track of, for 
whatever reason, even for reasons you find bogus.

It was not intentional, but I think I just explained why Ethereum aquired 
higher market value by being register of ICO tokens.

Now back to the coins encumbered with the debt covenant:
Transactions moving them constitute a register of covered debt and you need 
them to update that register.
Should some people find such a register useful then those coins needed to 
update this register will aquire value.
Does not matter if you think the concept of covered debt is just as bogus as 
ICOs.

Here some good news: If they aquire value then they offer a way to generate 
income for hodler by temporarily giving up control.

Tamas Blummer

> 
> The meaning in terms of Bitcoin is clear - the “owner” of outputs that 
> represent value (i.e. in the ability to trade them for something else) is 
> recorded publicly and, given Bitcoin security assumptions, cannot be faked. 
> What is not clear is the utility of a record of outputs that cannot be traded 
> for something else. You seem to imply that a record is valuable simply 
> because it’s a record.
> 
> e
> 
>> On Jun 30, 2019, at 11:35, Tamas Blummer  wrote:
>> 
>> 
>>> On Jun 30, 2019, at 19:41, Eric Voskuil  wrote:
>>> 
>>> 
 On Jun 30, 2019, at 03:56, Tamas Blummer  wrote:
 
 Hi Eric,
 
> On Jun 29, 2019, at 23:21, Eric Voskuil  wrote:
> 
> What loan? Alice has paid Bob for something of no possible utility to 
> her, or anyone else.
> 
 
 Coins encumbered with the described covenant represent temporary control 
 of a scarce resource.
 
 Can this obtain value? That depends on the availability of final control 
 and ability to deal with temporary control.
>>> 
>>> For something to become property (and therefore have marketable value) 
>>> requires that it be both scarce and useful. Bitcoin is useful only to the 
>>> extent that it can be traded for something else that is useful. Above you 
>>> are only dealing with scarcity, ignoring utility.
>> 
>> There is a deeper utility of Bitcoin than it can be traded for something 
>> else. That utility is to use its unforgeable register.
>> We have only one kind of units in this register and by having covenants we 
>> would create other kinds that are while encumbered not fungible with the 
>> common ones.
>> 
>> Units are certainly less desirable if encumbered with a debt covenant. You 
>> say no one would assign them any value.
>> 
>> I am not that sure as they still offer the utility of using the unforgeable 
>> register, in this case a register of debt covered by reserves.
>> You also doubt forcing debt to be covered by reserves is a good idea, I got 
>> that, but suppose we do not discuss this here.
>> If there are people who think it is a good idea, then they would find having 
>> an unforgeable register of it useful and therefore units needed to maintain 
>> that register valuable to some extent.
>> 
>>> 
 I think you do not show the neccesary respect of the market.
>>> 
>>> I’m not sure what is meant here by respect, or how much of it is necessary. 
>>> I am merely explaining the market.
>>> 
>> 
>> You are not explaining an existing market but claim that market that is not 
>> yet there will follow your arguments.
>> 
 Your rant reminds me of renowed economists who still argue final control 
 Bitcoin can not have value, you do the same proclaiming that temporary 
 control of Bitcoin can not have value.
>>> 
>>> It seems to me you have reversed the meaning of temporary and final. 
>>> Bitcoin is useful because of the presumption that there is no finality of 
>>> control. One presumes an ability to trade control of it for something else. 
>>> This is temporary control. Final control would be the case in which, at 
>>> some point, it can no longer be traded, making it worthless at that point. 
>>> If this is known to be the case it implies that it it worthless at all 
>>> prior points as well.
>>> 
>>> These are distinct scenarios. The fact that temporary (in my usage) control 
>>> implies the possibility of value does not imply that finality of control 
>>> does as well. The fact that (renowned or otherwise) people have made errors 
>>> does not imply that I am making an error. These are both non-sequiturs.
>>> 
 I say, that temporary control does not have value until means dealing with 
 it are offered, and that is I work 

Re: [bitcoin-dev] Generalized covenants with taproot enable riskless or risky lending, prevent credit inflation through fractional reserve

[Tamas Blummer via bitcoin-dev]

> On Jun 30, 2019, at 19:41, Eric Voskuil  wrote:
> 
> 
>> On Jun 30, 2019, at 03:56, Tamas Blummer  wrote:
>> 
>> Hi Eric,
>> 
>>> On Jun 29, 2019, at 23:21, Eric Voskuil  wrote:
>>> 
>>> What loan? Alice has paid Bob for something of no possible utility to her, 
>>> or anyone else.
>>> 
>> 
>> Coins encumbered with the described covenant represent temporary control of 
>> a scarce resource.
>> 
>> Can this obtain value? That depends on the availability of final control and 
>> ability to deal with temporary control.
> 
> For something to become property (and therefore have marketable value) 
> requires that it be both scarce and useful. Bitcoin is useful only to the 
> extent that it can be traded for something else that is useful. Above you are 
> only dealing with scarcity, ignoring utility.

There is a deeper utility of Bitcoin than it can be traded for something else. 
That utility is to use its unforgeable register.
We have only one kind of units in this register and by having covenants we 
would create other kinds that are while encumbered not fungible with the common 
ones.

Units are certainly less desirable if encumbered with a debt covenant. You say 
no one would assign them any value.

I am not that sure as they still offer the utility of using the unforgeable 
register, in this case a register of debt covered by reserves.
You also doubt forcing debt to be covered by reserves is a good idea, I got 
that, but suppose we do not discuss this here.
If there are people who think it is a good idea, then they would find having an 
unforgeable register of it useful and therefore units needed to maintain that 
register valuable to some extent.

> 
>> I think you do not show the neccesary respect of the market.
> 
> I’m not sure what is meant here by respect, or how much of it is necessary. I 
> am merely explaining the market.
> 

You are not explaining an existing market but claim that market that is not yet 
there will follow your arguments.

>> Your rant reminds me of renowed economists who still argue final control 
>> Bitcoin can not have value, you do the same proclaiming that temporary 
>> control of Bitcoin can not have value.
> 
> It seems to me you have reversed the meaning of temporary and final. Bitcoin 
> is useful because of the presumption that there is no finality of control. 
> One presumes an ability to trade control of it for something else. This is 
> temporary control. Final control would be the case in which, at some point, 
> it can no longer be traded, making it worthless at that point. If this is 
> known to be the case it implies that it it worthless at all prior points as 
> well.
> 
> These are distinct scenarios. The fact that temporary (in my usage) control 
> implies the possibility of value does not imply that finality of control does 
> as well. The fact that (renowned or otherwise) people have made errors does 
> not imply that I am making an error. These are both non-sequiturs.
> 
>> I say, that temporary control does not have value until means dealing with 
>> it are offered, and that is I work on. Thereafter might obtain value if 
>> final control is deemed too expensive or not attainable, we shall see.
> 
> The analogy to rental of a consumable good does not apply to the case of a 
> non-consumable good. If it cannot be traded and cannot be consumed it cannot 
> obtain marketable value. To this point it matters not whether it exists.
> 

I meant with control the control of entries in the register which I think is 
the deeper utility of Bitcoin. Final control is meant to be the opposite of 
temporary which is the time limited control with some expiry.

Thank you for your thoughts as they help to sharpen my arguments.

Best,

Tamas Blummer

> Best,
> Eric
> 
>> Tamas Blummer
>> 
>> 



signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Generalized covenant to implement side chains embedded into the bitcoin block chain

[Tamas Blummer via bitcoin-dev]

I made an error proposing the new covenant. It should be unchanged as in the 
original example:

‘covenant or(and(_, pk(Transfer)) covenant transitive, and(pk(Exit), _) 
covenant drop)’

since the placeholder stays for the control of the rightful owner without 
transfer signature on or off chain.

The exit could be alternatively automatic allowing to exit a stalling unchained 
platform:

‘covenant or(and(_, pk(Transfer)) covenant transitive, and(delay(100), _) 
covenant drop)’

There remains the question why the rightful owner is not enforcing the covenant 
instead of having it enforced by on-chain consensus.

I do not yet have a good answer for that as in contrast to the debt example, 
here it is aligned with the interest of the current owner to have the covenant.

Tamas Blummer

> On Jun 30, 2019, at 18:57, Tamas Blummer  wrote:
> 
> Hello ZmnSCPxj,
> 
> Yes, representation of debt is more interesting here as it requires the 
> covenant, wheras this example, as you point out, was less convincing given 
> alternatives.
> I created this example to avoid discussion of topics not approriate on this 
> list.
> 
> Thank you for the suggestion of unchained execution of transfers with 
> cut-through exit transaction as this made the example much stronger:
> 
> The most important question for someone who trusts his coins to some 
> unchained platform is probably the question of how exit is guaranteed if one 
> is unhappy with what one gets.
> 
> With the exit covenant exit conditions are set in stone, since validated 
> on-chain. If the exit key is owned by a trusted arbiter other than the 
> federation governing the unchained platform
> then one at least have the option to cut losses at some point by presenting 
> the arbiter a chain of valid transactions and asking to sign the exit.
> 
> Participants in the unchained platform would also be interested to regularly 
> snapshot the economic effect of offchain transactions with cut-through 
> transactions as such cut-through shortens the chain of transactions
> they would need to get on chain if chosing the exit without consent of the 
> federation governing the transfers.
> 
> So the convenant needed is: 'covenant or(_ covenant transitive, and(pkExit, 
> _) covenant drop)' which gives unrestricted flexibility to the unchained 
> platform with the exception that it has to maintain the exit option.
> 
> 
> Tamas Blummer
> 
> 
>> On Jun 29, 2019, at 22:25, ZmnSCPxj  wrote:
>> 
>> Good morning Tamas,
>> 
>> While I think covenants for some kind of debt tool is mildly interesting and 
>> an appropriate solution, I wonder about this particular use-case.
>> 
>> It seems to me that, as either the `Transfer` signers or `Exit` signers are 
>> always involved, that the `Transfer` signers can be constrained so as to 
>> ensure that the rules are followed correctly, without requiring that 
>> covenants be used on the Bitcoin layer.
>> After all, the outputs of each transaction signed by the `Transfer` signers 
>> are part of the transaction that is being signed; surely the `Transfer` 
>> signers can validate that the output matches the contract expected, without 
>> requiring that fullnodes also validate this?
>> 
>> In particular, it seems to me that covenants are only useful if there exist 
>> some alternative that does not involve some kind of fixed `Transfer` signer 
>> set, but still requires a covenant.
>> Otherwise, the `Transfer` signer set could simply impose the rules by 
>> themselves.
>> 
>> 
>> Another thing is that, if my understanding is correct, the "sidechain" here 
>> is not in fact a sidechain; the "sidechain" transaction graph is published 
>> on the Bitcoin blockchain.
>> Instead, the `Transfer` signers simply validate some smart contract, most 
>> likely embedded as a pay-to-contract in the `pk(Alice)`/`pk(Bob)` public 
>> keys, and ensure that the smart contract is correctly executed.
>> In that case, it may be useful to consider Smart Contracts Unchained 
>> instead: https://zmnscpxj.github.io/bitcoin/unchained.html
>> 
>> It would be possible, under Smart Contracts Unchained, to keep the 
>> `Transfer`-signed transactions offchain, until `Exit`-signing.
>> Then, when this chain of transaction spends is presented to the 
>> participants, the participants can be convinced to sign a "cut-through" 
>> transaction that cuts through the offchain transactions, with the resulting 
>> cut-through being the one confirmed onchain, and signed only the 
>> participants, without the `Transfer` or `Exit` federation signatures 
>> appearing onchain.
>> This hides not only the

Re: [bitcoin-dev] Generalized covenant to implement side chains embedded into the bitcoin block chain

[Tamas Blummer via bitcoin-dev]

Hello ZmnSCPxj,

Yes, representation of debt is more interesting here as it requires the 
covenant, wheras this example, as you point out, was less convincing given 
alternatives.
I created this example to avoid discussion of topics not approriate on this 
list.

Thank you for the suggestion of unchained execution of transfers with 
cut-through exit transaction as this made the example much stronger:

The most important question for someone who trusts his coins to some unchained 
platform is probably the question of how exit is guaranteed if one is unhappy 
with what one gets.

With the exit covenant exit conditions are set in stone, since validated 
on-chain. If the exit key is owned by a trusted arbiter other than the 
federation governing the unchained platform
then one at least have the option to cut losses at some point by presenting the 
arbiter a chain of valid transactions and asking to sign the exit.

Participants in the unchained platform would also be interested to regularly 
snapshot the economic effect of offchain transactions with cut-through 
transactions as such cut-through shortens the chain of transactions
they would need to get on chain if chosing the exit without consent of the 
federation governing the transfers.

So the convenant needed is: 'covenant or(_ covenant transitive, and(pkExit, _) 
covenant drop)' which gives unrestricted flexibility to the unchained platform 
with the exception that it has to maintain the exit option.


Tamas Blummer


> On Jun 29, 2019, at 22:25, ZmnSCPxj  wrote:
> 
> Good morning Tamas,
> 
> While I think covenants for some kind of debt tool is mildly interesting and 
> an appropriate solution, I wonder about this particular use-case.
> 
> It seems to me that, as either the `Transfer` signers or `Exit` signers are 
> always involved, that the `Transfer` signers can be constrained so as to 
> ensure that the rules are followed correctly, without requiring that 
> covenants be used on the Bitcoin layer.
> After all, the outputs of each transaction signed by the `Transfer` signers 
> are part of the transaction that is being signed; surely the `Transfer` 
> signers can validate that the output matches the contract expected, without 
> requiring that fullnodes also validate this?
> 
> In particular, it seems to me that covenants are only useful if there exist 
> some alternative that does not involve some kind of fixed `Transfer` signer 
> set, but still requires a covenant.
> Otherwise, the `Transfer` signer set could simply impose the rules by 
> themselves.
> 
> 
> Another thing is that, if my understanding is correct, the "sidechain" here 
> is not in fact a sidechain; the "sidechain" transaction graph is published on 
> the Bitcoin blockchain.
> Instead, the `Transfer` signers simply validate some smart contract, most 
> likely embedded as a pay-to-contract in the `pk(Alice)`/`pk(Bob)` public 
> keys, and ensure that the smart contract is correctly executed.
> In that case, it may be useful to consider Smart Contracts Unchained instead: 
> https://zmnscpxj.github.io/bitcoin/unchained.html
> 
> It would be possible, under Smart Contracts Unchained, to keep the 
> `Transfer`-signed transactions offchain, until `Exit`-signing.
> Then, when this chain of transaction spends is presented to the participants, 
> the participants can be convinced to sign a "cut-through" transaction that 
> cuts through the offchain transactions, with the resulting cut-through being 
> the one confirmed onchain, and signed only the participants, without the 
> `Transfer` or `Exit` federation signatures appearing onchain.
> This hides not only the smart contract being executed, but also the fact that 
> a Smart Contracts Unchained technique was at all used.
> 
> Regards,
> ZmnSCPxj
> 
> 
> Sent with ProtonMail Secure Email.
> 
> ‐‐‐ Original Message ‐‐‐
> On Saturday, June 29, 2019 1:53 PM, Tamas Blummer via bitcoin-dev 
>  wrote:
> 
>> I introduced you to gerneralized covenants[1] earlier, but in a domain 
>> specific context that de-routed us from technical discussion. Let me 
>> demonstrate the concept in a more generic use:
>> 
>> A covenant
>> 
>> or(and(pk(Transfer), _) covenant transitive, and(pk(Exit),_) covenant drop)
>> 
>> would put a coin under the alternative control of a Transfer and Exit keys 
>> together with the script in control of the current owner.
>> Additional transaction level validations of transactions spending input with 
>> covenants apply as in [1]
>> 
>> Owner of such coins would be able to transfer them to others provided an 
>> addtional Transfer signature, in which case the coin remains encumbered with 
>> the same covenant.
>> If Exit and own

Re: [bitcoin-dev] Generalized covenants with taproot enable riskless or risky lending, prevent credit inflation through fractional reserve

[Tamas Blummer via bitcoin-dev]

Hi Eric,

> On Jun 29, 2019, at 23:21, Eric Voskuil  wrote:
> 
> What loan? Alice has paid Bob for something of no possible utility to her, or 
> anyone else.
> 

Coins encumbered with the described covenant represent temporary control of a 
scarce resource.

Can this obtain value? That depends on the availability of final control and 
ability to deal with temporary control.

An example where final control is not available are areas and jurisdictions 
where land can not be bought only long time rents are offered.
People pay high prices there to step in place of the renter in an existing long 
term rent contract and they figured out the contracts that work under these 
restrictions.

Bitcoin’s predominant use is already store of value. Many assume not only 
wealth preservation but that it would allow to purchase of more goods in the 
future than now.
This leads to unwillingnes to give up final control, which can resolve in two 
ways:

- Increasing fiat prices for final control. We see this, and is actually 
further reinforcing unwillingnes to give up final control.
- dealing with temporary control. We do not yet have the technical means of 
even representing this. Developing them is my goal.

I think you do not show the neccesary respect of the market.

Your rant reminds me of renowed economists who still argue final control 
Bitcoin can not have value, you do the same proclaiming that temporary control 
of Bitcoin can not have value.

I say, that temporary control does not have value until means dealing with it 
are offered, and that is I work on. Thereafter might obtain value if final 
control is deemed too expensive or not attainable, we shall see.

Tamas Blummer




signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Generalized covenant to implement side chains embedded into the bitcoin block chain

[Tamas Blummer via bitcoin-dev]

I introduced you to gerneralized covenants[1] earlier, but in a domain specific 
context that de-routed us from technical discussion. Let me demonstrate the 
concept in a more generic use:

A covenant

or(and(pk(Transfer), _) covenant transitive, and(pk(Exit),_) covenant drop)

would put a coin under the alternative control of a Transfer and Exit keys 
together with the script in control of the current owner.
Additional transaction level validations of transactions spending input with 
covenants apply as in [1]

Owner of such coins would be able to transfer them to others provided an 
addtional Transfer signature, in which case the coin remains encumbered with 
the same covenant.
If Exit and owner signs the covenant is dropped on the output, it becomes a 
plain Bitcoin again.

The Thransfer and Exit signatures could be threshold signatures of a 
federation, whereby member decide if the proposed transfer transaction complies 
with whatever unique rules they impose.

The result is a federated side chain embedded into the Bitcoin block chain.

Bob could purchase some asset guarded by the federation with a transaction:

Inputs
100.0001 pk(Bob)

Outputs
0.1 or(and(pk(Transfer), pk(Bob)), and(pk(Exit), pk(Bob)) covenant 
or(and(pk(Transfer), _) covenant transitive, and(pk(Exit),_) covenant drop)
99.9 pk(Transfer)

Transfer to Alice with consent of the transfer validators:

Inputs
0.1 or(and(pk(Transfer), pk(Bob)), and(pk(Exit), pk(Bob)) covenant 
or(and(pk(Transfer), _) covenant transitive, and(pk(Exit),_) covenant drop)
100.001 pk(Alice)

Outputs
0.1 or(and(pk(Transfer), pk(Alice)), and(pk(Exit), pk(Alice)) covenant 
or(and(pk(Transfer), _) covenant transitive, and(pk(Exit),_) covenant drop)
100 pk(Bob)

Alice might be approved to exit with the exit signature of the federation:

Inputs
0.1 or(and(pk(Transfer), pk(Alice)), and(pk(Exit), pk(Alice)) covenant 
or(and(pk(Transfer), _) covenant transitive, and(pk(Exit),_) covenant drop)
99.9 pk(Transfer)

Outputs
99. pk(Alice)

Tamas Blummer
[1] 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-June/017059.html 



signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Generalized covenants with taproot enable riskless or risky lending, prevent credit inflation through fractional reserve

[Tamas Blummer via bitcoin-dev]

Hi Eric,

Thank you for your questions as they show what concepts need further 
explanation, so you understand the potential of this proposal and how it is 
helpful to the ecosystem.

Riskless zero bond is in fact the most basic concept of financial engineering. 
Yes, there are engineers of finance, those who create and price financial 
derivatives (e.g. options, swaps) and structure products such as e.g. ABS, CDO 
etc.
I used to be one of them.

A zero bond formalizes the observation that 1 unit of currency in the future 
has different value than 1 unit available now. It is called riskless if it is 
certain to receive the payment in the future.
If we put this difference of vaue in relation to the amount then we get the 
“risk freee rate of return”, that you heard of.

E.g if one is willing to exchange 1 BTC unconditionally available now for 1.1 
BTC certainly available in a year but not earlier, then the implied “risk free 
rate of return” is apparently 10% pa. for Bitcoins.

The transaction I construct in the first example achives exactly this, because:

Bob forgoes his ability to use his unconditionally available coins by giving 
them to Alice with a covenant that ensures that Bob will receive them back 
later.
Bob does this because Alice pays for this in advance.

Alice can further transfer the coins encumbered by the covenant, but they will 
unconditionally return to Bob in the future.

The utility of these encumbered coins is that they prove that the loan is fully 
covered by reserves.

How valuable this utility is will be decided by the market and that value will 
be interest received by those who temporarily give up control. I am guess the 
value will be low but positive.

Lending does not mandate fractional or full reserves. These are choices the 
market or regulators enforce. Full reserve banking is not a fiction but is how 
things worked before introduction of gold receipts. A bank could only lend gold 
coins it possesed. Perils of fractional reserve were felt repeatedly by the 
Bitcoin ecnomy e.g. in the collaps of MtGox.

The idea to return to full reserve banking is not unique to gold bugs or 
Bitcoin but recently a popular vote was initiated in Switzerland to force Swiss 
banks to full reserves with respect to lending. This popular vote achived  24% 
support [1] which is quite remarkable if considered that the topic is not 
trivial as also our exchange shows.

I published today a writing in medium, that explains the concept of fractional 
vs. full reserve banking in conjunction with this proposal. Please read: 
https://medium.com/@tamas.blummer/full-reserve-banking-with-bitcoin-462b21ae9479
 
<https://medium.com/@tamas.blummer/full-reserve-banking-with-bitcoin-462b21ae9479>

I would welcome feedback on the generalized covenant construct or its 
implementation, as I think it can open up much more uses than the few examples 
I gave.

Tamas Blummer

[1] Vollgeld Initiative: 
https://www.bfs.admin.ch/bfs/de/home/statistiken/politik/abstimmungen/jahr-2018/2018-06-10/vollgeld-initiative.html
 
<https://www.bfs.admin.ch/bfs/de/home/statistiken/politik/abstimmungen/jahr-2018/2018-06-10/vollgeld-initiative.html>
> On Jun 28, 2019, at 19:25, Eric Voskuil  wrote:
> 
> Hi Tamas,
> 
> There are a number of economic assumptions contained herein. While I 
> understand you would like to focus on implementation, the worst bugs are 
> requirements bugs. IMO these should be addressed first. I’ve addressed some 
> possible issues inline.
> 
>> On Jun 28, 2019, at 01:27, Tamas Blummer via bitcoin-dev 
>> > <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>> 
>> I start with a formalisation of loans as common in finance:
>> 
>> A zero bond is a contract between two parties Alice and Bob whereby Alice 
>> receives an amount less than P and has to pay back P at a later time point 
>> called maturity.
>> The difference between the amount received and P is the interest implied by 
>> the contract. E.g. receiving 1 Bitcoin (> in a year is the same as getting a loan with 10% p.a. interest.
>> 
>> The inherent risk in the contract is that Alice may not honor the agreement 
>> or be bankrupt by then.
>> 
>> If we could programmatically guarantee that Alice honors the contract then 
>> we would be able to create a riskless zero bond, the fundation of financial 
>> engineering.
> 
> I’m not aware of the basis of this statement. While people use the term “risk 
> free rate of return” there has never actually been such a thing. It’s not 
> clear to me how a unicorn has been the foundation of “financial engineering”, 
> but I’m not also clear and what is intended by “engineering” in this sense. 
> Generally engineering is the implementation of higher level concepts. It is 
> those concepts that constitute requirements here.
> 
> At a m

[bitcoin-dev] Generalized covenants with taproot enable riskless or risky lending, prevent credit inflation through fractional reserve

[Tamas Blummer via bitcoin-dev]

I start with a formalisation of loans as common in finance:

A zero bond is a contract between two parties Alice and Bob whereby Alice 
receives an amount less than P and has to pay back P at a later time point 
called maturity.
The difference between the amount received and P is the interest implied by the 
contract. E.g. receiving 1 Bitcoin (http://bitcoin.sipa.be/miniscript/): 
'and(time(100),pk(C))' where C is Bob’s key and 100 is maturity

This requires a generalization of the Bitcoin Covenants Idea[1] such that it 
nicely fits with taproot as follows:

1. A covenant in the form of '_ covenant C’ on output means that it can be 
spent to an output that maches the covenant pattern with placeholder _  and the 
output(s) will be assigned 'covenant C'.
2. A covenant that mandates an output script with alternate validation paths 
can also assign alternate covernants to be inherited by the output(s) depending 
on which path was used to spend the input eg. 'covenant or(c covenant C, d 
covernant D)’
3. The resulting covenant of outputs should be reduced following boolean 
algebra, e.g. or(b,or(b,a)) to or(b, a)
4. express transitivity with 'covenant transitive’ which means the output will 
have the same covenant as the input
5. allow to omit covenant on the output with 'covenant drop'

The covenant Bob would assign to the loan output sent to Alice is: 'covenant 
or(and(time(100),pk(Bob)) covenant drop, _ covenant transitive)' which means:
- Alice can send to an output script where she is free to chose the embedded 
script at the placeholder _ and that output will again have the same covenant 
as the input.
- After maturity Bob can claim any coin that is transitively rooted in the loan 
(more on this later) and the covenant will no longer be assigned to his new 
output(s).

Assuming Alice wants to send some of the borrowed coins to Charlie:

for shorter notation lets use b='and(time(100),pk(Bob)) covenant drop’ for the 
script that gives Bob control after maturity.

Alice can not send to pk(Charlie), but she can send to or(b, pk(Charlie) 
covenant transitive)
Sending to pk(Charlie) would be sending cash, sending to or(b, pk(Charlie) 
covenant transitive) is a promissory note issued by Alice to Charlie, here is 
why:

If Charlie accepts an or(b, pk(Charlie) covenant transitive) output then he 
trusts, that Alice will offer a regular payment in exchange for it before 
maturity, since that output is worthless to Charlie after maturity as Bob can 
just take it.

It seems at the first sight that there is no value in these outputs for 
Charlie, since he still has to ensure Alice replaces them before maturity.

The value of these outputs to Charlie is the proof that he has exclusive 
control of the coins until maturity.
Alice can not issue promissory notes in excess of own capital or capital that 
she was able to borrow. No coin inflation or fractional reserve here, which 
also reduces the credit risk Charlie takes.

Due to the transitive covenant Charlie could pass on the coins to an other 
temporary owner until maturity when Bob would re-collect them unconditionally.

Should Charlie no longer be comfortable with Alice’s promise or need final 
coins (cash) immediatelly, then he could turn to Dan and do a re-purchase 
(repo) agreement with him.

Charlie would receive final coins from Dan in exchange for the temporarily 
controled coins and Charlie's promise to replace them with final coins before 
maturity.
Dan would thereby charge high interest through a discount since as he has to 
bear the credit risk of Charlie. This is not a riskless but a plain zero bond.

Why would Dan want to take temporary control of the coins at all? Again, to 
ensure Charlie is not doing yet another repo with Frank on the same coins, the 
sum of Charlie's repo deals are not in excess of his claims against others.
This again avoids lending in excess of coin supply and reduces the credit risk 
Dan takes.

Here are the sketches for the transacions for above alternate actions:

lets use shortcut c for 'or(and(time(100),pk(Bob)) covenant drop, _ covenant 
transitive)’

the transactions offer a fee of 0.0001

Bob gives a riskless credit to Alice:

Input   Output
1 pk(Bob)   1 or(b,pk(Alice) covenant c)
0.1 pk(Alice)   0. pk(Bob)

Alice could send a 0.5 promissory note to Charlie:

Input   Output
1 or(pk(Alice) covenant c)  0.5 or(b,pk(Charlie) covenant c)
1 pk(Alice) 0.5 or(b,pk(Alice) covenant c)
0. pk(Alice)

Alice could make good of the note before maturity, pay some interest and get 
back temporary control of the coins with:
Input   Output
0.5 or(b,pk(Charlie) covenant c)0.5 or(b,pk(Alice) covenant c)
0.5101 pk(Alice)0.51 pk(Charlie)

alternatively Charlie borrows from Dan at high interest:

Input 

Re: [bitcoin-dev] An alternative: OP_CAT & OP_CHECKSIGFROMSTACK

[Tamas Blummer via bitcoin-dev]

ZmnSCPxj already observed in [1] that these ops would enable introspection of 
any field of the transactions and make both `OP_CHECKLOCKTIMEVERIFY` and 
`OP_CHECKSEQUENCEVERIFY` superfluous.
There is much more to this as enumerated in generic terms by Russel O’Connor 
below and I would like to add a concrete example.

We could implement oracle less difficulty contracts without the need the of a 
CISC type OP_WORKVERIFY but instead through resurrection/extension of OP_CAT, 
OP_GREATERTHANOREQUAL and introduction of a new RISC opcode 
OP_CHECKBLOCKATHEIGHT[3] suggested by Luke Dashjr. Thanks for the pointer to 
Nathan Cook [4]

Technically we could resurrect and add them without burning more than one 
OP_NOP by redefining it as a prefix (OP_EXTENSION), such as:

OP_EXTENSION OP_CAT would become a two byte opcode pointing to a resurrected 
implementation of OP_CAT.

This could be soft forked in.

A concrete oracle less difficulty contract could look like:
It is an european digital call option on target difficulty after maturity and 
10 blocks notice period. I gave you reasons while having these would increase 
bitcoin's security in [2]

IF
 CHECKLOCKTIMEVERIFY DROP
   CHECKSIGVERIFY
ELSE
OP_DUP   OP_CHECKBLOCKATHEIGHT 
OP_LESSTHANEQUAL OP_VERIFY
OP_SWAP OP_CAT  OP_CAT  OP_HASH256  OP_LESSTHANEQUAL 
OP_VERIFY
 CHECKSIGVERIFY
ENDIF

insurance premium could be collected by the seller of the insurance after 
maturity + 10 blocks if target difficulty was not reached



miner would get back its insurance premium plus collateral of the seller if 
target difficulty was not reached at maturity. Miner has 10 blocks time after 
maturity to claim with:

  

The stack would be in second case processed as:

1: after pushes




2: after OP_DUP:





3: after push






4: after OP_CHECKBLOCKATHEIGHT OP_VERIFY is successful proving that prevhash is 
the block at maturity block height - 1




5: after OP_SWAP




6: after OP_CAT



7: after OP_CAT


8: after OP_HASH256


9: after push



10: after OP_GREATERTHANOREQUAL OP_VERIFY proves that contracted target was 
reached

Tamas Blummer


[1] 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016966.html 

[2] 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-June/017019.html 

[3] https://github.com/luke-jr/bips/blob/bip-cbah/bip-cbah.mediawiki 

[4] 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016954.html 

[5] https://github.com/bitcoin/bitcoin/blob/master/src/script/script.h 

> On May 22, 2019, at 23:01, Russell O'Connor via bitcoin-dev 
>  wrote:
> 
> Recently there have been some tapscript proposals, SIGHASH_ANYPREVOUT and 
> OP_CHECKOUTPUTHASHVERIFY, that aim to enable particular new features for 
> Bitcoin via new Script operations.  However, I think that these proposals 
> miss the mark when it comes to how they approach Bitcoin Script and language 
> features.
> 
> Bitcoin Script appears designed to be a flexible programmable system that 
> provides generic features to be composed to achieve various purposes.  Thus, 
> when we design new language features for Script, we should be striving, as 
> much as possible, to similarly build general purpose tools which can in turn 
> be used for a variety of purposes.
> 
> I feel the SIGHASH_ANYPREVOUT and OP_CHECKOUTPUTHASHVERIFY proposals fail to 
> achieve these design goals.  They are both are designed with very narrow 
> applications in mind, while also going out of their way to extend the 
> semantic domain of the interpretation of Bitcoin operations in new ways that 
> complicate their specification.  In the case of SIGHASH_ANYPREVOUT, the 
> semantic domain is extended by adding new counters to track the use of 
> various v0 and v2 signature types.  In the case of OP_CHECKOUTPUTHASHVERIFY, 
> it employs a new context-sensitive operation that peeks at the value of 
> surrounding opcodes.
> 
> Instead, I propose that, for the time being, we simply implement OP_CAT and 
> OP_CHECKSIGFROMSTACKVERIFY.  OP_CAT pops two byte arrays off the stack and 
> pushes their concatenation back onto the stack.  OP_CHECKSIGFROMSTACKVERIFY 
> pops a signature, message, and pubkey off the stack and performs a 
> bip-schnorr verification on the SHA256 hash of the message.
> 
> In concert, these two operations enable:
> 
> * Oracle signature verification, including discrete log contracts.
> * Amortized secure multiparty computations (see "Amortizing Secure 
> Computation with Penalties" by Kumaresan and Bentov).
> * Transaction introspection including:
> + <> Simulated SIGHASH_ANYPREVOUT, which 

[bitcoin-dev] WORKVERIFY: uncensorable contracts hedging biggest risk of mining without 3rd party or oracle

[Tamas Blummer via bitcoin-dev]

In an earlier post [1] I suggested an approach to create native Bitcoin 
contracts that reduce mining's income volatility and received very helpful 
comments on implementation from Pieter Wuille [2] and Natanael [3]

After processing those comments I instead suggest the following restricted 
interpretation of nSequence and a new opcode WORKVERIFY that in combination is 
easier to implement and reason about as it follows the implementation pattern 
of CHECKSEQUENCEVERIFY[5]

Accumulated work on the blockchain is strictly increasing, therefore 
transaction eligibility rule with a >= condition on it would need no 
re-evaluation for descendant blocks, in mempool or at re-org, since additional 
blocks or re-org can only increase the accumulated work. Accumulated work is 
just like time, it is actually an alternate measure of time through 
computation[6], therefore analogous to MTP based restriction implemented with 
BIP68 [4].

=== (the implementation proposal) ===

(needs soft fork for two reasons, activation logic tbd.)

I. Stricter interpretation of nSequence to optionally refer accumulated work:

Only if bit 31 AND bit 30 is set in nSequence can the transaction be included 
into any block. This is a restricting a rule of BIP68 [4] that only required 
bit 31 to be set for unrestricted inclusion into blocks. Otherwise nSequence 
refers to accumulated work (see encoding later) and it is only viable to 
include the transaction into a block if the block has >= work accumulated. This 
would define the meaning of one additional bit in nSequence, but leave all 
other freedom of later improvement left by BIP68.

II. New WORKVERIFY opcode redefining a NOPx in transaction script as:

Terminate script with false for any reason described in BIP112 or if bit 31 is 
set but bit 30 is not set and 256 bit unsigned integer on stack is higher than 
(nSequence &0x)>> 6 * 2^((nSequence & 0x3f) + 84)

=== (end proposal) ===

Notes on the work encoding:

Total accumulated work as of now is > 2^90 and if we assume that mining 
capacity keeps increasing with Moore’s law (double every year) for the next 50 
years, then it could sum up to 2^140. We have much less bits available in 
nSequence therefore we have to encode accumulated work in a floating point 
number with sufficient precision.

The work accumulated during the current difficulty adjustment cycle is > 2016 * 
2^74 which is > 2^84. It is rather unlikely that accumulated work in a 
difficulty adjustment period drops below 2^80 ever again in future which means 
we need not be more precise than  2^80/2^90 or 2^-10 to allow for contracts 
that reference increment until the next adjustment. Therefore a mantissa of 10 
bits should be sufficient. Using 6 bits of exponent and an offset of 2^84 we 
can express the range of [2^84, 2^148) that should be sufficient now and for 
foreseeable future. Please let me know if the approach is not optimal or future 
proof in your opinion.

Why, should we build this into Bitcoin ?

The most influential risk factor in miners' investment decision is the 
anticipated change of difficulty over the time horizon of the mining 
equipment's expected lifetime. Their investments secure the network. The 
ability to create contracts that reduce income volatility would lead to 
additional investment into mining.

A native Bitcoin contract is far superior to alternatives that could be offered 
on traditional markets as:

a native Bitcoin contract would be:
- uncensorable: It requires only the agreement to terms between those 
financially involved
- fully collaterized: no counterparty risk which means Miner could buy hedging 
contracts from any unkown and un-trusted actor that is able to commit collateral
- no oracle is needed
- no disagreement on the settlement
- publicly observable: allow to observe market opinion on future difficulty
- the length of the contract could match miner's investment horizon extending 
over several difficulty adjustments.

Why not on a side-chain ?

Work is fundamental and intrinsic to the base layer. A contract that reduces 
earnings volatility helps to attract more capital for mining and therefore 
increase security on the base layer.

How would this be used?

Miner and Speculator sign a transaction that has an nLockTime of S in the 
future. This gives both parties the option to alternatively spend committed 
output in case the other would not follow through and publish committing the 
collateral until S.

Speculators contribution to collateral is higher than that of the Miner. 
Miner’s collateral is the premium for the insurance provided by Speculator.

The single output of the transaction has following script:

IF
 CHECKLOCKTIMEVERIFY DROP
 CHECKSIGVERIFY
ELSE
 WORKVERIFY DROP
 CHECKSIGVERIFY
ENDIF

This allows the speculator to take back its collateral plus the option premium 
after the maturity time point, which would however only be possible if it was 
not taken earlier by Miner as 

Re: [bitcoin-dev] OP_DIFFICULTY to enable difficulty hedges (bets) without an oracle and 3rd party.

[Tamas Blummer via bitcoin-dev]

yes, log2work is already computed and would be a strictly increasing value, 
like time. Thank you for this suggestion. I think attempting an implementation 
will give further clues it this more suitable to express the same.

Tamas Blummer

> On May 24, 2019, at 10:36, Natanael  wrote:
> 
> On Thu, May 23, 2019 at 9:58 PM Pieter Wuille via bitcoin-dev 
>  > wrote:
> If the difficulty can be directly observed by the script language, you
> would need to re-evaluate all scripts in unconfirmed transactions
> whenever the difficulty changes. This complicates implementation of
> mempools, but it also makes reasoning about validity of (chains of)
> unconfirmed transactions harder, as an unconfirmed predecessor may
> have conditions that change over time.
> 
> To deal with potentially wildly varying difficulty, could the value exposed 
> be the sum of accumulated PoW, or in other words the sum of each block's 
> difficulty value in the entire chain? This should be a value that will only 
> rise unless a reorg happens after a difficulty drop happens (only likely to 
> be the result of users manually blacklisting an otherwise valid block that is 
> several blocks back in the chain).
> 
> This mimics the effect of the block number which only grows. So if you're 
> starting at time A with difficulty X, then you'd estimate what you think the 
> accumulated PoW ought to be at time B with expected difficulty Y (as compared 
> to the current value at time A), and put that value into the script.



signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] OP_DIFFICULTY to enable difficulty hedges (bets) without an oracle and 3rd party.

[Tamas Blummer via bitcoin-dev]

> On May 23, 2019, at 21:45, Pieter Wuille  wrote:
> 
> On Thu, 23 May 2019 at 11:33, Tamas Blummer via bitcoin-dev
>  wrote:
>> 
>> Difficulty change has profound impact on miner’s production thereby 
>> introduce the biggest risk while considering an investment.
>> Commodity markets offer futures and options to hedge risks on traditional 
>> trading venues. Some might soon list difficulty futures.
>> 
>> I think we could do much better than them natively within Bitcoin.
>> 
>> A better solution could be a transaction that uses nLocktime denominated in 
>> block height, such that it is valid after the difficulty adjusted block in 
>> the future.
>> A new OP_DIFFICULTY opcode would put onto stack the value of difficulty for 
>> the block the transaction is included into.
>> The output script may then decide comparing that value with a strike which 
>> key can spend it.
>> The input of the transaction would be a multi-sig escrow of those who 
>> entered the bet.
>> The winner would broadcast.
> 
> If the difficulty can be directly observed by the script language, you
> would need to re-evaluate all scripts in unconfirmed transactions
> whenever the difficulty changes. This complicates implementation of
> mempools, but it also makes reasoning about validity of (chains of)
> unconfirmed transactions harder, as an unconfirmed predecessor may
> have conditions that change over time.
> 
> For things like block time/height, this is solved by not having the
> script itself observe the context state directly, but instead having
> an assertion on the state outside of script (nLockTime for absolute
> time/height and nSequence for relative), and then having opcodes
> inside script that observe the assertion (OP_CLTV and OP_CSV). By
> doing so, script validity is a single context-free yes or not that can
> be evaluated once, and the variable part is just transaction-level
> reasoning that doesn't involve a full script interpreter.
> Additionally, the supported assertions are restricted in such a way
> that if they are true within a particular block, they're also true in
> any descendant, removing the complexity of reasoning about validity
> (apart from the inevitable reasoning about possible double-spend
> before confirmation).
> 
> I feel a similar construction is needed for observing block
> difficulty. This can be done by either having an opcode that as a side
> effect of execution "posts" an assertion (e.g. "difficulty at block
> height X is at least Y"), instead of putting the difficulty on the
> stack. An alternative is having the assertion be part of the
> transaction structure (for example in the annex we propose in
> bip-taproot), and having an opcode that observes the difficulty
> assertion inside script.

Thanks for these suggestions I will follow up while preparing the BIP.

> 
> I don't have a strong opinion either way on the usefulness of having
> difficulty-dependent transaction/scripts.
> 

This is the best reception I could have hoped for :)

> Cheers,
> 
> --
> Pieter



signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] OP_DIFFICULTY to enable difficulty hedges (bets) without an oracle and 3rd party.

[Tamas Blummer via bitcoin-dev]

Block hash can suggest much higher difficulty than what is in effect, so 
OP_CHECKBLOCKATHEIGHT would not work to decide if difficulty is above the level 
of the bet.

> On May 23, 2019, at 21:45, Tamas Blummer  wrote:
> 
> I see. The uncompressing needs to be done either to compare. How are chances 
> for that BIP?
> 
> This BIP would be explicitly offering risk managment of miners biggest risk.
> Doing so without relying on external markets or oracle, self cointained would 
> be an impressive and adequate feature.
> 
> Tamas Blummer
> 
>> On May 23, 2019, at 21:21, Nathan Cook  wrote:
>> 
>> It's true that it fetches the block hash; the idea is to compare the block 
>> hash's numeric value to the desired (uncompressed) difficulty directly, 
>> using a 256-bit version of OP_LESSTHAN.
>> 
>> Nathan Cook
>> 
>> 
>> On Thu, 23 May 2019 at 22:18, Tamas Blummer  wrote:
>> That opcode would not help as it fetches block hash and not the content of 
>> the header.
>> 
>>> On May 23, 2019, at 21:05, Nathan Cook  wrote:
>>> 
>>> You can get the same effect with OP_CHECKBLOCKATHEIGHT as proposed by Luke 
>>> Dashjr (https://github.com/luke-jr/bips/blob/bip-cbah/bip-cbah.mediawiki) 
>>> if you also re-enable/extend certain opcodes like OP_AND and OP_LESSTHAN. 
>>> See 
>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-September/013149.html
>>>  and the ensuing thread.
>>> 
>>> Nathan Cook
>>> 
>>> 
>>> On Thu, 23 May 2019 at 21:33, Tamas Blummer via bitcoin-dev 
>>>  wrote:
>>> Difficulty change has profound impact on miner’s production thereby 
>>> introduce the biggest risk while considering an investment.
>>> Commodity markets offer futures and options to hedge risks on traditional 
>>> trading venues. Some might soon list difficulty futures.
>>> 
>>> I think we could do much better than them natively within Bitcoin.
>>> 
>>> A better solution could be a transaction that uses nLocktime denominated in 
>>> block height, such that it is valid after the difficulty adjusted block in 
>>> the future.
>>> A new OP_DIFFICULTY opcode would put onto stack the value of difficulty for 
>>> the block the transaction is included into.
>>> The output script may then decide comparing that value with a strike which 
>>> key can spend it.
>>> The input of the transaction would be a multi-sig escrow of those who 
>>> entered the bet.
>>> The winner would broadcast.
>>> 
>>> Once signed by both the transaction would not carry any counterparty risk 
>>> and would not need an oracle to settle according to the bet.
>>> 
>>> I plan to draft a BIP for this as I think this opcode would serve 
>>> significant economic interest of Bitcoin economy, and is compatible with 
>>> Bitcoin’s aim not to introduce 3rd party to do so.
>>> 
>>> Do you see a fault in this proposal or want to contribute?
>>> 
>>> Tamas Blummer
>>> 
>>> ___
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> 
> 



signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] OP_DIFFICULTY to enable difficulty hedges (bets) without an oracle and 3rd party.

[Tamas Blummer via bitcoin-dev]

I see. The uncompressing needs to be done either to compare. How are chances 
for that BIP?

This BIP would be explicitly offering risk managment of miners biggest risk.
Doing so without relying on external markets or oracle, self cointained would 
be an impressive and adequate feature.

Tamas Blummer

> On May 23, 2019, at 21:21, Nathan Cook  wrote:
> 
> It's true that it fetches the block hash; the idea is to compare the block 
> hash's numeric value to the desired (uncompressed) difficulty directly, using 
> a 256-bit version of OP_LESSTHAN.
> 
> Nathan Cook
> 
> 
> On Thu, 23 May 2019 at 22:18, Tamas Blummer  wrote:
> That opcode would not help as it fetches block hash and not the content of 
> the header.
> 
>> On May 23, 2019, at 21:05, Nathan Cook  wrote:
>> 
>> You can get the same effect with OP_CHECKBLOCKATHEIGHT as proposed by Luke 
>> Dashjr (https://github.com/luke-jr/bips/blob/bip-cbah/bip-cbah.mediawiki) if 
>> you also re-enable/extend certain opcodes like OP_AND and OP_LESSTHAN. See 
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-September/013149.html
>>  and the ensuing thread.
>> 
>> Nathan Cook
>> 
>> 
>> On Thu, 23 May 2019 at 21:33, Tamas Blummer via bitcoin-dev 
>>  wrote:
>> Difficulty change has profound impact on miner’s production thereby 
>> introduce the biggest risk while considering an investment.
>> Commodity markets offer futures and options to hedge risks on traditional 
>> trading venues. Some might soon list difficulty futures.
>> 
>> I think we could do much better than them natively within Bitcoin.
>> 
>> A better solution could be a transaction that uses nLocktime denominated in 
>> block height, such that it is valid after the difficulty adjusted block in 
>> the future.
>> A new OP_DIFFICULTY opcode would put onto stack the value of difficulty for 
>> the block the transaction is included into.
>> The output script may then decide comparing that value with a strike which 
>> key can spend it.
>> The input of the transaction would be a multi-sig escrow of those who 
>> entered the bet.
>> The winner would broadcast.
>> 
>> Once signed by both the transaction would not carry any counterparty risk 
>> and would not need an oracle to settle according to the bet.
>> 
>> I plan to draft a BIP for this as I think this opcode would serve 
>> significant economic interest of Bitcoin economy, and is compatible with 
>> Bitcoin’s aim not to introduce 3rd party to do so.
>> 
>> Do you see a fault in this proposal or want to contribute?
>> 
>> Tamas Blummer
>> 
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 



signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] OP_DIFFICULTY to enable difficulty hedges (bets) without an oracle and 3rd party.

[Tamas Blummer via bitcoin-dev]

That opcode would not help as it fetches block hash and not the content of the 
header.

> On May 23, 2019, at 21:05, Nathan Cook  wrote:
> 
> You can get the same effect with OP_CHECKBLOCKATHEIGHT as proposed by Luke 
> Dashjr (https://github.com/luke-jr/bips/blob/bip-cbah/bip-cbah.mediawiki 
> <https://github.com/luke-jr/bips/blob/bip-cbah/bip-cbah.mediawiki>) if you 
> also re-enable/extend certain opcodes like OP_AND and OP_LESSTHAN. See 
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-September/013149.html
>  
> <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-September/013149.html>
>  and the ensuing thread.
> 
> Nathan Cook
> 
> 
> On Thu, 23 May 2019 at 21:33, Tamas Blummer via bitcoin-dev 
>  <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
> Difficulty change has profound impact on miner’s production thereby introduce 
> the biggest risk while considering an investment.
> Commodity markets offer futures and options to hedge risks on traditional 
> trading venues. Some might soon list difficulty futures.
> 
> I think we could do much better than them natively within Bitcoin.
> 
> A better solution could be a transaction that uses nLocktime denominated in 
> block height, such that it is valid after the difficulty adjusted block in 
> the future.
> A new OP_DIFFICULTY opcode would put onto stack the value of difficulty for 
> the block the transaction is included into.
> The output script may then decide comparing that value with a strike which 
> key can spend it.
> The input of the transaction would be a multi-sig escrow of those who entered 
> the bet.
> The winner would broadcast.
> 
> Once signed by both the transaction would not carry any counterparty risk and 
> would not need an oracle to settle according to the bet.
> 
> I plan to draft a BIP for this as I think this opcode would serve significant 
> economic interest of Bitcoin economy, and is compatible with Bitcoin’s aim 
> not to introduce 3rd party to do so.
> 
> Do you see a fault in this proposal or want to contribute?
> 
> Tamas Blummer
> 
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org 
> <mailto:bitcoin-dev@lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev 
> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>



signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] OP_DIFFICULTY to enable difficulty hedges (bets) without an oracle and 3rd party.

[Tamas Blummer via bitcoin-dev]

The parameter used is property of the block just like the block height is a 
property and is already evaluated in scripts,
so no new kind of dependency or encapsulation break.

The transaction itself was not invalid in a re-org but evtl. others spending it 
if the difficulty on that fork is different,
this is however intended as then on that fork the other was the winner.

Tamas Blummer

> On May 23, 2019, at 21:03, Jorge Timón  wrote:
> 
> The complains I could imagine about this, (apart from being a very
> specific use case) are the same complains I heard about op_expiry.
> Namely, that in a reorg, the same tx, having been valid in a given
> block could potentially become invalid in some other block mining it.
> I guess in this case the situation is less likely in this case than
> with op_expiry, but it is still possible.
> Another complain I could imagine is this kind of forces the
> implementation to break some existing encapsulations, but I guess
> those are just implementation details not that relevant here.
> I personally don't have strong feelings towards this proposal one way
> or the other, I'm just imagining what other people may complain about.
> 
> On Thu, May 23, 2019 at 8:33 PM Tamas Blummer via bitcoin-dev
>  wrote:
>> 
>> Difficulty change has profound impact on miner’s production thereby 
>> introduce the biggest risk while considering an investment.
>> Commodity markets offer futures and options to hedge risks on traditional 
>> trading venues. Some might soon list difficulty futures.
>> 
>> I think we could do much better than them natively within Bitcoin.
>> 
>> A better solution could be a transaction that uses nLocktime denominated in 
>> block height, such that it is valid after the difficulty adjusted block in 
>> the future.
>> A new OP_DIFFICULTY opcode would put onto stack the value of difficulty for 
>> the block the transaction is included into.
>> The output script may then decide comparing that value with a strike which 
>> key can spend it.
>> The input of the transaction would be a multi-sig escrow of those who 
>> entered the bet.
>> The winner would broadcast.
>> 
>> Once signed by both the transaction would not carry any counterparty risk 
>> and would not need an oracle to settle according to the bet.
>> 
>> I plan to draft a BIP for this as I think this opcode would serve 
>> significant economic interest of Bitcoin economy, and is compatible with 
>> Bitcoin’s aim not to introduce 3rd party to do so.
>> 
>> Do you see a fault in this proposal or want to contribute?
>> 
>> Tamas Blummer
>> 
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev



signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] OP_DIFFICULTY to enable difficulty hedges (bets) without an oracle and 3rd party.

[Tamas Blummer via bitcoin-dev]

Difficulty change has profound impact on miner’s production thereby introduce 
the biggest risk while considering an investment.
Commodity markets offer futures and options to hedge risks on traditional 
trading venues. Some might soon list difficulty futures.

I think we could do much better than them natively within Bitcoin.

A better solution could be a transaction that uses nLocktime denominated in 
block height, such that it is valid after the difficulty adjusted block in the 
future.
A new OP_DIFFICULTY opcode would put onto stack the value of difficulty for the 
block the transaction is included into. 
The output script may then decide comparing that value with a strike which key 
can spend it. 
The input of the transaction would be a multi-sig escrow of those who entered 
the bet. 
The winner would broadcast. 

Once signed by both the transaction would not carry any counterparty risk and 
would not need an oracle to settle according to the bet.

I plan to draft a BIP for this as I think this opcode would serve significant 
economic interest of Bitcoin economy, and is compatible with Bitcoin’s aim not 
to introduce 3rd party to do so.

Do you see a fault in this proposal or want to contribute?

Tamas Blummer 

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Smart Contracts Unchained

[Tamas Blummer via bitcoin-dev]

Hi ZmnSCPxj,

Thought provoking, thank you!

Something I dislike in the scheme, that one could not tell which party colluded 
with the escrow agent.

Tamas Blummer

> On Apr 4, 2019, at 03:55, ZmnSCPxj via bitcoin-dev 
>  wrote:
> 
> https://zmnscpxj.github.io/bitcoin/unchained.html
> 
> Smart contracts have traditionally been implemented as part of the consensus 
> rules of some blokchain.  Often this means creating a new blockchain, or at 
> least a sidechain to an existing blockchain.  This writeup proposes an 
> alternative method without launching a separate blockchain or sidechain, 
> while achieving security similar to federated sidechains and additional 
> benefits to privacy and smart-contract-patching.
> ___
> 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

Re: [bitcoin-dev] BIP - Symbol for satoshi

[Tamas Blummer via bitcoin-dev]

It is highly unikely that non-engineers will adopt scientific notation or 
mili/nano/pico prefixes for money. 

All common currencies either have no change or one that is 1/100 of the base 
unit. 
This is the convention that practically all existing finance software and 
non-Bitcoin related UI that deals with money assumes.

Ignoring evident cultural preference and all pre-existenting finance related 
software is blatant Bitcoin engineering blindness.

We already had a BIP for bits, which I support for above reasons. 
https://github.com/bitcoin/bips/blob/master/bip-0176.mediawiki

Tamas Blummer

> On Mar 7, 2019, at 00:35, Gregory Maxwell via bitcoin-dev 
>  wrote:
> 
> On Wed, Mar 6, 2019 at 12:32 AM Amine Chakak via bitcoin-dev
>  wrote:
>> The idea has been floated around to switch to satoshi as a base unit.
> 
> If Satoshi wanted the currency units named after him, he would simply
> have done it. I think this behaviour seems creepy and is harmful to
> Bitcoin.
> 
>> The lightning network uses satoshis as a base unit.
> 
> It absolutely does not. Lightning uses units of 10 picobitcoin (1e-11
> btc), which is significantly smaller.
> 
>> Pleas let me know if it would be appropriate to write a BIP for it.
> 
> Please don't.
> ___
> 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

Re: [bitcoin-dev] Interrogating a BIP157 server, BIP158 change proposal

[Tamas Blummer via bitcoin-dev]

The attack was in your implication that I would assume  ill intent of those
contributed to the proposal. That is not my position. I explained why, I
think, rolling out a commitment could face opposition. This foreseable
opposition, that must not come from you makes me prefer a provable
uncommitted filter for now.

I am myself concerned of the implications if many nodes would blindly
follow POW.

I did restart the discussion which I read and participated in at its first
instance because implementing the current proposal taught me how
problematic as is until not committed and because I have not seen a sign to
assume commitment was imminent.

This is not just missing code. AFAIK we do not even have a consensus on how
any future soft fork would be activated.

While trying to build a useful software I have to make assumtions on the
timeline of dependencies and in my personal evaluation commitment is not
yet to build on.

I and others learned in this new discussion new arguments such as that of
atomic swaps by Laolu. If nothing else, this was worth of learning.

It appears me that it is rather you assuming ill intent on my side, which
hurts given that I do contribute to the ecosystem since many years and have
not ever been caught of hurting the project.

Tamas Blummer


On Wed, 6 Feb 2019, 20:16 Gregory Maxwell  On Wed, Feb 6, 2019 at 7:48 PM Tamas Blummer 
> wrote:
> > I do not think this ad hominem attack of you on me was justified.
>
> I apologize if I have offended you, but I am at a loss to find in my
> words you found to be an attack. Can you help me out?
>
> On reread the only thing I'm saying is that you hadn't even read the
> prior discussion. Am I mistaken?  If so, why did you simply propose
> reverting prior improvements without addressing the arguments given
> the first time around or even acknowledging that you were rehashing an
> old discussion?
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Interrogating a BIP157 server, BIP158 change proposal

[Tamas Blummer via bitcoin-dev]

I do not think this ad hominem attack of you on me was justified.

I wrote code, gathered and shared data now and back in 2018. I showed
understanding of non technical issues. Is there an actual action that
defies my observation that a commitment is not yet in sight?

Is there anything technically wrong in what I wrote?

If not you should stop.

Tamas Blummer


On Wed, 6 Feb 2019, 18:17 Gregory Maxwell  On Wed, Feb 6, 2019 at 8:10 AM Tamas Blummer 
> wrote:
> > I am skeptical that commitment of any filter will come into Core soon.
> [...] A committed filter makes light clients much more reliable and
> attractive, for some taste too much more.
>
> You keep repeating this smear. Please stop.
>
> If you would actually bother reading the threads where this was
> discussed previously you will see that there was significant interest
> from bitcoin developers to eventually commit an output filter, and a
> significant investment of effort in improving the proposal to that
> end.  It is really disheartening to see you continue to repeat your
> negative assumptions about other people's wishes when you haven't even
> invested the time required to read their words.
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Interrogating a BIP157 server, BIP158 change proposal

[Tamas Blummer via bitcoin-dev]

itives can be sorted out 
> > with a block download. Murmel implements this if running in server mode, 
> > where blocks are already there.
> > 
> > Therefore I ask for a BIP change based on better insight gained through 
> > implementation.
> > 
> > Tamas Blummer
> > 
> >> On Feb 4, 2019, at 21:18, Jim Posen  wrote:
> >> 
> >> Please see the thread "BIP 158 Flexibility and Filter Size" from 2018 
> >> regarding the decision to remove outpoints from the filter [1].
> >> 
> >> Thanks for bringing this up though, because more discussion is needed on 
> >> the client protocol given that clients cannot reliably determine the 
> >> integrity of a block filter in a bandwidth-efficient manner (due to the 
> >> inclusion of input scripts).
> >> 
> >> I see three possibilities:
> >> 1) Introduce a new P2P message to retrieve all prev-outputs for a given 
> >> block (essentially the undo data in Core), and verify the scripts against 
> >> the block by executing them. While this permits some forms of input script 
> >> malleability (and thus cannot discriminate between all valid and invalid 
> >> filters), it restricts what an attacker can do. This was proposed by Laolu 
> >> AFAIK, and I believe this is how btcd is proceeding.
> >> 2) Clients track multiple possible filter header chains and essentially 
> >> consider the union of their matches. So if any filter received for a 
> >> particular block header matches, the client downloads the block. The 
> >> client can ban a peer if they 1) ever return a filter omitting some data 
> >> that is observed in the downloaded block, 2) repeatedly serve filters that 
> >> trigger false positive block downloads where such a number of false 
> >> positives is statistically unlikely, or 3) repeatedly serves filters that 
> >> are significantly larger than the expected size (essentially padding the 
> >> actual filters with garbage to waste bandwidth). I have not done the 
> >> analysis yet, but we should be able to come up with some fairly simple 
> >> banning heuristics using Chernoff bounds. The main downside is that the 
> >> client logic to track multiple possible filter chains and filters per 
> >> block is more complex and bandwidth increases if connected to a malicious 
> >> server. I first heard about this idea from David Harding.
> >> 3) Rush straight to committing the filters into the chain (via witness 
> >> reserved value or coinbase OP_RETURN) and give up on the pre-softfork BIP 
> >> 157 P2P mode.
> >> 
> >> I'm in favor of option #2 despite the downsides since it requires the 
> >> smallest number of changes and is supported by the BIP 157 P2P protocol as 
> >> currently written. (Though the recommended client protocol in the BIP 
> >> needs to be updated to account for this). Another benefit of it is that it 
> >> removes some synchronicity assumptions where a peer with the correct 
> >> filters keeps timing out and is assumed to be dishonest, while the 
> >> dishonest peer is assumed to be OK because it is responsive.
> >> 
> >> If anyone has other ideas, I'd love to hear them.
> >> 
> >> -jimpo
> >> 
> >> [1] 
> >> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-June/016057.html
> >> 
> >> 
> >> 
> >> On Mon, Feb 4, 2019 at 10:53 AM Tamas Blummer via bitcoin-dev 
> >>  wrote:
> >> TLDR: a change to BIP158 would allow decision on which filter chain is 
> >> correct at lower bandwith use
> >> 
> >> Assume there is a BIP157 client that learned a filter header chain earlier 
> >> and is now offered an alternate reality by a newly connected BIP157 server.
> >> 
> >> The client notices the alternate reality by routinely asking for filter 
> >> chain checkpoints after connecting to a new BIP157 server. A divergence at 
> >> a checkpoint means that the server disagrees the client's history at or 
> >> before the first diverging checkpoint. The client would then request the 
> >> filter headers between the last matching and first divergent checkpoint, 
> >> and quickly figure which block’s filter is the first that does not match 
> >> previous assumption, and request that filter from the server.
> >> 
> >> The client downloads the corresponding block, checks that its header fits 
> >> the PoW secured best header chain, re-calculates merkle root of its 
> >> transaction list to

Re: [bitcoin-dev] Interrogating a BIP157 server, BIP158 change proposal

[Tamas Blummer via bitcoin-dev]

or bringing this up though, because more discussion is needed on the 
>> client protocol given that clients cannot reliably determine the integrity 
>> of a block filter in a bandwidth-efficient manner (due to the inclusion of 
>> input scripts).
>> 
>> I see three possibilities:
>> 1) Introduce a new P2P message to retrieve all prev-outputs for a given 
>> block (essentially the undo data in Core), and verify the scripts against 
>> the block by executing them. While this permits some forms of input script 
>> malleability (and thus cannot discriminate between all valid and invalid 
>> filters), it restricts what an attacker can do. This was proposed by Laolu 
>> AFAIK, and I believe this is how btcd is proceeding.
>> 2) Clients track multiple possible filter header chains and essentially 
>> consider the union of their matches. So if any filter received for a 
>> particular block header matches, the client downloads the block. The client 
>> can ban a peer if they 1) ever return a filter omitting some data that is 
>> observed in the downloaded block, 2) repeatedly serve filters that trigger 
>> false positive block downloads where such a number of false positives is 
>> statistically unlikely, or 3) repeatedly serves filters that are 
>> significantly larger than the expected size (essentially padding the actual 
>> filters with garbage to waste bandwidth). I have not done the analysis yet, 
>> but we should be able to come up with some fairly simple banning heuristics 
>> using Chernoff bounds. The main downside is that the client logic to track 
>> multiple possible filter chains and filters per block is more complex and 
>> bandwidth increases if connected to a malicious server. I first heard about 
>> this idea from David Harding.
>> 3) Rush straight to committing the filters into the chain (via witness 
>> reserved value or coinbase OP_RETURN) and give up on the pre-softfork BIP 
>> 157 P2P mode.
>> 
>> I'm in favor of option #2 despite the downsides since it requires the 
>> smallest number of changes and is supported by the BIP 157 P2P protocol as 
>> currently written. (Though the recommended client protocol in the BIP needs 
>> to be updated to account for this). Another benefit of it is that it removes 
>> some synchronicity assumptions where a peer with the correct filters keeps 
>> timing out and is assumed to be dishonest, while the dishonest peer is 
>> assumed to be OK because it is responsive.
>> 
>> If anyone has other ideas, I'd love to hear them.
>> 
>> -jimpo
>> 
>> [1] 
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-June/016057.html
>> 
>> 
>> 
>> On Mon, Feb 4, 2019 at 10:53 AM Tamas Blummer via bitcoin-dev 
>>  wrote:
>> TLDR: a change to BIP158 would allow decision on which filter chain is 
>> correct at lower bandwith use
>> 
>> Assume there is a BIP157 client that learned a filter header chain earlier 
>> and is now offered an alternate reality by a newly connected BIP157 server.
>> 
>> The client notices the alternate reality by routinely asking for filter 
>> chain checkpoints after connecting to a new BIP157 server. A divergence at a 
>> checkpoint means that the server disagrees the client's history at or before 
>> the first diverging checkpoint. The client would then request the filter 
>> headers between the last matching and first divergent checkpoint, and 
>> quickly figure which block’s filter is the first that does not match 
>> previous assumption, and request that filter from the server.
>> 
>> The client downloads the corresponding block, checks that its header fits 
>> the PoW secured best header chain, re-calculates merkle root of its 
>> transaction list to know that it is complete and queries the filter to see 
>> if every output script of every transaction is contained in there, if not 
>> the server is lying, the case is closed, the server disconnected.
>> 
>> Having all output scripts in the filter does not however guarantee that the 
>> filter is correct since it might omit input scripts. Inputs scripts are not 
>> part of the downloaded block, but are in some blocks before that. Checking 
>> those are out of reach for lightweight client with tools given by the 
>> current BIP.
>> 
>> A remedy here would be an other filter chain on created and spent outpoints 
>> as is implemented currently by Murmel. The outpoint filter chain must offer 
>> a match for every spent output of the block with the divergent filter, 
>> otherwise the interrogated server is lying since a PoW secured bl

Re: [bitcoin-dev] Interrogating a BIP157 server, BIP158 change proposal

[Tamas Blummer via bitcoin-dev]

I participated in that discussion in 2018, but have not had the insight 
gathered by now though writing both client and server implementation of 
BIP157/158

Pieter Wuille considered the design choice I am now suggesting here as 
alternative (a) in: 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-June/016064.html 
<https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-June/016064.html>
In his evaluation he recognized that a filter having spent output and output 
scripts would allow decision on filter correctness by knowing the block only.
He did not evaluate the usefulness in the context of checkpoints, which I think 
are an important shortcut here.

Yes, a filter that is collecting input and output scripts is shorter if script 
re-use is frequent, but I showed back in 2018 in the same thread that this 
saving is not that significant in recent history as address reuse is no longer 
that frequent.

A filter on spent outpoint is just as useful for wallets as is one on spent 
script, since they naturally scan the blockchain forward and thereby learn 
about their coins by the output script before they need to check spends of 
those outpoints.

It seems to me that implementing an interrogation by evtl. downloading blocks 
at checkpoints is much simpler than following multiple possible filter paths.

A spent outpoint filter allows us to decide on coin availability based on 
immutable store, without updated and eventually rolled back UTXO store. The 
availability could be decided by following the filter path to current tip to 
genesis and
check is the outpoint was spent earlier. False positives can be sorted out with 
a block download. Murmel implements this if running in server mode, where 
blocks are already there.

Therefore I ask for a BIP change based on better insight gained through 
implementation.

Tamas Blummer

> On Feb 4, 2019, at 21:18, Jim Posen  wrote:
> 
> Please see the thread "BIP 158 Flexibility and Filter Size" from 2018 
> regarding the decision to remove outpoints from the filter [1].
> 
> Thanks for bringing this up though, because more discussion is needed on the 
> client protocol given that clients cannot reliably determine the integrity of 
> a block filter in a bandwidth-efficient manner (due to the inclusion of input 
> scripts).
> 
> I see three possibilities:
> 1) Introduce a new P2P message to retrieve all prev-outputs for a given block 
> (essentially the undo data in Core), and verify the scripts against the block 
> by executing them. While this permits some forms of input script malleability 
> (and thus cannot discriminate between all valid and invalid filters), it 
> restricts what an attacker can do. This was proposed by Laolu AFAIK, and I 
> believe this is how btcd is proceeding.
> 2) Clients track multiple possible filter header chains and essentially 
> consider the union of their matches. So if any filter received for a 
> particular block header matches, the client downloads the block. The client 
> can ban a peer if they 1) ever return a filter omitting some data that is 
> observed in the downloaded block, 2) repeatedly serve filters that trigger 
> false positive block downloads where such a number of false positives is 
> statistically unlikely, or 3) repeatedly serves filters that are 
> significantly larger than the expected size (essentially padding the actual 
> filters with garbage to waste bandwidth). I have not done the analysis yet, 
> but we should be able to come up with some fairly simple banning heuristics 
> using Chernoff bounds. The main downside is that the client logic to track 
> multiple possible filter chains and filters per block is more complex and 
> bandwidth increases if connected to a malicious server. I first heard about 
> this idea from David Harding.
> 3) Rush straight to committing the filters into the chain (via witness 
> reserved value or coinbase OP_RETURN) and give up on the pre-softfork BIP 157 
> P2P mode.
> 
> I'm in favor of option #2 despite the downsides since it requires the 
> smallest number of changes and is supported by the BIP 157 P2P protocol as 
> currently written. (Though the recommended client protocol in the BIP needs 
> to be updated to account for this). Another benefit of it is that it removes 
> some synchronicity assumptions where a peer with the correct filters keeps 
> timing out and is assumed to be dishonest, while the dishonest peer is 
> assumed to be OK because it is responsive.
> 
> If anyone has other ideas, I'd love to hear them.
> 
> -jimpo
> 
> [1] 
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-June/016057.html 
> <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-June/016057.html>
> 
> 
> 
> On Mon, Feb 4, 2019 at 10:53 AM Tamas Blummer via bitcoin-dev 
>  <

[bitcoin-dev] Interrogating a BIP157 server, BIP158 change proposal

[Tamas Blummer via bitcoin-dev]

TLDR: a change to BIP158 would allow decision on which filter chain is correct 
at lower bandwith use

Assume there is a BIP157 client that learned a filter header chain earlier and 
is now offered an alternate reality by a newly connected BIP157 server.

The client notices the alternate reality by routinely asking for filter chain 
checkpoints after connecting to a new BIP157 server. A divergence at a 
checkpoint means that the server disagrees the client's history at or before 
the first diverging checkpoint. The client would then request the filter 
headers between the last matching and first divergent checkpoint, and quickly 
figure which block’s filter is the first that does not match previous 
assumption, and request that filter from the server.

The client downloads the corresponding block, checks that its header fits the 
PoW secured best header chain, re-calculates merkle root of its transaction 
list to know that it is complete and queries the filter to see if every output 
script of every transaction is contained in there, if not the server is lying, 
the case is closed, the server disconnected.

Having all output scripts in the filter does not however guarantee that the 
filter is correct since it might omit input scripts. Inputs scripts are not 
part of the downloaded block, but are in some blocks before that. Checking 
those are out of reach for lightweight client with tools given by the current 
BIP.

A remedy here would be an other filter chain on created and spent outpoints as 
is implemented currently by Murmel. The outpoint filter chain must offer a 
match for every spent output of the block with the divergent filter, otherwise 
the interrogated server is lying since a PoW secured block can not spend coins 
out of nowhere. Doing this check would already force the client to download the 
outpoint filter history up-to the point of divergence. Then the client would 
have to download and PoW check every block that shows a match in outpoints 
until it figures that one of the spent outputs has a script that was not in the 
server’s filter, in which case the server is lying. If everything checks out 
then the previous assumption on filter history was incorrect and should be 
replaced by the history offered by the interrogated server. 

As you see the interrogation works with this added filter but is highly 
ineffective. A really light client should not be forced to download lots of 
blocks just to uncover a lying filter server. This would actually be an easy 
DoS on light BIP157 clients.

A better solution is a change to BIP158 such that the only filter contains 
created scripts and spent outpoints. It appears to me that this would serve 
well both wallets and interrogation of filter servers well:

Wallets would recognize payments to their addresses by the filter as output 
scripts are included, spends from the wallet would be recognized as a wallet 
already knows outpoints of its previously received coins, so it can query the 
filters for them.

Interrogation of a filter server also simplifies, since the filter of the block 
can be checked entirely against the contents of the same block. The decision on 
filter correctness does not require more bandwith then download of a block at 
the mismatching checkpoint. The client could only be forced at max. to download 
1/1000 th of the blockchain in addition to the filter header history.

Therefore I suggest to change BIP158 to have a base filter, defined as:

A basic filter MUST contain exactly the following items for each transaction in 
a block:
• Spent outpoints
• The scriptPubKey of each output, aside from all OP_RETURN output 
scripts.

Tamas Blummer
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] BIP157 server Murmel introduced, enchancement suggestion to BIP158

[Tamas Blummer via bitcoin-dev]

TLDR: I suggest to add outpoint filter to BIP158 as it proved to be useful 
while developing a filter server and allows further checks in filter client.

Murmel is my project within the rust-bitcoin community. 
https://github.com/rust-bitcoin/murmel

Its goal is to provide a lightweight, at least SPV security, settlement layer 
for the Lightning Network implementation in Rust. 
https://github.com/rust-bitcoin/rust-lightning

Murmel relies on BIP157 (Client Side Block Filtering). Since Bitcoin Core does 
not yet support this protocol extension, I also added filter and block server 
functionality to Murmel and this might be useful for 
development purposes any other BIP157 client project.

You may compile and run a Murmel filter server to support your client 
development. It bootstraps within a few hours. Follow the instructions at: 
https://github.com/rust-bitcoin/murmel

While implementing both client and server side I made an observation that 
should be considered for BIP158:

BIP158 specifies base filter containing all scripts spent or created by a block 
(except those with OP_RETURN). I found it useful to also compute a filter on 
spent and created outpoints.
The Murmel filter server consults these outpoint filters to find the 
transactions with the spent scripts while computing the base script filter. 
Since outpoints usually getting spent shortly after created, this approach 
works well enough to
keep up with the blockchain, although far too slow to rely on it while 
bootstrapping. An advantage of this approach of looking up UTXO is that there 
is nothing to be recomputed at re-org, filters are consulted following
the path from current tip back to genesis. This fits well with Murmel’s 
storage, that is my other project Hammersbald 
https://github.com/rust-bitcoin/hammersbald, a highly efficient truly append 
only blockchain store in Rust.
Filter matching is also nicely parallelizable looking up subsets of spent 
outputs in parallel. 

A lightweight client can use outpoint filters to efficiently validate spent 
coins or miner reward, which goes beyond SPV guarantees. This is 
probabilistically possible now, and definitely once filters are committed.

For above reasons I suggest to also add outpoint filter to BIP158, so filter 
servers may support it, as does Murmel. Murmel is moving quickly; I tagged the 
version as of this mail with DEVLIST for later reference.

Tamas Blummer
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP 158 Flexibility and Filter Size

[Tamas Blummer via bitcoin-dev]

Correction:
- Output script + spent script filters (Wuille’s (b)) have sizes of ca. 2% of 
block size.

Tamas Blummer

> On Jun 3, 2018, at 18:44, Tamas Blummer  wrote:
> 
> I processed bitcoin history assuming filters using with P=19 M=784931.
> 
> Findings:
> - Output script + spent script filters (Wuille’s (b)) have sizes of ca. 0.2% 
> of block size.
> - Output script + spent script filters (Wuille’s (b)) are ca. 10% smaller 
> than output script + spent outpoint filters (Wuille's (a)). Savings here 
> however trend lower since years.
> 
> Graphs attached.
> 
> Tamas Blummer
> 
> 



signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP 158 Flexibility and Filter Size

[Tamas Blummer via bitcoin-dev]

Lighter but SPV secure nodes (filter committed) would help the network (esp. 
Layer 2) to grow mesh like, but add more user that blindly follow POW.

On longer term most users' security will be determined by either trusted hubs 
or POW.
I do not know which is worse, but we should at least offer the choice to the 
user, therefore commit filters.

Tamas Blummer

> On Jun 3, 2018, at 02:28, Gregory Maxwell  wrote:
> 
> pretty much us that all these filter things are a total waste of time.


signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP 158 Flexibility and Filter Size

[Tamas Blummer via bitcoin-dev]

Without block commitment mobiles would have to use trusted filter provider or 
implement a complex data hungry algorithm and still remain as insecure as with 
BIP 37.

Years of experience implementing wallets with BIP 37 taught us that an outpoint 
+ output script filter is useful. Committing such a filter to the block can not 
be an error.

We could roll this out on P2P prior to a soft fork adding the commitment, but I 
would not expect its use to pick up before that.
Therafter BIP 37 could be rightfully decommissioned, herby offering both 
security and privacy enhancement at modest data cost.

Tamas Blummer

> On Jun 2, 2018, at 14:41, David A. Harding via bitcoin-dev 
>  wrote:
> 
> On Fri, Jun 01, 2018 at 07:02:38PM -0700, Jim Posen via bitcoin-dev wrote:
>> Without the ability to verify filter validity, a client would have to stop
>> syncing altogether in the presence of just one malicious peer, which is
>> unacceptable.
> 
> I'm confused about why this would be the case.  If Alice's node
> generates filters accurately and Mallory's node generates filters
> inaccurately, and they both send their filters to Bob, won't Bob be able
> to download any blocks either filter indicates are relevant to his
> wallet?



signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP 158 Flexibility and Filter Size

[Tamas Blummer via bitcoin-dev]

Forgot to mention: The link I sent is to a branch that is patched to produce 
the filter stats. 
This is the main project and the BIP158 implementation: 
https://github.com/rust-bitcoin/rust-bitcoin-spv/blob/master/src/blockfilter.rs

Tamas Blummer

> On May 28, 2018, at 20:18, Tamas Blummer  wrote:
> 
> Hi Jim,
> 
> A “basic” combined filter would mean up to 0.5 GB filter data per month (with 
> 100% segwith use). Considering that 1 GB is the usual data quota for an entry 
> level mobile phone contract, this could be a too high barrier for adoption.
> 
> I repeated your calculations and produced a slightly different graph that 
> shows the fraction of cummulative filter size to cummulative blockchain size. 
> This is less noisy but otherwise confirms your measurement.
> 
> I think that the data supports separation of filters as a combined filter 
> does not seem to come with significant savings. (basic  size ~= txid + input 
> points + output scripts sizes)
>  
> My calculations are repeatable with:
> 
> https://github.com/tamasblummer/rust-bitcoin-spv/blob/blockfilterstats/src/bin/blockfilterstats.rs
> 
> that is using a Rust implementation of an SPV client built on top of other 
> libraries we work on in the rust-bitcoin GitHub community 
> (https://github.com/rust-bitcoin). Yes, this is a shameles plug for the 
> project hoping to attract more developer.
> 
> Tamas Blummer
> 
> 
> 
> 
>> On May 24, 2018, at 05:48, Jim Posen via bitcoin-dev 
>>  wrote:
>> 
>> Greg, I've attached a graph including the input scripts.
>> 
>> In the top graph, we can see how the input script filter compares to the 
>> input outpoint filter. It is definitely smaller as a result of address 
>> reuse. The bottom graph shows the ratio over time of combining the input 
>> prev script and output script filters vs keeping them separate. In more 
>> recent blocks, it appears that there are decreasing savings.
>> 
> 

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP Proposal: Utilization of bits denomination

[Tamas Blummer via bitcoin-dev]

I see further arguments supporting the “bit" denomination:

huge benefit:
- amounts denominated in bits fit nicely into legacy database 
structures and UIs with two decimal places for currency. This change to the 
usual currrency precision is a huge benefit for integration into existing 
financial software.

nice to have:
- while fraction prefixes m for 1/1000 and u for 1/100 are obvious 
to engineers and geeks, they are a foreign concept to many. Chances confusing 
magnitudes would be high if alternative scales were offered.
- bit assigns an easy to comprehend meaning to the second part of the 
Bitcoin name: I think the term “(a whole) coin" would quickly catch on as a 
synonym for a million bits.


Tamas Blummer
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Segregated Witness features wish list

[Tamas Blummer via bitcoin-dev]

Note that the unused space in coin base input script allows us to soft-fork an 
additional SW Merkle tree root into the design,
therefore please make sure the new SW data structure also has a new slot for 
future extension.

Tamas Blummer

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Dynamic Hierarchical Deterministic Key Trees

[Tamas Blummer via bitcoin-dev]

Hi Eric,

Would you please enumerate, or point to, arguments that discourage the use of a 
key both for signing and for derivation of a deeper level of the hierarchy ?

Tamas Blummer

> On Nov 17, 2015, at 12:40, Eric Lombrozo via bitcoin-dev 
>  wrote:
> 
> I've submitted a BIP proposal that solves the issue of needing to predefine 
> HD wallet structures and not being able to arbitrarily nest deeper levels. 
> Comments appreciated.
>  
> https://github.com/bitcoin/bips/pull/242
>  
>  
> - Eric
> ___
> 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

Re: [bitcoin-dev] [patch] Switching Bitcoin Core to sqlite db

[Tamas Blummer via bitcoin-dev]

Isolating storage from the rest of consensus code is technically desirable, but 
implementations using different storage will be unlikely bug-for-bug compatible,
hence able to split the network.

Such split was disastrous on the network level if partitions were of comparable 
magnitude - as was the case in the March 2013 fork between versions of Bitcoin 
Core.

This means high level implementation diversity was great, provided we would get 
there without blowing up the network on the way from monoculture to true 
decentralization of code.

Libconsensus is immensely valuable to get diversity, as it makes alternate 
implementations bug-for-bug compatible for a big part of the consensus code.

Tamas Blummer


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Libconsensus separated repository (was Bitcoin Core and hard forks)

[Tamas Blummer via bitcoin-dev]

I see the huge amount of sweat and love that went into core and it actually 
hurts to see that most is expended in friction and lack of a vision for the 
software architecture.

To be concrete, this was my plan if dealing with the Core code base:

1) I'd consider the separation of networking and storage as suggested for a 
future extended libconsensus low priority, as their design should be (are) 
dominated by the need of the consensus logic only.

2) create an API to the consensus+networking+storage service that is not at the 
C++ language level but some scaleable cross-platform remoting, like eg. ZeroMQ.
This API should be minimal and simple, assuming that one fully trusts the node 
answering it. This API would unlock user land development by distinct teams 
with diverse technologies.

3) move the wallet, QT and RPC and other backward compatibility stuff (if e.g. 
there is some mining support) in-top of the new API and into distinct source 
code repositories.


Tamas Blummer

 On Aug 23, 2015, at 03:23, Eric Lombrozo elombr...@gmail.com wrote:
 
 I've been pushing for greater modularization since I first got into bitcoin. 
 I got quickly frustrated when I was only able to get through very few things 
 (i.e. moving core structure serialization classes to a separate unit not 
 called main). Working on Bitcoin has an added layer of frustration that goes 
 beyond most open source projects: even though we're clearly in userland 
 working at the application layer, a good layered protocol design is still 
 lacking. We have no standards process separate from what basically amount to 
 updates to one specific reference implementation. And we all need to agree on 
 any major change, since a blockchain that is easily forked in contentious 
 ways pretty much defeats its own purpose.
 
 I went off to develop my own stack, where I could more easily avoid politics 
 and focus on engineering. But I now understand the politics are inevitable. 
 Bitcoin is inherently a cooperative project. Several people have poured 
 themselves passionately into the reference codebase, most of whom did it (at 
 least initially) purely as unpaid volunteers. There's a lot of love that's 
 gone into this. But it's become pretty clear that the modularization is no 
 longer merely a matter of good engineering - it is essential to resolving 
 serious political challenges.
 
 Perhaps the most frustrating thing of all is watching people pushing for 
 relatively superficial yet highly controversial changes while we still lack 
 the proper infrastructure to handle these kinds of divergences of opinion 
 without either stagnating or becoming polarized.
 
 I could continue working to reimplement an entire stack from scratch, as 
 several others have also done - but besides the serious effort duplication 
 this entails, it doesn't really seem like it will ultimately be a convergent 
 process. It's too easy to let ego and habit dictate one's preferences rather 
 than rational engineering considerations.
 
 I know that some might feel I'm just preaching to the choir, but we should 
 probably take a step back from implementation hackery and try to specify some 
 core protocol layers, focusing on interfaces. Specifically, we need a 
 consensus layer that doesn't try to specify networking, storage, wallets, UI, 
 etc. Let different people improve upon these things independently in their 
 own implementations. What matters is that we all converge on a common history 
 and state. At the same time, let's open up more competition on all these 
 other things that are separate from the consensus layer.
 
 If only we were to dedicate a fraction of the effort we've put into this 
 whole block size circus into what's actually important...and I blame myself 
 as well...
 
 
 On Sat, Aug 22, 2015, 4:05 AM Tamas Blummer via bitcoin-dev 
 bitcoin-dev@lists.linuxfoundation.org 
 mailto:bitcoin-dev@lists.linuxfoundation.org wrote:
 On Aug 21, 2015, at 21:46, Jorge Timón jti...@jtimon.cc 
 mailto:jti...@jtimon.cc wrote:
 
 On Thu, Aug 20, 2015 at 10:35 AM, Tamas Blummer ta...@bitsofproof.com 
 mailto:ta...@bitsofproof.com wrote:
 Every re-implementation, re-factoring even copy-paste introduces a risk of 
 disagreement,
 but also open the chance of doing the work better, in the sense of software 
 engineering.
 
 But you don't want something better, you want something functionally 
 identical.
 You may want to watch sipa's explanation on why the implementation is
 the specification and the reasons to separate libconsensus:
 https://youtu.be/l3O4nh79CUU?t=764 https://youtu.be/l3O4nh79CUU?t=764
 
 I do want something better, but not for the focus you have.
 
 Not because what you produce was not high quality, but because quality is 
 achieved at a very
 high cost and is hard to uphold over generations of developer. You focus on a 
 single use case
 while there are many out there for distributed ledgers.
 
 I think in an infrastructure for enterprise applications, building

Re: [bitcoin-dev] Libconsensus separated repository (was Bitcoin Core and hard forks)

[Tamas Blummer via bitcoin-dev]

 On Aug 21, 2015, at 21:46, Jorge Timón jti...@jtimon.cc wrote:
 
 On Thu, Aug 20, 2015 at 10:35 AM, Tamas Blummer ta...@bitsofproof.com 
 mailto:ta...@bitsofproof.com wrote:
 Every re-implementation, re-factoring even copy-paste introduces a risk of 
 disagreement,
 but also open the chance of doing the work better, in the sense of software 
 engineering.
 
 But you don't want something better, you want something functionally 
 identical.
 You may want to watch sipa's explanation on why the implementation is
 the specification and the reasons to separate libconsensus:
 https://youtu.be/l3O4nh79CUU?t=764 https://youtu.be/l3O4nh79CUU?t=764

I do want something better, but not for the focus you have.

Not because what you produce was not high quality, but because quality is 
achieved at a very
high cost and is hard to uphold over generations of developer. You focus on a 
single use case
while there are many out there for distributed ledgers.

I think in an infrastructure for enterprise applications, building consensus on 
the ledger is a
cornerstone there, but is only a piece of the solution. I built several 
commercially successful
deployments where I delegated the consensus building to a border router, a 
Bitcoin Core,
then interfaced that trusted peer with my  implementation that accepted Core’s 
decisions
in an SPV manner. One might think of this setup as wasteful and unsuitable for 
“small devices”
therefore an example of centralization people here try to avoid.

Enterprises have sufficient resources. Solving the business problem is valuable 
to them even at
magnitudes higher cost than a hobbyist would bear.

For mainstream adoption you need to get enterprises on board too, and  that is 
what I care of.
Enterprises want code that is not only high quality, but is easy to maintain 
with a development
team with high attrition. One has to take whatever help is offered for that, 
and one is modern
languages and runtimes.

Bits of Proof’s own implementation of the scripts was not practically relevant 
in my commercially
successful deployments, because of the use of a border router, but it helped 
development,
enabling easier debug and precise error feedback esp. end even after Core had a 
reject message.

I integrated libconsensus only for the hope that is significantly fastens 
application side tx verification,
 which it has turned out it does not, until secp265k1 is integrated.

I would likely use an other extended libconsensus too, but do not think there 
was a dependency on
that for enterprise development.

It would help there more to have a slim protocol server, no wallet, no rpc, no 
qt but a high
performance remoting API.

 Since you already depend on libconsensus for VerifyScript, wouldn't it
 be nice that it also offered VerifyTx, VerifyHeader and VerifyBlock?
 You would still have complete control over storage, concurrency,
 networking, policy...
 My plan is for the C API to interface with the external storage by
 passing a function pointer to it.


Storage and validation is non-trivially interconnected, but I now the 
separation can be done,
since I did it.

Excuse me, but function pointers is a pattern I used in the 80’s. I know that 
they are behind
the curtain of modern abstractions with similar use, I still prefer not to see 
them again.

Tamas Blummer



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Libconsensus separated repository (was Bitcoin Core and hard forks)

[Tamas Blummer via bitcoin-dev]

Thinking in Bitcoins only on the level of technology unnecessarily narrows your 
view.

OK, I hope to be pleasantly surprised.

Tamas Blummer

 On Aug 20, 2015, at 23:35, Matt Corallo lf-li...@mattcorallo.com wrote:
 
 
 
 On 08/20/15 21:26, Tamas Blummer wrote:
 I know what you mean as I already have such a component with pluggable
 block store and networking.
 
 I'm not suggesting pluggable networking, I'm suggesting (and I think
 everyone thinks the design should be) NO networking. The API is
 ValidationResult libconsensus.HeyIFoundABlock(Block) and
 ListOfBlocksToDownloadNext libconsensus.HeyIFoundAHeaderList(ListOfHeaders).
 
 While you are at it you could aim for isolation of bitcoin specific
 decisions and algos from generic block chain code.
 
 Are you suggesting to support altcoins? I dont think anyone cares about
 supporting that.
 
 The magnitude of refactoring you would have to do to get there from
 main.cpp and the rest of the hairball
 is harder than a re-write from scratch,
 
 I think you'd be very pleasantly surprised. It sounds like you havent
 dug into Bitcoin Core validation code in years.
 
 and the result will not be
 impressive, just hopefully working.
 
 Hmm? The result would be an obviously correct consensus implementation
 that everyone could use, instead of everyone going off and writing their
 own and either being wrong, or never updating in the case of forks. Its
 a huge deal to allow people to focus on making their libraries have good
 APIs/Wallets/etc instead of focusing on making a working validation
 engine (though maybe for that the p2p layer needs to also be in a library).
 
 I think a slim API server was a lower hanging fruit in Core’s case.
 
 We have one, it just needs a few already obvious performance improvements.
 
 BTW, support for refactoring is an example where you see if your tool
 set is modern.
 
 There are a number of good development tools for C++ that allow this
 
 Tamas Blummer
 
 On Aug 20, 2015, at 19:44, Matt Corallo via bitcoin-dev
 bitcoin-dev@lists.linuxfoundation.org
 mailto:bitcoin-dev@lists.linuxfoundation.org wrote:
 
 I dont think a libconsensus would have any kind of networking layer, nor
 is C++ an antique tool set (hopefully libconsensus can avoid a boost
 dependency, though thats not antique either). Ideally it would have a
 simple API to give it blocks and a simple API for it to inform you of
 what the current chain is. If you really want to get fancy maybe it has
 pluggable block storage, too, but I dont see why you couldnt use this in
 ~any client?
 
 On 08/20/15 08:35, Tamas Blummer via bitcoin-dev wrote:
 Every re-implementation, re-factoring even copy-paste introduces a
 risk of disagreement,
 but also open the chance of doing the work better, in the sense of
 software engineering.
 
 On Aug 20, 2015, at 10:06, Jorge Timón jti...@jtimon.cc
 mailto:jti...@jtimon.cc wrote:
 
 
 But the goal is not reimplementing the consensus rules but rather
 extract them from Bitcoin Core so that nobody needs to re-implement
 them again.
 
 
 
 My goal is different. Compatibility with Bitcoin is important as I
 also want to deal with Bitcoins,
 but it is also imperative to be able to create and serve other block
 chains with other rules and for those
 I do not want to carry on the legacy of an antique tool set and a
 spaghetti style.
 
 Bits of Proof uses scala (akka networking), java (api service), c++
 (leveledb and now libconsensus)
 and I am eager to integrate secp256k1 (c) as soon as part of
 consensus. The choices were
 made because each piece appears best in what they do.
 
 Tamas Blummer
 
 
 
 ___
 bitcoin-dev mailing list
 bitcoin-dev@lists.linuxfoundation.org
 mailto:bitcoin-dev@lists.linuxfoundation.org
 https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
 
 ___
 bitcoin-dev mailing list
 bitcoin-dev@lists.linuxfoundation.org
 mailto:bitcoin-dev@lists.linuxfoundation.org
 https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
 
 
 



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Libconsensus separated repository (was Bitcoin Core and hard forks)

[Tamas Blummer via bitcoin-dev]

I know what you mean as I already have such a component with pluggable block 
store and networking.
While you are at it you could aim for isolation of bitcoin specific decisions 
and algos from generic block chain code.

The magnitude of refactoring you would have to do to get there from main.cpp 
and the rest of the hairball
is harder than a re-write from scratch, and the result will not be impressive, 
just hopefully working.
I think a slim API server was a lower hanging fruit in Core’s case.

BTW, support for refactoring is an example where you see if your tool set is 
modern.

Tamas Blummer

 On Aug 20, 2015, at 19:44, Matt Corallo via bitcoin-dev 
 bitcoin-dev@lists.linuxfoundation.org wrote:
 
 I dont think a libconsensus would have any kind of networking layer, nor
 is C++ an antique tool set (hopefully libconsensus can avoid a boost
 dependency, though thats not antique either). Ideally it would have a
 simple API to give it blocks and a simple API for it to inform you of
 what the current chain is. If you really want to get fancy maybe it has
 pluggable block storage, too, but I dont see why you couldnt use this in
 ~any client?
 
 On 08/20/15 08:35, Tamas Blummer via bitcoin-dev wrote:
 Every re-implementation, re-factoring even copy-paste introduces a risk of 
 disagreement,
 but also open the chance of doing the work better, in the sense of software 
 engineering.
 
 On Aug 20, 2015, at 10:06, Jorge Timón jti...@jtimon.cc wrote:
 
 
 But the goal is not reimplementing the consensus rules but rather
 extract them from Bitcoin Core so that nobody needs to re-implement
 them again.
 
 
 
 My goal is different. Compatibility with Bitcoin is important as I also want 
 to deal with Bitcoins,
 but it is also imperative to be able to create and serve other block chains 
 with other rules and for those
 I do not want to carry on the legacy of an antique tool set and a spaghetti 
 style.
 
 Bits of Proof uses scala (akka networking), java (api service), c++ 
 (leveledb and now libconsensus)
 and I am eager to integrate secp256k1 (c) as soon as part of consensus. The 
 choices were
 made because each piece appears best in what they do.
 
 Tamas Blummer
 
 
 
 ___
 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
 



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] libconsensus assertion fails if used in multiple threads

[Tamas Blummer via bitcoin-dev]

 be trivial to apply to
 release tags.
 
 Please let me know how it works out.
 
 Regards,
 Cory
 
 On Fri, Aug 14, 2015 at 12:37 PM, Tamas Blummer via bitcoin-dev
 bitcoin-dev@lists.linuxfoundation.org wrote:
 We integrated libconsensus into bits of proof. It works well, in-line for 
 all test cases with our Java engine and is about 50% faster on a single 
 thread.
 
 The performance advantage unfortunatelly reverses if libconsensus is 
 executed on several threads simultaneously as we do with the Java engine, 
 since an error:
 
Assertion failed: (pkey != NULL), function CECKey, file 
 ecwrapper.cpp, line 96.
 
 arises under that stress.
 
 I guess that the cause is that thread callbacks as advised for OpenSSL on 
 https://www.openssl.org/docs/crypto/threads.html are not registered.
 Registering those however would require access to OpenSSL functions, not 
 exported from the lib.
 
 I’d be thankful for a pointer to a workaround.
 
 Tamas Blummer
 
 ___
 bitcoin-dev mailing list
 bitcoin-dev@lists.linuxfoundation.org
 https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
 
 



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin XT 0.11A

[Tamas Blummer via bitcoin-dev]

Hi Adam,

I welcomed XT for its declared focus on usability with current means.
I think there is also more room for non-consenus relevant P2P protocol flavors 
than a single code base can accommodate.
XT is also as Jeff just tweeted a relief valve.

It became important, that Bitcoin is able to evolve even if there are 
conflicting educated opinions.
If a review process serves decision making, then I’d be glad to participate.

Tamas Blummer

 On Aug 16, 2015, at 19:01, Adam Back a...@cypherspace.org wrote:
 
 Hi Tamas
 
 Do you find BIP 101, BIP 102, BIP 103 and the flexcap proposal
 deserving of equal consideration?  Just curious because of your post.
 
 Will you be interested to participate in the BIP review process and
 perhaps attend the workshop on Bitcoin scaling announced here
 recently?
 
 Adam
 
 On 16 August 2015 at 17:07, Tamas Blummer via bitcoin-dev
 bitcoin-dev@lists.linuxfoundation.org wrote:
 Being a bitcoin software developer an entrepreneur for years I learned that 
 success is not a direct consequence of technology and is not inevitable.
 BitcoinXT manifesto 
 (https://github.com/bitcoinxt/bitcoinxt#the-xt-manifesto) should resonate 
 with many fellow entrepreneurs.
 I applaud Mike and Gavin for creating that choice for us.
 
 Tamas Blummer
 
 
 ___
 bitcoin-dev mailing list
 bitcoin-dev@lists.linuxfoundation.org
 https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
 
 



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin XT 0.11A

[Tamas Blummer via bitcoin-dev]

Being a bitcoin software developer an entrepreneur for years I learned that 
success is not a direct consequence of technology and is not inevitable.
BitcoinXT manifesto (https://github.com/bitcoinxt/bitcoinxt#the-xt-manifesto) 
should resonate with many fellow entrepreneurs.
I applaud Mike and Gavin for creating that choice for us.

Tamas Blummer



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev