Hello,
Today we'd like to announce the release of version 0.4.0 of libsecp256k1:
https://github.com/bitcoin-core/secp256k1/releases/tag/v0.4.0
The highlight is the addition of the ellswift module, which implements
ElligatorSwift encoding. For the full release notes of 0.4.0 (and earlier
re
Hello,
Today we'd like to announce the release of version 0.3.1 of libsecp256k1:
https://github.com/bitcoin-core/secp256k1/releases/tag/v0.3.1
This is a bugfix release after 0.3.0 (which was not announced on this list).
For the full release notes of 0.3.0 and 0.3.1 see:
https://github.com/
On Sunday, February 19th, 2023 at 6:56 PM, Anthony Towns
wrote:
> On Fri, Feb 17, 2023 at 10:13:05PM +0000, Pieter Wuille via bitcoin-dev wrote:
>
> > > I think it's probably less complex to close some of the doors?
> > > 2) are short ids available/meaningful
On Friday, February 17th, 2023 at 10:51 AM, Anthony Towns via bitcoin-dev
wrote:
> I think it's probably less complex to close some of the doors?
> 2) are short ids available/meaningful to send prior to VERACK being
> completed?
Ah, I hadn't considered this nuance. If we don't care about them
--- Original Message ---
On Friday, November 18th, 2022 at 3:24 AM, Anthony Towns
wrote:
> > * etc
> > So this gives a uniform space which commands can be assigned from, and
> > there is no strict need for thinking of the short-binary and
> > long-alphabetic commands as distinct. In v2
Hi,
After not even 10 years of development, we'd like to announce the first tagged
release of libsecp256k1, version 0.2.0:
https://github.com/bitcoin-core/secp256k1/releases/tag/v0.2.0
For a long time, libsecp256k1's development only had a master branch, creating
unclarity about API compat
Another idea...
On Thursday, November 10th, 2022 at 4:23 PM, Pieter Wuille via bitcoin-dev
wrote:
> On Thursday, November 3rd, 2022 at 1:53 PM, Murch wrote:
>
> > From what I understand we'll have about 35 message types on the network
> > with the addition of BIP324.
Hi,
Thanks for the comments so far. I think these are all reasonable ideas.
Comments inline below.
On Thursday, November 3rd, 2022 at 1:53 PM, Murch wrote:
> From what I understand we'll have about 35 message types on the network
> with the addition of BIP324. 256 possible IDs sounds like plenty
Hi all,
On Saturday, October 8th, 2022 at 8:59 AM, Dhruv M wrote:
> We have refreshed the proposal for BIP324, a new bitcoin P2P protocol
> featuring opportunistic encryption, a mild bandwidth reduction, and the
> ability
> to negotiate upgrades before exchanging application messages. We'd like
On Wednesday, October 12th, 2022 at 1:42 AM, Anthony Towns
wrote:
> On Tue, Oct 11, 2022 at 04:18:10PM +0000, Pieter Wuille via bitcoin-dev wrote:
>
> > On Friday, October 7th, 2022 at 5:37 PM, Dario Sneidermanis via bitcoin-dev
> > bitcoin-dev@lists.linuxfo
On Friday, October 7th, 2022 at 5:37 PM, Dario Sneidermanis via bitcoin-dev
wrote:
> Hello David,
>
> Thanks for the fast answer! It seems I missed the link to the PR, sorry for
> the
> confusion. I'm referring to the opt-in flag for full-RBF from #25353
> (https://github.com/bitcoin/bitcoin/
--- Original Message ---
On Thursday, July 28th, 2022 at 11:51 AM, Ali Sherief
wrote:
> The way I understood the BIP, was that a user can do batch recovery or
> single-key recovery. Can you explain how it is possible to recover a public
> key from a single-key signature, because a few
--- Original Message ---
On Thursday, July 28th, 2022 at 3:27 AM, Ali Sherief via bitcoin-dev
wrote:
> Essentially, zero-knowledge proofs such as Schnorr are not compatible with
> address message signing - the public key cannot be retrieved from the address
> or the signature, so the a
> Dear Bitcoin Developers,
> -When I contacted bitInfoCharts to divide the first interval of addresses,
> they kindly did divided to 3 intervals. From here:
> https://bitinfocharts.com/top-100-richest-bitcoin-addresses.html
> -You can see that there are more than 3.1m addresses holding ≤ 0.0
On Sunday, December 12th, 2021 at 9:23 AM, Aymeric Vitte via bitcoin-dev
wrote:
> Using the Tor network to bypass censorship for bitcoin can work but is a very
> poor solution, the Tor network is very centralized, very small, watched and
> controlled, with plenty of features that do not apply
> It is that the solution to privacy is to use privacy-enhancing network
> communications, such as TOR. I am not against a mechanism to rebroadcast
> transactions more robustly if the mempool of adjoining nodes has
> forgotten about them, but the truth is, all transactions originate from
> some nod
On Wednesday, November 24th, 2021 at 7:44 AM, Sjors Provoost via bitcoin-dev
wrote:
> Hi Andrew,
>
> I'm confused why PSBT_IN_TAP_BIP32_DERIVATION and
> PSBT_OUT_TAP_BIP32_DERIVATION
> contain not just the derivation path for the xonlypubkey, but also the
> tapleaf merkle path.
>
> First I tho
On Wednesday, November 17th, 2021 at 1:07 PM, Andrew Chow via bitcoin-dev
wrote:
> 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.
That's correct, but I think OP's proble
Hi all,
I wanted to bring some attention to a set of test vectors I'm proposing to add
to BIP341 in https://github.com/bitcoin/bips/pull/1225.
These are focused on wallet implementations, covering Merkle root / tweak /
scriptPubKey computation from key/scripts, sigmsg/sighash/signature computat
On Monday, October 25th, 2021 at 10:56 PM, lisa neigut via bitcoin-dev
wrote:
> Hi all,
>
> In a recent conversation with @glozow, I had the realization that the mempool
> is obsolete and should be eliminated.
Hi Lisa,
I see where this idea is coming from, especially as it relates to reducing
On Wednesday, October 20th, 2021 at 3: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.
This is not correct. Here are Wladimir's attestati
On Oct 9, 2021, 11:36, Andreas Schildbach via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> I'm trying to finish off bitcoinj's implementation for sending to
taproot addresses. For this, I'd like to test against a wallet that can
receive to P2TR and spend back.
> I've been tryi
Jumping in late to this thread.
I very much agree with how David Harding presents things, with a few comments
inline.
‐‐‐ Original Message ‐‐‐
On Sunday, August 8th, 2021 at 5:51 PM, David A. Harding via bitcoin-dev
wrote:
> > 1. it's not our business what outputs people want to crea
On Thursday, September 16th, 2021 at 5:36 PM, Giacomo Caironi via bitcoin-dev
wrote:
> Hi,
> recently I have worked on a python implementation of bitcoin signature
> messages, and I have found that there was way better documentation about
> Segwit signature message than Taproot.
>
> 1) Segwit
On Thursday, August 19th, 2021 at 1:02 PM, ts via bitcoin-dev
wrote:
> > In any case --- the last 5 characters of a bech32 string are already a
> > human-readable 5-digit code, with fairly good properties, why is it not
> > usable for this case?
Side note: it's actually the last six character
On Sunday, August 29th, 2021 at 5:32 AM, Prayank via bitcoin-dev
wrote:
> Wanted to know if others think we should allow more numbers in transaction
> version by considering such transaction standard. I have shared an example
> how transaction version can be used to bet on something that invol
On Saturday, August 28th, 2021 at 5:17 PM, ts via bitcoin-dev
wrote:
> Following up on my original proposal, I would like to get some more feedback
> of the community
>
> to see if this could be realized at some point. Also, any recommendations as
> to who to contact
>
> to get things rolling?
> This is an interesting read: https://bitcointalk.org/index.php?topic=5348856.0
>
> So according to this, somebody is spamming the bitcoin network with addr
> message pointing to invalid addresses and ports, which bloats the peers.dat
> and corresponding structure in memory.
The peers.dat file
> 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?
What kind of privacy concern are you talking about? I'm not sure I
‐‐‐ Original Message ‐‐‐
On Thursday, February 11, 2021 6:38 AM, Dr Maxim Orlovsky
wrote:
> Thank you very much for all the clarifications; it’s good to have them sorted
> out and clearly structured. From what you wrote it follows that we still need
> to reserve a dedicated purpose (wi
On Friday, February 5, 2021 9:51 AM, Dr Maxim Orlovsky via bitcoin-dev
wrote:
> Hi,
>
> Background
>
>
>
> Had a discussion last night in Bitcoin Core IRC with Peter Wuille on
> different topics regarding key derivations, security, key tweaks in context
> of Schnorr signat
On Tuesday, January 19, 2021 4:23 PM, nakagat wrote:
> Dear. Pieter,
>
> My idea is exactly what you wrote.
>
> However, I don't think it is the same as "checksum = hash (hrp, data)".
No, it is not the same. But it has the same error-detection properties as just
a hash. Hash-based checksums are
On Sunday, January 17, 2021 9:59 PM, nakagat wrote:
> I thought that BECH32M_CONST could be created from hrp and data
> instead of constants.
>
> I thought that the error position would be the same as bech32 by
> recalculating the value created from hrp and data.
So, bech32 can be written as:
*
Hi all,
A few updates, in response to comments here and in a few other places:
- Updated several reference implementations (C, C++, Python, Javascript) to
support Bech32m: https://github.com/sipa/bech32/tree/bech32m (but contributions
to update other languages are welcome!)
- Updated website,
On Monday, January 4, 2021 4:14 PM, Pieter Wuille
wrote:
> Hello all,
>
> here is a BIP draft for changing the checksum in native segwit addresses for
> v1 and higher, following the discussion in
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-December/018293.html
>
> Overall, t
Hello all,
here is a BIP draft for changing the checksum in native segwit addresses for v1
and higher, following the discussion in
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-December/018293.html
Overall, the idea is:
* Define a new encoding which is a tweaked variant of Bech32
On Monday, December 21, 2020 2:57 PM, Pieter Wuille via bitcoin-dev
wrote:
> On Sunday, December 20, 2020 9:37 PM, Karl-Johan Alm via bitcoin-dev
> bitcoin-dev@lists.linuxfoundation.org wrote:
>
> > Thanks a lot for taking the time to brush up the BIP. For what it's
>
On Sunday, December 20, 2020 9:37 PM, Karl-Johan Alm via bitcoin-dev
wrote:
> Thanks a lot for taking the time to brush up the BIP. For what it's
> worth, I am all for these changes, and I see them as clear
> improvements all around.
>
> IIRC Pieter was the one who originally suggested the two-c
On Tuesday, December 8, 2020 9:39 AM, Ryan Grant wrote:
> It looks like a good strategy for a bech32 library that is external to
> Bitcoin Core would be:
>
> - Default to the new M, under the same bech32 brand.
> - Provide an interface to explicitly use both M=1 and M=0x2bc830a3.
> - If dec
‐‐‐ Original Message ‐‐‐
On Sunday, December 6, 2020 5:04 AM, David A. Harding wrote:
> On Sat, Dec 05, 2020 at 11:10:51PM +0000, Pieter Wuille via bitcoin-dev wrote:
>
> > I think these results really show there is no reason to try to
> > maintain the old-so
> On Wednesday, October 7, 2020 5:21 PM, Rusty Russell via bitcoin-dev
> bitcoin-dev@lists.linuxfoundation.org wrote:
>
> > 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/a9845b37c1b298a
On Friday, November 6, 2020 11:49 AM, Mike Schmidt via bitcoin-dev
wrote:
> Well I sure picked a bad couple weeks to volunteer to send a bunch of Bitcoin
> test transactions...
>
> While I tested less than I would have liked, there are some notable results:
I think these results really show th
On Wednesday, October 7, 2020 5:21 PM, Rusty Russell via bitcoin-dev
wrote:
> 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 variant,
> unless the first by
On Tuesday, October 20, 2020 3:29 AM, David A. Harding wrote:
> I would guess that some of the failures / stuck transactions might now be
> successes if the backend infrastructure has upgraded to Bitcoin Core > = 0.19.
Yeah, it would be good to re-test them since a ~year has passed since the
On Sunday, October 18, 2020 5:49 PM, Rusty Russell
wrote:
> Pieter Wuille bitcoin-...@wuille.net writes:
>
> > Today, no witness v1 receivers exist. So it seems to me the only question
> > is what software/infrastructure exist that supports sending to witness v1,
> > and whether they (and their
On Tuesday, September 29, 2020 10:34 AM, Leonardo Comandini via bitcoin-dev
wrote:
> Hi all,
>
> BIP32 [1] says: "In order to prevent these from depending solely on the key
> itself, we extend both private and public keys first with an extra 256 bits of
> entropy. This extension, called the chai
On Saturday, September 19, 2020 5:36 AM, yanmaani--- via bitcoin-dev
wrote:
> Currently, Bitcoin's timestamp rules are as follows:
>
> 1. The block timestamp may not be lower than the median of the last 11
> blocks'
>
> 2. The block timestamp may not be greater than the current time plus t
Hi Rusty,
thanks for starting this thread. We definitely should make a decision around
this soon.
On Wednesday, October 14, 2020 6:40 PM, Rusty Russell via bitcoin-dev
wrote:
> > > Here's a summary of each proposal:
> > > Length restrictions (future segwits must be 10, 13, 16, 20, 23, 26, 29,
On Wednesday, October 7, 2020 1:31 PM, Mike Brooks via bitcoin-dev
wrote:
> But first of all, I'd like to say that the idea for FPNC came out of a
> conversation with ZmnSCPxj's in regards to re-org stability. When I had
> proposed blockchain pointers with the PubRef opcode, he took the time t
On Friday, August 21, 2020 1:50 AM, John Newbery via bitcoin-dev
wrote:
> Summary: We should change the proposal and implementation to use even
> tie-breakers everywhere.
>
> John #notoquadraticresiduetiebreakers Newbery
Thanks Nadav, Lloyd, John, and those who commented privately,
As the com
On Wednesday, August 12, 2020 11:49 AM, Pieter Wuille
wrote:
> It is late in the process, but I feel I owe this explanation so that at least
> the possibility of changing can be discussed with all information.
As the responses have been pretty positive so far, we've gone ahead and made a
patc
Hello all,
The current BIP340 draft[1] uses two different tiebreakers for conveying the Y
coordinate of points: for the R point inside signatures squaredness is used,
while for public keys evenness is used. Originally both used squaredness, but
it was changed[2] for public keys after observing
Hi all,
On Tuesday, May 5, 2020 3:20 AM, Jonas Nick via bitcoin-dev
wrote:
> This is a reasonable suggestion. Committing to every spent scriptPubKey and
> therefore every element of the TxOut instead of just the amount makes sense
> conceptually. And it would be a small diff (~4 lines + rationa
On Tuesday, March 24, 2020 6:00 AM, Lloyd Fournier via bitcoin-dev
wrote:
> Hi List,
>
> I felt this topic deserved it's own thread but it follows on from the mailing
> list post [2] announcing a new PR [1] to change BIP-340 in several ways,
> including adding random auxiliary data into the no
Hi all,
Given the recent activity and attention [1,2] around anti-covert channel
signing schemes, I decided to create this overview of the various techniques
that I know of, their trade-offs, and the various issues they protect against.
Most of this is based on various schemes by a number of autho
Hello list,
Despite saying earlier that I expected no further semantical changes
to BIP 340-342, I've just opened
https://github.com/bitcoin/bips/pull/893 to make a number of small
changes that I believe are still worth making.
1. Even public keys
Only one change affects the validation rules: th
On Fri, 14 Feb 2020 at 14:37, David A. Harding via bitcoin-dev
wrote:
>
> 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
> > So my suggestion for the next steps are:
> >
> > - Update BIP173 to include the insertion weakness as an erratum, and
> > the results of this analysis.
> >
>
> To clarify, this step does not modify anything about the implementation of
> BIP173, only adds this as an additional erratum sec
Hi all,
I've made a writeup on Bech32's detection abilities, analysing how it
behaves in the presence of not just substitution errors, but also
swapping of characters, and insertions and deletions:
https://gist.github.com/sipa/a9845b37c1b298a7301c33a04090b2eb
It shows that the "insert or delete a
On Tue, Nov 12, 2019, 21:33 ZmnSCPxj via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Good morning all,
>
> It seems to me that adding the length for checksumming purposes need not
> require the length to be *actually* added in the address format.
>
Indeed!
This has the followin
On Thu, Nov 7, 2019, 18:16 David A. Harding wrote:
> On Thu, Nov 07, 2019 at 02:35:42PM -0800, Pieter Wuille via bitcoin-dev
> wrote:
> > In the current draft, witness v1 outputs of length other
> > than 32 remain unencumbered, which means that for now such an
> > in
Hello all,
A while ago it was discovered that bech32 has a mutation weakness (see
https://github.com/sipa/bech32/issues/51 for details). Specifically,
when a bech32 string ends with a "p", inserting or erasing "q"s right
before that "p" does not invalidate it. While insertion/erasure
robustness wa
Hi all,
I wanted to give an update on some of the changes we've made to the
bip-schnorr/taproot/tapscript drafts following discussions on this
list:
* The original post:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016914.html
and follow-ups
* Using 2 or 4 byte indexes:
https:/
On Mon, 16 Sep 2019 at 21:10, ZmnSCPxj via bitcoin-dev
wrote:
> ‐‐‐ Original Message ‐‐‐
> > I'd prefer to not support P2SH-nested TR. P2SH wrapping was useful for
> > segwit
> > v0 for compatibility reasons. Most wallets/exchanges/services now support
> > sending
> > to native segwit a
Hi all,
In the draft for bip-tapscript (see [1], current version [2]), we
propose removing the per-block sigops limit for tapscript scripts, and
replacing it with a "every script gets a budget of sigops based on its
witness size (one per 50 WU)". Since signatures (plus pubkeys) take
more WU than t
On Tue, 6 Aug 2019 at 09:57, Niels Thijssen via bitcoin-dev
wrote:
>
> Hi,
>
> I'm working as (software) test specialist and run private a full bitcoin node
> (based upon Raspberry Pi 4).
> I've been trying to figure out the tests performed during
> installation/upgrade/compilation of the softwa
Hi all,
Miniscript is a project we've been working on for the past year or so,
and is now at a stage where I'd like to get it some more attention. It is joint
work with Andrew Poelstra and Sanket Sanjalkar.
It's a language for writing (a subset of) Bitcoin Scripts in a structured way,
enabling an
On Fri, 9 Aug 2019 at 08:02, Elichai Turkel via bitcoin-dev
wrote:
>
> Hi,
Since the idea of implicitly even pubkeys has potentially more general
implications, I've started a separate thread [1] about that idea.
> I want to add to John Newbery's suggestion of using implicit even/odd only
> publ
Hello all,
It has been suggested [1] to drop the Y oddness bit in the witness
program for Taproot outputs. This seems like a worthwhile change, as:
* The bit doesn't actually contribute to security.
* It avoids Taproot outputs from being more expensive to create than v0 P2WSH.
* It doesn't preclud
On Fri, Jul 19, 2019, 12:13 William Casarin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Hello Mike,
>
> Mike Brooks via bitcoin-dev
> writes:
>
> > Motivation
> >
> > Giving scripts the ability to refer to data on the blockchain will reduce
> > transaction sizes because ke
On Sun, May 26, 2019, 07:07 Aymeric Vitte via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> I realized recently that my segwit implementation was not correct,
> basically some time ago, wrongly reading the specs (and misleaded by
> what follows), I thought that scriptsig would go i
On Thu, 23 May 2019 at 11:33, Tamas Blummer via bitcoin-dev
wrote:
>
> Difficulty change has profound impact on miner’s production thereby introduce
> the biggest risk while considering an investment.
> Commodity markets offer futures and options to hedge risks on traditional
> trading venues. S
On Tue, 21 May 2019 at 10:20, Russell O'Connor wrote:
>
> Regarding Tapscript, the specification calls for the final value of the stack
> being a single non-false value:
>
>> The tapscript is executed according to the rules in the following section,
>> with the initial stack as input
>> II.
Thanks for the comments so far!
I'm going to respond to some of the comments here. Things which I plan
to address with changes in the BIP I'll leave for later.
On Mon, 6 May 2019 at 13:17, Luke Dashjr wrote:
> Tagged hashes put the tagging at the start of the hash input. This means
> implementat
Hello everyone,
Here are two BIP drafts that specify a proposal for a Taproot
softfork. A number of ideas are included:
* Taproot to make all outputs and cooperative spends indistinguishable
from eachother.
* Merkle branches to hide the unexecuted branches in scripts.
* Schnorr signatures enable
On Thu, 2 May 2019 at 16:28, Aymeric Vitte via bitcoin-dev
wrote:
>
> Thanks for the answer, indeed for the redeem script and someone
> attempting a 0/1 of 3, good example
>
> So to summarize everything is standard as long as it matches P2PKH,
> P2SH, P2WPKH or P2WSH , the redeem scripts for the s
On Wed, 19 Dec 2018 at 18:06, Rusty Russell via bitcoin-dev
wrote:
>
> Meanwhile, both SIGHASH_NOINPUT and OP_MASK have the reuse-is-dangerous
> property; with OP_MASK the danger is limited to reuse-on-the-same-script
> (ie. if you use the same key for a non-lightning output and a lightning
> outp
On Thu, 7 Feb 2019 at 12:19, Tamas Blummer via bitcoin-dev
wrote:
> I did restart the discussion which I read and participated in at its first
> instance because implementing the current proposal taught me how problematic
> as is until not committed and because I have not seen a sign to assume
On Mon, 19 Nov 2018 at 14:37, Pieter Wuille wrote:
> Here is a combined proposal:
> * Three new sighash flags are added: SIGHASH_NOINPUT, SIGHASH_NOFEE, and
> SIGHASH_SCRIPTMASK.
> * A new opcode OP_MASK is added, which acts as a NOP during execution.
> * The sighash is computed like in BIP143, b
Hello everyone,
For future segwit versions, I think it would be good add a few things
to the sighash by default that were overlooked in BIP143:
* Committing to the absolute transaction fee (in addition to just the
amount being spent in each input) would categorically remove concerns
about wallets
On Thu, Jul 12, 2018 at 6:52 PM Anthony Towns via bitcoin-dev
wrote:
> On Fri, Jan 26, 2018 at 09:34:39PM +, Gregory Maxwell via bitcoin-dev
> wrote:
> > [pubkey]
> > \-[pubkey]&&CSV
> > \-[fancy script]
>
> I think it's possible to do recursive taproot in this manner in a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hello all,
Bitcoin Core 0.16.3 was just released with a fix for
CVE-2018-17144:
https://bitcoincore.org/en/2018/09/18/release-0.16.3/
We urge all network participants to upgrade to 0.16.3[*] as soon
as possible.
[*] For those who build from source
On Tue, Sep 4, 2018, 04:32 Alex Bosworth via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> I've been experimenting with a format tag for BIP 174 to help support
> HTLC scripts I've been working with.
>
I've been thinking about this as well.
A useful way to look at it IMHO is to s
Hello all,
BIP174 currently specifies that non-witness UTXOs (the transactions
being spent by non-witness inputs) should be serialized in network
format.
I believe there are two issues with this.
1. Even in case the transaction whose output being spent itself has a
witness, this witness is immat
On Sat, Jul 14, 2018 at 8:42 AM, Sjors Provoost wrote:
> Questions:
>
> Regarding verification: why does bytes(P) use compressed key serialization
> rather than the implicit Y coordinate used for signing? I understand space
> savings don't matter since these values don't end up on the blockchain
On Tue, Jul 10, 2018 at 5:10 AM, matejcik wrote:
> On 6.7.2018 00:06, Pieter Wuille wrote:> The only case where "malicious"
> conflicting values can occur is when
>> one of the Signers produces an invalid signature, or modifies any of
>> the other fields already present in the PSBT for consumption
On Sun, Jul 8, 2018, 21:29 Erik Aronesty wrote:
> Because it's non-interactive, this construction can produce multisig
> signatures offline. Each device produces a signature using it's own
> k-share and x-share. It's only necessary to interpolate M of n shares.
>
> There are no round trips.
>
On Sun, Jul 8, 2018, 19:23 Erik Aronesty via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Pretty sure these non interactive sigs are more secure.
>
Schnorr signatures are provably secure in the random oracle model assuming
the discrete logarithm problem is hard in the used group.
On Sun, Jul 8, 2018, 07:26 Erik Aronesty via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> To save space, start with the wiki terminology on schnorr sigs.
>
> Consider changing the "e" term in the schnorr algorithm to hash of message
> (elligator style) to the power of r, rather th
Hello everyone,
Here is a proposed BIP for 64-byte elliptic curve Schnorr signatures,
over the same curve as is currently used in ECDSA:
https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki
It is simply a draft specification of the signature scheme itself. It
does not concern conse
On Thu, Jul 5, 2018 at 4:52 AM, matejcik wrote:
>> Allowing combiners to choose any value also allows for intelligent combiners
>> to choose the
>> correct values in the case of conflicts. A smart combiner could, when
>> combining redeem scripts
>> and witness scripts, check that the redeem scri
On Wed, Jul 4, 2018 at 6:19 AM, matejcik wrote:
> hello,
>
> we still have some concerns about the BIP as currently proposed - not
> about the format or data contents, but more about strictness and
> security properties. I have raised some in the previous e-mails, but
> they might have been lost i
On Wed, Jun 27, 2018, 07:04 matejcik wrote:
> hello,
>
> On 26.6.2018 22:30, Pieter Wuille wrote:
> >> (Moreover, as I wrote previously, the Combiner seems like a weirdly
> >> placed role. I still don't see its significance and why is it important
> >> to correctly combine PSBTs by agents that do
On Tue, Jun 26, 2018 at 8:33 AM, matejcik via bitcoin-dev
wrote:
> I'm still going to argue against the key-value model though.
>
> It's true that this is not significant in terms of space. But I'm more
> concerned about human readability, i.e., confusing future implementers.
> At this point, the
On Fri, Jun 15, 2018 at 8:54 AM, Russell O'Connor
wrote:
>
>> For codes designed for length 341 (the first length enough to support
>> 512 bits of data):
>> * correct 1 error = 3 checksum characters
>> * correct 2 errors = 7 checksum characters
>> * correct 3 errors = 11 checksum characters
>> * c
On Thu, Jun 21, 2018 at 12:56 PM, Peter D. Gray via bitcoin-dev
wrote:
> I have personally implemented this spec on an embedded micro, as
> the signer and finalizer roles, and written multiple parsers for
> it as well. There is nothing wrong with it, and it perfectly meets
> my needs as a hardware
On Thu, Jun 21, 2018 at 4:29 AM, matejcik wrote:
> In the case of everything per-input, the naive Signer can do this:
> 1. (in the global section) pre-serialize the transaction
> 2. (in each input) find and fill out scriptPubKey from the provided UTXO
> 3. (for a given BIP32 path) check if the mas
On Tue, Jun 19, 2018 at 7:20 AM, matejcik via bitcoin-dev
wrote:
Thanks for your comments so far. I'm very happy to see people dig into
the details, and consider alternative approaches.
> 1) Why isn't the global type 0x03 (BIP-32 path) per-input? How do we
> know, which BIP-32 path goes to which
Hello all,
given some recent work and discussions around BIP 174 (Partially
Signed Bitcoin Transaction Format) I'd like to bring up a few ideas.
First of all, it's unclear to me to what extent projects have already
worked on implementations, and thus to what extent the specification
is still subj
On Sun, Jun 3, 2018 at 2:30 PM, Jonas Schnelli wrote:
>> If there is interest, I can construct a code + implementation for any
>> of these in a few days probably, once the requirements are clear.
>
> Yes. Please.
Here is an example BCH code for base32 data which adds 27 checksum
characters, and c
1 - 100 of 200 matches
Mail list logo
