Re: [bitcoin-dev] [Lightning-dev] Inherited IDs - A safer, more powerful alternative to BIP-118 (ANYPREVOUT) for scaling Bitcoin

2021-09-24 Thread Jeremy via bitcoin-dev
John let me know that he's posted some responses in his Github repo https://github.com/JohnLaw2/btc-iids probably easiest to respond to him via e.g. a github issue or something. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org

[bitcoin-dev] Inherited IDs - A safer, more powerful alternative to BIP-118 (ANYPREVOUT) for scaling Bitcoin

2021-09-17 Thread Jeremy via bitcoin-dev
Bitcoin & LN Devs, The below is a message that was shared to me by an anon account on Telegram (nym: John Law). You can chat with them directly in the https://t.me/op_ctv or https://t.me/bips_activation group. I'm reproducing it here at their request as they were unsure of how to post to the

Re: [bitcoin-dev] TAPLEAF_UPDATE_VERIFY covenant opcode

2021-09-09 Thread Jeremy via bitcoin-dev
I'm a bit skeptical of the safety of the control byte. Have you considered the following issues? > The low bit of C indicates the parity of X; if it's 0, X has even y, > if it's 1, X has odd y. > > The next bit of C indicates whether the current script is dropped from > the merkle path, if it's

Re: [bitcoin-dev] TAPLEAF_UPDATE_VERIFY covenant opcode

2021-09-09 Thread Jeremy via bitcoin-dev
I like this proposal, I think it has interesting use cases! I'm quick to charitably Matt's comment, "I’ve been saying we need more covenants research and proposals before we move forward with one", as before we move forward with *any.* I don't think that these efforts are rival -- different

Re: [bitcoin-dev] Note on Sequence Lock Upgrades Defect

