Re: [bitcoin-dev] BIP process friction

On 2024-01-16 16:42, Anthony Towns via bitcoin-dev wrote: I'm switching inquisition over to having a dedicated "IANA"-ish thing that's independent of BIP process nonsense. It's at: * https://github.com/bitcoin-inquisition/binana If people want to use it for bitcoin-related proposals that

Re: [bitcoin-dev] Lamport scheme (not signature) to economize on L1

On 2024-01-01 00:17, yuri...@pm.me wrote: I'm afraid I didn't understand your objection. [...] I suspect my proposed scheme can be implemented with available, existing Bitcoin infrastructure. Is a soft fork or a hard fork required? If so, the proposal will need a lot of peer review and user

Re: [bitcoin-dev] Lamport scheme (not signature) to economize on L1

Hi Yuri, I think it's worth noting that for transactions with an equal number of P2TR keypath spends (inputs) and P2TR outputs, the amount of space used in a transaction by the serialization of the signature itself (16 vbytes per input) ranges from a bit over 14% of transaction size (1-input,

Re: [bitcoin-dev] Scaling Lightning Safely With Feerate-Dependent Timelocks

On 2023-12-29 15:17, Nagaev Boris wrote: Feerate-Dependent Timelocks do create incentives to accept out-of-band fees to decrease in-band fees and speed up mining of transactions using FDT! Miners can make a 5% discount on fees paid out-of-band and many people will use it. Observed fees decrease

Re: [bitcoin-dev] Scaling Lightning Safely With Feerate-Dependent Timelocks

On 2023-12-28 08:42, Eric Voskuil via bitcoin-dev wrote: Assuming a “sufficient fraction” of one of several economically rational behaviors is a design flaw. The amount of effort it takes a user to pay additional miners out of band is likely to increase much faster than probability that the

Re: [bitcoin-dev] Scaling Lightning Safely With Feerate-Dependent Timelocks

On 2023-12-28 08:06, jlspc via bitcoin-dev wrote: On Friday, December 22nd, 2023 at 8:36 AM, Nagaev Boris wrote: To validate a transaction with FDT [...] a light client would have to determine the median fee rate of the recent blocks. To do that without involving trust, it has to download the

Re: [bitcoin-dev] Future of the bitcoin-dev mailing list

On 2023-11-07 05:37, Bryan Bishop via bitcoin-dev wrote: What about [...] delvingbitcoin.org? I'm only willing to consider discussion groups that provide good archives, so I think it's worth noting that James O'Beirne has written code[1] and is currently maintaining a git repo[2] with a

Re: [bitcoin-dev] Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us"

On 2023-10-21 18:49, Nadav Ivgi via bitcoin-dev wrote: Could this be addressed with an OP_CSV_ALLINPUTS, a covenant opcode that requires _all_ inputs to have a matching nSequence, and using `1 OP_CSV_ALLINPUTS` in the HTLC preimage branch? This would prevent using unconfirmed outputs in the

Re: [bitcoin-dev] OP_Expire and Coinbase-Like Behavior: Making HTLCs Safer by Letting Transactions Expire Safely

On 2023-10-20 14:09, Peter Todd via bitcoin-dev wrote: The basic problem here is after the HTLC-timeout path becomes spendable, the HTLC-preimage path remains spendable. That's bad, because in this case we want spending the HTLC-preimage - if possible - to have an urgency attached to it to

Re: [bitcoin-dev] Actuarial System To Reduce Interactivity In N-of-N (N > 2) Multiparticipant Offchain Mechanisms

On September 8, 2023 3:27:38 PM HST, ZmnSCPxj via bitcoin-dev wrote: >Now, suppose that participant A wants B to be assured that >A will not double-spend the transaction. >Then A solicits a single-spend signature from the actuary, >getting a signature M: > >current state

Re: [bitcoin-dev] BIP for Serverless Payjoin

On August 10, 2023 5:37:54 AM HST, AdamISZ via bitcoin-dev wrote: >Hi Dan, >A couple more more thoughts: > >> Out of band, the receiver of the payment, shares a bitcoin URI with the >> sender including a pj= query parameter describing the relay >> subdirectory endpoint and psk= parameter

Re: [bitcoin-dev] Concrete MATT opcodes

