On Sunday, December 12th, 2021 at 9:23 AM, Aymeric Vitte via bitcoin-dev
> 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
On Wednesday, November 24th, 2021 at 7:44 AM, Sjors Provoost via bitcoin-dev
> Hi Andrew,
> I'm confused why PSBT_IN_TAP_BIP32_DERIVATION and
> contain not just the derivation path for the xonlypubkey, but also the
> tapleaf merkle path.
> First I
On Wednesday, November 17th, 2021 at 1:07 PM, Andrew Chow via bitcoin-dev
> 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
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
On Monday, October 25th, 2021 at 10:56 PM, lisa neigut via bitcoin-dev
> Hi all,
> In a recent conversation with @glozow, I had the realization that the mempool
> is obsolete and should be eliminated.
I see where this idea is coming from, especially as it relates to
On Wednesday, October 20th, 2021 at 3:20 PM, Owen Gunden via bitcoin-dev
> 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
On Oct 9, 2021, 11:36, Andreas Schildbach via bitcoin-dev <
> 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
Jumping in late to this thread.
I very much agree with how David Harding presents things, with a few comments
‐‐‐ Original Message ‐‐‐
On Sunday, August 8th, 2021 at 5:51 PM, David A. Harding via bitcoin-dev
> > 1. it's not our business what outputs people want to
On Thursday, September 16th, 2021 at 5:36 PM, Giacomo Caironi via bitcoin-dev
> 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
> > 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
On Sunday, August 29th, 2021 at 5:32 AM, Prayank via bitcoin-dev
> 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
On Saturday, August 28th, 2021 at 5:17 PM, ts via bitcoin-dev
> 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
> 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
‐‐‐ Original Message ‐‐‐
On Thursday, February 11, 2021 6:38 AM, Dr Maxim Orlovsky
> 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
On Friday, February 5, 2021 9:51 AM, Dr Maxim Orlovsky via bitcoin-dev
> 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
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
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:
On Monday, January 4, 2021 4:14 PM, Pieter Wuille
> Hello all,
> here is a BIP draft for changing the checksum in native segwit addresses for
> v1 and higher, following the discussion in
here is a BIP draft for changing the checksum in native segwit addresses for v1
and higher, following the discussion in
Overall, the idea is:
* Define a new encoding which is a tweaked variant of
On Monday, December 21, 2020 2:57 PM, Pieter Wuille via bitcoin-dev
> On Sunday, December 20, 2020 9:37 PM, Karl-Johan Alm via bitcoin-dev
> email@example.com 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
> 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
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
‐‐‐ 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
> On Wednesday, October 7, 2020 5:21 PM, Rusty Russell via bitcoin-dev
> firstname.lastname@example.org wrote:
> > I propose an alternative to length restrictions suggested by
> > Russell in https://github.com/bitcoin/bips/pull/945: use the
On Friday, November 6, 2020 11:49 AM, Mike Schmidt via bitcoin-dev
> 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
On Wednesday, October 7, 2020 5:21 PM, Rusty Russell via bitcoin-dev
> 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
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
> 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
> Hi all,
> BIP32  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
On Saturday, September 19, 2020 5:36 AM, yanmaani--- via bitcoin-dev
> Currently, Bitcoin's timestamp rules are as follows:
> 1. The block timestamp may not be lower than the median of the last 11
> 2. The block timestamp may not be greater than the current time plus
thanks for starting this thread. We definitely should make a decision around
On Wednesday, October 14, 2020 6:40 PM, Rusty Russell via bitcoin-dev
> > > 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
> 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
On Friday, August 21, 2020 1:50 AM, John Newbery via bitcoin-dev
> 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,
On Wednesday, August 12, 2020 11:49 AM, Pieter Wuille
> 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
The current BIP340 draft 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 for public keys after observing
On Tuesday, May 5, 2020 3:20 AM, Jonas Nick via bitcoin-dev
> 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 +
On Tuesday, March 24, 2020 6:00 AM, Lloyd Fournier via bitcoin-dev
> Hi List,
> I felt this topic deserved it's own thread but it follows on from the mailing
> list post  announcing a new PR  to change BIP-340 in several ways,
> including adding random auxiliary data into the
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
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:
On Fri, 14 Feb 2020 at 14:37, David A. Harding via bitcoin-dev
> 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.
> > 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
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:
It shows that the "insert or delete
On Tue, Nov 12, 2019, 21:33 ZmnSCPxj via bitcoin-dev <
> 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.
This has the
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
> > In the current draft, witness v1 outputs of length other
> > than 32 remain unencumbered, which means that for now such an
> > in
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
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
* The original post:
* Using 2 or 4 byte indexes:
On Mon, 16 Sep 2019 at 21:10, ZmnSCPxj via bitcoin-dev
> ‐‐‐ 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
In the draft for bip-tapscript (see , current version ), 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
On Tue, 6 Aug 2019 at 09:57, Niels Thijssen via bitcoin-dev
> 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
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,
On Fri, 9 Aug 2019 at 08:02, Elichai Turkel via bitcoin-dev
Since the idea of implicitly even pubkeys has potentially more general
implications, I've started a separate thread  about that idea.
> I want to add to John Newbery's suggestion of using implicit even/odd only
It has been suggested  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
On Fri, Jul 19, 2019, 12:13 William Casarin via bitcoin-dev <
> Hello Mike,
> Mike Brooks via bitcoin-dev
> > Motivation
> > Giving scripts the ability to refer to data on the blockchain will reduce
> > transaction sizes because
On Sun, May 26, 2019, 07:07 Aymeric Vitte via bitcoin-dev <
> 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
On Thu, 23 May 2019 at 11:33, Tamas Blummer via bitcoin-dev
> 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.
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
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
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
* 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
> 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
On Wed, 19 Dec 2018 at 18:06, Rusty Russell via bitcoin-dev
> 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
On Thu, 7 Feb 2019 at 12:19, Tamas Blummer via bitcoin-dev
> 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
> * A new opcode OP_MASK is added, which acts as a NOP during execution.
> * The sighash is computed like in BIP143,
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
On Thu, Jul 12, 2018 at 6:52 PM Anthony Towns via bitcoin-dev
> On Fri, Jan 26, 2018 at 09:34:39PM +, Gregory Maxwell via bitcoin-dev
> > [pubkey]
> > \-[pubkey]&
> > \-[fancy script]
> I think it's possible to do recursive taproot in this manner in a
-BEGIN PGP SIGNED MESSAGE-
Bitcoin Core 0.16.3 was just released with a fix for
We urge all network participants to upgrade to 0.16.3[*] as soon
[*] For those who build from
On Tue, Sep 4, 2018, 04:32 Alex Bosworth via bitcoin-dev <
> 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
BIP174 currently specifies that non-witness UTXOs (the transactions
being spent by non-witness inputs) should be serialized in network
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
On Sat, Jul 14, 2018 at 8:42 AM, Sjors Provoost wrote:
> 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
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
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 <
> 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
On Sun, Jul 8, 2018, 07:26 Erik Aronesty via bitcoin-dev <
> 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
Here is a proposed BIP for 64-byte elliptic curve Schnorr signatures,
over the same curve as is currently used in ECDSA:
It is simply a draft specification of the signature scheme itself. It
does not concern
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
On Wed, Jul 4, 2018 at 6:19 AM, matejcik wrote:
> 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
On Wed, Jun 27, 2018, 07:04 matejcik wrote:
> 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
On Tue, Jun 26, 2018 at 8:33 AM, matejcik via bitcoin-dev
> 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
>> 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
On Thu, Jun 21, 2018 at 12:56 PM, Peter D. Gray via bitcoin-dev
> 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
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
On Tue, Jun 19, 2018 at 7:20 AM, matejcik via bitcoin-dev
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
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
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
On Mon, Jun 11, 2018, 07:37 Bradley Denby via bitcoin-dev <
> Thanks for the comments Pieter!
> We can make descriptions for the intended node behaviors more clear in the
> Regarding interaction with BIPs 37 and 133, we have found that if
On Wed, Jun 6, 2018 at 5:48 AM, Tim Ruffing via bitcoin-dev
> On Thu, 2018-05-31 at 17:25 -0700, Pieter Wuille via bitcoin-dev wrote:
>> The best argument for why Graftroot does not need to be optional I
>> think was how Greg put it: "since the signer(s) could have si
On Thu, May 10, 2018 at 5:59 AM, Bradley Denby via bitcoin-dev
> Hi all,
> This iteration of Dandelion has been tested on our own small network, and we
> would like to get the implementation in front of a wider audience. An
> BIP document with further details on
On Sun, Jun 3, 2018 at 9:51 AM, Jonas Schnelli via bitcoin-dev
> The BIP proposal is now available here:
> Reference C code is available here:
On Sat, Jun 2, 2018, 22:56 Tamas Blummer via bitcoin-dev <
> Lighter but SPV secure nodes (filter committed) would help the network
> (esp. Layer 2) to grow mesh like, but add more user that blindly follow POW.
> On longer term most users' security
On Fri, May 25, 2018 at 3:14 AM, Johnson Lau wrote:
> A graftroot design like this is a strict subset of existing signature
> checking rules. If this is dangerous, the existing signature checking rules
> must be dangerous.
While you may be right in this situation, I'm not sure that conclusion
I spent some time working out the optimal parameter selection for the
Golomb Coded Sets that are proposed in BIP158:
TL;DR: if we really want an FP rate of exactly 1 in 2^20, the Rice
parameter should be 19, not 20. If we
On Tue, May 22, 2018 at 11:17 AM, Pieter Wuille wrote:
> Hello all,
> Given the recent discussions about Taproot  and Graftroot , I
> was wondering if a practical deployment needs a way to explicitly
> enable or disable the Graftroot spending path. I have no
Given the recent discussions about Taproot  and Graftroot , I
was wondering if a practical deployment needs a way to explicitly
enable or disable the Graftroot spending path. I have no strong
reasons why this would be necessary, but I'd like to hear other
On Fri, May 18, 2018, 19:57 Olaoluwa Osuntokun via bitcoin-dev <
> Greg wrote:
> > What about also making input prevouts filter based on the scriptpubkey
> > _spent_? Layering wise in the processing it's a bit ugly, but if you
> > validated
Thanks for starting a discussion about this idea.
A few comments inline:
On Wed, Mar 14, 2018 at 1:09 AM, Karl Johan Alm via bitcoin-dev <
> I am considering writing a replacement for the message signing tools
> that are currently
On Jan 9, 2018 13:41, "Mark Friedenbach via bitcoin-dev" <
The use of the alt stack is a hack for segwit script version 0 which has
the clean stack rule. Anticipated future improvements here are to switch to
a witness script version, and a new segwit
On Dec 11, 2017 10:23, "Nick Pudar via bitcoin-dev" <
This topic has come up several times in recent years. While it is well
intentioned, it can have devastating outcomes for people that want to save
long term. If such a system were implemented, it
On Oct 30, 2017 15:21, "shiva sitamraju via bitcoin-dev" <
For example bc1qeklep85ntjz4605drds6aww9u0qr46qzrv5xswd35uhjuj8ahfcqgf6hak
in 461e8a4aa0a0e75c06602c505bd7aa06e7116ba5cd98fd6e046e8cbeb00379d6 is 62
While I get the
On Fri, Sep 22, 2017 at 2:54 PM, Sergio Demian Lerner via bitcoin-dev <
> If the variable size increase is only a few bytes, then three
> possibilities arise:
> - one should allow signatures to be zero padded (to reach the maximum
> size) and
1 - 100 of 171 matches
Mail list logo