2021-09-08 Thread Jeremy via bitcoin-dev
ally start to > discourage the usage. Otherwise, by introducing new discouragement waivers, > e.g not rejecting the usage of the top 8 bits, I think we're moving away > from the policy design principle we're trying to establish (separation of > mempool policies signaling from co

Re: [bitcoin-dev] Reorgs on SigNet - Looking for feedback on approach and parameters

2021-09-07 Thread Jeremy via bitcoin-dev
If you make the to be reorged flag 2 bits, 1 bit can mark final block and the other can mark to be reorged. That way the nodes opting into reorg can see the reorg and ignore the final blocks (until a certain time? Or until it's via a reorg?), and the nodes wanting not to see reorgs get continuous

Re: [bitcoin-dev] Note on Sequence Lock Upgrades Defect

2021-09-05 Thread Jeremy via bitcoin-dev
uld be weird/bad to change the semantic in transaction version 3. -- @JeremyRubin <https://twitter.com/JeremyRubin> <https://twitter.com/JeremyRubin> On Sun, Sep 5, 2021 at 7:36 PM David A. Harding wrote: > On Fri, Sep 03, 2021 at 08:32:19PM -0700, Jeremy via bitcoin-dev

Re: [bitcoin-dev] Note on Sequence Lock Upgrades Defect

2021-09-04 Thread Jeremy via bitcoin-dev
In working on resolving this issue, one issue that has come up is what sequence values get used by wallet implementations? E.g., in Bitcoin Core a script test says BIP125_SEQUENCE_NUMBER = 0xfffd # Sequence number that is rbf-opt-in (BIP 125) and csv-opt-out (BIP 68) Are any other numbers

[bitcoin-dev] Note on Sequence Lock Upgrades Defect

2021-09-03 Thread Jeremy via bitcoin-dev
Hi Bitcoin Devs, I recently noticed a flaw in the Sequence lock implementation with respect to upgradability. It might be the case that this is protected against by some transaction level policy (didn't see any in policy.cpp, but if not, I've put up a blogpost explaining the defect and patching

Re: [bitcoin-dev] Is there a tool like Ethereum EVM at present for Bitcoin script?

2021-08-26 Thread Jeremy via bitcoin-dev
Will update those soon / in November. Sapio needs the rust Bitcoin taproot ecosystem to mature, as well as a spec for miniscript taproot (altho we can kinda monkey patch one in without it). To be honest, I had some technical difficulties with getting Libera to work and I gave up... But perhaps I

Re: [bitcoin-dev] Is there a tool like Ethereum EVM at present for Bitcoin script?

2021-08-26 Thread Jeremy via bitcoin-dev
This has actually never been true (Sapio assumes extensions). If the extensions are not present, you can stub them out with a signing federation instead, configurable as flags, and you can also write many contracts that do not use the ctv based components at all. The protocol for emulation is a

Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit

2021-08-19 Thread Jeremy via bitcoin-dev
one interesting point that came up at the bitdevs in austin today that favors remove that i believe is new to this discussion (it was new to me): the argument can be reduced to: - dust limit is a per-node relay policy. - it is rational for miners to mine dust outputs given their cost of

Re: [bitcoin-dev] src/httprpc.cpp InterruptHTTPRPC

2021-08-12 Thread Jeremy via bitcoin-dev
This is probably best to open as an issue in github! -- @JeremyRubin On Thu, Aug 12, 2021 at 11:03 AM Ali Sherief via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > I am using Bitcoin Core's HTTP RPC server as a

Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit

2021-08-09 Thread Jeremy via bitcoin-dev
You might be interested in https://eprint.iacr.org/2017/1066.pdf which claims that you can make CT computationally hiding and binding, see section 4.6. with respect to utreexo, you might review https://github.com/mit-dci/utreexo/discussions/249?sort=new which discusses tradeoffs between different

Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit

2021-08-08 Thread Jeremy via bitcoin-dev
some additional answers/clarifications > Question for Jeremy: would you also allow zero-value outputs? Or would > you just move the dust limit down to a fixed 1-sat? > I would remove it entirely -- i don't think there's a difference between the two realistically. > > Allowing 0-value or

Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit

2021-08-08 Thread Jeremy via bitcoin-dev
Under no circumstances do I think we should *increase* the dust limit. That would have a mildly confiscatory effect on current Lightning Channel operators, among others. Generally, the UTXO set will grow. We should work to accommodate the worst case scenario under current consensus rules. I think

[bitcoin-dev] Removing the Dust Limit

2021-08-08 Thread Jeremy via bitcoin-dev
We should remove the dust limit from Bitcoin. Five reasons: 1) it's not our business what outputs people want to create 2) dust outputs can be used in various authentication/delegation smart contracts 3) dust sized htlcs in lightning (

Re: [bitcoin-dev] Covenant opcode proposal OP_CONSTRAINDESTINATION (an alternative to OP_CTV)

2021-07-28 Thread Jeremy via bitcoin-dev
High level feedback: you should spec out the opcodes as separate pieces of functionality as it sounds like OP_CD is really 3 or 4 opcodes in one (e.g., amounts to outputs, output addresses, something with fees). One major drawback of your approach is that all transactions are twice as large as

Re: [bitcoin-dev] [Lightning-dev] Eltoo / Anyprevout & Baked in Sequences

2021-07-12 Thread Jeremy via bitcoin-dev
On Sun, Jul 11, 2021 at 10:01 PM Anthony Towns wrote: > On Thu, Jul 08, 2021 at 08:48:14AM -0700, Jeremy wrote: > > This would disallow using a relative locktime and an absolute > locktime > > for the same input. I don't think I've seen a use case for that so > far, > > but ruling it

Re: [bitcoin-dev] OP_CAT Makes Bitcoin Quantum Secure [was CheckSigFromStack for Arithmetic Values]

2021-07-09 Thread Jeremy via bitcoin-dev
I thought about this, but at the time of writing I couldn't come up with something I thought was substantially better. I spent a few more cycles thinking on it -- you can definitely do better. It's not clear how much better Winternitz might be, or if it would be secure in this context? Here's some

Re: [bitcoin-dev] Taproot Fields for PSBT

2021-07-08 Thread Jeremy via bitcoin-dev
Suggestion: It should be allowed that different keys can specify different sighash flags. As an example, if chaperone signatures were desired with anyprevout, it would be required to specify that the anyprevout key sign with APO and the chaperone sign with ALL. As another example, Sapio emulator

Re: [bitcoin-dev] Eltoo / Anyprevout & Baked in Sequences

2021-07-08 Thread Jeremy via bitcoin-dev
> > This would disallow using a relative locktime and an absolute locktime > for the same input. I don't think I've seen a use case for that so far, > but ruling it out seems suboptimal. I think you meant disallowing a relative locktime and a sequence locktime? I agree it is suboptimal. What

[bitcoin-dev] Eltoo / Anyprevout & Baked in Sequences

2021-07-07 Thread Jeremy via bitcoin-dev
I made a comment on https://github.com/bitcoin/bips/pull/943#issuecomment-876034559 but it occurred to me it is more ML appropriate. In general, one thing that strikes me is that when anyprevout is used for eltoo you're generally doing a script like: ``` IF 10 CSV DROP 1::musigkey(As,Bs)

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

2021-07-07 Thread Jeremy via bitcoin-dev
Hah -- ZmnSCPxj that post's a doozy -- but it more or less makes sense the argument you're making in favor of permitting recursion at the transaction level. One part that's less clear is if you can make a case against being recursive in Script fragments themselves -- ignoring bitcoin script for

[bitcoin-dev] OP_CAT Makes Bitcoin Quantum Secure [was CheckSigFromStack for Arithmetic Values]

2021-07-06 Thread Jeremy via bitcoin-dev
Dear Bitcoin Devs, As mentioned previously, OP_CAT (or similar operation) can be used to make Bitcoin "quantum safe" by signing an EC signature. This should work in both Segwit V0 and Tapscript, although you have to use HASH160 for it to fit in Segwit V0. See [my

Re: [bitcoin-dev] CHECKSIGFROMSTACK/{Verify} BIP for Bitcoin

2021-07-06 Thread Jeremy via bitcoin-dev
I don't think Elements engineering decisions or management timelines should have any bearing on what Bitcoin adopts, beyond learning what works/doesn't. Same as litecoin, dogecoin, or bitcoin cash :) With my understanding of elements it makes sense that you wouldn't want to break compatibility

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

2021-07-06 Thread Jeremy via bitcoin-dev
heh -- I pointed out these evil multisig covenants in 2015 :) https://medium.com/@jeremyrubin/regulating-bitcoin-by-mining-the-regulator-miner-attack-c8fd51185b78 I'm relatively unconcerned by it except to the extent that mining centralizes to the point of censoring other traffic. Overall, I

Re: [bitcoin-dev] CHECKSIGFROMSTACK/{Verify} BIP for Bitcoin

2021-07-06 Thread Jeremy via bitcoin-dev
Re-threading Sanket's comment on split R value: I also am in general support of the `OP_CHECKSIGFROMSTACK` opcode. We would > need to update the suggestion to BIP340, and add it to sigops budget. I > have no strong preference for splitting R and s values or variable-length > messages. > Back to

Re: [bitcoin-dev] CHECKSIGFROMSTACK/{Verify} BIP for Bitcoin

2021-07-04 Thread Jeremy via bitcoin-dev
> > Do you have concerns about sophisticated covenants, and if so, would you > mind describing them? Personally, not in particular worried about arbitrary covenants as I think that: 1 validation costs can be kept in check; 2 you're free to burn your coins it you want to. I *do* care that when

Re: [bitcoin-dev] CHECKSIGFROMSTACK/{Verify} BIP for Bitcoin

2021-07-04 Thread Jeremy via bitcoin-dev
I don't really see the point of CHECKSIGFROMSTACKADD since it's not bound to the txdata? When might you use this? And yes -- "Add OP_CHECKSIGFROMSTACK and OP_CHECKSIGFROMSTACKVERIFY to follow the semantics from bip340-342 when witness program is v1." is a bit light on detail for what the BIP

Re: [bitcoin-dev] CHECKSIGFROMSTACK/{Verify} BIP for Bitcoin

2021-07-03 Thread Jeremy via bitcoin-dev
tes. > > I think this design we are aiming for would be perfectly suited for > Bitcoin as well. > > On Sat, Jul 3, 2021 at 12:32 PM Jeremy via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> Reproduced below is the BIP text from Bitcoin Cash's (MIT-Li

[bitcoin-dev] CHECKSIGFROMSTACK/{Verify} BIP for Bitcoin

2021-07-03 Thread Jeremy via bitcoin-dev
Reproduced below is the BIP text from Bitcoin Cash's (MIT-Licensed) specification for "CheckDataSig", more or less the same thing as CHECKSIGFROMSTACK https://github.com/bitcoincashorg/bitcoincash.org/blob/master/spec/op_checkdatasig.md. In contrast to Element's implementation, it does not have

[bitcoin-dev] Templates, Eltoo, and Covenants, Oh My!

2021-07-03 Thread Jeremy via bitcoin-dev
Dear Bitcoin Devs, I recently put a blog post up which is of interest for this list. Post available here: https://rubin.io/blog/2021/07/02/covenants/ (text reproduced below for archives). The main technical points of interest for this list are: 1) There's a similar protocol to Eltoo built with

Re: [bitcoin-dev] CheckSigFromStack for Arithmetic Values

2021-07-02 Thread Jeremy via bitcoin-dev
Yep -- sorry for the confusing notation but seems like you got it. C++ templates have this issue too btw :) One cool thing is that if you have op_add for arbitrary width integers or op_cat you can also make a quantum proof signature by signing the signature made with checksig with the lamport.

