Re: [bitcoin-dev] Package Relay Proposal

2022-05-17 Thread Greg Sanders via bitcoin-dev
Hi Gloria,

Thanks for working on this important proposal!

Still a lot to digest, but I just had on area of comment/question:

> A child-with-unconfirmed-parents package sent between nodes must abide by
the rules below, otherwise the package is malformed and the sender should
be disconnected.

> However, if the child has confirmed parents, they must not be in the
package.

If my naive understanding is correct, this means things like otherwise
common situations such as a new block will result in disconnects, say when
the sender doesn't hear about a new block which makes the relay package
superfluous/irrelevant. Similar would be disconnection
when confirmed gets turned into unconfirmed, but those situations are
extremely uncommon. The other rules are entirely under the control
of the sender, which leads me to wonder if it's appropriate.

Cheers,
Greg

On Tue, May 17, 2022 at 12:09 PM Gloria Zhao via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi everybody,
>
> I’m writing to propose a set of p2p protocol changes to enable package
> relay, soliciting feedback on the design and approach. Here is a link
> to the most up-to-date proposal:
>
> https://github.com/bitcoin/bips/pull/1324
>
> If you have concept or approach feedback, *please respond on the
> mailing list* to allow everybody to view and participate in the
> discussion. If you find a typo or inaccurate wording, please feel free
> to leave suggestions on the PR.
>
> I’m also working on an implementation for Bitcoin Core.
>
>
> The rest of this post will include the same contents as the proposal,
> with a bit of reordering and additional context. If you are not 100%
> up-to-date on package relay and find the proposal hard to follow, I
> hope you find this format more informative and persuasive.
>
>
> ==Background and Motivation==
>
> Users may create and broadcast transactions that depend upon, i.e.
> spend outputs of, unconfirmed transactions. A “package” is the
> widely-used term for a group of transactions representable by a
> connected Directed Acyclic Graph (where a directed edge exists between
> a transaction that spends the output of another transaction).
>
> Incentive-compatible mempool and miner policies help create a fair,
> fee-based market for block space. While miners maximize transaction
> fees in order to earn higher block rewards, non-mining users
> participating in transaction relay reap many benefits from employing
> policies that result in a mempool with the same contents, including
> faster compact block relay and more accurate fee estimation.
> Additionally, users may take advantage of mempool and miner policy to
> bump the priority of their transactions by attaching high-fee
> descendants (Child Pays for Parent or CPFP).  Only considering
> transactions one at a time for submission to the mempool creates a
> limitation in the node's ability to determine which transactions have
> the highest feerates, since it cannot take into account descendants
> until all the transactions are in the mempool. Similarly, it cannot
> use a transaction's descendants when considering which of two
> conflicting transactions to keep (Replace by Fee or RBF).
>
> When a user's transaction does not meet a mempool's minimum feerate
> and they cannot create a replacement transaction directly, their
> transaction will simply be rejected by this mempool. They also cannot
> attach a descendant to pay for replacing a conflicting transaction.
> This limitation harms users' ability to fee-bump their transactions.
> Further, it presents a security issue in contracting protocols which
> rely on **presigned**, time-sensitive transactions to prevent cheating
> (HTLC-Timeout in LN Penalty [1] [2] [3], Unvault Cancel in Revault
> [4], Refund Transaction in Discreet Log Contracts [5], Updates in
> eltoo [6]). In other words, a key security assumption of many
> contracting protocols is that all parties can propagate and confirm
> transactions in a timely manner.
>
> In the past few years, increasing attention [0][1][2][3][6] has been
> brought to **pinning attacks**, a type of censorship in which the
> attacker uses mempool policy restrictions to prevent a transaction
> from being relayed or getting mined.  TLDR: revocation transactions
> must meet a certain confirmation target to be effective, but their
> feerates are negotiated well ahead of broadcast time. If the
> forecasted feerate was too low and no fee-bumping options are
> available, attackers can steal money from their counterparties. I walk
> through a concrete example for stealing Lightning HTLC outputs at
> ~23:58 in this talk [7][8].  Note that most attacks are only possible
> when the market for blockspace at broadcast time  demands much higher
> feerates than originally anticipated at signing time. Always
> overestimating fees may sidestep this issue temporarily (while mempool
> traffic is low and predictable), but this solution is not foolproof
> and wastes users' money. The feerate 

Re: [bitcoin-dev] Improving BIP 8 soft fork activation

2022-05-12 Thread Greg Sanders via bitcoin-dev
I think you may be confused. Mandatory signaling is not the same thing as
mandatory activation on timeout, aka Lock On Timeout aka LOT=true.

These are two related but separate things.

On Thu, May 12, 2022, 6:53 PM alicexbt via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi Russell,
>
>
> As far as I understand things, I believe the whole notion of a MUST_SIGNAL
> state is misguided today. Please correct me if I'm misunderstanding
> something here.
>
> Back when BIP8 was first proposed by Shaolin Fry, we were in a situation
> where many existing clients waiting for segwit signalling had already been
> deployed. The purpose of mandatory signaling at that point in time was to
> ensure all these existing clients would be activated together with any BIP8
> clients.
>
>
> I won't consider it misguided. Not using MUST_SIGNAL gives opportunity for
> drama and politics during signaling. MUST_SIGNAL phase is initiated when
> height + 2016 >= timeoutheight and if a mining pool is still not sure about
> signaling at that point, maybe they are not interested in mining bitcoin
> anymore.
>
> Rephrasing 'motivation' section in BIP 8:
>
> BIP 9 activation is dependent on near unanimous hashrate signaling which
> may be impractical and result in veto by a small minority of
> non-signaling hashrate. All consensus rules are ultimately enforced by full
> nodes, eventually any new soft fork will be enforced by the economy. BIP 8
> provides optional flag day activation after a reasonable time, as well as
> for accelerated activation by majority of hash rate before the flag date.
>
> We also don't need such a signal span over multiple blocks. Indeed, using
> version bits and signaling over multiple blocks is quite bad because it
> risks losing mining power if miners don't conform, or are unable to
> conform, to the version bits signal. (Recall at the time taproot's
> signaling period started, the firmware needed for many miners to signal
> version bits did not even exist yet!).
>
>
> Solutions to these problems:
>
> 1)Developers plan and ship the binaries with activation code in time.
> 2)Mining pools pay attention, participate in soft fork discussions, hire
> competent developers and reach out to developers in community if require
> help.
> 3)Mining pools understand the loss involved in mining invalid blocks and
> upgrade during the first month of signaling.
>
> If some mining pools still mine invalid blocks, Bitcoin should still work
> normally as it did during May-June 2021 when 50% hashrate went down due to
> some issues in China.
>
>
> /dev/fd0
>
> Sent with ProtonMail  secure email.
>
> --- Original Message ---
> On Thursday, May 12th, 2022 at 12:52 AM, Russell O'Connor via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Hi alicexbt,
>
> As far as I understand things, I believe the whole notion of a MUST_SIGNAL
> state is misguided today. Please correct me if I'm misunderstanding
> something here.
>
> Back when BIP8 was first proposed by Shaolin Fry, we were in a situation
> where many existing clients waiting for segwit signalling had already been
> deployed. The purpose of mandatory signaling at that point in time was to
> ensure all these existing clients would be activated together with any BIP8
> clients.
>
> However, if such other clients do not exist, the MUST_SIGNAL state no
> longer accomplishes its purpose. Going forward, I think there is little
> reason to expect such other clients to exist alongside a BIP8 deployment.
> If everyone uses a BIP8 deployment, then there are no other clients to
> activate. Alternatively, Speedy Trial was specifically designed to avoid
> this parallel deployment for the reason that several people object to
> allowing their client's non-BIP8 activation logic to be hijacked in this
> manner.
>
> Now I understand that some people would like *some* signal on the chain
> that indicates a soft-fork activation in order to allow people who object
> to the fork to make an "anti-fork" that rejects blocks containing the
> soft-fork signal. And while some sort of mandatory version bit signaling
> *could* be used for this purpose, we do not *have* to use version bits. We
> also don't need such a signal span over multiple blocks. Indeed, using
> version bits and signaling over multiple blocks is quite bad because it
> risks losing mining power if miners don't conform, or are unable to
> conform, to the version bits signal. (Recall at the time taproot's
> signaling period started, the firmware needed for many miners to signal
> version bits did not even exist yet!).
>
> A soft-fork signal to enable an "anti-fork" only needs to be on a single
> block and it can be almost anything. For example we could have a signal
> that at the block at lockin or perhaps the block at activation requires
> that the coinbase must *not* contain the suffix "taproot sucks!". This
> suffices to prepare an "anti-fork" which would simply require that 

Re: [bitcoin-dev] Bringing a nuke to a knife fight: Transaction introspection to stop RBF pinning

2022-05-12 Thread Greg Sanders via bitcoin-dev
Great point in this specific case I unfortunately didn't consider! So
basically the design degenerates to the last option I gave, where the
counterparty
can send off N(25) weight-bound packages.

A couple thoughts:

0) Couldn't we relative-time lock update transactions's state input by 1
block as well to close the vector off? People are allowed
one "update transaction package" at a time in mempool, so if detected
in-mempool it can be RBF'd, or in-block can be immediately responded to.
1) other usages of ANYONECANPAY like behavior may not have these issues,
like vault structures.


On Thu, May 12, 2022, 3:17 AM David A. Harding  wrote:

> On 2022-05-10 08:53, Greg Sanders via bitcoin-dev wrote:
> > We add OPTX_SELECT_WEIGHT(pushes tx weight to stack, my addition to
> > the proposal) to the "state" input's script.
> > This is used in the update transaction to set the upper bound on the
> > final transaction weight.
> > In this same input, for each contract participant, we also
> > conditionally commit to the change output's scriptpubkey
> > via OPTX_SELECT_OUTPUT_SCRIPTPUBKEY and OPTX_SELECT_OUTPUTCOUNT==2.
> > This means any participant can send change back
> > to themselves, but with a catch. Each change output script possibility
> > in that state input also includes a 1 block
> > CSV to avoid mempool spending to reintroduce pinning.
>
> I like the idea!   However, I'm not sure the `1 CSV` trick helps much.
> Can't an attacker just submit to the mempool their other eltoo state
> updates?  For example, let's assume Bob and Mallory have a channel with
>  >25 updates and Mallory wants to prevent update[-1] from being committed
> onchain before its (H|P)TLC timeout.  Mallory also has at least 25
> unencumbered UTXOs, so she submits to the mempool update[0], update[1],
> update[...], update[24]---each of them with a different second input to pay
> fees.
>
> If `OPTX_SELECT_WEIGHT OP_TX` limits each update's weight to 1,000
> vbytes[1] and the default node relay/mempool policy of allowing a
> transaction and up to 24 descendants remains, Mallory can pin the
> unsubmitted update[-1] under 25,000 vbytes of junk---which is 25% of
> what she can pin under current mempool policies.
>
> Alice can't RBF update[0] without paying for update[1..24] (BIP125 rule
> #3), and an RBF of update[24] will have its additional fees divided by
> its size plus the 24,000 vbytes of update[1..24].
>
> To me, that seems like your proposal makes escaping the pinning at most
> 75% cheaper than today.  That's certainly an improvement---yay!---but
> I'm not sure it eliminates the underlying concern.  Also depending on
> the mempool ancestor/descendant limits makes it harder to raise those
> limits in the future, which is something I think we might want to do if
> we can ensure raising them won't increase node memory/CPU DoS risk.
>
> I'd love to hear that my analysis is missing something though!
>
> Thanks!,
>
> -Dave
>
> [1] 1,000 vbytes per update seems like a reasonable value to me.
> Obviously there's a tradeoff here: making it smaller limits the amount
> of pinning possible (assuming mempool ancestor/descendant limits remain)
> but also limits the number and complexity of inputs that may be added.
> I don't think we want to discourage people too much from holding
> bitcoins in deep taproot trees or sophisticated tapscripts.
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


[bitcoin-dev] Bringing a nuke to a knife fight: Transaction introspection to stop RBF pinning

2022-05-10 Thread Greg Sanders via bitcoin-dev
Hello devs,

I've had this thought rattling around and thought it was worth putting to a
wider audience since
I haven't really seen it in other contexts. I've been working on eltoo
designs for Elements and
eventual inclusion into Bitcoin. With that in mind there's been a
reasonable amount of discussion
on the remaining unknowns on how well eltoo could work. To me the biggest
issue is BIP125 rule#3.

To quote:"The replacement transaction pays an absolute fee of at least the
sum paid by the original
transactions."

