Hi Dan,
I don't think nostr would be a suitable replacement for the mailing
list, although this opinion is biased by the fact that I do not use
nostr and find it to be uninteresting.
From my limited understanding of how nostr works, it's not clear to me
how a distributed system that uses mess
Thanks for writing this up.
I would prefer that we continue to have a mailing list where email is a
functional and first class user interface. So that would be to migrate
to groups.io or Google Groups. I think Google Groups is probably the
better choice of the two.
Although there are concerns
On 10/11/2023 07:47 PM, Anthony Towns wrote:
> On Tue, Oct 10, 2023 at 10:28:37PM +0000, Andrew Chow via bitcoin-dev wrote:
>> I've written up a BIP draft for MuSig2 PSBT fields. It can be viewed at
>> https://github.com/achow101/bips/blob/musig2-psbt/bip-musig2-psbt.mediawik
Hi All,
I've written up a BIP draft for MuSig2 descriptors. It can be viewed at
https://github.com/achow101/bips/blob/musig2-descriptors/bip-musig2-descriptors.mediawiki.
Andrew
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https:
Hi All,
I've written up a BIP draft for MuSig2 PSBT fields. It can be viewed at
https://github.com/achow101/bips/blob/musig2-psbt/bip-musig2-psbt.mediawiki.
This is based on this gist from Sanket:
https://gist.github.com/sanket1729/4b525c6049f4d9e034d27368c49f28a6.
There are a few notable diff
On 07/06/2023 12:22 PM, alicexbt via bitcoin-dev wrote:
> 1) Register input in A
> 2) Double spend same input with zero fee to your own address
> 3) Register unconfirmed UTXO from 2 in B
Why would unconfirmed inputs be accepted in a coinjoin? That seems
unsafe, regardless of package relay. The
On 05/07/23 03:03 AM, Michael Folkson via bitcoin-dev wrote:
> The decision process for adding a new maintainer was according to the IRC
> meeting that the maintainers decided privately there was a need for a
> maintainer “who understood our interfaces and modularization efforts well”
> and tha
Responses in-line.
Note that the opinions expressed in this email are my own and are not
representative of what other maintainers think or believe.
On 04/18/2023 08:40 AM, Michael Folkson via bitcoin-dev wrote:
>
> Communication has been a challenge on Bitcoin Core for what I can
tell the entire
Hi James,
This seems like a promising proposal, but I noticed have a few issues
regarding batching and privacy.
It seems like this proposal will encourage address reuse for vaults, at
least in some parts. It seems like it would not be difficult to ensure
that each vault address was unique through
This is a known issue that I've been working on. The wallet is a large module
in Bitcoin Core and changing it takes quite a bit of time.
On 08/20/2022 10:16 AM, Felipe Micaroni Lalli via bitcoin-dev wrote:
> 8.1) Can we "optimize" a huge wallet without moving the funds to a new one?
> Like a "f
I've updated the BIP text to allow arbitrary length tuples.
On 07/27/2022 04:44 AM, Pavol Rusnak wrote:
> On Wed, 27 Jul 2022 at 00:28, Andrew Chow wrote:
>
>> However I don't see why this couldn't generalize to any sized tuples. As
>> long as the tuples are all the same length, and the limit i
;
> Just one clarification: Should , , ... also
> work or we only aim to support only tuples of exactly two values?
>
> On Tue, 26 Jul 2022 at 23:51, Andrew Chow via bitcoin-dev
> wrote:
>
>> Hi All,
>>
>> I would like to propose a BIP that de-duplicates and simplif
Hi All,
I would like to propose a BIP that de-duplicates and simplifies how we
represent descriptors for receiving and change addresses. Under the
existing BIPs, this requires two descriptors, where the vast majority of
the descriptors are the same, except for a single derivation path
element. Thi
Prior to 0.19.0, creating outputs with an unknown witness version was
considered non-standard. This was a violation of BIP 173 and was fixed for
0.19.0+ in PR #15846.
On 11/16/2021 10:17 PM, n1ms0s via bitcoin-dev wrote:
> Hello all,
> I am currently working on a fork of bitcoinj with basic Tap
On 10/20/2021 03:20 PM, Owen Gunden via bitcoin-dev wrote:
> I also notice that, as of 22.0, Wladimir is no longer signing the
> releases, and I have no trust in my gpg network of the people who seem
> to have replaced him.
It is signed with his personal key, as well as the personal keys of
several
Hi Peter,
It would be nice to have mime types registered for Bitcoin things, but
I'm not sure that it will be possible, at least not in the way that we
would like. I tried doing this with "application/bitcoin-psbt" back in
2019 but it was not accepted. From that attempt, here is what I have
learne
On 7/2/21 11:24 PM, David A. Harding wrote:
> Is there any chance we can take this opportunity to make "h"/"H" the
> preferred aliases? Using "'" in bourne-style shells is very
> annoying[1], and I suspect it's also creating unnecessary complications
> elsewhere.
I've updated the text to use "h".
collect feedback?
> --
> [@JeremyRubin](https://twitter.com/JeremyRubin)
>
> On Tue, Jun 29, 2021 at 2:15 PM Andrew Chow via bitcoin-dev
> wrote:
>
>> Hi All,
>>
>> I've been working on formalizing the Output Script Descriptors that have
>> been available in Bitc
This was assigned BIP number 86, so the purpose level path will be m/86'
Andrew
On 6/22/21 9:17 PM, Andrew Chow wrote:
> Hi All,
>
> I would like to propose a simple derivation path scheme for keys to be
> used in single key Taproot scripts. This is based on BIP 44 so it is
> basically identical
On 6/29/21 6:22 PM, Christopher Allen wrote:
> Are there any plans other than `raw` to support time locks in descriptors?
>
> Any plans for descriptors offering closer integration with miniscript?
I expect miniscript to be a followup BIP that extends these descriptors.
Miniscript has timelock fu
Hi All,
I've been working on formalizing the Output Script Descriptors that have
been available in Bitcoin Core for a while into BIPs. Since descriptors
are modular and have optional components, I've decided to split it into
7 BIPs, rather than a single one. The first describes descriptors in
gene
Hi Salvatore,
On 6/28/21 6:03 AM, Salvatore Ingala wrote:
> Hi Andrew,
>
> I just have a small suggestion on this proposal.
>
> On Tue, 22 Jun 2021 at 23:29, Andrew Chow via bitcoin-dev
> wrote:
>
>> | Taproot Leaf Script
>> | PSBT_IN_TAP_LEAF_SCRIPT = 0x15
Hi All,
I would like to propose a simple derivation path scheme for keys to be
used in single key Taproot scripts. This is based on BIP 44 so it is
basically identical to BIPs 49 and 84. Like with those BIPs, the actual
value to be used in the purpose level will be set to the BIP number,
once assi
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
https://github.com/achow101/bips/blob/taproot-psbt/bip-taproot-psbt.mediawiki.
Andrew Chow
---
BIP: taproot-psbt
Layer: Applications
; On Saturday 06 March 2021 06:04:22 Andrew Chow via bitcoin-dev wrote:
>> I like this idea.
>>
>> In terms of actual parameters, I propose that we base this Speedy Trial
>> off of BIP 8 with the following parameters:
>> * start height = 681408
>> * timeout heigh
I like this idea.
In terms of actual parameters, I propose that we base this Speedy Trial
off of BIP 8 with the following parameters:
* start height = 681408
* timeout height = 695520
* lockinontimeout = False
* signaling bit = 2
* threshold = 1815/2016 blocks (90%)
For the extended lockin period
While working on the reference implementation for this, it occurred to
me that the Inputs Modifiable flag needs to be more than just a boolean.
If there are existing signatures in the PSBT, then any added inputs
cannot change the transaction's locktime as all signatures, regardless
of sighash t
Hi All,
I've made some reorganization changes to the way that new PSBT versions
should be handled in BIP 174 (see
https://github.com/bitcoin/bips/pull/1055) so PSBTv2 will be submitted
as a separate BIP. The full document can be read at
https://github.com/achow101/bips/blob/psbt2/bip-psbt2.med
On 1/7/21 7:40 PM, Rusty Russell wrote:
> Andrew Chow writes:
>> Hi Rusty,
>>
>> On 1/6/21 6:26 PM, Rusty Russell wrote:
>>> Hi Andrew et al,
>>>
>>> Very excited to see this progress; thanks for doing all the
>>> work! Sorry for the delayed feedback, I didn't get to this before the
>
Hi Rusty,
On 1/6/21 6:26 PM, Rusty Russell wrote:
> Hi Andrew et al,
>
> Very excited to see this progress; thanks for doing all the
> work! Sorry for the delayed feedback, I didn't get to this before the
> break.
>
>> Additionally, I would like to add a new global field:
>> * PSBT_GLOBA
Hi All,
The full modified BIP can be read at
https://github.com/achow101/bips/blob/psbt2/bip-0174.mediawiki.
I will open a PR to the BIPs repo soon after further discussion on this.
Andrew
On 12/22/20 3:12 PM, Andrew Chow wrote:
> Hi All,
>
> I have some updates on this after speaking with so
> some reason it ends up not being relevant to this specific case):
> http://scripting.com/2017/05/09/rulesForStandardsmakers.html
>
> On Tue, 22 Dec 2020 17:12:22 -0300 Andrew Chow via bitcoin-dev
> wrote
> > Hi All,
> >
> > I have some updates on this
Hi All,
I have some updates on this after speaking with some people off-list.
Firstly, the version number will be set to 2. In most discussions, this
proposal was being referred to as PSBT version 2, so it'll be easier and
clearer to set the version number to 2.
For lock times, instead of a si
Hi All,
I would like to propose a new PSBT version that addresses a few
deficiencies in the current PSBT v0. As this will be backwards
incompatible, a new PSBT version will be used, v1.
The primary change is to truly have all input and output data for each
in their respective maps. Instead of
On 1/13/20 3:29 PM, Peter D. Gray wrote:
> The Signer may be signing a PSBT that was corrupted by the MitM,
> but at least later users of the signed PSBT can detect that occured.
> At present, they do not know what the input PSBT content was when
> it got to the Signer.
But the MiTM on the way to
On 1/13/20 9:28 AM, Peter D. Gray wrote:
> I don't have a specific attack in mind, but these signatures, if
> adopted by the community at large, will allow detection of-, and
> could mitigate damage from-, some broad "bug-classes".
>
> Consider if the PSBT Signer (hardware wallet) has bugs. Perh
I agree with Dimitry. I don't see the point of having the MiTM
protection within the PSBT structure itself, in addition to the fact
that adding new fields is largely unnecessary. In fact, I'm not quite
sure what kind of attack you are trying to defend against with this
proposal.
If there is a MiTM
Hi All,
Just a few comments about choosing an encoding and why this is even
being proposed.
On Wednesday, December 25, 2019 12:17 PM, William Casarin via
bitcoin-dev wrote:
> I don't think encoding descriptors is a good idea. Encoding makes more
> sense if it's non-human-readable binary data t
The rationale was that xpubs was already a predefined standard which many
software already have serialization code for. It's simpler to just reuse what
has been defined before.
IMO, the version bytes don't matter and should be ignored. In the proposed
implementation to Bitcoin Core, the version
I spoke to some people OOB and they said that they didn't really like
the idea of having a prefix string (partially because they've already
implemented some proprietary types by simply squatting on unused types).
Matching the prefix string adds additional complexity to the parser
code. The main con
It seems like the consensus is that we should use Compact Size Unsigned
Integers for the field types, so we will do that. The types will be
minimally encoded CSUints.
For the proprietary types, I will use Dimitry's and Andrew Poelstra's
(https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019
Hi,
On 7/31/19 12:19 PM, Dmitry Petukhov wrote:
>
> I think private formats should have at least a basic format: they
> should start with a prefix. This way different prviate formats can be
> distinguished by this prefix, and there will be no risk of
> unintentional confusion.
>
> Private types
Hi All,
I would like to propose some types that allow for BIP 174 PSBT to be
extended more in the future.
Firstly, I would like to propose that some types be reserved for
proprietary use. These proprietary use types are, in general, for
private use by individuals and organizations who want to us
This was the original intent of the sighash field. Either the sighash is
acceptable to the signer and the signer signs with it, or they do not sign at
all.
On 7/9/19 11:58 AM, Jonathan Underwood via bitcoin-dev wrote:
> Hi all,
>
> Just to be brief, I'll kick off with an attack scenario.
>
> 1.
Hi Stepan,
I think that this would be a good extension.
Just for clairty, by xpub, do you mean the extended serialization format
defined in BIP 32 or the Base58 check encoded string of that serialization?
Andrew
On 4/26/19 11:21 AM, Stepan Snigirev via bitcoin-dev wrote:
> Hi list,
>
> I was l
Hi Michele,
You are seeing this discrepancy due to the address types in use.
addmultisigaddress uses the default address type of the wallet, which is
p2sh-segwit. createmultisig uses a default address type of legacy. To have
createmultisig get addmultisigaddress's result, you need to add the st
Hi Andrew,
I think having some of these extensions would be great.
On 3/6/19 1:08 PM, Andrew Poelstra via bitcoin-dev wrote:
> 1. Add an field to PSBT_GLOBAL_UNSIGNED_TX to the global table which contains
>just a txid of the unsigned transaction, for bandwidth savings in case
>signers ha
The backported versions have not been released yet. They are still going
through the gitian build process. 0.16.3 was the first one to be
released so that is the one that everyone is being recommended to
upgrade to. Regardless, you should upgrade to a patched version, whether
that is 0.14.3, 0.15.2
signers, no special feeling regarding the
> encoding.Looking forward for the test vectors and the new spec.
>
> Cheers, Andrea.
>
> ‐‐‐ Original Message ‐‐‐
>
> On June 23, 2018 10:33 PM, Andrew Chow via bitcoin-dev
> wrote:
>
>>
>>
>> On 06/23/201
On 06/23/2018 10:00 AM, William Casarin wrote:
> Since we're still considering the encoding, I wonder if it would be a
> good idea to have a human-readible part like lightning invoices[1]?
I don't think that is necessary.
> Then perhaps you could drop the magic code as well?
The magic is still n
> (for protocol noncompliance), and I’m considering reinstating that
> behavior.
>
> e
>
> On Mar 9, 2018, at 16:33, Andrew Chow via bitcoin-dev
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>
>> Looking through the code, I don't think that thi
Looking through the code, I don't think that this behavior has changed.
Are you sure that you are actually connected to Satoshi:0.15.0 nodes and
not a node that has simply set their user-agent to that (i.e. not a real
Satoshi:0.15.0 node)?
If what you are seeing is true, it is likely a bug and not
Hi everyone,
I would like to propose a standard format for unsigned and partially signed
transactions.
===Abstract===
This document proposes a binary transaction format which contains the
information
necessary for a signer to produce signatures for the transaction and holds
the
signatures for an
What's special about block 475776?
On July 13, 2017 12:23:46 PM Sergio Demian Lerner via bitcoin-dev
wrote:
The BIP has been updated.
Changes:
- The technical spec has been improved: now the block size increase is
specified in terms of weight and not in terms of bytes.
- The increase in th
incorrect, it is compatible with the current segwit
> implementation because it triggers a mandatory signalling period that
> will activate segwit on existing nodes.
>
> On Tue, May 23, 2017 at 4:39 PM, Andrew Chow via bitcoin-dev
> wrote:
>> Hi James,
>>
>> From wh
Hi James,
>From what I understand, this proposal is incompatible with the current
segwit implementation with regards to the NODE_WITNESS service bit. I
believe it could cause network partitioning if the service bit is not
changed.
Andrew
On 5/22/2017 6:40 PM, James Hilliard via bitcoin-dev wrot
A correction to my previous email (because people are quoting me on
r/btc and what I wrote was wrong)
This statement is incorrect:
> Given that Testnet has a smaller number of nodes and less difficulty,
this could result in some miners using 0.13.0+ mining blocks which do
not propagate well and t
The issue is due to Segwit blocks since Testnet has already activated
Segwit. 0.12.x- nodes will receive a Segwit block with all of the
witnesses stripped. When they relay this block to a 0.13.0+ node, the
block will be rejected because those have Segwit functionality and
require the witnesses to b
Hi Erik,
I have left you some comments below.
Some general questions:
How will you deal with excessive sighashing (i.e. massive transactions
that include a lot of signature verification)?
Presumably the sigops limit will increase proportionally?
On 3/8/2017 2:42 PM, Erik Aronesty via bitcoin-dev
59 matches
Mail list logo