[bitcoin-dev] CheckSigFromStack for Arithmetic Values

2021-07-02 Thread Jeremy via bitcoin-dev
Dear Bitcoin Devs, It recently occurred to me that it's possible to do a lamport signature in script for arithmetic values by using a binary expanded representation. There are some applications that might benefit from this and I don't recall seeing it discussed elsewhere, but would be happy for a

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

2021-06-26 Thread Jeremy via bitcoin-dev
If the parties trust each other, rbf is still opt-in. Just don't do it? On Sat, Jun 26, 2021, 9:30 AM Billy Tetrud via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > services providers are offering zero-conf channels, where you can start > to spend instantly [0]. I believe

Re: [bitcoin-dev] A Stroll through Fee-Bumping Techniques : Input-Based vs Child-Pay-For-Parent

2021-06-13 Thread Jeremy via bitcoin-dev
The API of a sponsor-like mechanism is close to ideal in my opinion: - compatible with non malleable transactions - 0 overhead if fees accurately estimated - watchtower friendly - post hoc, requires minimal 'protocol awareness' - friendly with most mempool eviction policies, not much new required

Re: [bitcoin-dev] Opinion on proof of stake in future

2021-05-10 Thread Jeremy via bitcoin-dev
re: 2, there's been some promising developments with Verifiable Delay Functions that make me think that the block regulation problems are solvable without requiring brute-force search proof of work. Are those inapplicable for some reason? ___ bitcoin-dev