In the ANYONECANPAY-like scenarios like eltoo that require "bring your own
fees", this essentially
means the counterparty(or anyone, if you don't include chaperone sigs[0])
can post a series of low
feerate update transactions, or the final update, with bloated
inputs/outputs(depending on flags),
and this results in illicit HTLC timeouts as the channel is unable to be
settled in time, unless you fork
over quite a few sats. This is a problem in both "vanilla" eltoo[1] from
the original paper, as well as the
"layered commitments" style of eltoo[2]. This problem is highly reminiscent
of the ANYONECANPAY
pinning that others have discussed for vaults and other usecases, in that
anyone can include new
inputs(and sometimes outputs) to make the overall feerate lower. To
promptly get the final transactions
settled, you are forced to over-pay, and essentially refund your griefing
counterparty by knocking their
inputs out of the mempool.

Fixing BIP125 rule#3 would be great. It's also a while out at a minimum.

There are thoughts on how to mitigate some cases[3] of this pinning using
policy, and could be extended
to cover this particular pinning case(restrict both transaction weight AND
the weight of the descendant
package, or maybe just include the txns weight in the original idea?). This
might be the simplest idea,
if it ends up being deemed incentive compatible and deployed.

In case the above is not incentive compatible, we can use more drastic
measures. Another tactic would
be to use transaction introspection opcodes to smooth around these policy
issues.

Elements has its own set of transaction introspection codes[4], but fairly
standard introspection codes
seem to be sufficient.

This example is using Rusty's quite recent OP_TX proposal[5] with a single
extension but as mentioned
before it's all fairly standard. The actual eltoo-enabling opcode
implementation is basically orthogonal
to this problem, so I'm simply focusing on restricting the size of the
transaction package being
submitted to mempools.

For simplicity of a working example, we'll assume a set of "state" outputs
that are continuously being spent
off-chain and sent to a committed set of outputs. In vanilla eltoo case
this corresponds to the first
input and output you typically see in diagrams. The state transitions
include no fees themselves,
sending inputs of sum value N to outputs that sum to the value of N.
Vanilla eltoo uses SIGHASH_SINGLE
to bind just the first input/ouput pair. To post on-chain, we will need to
include at least one input,
and likely an output for change.

We add OPTX_SELECT_WEIGHT(pushes tx weight to stack, my addition to the
proposal) to the "state" input's script.
This is used in the update transaction to set the upper bound on the final
transaction weight.
In this same input, for each contract participant, we also conditionally
commit to the change output's scriptpubkey
via OPTX_SELECT_OUTPUT_SCRIPTPUBKEY and OPTX_SELECT_OUTPUTCOUNT==2. This
means any participant can send change back
to themselves, but with a catch. Each change output script possibility in
that state input also includes a 1 block
CSV to avoid mempool spending to reintroduce pinning. This allows the
change value to be anything, contra to
what SIGHASH_ALL would give you instead.

With this setup, you can't CPFP-spend the fee change outputs you create,
but you can RBF as much as
you'd like by RBFing at higher feerates, using any number of inputs you'd
like provided the total tx
weight doesn't exceed the OPTX_SELECT_WEIGHT argument.

With more engineering we can re-enable CPFP of this change output as well.
Handwaves here, but we could
encumber change outputs to either the aformentioned 1 block CSV encumbered
outputs or one to another
OPTX_SELECT_WEIGHT, recursively. This would allow each counterparty to CPFP
N times, each transaction
a maximum weight, and use the 1 block CSV as an "escape hatch" to get their
fee output back out from
the covenant structure. We could mix and match strategies here as well
allowing bigger transactions at
each step, or more steps. I suspect you'd want a single weight-bound CPFP
that can later be RBF'd any
number of times under this same weight limit.

TL;DR: Mempool is hard, let's use transaction weight, output count, and
output scriptpubkey,
and ??? introspection to avoid solving life's hard problems.

0:
https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-May/001994.html
1: https://blockstream.com/eltoo.pdf
2:

Re: [bitcoin-dev] ANYPREVOUT in place of CTV

2022-04-30 Thread Greg Sanders via bitcoin-dev
The proposed use case for the ANYSCRIPT part of APOAS explicitly doesn't
commit to amount, so I'd also assume it not be re-added or at least be able
to be opened out.

On Sat, Apr 30, 2022, 4:47 AM Nadav Ivgi via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi darosior,
>
> It's interesting to note that APOAS|SINGLE (with the ANYONECANPAY
> behaviour and without covering the spent input index) has some interesting
> uses for cases where the covenant only needs to restrict a single output
> (so useful for e.g. vaults or spacechains, but not for batch channels or
> congestion control).
>
> For example in the vault use-case, it makes it possible to bump fees on
> the unvault tx by adding more inputs and a change output, as well as
> unvault multiple vaulted outputs in a single transaction.
>
> For spacechains, it makes it possible to add the spaceblock hash OP_RETURN
> and pay fees directly in the tx chain, instead of having to use an
> additional tx to prepare an output that gets spent in the tx chain  (see
> the diagram in [0]).
>
> > via `sha_sequences` and maybe also `sha_amounts`
>
> CTV does not commit to the input amounts. This has some practical
> implications:
>
> 1. If it is committed, sending an even slightly incorrect amount will make
> the covenant-encumbered spend path unusable.
>
> With CTV, sending a slightly lower amount results in slightly lower fees,
> while any extra gets spent/burned on fees. The covenant spend path only
> becomes unusable if the amount is too low to cover for the outputs (+relay
> fee for it to also be standard).
>
> 2. The ability to allow for additional inputs with unknown amounts makes
> it possible to fee-bump the covenant spending transaction (with whole utxos
> and no change). You can have one tapleaf for spending the covenant output
> alone, and another one for attaching an extra fee input to it.
>
> This also makes it possible to resolve the under-payment issue described
> in (1), by adding an input that covers the original intended amount.
>
> So my suggestion would be to either not cover `sha_amounts` in the msg
> hash, or to make it optional behind a flag.
>
> shesek
>
> [0] https://github.com/fiatjaf/simple-ctv-spacechain
>
> On Fri, Apr 22, 2022 at 2:23 PM darosior via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> I would like to know people's sentiment about doing (a very slightly
>> tweaked version of) BIP118 in place of
>> (or before doing) BIP119.
>>
>> SIGHASH_ANYPREVOUT and its precedent iterations have been discussed for
>> over 6 years. It presents proven and
>> implemented usecases, that are demanded and (please someone correct me if
>> i'm wrong) more widely accepted than
>> CTV's.
>>
>> SIGHASH_ANYPREVOUTANYSCRIPT, if its "ANYONECANPAY" behaviour is made
>> optional [0], can emulate CTV just fine.
>> Sure then you can't have bare or Segwit v0 CTV, and it's a bit more
>> expensive to use. But we can consider CTV
>> an optimization of APO-AS covenants.
>>
>> CTV advocates have been presenting vaults as the flagship usecase.
>> Although as someone who've been trying to
>> implement practical vaults for the past 2 years i doubt CTV is necessary
>> nor sufficient for this (but still
>> useful!), using APO-AS covers it. And it's not a couple dozen more
>> virtual bytes that are going to matter for
>> a potential vault user.
>>
>> If after some time all of us who are currently dubious about CTV's stated
>> usecases are proven wrong by onchain
>> usage of a less efficient construction to achieve the same goal, we could
>> roll-out CTV as an optimization.  In
>> the meantime others will have been able to deploy new applications
>> leveraging ANYPREVOUT (Eltoo, blind
>> statechains, etc..[1]).
>>
>>
>> Given the interest in, and demand for, both simple covenants and better
>> offchain protocols it seems to me that
>> BIP118 is a soft fork candidate that could benefit more (if not most of)
>> Bitcoin users.
>> Actually i'd also be interested in knowing if people would oppose the
>> APO-AS part of BIP118, since it enables
>> CTV's features, for the same reason they'd oppose BIP119.
>>
>>
>> [0] That is, to not commit to the other inputs of the transaction (via
>> `sha_sequences` and maybe also
>> `sha_amounts`). Cf
>> https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki#signature-message
>> .
>>
>> [1] https://anyprevout.xyz/ "Use Cases" section
>> ___
>> 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 mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] 7 Theses on a next step for BIP-119

2022-04-21 Thread Greg Sanders via bitcoin-dev
Ironically assumptions of bad faith are going to kill any proposal,
resulting in the status quo.

Let's keep the assumption of good faith, unless you are actually accusing
people of being a NSA-adjacent asset.

On Thu, Apr 21, 2022 at 10:08 AM alicexbt via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> There are a number of individuals who have stated opposition to attempting
> to activate a CTV soft fork in the near term:
>
> https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718
>
>
> sheshek found some issues with the list and some of them are not really an
> opposition for CTV. Others do not have any technical details to consider.
>
> The saddest thing is that if Jeremy's soft fork activation attempt causes
> the uncertainty, confusion and disruption I fear it could it will make
> future soft forks that do have community consensus orders of magnitude
> harder to pull off.
>
>
>
> Calling CTV an attack on bitcoin or doing personal attacks on Jeremy and
> other developers on social media that support CTV won't help. Developers
> should be free to propose improvements and write code. Users can decide if
> they want to run this code. Just because someone is opposing a change and
> prefers status quo does not mean it is better for Bitcoin. Attackers have
> used such things in past for many open source projects.
>
> Example: Someone signed up on the Tor Project mailing list and then
> participated in discussions to advocate against the removal of malicious
> servers
>
> https://nitter.net/campuscodi/status/1466748897003544579
>
>
> dev/fd0
>
> Sent with ProtonMail  secure email.
>
> --- Original Message ---
> On Wednesday, April 20th, 2022 at 6:54 PM, Michael Folkson via bitcoin-dev
>  wrote:
>
> > The client has a Speedy trial release similar to Taproots with
> parameters proposed to be
>
> As I've said before I was hoping we'd avoid this exercise. Best case, it
> wastes the time of people who could be working on all sorts of valuable
> projects for the ecosystem. Worst case, we take a Russian roulette style
> gamble with a chain split.
>
> But here's a summary of the basic facts:
>
> The latest Bitcoin Core release candidate (23.0) does not contain any new
> soft fork code, either CTV code or any new activation code. Running Bitcoin
> Core 23.0 out the box will not signal for any new soft fork and will not
> enforce any new soft fork rules (CTV or otherwise). Of course it will
> continue to enforce Taproot rules as Taproot activated last year.
>
> There are a number of individuals who have stated opposition to attempting
> to activate a CTV soft fork in the near term:
>
> https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718
>
> Most of those individuals haven't logged their opposition on Jeremy's site:
> https://utxos.org/signals/
>
> Hence their views haven't been included or discussed in Jeremy's latest
> blog post.
>
> Chain split risk
>
> I can't predict how many full nodes and miners will run Jeremy's client
> attempting to activate CTV. One would expect that many will continue to run
> versions of Bitcoin Core that will not enforce CTV rules and will not
> activate it. But whether Jeremy's client will be a majority, significant
> minority, insignificant minority of full nodes and miners would be
> speculation on my part. (Personally I highly doubt those running Jeremy's
> client will be a majority which leaves a significant minority and
> insignificant minority as the most likely options).
>
> Jeremy's client is intending to use Speedy Trial presumably with similar
> parameters to that used for Taproot. That would mean seeking 90 percent of
> miners to signal for this CTV soft fork activation attempt.
>
> Assuming 90 percent of miners don't signal for it in one of the Speedy
> Trial windows then the activation attempt will have failed and it will be
> back in Jeremy's court whether he tries again with a different activation
> attempt.
>
> Assuming 90 percent of miners do signal for it (unlikely in my opinion but
> presumably still a possibility) then the CTV soft fork could activate
> unless full nodes resist it. This resistance would most likely be in the
> form of a UASF style client which rejects blocks that apply the CTV rules
> and/or includes transactions that don't meet the CTV rules post activation.
> We would now be in chain split territory with two different assets and
> blockchains like we had with BTC and BCH.
>
> If I oppose this activation attempt and the associated chain split risk
> what should I do?
>
> Firstly, you can register your opposition to this soft fork activation
> attempt on Jeremy's site: https://utxos.org/signals/
>
> It seems Jeremy will continue this activation attempt regardless but it
> will be useful for others to see clearly that this a contentious soft fork
> activation attempt and act accordingly. So far only 3 individuals'
> opposition is registered on his site.
>
> 

Re: [bitcoin-dev] `OP_EVICT`: An Alternative to `OP_TAPLEAFUPDATEVERIFY`

2022-02-18 Thread Greg Sanders via bitcoin-dev
> One point of discomfort I have with Eltoo that I think is not universal,
but is shared by some others, is that non-punitive channels may not be good
for high-value channels as you do want, especially in a congested
blockspace world, punishments to incentivize correct behavior (otherwise
cheating may look like a free option).

Without derailing the conversation too far, "fully" punitive channels also
make large value channels more dangerous from the perspective of bugs
causing old states to be published. High value channels you'll need to have
very high uptime. If you're available, your counterparty is incentivized to
do a mutual close to reduce fees and remove timelocks on outputs. I think
these tradeoffs will result in both types existing for N==2.

On Sat, Feb 19, 2022 at 8:56 AM Jeremy Rubin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> This is a fascinating post and I'm still chewing on it.
>
> Chiming in with two points:
>
> Point 1, note with respect to evictions, revivals, CTV, TLUV:
>
> CTV enables 1 person to be evicted in O(log N) or one person to leave in
> O(log N). TLUV enables 1 person to leave in O(1) O(log N) transactions, but
> evictions take (AFAICT?) O(N) O(log N) transactions because the un-live
> party stays in the pool. Hence OP_EVICT helps also make it so you can kick
> someone out, rather than all having to leave, which is an improvement.
>
> CTV rejoins work as follows:
>
> suppose you have a pool with 1 failure, you need to do log N txns to evict
> the failure, which creates R * log_R(N) outputs, which can then do a
> transaction to rejoin.
>
> For example, suppose I had 64 people in a radix 4 tree. you'd have at the
> top level 4 groups of 16, then 4 groups of 4 people, and then 1 to 4 txns.
> Kicking 1 person out would make you do 3 txns, and create 12 outputs total.
> A transaction spending the 11 outputs that are live would capture 63 people
> back into the tree, and with CISA would not be terribly expensive. To be a
> bit more economical, you might prefer to just join the 3 outputs with 16
> people in it, and yield 48 people in one pool. Alternatively, you can
> lazily re-join if fees make it worth it/piggybacking another transaction,
> or operate independently or try to find new, better, peers.
>
> Overall this is the type of application that necessitates *exact* byte
> counting. Oftentimes things with CTV seem inefficient, but when you crunch
> the numbers it turns out not to be so terrible. OP_EVICT seems promising in
> this regard compared to TLUV or accumulators.
>
> Another option is to randomize the CTV trees with multiple outputs per
> party (radix Q), then you need to do Q times the evictions, but you end up
> with sub-pools that contain more people/fractional liquidity (this might
> happen naturally if CTV Pools have channels in them, so it's good to model).
>
>
> Point 2, on Eltoo:
>
> One point of discomfort I have with Eltoo that I think is not universal,
> but is shared by some others, is that non-punitive channels may not be good
> for high-value channels as you do want, especially in a congested
> blockspace world, punishments to incentivize correct behavior (otherwise
> cheating may look like a free option).
>
> Thus I'm reluctant to fully embrace designs which do not permit nested
> traditional punitive channels in favor of Eltoo, when Eltoo might not have
> product-market-fit for higher valued channels.
>
> If someone had a punitive-eltoo variant that would ameliorate this concern
> almost entirely.
>
> Cheers,
>
> Jeremy
>
>
>
> --
> @JeremyRubin 
>
> On Fri, Feb 18, 2022 at 3:40 PM ZmnSCPxj via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Good morning ariard,
>>
>>
>> > > A statechain is really just a CoinPool hosted inside a
>> > >  Decker-Wattenhofer or Decker-Russell-Osuntokun construction.
>> >
>> > Note, to the best of my knowledge, how to use LN-Penalty in the context
>> of multi-party construction is still an unsolved issue. If an invalidated
>> state is published on-chain, how do you guarantee that the punished output
>> value is distributed "fairly" among the "honest" set of users ? At least
>> > where fairness is defined as a reasonable proportion of the balances
>> they owned in the latest state.
>>
>> LN-Penalty I believe is what I call Poon-Dryja?
>>
>> Both Decker-Wattenhofer (has no common colloquial name) and
>> Decker-Russell-Osuntokun ("eltoo") are safe with N > 2.
>> The former has bad locktime tradeoffs in the unilateral close case, and
>> the latter requires `SIGHASH_NOINPUT`/`SIGHASH_ANYPREVOUT`.
>>
>>
>> > > In principle, a set of promised outputs, if the owners of those
>> > > outputs are peers, does not have *any* inherent order.
>> > > Thus, I started to think about a commitment scheme that does not
>> > > impose any ordering during commitment.
>> >
>> > I think we should dissociate a) *outputs publication ordering* from the
>> b) *spends paths 

