Re: [bitcoin-dev] Decentralized BIP 47 payment code directory

Hi Peter, > Regarding to BIP47 there's a newer version (v3 and v4) proposed here: > https://github.com/OpenBitcoinPrivacyProject/rfc/blob/master/obpp-05.mediawiki > Now the notification from Alice to Bob is a transaction from Alice to Alice > as a bare 1 of 3 multisig. The other 2 pubkeys repre

Re: [bitcoin-dev] Wasabi Wallet 2.0 Testnet Release

Hi Max, > Whenever the user wants to spend bitcoin to an address, the wallet > automatically selects those private coins with sufficient sats, coin control > is displayed to the user. 1.There are no 'private' coins. Every coin is public in Bitcoin. 2.Since, the wallet assumes some coins as 'pr

[bitcoin-dev] Decentralized BIP 47 payment code directory

Hello World, There was some discussion about BIP 47 on twitter recently: https://twitter.com/BitcoinQ_A/status/1356177927285714946 BIP 47 improves privacy however there are a few reasons why its less used: 1.Some developers consider it spams Bitcoin without improving anything: https://twitter.c

Re: [bitcoin-dev] Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

Good morning ZmnSCPxj, > Of course, I know of no such technique, but given that a technique > (Drivechains) which before would have required its own consensus change, > turns out to be implementable inside recursive covenants, then I wonder if > there are other things that would have required t

Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt

Goog morning ZmnSCPxj, Context: https://bitcointalk.org/index.php?topic=48.msg329#msg329 Maybe I should have rephrased it and quote Satoshi. I agree I should not speak for others and it was not my intention in the email. > If Satoshi refuses to participate in Bitcoin development today, who care

Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt

> note how ETH has quite high on chain fees for basic transactions,> because > there are so many use-cases where the per-tx value can afford much> higher > fees. That kind of expansion of use-case also arguably harms Bitcoin as> a > whole by providing more fuel for a future contentious blocksize

Re: [bitcoin-dev] Thoughts on fee bumping

> If anyone has any indication that there are miners running forks of bitcoind > that change this behavior, I'd be curious to know it. It is possible because some mining pools use bitcoind with custom patches.  Example: https://twitter.com/0xB10C/status/1461392912600776707 (f2pool) -- Prayank

Re: [bitcoin-dev] Thoughts on fee bumping

> I suspect the "economically rational" choice would be to happily trade off > that immediate loss against even a small chance of a simpler policy > encouraging higher adoption of bitcoin, _or_ a small chance of more on-chain > activity due to higher adoption of bitcoin protocols like lightning

Re: [bitcoin-dev] [Lightning-dev] Lightning and other layer 2 projects with multiple RBF policies

> That's not an argument not to do it though if you take a longer term > perspective on building the strongest possible foundation for Lightning or > other Layer 2 projects. The security benefit would just be delayed until a > significant majority of Bitcoin Core users upgraded to a version incl

Re: [bitcoin-dev] [Lightning-dev] Lightning and other layer 2 projects with multiple RBF policies

> I suspect as with defaults generally most users will run whatever the > defaults are as they won't care to change them (or even be capable of > changing them if they are very non-technical). 30% nodes are using 0.21.1 right now whereas latest version was 22.0 and some are even running lower

[bitcoin-dev] Lightning and other layer 2 projects with multiple RBF policies

Hello World, There was a discussion about improving fee estimation in Bitcoin Core last year in which 'instagibbs' mentioned that we cannot consider mempool as an orderbook in which which everyone is bidding for block space because nodes can use different relay policies: https://bitcoin-irc.ch

Re: [bitcoin-dev] Improving RBF Policy

Hi Bastein, > This work will highly improve the security of any multi-party contract trying > to build on top of bitcoin Do you think such multi party contracts are vulnerable by design considering they rely on policy that cannot be enforced? > For starters, let me quickly explain why the curre

[bitcoin-dev] non-default ports for automatic connections in Bitcoin P2P network

## Using non-default ports for automatic connections in Bitcoin P2P network ISPs can block default port 8333 used by Bitcoin nodes. One example: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-September/010798.html While it would still be possible for crawlers and scanners to know a

Re: [bitcoin-dev] CTV BIP review

Hi Luke, This is the first competent review for CTV based on my understanding. I would not mention controversial things in this email but nobody cares about scammers and we will review everything irrespective of personal or legal attacks on developers because some people are prepared for it and

Re: [bitcoin-dev] On the regularity of soft forks

