Hello,
First off, apologies about my lack of participation. I am working on
mostly unrelated things and I'm afraid I have failed the community in
terms of what I can do on my end to keep the BIP process functional.
As such I am hereby resigning as BIP editor effective immediately.
Please remove m
> Let me know how can I help you with your proposal.
>
> Regards,
> 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, Kar
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
ex
On Tue, 16 Mar 2021 at 07:48, Matt Corallo via bitcoin-dev
wrote:
>
> 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
Hello,
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
(ha
h funds.
>
> Just FYI.
>
> On Wed, Mar 4, 2020 at 9:35 AM Luke Dashjr via bitcoin-dev
> wrote:
>>
>> 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
>> OP_M
Hello,
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:
https://github.com/bitcoin/bips/pull/900
___
bitcoin-dev mailin
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.
=
6. Some othe
Hello,
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 pe
Hello,
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 outp
Hello,
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
Bitcoin?".
My argument is that Signet is indeed Bitcoin and should have a BIP, as
this facilitates the interoperability between different software i
I've proposed bitcoin invoice for awhile now. See
https://twitter.com/kallewoof/status/1165841566105079808
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
wrote:
>
> * Sorry if this mail was sent multiple tim
Hello,
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 a
Hello,
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
Hello,
I have written a BIP describing the Signet network. Feedback requested!
https://github.com/bitcoin/bips/pull/803
Pasted in its entirety below, with formatting issues left as is. See
above link for styled version.
BIP:
Layer: Applications
Title: Signet
Author: Karl-Johan Alm
Commen
Hi Varunram,
On Wed, Mar 13, 2019 at 3:41 PM Varunram Ganesh
wrote:
>
> 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 gu
Hi Anthony,
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, and
-Johan Alm via bitcoin-dev
> wrote:
> > 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
> n
e network of bitcoin core nodes running regtest? (this gives you the
> same power as centralization without any changes or extra functionality
> required)
>
> El vie., 8 de mar. de 2019 a la(s) 16:02, Karl-Johan Alm via bitcoin-dev
> escribió:
>>
>> Hello,
>>
Hi Matt,
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 to
Hello,
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 predi
Greetings,
(The quoted proposal is already outdated, and I recommend you check
out the up to date formatted version here:
https://github.com/kallewoof/bips/blob/bip-generic-signmessage/bip-0322.mediawiki
The PR with comments is here: https://github.com/bitcoin/bips/pull/725)
A big part of the fee
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
wrote:
>
> Hi bitcoin-dev@lists.linuxfoundation.org
>
> Here is
Hi.
[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 signing/verifica
On Fri, Aug 31, 2018 at 9:43 PM Gregory Maxwell via bitcoin-dev
wrote:
> 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
a
On Fri, May 18, 2018 at 12:25 AM, Matt Corallo via bitcoin-dev
wrote:
> 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 further exploration of ways to
> split
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, not recorded in blocks.
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.
___
bitcoin-dev maili
Clarification on one part below:
On Wed, Apr 11, 2018 at 2:21 PM, Karl-Johan Alm
wrote:
> On Wed, Apr 11, 2018 at 5:29 AM, Maksim Solovjov via bitcoin-dev
> wrote:
>> 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.
On Wed, Apr 11, 2018 at 5:29 AM, Maksim Solovjov via bitcoin-dev
wrote:
> 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 reorged out (negative confirmation coun
Hello,
I made slight modification to the BIP, dropping the 0x80 jump to 0x10:
https://github.com/kallewoof/bips/blob/bip-typed-wif/bip-extended-privkey.mediawiki
I will make the corresponding changes to the reference implementation shortly.
If there are no objections I would also like to request
I took the liberty of turning this into a BIP proposal -- the
formatted version can be seen here:
https://github.com/kallewoof/bips/blob/bip-typed-wif/bip-extended-privkey.mediawiki
BIP: XXX
Layer: Applications
Title: Typed Private Keys
Author: Karl-Johan Alm
Comments-Summary: No comme
Pieter,
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 verifier doesn't know, it c
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 per
> Bitcoin consensus
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 possession
> of fun
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 funds at
> all). To d
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?
Good question.. Since you do
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 to
> fool the verifie
Hello,
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*. B
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
welcome.
https://bc-2.jp/mempool.pdf
___
bitcoin
On Wed, Sep 13, 2017 at 4:57 AM, Mark Friedenbach via bitcoin-dev
wrote:
>> 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 other things that
> would consume space). T
On Wed, Jul 12, 2017 at 6:11 AM, Gregory Maxwell via bitcoin-dev
wrote:
> 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 really start being made.
Bitcoin develo
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
subject?
On Wed, Jun
On Sat, Jun 3, 2017 at 2:55 AM, Alex Akselrod via bitcoin-dev
wrote:
> 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 headers, creating a chain) and look for conflic
Hello,
Really wish I'd known you were working on this a few weeks ago, but
such is life. Hopefully I can provide some useful feedback.
On Fri, Jun 2, 2017 at 4:01 AM, Olaoluwa Osuntokun via bitcoin-dev
wrote:
> Full-nodes
> maintain an additional index of the chain, and serve this compact filter
Hello,
I have spent a fair bit of time trying to nail how exactly block
filter digests[1] should be done to optimize bandwidth, space,
resource usage.
The report can be found here: http://bc-2.jp/bfd-profile.pdf
This graph shows bandwidth use of 200 wallets simulated over 5000
blocks: http://bc-
On Tue, May 23, 2017 at 1:03 PM, Steven Pine via bitcoin-dev
wrote:
> 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 when used. Who are we protecting users from
Hello,
Some time has passed since this was initially posted, and I have not
received any negative feedback. If no objections are raised, I would
like to have a BIP number assigned.
On Mon, May 8, 2017 at 11:48 AM, Karl Johan Alm
wrote:
> Hello,
>
> I am proposing a new feature for rate limiting
Erik,
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'm not entirely sure w
Hello,
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
services).
The BIP currently includes two proofs of work (sha256 and
cuckoo-cycle) w
52 matches
Mail list logo
