Let me know how can I help you with your proposal.
> Federico Berrone.
> P/D: This is my first participation in the bitcoin-dev list, sorry if I
> am breaking any rule, I would be glad to know if that is the case.
> El 15/09/2021 a las 8:14, Karl-Joh
BIPs are proposals.
They begin as ideas, are formulated and discussed on this list, and
assuming no glaring flaws are observed, turned into pull requests to
the bips repository, assigned a BIP number by the editors, and merged.
It is then organically incorporated into the various entities that
On Tue, 16 Mar 2021 at 07:48, Matt Corallo via bitcoin-dev
> Overall, the tradeoffs here seem ludicrous, given that any QC issues in
> Bitcoin need to be solved in another way, and
> can't practically be solved by just relying on the existing hash indirection.
The important distinction
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-checks
approach (invalid, inconclusive, valid) which is being modified here,
so would be
I have updated the signmessage proposal (BIP-322) to use the same
approach as signet uses, which brings out of the box support for psbt
and such, and removes the need for a custom signer and validator
(well, sort of anyway).
In the process, I've also replaced the concatenation approach
> Just FYI.
> On Wed, Mar 4, 2020 at 9:35 AM Luke Dashjr via bitcoin-dev
>> In addition to starting with proof-of-funds instead of proof-of-receiver, it
>> would be nice to integrate with Taproot somehow or another. Perhaps
I am proposing a modification to BIP-325 to make the genesis block
static and to rely on the message start to avoid collision between
signets when multiple nets exist simultaneously:
I forgot one:
5. The current BIP itself is poorly written and/or unnecessarily
complex: e.g. remove the multi-proof support, and/or remove the
extensibility stuff for a future proof-of-funds extension, and/or
focus solely on the generic sign message stuff.
I noticed recently that a PR to Bitcoin Core that pretty much touched
everything my BIP-322 pull request touches (around the same
complexity) was merged without a thought given to BIP-322
compatibility, despite the BIP-322 PR being open for 2x the time. I
can only conclude from this that
One of the tools I am maintaining called btcdeb (Bitcoin Script
Debugger) has a new experimental branch "taproot", which builds on top
of the WIP taproot pull request to Bitcoin Core, and contains a new
command line tool called "tap".
Tap allows you to compose taproot and/or tapscript
The pull request to the bips repository for Signet has stalled, as the
maintainer isn't sure Signet should have a BIP at all, i.e. "is Signet
My argument is that Signet is indeed Bitcoin and should have a BIP, as
this facilitates the interoperability between different software
I've proposed bitcoin invoice for awhile now. See
I like bitcoin invoice address into bitcoin address as proposed by Chris.
On Fri, Oct 11, 2019 at 12:45 AM Emil Engler via bitcoin-dev
> * Sorry if this mail was sent multiple
It makes no sense to me to not switch to 32-byte keys. There are
literally no (or very mild) disadvantages to this, from what it
appears like. I don't think refraining from updating a proposal just
because it's been out there for awhile is a valid reason, personally.
On Sat, Aug 10, 2019
People come in as Bitcoin developers all the time, but sometimes
people also leave permanently. In the case of BIP authors, when a user
leaves and does not respond to (reasonable) requests to change their
BIPs, we are sort of stuck right now.
BIP-2 states that anyone is allowed to request
I have written a BIP describing the Signet network. Feedback requested!
Pasted in its entirety below, with formatting issues left as is. See
above link for styled version.
Author: Karl-Johan Alm
On Wed, Mar 13, 2019 at 3:41 PM Varunram Ganesh
> I like your idea of a signet as it would greatly help test reorgs and stuff
> without having to experiment with regtest. But I'm a bit concerned about
> running a common signet (Signet1) controlled by a trusted entity. I
On Wed, Mar 13, 2019 at 12:23 PM Anthony Towns wrote:
> Maybe make the signature be an optional addition to the header, so
> that you can have a "light node" that doesn't download/verify sigs
> and a full node that does? (So signatures just sign the traditional
> 80-byte header,
-Johan Alm via bitcoin-dev
> > Keeping the PoW rule and moving the signature would mean DoS attacks
> > would be trivial as anyone could mine blocks without a signature in
> > them
> Sure, but anyone could also just connect their lite client to a trusted
work of bitcoin core nodes running regtest? (this gives you the
> same power as centralization without any changes or extra functionality
> El vie., 8 de mar. de 2019 a la(s) 16:02, Karl-Johan Alm via bitcoin-dev
On Sat, Mar 9, 2019 at 5:20 AM Matt Corallo wrote:
> To make testing easier, it may make sense to keep the existing block header
> format (and PoW) and instead apply the signature rules to some field in the
> coinbase transaction. This means SPV clients (assuming they only connect
As some of you already know, I've been working on a network called
"signet", which is bascially a complement to the already existing testnet,
except it is completely centralized, and blocks are signed by a specific
key rather than using proof of work.
Benefits of this:
1. It is more
(The quoted proposal is already outdated, and I recommend you check
out the up to date formatted version here:
The PR with comments is here: https://github.com/bitcoin/bips/pull/725)
A big part of the
A potential problem is that it would be a new attack vector to simply
color something to appear as e.g. 10x more than it really is, if
everyone started using this system.
On Sun, Aug 19, 2018 at 5:27 AM Martin Damgaard via bitcoin-dev
> Hi firstname.lastname@example.org
[note: BIP number was assigned to PR before this email was sent; I did
not self-assign the BIP number]
Below is a proposal to extend the existing sign/verifymessage format
to a more generalized variant relying on the script verification
mechanism in Bitcoin itself for message
On Fri, Aug 31, 2018 at 9:43 PM Gregory Maxwell via bitcoin-dev
> We looked at doing this previously in Bitcoin core and jtimon had some
> patches, but the existing approach increased the size of the
> blockindex objects in memory while not in signed testnet mode. This
> could probably
On Tue, Jun 5, 2018 at 10:08 AM, Jim Posen wrote:
> It also derives all bandwidth gains from address reuse. So I'm
> hesitant to make the complexity tradeoff for bandwidth savings due to a
> behavior that is actively discouraged.
I don't understand this comment. The bandwidth gains are not from
On Fri, May 18, 2018 at 12:25 AM, Matt Corallo via bitcoin-dev
> In general, I'm concerned about the size of the filters making existing
> SPV clients less willing to adopt BIP 158 instead of the existing bloom
> filter garbage and would like to see a
Thanks for clarifying!
On Wed, Apr 11, 2018 at 6:48 PM, ZmnSCPxj wrote:
> Good morning Karl-Johan Alm,
> To clarify:
> Nothing prevents a miner from completely ignoring nSequence when putting
> transactions in blocks.
> Unconfirmed transactions are, by definition,
On Wed, Apr 11, 2018 at 4:52 PM, Peter Todd wrote:
> Or via full replace-by-fee, which appears to be used by a significant minority
> of miners:
I was of the impression that final transactions (sequence=0x)
cannot be RBF'd.
Clarification on one part below:
On Wed, Apr 11, 2018 at 2:21 PM, Karl-Johan Alm
> On Wed, Apr 11, 2018 at 5:29 AM, Maksim Solovjov via bitcoin-dev
>> 1. What does it mean for a transaction ( with 0 confirmations
On Wed, Apr 11, 2018 at 5:29 AM, Maksim Solovjov via bitcoin-dev
> 1. What does it mean for a transaction ( with 0 confirmations ) to be
> trusted or not?
It is trusted if (1) it is final (i.e. it can't be replaced), (2) it
is not in a block that was
I made slight modification to the BIP, dropping the 0x80 jump to 0x10:
I will make the corresponding changes to the reference implementation shortly.
If there are no objections I would also like to
I took the liberty of turning this into a BIP proposal -- the
formatted version can be seen here:
Title: Typed Private Keys
Author: Karl-Johan Alm
Thanks for the feedback. Comments below:
On Mon, Mar 26, 2018 at 5:53 PM, Pieter Wuille wrote:
> One solution is to include a version number in the signature, which
> explicitly corresponds to a set of validation flags. When the version number
> is something a
On Fri, Mar 16, 2018 at 1:59 AM, Greg Sanders wrote:
> Sorry if I missed the rationale earlier, but why not just do a transaction,
> with a FORKID specifically for this? Then a node can have a mempool
> acceptance test that returns true even if the signature is not valid as
On Thu, Mar 15, 2018 at 2:14 PM, Luke Dashjr wrote:
> Not necessarily specific UTXOs (that would contradict fungibility, as well as
> be impossible for hot/cold wallet separation), but just to prove funds are
> available. The current sign message cannot be used to prove present
On Wed, Mar 14, 2018 at 12:36 PM, Luke Dashjr wrote:
> Ideally, it should support not only just "proof I receive at this address",
> but also "proof of funds" (as a separate feature) since this is a popular
> misuse of the current message signing (which doesn't actually prove
On Thu, Mar 15, 2018 at 6:43 AM, Jim Posen wrote:
> How are scripts with OP_CLTV and OP_CSV handled by verifiers? Do they always
> succeed? Or should an nLockTime and nSequence also be included in the proof
> in a way that can be parsed out and displayed to verifiers?
On Wed, Mar 14, 2018 at 5:46 AM, Kalle Rosenbaum wrote:
> I can't really see from your proposal if you had thought of this: A soft
> fork can make old nodes accept invalid message signatures as valid. For
> example, a "signer" can use a witness version unknown to the verifier
I am considering writing a replacement for the message signing tools
that are currently broken for all but the legacy 1xx addresses. The
approach (suggested by Pieter Wuille) is to do a script based
approach. This does not seem to require a lot of effort for
implementing in Bitcoin Core*.
This is the paper detailing the research behind my talk "Optimizing
fee estimation via the mempool state" (the presentation only covers
part of the paper) at Scaling Stanford (this coming Sunday). Feedback
On Wed, Sep 13, 2017 at 4:57 AM, Mark Friedenbach via bitcoin-dev
>> Without the limit I think we would be DoS-ed to dead
> 4MB of secp256k1 signatures takes 10s to validate on my 5 year old
> laptop (125,000 signatures, ignoring public keys and
On Wed, Jul 12, 2017 at 6:11 AM, Gregory Maxwell via bitcoin-dev
> IMO the way to do "roadmaps" in Bitcoin is to roadmap the finalization
> and release process once the basic technology is done; because it's
> only past that point that guarantees can
One thing about BIP148 activation that may be affected by this is the
fact that segwit signalling non-BIP148 miners + BIP148 miners may hold
majority hash power and prevent a chain split. With this SF, that will
no longer be the case, right? Or am I completely confused on the
On Wed, Jun
On Sat, Jun 3, 2017 at 2:55 AM, Alex Akselrod via bitcoin-dev
> Without a soft fork, this is the only way for light clients to verify that
> peers aren't lying to them. Clients can request headers (just hashes of the
> filters and the previous
I have spent a fair bit of time trying to nail how exactly block
filter digests should be done to optimize bandwidth, space,
The report can be found here: http://bc-2.jp/bfd-profile.pdf
This graph shows bandwidth use of 200 wallets simulated over 5000
On Tue, May 23, 2017 at 1:03 PM, Steven Pine via bitcoin-dev
> Correct me if I am wrong, but currently core developers are arguing over
> whether or not to allow an optional configuration switch which defaults off
> but signals and enforces BIP148
On Tue, May 9, 2017 at 3:58 AM, Erik Aronesty wrote:
> - It would be cool if any rate-limiting POW was specified as bytecode ... so
> nodes can plug in as many "machine-captcha" things as they please, and
> solvers can choose to solve... or just say "nope too hard".
I am proposing a new feature for rate limiting purposes where nodes
can make and solve arbitrary PoW challenges in return for connection
slots (to be expanded to cover e.g. bloom filters or other DoS risky
The BIP currently includes two proofs of work (sha256 and
Mail list logo