Re: [bitcoin-dev] Time to lower minrelaytxfee ?

2020-08-21 Thread Nadav Ivgi via bitcoin-dev
Having large portions of the network using a different minrelayfee could
make it easier to reliably get different parts of the network to accept
different conflicting transactions into their mempools, which could
potentially be used to double-spend unconfirmed non-rbf transactions with
more ease. Node operators that accept unconfirmed payments with a
minrelayfee that's higher than what other nodes/miners are typically
accepting would be at risk.

Relying on unconfirmed transactions is of course discouraged so I'm not
sure how much weight this should be given if at all, but I thought it was
at least worth bringing up.

Nadav


On Fri, Aug 21, 2020 at 11:00 AM Dan Bryant via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> It's been 5 years since minrealytxfee was lowered.  At the time
> bitcoin was trading for $255 and it was agreed that the fee of 5000
> sat/vkB was too high.  It was lowered to 1000 sat/vkB.  In regards to
> how much anti-DoS protection that provided, it comes out to $0.00255 /
> vkB in USD terms.  To have parity with the last reduction, we would
> need to reduce minrealytxfee to 22 sat/vKB, though an even more
> conservative reduction to 100 or 50 sat/vKB would be welcome.
>
> With the growing adoption of LN, there is a need for ultra-low-fee
> on-chain TXNs.  Having these queue and confirm overnight, or even
> waiting until the Sunday lull would still probably be welcome to many
> users.  The fact that the mempool is going empty at least every week
> indicates that miners have not reached the floor of what they are
> willing to mine.
>
> About 2 years ago there was a PR (#13922) to try to make a reduction
> from 1000 to 200 sat/vkB.  It was widely accepted but the submitter
> eventually closed it in favor of PR #13990.
>
> If minrelaytxfee is already parameterized and configurable in
> bitcoin.conf, how could it be detrimental to operation of a node to
> change the default?
>
> References:
>
> *
> https://github.com/bitcoin/bitcoin/commit/9e93640be6c49fa1505ba5c5df8c89210da5a6e4
> * https://github.com/bitcoin/bitcoin/pull/13922
> * https://github.com/bitcoin/bitcoin/pull/13990
> ___
> 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] Minsc, a Miniscript-based scripting language

2020-07-29 Thread Nadav Ivgi via bitcoin-dev
Hi all,

I recently released Minsc, a high-level scripting language for expressing
Bitcoin Script spending conditions using a simple and familiar syntax.

Minsc is based on the Miniscript Policy language, with additional features
and syntactic sugar sprinkled on top, including variables, functions, infix
notation, human-readable times and more.

A live compiler (Minsc->Policy->Miniscript->Script) and documentation are
available on the website: https://min.sc

Source code (in Rust) is available on github:
https://github.com/shesek/minsc

Some example Minsc scripts:

- A user and a 2FA service need to sign off, but after 90 days the user
alone is enough

  pk(user_pk) && (9@pk(service_pk) || older(90 days))

- Traditional preimage-based HTLC

  $redeem = pk(A) && sha256(H);
  $refund = pk(B) && older(10);

  likely@$redeem || $refund

- Liquid-like federated pegin with emergency recovery keys

  $federation = 4 of [ pk(A), pk(B), pk(C), pk(D), pk(E) ];
  $recovery = 2 of [ pk(F), pk(G), pk(H) ];
  $timeout = older(heightwise 2 weeks);

  likely@$federation || ($timeout && $recovery)

- The BOLT #3 received HTLC policy

  fn htlc_received($revoke_pk, $local_pk, $remote_pk, $secret, $delay) {
$success = pk($local_pk) && hash160($secret);
$timeout = older($delay);

pk($revoke_pk) || (pk($remote_pk) && ($success || $timeout))
  }

  htlc_received(A, B, C, H, 3 hours)

- 2FA where the user has a 2-of-2 setup and the service provider is a
3-of-4 federation

  fn two_factor($user, $provider, $delay) =
$user && (likely@$provider || older($delay));

  $user = pk(user_desktop) && pk(user_mobile);
  $providers = [ pk(P1), pk(P2), pk(P3), pk(P4) ];

  two_factor($user, 3 of $providers, 4 months)