Re: [bitcoin-dev] Thoughts on fee bumping

2022-02-10 Thread Greg Sanders via bitcoin-dev
One quick thought to the proposal and perhaps to sponsors in general(didn't
have time to go over original proposal again):

Since sponsors can come from anywhere, the wallet application must have
access to the mempool to know what inputs must be double spent to RBF the
sponsor transaction.

Seems like an important difference to be considered.

On Fri, Feb 11, 2022 at 3:49 AM James O'Beirne via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> There's been much talk about fee-bumping lately, and for good reason -
> dynamic fee management is going to be a central part of bitcoin use as
> the mempool fills up (lord willing) and right now fee-bumping is
> fraught with difficulty and pinning peril.
>
> Gloria's recent post on the topic[0] was very lucid and highlights a
> lot of the current issues, as well as some proposals to improve the
> situation.
>
> As others have noted, the post was great. But throughout the course
> of reading it and the ensuing discussion, I became troubled by the
> increasing complexity of both the status quo and some of the
> proposed remedies.
>
> Layering on special cases, more carve-outs, and X and Y percentage
> thresholds is going to make reasoning about the mempool harder than it
> already is. Special consideration for "what should be in the next
> block" and/or the caching of block templates seems like an imposing
> dependency, dragging in a bunch of state and infrastructure to a
> question that should be solely limited to mempool feerate aggregates
> and the feerate of the particular txn package a wallet is concerned
> with.
>
> This is bad enough for protocol designers and Core developers, but
> making the situation any more intractable for "end-users" and wallet
> developers feels wrong.
>
> I thought it might be useful to step back and reframe. Here are a few
> aims that are motivated chiefly by the quality of end-user experience,
> constrained to obey incentive compatibility (i.e. miner reward, DoS
> avoidance). Forgive the abstract dalliance for a moment; I'll talk
> through concretes afterwards.
>
>
> # Purely additive feerate bumps should never be impossible
>
> Any user should always be able to add to the incentive to mine any
> transaction in a purely additive way. The countervailing force here
> ends up being spam prevention (a la min-relay-fee) to prevent someone
> from consuming bandwidth and mempool space with a long series of
> infinitesimal fee-bumps.
>
> A fee bump, naturally, should be given the same per-byte consideration
> as a normal Bitcoin transaction in terms of relay and block space,
> although it would be nice to come up with a more succinct
> representation. This leads to another design principle:
>
>
> # The bandwidth and chain space consumed by a fee-bump should be minimal
>
> Instead of prompting a rebroadcast of the original transaction for
> replacement, which contains a lot of data not new to the network, it
> makes more sense to broadcast the "diff" which is the additive
> contribution towards some txn's feerate.
>
> This dovetails with the idea that...
>
>
> # Special transaction structure should not be required to bump fees
>
> In an ideal design, special structural foresight would not be needed
> in order for a txn's feerate to be improved after broadcast.
>
> Anchor outputs specified solely for CPFP, which amount to many bytes of
> wasted chainspace, are a hack. It's probably uncontroversial at this
> point to say that even RBF itself is kind of a hack - a special
> sequence number should not be necessary for post-broadcast contribution
> toward feerate. Not to mention RBF's seemingly wasteful consumption of
> bandwidth due to the rebroadcast of data the network has already seen.
>
> In a sane design, no structural foresight - and certainly no wasted
> bytes in the form of unused anchor outputs - should be needed in order
> to add to a miner's reward for confirming a given transaction.
>
> Planning for fee-bumps explicitly in transaction structure also often
> winds up locking in which keys are required to bump fees, at odds
> with the idea that...
>
>
> # Feerate bumps should be able to come from anywhere
>
> One of the practical downsides of CPFP that I haven't seen discussed in
> this conversation is that it requires the transaction to pre-specify the
> keys needed to sign for fee bumps. This is problematic if you're, for
> example, using a vault structure that makes use of pre-signed
> transactions.
>
> What if the key you specified n the anchor outputs for a bunch of
> pre-signed txns is compromised? What if you'd like to be able to
> dynamically select the wallet that bumps fees? CPFP does you no favors
> here.
>
> There is of course a tension between allowing fee bumps to come from
> anywhere and the threat of pinning-like attacks. So we should venture
> to remove pinning as a possibility, in line with the first design
> principle I discuss.
>
>
> ---
>
> Coming down to earth, the "tabula rasa" thought experiment above 

Re: [bitcoin-dev] Taproot Fields for PSBT

2021-11-24 Thread Greg Sanders via bitcoin-dev
I may be misunderstanding the question, but it seems essential data for the
finalizer role, which may not know such information on its own.

On Wed, Nov 24, 2021 at 11:15 PM Sjors Provoost via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi Andrew,
>
> I'm confused why PSBT_IN_TAP_BIP32_DERIVATION and
> PSBT_OUT_TAP_BIP32_DERIVATION
> contain not just the derivation path for the xonlypubkey, but also the
> tapleaf merkle path.
>
> First I thought it was perhaps necessary in order for a signer to guess
> which
> script leaves it can sign with its own keys. But you can't really know
> that without
> actually seeing the script. When a signer looks at a script, it presumably
> already
> knows the leaf path.
>
> - Sjors
>
> Op 22 jun. 2021, om 23:22 heeft Andrew Chow via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> het volgende geschreven:
>
> Hi All,
>
> I would like to propose a BIP which defines new fields for Taproot
> support in PSBT.
>
> The full text is below, and the rendered file can be found at
>
>
> Now at: https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki
>
> -
> | Taproot Key BIP 32 Derivation Path
> | PSBT_IN_TAP_BIP32_DERIVATION = 0x16
> | 
> | The 32 byte X-only public key
> |  * <32-bit uint> <32-bit uint>*
> | A compact size unsigned integer representing the number of leaf
> hashes, followed by a list of leaf hashes, followed by the master key
> fingerprint concatenated with the derivation path of the public key. The
> derivation path is represented as 32-bit little endian unsigned integer
> indexes concatenated with each other. Public keys are those needed to
> spend this output. The leaf hashes are of the leaves which involve this
> public key.
>
>
> |-
> | Taproot Key BIP 32 Derivation Path
> | PSBT_OUT_TAP_BIP32_DERIVATION = 0x07
> | 
> | The 32 byte X-only public key
> |  * <32-bit uint> <32-bit uint>*
>
>
> ___
> 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] Reorgs on SigNet - Looking for feedback on approach and parameters

2021-09-12 Thread Greg Sanders via bitcoin-dev
> Sometimes that reorg could be deeper if you would be lucky enough to get
a block with more work than N following blocks combined

Each block is credited for its contribution to total chainwork by the
difficulty target, not the hash of the block itself.

On Sun, Sep 12, 2021 at 10:42 PM vjudeu via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> > - 1 block reorgs: these are a regular feature on mainnet, everyone
>should cope with them; having them happen multiple times a day to
>make testing easier should be great
>
> Anyone can do 1 block reorg, because nonce is not signed, so anyone can
> replace that with better value. For example, if you have block
> 0086d6b2636cb2a392d45edc4ec544a10024d30141c9adf4bfd9de533b53 with
> 0x0007f4cc nonce, you can replace that with 0x00110241 nonce and get
> 00096a1c4239d994547185c80308a552cba85d5bd28a51e9dc583ae5eadb block,
> where everything is identical, except the nonce.
>
> Sometimes that reorg could be deeper if you would be lucky enough to get a
> block with more work than N following blocks combined.
>
> On 2021-09-08 09:59:29 user Anthony Towns via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> > On Tue, Sep 07, 2021 at 06:07:47PM +0200, 0xB10C via bitcoin-dev wrote:
> > The reorg-interval X very much depends on the user's needs. One could
> > argue that there should be, for example, three reorgs per day, each 48
> > blocks apart.
>
> Oh, wow, I think the last suggestion was every 100 blocks (every
> ~16h40m). Once every ~8h sounds very convenient.
>
> > Such a short reorg interval allows developers in all time
> > zones to be awake during one or two reorgs per day.
>
> And also for there to reliably be reorgs when they're not awake, which
> might be a useful thing to be able to handle, too :)
>
> > Developers don't
> > need to wait for, for example, a week until they can test their reorgs
> > next. However, too frequent reorgs could hinder other SigNet users.
>
> Being able to run `bitcoind -signet -signetacceptreorg=0` and never
> seeing any reorgs should presumably make this not a problem?
>
> For people who do see reorgs, having an average of 2 or 3 additional
> blocks every 48 blocks is perhaps a 6% increase in storage/traffic.
>
> > # Scenario 1: Race between two chains
> >
> > For this scenario, at least two nodes and miner scripts need to be
> > running. An always-miner A continuously produces blocks and rejects
> > blocks with the to-be-reorged version bit flag set. And a race-miner R
> > that only mines D blocks at the start of each interval and then waits X
> > blocks. A and R both have the same hash rate. Assuming both are well
> > connected to the network, it's random which miner will first mine and
> > propagate a block. In the end, the A miner chain will always win the
> race.
>
> I think this description is missing that all the blocks R mines have
> the to-be-reorged flag set.
>
> > 3. How deep should the reorgs be on average? Do you want to test
> >deeper reorgs (10+ blocks) too?
>
> Super interested in input on this -- perhaps we should get optech to
> send a survey out to their members, or so?
>
> My feeling is:
>
>  - 1 block reorgs: these are a regular feature on mainnet, everyone
>should cope with them; having them happen multiple times a day to
>make testing easier should be great
>
>  - 2-3 block reorgs: good for testing the "your tx didn't get enough
>confirms to be credited to your account" case, even though it barely
>ever happens on mainnet
>
>  - 4-6 block reorgs: likely to violate business assumptions, but
>completely technically plausible, especially if there's an attack
>against the network
>
>  - 7-100 block reorgs: for this to happen on mainnet, it would probably
>mean there was a bug and pools/miners agree the chain has to
>be immediately reverted -- eg, someone discovers and exploits an
>inflation bug, minting themselves free bitcoins and breaking the 21M
>limit (eg, the 51 block reorg in Aug 2010); or someone discovers a
>bug that splits the chain, and the less compatible chain is reverted
>(eg, the 24 block reorg due to the bdb lock limit in Mar 2013);
>or something similar. Obviously the bug would have to have been
>discovered pretty quickly after it was exploited for the reorg to be
>under a day's worth of blocks.
>
>  - 100-2000+ block reorgs: severe bug that wasn't found quickly, or where
>getting >50% of miners organised took more than a few hours. This will
>start breaking protocol assumptions, like pool payouts, lightning's
>relative locktimes, or liquid's peg-in confirmation requirements, and
>result in hundres of MBs of changes to the utxo set
>
> Maybe it would be good to do reorgs of 15, 150 or 1500 blocks as a
> special fire-drill event, perhaps once a month/quarter/year or so,
> in some pre-announced window?
>
> I think sticking to 1-6 block reorgs initially is a fine way to 

Re: [bitcoin-dev] Unlimited covenants, was Re: CHECKSIGFROMSTACK/{Verify} BIP for Bitcoin

2021-07-05 Thread Greg Sanders via bitcoin-dev
Funny AJ mentions the multisig idea, because I know for a fact it's being
used in certain permissioned systems in this exact way. Regulators will
dream up these ideas with or without more useful covenants!

On Mon, Jul 5, 2021 at 9:46 PM Matt Corallo via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I find this point to be incredibly important. Indeed I, like several
> others, have historically been concerned with
> covenants in the unbounded form. However, as more and more research has
> been done in what they can accomplish, the
> weighting of such arguments naturally has to be reduced. More importantly,
> AJ's point here neuters anti-covanent
> arguments rather strongly.
>
> Matt
>
> On 7/5/21 01:04, Anthony Towns via bitcoin-dev wrote:
> > On Sun, Jul 04, 2021 at 09:02:25PM -0400, Russell O'Connor via
> bitcoin-dev wrote:
> >> Bear in mind that when people are talking about enabling covenants, we
> are
> >> talking about whether OP_CAT should be allowed or not.
> >
> > In some sense multisig *alone* enables recursive covenants: a government
> > that wants to enforce KYC can require that funds be deposited into
> > a multisig of "2   2 CHECKMULTISIG", and that
> > "recipient" has gone through KYC. Once deposited to such an address,
> > the gov can refus to sign with gov_key unless the funds are being spent
> > to a new address that follows the same rules.
> >
> > (That's also more efficient than an explicit covenant since it's all
> > off-chain -- recipient/gov_key can jointly sign via taproot/MuSig at
> > that point, so that full nodes are only validating a single pubkey and
> > signature per spend, rather than having to do analysis of whatever the
> > underlying covenant is supposed to be [0])
> >
> > This is essentially what Liquid already does -- it locks bitcoins into
> > a multisig and enforces an "off-chain" covenant that those bitcoins can
> > only be redeemed after some valid set of signatures are entered into
> > the Liquid blockchain. Likewise for the various BTC-on-Ethereum tokens.
> > To some extent, likewise for coins held in exchanges/custodial wallets
> > where funds can be transferred between customers off-chain.
> >
> > You can "escape" from that recursive covenant by having the government
> > (or Liquid functionaries, or exchange admins) change their signing
> > policy of course; but you could equally escape any consensus-enforced
> > covenant by having a hard fork to stop doing consensus-enforcement (cf
> > ETH Classic?). To me, that looks more like a difference of procedure
> > and difficulty, rather than a fundamental difference in kind.
> >
> > Cheers,
> > aj
> >
> > [0] https://twitter.com/pwuille/status/1411533549224693762
> >
> > ___
> > 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 mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] Proposal: Full-RBF in Bitcoin Core 24.0

2021-06-17 Thread Greg Sanders via bitcoin-dev
Transaction analysis tools do take the signal into account, but I'm unsure
if retail, non-custodial wallets use this information.

Historically the biggest pushback has been from services like Bitrefill
which have had quite a bit of success with 0-conf payments, but perhaps LN
adoption is at a point where it's less of an impact?