> We should strive to one day get to a point where the bitcoin consensus isn't > updating at all. That day is nowhere near IMO and maybe we won't see it in my lifetime. > Perhaps we should come to a consensus as a consensus as a community what the > minimum time between soft forks should be, an

Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt

Hi Peter, > that current lacks compelling use-cases clearly beneficial to all users All the use cases shared in below links look compelling enough to me and we can do anything that a programmer could think of using such restrictions: https://utxos.org/uses/ https://rubin.io/archive/ > I don'

[bitcoin-dev] CTV and ANYPREVOUT vault designs

Everything shared in this email was earlier posted by Michael Folkson on Bitcoin Stackexchange (a site that allows people to close opinion based questions), cross posting here so that more developers could discuss and in a better way. I have just removed one paragraph. At the time of writing (J

Re: [bitcoin-dev] Bitcoin Legal Defense Fund

Hi Jack, > The main purpose of this Fund is to defend developers from lawsuits regarding >their activities in the Bitcoin ecosystem, including finding and retaining >defense counsel, developing litigation strategy, and paying legal bills. This >is a free and voluntary option for developers to

Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt

really want to spend my year imploring people to dig deeper on this >>> before indicating they support an imminent activation attempt. Some people >>> don't have the understanding to dig deeper, some people don't have the time >>> and some don't have eit

Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt

nteresting) I don't feel like I can participate because deployment > and activation is being included and I think it is irresponsible to be > discussing those at this point. In my view activation should not even be > speculated upon until it is clear there is overwhelming community support for

Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt

uld be clear consensus for APO. -- Prayank A3B1 E430 2298 178F Jan 4, 2022, 20:12 by decker.christ...@gmail.com: > Prayank via bitcoin-dev writes: > >>> To contrast with his approach, the authors and contributors of >>> another future soft fork proposal (BIP 118 [3

Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt

Hi Michael, > If OP_CTV is ready to go now and has overwhelming community support (I don’t > think either is true) it should surely have been included in the Taproot soft > fork (perhaps delayed) rather than going through the months of activation > wrangling and community outreach twice. It sh

Re: [bitcoin-dev] Nuke *notify options from Bitcoin Core

Hi Daniel, Not sure which PRs are you talking about, maybe you missed these points based on your understanding: Lot of fancy things won't work in windows shortcut target It is more suspicious even if you try, compared to something wrapped in *notify options provided by bitcoin core This will

[bitcoin-dev] Nuke *notify options from Bitcoin Core

Hello World, What? Remove all *notify options from Bitcoin Core (full node implementation used by 99% nodes) Or one of the below: notifications.dat not use system() in runCommand() Use a new setting in settings.json file, notifypolicy which is 0 by default (restricted) and can be set to 1 (un

Re: [bitcoin-dev] [Bitcoin Advent Calendar] Derivatives and Options

Hi Jeremy, > Wheres the info come from? Well, multiple places. We could get it from a > third party (maybe using anattestation chain of some sort?), or there are > certain ways it could beself-referential (like for powswap > ). > Now let’s define a threshold oracle – we wo

Re: [bitcoin-dev] [Bitcoin Advent Calendar] A Defense of Having Fun (and maybe staying poor)

Hi Jeremy, > Eugene just dropped a project he’s been working on, and it’s really freakin’ > cool. He basically implemented a human v. chess engine in Solidity that mints > beautiful interactive NFTs of representations of the contract’s internal > states. Not sure why NFT is involved here but e

Re: [bitcoin-dev] [Bitcoin Advent Calendar] Review of Smart Contract Concepts

Hi Jeremy, > This post covers some high-level smart contract concepts that different opcodes or proposals could have (or not). https://rubin.io/bitcoin/2021/12/04/advent-7/ Interesting post. I love the concept of recursion in programming. There is one Indian movie called 'Karthik calling Karthik

Re: [bitcoin-dev] [Bitcoin Advent Calendar] What's Smart about Smart Contracts

Hi Jeremy, > Here's the day 6 post: https://rubin.io/bitcoin/2021/12/03/advent-6/, the topic is why smart contracts (in extended form) may be a critical precursor to securing Bitcoin's future rather than something we should do after making the base layer more robust. There are few comparisons in

Re: [bitcoin-dev] Rebroadcast mechanism in Bitcoin P2P network

Hi Aymeric, > What I am proposing since years, not only to bitcoin, is to use the Tor protocol independently of the Tor network, and from the browsers alsoacting as nodes (not to be misunderstood with the Tor Browser, this hasnothing to do) probably someone one day will understand it I understand

[bitcoin-dev] Rebroadcast mechanism in Bitcoin P2P network

Hello World, I had started working on this blog dedicated to Hal Finney in August: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-August/019367.html I have been able to track more than 10 Issues and Pull Requests from different Bitcoin projects that are focused on privacy. Wrote 3

Re: [bitcoin-dev] Pawn (chess piece) | Breaking bitcoin by playing chess

lltech.com.au > www.go-overt.com > duigco.org DUIGCO API > and other projects >   > > m. 0487135719 > f. +61261470192 > > > This email does not constitute a general advice. Please disregard this email > if misdelivered. > > > > From:> bitcoin-de

[bitcoin-dev] Pawn (chess piece) | Breaking bitcoin by playing chess

Hello World, Link with what, why and how: https://gist.github.com/prayank23/22763f48199ed106e59801be43ad4efc Two related things that I found: 1.Koala Studio tried chess on LN in 2019 but shutdown in August 2019 2.Etleneum still has chess but works differently Primary goal of this project can

Re: [bitcoin-dev] A fee-bumping model

Good morning darosior, Subject of the email looks interesting and I have few comments on the things shared: > The part of Revault we are interested in for this study is the delegation > process, and more specifically the application of spending policies by > network monitors (watchtowers). Par

Re: [bitcoin-dev] Trying to patch Core ZMQ "rawtx" topic to only publish unconfirmed transactions: How?

Hi Ali, Not sure if this is exactly what you are looking for but maybe trying to solve this I might also learn few things: Save zmqpubsequence=tcp://127.0.0.1:28332 in bitcoin.conf Run bitcoind Run this python script: https://pastebin.com/raw/tNp2x5y3 You will see results like this: https://

Re: [bitcoin-dev] Mock introducing vulnerability in important Bitcoin projects

Good morning ZmnSCPxj, > Indeed, I believe we should take the position that "review process is as much > a part of the code as the code itself, and should be tested regularly". Agree. Review process is an important part of open source Bitcoin projects. We should test and verify if everything is

Re: [bitcoin-dev] bitcoin.org missing bitcoin core version 22.0

could also look into a system like Monero's CCS. Yes I like it and suggested once in bitcoin.org repository even though it can be done by anyone as there is no official website for Bitcoin: https://github.com/bitcoin-dot-org/Bitcoin.org/issues/3545 -- Prayank A3B1 E430 2298 178F N

Re: [bitcoin-dev] bitcoin.org missing bitcoin core version 22.0

Hi Kate, > He is taking the most sensible way forward, decreasing bus factor. Agree. Work being shared with other maintainers is an improvement. > Read: https://laanwj.github.io/2021/01/21/decentralize.html Interesting blog post. First paragraph talks about strange expectations, not sure what

Re: [bitcoin-dev] bitcoin.org missing bitcoin core version 22.0

Hi Owen, > When I search for "download bitcoin core" my top result is bitcoin.org, which >is out of date and doesn't have 22.0 This is an issue related to SEO which only website owners can fix or maybe others can help who know better. > It seems confusing to have two sites that seemingly both

Re: [bitcoin-dev] Taproot testnet wallet

Hi Andreas, > 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 did this transaction few days back which creates a P2TR output while answering a question on Bitcoin Stackexc

Re: [bitcoin-dev] On the regularity of soft forks

Hi Michael, Agree with almost everything. > Miner signaling is a tool for signaling readiness. It is not voting for the > soft fork or expressing support for the soft fork. There should not be any > attempt to facilitate miner signaling until there is sufficient community > consensus (the mini

Re: [bitcoin-dev] Wednesday’s second BIP process meeting

Good morning Michael, Thanks for sharing the summary about BIP process meeting. > However, zero filters creates a Ethereum style bewildering number of BIPs of > varying quality that all need to be stored and maintained. The option of > being able to store a BIP in any repo doesn’t appear to of

Re: [bitcoin-dev] Mock introducing vulnerability in important Bitcoin projects

This looks interesting although I don't understand few things: > The scheme should include public precommitments collected at ceremonial > intervals. How would this work? Can you explain with an example please. > Upon assignment, the dev would have community approval to opportunistically > ins

Re: [bitcoin-dev] Mock introducing vulnerability in important Bitcoin projects

Good morning ZmnSCPxj, Although its evening here and time zones feel irrelevant since I got involved in Bitcoin few years back. Initially I tried everything a tech enthusiast does after finding such thing online. Had a startup in 2017 which was a website that can be used to buy flight tickets u

[bitcoin-dev] Replacement transaction and ancestor score bug

This pull request was mentioned in the thread: "Proposal: Package Mempool Accept and Package RBF" however I am not sure if everyone would have read all the emails if they were not interested in packages. Also not possible to keep track of each pull request in Bitcoin Core repository. PR: https:

Re: [bitcoin-dev] Mock introducing vulnerability in important Bitcoin projects

n. For this reason, it > would be appropriate to check first whether your plan is actually appreciated. > > Speaking on behalf of the bitcoin-dev moderators, please ensure your plan is > welcomed by the contributors, prior to proceeding. > > Best regards, > Ruben Somsen &

Re: [bitcoin-dev] Mock introducing vulnerability in important Bitcoin projects

Hi ZmnSCPxj, Thanks for suggestion about sha256sum. I will share 10 in next few weeks. This exercise will be done for below projects: 1.Two Bitcoin full node implementations (one will be Core) 2.One Lightning implementation 3.Bisq 4.Two Bitcoin libraries 5.Two Bitcoin wallets 6.On

[bitcoin-dev] Mock introducing vulnerability in important Bitcoin projects

Good morning Bitcoin devs, In one of the answers on Bitcoin Stackexchange it was mentioned that some companies may hire you to introduce backdoors in Bitcoin Core: https://bitcoin.stackexchange.com/a/108016/ While this looked crazy when I first read it, I think preparing for such things should

Re: [bitcoin-dev] Reminder on the Purpose of BIPs

> I like the idea of decentralizing the BIPs process. It is a historical > artifact that the bips repository is part of the same organization that > bitcoin core is part of. But there shouldn't be the perception that > standardization is driven by that, or that there is any kind of (non-trivial)

Re: [bitcoin-dev] BIP process meeting - Tuesday September 14th 23:00 UTC on #bitcoin-dev Libera IRC

> A mailing list post is static and a BIP will go normally go through multiple > edits and revisions so you do need to take advantage of the Git version > control system. It gets quite unwieldy to attempt to do that via a mailing > list with every minor suggested edit getting sent to all subscri

Re: [bitcoin-dev] BIP process meeting - Tuesday September 14th 23:00 UTC on #bitcoin-dev Libera IRC

Hi Michael, Thanks for sharing the details about the meeting. Wishlist has some interesting points. I would like to suggest few things: 1.BIP process: A. Plan and document a proposal B. Open PR in https://github.com/bitcoin/bips and edit everything properly C. BIP is assigned a number and

Re: [bitcoin-dev] Braidpool: Proposal for a decentralised mining pool

> How would you compare this to Stratum v2? Stratum v2 will help miners with encryption, broadcasting new blocks, signalling bits, choose transactions set, however the mining pools can still reject negotiations and censor payments. Maybe Stratum v2 can be used in combination with other things l

Re: [bitcoin-dev] Drivechain: BIP 300 and 301

> of course stacks can do this even without drivechain, so not sure whatwe're > hiding from there Stacks is not a Bitcoin sidechain IMO. It has its own native token which isn't pegged to BTC. Premined.  It uses Bitcoin as a storage and broadcast medium for recording all blocks. Marketing with l

Re: [bitcoin-dev] Drivechain: BIP 300 and 301

Good morning ZmnSCPxj, Thanks for sharing all the details. One thing that I am not sure about: > * We already ***know*** that blockchains cannot scale > * Your plan for scaling is to make ***more*** blockchains? Scaling Bitcoin can be different from scaling Bitcoin sidechains. You can experimen

[bitcoin-dev] Drivechain: BIP 300 and 301

printf("Hello, World!"); What are your thoughts on Drivechain and associated BIPs? This article compares Liquid and Lightning:  https://blog.liquid.net/six-differences-between-liquid-and-lightning/. Two things from it that I am interested in while evaluating Drivechain: 1.Trust model 2.On-Ramps

[bitcoin-dev] Using transaction version number in different projects

print('Hello, world!') I had asked related question on Bitcoin Stackexchange:  https://bitcoin.stackexchange.com/questions/108248/version-in-transaction Wanted to know if others think we should allow more numbers in transaction version by considering such transaction standard. I have shared an e

Re: [bitcoin-dev] Camouflage: A project dedicated to Hal Finney

oth while using a browser. -- Prayank A3B1 E430 2298 178F Aug 28, 2021, 22:06 by ayme...@peersm.com: > > Probably you could add to your links this discussion/issue > > https://github.com/bitcoin/bitcoin/pull/18988#issuecomment-646564853 > > > Le 27/08/2021 à 23:29, Prayank

[bitcoin-dev] Camouflage: A project dedicated to Hal Finney

I wish Hal Finney was with us today and help us improve privacy in Bitcoin. I like reading his posts and one of them is https://bitcointalk.org/index.php?topic=156390.msg1659654#msg1659654 I had emailed about Privacy related things on July 23: https://lists.linuxfoundation.org/pipermail/bitcoi

Re: [bitcoin-dev] Announcing bip174.org, a web-based PSBT viewer and editor

Hi Alekos, > bip174.org, a PSBT viewer and editor that runs in the browser The PSBT editor looks good and will be helpful. Thanks for working on it. Would love to see an option to switch between light and dark theme and highlighting few things with different colors. Maybe a similar project for

[bitcoin-dev] bitcoin-ps | Desktop application to test Bitcoin Core using PowerShell scripts

Hello World, I was working on an intern project in last few weeks which is almost ready for first release. Will be helpful if devs working on Bitcoin Core and .NET projects related to Bitcoin can share feedback. Pieter Wuille and Luke Dashjr had already shared few things before I started workin

Re: [bitcoin-dev] Removing the Dust Limit

> As feerates have gone up over time, and as we expect them to go up further, >we should be considering drastically increasing the 3 sat/vByte basis to >something more like 20 sat/vB. I have no opinion on changing or removing dust limit. However, fee rates are not going up. Yes, we expect them

[bitcoin-dev] Bitcoin Privacy Week/Month

Hello World, What? I would love if Bitcoin developers would celebrate a 'Bitcoin Privacy week or month' once in an year. Not sure about the dates. Enthusiasm can be similar to Valentines week or Secret Santa week but Seriousness should be like Wikileaks or Human Rights Foundation. Why? I am

Re: [bitcoin-dev] Trinary Version Signaling for softfork

> I’ve seen no actual demonstration of the relevance of game theory to Bitcoin. >People throw the words around quite a bit, but I can’t give you an answer >because I have found no evidence of a valid game theoretic model applicable to >Bitcoin. It’s not a game, it’s a market. Agree its difficul

Re: [bitcoin-dev] Trinary Version Signaling for softfork

Hello Eric, I have few questions: > Without majority hash power support, activation simply means you are off on a >chain split. So majority hash power not following the consensus rules can result in chain split? Why would majority of miners decide to mine a chain that nobody wants to use? Wha

[bitcoin-dev] Wallet fingerprinting and other privacy issues in Bitcoin Core

Hello World, There are other privacy issues in Core (node and wallet) but recently I came across one which can be used to identify if someone is using Bitcoin Core with just the bitcoin address and couple of transactions. I think people have already given up and don't expect privacy in Core wal

Re: [bitcoin-dev] Fee estimates and RBF

I have shared response by Jeremy and ZmnSCPxj in an answer to  https://bitcoin.stackexchange.com/questions/105860/what-are-we-trying-to-predict-in-fee-estimation-and-why Also find the recent CVE related to RBF by Antoine Riard and implementation of RBF in Bitcoin Core compared to btcd interesting

Re: [bitcoin-dev] Prediction Markets and Bitcoin

Good morning ZmnSCPxj, This will be a long email because I want to cover all the things and difficult to express them in few sentences or respond to the tweets about use of futures markets in Bitcoin. TL;DR: Prediction markets or futures markets can be helpful in collecting more information an

Re: [bitcoin-dev] Opinion on proof of stake in future

My opinion: 1.I don't consider PoS to be a better consensus mechanism compared to PoW used in Bitcoin. So any proposal related to PoS in Bitcoin is not an improvement for me.   2.Bitcoin is a protocol for decentralized network that creates consensus without needing a central authority to provid

Re: [bitcoin-dev] Fee estimates and RBF

Good morning ZmnSCPxj, Thanks for your response. I agree there are few exceptions:  1.Unconfirmed output can be spent resulting in conflict with RBF 2.Race condition and mining pool may include old transaction with low fee I am trying few things related to RBF and handling such exceptions, will s

Re: [bitcoin-dev] Fee estimates and RBF

> Jeremy > -- > @JeremyRubin <https://twitter.com/JeremyRubin> > <https://twitter.com/JeremyRubin> > > > On Fri, Apr 30, 2021 at 2:40 PM Prayank via bitcoin-dev <> > bitcoin-dev@lists.linuxfoundation.org> > wrote: > >> Hello World, >> &

[bitcoin-dev] Fee estimates and RBF

Hello World, I hope everyone is doing okay. Things are not good in India and even I was tested covid positive few days back. Recovered and feeling better now. Hoping everything gets back to normal soon. There are different estimations used in wallets, explorers and other Bitcoin projects. For

Re: [bitcoin-dev] Block weight penalty for UTXO set growth

Hello Yanmaani, Incentives for UTXO consolidation already exists IMO. 1.If UTXO consolidation is done when fee rates are low (less congestion in mempool), it helps in saving money in lot of cases. Example:  https://bitcoin.stackexchange.com/a/100811/ 2.If running full node for Bitcoin, it will h

Re: [bitcoin-dev] BIPs - notarization protocol and decentralized storage

Hello Christopher, Decentralized storage as an idea looks interesting. I am researching about similar things for one of my Bitcoin project. Although an implementation or proof of concept code in the BIP would have been better. Also since this involves LN, maybe it can just be a LN project inste

[bitcoin-dev] Prediction Markets and Bitcoin

Positives: You need money to participate even though your position size may not matter if really small based on liquidity and volume. Useful information if looking at overall sentiments especially traders Noise filter because its not same as trolling on social media Opportunity for some people to

Re: [bitcoin-dev] Taproot activation meeting on IRC - Tuesday 16th March 19:00 UTC

> back in the day we also had people that thought 10 min avg block time is too > much. Not sure what some people thought about block time interval has to do with me. Also these are the things written by Greg Maxwell and Chris Belcher about it that I agree with and been sharing from sometime now

Re: [bitcoin-dev] Taproot activation meeting on IRC - Tuesday 16th March 19:00 UTC

> the last thing we need is a rushed upgrade Why do you think this is rushed? Speedy Trial will have few months and if UASF is required it won't involve activation immediately after ST fails. Taproot by 2022 doesn't look rushed approach IMO. > We're not changing things that we worked out alread

[bitcoin-dev] Mining Pools in Bitcoin and their involvement in Bitcoin development

Hello World, Lets start with facts instead of opinion. Mining pool distribution in last 24 hours: Binance - 16% F2Pool - 15% Huobi - 11% AntPool - 10% ViaBTC - 10% Poolin - 9% BTC.com - 8% This is 80% and things are not really different even if look at last 2 weeks. Most of the pools have been

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

Hello Everyone, The below comment by Matt about different implementations and their opinion on `lockinontimeout` is from 18 Feb 2021 communication:  https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018433.html > If the eventual outcome is that different implementations (that

[bitcoin-dev] BIP - Automated and Secure Communication

Hello Everyone, I know there have been lot of controversial and heated discussions involving Samourai in past. Ignoring everything including the tweets in which Samourai team mentioned no interest in proposing a BIP related to automated and secure communication used in Soroban, I wanted to know

[bitcoin-dev] bips.txt format for all Bitcoin projects

Hello Everyone, What? Can we request all Bitcoin projects to create a file 'bips.txt' with a format that describes all the BIPs used in the project? How? The file can be uploaded to the root of website used for the project. For example: BTCPay can have this file at:  https://btcpayserver.org/

Re: [bitcoin-dev] Post-mix(coinjoin) usage with multisig and cpfp in bitcoin core wallet

Hello ZmnSCPxj, Thanks for your response. The spending tx of multisig can be decided earlier and all three can review the outputs involved in it. All 3 txs involved in the system if we consider only one mixer and not a chain will get confirmed in the same block as we are using CPFP so child p

Re: [bitcoin-dev] Post-mix(coinjoin) usage with multisig and cpfp in bitcoin core wallet

Hello ZmnSCPxj, Thanks for the feedback. 1. Peer 1 doesn't need to be a trusted third party, it can be implemented in a way that some peers involved in this system can provide liquidity for others and incentives can be a small fee. 2. Yes joinmarket is awesome and its payjoin will be better

[bitcoin-dev] Post-mix(coinjoin) usage with multisig and cpfp in bitcoin core wallet

I have explained the whole idea with a proof of concept in this link:  https://medium.com/@prayankgahlot/post-mix-usage-using-multisig-and-cpfp-e6ce1fdd57a1 Does it make sense to add such options in bitcoin core wallet and how is the overall idea once we have taproot because for now people can ch