Re: [bitcoin-dev] BIP extensions

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, Karl-Joh

[bitcoin-dev] BIP extensions

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

Re: [bitcoin-dev] PSA: Taproot loss of quantum protections

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

Re: [bitcoin-dev] BIP-0322 (generic signmessage) improvements

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

[bitcoin-dev] Message signing (again)

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

Re: [bitcoin-dev] RFC: Kicking BIP-322 (message signing) into motion

. > > 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_MESSAGEONLY

[bitcoin-dev] Signet: static genesis block, and dynamic message start

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

Re: [bitcoin-dev] RFC: Kicking BIP-322 (message signing) into motion

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

[bitcoin-dev] RFC: Kicking BIP-322 (message signing) into motion

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

[bitcoin-dev] New tool to assist in BIP 340-342 review: tap

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

[bitcoin-dev] Is Signet Bitcoin?

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

Re: [bitcoin-dev] BIPable-idea: Consistent and better definition of the term 'address'

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

Re: [bitcoin-dev] 32-byte public keys in Schnorr and Taproot

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

[bitcoin-dev] Absent authors and BIP updates

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

[bitcoin-dev] BIP: Signet

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

Re: [bitcoin-dev] Signet

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

Re: [bitcoin-dev] Signet

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,

Re: [bitcoin-dev] Signet

-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

Re: [bitcoin-dev] Signet

work 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, >> &

Re: [bitcoin-dev] Signet

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

[bitcoin-dev] Signet

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

Re: [bitcoin-dev] RFC: BIP 322: Generic Signed Message Format

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

Re: [bitcoin-dev] Suggestion for a universal bitcoin value scale

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

[bitcoin-dev] RFC: BIP 322: Generic Signed Message Format

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

Re: [bitcoin-dev] Testnet3 Reest

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

Re: [bitcoin-dev] BIP 158 Flexibility and Filter Size

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

Re: [bitcoin-dev] BIP 158 Flexibility and Filter Size

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

Re: [bitcoin-dev] Few questions regarding ListTransaction

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,

Re: [bitcoin-dev] Few questions regarding ListTransaction

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.

Re: [bitcoin-dev] Few questions regarding ListTransaction

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

Re: [bitcoin-dev] Few questions regarding ListTransaction

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

Re: [bitcoin-dev] proposal: extend WIF format for segwit

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

Re: [bitcoin-dev] proposal: extend WIF format for segwit

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

Re: [bitcoin-dev] {sign|verify}message replacement

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

Re: [bitcoin-dev] {sign|verify}message replacement

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

Re: [bitcoin-dev] {sign|verify}message replacement

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

Re: [bitcoin-dev] {sign|verify}message replacement

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

Re: [bitcoin-dev] {sign|verify}message replacement

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

Re: [bitcoin-dev] {sign|verify}message replacement

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

[bitcoin-dev] {sign|verify}message replacement

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*.

[bitcoin-dev] Mempool optimized fees, etc. (Scaling Bitcoin)

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 ___

Re: [bitcoin-dev] Merkle branch verification & tail-call semantics for generalized MAST

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

Re: [bitcoin-dev] Updating the Scaling Roadmap

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

Re: [bitcoin-dev] User Activated Soft Fork Split Protection

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

Re: [bitcoin-dev] BIP Proposal: Compact Client Side Filtering for Light Clients

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

[bitcoin-dev] Block Filter Digest profiling

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:

Re: [bitcoin-dev] I do not support the BIP 148 UASF

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

Re: [bitcoin-dev] BIP Proposal: Rate Limiting with server specified Proof of Work challenges

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

[bitcoin-dev] BIP Proposal: Rate Limiting with server specified Proof of Work challenges

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)