On Fri, Jun 18, 2021 at 4:15 AM Billy Tetrud via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Russel O'Connor recently opined
> 
> that RBF should be standard treatment of all transactions, rather than as a
> transaction opt-in/out. I agree with that. Any configuration in a
> transaction that has not been committed into a block yet simply can't be
> relied upon. Miners also have a clear incentive to ignore RBF rules and
> mine anything that passes consensus. At best opting out of RBF is a weak
> defense, and at worst it's simply a false sense of security that is likely
> to actively lead to theft events.
>
> Do we as a community want to support 0-conf payments in any way at this
> point? It seems rather silly to make software design decisions to
> accommodate 0-conf payments when there are better mechanisms for fast
> payments (ie lightning).
>
> One question I have is: how does software generally inform the user about
> 0-conf payment detection? Does software generally tell the user something
> along the lines of "This payment has not been finalized yet. All recipients
> should wait until the transaction has at least 1 confirmation, and most
> recipients should wait for 6 confirmations" ? I think unless we pressure
> software to be very explicit about what counts as finality, users will
> simply continue to do what they've always done. Rolling out this policy
> change over the course of a year or two seems fine, no need to rush. But I
> suppose it would depend on how often 0-conf is used in the bitcoin
> ecosystem at this point, which I don't have any data on.
>
> On Tue, Jun 15, 2021 at 10:00 AM Antoine Riard via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Hi,
>>
>> I'm writing to propose deprecation of opt-in RBF in favor of full-RBF as
>> the Bitcoin Core's default replacement policy in version 24.0. As a
>> reminder, the next release is 22.0, aimed for August 1st, assuming
>> agreement is reached, this policy change would enter into deployment phase
>> a year from now.
>>
>> Even if this replacement policy has been deemed as highly controversial a
>> few years ago, ongoing and anticipated changes in the Bitcoin ecosystem are
>> motivating this proposal.
>>
>> # RBF opt-out as a DoS Vector against Multi-Party Funded Transactions
>>
>> As explained in "On Mempool Funny Games against Multi-Party Funded
>> Transactions'', 2nd issue [0], an attacker can easily DoS a multi-party
>> funded transactions by propagating an RBF opt-out double-spend of its
>> contributed input before the honest transaction is broadcasted by the
>> protocol orchester. DoSes are qualified in the sense of either an attacker
>> wasting timevalue of victim's inputs or forcing exhaustion of the
>> fee-bumping  reserve.
>>
>> This affects a series of Bitcoin protocols such as Coinjoin, onchain DLCs
>> and dual-funded LN channels. As those protocols are still in the early
>> phase of deployment, it doesn't seem to have been executed in the wild for
>> now.  That said, considering that dual-funded are more efficient from a
>> liquidity standpoint, we can expect them to be widely relied on, once
>> Lightning enters in a more mature phase. At that point, it should become
>> economically rational for liquidity service providers to launch those DoS
>> attacks against their competitors to hijack user traffic.
>>
>> Beyond that, presence of those DoSes will complicate the design and
>> deployment of multi-party Bitcoin protocols such as payment
>> pools/multi-party channels. Note, Lightning Pool isn't affected as there is
>> a preliminary stage where batch participants are locked-in their funds
>> within an account witnessScript shared with the orchestrer.
>>
>> Of course, even assuming full-rbf, propagation of the multi-party funded
>> transactions can still be interfered with by an attacker, simply
>> broadcasting a double-spend with a feerate equivalent to the honest
>> transaction. However, it tightens the attack scenario to a scorched earth
>> approach, where the attacker has to commit equivalent fee-bumping reserve
>> to maintain the pinning and might lose the "competing" fees to miners.
>>
>> # RBF opt-out as a Mempools Partitions Vector
>>
>> A longer-term issue is the risk of mempools malicious partitions, where
>> an attacker exploits network topology or divergence in mempools policies to
>> partition network mempools in different subsets. From then a wide range of
>> attacks can be envisioned such as package pinning [1], artificial
>> congestion to provoke LN channels closure or 

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

2020-08-21 Thread Greg Sanders via bitcoin-dev
No strong opinions but:

Denial of service attacks can become 5x cheaper.

If you don't thoroughly test
https://github.com/bitcoin/bitcoin/issues/16499 these
changes you can end up with bugs that can cause issues on p2p network.

On Fri, Aug 21, 2020 at 4: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


Re: [bitcoin-dev] Bech32 weakness and impact on bip-taproot addresses

2020-07-15 Thread Greg Sanders via bitcoin-dev
Can you make it clear what the bold vs not-bold numbers mean?

On Wed, Jul 15, 2020 at 4:56 PM Russell O'Connor via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Wed, Nov 13, 2019 at 1:31 AM Pieter Wuille via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>>
>> That brings me to Matt's point: there is no need to do this right now. We
>> can simply amend BIP173 to only permit length 20 and length 32 (and only
>> length 20 for v0, if you like; but they're so far apart that permitting
>> both shouldn't hurt), for now. Introducing the "new" address format (the
>> one using an improved checksum algorithm) only needs to be there in time
>> for when a non-32-byte-witness-program would come in sight.
>>
>
> As a prerequisite to taproot activation, I was looking into amending
> BIP173 as stated above.  However after reviewing
> https://gist.github.com/sipa/a9845b37c1b298a7301c33a04090b2eb#detection-of-insertion-errors
> it seems that insertions of 5 characters or more is "safe" in the sense
> that there is low probability of creating a valid checksum by doing so
> randomly.
>
> This means we could safely allow witness programs of lengths *20*, 23,
> 26, 29, *32*, 36, and 40 (or 39).  These correspond to Bech32 addresses
> of length *42*, 47, 52, 57, *62*, 68, and 74 (or 73).  We could also
> support a set of shorter addresses, but given the lack of entropy in such
> short addresses, it is hard to believe that such witness programs could be
> used to secure anything.  I'm not sure what the motivation for allowing
> such short witness programs was, but I'm somewhat inclined to exclude them
> from the segwit address format.
>
> Given that we would only be able to support one of 39 or 40 byte witness
> programs, it is sensible to choose to allow 40 byte witness programs to be
> addressable.  This is the maximum witness program size allowed by BIP 141.
>
> So my proposal would be to amend BIP173 in such a way to restrict "bc" and
> "tb" segwit address formats to require witness programs be of size *20*,
> 23, 26, 29, *32*, 36, or 40.  Witness programs of other sizes (between 2
> and 40) would, of course, still be legal in accordance with BIP 141;
> however they would be unaddressable by using this "bc" and "tb" prefix.
> Another address format would be needed to support other witness sizes,
> should the need ever arise.
>
> --
> Russell O'Connor
> ___
> 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] Tainting, CoinJoin, PayJoin, CoinSwap

2020-06-10 Thread Greg Sanders via bitcoin-dev
A major point of defeating the common input heuristic and others is to make
"super-clusters". A small number of users that "don't care" about possibly
touching tainted coins can render many chain analysis techniques unworkable
in practice for enforcement. You don't need 100% coverage to defeat the
heuristic.

On Wed, Jun 10, 2020 at 9:40 AM nopara73 via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> The problem with CoinJoins is that desire for privacy is explicitly
> signalled by them, so adversaries can consider them "suspicious." PayJoin
> and CoinSwap solve this problem, because they are unnoticeable. I think
> this logic doesn't stand for scrutiny.
>
> From here on let's use the terminology of a typical adversary: there are 3
> kinds of coin histories: "clean", "dirty" and "suspicious".
> The aftermath of you using a "dirty" coin is knocks on your door. You
> using a "suspicious" coin is uncomfortable questions and you using a
> "clean" coin is seamless transfer.
>
> In scenario 1, you start out with a "clean" history. By using CoinJoins
> you make your new coin's history "suspicious" so you have no incentive to
> CoinJoin. By using CoinSwap/PayJoin your new coin can be either "clean" or
> "dirty". What would a "clean" coin owner prefer more? Take the risk of
> knocking on the door or answering uncomfortable questions?
>
> In scenario 2, you start out with a "dirty" history. By using CoinJoins
> you make your new coin's history "suspicious" so you have an incentive to
> CoinJoin. By using CoinSwap/PayJoin your new coin can either be "clean" or
> "dirty". What would a "dirty" coin owner prefer more? And here's an
> insight: you may get knocks on your door for a dirty coin that you have
> nothing to do with. And you can prove this fact to the adversary, but by
> doing so, you'll also expose that you started out with a "dirty" coin to
> begin with and now the adversary becomes interested in you for a different
> reason.
>
> You can also examine things assuming full adoption of PJ/CS vs full
> adoption of CJ, but you'll see that full adoption of any of these solves
> the tainting issue.
>
> So my current conclusion is that PJ/CS does not only not solve the taint
> problem, it just alters it and ultimately very similar problems arise for
> the users. Maybe the goal of unobservable privacy is a fallacy in this
> context as it is based on the assumption that desiring privacy is
> suspicious, so you want to hide the fact that you desire privacy. And the
> solution to the taint issue is either protocol change or social change
> (decent adoption.)
>
> PS.: Please try to keep the conversation to the Taint Issue as this email
> of mine isn't supposed to be discussing general pros and cons of various
> privacy techniques.
>
> Any thoughts?
>
> --
> Best,
> Ádám
> ___
> 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] MIN_STANDARD_TX_NONWITNESS_SIZE and OP_RETURN

2020-05-23 Thread Greg Sanders via bitcoin-dev
So I think the question to ask would be "why can't we just make sure it's
not 64?"

On Sat, May 23, 2020 at 11:24 AM Greg Sanders  wrote:

> AFAIU the number was picked to protect against CVE-2017-12842 covertly.
> See: https://github.com/bitcoin/bitcoin/pull/16885
>  which updated the
> text to explicitly mention this fact.
>
> On Sat, May 23, 2020 at 11:20 AM Thomas Voegtlin via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Hello list,
>>
>> I have been trying to CPFP a transaction using OP_RETURN, because the
>> remaining output value would have been lower than the dust threshold.
>>
>> The scriptPubkey of the output was OP_RETURN + OP_0, and there was a
>> single p2wsh input.
>>
>> The result is a 60 bytes transaction (without witness), that gets
>> rejected because it is lower than MIN_STANDARD_TX_NONWITNESS_SIZE, which
>> is equal to 82 bytes.
>>
>> Why is that value so high? Would it make sense to lower it to 60?
>>
>>
>> Thomas
>> ___
>> 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] MIN_STANDARD_TX_NONWITNESS_SIZE and OP_RETURN

2020-05-23 Thread Greg Sanders via bitcoin-dev
AFAIU the number was picked to protect against CVE-2017-12842 covertly.
See: https://github.com/bitcoin/bitcoin/pull/16885
 which updated the
text to explicitly mention this fact.

On Sat, May 23, 2020 at 11:20 AM Thomas Voegtlin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hello list,
>
> I have been trying to CPFP a transaction using OP_RETURN, because the
> remaining output value would have been lower than the dust threshold.
>
> The scriptPubkey of the output was OP_RETURN + OP_0, and there was a
> single p2wsh input.
>
> The result is a 60 bytes transaction (without witness), that gets
> rejected because it is lower than MIN_STANDARD_TX_NONWITNESS_SIZE, which
> is equal to 82 bytes.
>
> Why is that value so high? Would it make sense to lower it to 60?
>
>
> Thomas
> ___
> 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-341: Committing to all scriptPubKeys in the signature message

2020-05-01 Thread Greg Sanders via bitcoin-dev
For what it's worth this measure had been discussed as a lightweight way of
informing offline signers if inputs were segwit or not for malleability
analysis reasons. So there's at least a couple direct use-cases it seems.

On Fri, May 1, 2020, 8:23 AM Russell O'Connor via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> While I'm not entirely convinced yet that accertaining non-ownership of an
> input is a robust method of solving the problem here, I also see little
> reason not to amend BIP-341 as proposed. The ScriptPubKeys in question is
> already indirectly covered through the outpoints, so it is just a matter of
> optimization.  Furthermore in the consensus code, the ScriptPubKeys are
> part of the UTXO data set, and it is already being retrieved as part of the
> transaction checking process, so it is readily available.
>
> I'm not sure how much my opinion on the topic matters, but I did include
> this kind of functionality in my design for Simplicity on Elements, and I
> have been leaning towards adding this kind of functionality in my Bitcoin
> demo application of Simplicity.
>
> Regarding specifics, I personally think it would be better to keep the
> hashes of the ScriptPubKeys separate from the hashes of the input values.
> This way anyone only interested in input values does not need to wade
> through what are, in principle, arbitrarily long ScriptPubKeys in order to
> check the input values (which each fixed size).  To that end, I would also
> (and independently) propose separating the hashing of the output values
> from the output ScriptPubKeys in `sha_outputs` so again, applications
> interested only in summing the values of the outputs (for instance to
> compute fees) do not have to wade through those arbitrarily long
> ScriptPubKeys in the outputs.
>
> On Thu, Apr 30, 2020 at 4:22 AM Andrew Kozlik via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Hi everyone,
>>
>> In the current draft of BIP-0341 [1] the signature message commits to the
>> scriptPubKey of the output being spent by the input. I propose that the
>> signature message should commit to the scriptPubKeys of *all* transaction
>> inputs.
>>
>> In certain applications like CoinJoin, a wallet has to deal with
>> transactions containing external inputs. To calculate the actual amount
>> that the user is spending, the wallet needs to reliably determine for each
>> input whether it belongs to the wallet or not. Without such a mechanism an
>> adversary can fool the wallet into displaying incorrect information about
>> the amount being spent, which can result in theft of user funds [2].
>>
>> In order to ascertain non-ownership of an input which is claimed to be
>> external, the wallet needs the scriptPubKey of the previous output spent by
>> this input. It must acquire the full transaction being spent and verify its
>> hash against that which is given in the outpoint. This is an obstacle in
>> the implementation of lightweight air-gapped wallets and hardware wallets
>> in general. If the signature message would commit to the scriptPubKeys of
>> all transaction inputs, then the wallet would only need to acquire the
>> scriptPubKey of the output being spent without having to acquire and verify
>> the hash of the entire previous transaction. If an attacker would provide
>> an incorrect scriptPubKey, then that would cause the wallet to generate an
>> invalid signature message.
>>
>> Note that committing only to the scriptPubKey of the output being spent
>> is insufficient for this application, because the scriptPubKeys which are
>> needed to ascertain non-ownership of external inputs are precisely the ones
>> that would not be included in any of the signature messages produced by the
>> wallet.
>>
>> The obvious way to implement this is to add another hash to the signature
>> message:
>> sha_scriptPubKeys (32): the SHA256 of the serialization of all
>> scriptPubKeys of the previous outputs spent by this transaction.
>>
>> Cheers,
>> Andrew Kozlik
>>
>> [1]
>> https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#common-signature-message
>> [2]
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-August/014843.html
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] Statechain implementations

2020-03-26 Thread Greg Sanders via bitcoin-dev
> Wouldn't that result in a changing pubkey at each update, and thus
require an onchain move to be committed?

Suggestion was in line with original proposal where no keys are changing
ever, just not presupposing existence of MuSig.