On July 30, 2023 11:37:49 AM HST, Salvatore Ingala via bitcoin-dev >I have put together a first complete proposal for the core opcodes of >MATT [1][2]. >The changes make the opcode functionally complete, and the >implementation is revised and improved. > [...] >[1] - https://merkle.fun/ >[2] -

Re: [bitcoin-dev] Standardisation of an unstructured taproot annex

On 2023-06-11 09:25, Joost Jager wrote: Isn't it the case that that op-dropped partial signature for the ephemeral key isn't committed to and thus can be modified by anyone before it is mined That's correct; I hadn't thought of that, sorry. I am really looking for a bitcoin-native solution

Re: [bitcoin-dev] Standardisation of an unstructured taproot annex

On 2023-06-09 21:43, Joost Jager via bitcoin-dev wrote: The most critical application in this category, for me, involves time-locked vaults. [...] Backing up the ephemeral signatures of the pre-signed transactions on the blockchain itself is an excellent way to ensure that the vault can always

Re: [bitcoin-dev] Ark: An Alternative Privacy-preserving Second Layer Solution

On 2023-06-07 03:30, Burak Keceli wrote: If the service provider double-spends a transaction that enforces a one-time signature where Bob is the vendor, Bob can forge the service provider’s signature from the 2-of-2 and can immediately claim his previously-spent vTXO(s). Hi Burak, I'm

Re: [bitcoin-dev] Standardisation of an unstructured taproot annex

On 2023-06-02 05:00, Joost Jager via bitcoin-dev wrote: the benefits of making the annex available in a non-structured form are both evident and immediate. By allowing developers to utilize the taproot annex without delay, we can take advantage of its features today, Hi Joost, Out of

Re: [bitcoin-dev] Bitcoin Transaction Relay over Nostr

On 2023-05-22 21:19, Joost Jager via bitcoin-dev wrote: A notable advantage of this approach is that it delegates the responsibility of dealing with Denial-of-Service (DoS) threats to the relays themselves. They could, for example, require a payment to mitigate such concerns. Hi Joost, Thanks

Re: [bitcoin-dev] Ark: An Alternative Privacy-preserving Second Layer Solution

Hi Burak, Thanks for your response! I found it very helpful. I'm going to reply to your email a bit out of order. 4. Alice places one input to her one-in, three-out transaction to supply funds to commitment output, connectors output, change output, and transaction fees. You don't

Re: [bitcoin-dev] Ark: An Alternative Privacy-preserving Second Layer Solution

Hi Burak, Thanks for this really interesting protocol! I tend to analyze complicated ideas like this by writing about them in my own words, so I've pasted my summary of your idea to the end of this email in case it's useful, either to other people or to you in helping understand my one concern.

Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions

On 2023-05-06 21:03, Michael Folkson via bitcoin-dev wrote: Essentially my concern is going forward current maintainers will decide which proposed new maintainers to add and which to block. This is how a large percentage of organizations are run. The current members of a board or other

Re: [bitcoin-dev] RGB protocol announcement

On 2023-04-18 13:16, Dr Maxim Orlovsky wrote: 1. Assume we have some BTC lifted to RGB, which we will name BTC*. (let’s leave the question on how to do that aside; it can be discussed separately). Hi Maxim, Ok, I think I understand you, but I'd like to try rephrasing what you wrote in a

Re: [bitcoin-dev] Proposal to Remove BIP35 P2P 'mempool' Message

When serving trusted clients one alternative might be to use the `savemempool` RPC, which can then be loaded directly (in whole) by the client. It was common in the past for lightweight clients to load a BIP37 filter and then send a `getdata` for requesting `mempool`. In that case, the node

Re: [bitcoin-dev] RGB protocol announcement

Hi Dr Orlovsky, Thank you for writing about your interesting project. Some replies inline below: On 2023-04-10 12:09, Dr Maxim Orlovsky via bitcoin-dev wrote: RGB v0.10 can be downloaded and installed as described on website, which also contains a number of user and

Re: [bitcoin-dev] BIP proposal: Fee-redistribution contracts

On 2023-02-27 03:32, Rastislav Budinsky via bitcoin-dev wrote: When a miner mines a block he takes all the fees currently. However with the proposed solution he takes only fraction M and remaining fraction C is sent to one of more contracts. One contract at its simplest collects fees from the

Re: [bitcoin-dev] Codex32

