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

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

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

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

[bitcoin-dev] side memory - Transient memory of an other peer to peer network controlled through the bitcoin utxo set

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

> 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

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

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

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

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

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

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

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

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

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

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

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

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

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

> 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

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

b.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 >>> participan

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

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

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

> 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

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

> 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. >>> >> >>

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

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

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

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 i

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

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

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

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

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

nomic 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 Blum

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

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

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

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

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

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

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

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,

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

> 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 investme

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

e 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.or

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

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.

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

foundation.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 pro

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

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

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

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

Re: [bitcoin-dev] Smart Contracts Unchained

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

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

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

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

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

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

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

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

rly 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 he

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

gt;> 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

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

ect 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/

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 ___

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

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: > >

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

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

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

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

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

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

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

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

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

). 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

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

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

Re: [bitcoin-dev] Bitcoin XT 0.11A

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

Re: [bitcoin-dev] Bitcoin XT 0.11A

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