Re: [bitcoin-dev] Opinion on proof of stake in future

2021-05-07 Thread Jeremy via bitcoin-dev
Proof-of-stake tends towards oligopolistic control, which is antithetical to bitcoin. Proof-of-stake also has some other security issues that make it a bad substitute for Proof-of-work with respect to equivocation (reorgs). Overall you'll find me *personally* in the camp that it's OK to explore

Re: [bitcoin-dev] Fee estimates and RBF

2021-04-30 Thread Jeremy via bitcoin-dev
Hi Prayank, Very glad to hear you are weathering the storm OK, wishing you and yours safety in the weeks ahead. I think you'll be interested to see https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html especially with regards to background services. In the long

Re: [bitcoin-dev] [Pre-BIP] Motivating Address type for OP_RETURN

2021-04-24 Thread Jeremy via bitcoin-dev
Zac -- this is kind of offtopic for this thread, which is primarily to do with making software/standards that supports existing practices in the bitcoin community rather than new standards/formats for a similar task. I think there have been some other related posts recently where it might be more

Re: [bitcoin-dev] [Pre-BIP] Motivating Address type for OP_RETURN

2021-04-24 Thread Jeremy via bitcoin-dev
I guess in the interest of being clear; I don't particularly want a OP_RETURN address either, they're just annoying to program around, and they exist historically, as well as perhaps in the future. Maybe people will start using the annex space to add any metadata required? E.g. stealth addresses.

Re: [bitcoin-dev] [Pre-BIP] Motivating Address type for OP_RETURN

2021-04-24 Thread Jeremy via bitcoin-dev
Inline responses On Fri, Apr 23, 2021, 11:18 AM David A. Harding wrote: > On Tue, Apr 20, 2021 at 08:46:07AM -0700, Jeremy via bitcoin-dev wrote: > > > > > > * > Script is technically "too wide" a type as what I really want is to > > only return coins wit

Re: [bitcoin-dev] [Lightning-dev] L2s Onchain Support IRC Workshop

2021-04-23 Thread Jeremy via bitcoin-dev
I'd be excited to join. Recommend bumping the date to mid June, if that's ok, as many Americans will be at Bitcoin 2021. I was thinking about reviving the sponsors proposal with a 100 block lock on spending a sponsoring tx which would hopefully make less controversial, this would be a great

Re: [bitcoin-dev] Proposed BIP editor: Kalle Alm

2021-04-22 Thread Jeremy via bitcoin-dev
ACK adding Kalle. Kalle is a qualified reviewer / editor and well suited for this role. -- @JeremyRubin On Thu, Apr 22, 2021 at 7:09 PM Luke Dashjr via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Unless there

[bitcoin-dev] And Then What? Defining a Complete Process for Upgrades

2021-04-22 Thread Jeremy via bitcoin-dev
This letter is particularly aimed at addressing Rusty Russell's quest for a development process that respects all groups in a balance of powers. However, in the spirit of open discussion, I'm sending it directly to the list. This proposal is aimed to be compatible with Taproot's ST, and I hope

[bitcoin-dev] [Pre-BIP] Motivating Address type for OP_RETURN