On Thu, Mar 26, 2020 at 1:15 PM Christian Decker via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Ruben Somsen via bitcoin-dev 
> writes:
> > Regarding modification 1, I agree with ZmnSCPxj that
> > Decker-Wattenhofer is your next best option, given that eltoo is not
> > yet available. But if you are going to use a kickoff transaction, keep
> > in mind that every previous owner will have a copy of it. Because of
> > this, you can't include a fee, and will instead need to have a second
> > output for CPFP. This way a previous owner will at least have to pay
> > the fee if they want to publish it. Note that it's still an
> > improvement, because even if the kickoff transaction gets posted, it
> > basically becomes no different than what it would have been, had you
> > not used a kickoff transaction at all.
>
> It might be worth adopting the late fee binding we have in eltoo by
> having the kickoff transaction input spending the funding tx signed with
> sighash_single. This works because we only have 1 input and 1 output
> that we really care about, and can allow others to attach fees at
> will. That'd at least remove the need to guess the feerate days or
> months in advance and thus having to overestimate.
>
> > Regarding modification 2, I like it a lot conceptually. It hadn't
> > occurred to me before, and it's a clear security improvement. The only
> > question is something Greg Sanders mentioned: whether it's enough to
> > justify the added complexity of using 2P ECDSA. The alternative would
> > be to simply use a regular 2-of-2 multisig (until Schnorr arrives,
> > possibly).
>
> Wouldn't that result in a changing pubkey at each update, and thus
> require an onchain move to be committed?
>
> > I'm looking forward to seeing statechains become a reality.
>
> That'd indeed be great :-)
>
> Cheers,
> Christian
> ___
> 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] RFC: Kicking BIP-322 (message signing) into motion

2020-03-04 Thread Greg Sanders via bitcoin-dev
OP_MESSAGEONLY would make "dumb" signers like HWW more difficult to
support. They'd have to do script interpretation to make sure they're not
signing something real with funds.

Just FYI.

On Wed, Mar 4, 2020 at 9:35 AM Luke Dashjr via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> In addition to starting with proof-of-funds instead of proof-of-receiver,
> it
> would be nice to integrate with Taproot somehow or another. Perhaps
> OP_MESSAGEONLY is the most straightforward way to do this? It might be a
> good
> idea to have a message type after the opcode too.
>
> On Wednesday 04 March 2020 06:23:53 Karl-Johan Alm via bitcoin-dev wrote:
> > Hello,
> >
> > I noticed recently that a PR to Bitcoin Core that pretty much touched
> > everything my BIP-322 pull request touches (around the same
> > complexity) was merged without a thought given to BIP-322
> > compatibility, despite the BIP-322 PR being open for 2x the time. I
> > can only conclude from this that people dislike BIP-322 in its current
> > form, which the 9 month old pull request stagnating can probably
> > attest to.
> >
> > There are several things that I can do to make this a bit more
> > appealing to people, which would hopefully kick the progress on this
> > forward. I have already put in a non-trivial amount of energy and
> > effort into maintaining the pull request as is, so I'd prefer if
> > people were harsh and unfiltered in their criticism rather than polite
> > and buffered, so I can beat this thing into shape (or abandon it, in
> > the worst case).
> >
> > =
> > 1. People use signmessage as a way to prove funds. This is misleading
> > and should be discouraged; throw the sign message stuff out and
> > replace it entirely with a prove funds system.
> >
> > I know in particular luke-jr is of this opinion, and Greg Maxwell in
> > https://github.com/bitcoin/bitcoin/pull/16440#issuecomment-568194168
> > leans towards this opinion as well, it seems.
> >
> > =
> > 2. Use a transaction rather than a new format; make the first input's
> > txid the message hash to ensure the tx cannot be broadcasted. This has
> > the benefit of being able to provide to an existing hardware wallet
> > without making any modifications to its firmware.
> >
> > I think Mark Friedenbach and Johnson Lau are of this opinion, except
> > Johnson Lau also suggests that the signature hash is modified, see
> > https://github.com/bitcoin/bips/pull/725#issuecomment-420040430 --
> > which defeats the benefit above since now hw wallets can no longer
> > sign.
> >
> > Prusnak (I think he works at Trezor; apologies if I am mistaken) is
> > against this idea, and proposes (3) below:
> > https://github.com/bitcoin/bips/pull/725#issuecomment-420210488
> >
> > =
> > 3. Use Trezor style
> >
> > See https://github.com/trezor/trezor-mcu/issues/169
> >
> > This has the benefit of already being adopted (which clearly BIP-322
> > is failing hard at right now), but has the drawback that we can no
> > longer do *generic* signing; we are stuck with the exact same
> > limitations as in the legacy system, which we kinda wanted to fix in
> > the updated version.
> >
> > =
> > 4. Introduce OP_MESSAGEONLY
> >
> > Quoting Johnson Lau at
> > https://github.com/bitcoin/bips/pull/725#issuecomment-420421058 :
> > """
> > OP_MESSAGEONLY means the script following the code would never be
> > valid. For example, a scriptPubKey:
> >
> > OP_IF OP_MESSAGEONLY  OP_ELSE  OP_ENDIF OP_CHECKSIG
> >
> > For messaging purpose, OP_MESSAGEONLY is considered as OP_NOP and is
> > ignored. A message could be signed with either key_m or key_s.
> >
> > For spending, only key_s is valid.
> >
> > I don't think it is a big problem to consume a op_code. If this is a
> > real concern, I could modify it as follow: in message system,
> > OP_RETURN will pop the top stack. If top stack is msg in hex, it is
> > ignored. Otherwise, the script fails.
> > """
> >
> > =
> > 5. Some other solution
> > ___
> > 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 mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] Taproot proposal

2019-09-16 Thread Greg Sanders via bitcoin-dev
> I'd prefer to not support P2SH-nested TR. P2SH wrapping was useful for
segwit
v0 for compatibility reasons. Most wallets/exchanges/services now support
sending
to native segwit addresses (https://en.bitcoin.it/wiki/Bech32_adoption) and
that
will be even more true if Schnorr/Taproot activate in 12+ months time.

Apologies for necroing an ancient thread, but I'm echoing my agreement with
John here.
We still have plenty of time to have ecosystem upgrade by the time taproot
is likely to activate.



On Wed, May 22, 2019 at 10:30 AM John Newbery via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi,
>
> > A Taproot output is a SegWit output [...]  with
> > version number 1, and a 33-byte witness program whose first byte is 0 or
> 1.
>
> Given a secret key k and public key P=(x,y), a signer with the knowledge
> of k
> can sign for -P=(x,p-y) since -k is the secret key for that point.
> Encoding the
> y value of the public key therefore adds no security. As an alternative to
> providing the y value of the taproot output key Q when constructing the
> taproot
> output, the signer can provide it when signing. We can also restrict the y
> value
> of the internal key P to be even (or high, or a quadratic residue). That
> gives
> us 4 options for how to set the y signs for P and Q.
>
> 1. Q sign is explictly set in the witness program, P sign is explicitly
> set in the control block
> => witness program is 33 bytes, 32 possible leaf versions (one for
> each pair of 0xc0..0xff)
> 2. Q sign is explictly set in the witness program, P sign is implicitly
> even
> => witness program is 33 bytes, 64 possible leaf versions (one for
> each 0xc0..0xff)
> 3. Q sign is explictly set in the control block, P sign is explicitly set
> in the control block
> => witness program is 32 bytes, 16 possible leaf versions (one for
> each 4-tuple of 0xc0..0xff)
> 4. Q sign is explictly set in the control block, P sign is implicitly even
> => witness program is 32 bytes, 32 possible leaf versions (one for
> pair of 0xc0..0xff)
>
> The current proposal uses (1). Using (3) or (4) would reduce the size of a
> taproot output by one byte to be the same size as a P2WSH output. That
> means
> that it's not more expensive for senders compared to sending to P2WSH.
>
> (Credit to James Chiang for suggesting omitting the y sign from the public
> key and
> to sipa for pointing out the 4 options above)
>
> > (native or P2SH-nested, see BIP141)
>
> I'd prefer to not support P2SH-nested TR. P2SH wrapping was useful for
> segwit
> v0 for compatibility reasons. Most wallets/exchanges/services now support
> sending
> to native segwit addresses (https://en.bitcoin.it/wiki/Bech32_adoption)
> and that
> will be even more true if Schnorr/Taproot activate in 12+ months time.
>
> On Mon, May 6, 2019 at 2:36 PM Pieter Wuille via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Hello everyone,
>>
>> Here are two BIP drafts that specify a proposal for a Taproot
>> softfork. A number of ideas are included:
>>
>> * Taproot to make all outputs and cooperative spends indistinguishable
>> from eachother.
>> * Merkle branches to hide the unexecuted branches in scripts.
>> * Schnorr signatures enable wallet software to use key
>> aggregation/thresholds within one input.
>> * Improvements to the signature hashing algorithm (including signing
>> all input amounts).
>> * Replacing OP_CHECKMULTISIG(VERIFY) with OP_CHECKSIGADD, to support
>> batch validation.
>> * Tagged hashing for domain separation (avoiding issues like
>> CVE-2012-2459 in Merkle trees).
>> * Extensibility through leaf versions, OP_SUCCESS opcodes, and
>> upgradable pubkey types.
>>
>> The BIP drafts can be found here:
>> * https://github.com/sipa/bips/blob/bip-schnorr/bip-taproot.mediawiki
>> specifies the transaction input spending rules.
>> * https://github.com/sipa/bips/blob/bip-schnorr/bip-tapscript.mediawiki
>> specifies the changes to Script inside such spends.
>> * https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki
>> is the Schnorr signature proposal that was discussed earlier on this
>> list (See
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-July/016203.html
>> )
>>
>> An initial reference implementation of the consensus changes, plus
>> preliminary construction/signing tests in the Python framework can be
>> found on https://github.com/sipa/bitcoin/commits/taproot. All
>> together, excluding the Schnorr signature module in libsecp256k1, the
>> consensus changes are around 520 LoC.
>>
>> While many other ideas exist, not everything is incorporated. This
>> includes several ideas that can be implemented separately without loss
>> of effectiveness. One such idea is a way to integrate SIGHASH_NOINPUT,
>> which we're working on as an independent proposal.
>>
>> The document explains basic wallet operations, such as constructing
>> outputs and signing. However, a wide variety of more complex
>> constructions exist. 

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

2019-07-24 Thread Greg Sanders via bitcoin-dev
People are allowed the choice, it's a change of default only.

On Mon, Jul 22, 2019 at 4:41 PM Peter via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi,
>
> I believe two wallets. Andreas' Android Bitcoin wallet and BRD are
> significant users of node_bloom.
>
> Privacy is a matter of individual choice in the current protocol. Why not
> let people provide this network service? I don't see why it should be
> end-of-life if it provides value.
>
> I believe there's a network security obtained by having a large quantity
> of people following the Bitcoin headers based on longest weighted chain. As
> a means of nullifying potential miner initiated hard forks (like S2X).
>
> Respectfully,
> Peter
> ___
> 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 174 thoughts

2018-06-21 Thread Greg Sanders via bitcoin-dev
>Hmm, upon further reflection, maybe it's not even worth including *any*
per-output data, aside from what the original transaction contains.

>The output redeem script is either:
- unknown, because we have received only an address from the receiver
- or it is known, because it is ours and in that case it doesn’t make
sense to include it in PSBT

Signers are an extremely heterogeneous bunch. A signer may need to
introspect on the script, such as "this is a 2-of-3,
and I'm one of the keys". Even in basic p2pkh settings not adding any
output information rules out things like change
detection on any conceivable hardware wallet, or even simple software
wallets that don't carry significant state.

On Thu, Jun 21, 2018 at 10:35 AM Tomas Susanka via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hello,
>
> First of all, let me thank you for all the hard work you and others have
> put into this.
>
>
> On 21.6.2018 02:39, Achow101 via bitcoin-dev wrote:
> > While I agree that the BIP itself should be revised to reflect these
> suggestions, I fear that it may be too late. I know of a few other
> developers who have implemented BIP 174 already but have not yet responded
> to this email.
>
> We do realize that this discussion should have happened earlier, however
> agreeing on a good standard should be the number one priority for all
> the parties involved.
>
> The fact that someone already implemented this is indeed unfortunate,
> but I don't think we should lower our demands on the standard just
> because of a bad timing.
>
> >> A question to consider is,
> >> will there be more per-output data? If yes, it might make sense to have
> >> an output section.
> > I think it is unlikely that there would be anymore per-output data.
>
> Hmm, upon further reflection, maybe it's not even worth including *any*
> per-output data, aside from what the original transaction contains.
>
> The output redeem script is either:
> - unknown, because we have received only an address from the receiver
> - or it is known, because it is ours and in that case it doesn’t make
> sense to include it in PSBT
>
> We got stuck on the idea of the Creator providing future (output)
> redeem/witness scripts. But that seems to be a minority use case and can
> be solved efficiently via the same channels that coordinate the PSBT
> creation. Sorry to change opinions so quickly on this one.
>
> >
> >> 3) The sighash type 0x03 says the sighash is only a recommendation. That
> >> seems rather ambiguous. If the field is specified shouldn't it be
> binding?
> > I disagree. It is up to the signer to decide what they wish to sign, not
> for the creator to specify what to sign. The creator can ask the signer to
> sign something in a particular way, but it is ultimately up to the signer
> to decide.
>
> This seems very ambiguous. The Signer always has the option of not
> signing. *What* to sign is a matter of coordination between the parties;
> otherwise, you could make all the fields advisory and let anyone sign
> anything they like?
>
> We don't understand the usecase for a field that is advisory but not
> binding. On what basis would you choose to respect or disregard the
> advisory field? Either one party has a preference, in which case they
> have to coordinate with the other anyway - or they don't, in which case
> they simply leave the field out.
>
> > Size is not really a constraint, but we do not want to be unnecessarily
> large. The PSBT still has to be transmitted to other people. It will likely
> be used by copy and pasting the string into a text box. Copying and pasting
> very long strings of text can be annoying and cumbersome. So the goal is to
> keep the format still relatively clear while avoiding the duplication of
> data.
>
> I agree. Just to put some numbers on this: if we expect a 5-part
> derivation path, and add the master key fingerprint, that is 4 + 5*4 =
> 24 bytes (~32 base64 letters) per input and signer. I'd argue this is
> not significant.
> If we used full xpub, per Pieter's suggestion, that would grow to 32 +
> 32 + 5*4 = 84 bytes (~112 letters) per input/signer, which is quite a lot.
>
> On the other hand, keeping the BIP32 paths per-input means that we don't
> need to include the public key (as in the lookup key), so that's 32
> bytes down per path. In general, all the keys can be fully reconstructed
> from their values:
>
> redeem script key = hash160(value)
> witness script key = sha256(value)
> bip32 key = derive(value)
>
> The one exception is a partial signature. But even in that case we
> expect that a given public key will always correspond to the same
> signature, so we can act as if the public key is not part of the "key".
> In other words, we can move the public key to the value part of the record.
>
> This holds true unless there's some non-deterministic signing scheme,
> *and* multiple Signers sign with the same public key, which is what
> Pieter was alluding to on Twitter
> 

Re: [bitcoin-dev] {sign|verify}message replacement

2018-03-15 Thread Greg Sanders via bitcoin-dev
Sorry if I missed the rationale earlier, but why not just do a transaction,
with a FORKID specifically for this? Then a node can have a mempool
acceptance test that returns true even if the signature is not valid as per
Bitcoin consensus, but only due to the FORKID?

This way basically any wallet can support this provided generic FORKID
support.

On Thu, Mar 15, 2018 at 8:38 PM, Karl Johan Alm via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Thu, Mar 15, 2018 at 2:14 PM, Luke Dashjr  wrote:
> > Not necessarily specific UTXOs (that would contradict fungibility, as
> well as
> > be impossible for hot/cold wallet separation), but just to prove funds
> are
> > available. The current sign message cannot be used to prove present
> possession
> > of funds, only that you receive funds.
>
> By saying "not necessarily specific UTXOs", are you saying it may be
> spent outputs? I'm a little confused I think.
>
> On Thu, Mar 15, 2018 at 8:53 PM, Jim Posen  wrote:
> > In this general signing-a-script context, I think a verifier might want
> to
> > see the time conditions under which it may be spent. The proof container
> > could include an optional nLockTime which defaults to 0 and nSequence
> which
> > defaults to 0x...
>
> Good point!
>
> >> I think it would just use the default (SIGHASH_ALL?) for simplicity.
> >> Is there a good reason to tweak it?
> >
> > I took another look and there should definitely be a byte appended to the
> > end of the sig so that the encoding checks pass, but I think it might as
> > well be a 0x00 byte since it's not actually a sighash flag.
>
> I think the sighash flag affects the outcome of the actual
> verification, but I could be mistaken.
>
> -Kalle.
> ___
> 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] Revisiting BIP 125 RBF policy.

