On Feb 25, 2017 14:09, "Steve Davis via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
Hi Peter,
I really, really don’t want to get into it but segwit has many aspects that
are less appealing, not least of which being the amount of time it would
take to reach the critical mass.
Su
On Feb 25, 2017 22:26, "Steve Davis" wrote:
Hi Pieter,
> On Feb 25, 2017, at 4:14 PM, Pieter Wuille
wrote:
>
> Any alternative to move us away from RIPEMD160 would require:
>
“Any alternative”? What about reverting to:
[, OP_CHECKSIG]
snip
Could that be the alternative?
Ok, fair enoug
On Feb 28, 2017 15:10, "Bram Cohen via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
On Tue, Feb 28, 2017 at 8:43 AM, G. Andrew Stone
wrote:
>
> But since transactions' prevouts are not specified by [block height, tx
> index, output index] or by TXO index, I don't understand how a
On Wed, Mar 8, 2017 at 1:20 PM, Jonas Schnelli via bitcoin-dev
wrote:
>
>> Am 08.03.2017 um 22:09 schrieb Eric Voskuil :
>>
>> On 03/08/2017 11:47 AM, Jonas Schnelli wrote:
> Nodes are by design not supposed to be identifiable in any way
This is of course my objection to BIP150 ("a w
On Wed, Mar 8, 2017 at 5:16 PM, Eric Voskuil wrote:
> On 03/08/2017 03:12 PM, Pieter Wuille wrote:
>> In that way, I see BIP150 as an extension of IP addresses, except more
>> secure against network-level attackers. If you believe the concept of
>> people establishing links along existing trust li
Hello everyone,
I'd like to propose a new BIP for native segwit addresses to replace
BIP 142. These addresses are not required for segwit, but are more
efficient, flexible, and nicer to use.
The format is base 32 and uses a simple checksum algorithm with strong
error detection properties. Referen
On Thu, Mar 23, 2017 at 3:37 PM, Juan Garavaglia via bitcoin-dev
wrote:
> Long story short, when nodes 0.13+ receive blocks from 0.13+ nodes all is
> ok, and those blocks propagate to older nodes with no issues. But when a
> block tries to be propagated from bitcoind 0.12.+ to newer ones those blo
On Tue, Mar 28, 2017 at 12:56 PM, Paul Iverson via bitcoin-dev
wrote:
> So I think Core can't decide on hard forks like this. It must be left up to
> the users. I think only choice is for Core to add a run-time option to allow
> node operators to increase block size limit, so that this very contro
On Mon, Mar 20, 2017 at 2:35 PM, Pieter Wuille
wrote:
> Hello everyone,
>
> You can find the text here:
> https://github.com/sipa/bech32/blob/master/bip-witaddr.mediawiki
>
Responding to a few comments:
By Andreas Schildbach:
> I'm not convinced that transmitting addresses via voice should be
Hello all,
I would like to discuss a way of computing a UTXO set hash that is
very efficient to update, but does not support any compact proofs of
existence or non-existence.
Much has been written on the topic of various data structures and
derived hashes for the UTXO/TXO set before (including Al
On Tue, May 16, 2017 at 4:01 AM, Peter Todd via bitcoin-dev
wrote:
> To be clear, *none* of the previous (U)TXO commitment schemes require *miners*
> to participate in generating a commitment. While that was previously thought
> to
> be true by many, I've seen no counter-arguments to the argument
On Sun, May 7, 2017 at 2:39 PM, Pieter Wuille wrote:
> I'd like to move forward and request a BIP number assignment for this
> proposal.
The proposal has been submitted as BIP173:
https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki
Cheers,
--
Pieter
_
On Mon, May 22, 2017 at 9:47 PM, Rusty Russell wrote:
> Gregory Maxwell via bitcoin-dev
> writes:
>> On Tue, May 16, 2017 at 6:17 PM, Pieter Wuille
>> wrote:
>>> just the first - and one that has very low costs and no normative
>>> datastructures at all.
>>
>> The serialization of the txout it
On Wed, Jul 15, 2015 at 12:06 PM, Me via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Have you talk to them? If not, how can you be sure they don’t run large
> number of standard nodes and actually make the network stronger? Personally
> I never bring claims like this if I just as
Hello all,
I'd like to talk a bit about my view on the relation between the Bitcoin
Core project, and the consensus rules of Bitcoin.
I believe it is the responsibility of the maintainers/developers of Bitcoin
Core to create software which helps guarantee the security and operation of
the Bitcoin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello all,
I'd like to disclose a vulnerability I discovered in September 2014,
which became unexploitable when BIP66's 95% threshold was reached
earlier this month.
## Short description:
A specially-crafted transaction could have forked the blockch
On Thu, Jul 30, 2015 at 2:29 PM, Gavin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> > On Jul 30, 2015, at 4:21 AM, Eric Lombrozo wrote:
> >
> > and a number of the people most intimately familiar with the inner
> workings of the system (some of whom are in this thread) think
Hello all,
here is a proposal for long-term scalability I've been working on:
https://gist.github.com/sipa/c65665fc360ca7a176a6
Some things are not included yet, such as a testnet whose size runs ahead
of the main chain, and the inclusion of Gavin's more accurate sigop
checking after the hard for
On Thu, Jul 30, 2015 at 4:05 PM, Gavin Andresen
wrote:
> On Thu, Jul 30, 2015 at 8:50 AM, Pieter Wuille
> wrote:
>
>> Let's scale the block size gradually over time, according to
>> technological growth.
>
>
> Yes, lets do that-- that is EXACTLY what BIP101 intends to do.
>
Oh come on. Immediat
On Jul 30, 2015 6:20 PM, "Gavin Andresen" wrote:
>
> On Thu, Jul 30, 2015 at 10:25 AM, Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> Some things are not included yet, such as a testnet whose size runs
ahead of the main chain,
On Fri, Jul 31, 2015 at 10:39 AM, jl2012 via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> There is a summary of the proposals in my previous mail at
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009808.html
> 1. Initiation: BIP34 style voting, with support of
On Sat, Aug 1, 2015 at 10:22 PM, John T. Winslow via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Regarding the block size increase, at least conceptually it seems to me
> there should be an easy solution. If we look at what works well with
> bitcoin, for example the block reward
>>> 2. Starting date: 30 days after 75% miner support, but not before
>>> 2016-01-12 00:00 UTC
>>>
>>> Rationale: A 30-day grace period is given to make sure everyone has
>>> enough time to follow. This is a compromise between 14 day in BIP101
>>> and 1 year in BIP103. I tend to agree with BIP101.
I would like to withdraw my proposal from your self-appointed vote.
If you want to let a majority decide about economic policy of a currency, I
suggest fiat currencies. They have been using this approach for quite a
while, I hear.
Bitcoin's consensus rules are a consensus system, not a democracy.
I would say that things already demonstrately got terrible. The mining
landscape is very centralized, with apparently a majority depending on
agreements to trust each other's announced blocks without validation. Full
node count is at its historically lowest value in years, and outsourcing of
full v
On Tue, Aug 4, 2015 at 3:12 PM, Gavin Andresen
wrote:
> On Tue, Aug 4, 2015 at 7:27 AM, Pieter Wuille via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> I would say that things already demonstrately got terrible. The mining
>> landscape is very cen
On Sun, Jun 28, 2015 at 9:50 PM, Peter Todd wrote:
> On Thu, Jun 25, 2015 at 06:33:44PM -0400, Peter Todd wrote:
> > Thoughts? If there are no objections I'll go ahead and write that code,
> > using the same thresholds as BIP66.
>
> I've opened a pull-req to deploy CHECKLOCKTIMEVERIFY via the
> I
On Thu, Aug 6, 2015 at 3:40 PM, Gavin Andresen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Wed, Aug 5, 2015 at 9:26 PM, Jorge Timón <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> This is a much more reasonable position. I wish this had been starting
>> point of thi
On Thu, Aug 6, 2015 at 4:21 PM, Gavin Andresen
wrote:
> On Thu, Aug 6, 2015 at 10:06 AM, Pieter Wuille
> wrote:
>
>> But you seem to consider that a bad thing. Maybe saying that you're
>> claiming that this equals Bitcoin failing is an exaggeration, but you do
>> believe that evolving towards an
On Thu, Aug 6, 2015 at 5:06 PM, Gavin Andresen
wrote:
> On Thu, Aug 6, 2015 at 10:53 AM, Pieter Wuille
> wrote:
>
>> So if we would have 8 MB blocks, and there is a sudden influx of users
>> (or settlement systems, who serve much more users) who want to pay high
>> fees (let's say 20 transaction
On Thu, Aug 6, 2015 at 8:43 PM, Michael Naber wrote:
> How many nodes are necessary to ensure sufficient network reliability?
> Ten, a hundred, a thousand? At what point do we hit the point of
> diminishing returns, where adding extra nodes starts to have negligible
> impact on the overall reliab
On Aug 6, 2015 9:42 PM, "Gavin Andresen via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
2. The "market minimum fee" should be determined by the market. It should
not be up to us to decide "when is a good time."
I partially agree. The community should decide what risks it is willin
On Fri, Aug 7, 2015 at 1:26 AM, Dave Scotese via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
"Miners can do this unilaterally" maybe, if they are a closed group, based
> on the 51% rule. But aren't they using full nodes for propagation? In this
> sense, anyone can vote by coding.
On Fri, Aug 7, 2015 at 4:57 PM, Gavin Andresen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Every once in a while the network will get lucky and we'll find six blocks
> in ten minutes. If you are deciding what transaction fee to put on your
> transaction, and you're willing to
On Fri, Aug 7, 2015 at 5:55 PM, Gavin Andresen
wrote:
> On Fri, Aug 7, 2015 at 11:16 AM, Pieter Wuille
> wrote:
>
>> I guess my question (and perhaps that's what Jorge is after): do you feel
>> that blocks should be increased in response to (or for fear of) such a
>> scenario.
>>
>
> I think the
On Fri, Aug 7, 2015 at 6:06 PM, Thomas Zander via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> You make a logical fallacy;
>
> I would agree that nodes are there for people to stop trusting someone that
> they have no trust-relationship with.
>
Yay, trust!
> But your conclusion
On Fri, Aug 7, 2015 at 7:00 PM, Thomas Zander via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> > If the incentives for running a node don't weight up against the
> > cost/difficulty using a full node yourself for a majority of people in
> the
> > ecosystem, I would argue that ther
On Aug 7, 2015 7:50 PM, "Gavin Andresen" wrote:
>
>
> On Fri, Aug 7, 2015 at 12:30 PM, Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> If the incentives for running a node don't weight up against the
cost/difficulty us
On Mon, Aug 10, 2015 at 4:12 PM, Gavin Andresen
wrote:
>
> Executive summary: when networks get over-saturated, they become
> unreliable. Unreliable is bad.
>
> Unreliable and expensive is extra bad, and that's where we're headed
> without an increase to the max block size.
>
I think I see your
On Aug 10, 2015 7:03 PM, "odinn via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
Note that I've
> been in favor of going ahead with Cameron Garnham's dynamic softfork
> proposal right now, which can be seen at http://is.gd/DiFuRr
No offence, but I think that anyone who claims a blo
On Aug 7, 2015 11:19 PM, "Sergio Demian Lerner via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> b. Reduce the block rate to a half (average 5 minute blocks)
>
> Suppose this is a one time hard fork. There no drastic technical problems
with any of them: "SPV" mining and the relay n
On Aug 11, 2015 12:11 AM, "Sergio Demian Lerner"
wrote:
> What I'm saying is that this ratio may have improved 20x since miners
began using the TheBlueMatt relay network, so deteriorating the ratio 2x
does not put miners in a unknown future, but in an future which is far
better than the state they
On Aug 11, 2015 12:18 AM, "Thomas Zander via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Have you ever been to a concert that was far away from public transport?
They
> typically set up bus shuttles, or taxis to get people back into town
> afterwards.
> The result there is alway
On Aug 11, 2015 12:52 AM, "Pieter Wuille" wrote:
>
>
> On Aug 11, 2015 12:18 AM, "Thomas Zander via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> > Have you ever been to a concert that was far away from public
transport? They
> > typically set up bus shuttles, or taxis to get pe
On Tue, Aug 11, 2015 at 9:37 PM, Michael Naber via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hitting the limit in and of itself is not necessarily a bad thing. The
> question at hand is whether we should constrain that limit below what
> technology is capable of delivering. I'm
On Tue, Aug 11, 2015 at 11:30 PM, Angel Leon via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> tell that to people in poor countries, or even in first world countries.
> The competitive thing here is a deal breaker for a lot of people who have
> no clue/don't care for decentralizat
On Tue, Aug 11, 2015 at 11:35 PM, Michael Naber wrote:
> Bitcoin would be better money than current money even if it were a bit
> more expensive to transact, simply because of its other great
> characteristics (trustlessness, limited supply, etc). However... it is not
> better than something else
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
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
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
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, 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 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 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, 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 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 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
> 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
‐‐‐ 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 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
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 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
>
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, 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
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 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 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 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
‐‐‐ 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
> 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
> 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
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?
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 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
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 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
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 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
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 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
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
> 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 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
> 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
--- 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
--- 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
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/
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
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
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
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,
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
--- 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
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
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
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/
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
101 - 200 of 200 matches
Mail list logo