2021-04-20 Thread Jeremy via bitcoin-dev
Hi All, Introducing the notion that we might want to have an address type defined for OP_RETURN. I came across this when writing some code that wanted to handle common classes of user transactions generically, it's kind of annoying that you have to write code that's effectively: ``` try {

[bitcoin-dev] Taproot Activation Meeting 4/20 Cancelled

2021-04-17 Thread Jeremy via bitcoin-dev
Dear Bitcoin Developers, There are no current agenda items or technical issues to weed out, everything has been through the grinder, and Bitcoin Core seems to be on a roll with getting Release Candidate 1 with Speedy Trial MTP in the pipe. If anyone is hazy on the details -- it has been a little

Re: [bitcoin-dev] Gradual transition to an alternate proof without a hard fork.

2021-04-16 Thread Jeremy via bitcoin-dev
I think you need to hard deprecate the PoW for this to work, otherwise all old miners are like "toxic waste". Imagine one miner turns on a S9 and then ramps up difficulty for everyone else. On Fri, Apr 16, 2021, 2:08 PM Erik Aronesty via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org>

Re: [bitcoin-dev] Designing Bitcoin Smart Contracts with Sapio (available on Mainnet today)

2021-04-16 Thread Jeremy via bitcoin-dev
Hi ZmnSCPxj, Funny you mention BlueSpec -- I actually took 6.175[1] in my undergraduate studies with Arvind, BlueSpec's creator, and have often cited it as an inspiration for Sapio given that the target of program compilation is essentially a transaction circuit and I have a decent amount of

Re: [bitcoin-dev] BIP - limiting OP_RETURN / HF

2021-04-16 Thread Jeremy via bitcoin-dev
For every workaround, someone may have a long lost stash that you'd be confiscating :) https://bitcoin.stackexchange.com/questions/90127/why-does-this-coinbase-transaction-have-two-op-return-outputs ___ bitcoin-dev mailing list

Re: [bitcoin-dev] BIP - limiting OP_RETURN / HF

2021-04-16 Thread Jeremy via bitcoin-dev
NACK -- I happen to have a vault where I made emergency backup pre-signed transactions containing two OP_RETURN outputs and have subsequently lost the private key in an unfortunate boating incident. This proposed rule change would serve to confiscate my funds. -- @JeremyRubin

Re: [bitcoin-dev] Taproot activation meeting on IRC - Tuesday 13th April 19:00 UTC

2021-04-10 Thread Jeremy via bitcoin-dev
I concur that reviewing #21377 is the best path at this time. However, I want to draw attention to the middle road here: If Core chooses to not release activation params (which has been discussed as a general concept previously), #21377 can also be used to safely issue a community release. It's

Re: [bitcoin-dev] maximum block height on transaction

2021-04-09 Thread Jeremy via bitcoin-dev
You could accomplish your rough goal by having: tx A: desired expiry at H tx B: nlocktime H, use same inputs as A, create outputs equivalent to inputs (have to be sure no relative timelocks) Thus after a timeout the participants in A can cancel the action using TX B. The difference is the

[bitcoin-dev] Designing Bitcoin Smart Contracts with Sapio (available on Mainnet today)

2021-04-08 Thread Jeremy via bitcoin-dev
Bitcoin Developers, I'm very excited to introduce Sapio[0] formally to you all. Sapio empowers Bitcoin Developers to craft smart contracts in an intuitive, safe, and composable way. Sapio challenges the notion that you can't make complex smart contracts for

Re: [bitcoin-dev] Taproot Activation Meeting Notes, April 6th: The CoinFlip

2021-04-06 Thread Jeremy via bitcoin-dev
Update: the coin has flipped in favor of MTP https://blockstream.info/block/a6bcbf09849fe895b5d18ed884e8d558a57fc4f5e95c Further, there seems to be some agreement between Andrew and AJ w.r.t. reverting one of the changes AJ made recently (

[bitcoin-dev] Taproot Activation Meeting Notes, April 6th: The CoinFlip

2021-04-06 Thread Jeremy via bitcoin-dev
Bitcoin Developers, The second fortnightly taproot activation meeting has just concluded. Below are my notes: 1) On AJ's mods to MTP - luke-jr is still NACK any MTP related thing - It is generally uncontested that the Mods are fine; that it should be LOT (via LAST_CHANCE) compatible -

Re: [bitcoin-dev] Taproot Activation Meeting Reminder: April 6th 19:00 UTC bitcoin/bitcoin-dev

2021-04-05 Thread Jeremy via bitcoin-dev
l" is a retarget period here... Code: https://gist.github.com/ajtowns/fbcf30ed9d0e1708fdc98a876a04ff69#file-repeated_trials-py -- @JeremyRubin <https://twitter.com/JeremyRubin> <https://twitter.com/JeremyRubin> On Mon, Apr 5, 2021 at 3:35 AM Anthony Towns wrote: > On S

[bitcoin-dev] Taproot Activation Meeting Reminder: April 6th 19:00 UTC bitcoin/bitcoin-dev

2021-04-03 Thread Jeremy via bitcoin-dev
We'll be having another meeting this Tuesday, as per https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018699.html. If you can't make it feel free to leave a comment on any agenda item below, or if you think there are other things to be discussed. Agenda: 1. AJ's update to MTP

[bitcoin-dev] Response to Rusty Russell from Github

2021-03-25 Thread Jeremy via bitcoin-dev
In response to https://gist.github.com/michaelfolkson/92899f27f1ab30aa2ebee82314f8fe7f#gistcomment-3679489, reproduced below. Rusty, I concur with the gist of what you're saying -- Speedy Trial alone is not the final word on activation logic. There are likely better procedures for releasing and

Re: [bitcoin-dev] March 23rd 2021 Taproot Activation Meeting Notes

2021-03-25 Thread Jeremy via bitcoin-dev
25, 2021, 12:02 AM Anthony Towns wrote: > On Tue, Mar 23, 2021 at 08:46:54PM -0700, Jeremy via bitcoin-dev wrote: > > 3. Parameter Selection > > - There is broad agreement that we should target something like a May 1st > > release, with 1 week from rc1 starttime/startheigh

Re: [bitcoin-dev] March 23rd 2021 Taproot Activation Meeting Notes

2021-03-24 Thread Jeremy via bitcoin-dev
Michael, Your response strikes me as ingenuine with regards to "other projects" as it is a project I understand you to be one of the parties spearheading. I think it's misleading to not clarify that in your response. Your NACK on MTP based ST does not have any merit. The only argument you made

[bitcoin-dev] March 23rd 2021 Taproot Activation Meeting Notes

2021-03-23 Thread Jeremy via bitcoin-dev
We had a very productive meeting today. Here is a summary of the meeting -- I've done my best to summarize in an unbiased way. Thank you to everyone who attended. 1. On the use of a speedy trial variant: - There are no new objections to speedy trial generally. - There is desire to know if Rusty

Re: [bitcoin-dev] (Recurring) Taproot activation meeting on IRC - Tuesday 23rd March 19:00 UTC + every fortnight

2021-03-21 Thread Jeremy via bitcoin-dev
Meeting Reminder: A few people have pinged me asking when the meeting is. It is in the title of the email, apologies if that was unclear. 19:00 UTC this Tuesday (12pm Pacific Time). If you would like to pre-register a comment please try to send it to the list today or tomorrow if possible, it

[bitcoin-dev] (Recurring) Taproot activation meeting on IRC - Tuesday 23rd March 19:00 UTC + every fortnight

2021-03-19 Thread Jeremy via bitcoin-dev
BEGIN:VCALENDAR PRODID:-//Google Inc//Google Calendar 70.9054//EN VERSION:2.0 CALSCALE:GREGORIAN METHOD:PUBLISH X-WR-CALNAME:Bitcoin X-WR-TIMEZONE:America/Los_Angeles BEGIN:VTIMEZONE TZID:America/Los_Angeles X-LIC-LOCATION:America/Los_Angeles BEGIN:DAYLIGHT TZOFFSETFROM:-0800 TZOFFSETTO:-0700

Re: [bitcoin-dev] Delegated signatures in Bitcoin within existing rules, no fork required

2021-03-17 Thread Jeremy via bitcoin-dev
ZmnSCPxj, The chief reason to use SIGHASH_NONE (or SIGHASH_SINGLE for partial funds delegations) is to make it so that the delegator can dynamically choose things like a change output. Otherwise you need to know exactly what you want beforehand. I'd note that you can also achieve a decent amount

Re: [bitcoin-dev] Delegated signatures in Bitcoin within existing rules, no fork required

2021-03-16 Thread Jeremy via bitcoin-dev
inline responses -- @JeremyRubin On Mon, Mar 15, 2021 at 11:10 PM ZmnSCPxj wrote: > Good morning Jeremy, > > This is a very cool idea! > > > Multiple Delegates: By signing a txn with several delegate outputs, it > is possible

Re: [bitcoin-dev] PSA: Taproot loss of quantum protections

2021-03-15 Thread Jeremy via bitcoin-dev
I think Luke is pointing out that with the Signature and the Message you should be able to recover the key. if your address is H(P) and the message is H(H(P) || txn), then the you can use the public H(P) and the signature to recover the PK and verify that H(P) == P (I think you then don't even

Re: [bitcoin-dev] Taproot activation meeting on IRC - Tuesday 16th March 19:00 UTC

2021-03-15 Thread Jeremy via bitcoin-dev
Can you expand on the timeline issue? Which timelines are incompatible and why? It does seem like a release done *today* cannot happen anyways, so it sounds like it's already too late... or do you mean beginning the release process today? -- @JeremyRubin

Re: [bitcoin-dev] Taproot activation meeting on IRC - Tuesday 16th March 19:00 UTC

2021-03-15 Thread Jeremy via bitcoin-dev
Please announce such meetings with more than ~24 hours notice -- this has happened several times and while I recognize the pace of development on this issue I think that slotting a consensus meeting with less than 24 hours is inappropriate. I think we should proactively postpone it a week so that

[bitcoin-dev] Delegated signatures in Bitcoin within existing rules, no fork required

2021-03-10 Thread Jeremy via bitcoin-dev
I'm aware that some folks (I think nullc, sipa, myself... maybe more?) are aware of how to do script delegation in Bitcoin today (without any modifications to Bitcoin), but realized in a conversation with Andrew P that the technique is not widely known. So I figured it made sense to do a brief

[bitcoin-dev] Taproot: What are you building?

2021-03-06 Thread Jeremy via bitcoin-dev
Hi! As a minor diversion while discussing activation parameters, I felt it would be meaningful to collect a survey on what people are already using Taproot for in either conceptual, prototype, or implemented/spec phases. I suspect there are a lot of people tinkering with Taproot one way or

Re: [bitcoin-dev] Taproot activation proposal "Speedy Trial"

2021-03-05 Thread Jeremy via bitcoin-dev
Thank you for resurfacing and collating this concept. At this time I don't see major issues with this course of action and think it represents not only a reasonable compromise between all different perspectives, but also gives us an opportunity to learn more about less 'slow' yet safe consensus

[bitcoin-dev] In defense of a configurable LOT if LOT=false is released

2021-03-01 Thread Jeremy via bitcoin-dev
The short script* below could function as a cross platform (need only have python 2 and curl) way to make a LOT=False function like a LOT=true node. This sort of script was mentioned recently in the ##taproot-activation IRC channel. It is unclear to me with this sort of script what happens if a

Re: [bitcoin-dev] Straight Flag Day (Height) Taproot Activation

2021-02-28 Thread Jeremy via bitcoin-dev
s been correctly reconfigured) generating invalid blocks. > > As for "Taproot" took too long, hey, at least if its locked in people can > just build things assuming it exists. Some > already are, but once its clearly locked in, there's no reason to not > continue other work at the sa

Re: [bitcoin-dev] Straight Flag Day (Height) Taproot Activation

2021-02-28 Thread Jeremy via bitcoin-dev
I agree with much of the logic presented by Matt here. BIP8 was intended to be simpler to agree on to maintain consensus, yet we find ourselves in a situation where a "tiny" parameter has the potential to cause great network disruption and confusion (rationality is not too useful a concept here

Re: [bitcoin-dev] Taproot NACK

2021-02-27 Thread Jeremy via bitcoin-dev
I have good news for you: Taproot does not enable monero-like privacy features any moreso than already exist in Bitcoin today. At its core, taproot is a way to make transactions with embedded smart contracts less expensive, done so in a manner that may marginally improve privacy dependent on user

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

2021-02-22 Thread Jeremy via bitcoin-dev
Not responding to anyone in particular, but it strikes me that one can think about the case where a small minority (let's say H = 20%?) of nodes select the opposite of what Core releases (LOT=false, LOT=true). I'm ignoring the case where a critical bug is discovered in Taproot for reasons I could

Re: [bitcoin-dev] Proposal to stop processing of unrequested transactions in Bitcoin Core

2021-02-11 Thread Jeremy via bitcoin-dev
I'm not sure of the existing behavior is of when we issue a getdata request, but noting that there could be a privacy implication of this sort of change. Could you (or someone else) expand on why this is not a concern here? -- @JeremyRubin

[bitcoin-dev] Extension to BIP Format for Multiple Required SigHash Flags

2021-01-10 Thread Jeremy via bitcoin-dev
- *# The Issue:* - Currently the PSBT BIP has a slight "conceptual gap" where it is possible to both: - - 1) Have a PSBT which obtains multiple signatures per-input with any set of SIGHASH Flags - 2) Have a PSBT which obtains multiple signatures per-input with a fixed SigHash type applying to all

Re: [bitcoin-dev] New PSBT version proposal

2021-01-01 Thread Jeremy via bitcoin-dev
One thing I think should be added in V2 is the ability to specify sighash flags per-key as opposed to per-input. The per-key restriction is unfitting given that there are circumstances where multisig signers may validate heterogenous logic. -- @JeremyRubin

Re: [bitcoin-dev] Floating-Point Nakamoto Consensus

2020-09-25 Thread Jeremy via bitcoin-dev
If I understand correctly, this is purely a policy level decision to accept first-seen or a secondary deterministic test, but the most-work chain is still always better than a "more fit" but less work chain. In any case, I'm skeptical of the properties of this change. First-seen has a nice

Re: [bitcoin-dev] A Replacement for RBF and CPFP: Non-Destructive TXID Dependencies for Fee Sponsoring

2020-09-23 Thread Jeremy via bitcoin-dev
Hi Suhas, Thanks for your thoughtful response! Overall I'll boil down my thoughts to the following: If we can eventually come up with something clever at the user+policy layer to emulate a sponsor like mechanism, I would still greatly prefer to expose that sort of functionality directly and in

Re: [bitcoin-dev] A Replacement for RBF and CPFP: Non-Destructive TXID Dependencies for Fee Sponsoring

2020-09-21 Thread Jeremy via bitcoin-dev
Responses Inline: Would it make sense that, instead of sponsor vectors > pointing to txids, they point to input outpoints? E.g.: > > 1. Alice and Bob open a channel with funding transaction 0123...cdef, >output 0. > > 2. After a bunch of state updates, Alice unilaterally broadcasts a >

Re: [bitcoin-dev] A Replacement for RBF and CPFP: Non-Destructive TXID Dependencies for Fee Sponsoring

2020-09-19 Thread Jeremy via bitcoin-dev
Antoine, Yes I think you're a bit confused on where the actual sponsor vector is. If you have a transaction chain A->B->C and a sponsor S_A, S_A commits to txid A and A is unaware of S. W.r.t your other points, I fully agree that the 1-to-N sponsored case is very compelling. The consensus rules

Re: [bitcoin-dev] A Replacement for RBF and CPFP: Non-Destructive TXID Dependencies for Fee Sponsoring

2020-09-19 Thread Jeremy via bitcoin-dev
Hi David! Thanks for taking a look, and great question. > Is this in the reference implementation? It is indeed in the reference implementation. Please see https://github.com/bitcoin/bitcoin/compare/master...JeremyRubin:subsidy-tx#diff-24efdb00bfbe56b140fb006b562cc70bR741-R743 There is no

Re: [bitcoin-dev] A Replacement for RBF and CPFP: Non-Destructive TXID Dependencies for Fee Sponsoring

2020-09-19 Thread Jeremy via bitcoin-dev
Hi Cory! Thanks for taking a look. CC nopara as I think your questions are the same. I think there are a few reason we won't see functionally worse privacy: 1. RBF/CPFP may require the use of an external to the original transaction to pay sufficient fee. 2. RBF/CPFP may leak which address was

[bitcoin-dev] A Replacement for RBF and CPFP: Non-Destructive TXID Dependencies for Fee Sponsoring

2020-09-18 Thread Jeremy via bitcoin-dev
Hi Bitcoin Devs, I'd like to share with you a draft proposal for a mechanism to replace CPFP and RBF for increasing fees on transactions in the mempool that should be more robust against attacks. A reference implementation demonstrating these rules is available

Re: [bitcoin-dev] BIP OP_CHECKTEMPLATEVERIFY

2020-09-03 Thread Jeremy via bitcoin-dev
It's also not something that's trivial to set up in any scheme because you have to have an ordering around when you set up the tx intended to be the inverse lock before you create the tx using it. -- @JeremyRubin On Thu, Sep

Re: [bitcoin-dev] BIP OP_CHECKTEMPLATEVERIFY

2020-09-03 Thread Jeremy via bitcoin-dev
CTV does not enable this afaiu because it does not commit to the inputs (otherwise there's a hash cycle for predicting the output's TXID. -- @JeremyRubin On Thu, Sep 3, 2020 at 7:39 AM Dmitry Petukhov wrote: > Just had an

Re: [bitcoin-dev] reviving op_difficulty

2020-09-02 Thread Jeremy via bitcoin-dev
Yep this is a good example construction. I'd also point out that modulo a privacy improvement, you can also script it as something like: IF IF CLTV B DROP CHECKSIG ELSE CLTV DROP A CHECKSIG ENDIF ELSE 2 A B 2 CHECKMULTI ENDIF This way you equivalently have cooperative closing / early closing

Re: [bitcoin-dev] New tipe of outputs that saves space and give more privacy

2020-08-25 Thread Jeremy via bitcoin-dev
You may wish to review bip-119 ChecktemplateVerify, as it is designed to support something very similar to what you've described. You can see more at https://utxos.org On Tue, Aug 25, 2020, 6:48 AM Jule.Adka via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hey, there! I have a

Re: [bitcoin-dev] Generalizing feature negotiation when new p2p connections are setup

2020-08-24 Thread Jeremy via bitcoin-dev
On Mon, Aug 24, 2020 at 1:17 PM Eric Voskuil wrote: > I said security, not privacy. You are in fact exposing the feature to any > node that wants to negotiate for it. if you don’t want to expose the buggy > feature, then disable it. Otherwise you cannot prevent peers from accessing > it.

Re: [bitcoin-dev] Generalizing feature negotiation when new p2p connections are setup

2020-08-24 Thread Jeremy via bitcoin-dev
> > > > > > > * >> On 8/21/20 5:17 PM, Jeremy wrote: >> As for an example of where you'd > want multi-round, you could imagine a scenario where you have a feature A > which gets bugfixed by the introduction of feature B, and you don't want to > expose that you support A unless you first negotiate

Re: [bitcoin-dev] Generalizing feature negotiation when new p2p connections are setup

2020-08-21 Thread Jeremy via bitcoin-dev
As for an example of where you'd want multi-round, you could imagine a scenario where you have a feature A which gets bugfixed by the introduction of feature B, and you don't want to expose that you support A unless you first negotiate B. Or if you can negotiate B you should never expose A, but

Re: [bitcoin-dev] Generalizing feature negotiation when new p2p connections are setup

2020-08-21 Thread Jeremy via bitcoin-dev
Actually we already have service bits (which are sadly limited) which allow negotiation of non bilateral feature support, so this would supercede that. -- @JeremyRubin On Fri, Aug 21, 2020 at 1:45 PM Matt Corallo wrote: > This

Re: [bitcoin-dev] Generalizing feature negotiation when new p2p connections are setup

2020-08-21 Thread Jeremy via bitcoin-dev
I have a proposal: Protocol >= 70016 cease to send or process VERACK, and instead use HANDSHAKEACK, which is completed after feature negotiation. This should make everyone happy/unhappy, as in a new protocol number it's fair game to change these semantics to be clear that we're acking more than

Re: [bitcoin-dev] Generalizing feature negotiation when new p2p connections are setup

2020-08-16 Thread Jeremy via bitcoin-dev
Concept ack! It might be nice to include a few negotiation utility functions either in this bip or at the same time in a separate bip. An example we might want to include is a "polite disconnect", whereby a node can register that you don't want to connect in the future due to incompatibility. It

Re: [bitcoin-dev] CoinPool, exploring generic payment pools for Fun and Privacy

2020-06-11 Thread Jeremy via bitcoin-dev
Stellar work Antoine and Gleb! Really excited to see designs come out on payment pools. I've also been designing some payment pools (I have some not ready code I can share with you guys off list), and I wanted to share what I learned here in case it's useful. In my design of payment pools, I

[bitcoin-dev] [was BIP OP_CHECKTEMPLATEVERIFY] Fee Bumping Operation

2020-06-08 Thread Jeremy via bitcoin-dev
te: > В Sun, 7 Jun 2020 15:45:16 -0700 > Jeremy via bitcoin-dev wrote: > > > What I think we'll eventually land on is a way of doing a tx > > that contributes fee to another tx chain as a passive observer to > > them. While this breaks one abstraction around how depen

  1   2   >