2018-02-14 Thread Greg Sanders via bitcoin-dev
Yes.

On Wed, Feb 14, 2018 at 9:08 AM, Russell O'Connor via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Mon, Feb 12, 2018 at 6:42 PM, Peter Todd  wrote:
>
>> On Mon, Feb 12, 2018 at 06:19:40PM -0500, Russell O'Connor wrote:
>> > Surely CPFP is already computing the package-fee rates of mempool
>> > transactions.  That is the value we need to compute.
>>
>> True, maybe we can just reuse the CPFP calculation now. That said, AFAIK
>> that's
>> only done in the miner code, not the mempool, so that may not be trivial
>> to
>> actually do.
>>
>
> Do you (or anyone else) know if the package fee rate is considered when
> ejecting transactions from the bottom of the mempool when the mempool gets
> too large?
>
> ___
> 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] Taproot: Privacy preserving switchable scripting

2018-01-23 Thread Greg Sanders via bitcoin-dev
Interesting parallels to current Elements sidechain peg-in functionality.
User tweaks the watchmen(BTC holder) pubkey using P2CH, committing to a
script that is used on the *sidechain side* as spending authorization for
that bitcoin output rather than mainnet.

I think composing the two can be done as:

P = C' + H(C'||S')G + H(C||S)G

where C is redefined as `C' + H(C'||S')G`, which for Bitcoin consensus
purposes is just a single pubkey.



On Mon, Jan 22, 2018 at 7:30 PM, Gregory Maxwell via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Interest in merkelized scriptPubKeys (e.g. MAST) is driven by two main
> areas: efficiency and privacy. Efficiency because unexecuted forks of
> a script can avoid ever hitting the chain, and privacy because hiding
> unexecuted code leaves scripts indistinguishable to the extent that
> their only differences are in the unexecuted parts.
>
> As Mark Friedenbach and others have pointed out before it is almost
> always the case that interesting scripts have a logical top level
> branch which allows satisfaction of the contract with nothing other
> than a signature by all parties.  Other branches would only be used
> where some participant is failing to cooperate. More strongly stated,
> I believe that _any_ contract with a fixed finite participant set
> upfront can be and should be represented as an OR between an N-of-N
> and whatever more complex contract you might want to represent.
>
> One point that comes up while talking about merkelized scripts is can
> we go about making fancier contract use cases as indistinguishable as
> possible from the most common and boring payments. Otherwise, if the
> anonymity set of fancy usage is only other fancy usage it may not be
> very large in practice. One suggestion has been that ordinary
> checksig-only scripts should include a dummy branch for the rest of
> the tree (e.g. a random value hash), making it look like there are
> potentially alternative rules when there aren't really.  The negative
> side of this is an additional 32-byte overhead for the overwhelmingly
> common case which doesn't need it.  I think the privacy gains are
> worth doing such a thing, but different people reason differently
> about these trade-offs.
>
> It turns out, however, that there is no need to make a trade-off.  The
> special case of a top level "threshold-signature OR
> arbitrary-conditions" can be made indistinguishable from a normal
> one-party signature, with no overhead at all, with a special
> delegating CHECKSIG which I call Taproot.
>
> Let's say we want to create a coin that can be redeemed by either
> Alice && Bob   or by CSV-timelock && Bob.
>
> Alice has public A, Bob has pubkey B.
>
> We compute the 2-of-2 aggregate key C = A + B.  (Simplified; to
> protect against rogue key attacks you may want to use the MuSig key
> aggregation function [1])
>
> We form our timelock script S =  " OP_CSV OP_DROP B
> OP_CHECKSIGVERIFY"
>
> Now we tweak C to produce P which is the key we'll publish: P = C +
> H(C||S)G.
>
> (This is the attack hardened pay-to-contract construction described in [2])
>
> Then we pay to a scriptPubKey of [Taproot supporting version] [EC point P].
>
> Now Alice and Bob-- assuming they are both online and agree about the
> resolution of their contract-- can jointly form a 2 of 2 signature for
> P, and spend as if it were a payment to a single party (one of them
> just needs to add H(C||S) to their private key).
>
> Alternatively, the Taproot consensus rules would allow this script to
> be satisfied by someone who provides the network with C (the original
> combined pubkey), S, and does whatever S requires-- e.g. passes the
> CSV check and provides Bob's signature. With this information the
> network can verify that C + H(C||S) == P.
>
> So in the all-sign case there is zero overhead; and no one can tell
> that the contract alternative exists. In the alternative redemption
> branch the only overhead is revealing the original combined pubkey
> and, of course, the existence of the contract is made public.
>
> This composes just fine with whatever other merkelized script system
> we might care to use, as the S can be whatever kind of data we want,
> including the root of some tree.
>
> My example shows 2-of-2 but it works the same for any number of
> participants (and with setup interaction any threshold of
> participants, so long as you don't mind an inability to tell which
> members signed off).
>
> The verification computational complexity of signature path is
> obviously the same as any other plain signature (since its
> indistinguishable). Verification of the branch redemption requires a
> hash and a multiplication with a constant point which is strictly more
> efficient than a signature verification and could be efficiently fused
> into batch signature validation.
>
> The nearest competitor to this idea that I can come up with would
> supporting a simple delegation where the output can be spent by the
> named 

Re: [bitcoin-dev] BIP 39: Add language identifier strings for wordlists

2018-01-08 Thread Greg Sanders via bitcoin-dev
>I'm shocked that so many people are resisting the idea that just *maybe* there
could be people in other parts of the world who do not want to use or
cannot use the strict set of latin characters and words from the English
language.


You're mistaking concern for users potentially losing money with disdain
for them. I can read a few languages, yet I would not advise users to use a
wordlist that might not have support across multiple wallet
implementations, resulting in lock-in or worse.

If I'm wrong, great, more people can use software strictly in their native
language in a safe manner!

On Mon, Jan 8, 2018 at 10:26 AM, AJ West <ajw...@gmail.com> wrote:

> Greg yes, there were already examples in this very thread of people
> explaining how they use languages other than English. I'm shocked that so
> many people are resisting the idea that just *maybe* there could be
> people in other parts of the world who do not want to use or cannot use the
> strict set of latin characters and words from the English language.
>
> I agree with Sjors and maybe I'm simplifying too much, but can't we just
> map an existing ISO/UTF language character standard to the seeds? Why is
> there a word list at all? Choose a flexible encoding standard, create a
> clever map to the bytes, make sure to include a checksum.
>
> As an aside, I know there are some conventions which add space for error
> correction but I personally don't love the idea of somebody inputting what
> they think is the proper seed, only to have it auto-corrected and thus
> reinforcing their erroneously saved/written seed backup.
>
> Pavol, why do you say "I learned that it was something I should've been
> more persistently against?" I still can't see any good arguments as to why
> we should limit this to English other than "It's easier to support a single
> language" which comes at the cost of "It's hard for me to backup my seed"
> for those who don't speak English.
>
> On Mon, Jan 8, 2018 at 10:23 AM, Matias Alejo Garcia via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> > Let me re-phrase: Is it a known thing for users to actually use it?
>>
>> yes. Based on language stats from the app stores, roughly 30% to 40% of
>> Copay users have their backup on a language
>> other than English, and we constantly get requests to support new
>> languages in BIP39.
>>
>> On Mon, Jan 8, 2018 at 11:54 AM, Greg Sanders <gsander...@gmail.com>
>> wrote:
>>
>>> Let me re-phrase: Is it a known thing for users to actually use it?
>>>
>>> On Mon, Jan 8, 2018 at 9:52 AM, Matias Alejo Garcia <ema...@gmail.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Mon, Jan 8, 2018 at 11:34 AM, Greg Sanders via bitcoin-dev <
>>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>>
>>>>> Has anyone actually used the multilingual support in bip39?
>>>>>
>>>>
>>>>
>>>> Copay (and all its clones) use it.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>> If a feature of the standard has not been(widely?) used in years, and
>>>>> isn't supported in any major wallet(?), it seems indicative it was a
>>>>> mistake to add it in the first place, since it's a footgun in the making
>>>>> for some poor sap who can't even read English letters when almost all
>>>>> documentation is written in English.
>>>>>
>>>>> On Mon, Jan 8, 2018 at 6:13 AM, nullius via bitcoin-dev <
>>>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>>>
>>>>>> On 2018-01-08 at 07:35:52 +, 木ノ下じょな <kinoshitaj...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> This is very sad.
>>>>>>>
>>>>>>> The number one problem in Japan with BIP39 seeds is with English
>>>>>>> words.
>>>>>>>
>>>>>>> I have seen a 60 year old Japanese man writing down his phrase
>>>>>>> (because he kept on failing recovery), and watched him write down 
>>>>>>> "aneter"
>>>>>>> for "amateur"...
>>>>>>>
>>>>>>> [...]
>>>>>>>
>>>>>>> If you understand English and can spell, you read a word, your brain
>>>>>>> processes the word, and you can spell it on your own when writing down.
>>>>>>> Not many Japanese people ca

Re: [bitcoin-dev] BIP 39: Add language identifier strings for wordlists

2018-01-08 Thread Greg Sanders via bitcoin-dev
Let me re-phrase: Is it a known thing for users to actually use it?

On Mon, Jan 8, 2018 at 9:52 AM, Matias Alejo Garcia <ema...@gmail.com>
wrote:

>
>
> On Mon, Jan 8, 2018 at 11:34 AM, Greg Sanders via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Has anyone actually used the multilingual support in bip39?
>>
>
>
> Copay (and all its clones) use it.
>
>
>
>
>
>>
>> If a feature of the standard has not been(widely?) used in years, and
>> isn't supported in any major wallet(?), it seems indicative it was a
>> mistake to add it in the first place, since it's a footgun in the making
>> for some poor sap who can't even read English letters when almost all
>> documentation is written in English.
>>
>> On Mon, Jan 8, 2018 at 6:13 AM, nullius via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> On 2018-01-08 at 07:35:52 +, 木ノ下じょな <kinoshitaj...@gmail.com> wrote:
>>>
>>>> This is very sad.
>>>>
>>>> The number one problem in Japan with BIP39 seeds is with English words.
>>>>
>>>> I have seen a 60 year old Japanese man writing down his phrase (because
>>>> he kept on failing recovery), and watched him write down "aneter" for
>>>> "amateur"...
>>>>
>>>> [...]
>>>>
>>>> If you understand English and can spell, you read a word, your brain
>>>> processes the word, and you can spell it on your own when writing down.
>>>> Not many Japanese people can do that, so they need to copy letter for
>>>> letter, taking a long time, and still messing up on occasion.
>>>>
>>>> [...]
>>>>
>>>> Defining "everyone should only use English, because ASCII is easier to
>>>> plan for" is not a good way to move forward as a currency.
>>>>
>>>
>>> Well said.  Thank you for telling of these experiences.  Now please,
>>> let’s put the shoe on the other foot.
>>>
>>> I ask everybody who wants an English-only mnemonic standard to entrust
>>> *their own money* to their abilities to very, very carefully write this
>>> down—then later, type it back in:
>>>
>>> すさん たんろ りゆう しもん ていおん しとう
>>> とこや はやい おうさま ほくろ けちゃっふ たもつ
>>>
>>> (Approximate translation:  “Whatever would you do if Bitcoin had been
>>> invented by somebody named Satoshi Nakamoto?”)
>>>
>>> No, wait:  That is only a 12-word mnemonic.  We are probably talking
>>> about a Trezor; so now, hey you there, stake the backup of your life’s
>>> savings on your ability to handwrite *this*:
>>>
>>> にあう しひょう にんすう ひえる かいこう いのる ねんし はあさん ひこく
>>> とうく きもためし そなた こなこな にさんかたんそ ろんき めいあん みわく
>>> へこむ すひょう おやゆひ ふせく けさき めいきょく こんまけ
>>>
>>> Ready to bet your money on *that* as a backup phrase in your own hands?
>>> No?  Then please, stop demanding that others risk *their* money on the
>>> inverse case.
>>>
>>> 
>>>
>>> If you cheat here by having studied Japanese, then remember that many
>>> Japanese people know English and other European languages, too.  Then think
>>> of how much money would be lost by your non-Japanese-literate family and
>>> friends—if BIP 39 had only Japanese wordlists, and your folks needed to
>>> wrestle with the above phrases as their “mnemonics”.
>>>
>>> In such cases, the phrases cannot be called “mnemonics” at all.  A
>>> “mnemonic” implies aid to memory.  Gibberish in a wholly alien writing
>>> system is much worse even than transcribing pseudorandom hex strings.  The
>>> Japanese man in the quoted story, who wrote “aneter” for “amateur”, was not
>>> dealing with a *mnemonic*:  He was using the world’s most inefficient means
>>> of making cryptic bitstrings *less* userfriendly.
>>>
>>> 
>>>
>>> I began this thread with a quite simple request:  Is “日本語” an
>>> appropriate string for identifying the Japanese language to Japanese
>>> users?  And what of the other strings I posted for other languages?
>>>
>>> I asked this as an implementer working on my own instance of the
>>> greatest guard against vendor lock-in and stale software:  Independent
>>> implementations.  —  I asked, because obviously, I myself do not speak all
>>> these different languages; and I want to implement them all.  *All.*
>>>
>>> Some replies have been interesting in their own r