- Easily add NSA backdoors to everything ️

  _backdoor=pk(usgovt), _pk=pk, _older=older, _after=after,
  _sha256=sha256, _ripemd160=ripemd160;

  fn pk(x) = _pk(x) || _backdoor;
  fn older(x) = _older(x) || _backdoor;
  fn after(x) = _after(x) || _backdoor;
  fn sha256(x) = _sha256(x) || _backdoor;
  fn ripemd160(x) = _ripemd160(x) || _backdoor;

  (pk(A) && sha256(H)) || (pk(B) && older(10))

Feedback is appreciated!

Nadav

P.S Since every Miniscript Policy is also a valid Minsc expression, the
min.sc web code editor UI could also be useful for experimenting with bare
policies. You'll get syntax highlighting, parentheses matching, real-time
compilation (in a web worker so the browser doesn't freeze) and syntax
error reporting.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] MAD-HTLC

2020-06-25 Thread Nadav Ivgi via bitcoin-dev
Hi ZmnSCPxj,

You are of course correct. I had considered the effect of reorgs, but the
email seemed to be getting too lengthy to mention that too.

You would need a few spare blocks in which Bob won't be accused of bribery
as a safety margin, which does reduce the time frame in which Alice can get
her transaction confirmed in order to have a valid bribery fraud. This
seems workable if the time frame was long enough (over a few hours should
be sufficient, assuming we consider reorgs of over 3-4 blocks to be
unlikely), but could indeed be problematic if the time frame is already
short to begin with.

Nadav

On Thu, Jun 25, 2020 at 7:04 AM ZmnSCPxj  wrote:

> Good morning Nadav,
>
> > > I and some number of Lightning devs consider this to be sufficient
> disincentive to Bob not attacking in the first place.
> >
> > An additional disincentive could be introduced in the form of bribery
> proofs for failed attempts.
> >
> > If we assume that "honest" users of the LN protocol won't reveal their
> timelocked transactions before reaching the timelock expiry (they shouldn't
> anyway because standard full node implementations won't relay them), we can
> prove that Bob attempted bribery and failed to an outside observer by
> showing Bob's signed timelocked transaction, spending an output that was in
> reality spent by a different transaction prior to the locktime expiry,
> which should not be possible if Bob had waited.
>
>
> Unfortunately this could be subject to an inversion of this attack.
>
> Alice can wait for the timelock to expire, then bribe miners to prevent
> confirmation of the Bob timelocked transaction, getting the Alice
> hashlocked transaction confirmed.
>
> Now of course you do mention "prior to the locktime expiry" but there is
> now risk at around locktime.
>
> Particularly, "natural" orphaned blocks and short-term chainsplits can
> exist.
> Bob might see that the locktime has arrived and broadcast the signed
> timelocked transaction, then Alice sees the locktime has not yet arrived
> (due to short-term chainsplits/propagation delays) and broadcast the signed
> hashlocked transaction, then in the end the Alice side of the short-term
> chainsplit is what solidifies into reality due to random chance on which
> miner wins which block.
> Then Bob can now be accused of bribery, even though it acted innocently;
> it broadcasted the timelock branch due to a natural chainsplit but Alice
> hashlocked branch got confirmed.
>
> Additional complications can be added on top to help mitigate this edge
> case but more complex == worse in general.
> For example it could "prior to locktime expiry" can ignore a few blocks
> before the actual timelock, but this might allow Bob to mount the attack by
> initiating its bribery behavior earlier by those few blocks.
>
> Finally, serious attackers would just use new pseudonyms, the important
> thing is to make pseudonyms valuable and costly to lose, so it is
> considered sufficient that LN nodes need to have some commitment to the LN
> in the form of actual channels (which are valuable, potentially
> money-earning constructs, and costly to set up).
>
> Other HTLC-using systems, such as the "SwapMarket" being proposed by Chris
> Belcher, could use similar disincentivizing; I know Chris is planning a
> fidelity bond system for SwapMarket makers, for example, which would mimic
> the properties of LN channels (costly to set up, money-earning).
>
> Regards,
> ZmnSCPxj
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] MAD-HTLC