On 2023-02-16 03:49, Andrew Poelstra via bitcoin-dev wrote: the draft lists several benefits over SLIP-0039. The only benefit over SLIP39 that I see explicitly mentioned in the draft BIP is "simple enough for hand computation". In the FAQ[1] on the project's website, I see some additional

Re: [bitcoin-dev] Reference example bech32m address for future segwit versions

On 2023-01-31 04:30, Greg Sanders wrote: Hi David, From practical experience, I think you'll find that most exchanges will not enable sends to future segwit versions, as from a risk perspective it's likely a mistake to send funds there. Hi Greg!, I thought the best practice[1] was that

[bitcoin-dev] Reference example bech32m address for future segwit versions

Hi y'all!, One of the benefits proposed for bech32 (and, by extension, bech32m) is that spender wallets shouldn't need to be upgraded to pay segwit outputs defined in future soft forks. For example, Bitcoin Core today can pay a bech32m address for a segwit v2 output, even though no meaning has

Re: [bitcoin-dev] Why Full-RBF Makes DoS Attacks on Multiparty Protocols Significantly More Expensive

On 2023-01-10 00:06, Peter Todd wrote: Remember, we'd like decentralized coinjoin implementations like Joinmarket to work. How does a decentralized coinjoin implement "conflict monitoring"? 1. Run a relay node with a conflict-detection patch. Stock Bitcoin Core with -debug=mempoolrej will

Re: [bitcoin-dev] Why Full-RBF Makes DoS Attacks on Multiparty Protocols Significantly More Expensive

On 2023-01-09 22:47, Peter Todd wrote: How do you propose that the participants learn about the double-spend? Without knowing that it happened, they can't respond as you suggested. I can think of various ways---many of them probably the same ideas that would occur to you. More concise than

Re: [bitcoin-dev] Why Full-RBF Makes DoS Attacks on Multiparty Protocols Significantly More Expensive

On 2023-01-09 12:18, Peter Todd via bitcoin-dev wrote: [The quote:] "Does fullrbf offer any benefits other than breaking zeroconf business practices?" ...has caused a lot of confusion by implying that there were no benefits. [...] tl;dr: without full-rbf people can intentionally

Re: [bitcoin-dev] Using Full-RBF to fix BIP-125 Rule #3 Pinning with nLockTime

On 2022-11-07 11:17, Peter Todd via bitcoin-dev wrote: We can ensure with high probability that the transaction can be cancelled/mined at some point after N blocks by pre-signing a transaction, with nLockTime set sufficiently far into the future, spending one or more inputs of the transaction

Re: [bitcoin-dev] Merkleize All The Things

On 2022-11-07 23:17, Salvatore Ingala via bitcoin-dev wrote: Hi list, Hi Salvatore!, I have been working on some notes to describe an approach that uses covenants in order to enable general smart contracts in bitcoin. You can find them here: https://merkle.fun I haven't yet been able

Re: [bitcoin-dev] On mempool policy consistency

On 2022-10-26 13:52, Anthony Towns via bitcoin-dev wrote: The cutoff for that is probably something like "do 30% of listening nodes have a compatible policy"? If they do, then you'll have about a 95% chance of having at least one of your outbound peers accept your tx, just by random chance.

Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger

On 2022-10-19 04:29, Sergej Kotliar via bitcoin-dev wrote: The biggest risk in accepting bitcoin payments is in fact not zeroconf risk (it's actually quite easily managed), it's FX risk as the merchant must commit to a certain BTCUSD rate ahead of time for a purchase. Over time some transactions

Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger

On 2022-10-20 09:58, Anthony Towns via bitcoin-dev wrote: On Thu, Oct 20, 2022 at 02:37:53PM +0200, Sergej Kotliar via bitcoin-dev wrote: AJ previously wrote: > presumably that makes your bitcoin > payments break down as something like: >5% txs are on-chain and seem shady and are excluded

Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger

On 2022-10-07 06:20, Dario Sneidermanis via bitcoin-dev wrote: Hello list, I'm Dario, from Muun wallet [...] we've been reviewing the latest bitcoin core release candidate [...] we understood we had at least a year from the initial opt-in deployment until opt-out was deployed, giving us

Re: [bitcoin-dev] Trustless Address Server – Outsourcing handing out addresses to prevent address reuse

On 2022-09-29 05:39, Ruben Somsen via bitcoin-dev wrote: An alternative mitigation (more user friendly, but more implementation complexity) would be to require the sender to reveal their intended transaction to the server prior to receiving the address[^9]. This is not a privacy degradation,

Re: [bitcoin-dev] More uses for CTV

On 2022-08-19 06:33, James O'Beirne via bitcoin-dev wrote: Multiple parties could trustlessly collaborate to settle into a single CTV output using SIGHASH_ALL | ANYONECANPAY. This requires a level of interaction similar to coinjoins. Just to make sure I understand, is the reason for

Re: [bitcoin-dev] Regarding setting a lower minrelaytxfee

On 2022-07-26 02:45, Peter Todd via bitcoin-dev wrote: On Tue, Jul 26, 2022 at 01:56:05PM +0530, Aaradhya Chauhan via bitcoin-dev wrote: [...] in its early days, 1 sat/vB was a good dust protection measure. But now, I think it's a bit high [...] I think it can be done easily [...] [...]

Re: [bitcoin-dev] Surprisingly, Tail Emission Is Not Inflationary

On 2022-07-10 07:27, Peter Todd via bitcoin-dev wrote: The block subsidy directly ties miner revenue to the total value of Bitcoin: that's exactly how you want to incentivise a service that keeps Bitcoin secure. I'm confused. I thought your argument in the OP of this thread was that a

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

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

Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV

On 21.04.2022 14:28, Anthony Towns wrote: But, if [it's true that "many [...] use cases [...] to use CTV for are very long term in nature"], that's presumably incompatible with any sort of sunset that's less than many decades away, so doesn't seem much better than just having it be available on

Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV

[Rearranging Matt's text in my reply so my nitpicks come last.] On 21.04.2022 13:02, Matt Corallo wrote: I agree, there is no universal best, probably. But is there a concrete listing of a number of use-cases and the different weights of things, plus flexibility especially around

Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV

On 21.04.2022 08:39, Matt Corallo wrote: We add things to Bitcoin because (a) there's some demonstrated use-cases and intent to use the change (which I think we definitely have for covenants, but which only barely, if at all, suggests favoring one covenant design over any other) I'm

Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV

On 21.04.2022 04:58, Matt Corallo wrote: On 4/20/22 6:04 PM, David A. Harding via bitcoin-dev wrote: The main criticisms I'm aware of against CTV seem to be along the following lines: 1. Usage, either:   a. It won't receive significant real-world usage, or   b. It will be used but we'll end

[bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV

Hi all, The main criticisms I'm aware of against CTV seem to be along the following lines: 1. Usage, either: a. It won't receive significant real-world usage, or b. It will be used but we'll end up using something better later 2. An unused CTV will need to be supported forever, creating

[bitcoin-dev] Sponsor transaction engineering, was Re: Thoughts on fee bumping

On Tue, Feb 15, 2022 at 01:37:43PM -0800, Jeremy Rubin via bitcoin-dev wrote: > Unfortunately, there are technical reasons for sponsors to not be monotone. > Mostly that it requires the maintenance of an additional permanent > TX-Index Alternatively, you could allow a miner to include a sponsor

[bitcoin-dev] Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

On Mon, Feb 07, 2022 at 08:34:30PM -0800, Jeremy Rubin via bitcoin-dev wrote: > Whether [recursive covenants] is an issue or not precluding this sort > of design or not, I defer to others. For reference, I believe the last time the merits of allowing recursive covenants was discussed at length on

[bitcoin-dev] Finding peers that relay taproot spends, was Re: bitcoinj fork with Taproot support

On Wed, Nov 17, 2021 at 08:05:55PM +, n1ms0s via bitcoin-dev wrote: > This seems to be the case. I saw your reply on Bitcoin StackExchange > as well. In bitcoinj I just made it so the client only connects to > nodes with at least protocol version 70016. Seems to work well. Hi, This is a

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

On Fri, Sep 10, 2021 at 11:24:15AM -0700, Matt Corallo via bitcoin-dev wrote: > I'm [...] suggesting [...] that the existing block producers each > generate a new key, and we then only sign reorgs with *those* keys. > Users will be able to set a flag to indicate "I want to accept sigs > from

Re: [bitcoin-dev] Braidpool: Proposal for a decentralised mining pool

On Mon, Sep 06, 2021 at 09:29:01AM +0200, Eric Voskuil wrote: > It doesn’t centralize payment, which ultimately controls transaction > selection (censorship). Yeah, but if you get paid after each share via LN and you can switch pools instantly, then the worst case with centralized pools is that

Re: [bitcoin-dev] Braidpool: Proposal for a decentralised mining pool

On Wed, Sep 01, 2021 at 11:46:55PM -0700, Billy Tetrud via bitcoin-dev wrote: > How would you compare this to Stratum v2? Specifically, I'd be interested in learning what advantages this has over a centralized mining pool using BetterHash or StratumV2 with payouts made via LN (perhaps immediately

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

On Fri, Sep 03, 2021 at 08:32:19PM -0700, Jeremy via bitcoin-dev wrote: > 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

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

On Mon, Aug 09, 2021 at 09:22:28AM -0400, Antoine Riard wrote: > I'm pretty conservative about increasing the standard dust limit in any > way. This would convert a higher percentage of LN channels capacity into > dust, which is coming with a lowering of funds safety [0]. I think that reasoning

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

On Sun, Aug 08, 2021 at 11:52:55AM -0700, Jeremy wrote: > We should remove the dust limit from Bitcoin. Five reasons: Jeremy knows this, but to be clear for other readers, the dust limit is a policy in Bitcoin Core (and other software) where it refuses by default to relay or mine transactions

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

On Sun, Jul 25, 2021 at 12:49:38PM -0700, Billy Tetrud wrote: > find the median fee-rate for each block and store that, then calculate > the average of those stored per-block median numbers. One datapoint per block seems fine to me and it works much nicer with pruned nodes. > So the only

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

On Tue, Jul 20, 2021 at 10:56:10PM -0700, Billy Tetrud via bitcoin-dev wrote: > This involves [...] constraining the amount of the fee that output is > allowed to contribute to. [...] fee is specified relative to recent > median fee rates - details in the proposal). Here are the relevant

Re: [bitcoin-dev] Multisig Enhanced Privacy Scheme

On Tue, Jul 20, 2021 at 07:44:19PM +, Michael Flaxman via bitcoin-dev wrote: > I've been working on ways to prevent privacy leaks in multisig > quorums, and have come up with a creative use of BIP32 paths. It seems to me like it would be rare for an attacker to obtain a private BIP32 seed but

Re: [bitcoin-dev] Travel rule, VASP UID and bitcoin URI - A new BIP

On Fri, Jul 16, 2021 at 04:35:21PM +0200, Karel Kyovsky via bitcoin-dev wrote: > I would like to propose a standardization of [a new] bitcoin URI parameter > name > [...] > My question is: Should I prepare a completely new BIP or should I prepare a > modification of BIP21? Please use a new BIP.

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

On Sun, Jul 04, 2021 at 11:39:44AM -0700, Jeremy wrote: > However, I think the broader community is unconvinced by the cost benefit > of arbitrary covenants. See > https://medium.com/block-digest-mempool/my-worries-about-too-generalized-covenants-5eff33affbb6 > as a recent example. Therefore as a

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

On Sat, Jul 03, 2021 at 09:31:57AM -0700, Jeremy via bitcoin-dev wrote: > Note that with *just* CheckSigFromStack, while you can do some very > valuable use cases, but without OP_CAT it does not enable sophisticated > covenants Do you have concerns about sophisticated covenants, and if so, would

Re: [bitcoin-dev] BIP Proposals for Output Script Descriptors

On Sat, Jul 03, 2021 at 10:35:48AM +0200, Craig Raw wrote: > There is a downside to using "h"/"H" from a UX perspective - taking up more > space Is this a serious concern of yours? An apostrophe is 1/2 en; an "h" is 1 en; the following descriptor contains three hardened derivations in 149

Re: [bitcoin-dev] BIP Proposals for Output Script Descriptors

On Tue, Jun 29, 2021 at 09:14:39PM +, Andrew Chow via bitcoin-dev wrote: > *** Optionally followed by a single /* or /*' final > step to denote all direct unhardened or hardened children. > > [...] > > In the above specification, the hardened indicator ' may be > replaced with alternative

Re: [bitcoin-dev] [Lightning-dev] Waiting SIGHASH_ANYPREVOUT and Packing Packages

On Fri, Jun 18, 2021 at 06:11:38PM -0400, Antoine Riard wrote: > 2) Solving the Pre-Signed Feerate problem : Package-Relay or > SIGHASH_ANYPREVOUT > > For Lightning, either package-relay or SIGHASH_ANYPREVOUT should be able to > solve the pre-signed feerate issue [3] > > [...] > > [3] I don't

Re: [bitcoin-dev] Reminder on the Purpose of BIPs

On Sun, Apr 25, 2021 at 05:31:50PM -0400, Matt Corallo via bitcoin-dev wrote: > In general, I think its time we all agree the BIP process has simply failed > and move on. Luckily its not really all that critical and proposed protocol > documents can be placed nearly anywhere with the same effect.

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

On Sat, Apr 24, 2021 at 04:42:12AM +, Greg Maxwell via bitcoin-dev wrote: > I am opposed to the addition of Kalle Alm at this time. Those who > believe [this] will resolve the situation [...] re: PR1104 are > mistaken. PR1104 has been merged. Do you continue to oppose the addition? Thanks,

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

On Sat, Apr 24, 2021 at 01:05:25PM -0700, Jeremy wrote: > I meant the type itself is too wide, not the length of the value. As in > Script can represent things we know nothing about. I guess I still don't understand your concern, then. If script can represent things we know nothing about, then

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

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 with known output types. I don't understand this concern. If script is too wide a type, then OP_RETURN being a scriptPubKey of

Re: [bitcoin-dev] Update on "Speedy" Trial: The circus rolls on

On Thu, Apr 08, 2021 at 12:40:42PM +0100, Michael Folkson via bitcoin-dev wrote: > So the latest circus act is apparently a technical decision made by a > coin toss [organized by] Jeremy Rubin Actually, the coin toss was my idea[1], used a bash oneliner I wrote[2], and is the same method I've

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

(Replies to multiple emails) On Tue, Apr 06, 2021 at 12:27:34PM -0400, Russell O'Connor wrote: > It isn't "$MIN_LOCKIN_TIME + $((10 * 2016)) minutes". It's > "$MIN_LOCKIN_TIME + time until next retargeting period + $((10 * 2016)) > minutes". Ah, drat, I forgot about that. Thank you for

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

On Tue, Apr 06, 2021 at 10:34:57AM -0400, Russell O'Connor via bitcoin-dev wrote: > The other relevant value of giving enough time for users to upgrade is not > very sensitive. It's not like 180 days is magic number that going over is > safe and going below is unsafe. I don't think it's the 180

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

On Mon, Mar 15, 2021 at 09:48:15PM +, Luke Dashjr via bitcoin-dev wrote: > Note that in all circumstances, Bitcoin is endangered when QC becomes > a reality [...] it could very well become an unrecoverable situation > if QC go online prior to having a full quantum-safe solution. The main

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

On Sat, Mar 06, 2021 at 01:11:01PM -0500, Matt Corallo wrote: > I'm really unsure that three months is a short enough time window that there > wouldn't be a material effort to split the network with divergent consensus > rules. I oppose designing activation mechanisms with the goal of preventing

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

On the ##taproot-activation IRC channel, Russell O'Connor recently proposed a modification of the "Let's see what happens" activation proposal.[1] The idea received significant discussion and seemed acceptable to several people who could not previously agree on a proposal (although this doesn't

Re: [bitcoin-dev] A design for Probabilistic Partial Pruning

On Sat, Feb 27, 2021 at 09:19:34AM -1000, David A. Harding via bitcoin-dev wrote: > - Discussion thread 1: > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/014186.html Two particularly useful emails from that thread are: - https://lists.linuxfoundation.org/pipermail/b

Re: [bitcoin-dev] A design for Probabilistic Partial Pruning

On Fri, Feb 26, 2021 at 11:40:35AM -0700, Keagan McClelland via bitcoin-dev wrote: > Hi all, Hi Keagan, > 4. Once the node's IBD is complete it would advertise this as a peer > service, advertising its seed and threshold, so that nodes could > deterministically deduce which of its peers had

Re: [bitcoin-dev] Taproot activation meeting 2 - Tuesday 16th February 19:00 UTC

On Fri, Feb 05, 2021 at 12:43:57PM +, Michael Folkson via bitcoin-dev wrote: > https://old.reddit.com/r/Bitcoin/comments/lcjhl6/taproot_activation_pools_will_be_able_to_veto/gm2l02w/ > [...] > F6) It is more important that no rules that harm users are deployed > than it is that new useful

Re: [bitcoin-dev] Progress on bech32 for future Segwit Versions (BIP-173)

On Sat, Dec 05, 2020 at 11:10:51PM +, Pieter Wuille via bitcoin-dev wrote: > I think these results really show there is no reason to try to > maintain the old-software-can-send-to-future-segwit-versions property, > given that more than one not just didn't support it, but actually sent > coins

Re: [bitcoin-dev] Progress on bech32 for future Segwit Versions (BIP-173)

On Tue, Oct 20, 2020 at 11:12:06AM +1030, Rusty Russell wrote: > Here are my initial results: A while ago, around the Bitcoin Core 0.19.0 release that enabled relaying v1+ segwit addresses, Mike Schmidt was working on the Optech Compatibility Matrix[1] and tested a variety of software and

Re: [bitcoin-dev] Progress on bech32 for future Segwit Versions (BIP-173)

On Thu, Oct 08, 2020 at 10:51:10AM +1030, Rusty Russell via bitcoin-dev wrote: > Hi all, > > I propose an alternative to length restrictions suggested by > Russell in https://github.com/bitcoin/bips/pull/945 : use the > https://gist.github.com/sipa/a9845b37c1b298a7301c33a04090b2eb

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

On Fri, Sep 25, 2020 at 10:35:36AM -0700, Mike Brooks via bitcoin-dev wrote: > - with a fitness test you have a 100% chance of a new block from being > accepted, and only a 50% or less chance for replacing a block which has > already been mined. This is all about keeping incentives moving

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

On Sun, Sep 20, 2020 at 07:10:23PM -0400, Antoine Riard via bitcoin-dev wrote: > As you mentioned, if the goal of the sponsor mechanism is to let any party > drive a state N's first tx to completion, you still have the issue of > concurrent states being pinned and thus non-observable for

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

On Sat, Sep 19, 2020 at 09:30:56AM -0700, Jeremy wrote: > Yup, I was aware of this limitation but I'm not sure how practical it is as > an attack because it's quite expensive for the attacker. It's cheap if: 1. You were planning to consolidate all those UTXOs at roughly that feerate anyway.

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

On Fri, Sep 18, 2020 at 05:51:39PM -0700, Jeremy via bitcoin-dev wrote: > 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. Interesting idea! This is going to take

Re: [bitcoin-dev] reviving op_difficulty

On Sun, Aug 16, 2020 at 11:41:30AM -0400, Thomas Hartman via bitcoin-dev wrote: > First, I would like to pay respects to tamas blummer, RIP. > > https://bitcoinmagazine.com/articles/remembering-tamas-blummer-pioneering-bitcoin-developer RIP, Tamas. > Tamas proposed an additional opcode for

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

On Sun, Aug 16, 2020 at 12:06:55PM -0700, Eric Voskuil via bitcoin-dev wrote: > A requirement to ignore unknown (invalid) messages is [...] a protocol > breaking change I don't think it is. The proposed BIP, as currently written, only tells nodes to ignore unknown messages during peer

Re: [bitcoin-dev] BIP draft: BIP32 Path Templates

On Thu, Jul 02, 2020 at 09:28:39PM +0500, Dmitry Petukhov via bitcoin-dev wrote: > I think there should be standard format to describe constraints for > BIP32 paths. > > I present a BIP draft that specifies "path templates" for BIP32 paths: > >

Re: [bitcoin-dev] MAD-HTLC

On Tue, Jun 23, 2020 at 03:47:56PM +0300, Stanga via bitcoin-dev wrote: > On Tue, Jun 23, 2020 at 12:48 PM ZmnSCPxj wrote: > > * Inputs: > > * Bob 1 BTC - HTLC amount > > * Bob 1 BTC - Bob fidelity bond > > > > * Cases: > > * Alice reveals hashlock at any time: > > * 1 BTC goes to Alice

Re: [bitcoin-dev] MAD-HTLC

On Tue, Jun 23, 2020 at 09:41:56AM +0300, Stanga via bitcoin-dev wrote: > Hi all, > > We'd like to bring to your attention our recent result concerning HTLC. > Here are the technical report and a short post outlining the main points: > > * https://arxiv.org/abs/2006.12031 > *

Re: [bitcoin-dev] [Lightning-dev] RBF Pinning with Counterparties and Competing Interest

On Sat, Jun 20, 2020 at 10:54:03AM +0200, Bastien TEINTURIER wrote: > We're simply missing information, so it looks like the only good > solution is to avoid being in that situation by having a foot in > miners' mempools. The problem I have with that approach is that the incentive is to connect

Re: [bitcoin-dev] [Lightning-dev] RBF Pinning with Counterparties and Competing Interest

On Fri, Jun 19, 2020 at 03:58:46PM -0400, David A. Harding via bitcoin-dev wrote: > I think you're assuming here that the attacker broadcast a particular > state. Whoops, I managed to confuse myself despite looking at Bastien's excellent explainer. The attacker would be broadc

Re: [bitcoin-dev] [Lightning-dev] RBF Pinning with Counterparties and Competing Interest

On Fri, Jun 19, 2020 at 09:44:11AM +0200, Bastien TEINTURIER via Lightning-dev wrote: > The gist is here, and I'd appreciate your feedback if I have wrongly > interpreted some of the ideas: > https://gist.github.com/t-bast/22320336e0816ca5578fdca4ad824d12 Quoted text below is from the gist: >

Re: [bitcoin-dev] BIP-341: Committing to all scriptPubKeys in the signature message

On Wed, Apr 29, 2020 at 04:57:46PM +0200, Andrew Kozlik via bitcoin-dev wrote: > 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. A wallet can easily check whether a scriptPubKey

Re: [bitcoin-dev] RBF Pinning with Counterparties and Competing Interest

On Wed, Apr 22, 2020 at 03:53:37PM -0700, Matt Corallo wrote: > if you focus on sending the pinning transaction to miner nodes > directly (which isn't trivial, but also not nearly as hard as it > sounds), you could still pull off the attack. If the problem is that miners might have information

Re: [bitcoin-dev] RBF Pinning with Counterparties and Competing Interest

On Wed, Apr 22, 2020 at 03:03:29PM -0400, Antoine Riard wrote: > > In that case, would it be worth re-implementing something like a BIP61 > reject message but with an extension that returns the txids of any > conflicts? > > That's an interesting idea, but an attacker can create a local conflict

Re: [bitcoin-dev] RBF Pinning with Counterparties and Competing Interest

On Mon, Apr 20, 2020 at 10:43:14PM -0400, Matt Corallo via Lightning-dev wrote: > A lightning counterparty (C, who received the HTLC from B, who > received it from A) today could, if B broadcasts the commitment > transaction, spend an HTLC using the preimage with a low-fee, > RBF-disabled

Re: [bitcoin-dev] RBF Pinning with Counterparties and Competing Interest

On Tue, Apr 21, 2020 at 09:13:34PM -0700, Olaoluwa Osuntokun wrote: > On Mon, Apr 20, 2020 at 10:43:14PM -0400, Matt Corallo via Lightning-dev > wrote: > > While this is somewhat unintuitive, there are any number of good anti-DoS > > reasons for this, eg: > > None of these really strikes me as

Re: [bitcoin-dev] Statechain implementations

On Wed, Mar 25, 2020 at 01:52:10PM +, Tom Trevethan via bitcoin-dev wrote: > Hi all, > > We are starting to work on an implementation of the statechains concept ( > https://medium.com/@RubenSomsen/statechains-non-custodial-off-chain-bitcoin-transfer-1ae4845a4a39), > > [...] > There are two

Re: [bitcoin-dev] Block solving slowdown question/poll

On Sat, Mar 21, 2020 at 11:40:24AM -0700, Dave Scotese via bitcoin-dev wrote: > [Imagine] we also see mining power dropping off at a rate that > suggests the few days [until retarget] might become a few weeks, and > then, possibly, a few months or even the unthinkable, a few eons. I'm > curious

Re: [bitcoin-dev] Taproot (and graftroot) complexity (reflowed)

On Fri, Feb 14, 2020 at 12:07:15PM -0800, Jeremy via bitcoin-dev wrote: > Is the same if Schnorr + Merkle Branch without Taproot optimization, unless > I'm missing something in one of the cases? That's fair. However, it's only true if everyone constructs their merkle tree in the same way, with

  1   2   >