Re: [bitcoin-dev] BIP 39: Add language identifier strings for wordlists

2018-01-08 Thread Greg Sanders via bitcoin-dev
Has anyone actually used the multilingual support in bip39?

If a feature of the standard has not been(widely?) used in years, and isn't
supported in any major wallet(?), it seems indicative it was a mistake to
add it in the first place, since it's a footgun in the making for some poor
sap who can't even read English letters when almost all documentation is
written in English.

On Mon, Jan 8, 2018 at 6:13 AM, nullius via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On 2018-01-08 at 07:35:52 +, 木ノ下じょな  wrote:
>
>> This is very sad.
>>
>> The number one problem in Japan with BIP39 seeds is with English words.
>>
>> I have seen a 60 year old Japanese man writing down his phrase (because
>> he kept on failing recovery), and watched him write down "aneter" for
>> "amateur"...
>>
>> [...]
>>
>> If you understand English and can spell, you read a word, your brain
>> processes the word, and you can spell it on your own when writing down.
>> Not many Japanese people can do that, so they need to copy letter for
>> letter, taking a long time, and still messing up on occasion.
>>
>> [...]
>>
>> Defining "everyone should only use English, because ASCII is easier to
>> plan for" is not a good way to move forward as a currency.
>>
>
> Well said.  Thank you for telling of these experiences.  Now please, let’s
> put the shoe on the other foot.
>
> I ask everybody who wants an English-only mnemonic standard to entrust
> *their own money* to their abilities to very, very carefully write this
> down—then later, type it back in:
>
> すさん たんろ りゆう しもん ていおん しとう
> とこや はやい おうさま ほくろ けちゃっふ たもつ
>
> (Approximate translation:  “Whatever would you do if Bitcoin had been
> invented by somebody named Satoshi Nakamoto?”)
>
> No, wait:  That is only a 12-word mnemonic.  We are probably talking about
> a Trezor; so now, hey you there, stake the backup of your life’s savings on
> your ability to handwrite *this*:
>
> にあう しひょう にんすう ひえる かいこう いのる ねんし はあさん ひこく
> とうく きもためし そなた こなこな にさんかたんそ ろんき めいあん みわく
> へこむ すひょう おやゆひ ふせく けさき めいきょく こんまけ
>
> Ready to bet your money on *that* as a backup phrase in your own hands?
> No?  Then please, stop demanding that others risk *their* money on the
> inverse case.
>
> 
>
> If you cheat here by having studied Japanese, then remember that many
> Japanese people know English and other European languages, too.  Then think
> of how much money would be lost by your non-Japanese-literate family and
> friends—if BIP 39 had only Japanese wordlists, and your folks needed to
> wrestle with the above phrases as their “mnemonics”.
>
> In such cases, the phrases cannot be called “mnemonics” at all.  A
> “mnemonic” implies aid to memory.  Gibberish in a wholly alien writing
> system is much worse even than transcribing pseudorandom hex strings.  The
> Japanese man in the quoted story, who wrote “aneter” for “amateur”, was not
> dealing with a *mnemonic*:  He was using the world’s most inefficient means
> of making cryptic bitstrings *less* userfriendly.
>
> 
>
> I began this thread with a quite simple request:  Is “日本語” an appropriate
> string for identifying the Japanese language to Japanese users?  And what
> of the other strings I posted for other languages?
>
> I asked this as an implementer working on my own instance of the greatest
> guard against vendor lock-in and stale software:  Independent
> implementations.  —  I asked, because obviously, I myself do not speak all
> these different languages; and I want to implement them all.  *All.*
>
> Some replies have been interesting in their own right; but thus far,
> nobody has squarely addressed the substance of my question.
>
> Most worrisome is that much of the discussion has veered into criticism of
> multi-language support.  I opened with a question about other languages,
> and I am getting replies which raise a hue and cry of “English only!”
>
> Though I am fluent and literate in English, I am uninterested in ever
> implementing any standard of this nature which is artificially restricted
> to English.  I am fortunate; for as of this moment, we have a standard
> called “BIP 39” which has seven non-English wordlists, and four more
> pending in open pull requests (#432, #442, #493, #621).
>
> I request discussion of language identification strings appropriate for
> use with that standard.
>
> (P.S., I hope that my system did not mangle anything in the foregoing.  I
> have seen weird copypaste behaviour mess up decomposed characters.  I
> thought of this after I searched for and collected some visually
> fascinating phrases; so I tried to normalize these to NFC...  It should go
> without saying, easyseed output the Japanese perfectly!)
>
>
> --
> null...@nym.zone | PGP ECC: 0xC2E91CD74A4C57A105F6C21B5A00591B2F307E0C
> Bitcoin: bc1qcash96s5jqppzsp8hy8swkggf7f6agex98an7h | (Segwit nested:
> 3NULL3ZCUXr7RDLxXeLPDMZDZYxuaYkCnG)  (PGP RSA: 0x36EBB4AB699A10EE)
> “‘If you’re not doing anything wrong, you have nothing to hide.’

Re: [bitcoin-dev] "Compressed" headers stream

2017-08-28 Thread Greg Sanders via bitcoin-dev
Well, if anything my question may bolster your use-case. If there's a
heavier chain that is invalid, I kind of doubt it matters for timestamping
reasons.

/digression

On Mon, Aug 28, 2017 at 12:25 PM, Riccardo Casatta <
riccardo.casa...@gmail.com> wrote:

>
> 2017-08-28 18:13 GMT+02:00 Greg Sanders :
>
>> Is there any reason to believe that you need Bitcoin "full security" at
>> all for timestamping?
>>
>
> This is a little bit out of the main topic of the email which is the
> savings in bandwidth in transmitting headers, any comment about that?
>
>
> P.S. As a personal experience timestamping is nowadays used to prove date
> and integrity of private databases containing a lot of value, so yes, in
> that cases I will go with Bitcoin "full security"
>
>
>>
>> On Mon, Aug 28, 2017 at 11:50 AM, Riccardo Casatta via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> Hi everyone,
>>>
>>> the Bitcoin headers are probably the most condensed and important piece
>>> of data in the world, their demand is expected to grow.
>>>
>>> When sending a stream of continuous block headers, a common case in IBD
>>> and in disconnected clients, I think there is a possible optimization of
>>> the transmitted data:
>>> The headers after the first could avoid transmitting the previous hash
>>> cause the receiver could compute it by double hashing the previous header
>>> (an operation he needs to do anyway to verify PoW).
>>> In a long stream, for example 2016 headers, the savings in bandwidth are
>>> about 32/80 ~= 40%
>>> without compressed headers 2016*80=161280 bytes
>>> with compressed headers 80+2015*48=96800 bytes
>>>
>>> What do you think?
>>>
>>>
>>> In OpenTimestamps calendars we are going to use this compression to give
>>> lite-client a reasonable secure proofs (a full node give higher security
>>> but isn't feasible in all situations, for example for in-browser
>>> verification)
>>> To speed up sync of a new client Electrum starts with the download of a
>>> file  ~36MB containing
>>> the first 477637 headers.
>>> For this kind of clients could be useful a common http API with fixed
>>> position chunks to leverage http caching. For example /headers/2016/0
>>> returns the headers from the genesis to the 2015 header included while
>>> /headers/2016/1 gives the headers from the 2016th to the 4031.
>>> Other endpoints could have chunks of 20160 blocks or 201600 such that
>>> with about 10 http requests a client could fast sync the headers
>>>
>>>
>>> --
>>> Riccardo Casatta - @RCasatta 
>>>
>>> ___
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>>
>>
>
>
> --
> Riccardo Casatta - @RCasatta 
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] "Compressed" headers stream

2017-08-28 Thread Greg Sanders via bitcoin-dev
Is there any reason to believe that you need Bitcoin "full security" at all
for timestamping?

On Mon, Aug 28, 2017 at 11:50 AM, Riccardo Casatta via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi everyone,
>
> the Bitcoin headers are probably the most condensed and important piece of
> data in the world, their demand is expected to grow.
>
> When sending a stream of continuous block headers, a common case in IBD
> and in disconnected clients, I think there is a possible optimization of
> the transmitted data:
> The headers after the first could avoid transmitting the previous hash
> cause the receiver could compute it by double hashing the previous header
> (an operation he needs to do anyway to verify PoW).
> In a long stream, for example 2016 headers, the savings in bandwidth are
> about 32/80 ~= 40%
> without compressed headers 2016*80=161280 bytes
> with compressed headers 80+2015*48=96800 bytes
>
> What do you think?
>
>
> In OpenTimestamps calendars we are going to use this compression to give
> lite-client a reasonable secure proofs (a full node give higher security
> but isn't feasible in all situations, for example for in-browser
> verification)
> To speed up sync of a new client Electrum starts with the download of a
> file  ~36MB containing
> the first 477637 headers.
> For this kind of clients could be useful a common http API with fixed
> position chunks to leverage http caching. For example /headers/2016/0
> returns the headers from the genesis to the 2015 header included while
> /headers/2016/1 gives the headers from the 2016th to the 4031.
> Other endpoints could have chunks of 20160 blocks or 201600 such that with
> about 10 http requests a client could fast sync the headers
>
>
> --
> Riccardo Casatta - @RCasatta 
>
> ___
> 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 Proposal] Partially Signed Bitcoin Transaction (PSBT) format

2017-08-22 Thread Greg Sanders via bitcoin-dev
If 'x' is public, that makes it identifiable and privacy-losing across
inputs.

To avoid "re-use" I suppose you'd want to sign some message like
`HMAC("ownership proof", H(A || x) )` instead. Otherwise any signature you
make using `A` ends up being used as a proof you don't know the input(this
seems like just details but to be more clear)...

To reiterate:

Sign `HMAC("ownership proof", H(A || x) )` using `A`. Public verifiers see
`HMAC("ownership proof", some_random_hash_connected_to_A )` and the HWW
that owns that input can recreate `some_random_hash_connected_to_A` by `H(A
|| x) )`

On Mon, Aug 21, 2017 at 2:36 PM, Jochen Hoenicke <hoeni...@gmail.com> wrote:

> On 21.08.2017 20:12, Greg Sanders via bitcoin-dev wrote:
> > To fix this I consulted with andytoshi and got something we think works
> > for both cases:
> >
> > 1) When a signing device receives a partially signed transaction, all
> > inputs must come with a ownership proof:
> > - For the input at address A, a signature over H(A || x) using the key
> > for A. 'x' is some private fixed key that only the signing device
> > knows(most likely some privkey along some unique bip32 path).
> > - For each input ownership proof, the HW wallet validates each signature
> > over the hashed message, then attempts to "decode" the hash by applying
> > its own 'x'. If the hash doesn't match, it cannot be its own input.
> > - Sign for every input that is yours
>
> Interesting, basically a proof of non-ownership :), a proof that the
> hardware wallet doesn't own the address.
>
> But shouldn't x be public, so that the device can verify the signature?
> Can you expand on this, what is exactly signed with which key and how is
> it checked?
>
> One also has to make sure that it's not possible to reuse signatures as
> ownership proof that were made for a different purpose.
>
>   Jochen
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] [BIP Proposal] Partially Signed Bitcoin Transaction (PSBT) format

2017-08-21 Thread Greg Sanders via bitcoin-dev
Some related thoughts and suggestion for an extension that kanzure
suggested I post here:

Hardware Wallet attacks by input ownership omission and fix
--
So a while back I realized that to have HW wallets do safe automated
coinjoins(without any user interaction be sure there are no fee dumps or
handing money to others) you have to protect yourself from the case of
signing one set of inputs while the other owned set is hidden from the
device, then repeating the same action with the two sets reversed.

Note that there is no support for such a mode in HW wallets today, but
could possibly greatly increase liquidity of JoinMarket like systems.

First signing pass:
1 BTC (yours, host tells ledger about it) 
>   1.5 BTC
1 BTC (yours, host fails to tell ledger about it)-

Second signing pass:

1 BTC (yours, host fails to tell ledger) -
>   1.5 BTC
1 BTC (yours, host tells ledger about it)-

In this scenario, you sign the first input, thinking "great I'm getting 0.5
BTC for running coinjoin" when in reality this will simply be re-played
again later with the inputs switched, *costing* you 0.5 BTC. (Ledger
doesn't support "negative fees", but imagine more more inputs are included
that aren't yours.)

More recently I noticed a more common issue along the same lines:

With Segwit inputs, the entire transaction referred to in the prevout is
generally no longer included for HW wallet signing API. This greatly speeds
up signing since potentially multiple MBs of transactions are no longer
passed into the device, but comes with a cost: An attacker can claim
certain inputs' value is much lower than it actually is. In the first pass,
the host reports the first input's value properly, and the second as lower.
The signature on the first input will go through fine(value included in the
sighash is only for that input), then attacker prompts a restart of
signing, reporting the 2nd value properly, and first value improperly low,
which allows the attacker to report the same fee twice on the device. Both
signatures over each input are correct, but the user was prompted with an
invalid fee amount(too low).

To fix this I consulted with andytoshi and got something we think works for
both cases:

1) When a signing device receives a partially signed transaction, all
inputs must come with a ownership proof:
- For the input at address A, a signature over H(A || x) using the key for
A. 'x' is some private fixed key that only the signing device knows(most
likely some privkey along some unique bip32 path).
- For each input ownership proof, the HW wallet validates each signature
over the hashed message, then attempts to "decode" the hash by applying its
own 'x'. If the hash doesn't match, it cannot be its own input.
- Sign for every input that is yours

This at a minimum makes sure that the wallet's total "balance" will not go
down more than the reported fee.

Benefits:
- Still small memory footprint compared to legacy signing
- Allows user-interactionless coinjoins without putting funds at risk
- These proofs can be created at any time, collected at the front of any
CoinJoin like protocol.
- These proofs can be passed around as additional fields for Partially
Signed Bitcoin Transactions:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-August/014838.html

On Sun, Aug 20, 2017 at 5:00 PM, Bryan Bishop via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Fri, Aug 18, 2017 at 5:11 PM, Andrew Chow via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> I would like to propose a standard format for unsigned and partially
>> signed transactions.
>>
>
> Just a quick note but perhaps you and other readers would find this thread
> (on hardware wallet BIP drafting) to be tangentially related and useful:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/
> 2016-August/013008.html
>
> - Bryan
> http://heybryan.org/
> 1 512 203 0507 <(512)%20203-0507>
>
> ___
> 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] Network-layer attacks

2017-05-09 Thread Greg Sanders via bitcoin-dev
See https://github.com/bitcoin/bips/blob/master/bip-0150.mediawiki and
https://github.com/bitcoin/bips/blob/master/bip-0151.mediawiki

On Tue, May 9, 2017 at 12:09 PM, Raystonn . via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> This study was released last week, detailing some attacks at the network
> layer: https://btc-hijack.ethz.ch/files/btc_hijack.pdf.  Of the
> countermeasures discussed in the paper, the use of encryption
> to secure communications between nodes looks like low hanging fruit.
>
>
> Raystonn
>
>
>
> ___
> 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] I do not support the BIP 148 UASF

2017-04-15 Thread Greg Sanders via bitcoin-dev
> Besides that, I also just don't believe that UASF itself as a method to
activate softforks is a good choice. The only two reliable signals we have
for this purpose in Bitcoin are block height (flag day) and standard miner
signaling, as every other metric can be falsified or gamed.

UASF can be just a flag day.

On Sat, Apr 15, 2017 at 9:23 AM, Natanael via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
>
> Den 15 apr. 2017 13:51 skrev "Chris Acheson via bitcoin-dev" <
> bitcoin-dev@lists.linuxfoundation.org>:
>
>
> Not sure if you missed my previous reply to you, but I'm curious about
> your thoughts on this particular point. I contend that for any UASF,
> orphaning non-signalling blocks on the flag date is [maybe] safer [for
> those in on the UASF fork] than just
> considering the fork active on the flag date.
>
>
> Note my additions.
>
> Enforcement by orphaning non-compliance makes it harder to reverse a buggy
> softfork, since you necessarily increase the effort needed to return enough
> mining power to the safe chain since you now have mostly unmonitored mining
> hardware fighting you actively, whose operators you might not be able to
> contact. You'd practically have to hardfork out of the situation.
>
> There's also the risk of the activation itself triggering concensus bugs
> (multiple incompatible UASF forks), if there's multiple implementations of
> it in the network (or one buggy one). We have already seen something like
> it happen. This can both happen on the miner side, client side or both
> (miner side only would lead to a ton of orphaned blocks, client side means
> netsplit).
>
> It is also not economically favorable for any individual miner to be the
> one to mine empty blocks on top of any surviving softfork-incompatible
> chain. As a miner you would only volunteer to do it if you believe the
> softfork is necessary or itself will enable greater future profit.
>
> Besides that, I also just don't believe that UASF itself as a method to
> activate softforks is a good choice. The only two reliable signals we have
> for this purpose in Bitcoin are block height (flag day) and standard miner
> signaling, as every other metric can be falsified or gamed.
>
> But there's also more problems - a big one is that we have no way right
> now for a node to tell another "the transaction you just relayed to me is
> invalid according to an active softfork" (or "will become invalid". This
> matters for several reasons.
>
> The first one that came to my mind is that we have widespread usage of
> zero-confirmation payments in the network.
>
> This was already dangerous for other reasons, but this UASF could make it
> guaranteed cost-free to exploit - because as many also know, we ALSO
> already have a lot of nodes that do not enforce the non-default rejection
> policies (otherwise we'd never see such transactions on blocks), including
> many alternative Bitcoin clients.
>
> The combination of these factors means that you can present an UASF
> invalid transaction to a non-updated client that is supposedly protected by
> the deliberate orphaning effort, and have it accept this as a payment. To
> never see it get confirmed, or to eventually see it doublespent by an
> UASF-valid transaction.
>
> I would not at all be surprised if it turned out that many
> zero-confirmation accepting services do not reject non-default
> transactions, or if they aren't all UASF-segwit aware.
>
> This is why a flag day or similar is more effective - it can't be ignored
> unlike "just another one of those UASF proposals" that you might not have
> evaluated or not expect to activate.
>
> This is by the way also a reason that I believe that all nodes and
> services should publish all concensus critical policies that they enforce.
> This would make it far easier to alert somebody that they NEED TO prepare
> for whatever proposal that might conflict with their active policies.
>
> ___
> 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] Using a storage engine without UTXO-index

2017-04-07 Thread Greg Sanders via bitcoin-dev
Interesting work.

I was wondering if you could tell us what specs for the machine being used
as preliminary benchmark is here: https://bitcrust.org/results ?

I'd be interested to also see comparisons with 0.14 which has some
improvements for script validation with more cores.

On Fri, Apr 7, 2017 at 4:47 AM, Tomas via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Thank you Marcos,
>
> Though written in Rust, bitcrust-db is definitely usable as pluggable
> module as its interface will be roughly some queries, add_tx and
> add_block with blobs and flags. (Bitcrust internally uses a
> deserialize-only model, keeping references to the blobs with the parsed
> data).
>
> However, from Core's side I believe network and storage are currently
> rather tightly coupled, which will make this far from trivial.
>
> Regardless, I am also hoping (with funding & a team) to build a Bitcrust
> networking component as well to bring a strong competitor to the market.
>
> best,
> Tomas
>
>
>
> On Fri, Apr 7, 2017, at 09:55, Marcos mayorga wrote:
> > Hi Tomas,
> >
> > I've read it and think it is an excellent work, I'd like to see it
> > integrated into bitcoin-core as a 'kernel module'.
> >
> > I see there are a lot of proof of concepts out there, IMO every one
> > deserve a room in the bitcoin client as a selectable feature, to make the
> > software more flexible and less dictatorial, an user could easily select
> > which features she wants to run.
> >
> > Best regards,
> > Marcos
> >
> > > I have been working on a bitcoin implementation that uses a different
> > > approach to indexing for verifying the order of transactions. Instead
> of
> > > using an index of unspent outputs, double spends are verified by using
> a
> > > spend-tree where spends are scanned against spent outputs instead of
> > > unspent outputs.
> > >
> > > This allows for much better concurrency, as not only blocks, but also
> > > individual inputs can be verified fully in parallel.
> > >
> > > I explain the approach at https://bitcrust.org, source code is
> available
> > > at https://github.com/tomasvdw/bitcrust
> > >
> > > I am sharing this not only to ask for your feedback, but also to call
> > > for a clear separation of protocol and implementations: As this
> > > solution, reversing the costs of outputs and inputs, seems to have
> > > excellent performance characteristics (as shown in the test results),
> > > updates to the protocol addressing the UTXO growth, might not be worth
> > > considering *protocol improvements* and it might be best to address
> > > these concerns as implementation details.
> > >
> > > Kind regards,
> > > Tomas van der Wansem
> > > to...@bitcrust.org
> > > Bitcrust
> > > ___
> > > 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 mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] Extension block proposal by Jeffrey et al

2017-04-05 Thread Greg Sanders via bitcoin-dev
I'd appreciate the authors chiming in, but I read the PASDA differently:

1) If a transaction is mined with a certain bit set, it reserves 700 bytes
for that particular block.
2) In that space, 2 transactions may happen:
a) First, a transaction penalizing the "parent" transaction for fraud by
spending the funds immediately
b) Second, a "free rider" transaction that penalizes fraud within a ~2 week
window

This means during systematic flooding of closing transactions by
Goldfinger, vigilant watchers of their channels can immediately punish the
fraud in the same block using (a), and if they are unable to, need to find
space within two weeks in (b).

This is really in the LN weeds however, so I'll refrain from evaluating the
efficacy of such a solution.

On Wed, Apr 5, 2017 at 10:05 AM, Olaoluwa Osuntokun via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi Y'all,
>
> Thanks to luke-jr and jl2012 for publishing your analysis of the
> xblocks proposal. I'd like to also present some analysis but instead focus
> on the professed LN safety enhancing scheme in the proposal. It's a bit
> underspecified, so I've taken the liberty of extrapolating a bit to fill
> in the gaps to the point that I can analyze it.
>
> TLDR; The xblock proposal includes a sub-proposal for LN which is
> essentially a block-size decrease for each open channel within the network.
> This decrease reserves space in blocks to allow honest parties guaranteed
> space in the blocks to punish dishonest channel counter parties. As a
> result
> the block size is permanently decreased for each channel open. Some may
> consider this cost prohibitively high.
>
> >> If the second highest transaction version bit (30th bit) is set to to
> `1`
> >> within an extension block transaction, an extra 700-bytes is reserved on
> >> the transaction space used up in the block.
>
> > Why wouldn't users set this on all transactions?
>
> As the proposal stands now, it seems that users _are_ able to unilaterally
> use this for all their Bitcoin transactions, as there's no additional cost
> to using the smart-contract safety feature outlined in the proposal.
>
> The new safety measures proposed near the end of this xblock proposal
> could itself consume a dedicated document outlining the prior background,
> context, and implications of this new safety feature. Throughout the rest
> of this post, I'll be referring to the scheme as a Pre-Allocated
> Smart-contract Dispute arena (PASDA, chosen because it sounds kinda like
> "pasta", which brings me many keks). It's rather insufficiently described
> and
> under specified as it stands in the proposal. As a result, if one doesn't
> have the necessary prior context, it might've been skipped over entirely
> as it's difficult to extract the sub-proposal from the greater proposal. I
> think I possess the necessary prior context required to required to
> properly analyze the sub-proposal. As a result, I would like to illuminate
> the readers of the ML so y'all may also be able to evaluate this
> sub-proposal independently.
>
>
> ## Background
>
> First, some necessary background. Within LN as it exists today there is
> one particularly nasty systematic risk related to blockchain availability
> in the case of a channel dispute. This risk is clearly outlined in the
> original white paper, and in my opinion a satisfactory solution to the
> risks which safe guard the use of very high-value channels has yet to be
> presented.
>
>
> ### Chain Spam/Censorship Attack Vector
>
> The attack vector mentioned in the original paper is a reoccurring attack
> in systems of this nature: DoS attacks. As it stands today, if a channel
> counterparty is able to (solely, or in collaboration with other attackers)
> prevent one from committing a transaction to the chain, they're able to
> steal money from the honest participant in the channel. The attack
> proceeds something like this:
>
>* Mallory opens a very large channel with me.
>* We transfer money back and forth in the channel as normal. The nature
>  of these transfers isn't very important. The commitment balances may
>  be modified due to Mallory making multi-hop payments through my
>  channel, or possibly from Mallory directly purchasing some goods I
>  offer, paying via the channel.
>* Let's call the current commitment number state S_i. In the lifetime
>  of the channel there may exist some state S_j (i < j) s.t Mallory's
>  balance in S_i, is larger than S_j.
>* At this point, depending on the value of the channel's time-based
>  security parameter (T) it may be possible for Mallory to broadcast
>  state S_i (which has been revoked), and prevent me being able to
>  include by my punishment transaction (PTX) within the blockchain.
>* If Mallory is able to incapacitate me for a period of time T, or
>  censor my transactions from the chain (either selectively or via a
>  spam attack), then at time K (K > T + B, 

Re: [bitcoin-dev] BIP draft: Extended block header hardfork

2017-04-04 Thread Greg Sanders via bitcoin-dev
That's BIP30, he linked BIP34:
https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L3004

On Tue, Apr 4, 2017 at 11:32 AM, Tom Zander via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Can you tell me where it is enforced?
>
> The only place I found was here;
> https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L1793
>
> which doesn’t enforce it, all that code does is check that the txid is
> unknown or fully spent.
> And since the below idea from Russel would change the txid, it would seem
> no
> full client would reject this.
>
> Maybe its in a BIP, but I can’t find it in the code.
>
> On Tuesday, 4 April 2017 16:59:12 CEST James Hilliard wrote:
> > It is a consensus rule
> > https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki
> >
> > On Tue, Apr 4, 2017 at 6:47 AM, Tom Zander via bitcoin-dev
> >
> >  wrote:
> > > On Sunday, 2 April 2017 22:39:13 CEST Russell O'Connor via bitcoin-dev
> > >
> > > wrote:
> > >>  Someone told me a while back that it would be more natural if we move
> > >>  the
> > >>
> > >> nHeight from the coinbase script to the coinbase locktime.  Have you
> > >> considered doing this?
> > >
> > > That change would not be a consensus change and thus free to make any
> > > day.
>
>
> --
> Tom Zander
> Blog: https://zander.github.io
> Vlog: https://vimeo.com/channels/tomscryptochannel
> ___
> 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] Three hardfork-related BIPs

2017-01-27 Thread Greg Sanders via bitcoin-dev
Note that the 4MB number comes from a single network metric.

Quotes directly from the paper in question:
http://fc16.ifca.ai/bitcoin/papers/CDE+16.pdf

>Our results hinge on the key metric of effective throughput in the overlay
network, which we define here as which blocks propagate within an average
block interval period the percentage of nodes to.
...
>Note that as we consider only a subset of possible metrics (due to
difficulty in accurately measuring others), our results on
reparametrization may be viewed as upper bounds: additional metrics could
reveal even stricter limits.

It says nothing about any mining centralization pressure, DoS attacks, etc.
A single metric among many we have to contend with.






On Fri, Jan 27, 2017 at 3:34 PM, Russell O'Connor via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
>
> On Jan 27, 2017 03:03, "Andrew Johnson via bitcoin-dev" <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Other researchers have come to the conservative conclusion that we could
> handle 4MB blocks today.
>
>
> I believe this is a mischaracterization of the research conclusions.  The
> actual conclusion was that the maximum value for the blocksize that the
> network can safely handle (at that time) is some value that is
> (conservatively) no more than 4MB.  This is because the research only
> studies one aspect of the effect of blocksize on the network at a time and
> the true safe value is the minimum of all aspects.  For example, the 4MB
> doesn't cover the aspect of quadratic hashing for large transactions in
> large blocks.
>
> ___
> 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] Transaction Replacement by Fee

2017-01-12 Thread Greg Sanders via bitcoin-dev
BIP125 is the standard way to signal:
https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki

Should explain everything you need.

On Thu, Jan 12, 2017 at 9:02 AM, Police Terror via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hello,
>
> Where can I find the rules on transaction replacement?
>
> For instance what are the valid ranges for the sequence values in
> transaction inputs? Normally I set this value to MAX_UINT32, and the
> locktime to 0.
>
> Can I change the outputs? Can I add more inputs to pay a higher fee?
>
> Just looking for clarity on this aspect of Bitcoin. Any resources would
> be much appreciated.
>
> Thanks.
> ___
> 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] Block size following technological growth

2015-07-30 Thread Greg Sanders via bitcoin-dev
What, if any, methods would be used for miners to communicate their
upgrade?

Greg

On Thu, Jul 30, 2015 at 10:25 AM, Pieter Wuille via bitcoin-dev 
bitcoin-dev@lists.linuxfoundation.org wrote:

 Hello all,

 here is a proposal for long-term scalability I've been working on:
 https://gist.github.com/sipa/c65665fc360ca7a176a6

 Some things are not included yet, such as a testnet whose size runs ahead
 of the main chain, and the inclusion of Gavin's more accurate sigop
 checking after the hard fork.

 Comments?

 --
 Pieter


 ___
 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