2020-06-25 Thread Nadav Ivgi via bitcoin-dev
> I and some number of Lightning devs consider this to be sufficient
disincentive to Bob not attacking in the first place.

An additional disincentive could be introduced in the form of bribery
proofs for failed attempts.

If we assume that "honest" users of the LN protocol won't reveal their
timelocked transactions before reaching the timelock expiry (they shouldn't
anyway because standard full node implementations won't relay them), we can
prove that Bob attempted bribery and failed to an outside observer by
showing Bob's signed timelocked transaction, spending an output that was in
reality spent by a different transaction prior to the locktime expiry,
which should not be possible if Bob had waited.

These proofs would be gossiped, and lightning network participants could
choose not to peer with Bob when they see them. This might require some
sort of a scoring/reputation scheme that makes it harder for Bob to attack
with new throw-away identities to be effective. (i.e. limiting your
exposure to peers to some BTC amount based on their historical public
channels records, using fidelity bonds, etc.)

Bob could still send these bribery transactions privately to selected
miners, but not making them public would greatly reduce the participating
miners' confidence that there is enough participating hashpower for the
attack to be profitable.

Nadav

On Thu, Jun 25, 2020 at 4:38 AM ZmnSCPxj via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Good morning Stanga et al,
>
>
> > > Hi ZmnSCPxj,
> > >
> > > Thank you for taking the time to respond, these are very good points.
> Responses inline.
> > >
> > > On Tue, Jun 23, 2020 at 12:48 PM ZmnSCPxj 
> wrote:
> > >
> > > > Good morning Itay, Ittay, and Matan,
> > > >
> > > > I believe an unstated assumption in Bitcoin is that miners are
> short-sighted.
> > > >
> > > > The reasoning for this assumption is:
> > > >
> > > > * Deployment of new mining hardware controlled by others may occur
> at any time you do not control.
> > > >   * Thus, any transactions you leave on the table are potentially
> taken by somebody else and not by you.
> > > >   * Sudden changes in hashpower distribution may reduce your
> expected future earnings, so any future theoretical earnings should be
> discounted (*in addition to* expected return-on-investment on getting money
> you can invest *now*).
> > >
> > > Our analysis assumes constant difficulty, i.e., no significant changes
> of the miners set. Indeed, hash-rate changes typically occur at a much
> larger granularity than your average HTLC timeout. For instance, we noticed
> plenty of lightning nodes use timeouts of a day. So, we do not consider
> optimization at infinity, just a day ahead, and within this time frame all
> the factors you mentioned are not expected to dramatically change.
> > >
> > > That being said, it would be interesting to analyze the effect of
> miners joining during the HTLC duration. Intuitively, this shouldn’t affect
> the results, as those new miners have the same incentive to wait for the
> higher-paying tx.
>
> We already know that hashrate tends to trend upwards, and that we do not
> expect hashrate to fall except for occasional transients.
>
> The expectation is not that new miners have different incentives.
> Instead, the expectation is that current miners discount future possible
> gains because in the future, they expect to have less hashrate share than
> right now.
>
> The only trustless way for Bob to bribe miners into deferring Alice tx is
> to attach the bribe to the future confirmation of the Bob tx, thus Bob is
> offering future-coins, not present-coins like Alice can offer, and the fact
> that miners expect an overall uptrend in total hashrate (leading to an
> overall downtrend in their hashrate share) means that miners discount the
> Bob offered future-coins.
> The discounting is proportional to the time delay involved, as a larger
> delay implies greater reduction in hashrate share.
>
> This discounting is, again, *in addition to* natural discounting a.k.a. "I
> will gladly pay you Thursday for a hamburger today", the hamburger seller
> will want some pretty stiff assurances plus a bigger payment on Thursday
> for giving you a hamburger today, due to expected returns on investment.
>
>
> > >
> > >
> > > > It also strikes me that, in a world with RBF and CPFP, the same
> endpoint (i.e. miners earn the entire fund of the HTLC) is achieved by
> existing HTLCs, without the additional branch and script opcodes needed by
> MAD-HTLC.
> > > > For example, if an HTLC is confirmed but the hashlock-claiming
> transaction is not being confirmed (because miners are holding it up
> because Bob is offering a much higher fee in the future for the
> timelock-claiming transaction), then Alice can, regardless of the reason
> why it is not being confirmed, bump up the fee with RBF or CPFP.
> > > >
> > > > If the fee bump offered by Alice is sufficiently large, then miners
> will start re-preferring 

Re: [bitcoin-dev] Announcing Bitcoin Wallet Tracker

2020-06-01 Thread Nadav Ivgi via bitcoin-dev
Hi Antoine,

I designed both APIs, so they definitely do share some similarities.

It's difficult to compare their performance directly, since
esplora-electrs keeps a full index of everything, while bwt tracks
your wallet addresses only.

If you're only interested in your wallet addresses and don't have a
*really* huge number of them, bwt will definitely perform better, as
it can avoid a lot of unnecessary indexing work. If you do have a lot
of addresses, esplora-electrs will be better suited for the job, as
its designed to deal with high volumes of data and does not rely on
the bitcoind wallet functionality, which was not designed for this.

I'm not sure where the line for "really huge" crosses exactly though,
I have not put this to the test. Definitely if you're tracking
millions of addresses, probably also for hundreds of thousands,
possibly even less?

API design wise, the main differences between the two are:

- Esplora provides every bit of information one might want to know
about transactions/blocks, while bwt intentionally tries to reduce
this to the subset useful in the context of app development.

- bwt provides wallet-contextual information, like key origins next to
addresses and the net change inflicted on the wallet's balance by
transactions.

- Esplora doesn't provide real-time updates (yet), while bwt provides
them using two different mechanisms (SSE and Web Hooks).

Nadav



On Sun, May 31, 2020 at 5:56 PM darosior  wrote:
>
> Hi,
>
> I gave a quick look to the http API, and it seems very similar to Esplora's. 
> So I wonder : how does
> bwt compares to Esplora, performance-wise ?
>
> Thanks!
> Antoine
>
>
> ‐‐‐ Original Message ‐‐‐
> Le samedi, mai 30, 2020 4:16 PM, Nadav Ivgi via bitcoin-dev 
>  a écrit :
>
> Hi all,
>
> I recently released bwt [0], an HD wallet indexer implemented in Rust, using
> a model similar to that of Electrum Personal Server.
>
> It uses the bitcoind wallet functionality to do the heavy lifting and builds
> additional indexes on top of that, which can be queried using the Electrum
> RPC protocol, as well as a more modern, developer-friendly HTTP REST API.
>
> The electrum server can also be used as an electrum plugin [1], which
> integrates the server straight into the electrum client. From the user's
> perspective, this allows connecting electrum directly to a full node.
>
> The HTTP API is my take on a modern design for a wallet tracking API aimed
> at app developers. Some use-cases include using it as a backend for wallets
> (similarly to Samuari's Dojo) or to track deposits to a watch-only xpub
> (similarly to BTCPay's NBXplorer).
>
> Compared to using the bitcoind RPC directly, bwt provides:
>
> - The ability to track an xpub and automatically have new addresses derived
>   and imported as needed, according to the gap limit.
>
> - Two additional indexes, one for looking up the transaction history of
>   addresses, and another one for looking up txo spends (a map of
>   funding_txid:vout => spending_txid:vin).
>
> - Real-time updates using Server-Sent Events [2] (a long-lived streaming HTTP
>   connection) or Web Hooks [3] (an HTTP request sent to a configured URL).
>   The updates being sent [4] directly provide information about the funded
>   and spent wallet txos, instead of the client figuring it out from the tx.
>
> - Some API conveniences and simplifications, like including key origin
>   information directly alongside inputs/outputs [5], the ability to specify
>   key origins in place of addresses (eg. GET /hd/15cb9edc/8/utxos), a compact
>   history format [6], and an easy way to catch-up with missed events [7].
>   Unless explicitly asked for, the API omits information about non-wallet
>   inputs/outputs and protocol-level details like scriptsig and witnesses,
>   which are typically not needed for higher-level app development.
>
> The indexer is designed in a way that minimizes RPC requests to bitcoind. By
> using labels to store key origin information, it is able to index incoming
> transactions using the information available from `listtransactions` alone
> (plus 3 extra rpc requests that don't grow with the number of transactions),
> but requires 1 additional rpc call per outgoing transaction (to learn which
> prevouts were spent). It can index 10k incoming txs in under a second, or a
> mixture of 5k/5k in under 5 seconds. The index is currently entirely in-
> memory and does not get persisted. The indexer logic can be seen in [8].
>
> One major item on the roadmap that I'm hoping to tackle soon is support for
> output script descriptors.
>
> If anyone is interested in contributing, the README has some useful developer
> resources [9] and a handy script for setting up a development environment.
>
> This is an earl

[bitcoin-dev] Announcing Bitcoin Wallet Tracker

2020-05-30 Thread Nadav Ivgi via bitcoin-dev
Hi all,

I recently released bwt [0], an HD wallet indexer implemented in Rust, using
a model similar to that of Electrum Personal Server.

It uses the bitcoind wallet functionality to do the heavy lifting and builds
additional indexes on top of that, which can be queried using the Electrum
RPC protocol, as well as a more modern, developer-friendly HTTP REST API.

The electrum server can also be used as an electrum plugin [1], which
integrates the server straight into the electrum client. From the user's
perspective, this allows connecting electrum directly to a full node.

The HTTP API is my take on a modern design for a wallet tracking API aimed
at app developers. Some use-cases include using it as a backend for wallets
(similarly to Samuari's Dojo) or to track deposits to a watch-only xpub
(similarly to BTCPay's NBXplorer).

Compared to using the bitcoind RPC directly, bwt provides:

- The ability to track an xpub and automatically have new addresses derived
  and imported as needed, according to the gap limit.

- Two additional indexes, one for looking up the transaction history of
  addresses, and another one for looking up txo spends (a map of
  funding_txid:vout => spending_txid:vin).

- Real-time updates using Server-Sent Events [2] (a long-lived streaming
HTTP
  connection) or Web Hooks [3] (an HTTP request sent to a configured URL).
  The updates being sent [4] directly provide information about the funded
  and spent wallet txos, instead of the client figuring it out from the tx.

- Some API conveniences and simplifications, like including key origin
  information directly alongside inputs/outputs [5], the ability to specify
  key origins in place of addresses (eg. GET /hd/15cb9edc/8/utxos), a
compact
  history format [6], and an easy way to catch-up with missed events [7].
  Unless explicitly asked for, the API omits information about non-wallet
  inputs/outputs and protocol-level details like scriptsig and witnesses,
  which are typically not needed for higher-level app development.

The indexer is designed in a way that minimizes RPC requests to bitcoind. By
using labels to store key origin information, it is able to index incoming
transactions using the information available from `listtransactions` alone
(plus 3 extra rpc requests that don't grow with the number of transactions),
but requires 1 additional rpc call per outgoing transaction (to learn which
prevouts were spent). It can index 10k incoming txs in under a second, or a
mixture of 5k/5k in under 5 seconds. The index is currently entirely in-
memory and does not get persisted. The indexer logic can be seen in [8].

One major item on the roadmap that I'm hoping to tackle soon is support for
output script descriptors.

If anyone is interested in contributing, the README has some useful
developer
resources [9] and a handy script for setting up a development environment.

This is an early alpha release, recommended for use with testnet/regtest.

All feedback welcome!

Cheers,
Nadav

[0] https://github.com/shesek/bwt
[1] https://github.com/shesek/bwt#electrum-plugin
[2] https://github.com/shesek/bwt#server-sent-events
[3] https://github.com/shesek/bwt#web-hooks
[4] https://github.com/shesek/bwt#event-categories
[5] https://github.com/shesek/bwt#wallet-transaction-format
[6] https://github.com/shesek/bwt#get-txssinceblock-heightcompact
[7]
https://github.com/shesek/bwt#catching-up-with-missed-events--re-org-detection
[8] https://github.com/shesek/bwt/blob/master/src/indexer.rs
(sync_transactions and load_transactions_since)
[9] https://github.com/shesek/bwt#developing
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev