Hi Bitcoin Developers,
Since some emails get moderated, I wanted to share one python script that I
found useful.
Download eml file from moderated archives:
https://lists.ozlabs.org/pipermail/bitcoin-dev-moderation/
Install fast_mail_parser and use this python script:
Hi Bitcoin Developers,
### Problem
Wallet fingerprinting: Identifying the bitcoin wallet used to create the
transaction
### Previous research
A) 0xB10C wrote a [blog post][0] in 2020 about wallet fingerprinting.
Most transactions followed the fee rate recommendations provided by
Hi Peter,
> At that point, why are we bothering with numbers at all? If BIP #'s aren't
memorable, what is their purpose? Why not just let people publish ideas on
their own web pages and figure out what we're going to call those ideas on a
case-by-case basis.
I agree people can maintain BIPs in
Hi Erik,
> currently, there are providers of anonymity services, scaling services,
> custody, and other services layered on top of bitcoin using trust-based and
> federated models.
>
> as bitcoin becomes more popular, these service providers have increasingly
> had a louder "voice" in
Hi Ethan,
> [2]: P. Wuille, "Multisig on steroids using tree signatures", 2015,
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019233.html
Correct link for "Multisig on steroids using tree signatures":
https://blog.blockstream.com/en-treesignatures/
/dev/fd0
floppy disk
Hi Luke,
> Maybe we need a 3rd BIP editor. Both Kalle and myself haven't had time
> to keep up. There are several PRs far more important than Ordinals
> nonsense that need to be triaged and probably merged.
I don't think adding another editor solves the problem discussed in this
thread.
Last
Hi Dan,
May be too late to reply. Sorry.
Based on our last communication, I wanted to share these points after reading
https://payjoin.substack.com/p/serverless-payjoin-gets-its-wings so that other
can also evaluate them:
1) I don't think NIP 4 has any security issues. Maybe privacy issues.
Hi Bitcoin Developers,
Note: This email is inspired from
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018538.html
written by Chris Belcher
Lets compare all covenant proposals:
https://docs.google.com/spreadsheets/d/1YL5ttNb6-SHS6-C8-1tHwao1_19zNQ-31YWPAHDZgfo/edit#gid=0
Hi TheBlueMatt,
>> There are at least three or four separate covenants designs that have
>>> been posted to this list, and I don't see why we're even remotely
>>> talking about a specific one as something to move forward with at
>>> this point.
>>
>>> To my knowledge none of these other proposals
@DavidHarding
Interesting proposal to revert consensus changes. Is it possible to do this for
soft forks that are already activated?
Example: Some users are not okay with witness discount in segwit transactions
https://nitter.net/giacomozucco/status/1513614380121927682
@LukeDashjr
> The
> There are a number of individuals who have stated opposition to attempting to
> activate a CTV soft fork in the near term:
>
> https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718
sheshek found some issues with the list and some of them are not really an
opposition for CTV.
Hi Peter and Zac,
> I like the maxim of Peter Todd: any change of Bitcoin must benefit all
> users. This means that every change must have well-defined and transparent
> benefits. Personally I believe that the only additions to the protocol that
> would still be acceptable are those that clearly
Hi Michael,
> Doesn't sound to me that this was being "offered up for discussion". A week
> from April 17th would have been Sunday April 24th (2 days ago). Readers of
> this mailing list would have had no idea of these plans.
I'm quoting 5 points from the blog post and putting some words in
Hi ZmnSCPxj,
> TLDR: MEV = Miner-extractable value, basically if your contracts are complex
> enough, miners can analyze which of the possible contract executions are most
> profitable for them, and order transactions on the block they are building in
> such a way that it is the most
Hi Bitcoin Developers,
Summary for the last CTV meeting:
Topics:
1)OP_TX
2)OP_CAT / CSFS / General Covenants
3)Script interpreter flags
===
OP_TX
===
Jeremy Rubin thinks that if folks believe OP_TX
ot; which would simply require that the specified block
> must contain the suffix "taproot sucks!".
>
> Anyway, I'm sure there are lots of design choices available better than a
> MUST_SIGNAL state that does not risk potentially taking a large fraction of
> mining hard
Hi Peter,
> Point is, the attacker is thousands of UTXOs can also DoS rounds by simply
> failing to complete the round. In fact, the double-spend DoS attack requires
> more resources, because for a double-spend to be succesful, BTC has to be
> spent
> on fees.
>
> It's just a fact of life that a
Hi ZmnSCPxj,
> Thus, we should instead prepare for a future where the block subsidy must be
> removed, possibly before the existing schedule removes it, in case a majority
> coalition of miner ever decides to censor particular transactions without
> community consensus.
> Fortunately forcing
---
On Sunday, July 10th, 2022 at 2:17 PM, alicexbt via bitcoin-dev
wrote:
> Hi ZmnSCPxj,
>
> > Thus, we should instead prepare for a future where the block subsidy must
> > be removed, possibly before the existing schedule removes it, in case a
> > majority
t/blockchainbib/pdf/tran2020stealthier.pdf
>
> On 9 Jun 2022, at 20:24, alicexbt via bitcoin-dev wrote:
>
> > Hi Bitcoin Developers,
> >
> > Based on this answer from 2014, bitcoin nodes are vulnerable to BGP
> > hijacking. There was an incident in March 2022, twitter pre
l be punished and how does
this affect the attacker with thousands of UTXOs or normal users?
/dev/fd0
Sent with Proton Mail secure email.
--- Original Message ---
On Monday, June 27th, 2022 at 12:43 AM, Peter Todd wrote:
> On Sun, Jun 26, 2022 at 04:40:24PM +0000, alicexbt via bit
Hi Bitcoin Developers,
Based on this [answer][1] from 2014, bitcoin nodes are vulnerable to BGP
hijacking. There was an incident in March 2022, twitter prefix was hijacked and
details are shared in 2 blog posts:
https://isc.sans.edu/diary/rss/28488
> "fact checkers".
> Please, rise the bar.
> On Fri, Jun 3, 2022, 19:44 alicexbt via bitcoin-dev
> wrote:
>
> > Note: This email is an opinion and not an attack on bitcoin
> >
> > Covenants on bitcoin will eventually be implemented with a soft fork. CTV
> &
Hi John,
> Core development is not a hackathon project.
>
> None of the quoted following items are features or responsibilities of the
> Bitcoin software, nor Core developers
Core development was never listed as a hackathon project. Although I did not
share responsibilities, they will improve
Hi Antoine,
Thanks for opening the pull request to add support for full-rbf in Bitcoin
Core. I have a few disagreements with the approach and questions.
> Recent discussions among LN devs have brought back on the surface concerns
> about the security of multi-party funded transactions
asic RBF policy options rather than attempting to
>> define what constitutes a good policy and removing the ability to disable
>> something when necessary.
>
> If Knots has these knobs, just use Knots rather than lobby all
> implementations to have miner incentive incomp
Hi cndm1,
> If you see a "lack of basic options" and no one has opened a pull request for
> it, it may be for two reasons.
The basic option to disable all RBF policies in a node's mempool if required
was removed in [PR #16171][1]. No one has opened a pull request to revert this
because most
Hi Antoine,
> One could list the operating system on which is running your Lightning
> process or the compiler toolchain turning outyour Lightning source code in a
> binary artifact. Some weird kernel's memory mapping change could allow access
> toyour channel funding keys, _without_ breaking
Hi Peter,
> Only because the block reward goes away. If it was made to continue
> indefinitely - most likely with an inflation hard fork - demand for block
> space
> would not be critical to Bitcoin's security.
I am not completely against your proposal although 100% sure this will not have
Hi Bitcoin Developers,
Bitcoin knots has a config option to disallow address reuse in mempool:
spkreuse=conflict or GUI -> Settings -> Options -> Mempool. I tried
experimenting with it and running 2 nodes(signet) for which anyone can check
'getrawmempool' at a given time using:
GET
Note: This email is an opinion and not an attack on bitcoin
Covenants on bitcoin will eventually be implemented with a soft fork. CTV is
the easiest and best possible way OP_TX looks good as well. Apart from the
technical merits, covenants will improve a few other things:
- Developers can
Hi woltx,
Thanks for implementing silent payments in Bitcoin Core. I tried the steps
shared in tutorial and everything works as expected.
I have updated the silent payment address (signet) as TXT record for domain
alice.silentbitco.in
$ dig -t txt alice.silentbitco.in +short
Hi Aaradhya,
> As it's not a consensus rule, I think it can be done easily, just needing
> support from full node operators
A few miners will need to use a lower minrelaytxfee for this to work. I don't
think miners would want to lower their profits.
/dev/fd0
Sent with [Proton
Hi bitcoin-dev list members,
STONEWALLx2[1] is a p2p coinjoin transaction in Samourai wallet. The miner fee
is split between both participants of the transaction.
==
Problem
==
Antoine Riard shared the details of DoS attack in an [email][2] on
people or weight for a flight would still remain the same.
/dev/fd0
Sent with Proton Mail secure email.
--- Original Message ---
On Tuesday, July 26th, 2022 at 7:57 PM, Peter Todd wrote:
>
> On July 26, 2022 2:19:32 PM GMT+02:00, alicexbt via bitcoin-dev
&
Sent with Proton Mail secure email.
--- Original Message ---
On Tuesday, July 19th, 2022 at 10:14 AM, Anthony Towns via bitcoin-dev
wrote:
> On Fri, Jun 03, 2022 at 06:39:34PM +, alicexbt via bitcoin-dev wrote:
>
> > Covenants on bitcoin will eventually be im
Hi Antoine,
Thanks for sharing the DoS attack example with alternatives.
> - Caroll broadcasts a double-spend of her own input C, the double-spend is
> attached with a low-fee (1sat/vb) and it does _not_ signal opt-in RBF
> - Alice broadcasts the multi-party transaction, it is rejected by the
Hi Michael,
> Maybe the whole thing worked as designed. Some users identified what was
> going on, well known Bitcoin educators such as Andreas Antonopoulos, Jimmy
> Song etc brought additional attention to the dangers, a URSF movement started
> to gain momentum and those attempting a
Hi Bitcoin Developers,
Summary for the last CTV meeting:
Topics:
1)APO version of the simple vault
2)APO as alternative to CTV
3)fiatjaf's CTV spacechain demo
4)Compare CTV with other covenant proposals
5)Recursive covenants
6)Responding to FUD
CTV and other covenant proposals, tradeoffs, and overlapping features are among
the topics being explored recently. I had some views and questions on this
subject.:
a) Does bitcoin already have opcodes with overlapping features? Yes
b) Can we have multiple ways with some overlapping features
Hi Bitcoin Developers,
There were some disagreements with speedy trial activation method recently and
BIP 8 became controversial because of LOT earlier. I have tried to solve these
two problems after reading some arguments for/against different activation
methods by removing LOT from BIP 8 and
ced thing as part of the (very orthogonal) soft
> > fork implementation.
> > On Tue, May 10, 2022 at 9:02 AM alicexbt via bitcoin-dev
> > bitcoin-dev@lists.linuxfoundation.org wrote:
>
> > Hi Bitcoin Developers,
> >
> > There were some disagreements with s
Hi vjudeu,
> It can be changed by using different sighashes, for example, it is possible
> to create a "negative fee transaction", where all transaction costs are paid
> by receiver. Using SIGHASH_SINGLE | SIGHASH_ANYONECANPAY with a higher amount
> in outputs than inputs is enough to do that,
Hi Aaradhya,
> I discussed this on the Bitcoin subreddit and some suggested that the
> developers, in the future, have to just change the "default minimum relay tx
> fee" from 1000 today to 500 at that time.
>
There are several issues and pull requests (open and closed) in which
developers
Hi Bitcoin Developers,
I have written a python script as proof of concept for the [coinjoin
implementation][1] using [nostr][2]. I used a lot of Python scripts created by
others in school, so it feels nice to offer something that could be useful to
others.
The implementation uses Bitcoin Core
without attribution or
> defense.
>
> Skol
> Max
>
>
> On August 20, 2022 10:20:00 AM GMT+02:00, alicexbt via bitcoin-dev
> wrote:
>
> > Hi Bitcoin Developers,
> >
> > I have written a python script as proof of concept for the [coinjoin
&
Hi Eric,
> If by "range" you mean a connected tx subgraph, I don't see why not. But note
> that nodes only operate over signed txs. PSBT is a wallet workflow.
Matt Corallo mentioned that pre-signed transactions created with low fee rate
become an issue when they are broadcasted after a long
Hi Michael,
> We then get into the situation where the block signers (currently AJ and
> Kalle) are the gatekeepers on what soft fork proposals are added.
Things that could solve the gatekeeping issue:
1) Adding more maintainers that are experienced enough to review consensus
code.
2) Every
Hi aj,
> I mean, I guess I can understand wanting to reduce that responsibility
> for maintainers of the github repo, even if for no other reason than to
> avoid frivolous lawsuits, but where do you expect people to find better
> advice about what things are a good/bad idea if core devs as a
Hi Dave,
> One way to address this risk is by turning it into a certainty. If the
price of BTC increases between when the invoice is generated and when a
transaction is included in a block, give the customer a future purchase
credit equal in value to the difference between the price they paid
Hi woltx,
Thanks for the response.
> Using all inputs, it becomes possible to use SP addresses in coinjoins as
> long as all participants agree.
> More information:
> https://gist.github.com/RubenSomsen/c43b79517e7cb701ebf77eec6dbb46b8#variant-using-all-inputs
Using new addresses and SP
ut(input: dict[str, int, str, str]) -> bool:
>
> # ...
> result = core.verifymessage(address=input['address'],
> message=json.dumps(message), signature=input['signature'])
> return result['error'] == None and result['result'] == True
>
>
>
>
>
> --- Origin
This has been assigned CVE-2022-35913:
https://www.cve.org/CVERecord?id=CVE-2022-35913
/dev/fd0
Sent with Proton Mail secure email.
--- Original Message ---
On Thursday, July 14th, 2022 at 9:25 AM, alicexbt via bitcoin-dev
wrote:
> Hi bitcoin-dev list members,
>
>
> S
Hi Michael,
> I agree with Matt. The less said about the "Aw shucks Jeremy didn't know that
> CTV didn't have community consensus at the time" [0] and "it was the lack of
> process that was the problem" the better.
The linked gist cannot be taken seriously and I am not sure why you keep
Hi Eric,
This email wasn't answered by anyone on mailing list however I did some
research about packages yesterday including this email and below are my
observations, questions etc.
> The sole objective, as expressed in the OP proposal, is to:
>
> "Propagate transactions that are
Hi Bitcoin Developers,
I did some research about nLocktime and nVersion used by some open source
Bitcoin wallets. I have written a [blog post][0] co-authored with 'nothingmuch'
and this is the first post for the privacy focused blog 'consent':
Most wallets use nVersion 2. nLocktime for Bitcoin
Hi woltx,
Thanks for working on silent payments improving it in each version.
1) All inputs being used sounds good although I do not understand how it would
benefit coinjoin.
2) New RPC command name is better.
> I opened a new PR (#1143) to add a function to convert from x-only to
>
Hi Dario,
There aren't any risks with latest release of bitcoin core. However its not
just munn or other things mentioned, even other bitcoin projects could be
affected if [#25600][1] is merged.
Anyway I cannot comment anymore, neither in the PR or repository. I tried my
best. Peter Todd has
Hi cndm1,
> Bitrefill already supports lightning, so for them it would be easy to
> solve by displaying the lightning transfer by default and only show
> the on-chain payment as a fallback. Currently the on-chain payment at
> Bitrefill and other similar providers is really a drop-down where you
>
Hi Bitcoin Developers,
Does it make sense to trade replacement transactions for privacy? I have shared
basic details to implement this and would love to read opinions about it or
ways to improve it:
=
alice
=
tx1: input a (0.01) ->
> something.
>
> Thanks
> Michael
>
> [0]: https://bitcoinops.org/en/topics/coinswap/
>
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>
>
> --- Original Message
Hi Ali,
> It would probably only work out if each output got their own private keys,
> since otherwise Alice can't share any outputs with Bob and vice versa.
> The whole thing sounds like an HTLC with an additional trading of private
> keys for the actual trades instead of in the HLTC. How are
nmail.com
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>
> --- Original Message -------
> On Monday, December 19th, 2022 at 23:58, alicexbt via bitcoin-dev
> bitcoin-dev@lists.linuxfoundation.org wrote:
>
> > Hi Bitc
Hi Peter,
> ## How Full-RBF Mitigates the Double-Spend DoS Attack
>
> Modulo tx-pinning, full-rbf mitigates the double-spend DoS attack in a very
> straightforward way: the low fee transaction is replaced by the higher fee
> transaction, resulting in the latter getting mined in a reasonable
Hi Peter,
> Bringing up Whirlpool here is silly. Everyone knows Samourai has made, at
> best,
> some rather insane technical decisions. Quite likely downright malicious with
> their xpub collection. Their opinion isn't relevant. Cite reputable sources.
I didn't want this thread to become a
Hi Bitcoin Developers,
List of present bitcoin core maintainers:
| Username|Focus Area |
| - | - |
| MarcoFalke | General, QA |
| fanquake | General, Build |
| hebasto | General, UI/UX |
| achow101 | General, Wallet |
| glozow
Hi Bitcoin Developers,
Problem: In p2p exchanges that use 2of3 multisig (example: hodlhodl[0]), there
is a possibility of buyer and seller settling the trade without involving
exchange. Lets consider Alice (buyer), Bob (seller) and Carol (exchange). Once
bitcoin is locked in multisig, Alice
Hi Bitcoin Developers,
I have setup a [custom signet][0] for testing full RBF. You can connect to one
or more of these nodes using `addnode`:
13.115.34.55 (issuer, full-rbf)
kfupbqwb2yvzzqjomfq5pkem553a6uzp2k73seqn4d46smy7azua.b32.i2p (rbf-optin)
Hi Bitcoin Developers,
> Looking forward to the first session, listening to everyone's thoughts about
> what could be the scope discussed by this new community process: anyprevout,
> recursive covenants, introspection, new malleability flags, ZK rollups, new
> contracting protocols and many
-on-how-to-set-up-a-cust
> 1:
> https://bitcoin.stackexchange.com/questions/114724/peer-discovery-on-a-custom-signet-custom-signetchallenge
> 2: 0: https://en.bitcoin.it/wiki/Signet#Custom_Signet
>
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
>
Hi Bitcoin Developers,
> Anyone who runs an unpruned bitcoin node should be capacity-planning their
> disk space assuming that in the future blocks will be more full - as demand
> for blockspace increases, people will make better use of the space that we
> already have and average block weight
Hi Michael,
If I were to fork bitcoin core and maintain an implementation, I wouldn't
integrate any lightning implementation with it. Instead remove some things from
bitcoin core and keep it simple. There is also scope for improving privacy.
Example:
Hi Peter,
> tl;dr: I'm broadcasting full-RBF replacements paying extremely high fees to
> reward miners that turn on full-RBF. I'm starting small, just ~$100/block in
> times of congestion. Miner and pool profit margins are pretty small, on the
> order of $1k/block in many cases, so I know it
URN means that
> all nodes will store such data. Using witness means that only witness nodes
> will keep that. So, if it is already possible to have a node that cannot see
> witness data, and still remain in the network, I think commitments should be
> stored only by nodes
Hi Bitcoin Developers,
I have written a BIP that describes the process to swap inscriptions however
there can be other use cases for it as well:
https://gist.github.com/144bytes/a7deeb3f1740bc533a61fbcc1fe58d77
Feel free to share your opinion or feedback to improve the usage of PSBTs in
Hi Michael,
I was initially sad about the politics in Vasil's pull request, written about
it and also tried to document the process. Still think he deserves to be a
maintainer. Although I have some counter arguments:
> Maintainers merge a pull request and provide no commentary on why they’ve
Hi Michael,
I will share something even though you didn't let me write things on several
occasions on github, twitter etc.
Try this:
- As Gloria said (respect people you don't like and shared something against),
create a competition for Brink. Fund bitcoin developers.
- Do more reviews
Hi Zac,
Let me share what those parasites achieved:
- Fees paid: 150 BTC
- Lot of users and developers trying bitcoin that either never tried or gave up
early in 2013-15
- Mempools of nodes of being busy on weekends and got lots of transactions
- PSBT became cool and application devs are trying
Hi Zac,
> Regarding “Fees paid: 150 BTC” (uh, *citation needed*):
https://dune.com/queries/2008613/3326984
> Your other arguments are nonsensical so excuse me for ignoring them.
There were zero browser extensions that could sign PSBT to be used in different
bitcoin projects that have web
Hi Steve and Bitcoin Developers,
I have created a new thread as requested by one of the developers. I respect
him and the readers of this list.
> "want bitcoin to be money and money means different things for people in
this world"
> I think we can all agree that a property of money is
Hi Bitcoin Developers,
There is a famous quote attributed to Evelyn Beatrice Hall in her biography of
Voltaire: "I disapprove of what you say, but I will defend to the death your
right to say it." I'm curious to know how many Bitcoin developers share this
sentiment.
Recently there was a lot
Hi Anthony,
> I think, however, that you can move inscriptions entirely off-chain. I
wrote a little on this idea on twitter already [1], but after a bit more
thought, I think pushing things even further off-chain would be plausible.
Whole point of inscriptions is to keep something on-chain
Hi Anthony,
> As far as salience/notability goes, personally, I'd see ownership of
inscriptions as a negative indicator; "hey, when I was young and foolish I
wasted x-thousand bytes on the bitcoin blockchain, pointlessly creating a
permanent cost for everyone trying to use bitcoin in future".
Hi Symphonic,
> I'm a bit confused as to what exactly this is a proof of concept for.
This is a proof of concept for using nostr npub and relays for payjoin.
> Your use of SIGHASH_NONE does in fact make it possible for the reciever to do
> whatever they want with your funds (which I see you
Hi Bitcoin Developers,
I think its possible to use [package relay][0] for DoS attack in coinjoin. A
few other projects could also be affected by packages. Since its a proposal
that adds new P2P messages, transaction relay etc. its as important as any soft
fork. Let me know if I am missing
the issue faster through
> > > wider collaboration versus keeping knowledge of the issue within a
> > > smaller group.
> > >
> > > Thanks
> > > Michael
> > >
> > > [0]: https://github.com/bitcoin/bitcoin/blob/master/SECURITY.md
> > > [1
Hi Bitcoin Developers,
I recently experimented with different sighash flags, PSBTs and realized
ALL|ANYONECANPAY could be used to reduce some steps in coinjoin.
Steps:
- Register outputs.
- One user creates a signed PSBT with 1 input, all registered outputs and
ALL|ANYONECANPAY sighash flag.
ient/VortexClient.scala#L616
>
>
> Best,
>
> benthecarman
>
>
>
> From: bitcoin-dev on behalf
> of alicexbt via bitcoin-dev
> Sent: Monday, May 22, 2023 7:51 AM
> To: Bitcoin Protocol Discussion
> Subject: [bitcoin-dev] Coinjoin with less steps using ALL|ANYON
An input from a sanctioned address is added, causing you
> > to get "tainted" coins.
> >
> >
> > This is the code in ln-vortex that verifies the psbt on the client side if
> > you are curious
> >
> > https://github.com/ln-vortex/ln-vortex/b
Hi Joost,
Transaction relay over nostr sounds interesting. I have 2 suggestions:
- Transactions could be encrypted when published as nostr events initially
except size, fee rate and offer. This can be used by different clients to show
them as external mempool with transactions sorted by fee
t going to result in loss of
> > > > > onchain funds and doesn't seem to present a systemic issue (e.g.
> > > > > network DoS attack, inflation bug) I'm of the view that opening a
> > > > > public issue was appropriate in this case especially as the issue
Hello Bitcoin Developers,
Since I learnt about payjoin(p2ep), there was always discussion of it not being
adopted because of need for sever. This proposal needs no personal sever
however I am doubtful it still gets any adoption.
Note: Even stowaway (used by samourai) uses servers in fact two:
Hi Maxim,
> In this regard, I’d like to propose the following:
>
> 1. The bitcoin-dev mail list must have a clear moderation (or
> pre-publication peer-review policy). It can be proposed and discussed in this
> mail list and, upon agreement, must become public and obligatory.
> 2. Bryan
ww.youtube.com/@portofbitcoin
>
> --- Original Message ---
> On Tuesday, May 9th, 2023 at 03:47, alicexbt via bitcoin-dev
> wrote:
>
>> Hi Bitcoin Developers,
>>
>> There is an open issue in bitcoin core repository which was created last
>> week: h
Hi Andrew,
> We can take a look at how previous maintainers were added to see how this has
> played out in the past.
Can we learn something from past?
Bitcoin's initial release was in 2009 with one developer and few others
experimenting with it. It is considered decentralized in 2023 however
Hi Bitcoin Developers,
There is an open issue in bitcoin core repository which was created last week:
https://github.com/bitcoin/bitcoin/issues/27586
I think this should have been reported privately as vulnerability instead of
creating a GitHub issue even if it worked only in debug mode. Some
Hi ArmchairCryptologist,
Bitcoin is working as expected and I don't see any 'manipulation' attacks in
the bidding for block space. Maybe we aren't used to such demand for blockspace
on bitcoin. Additionally, fingerprinting based on fee rates and timing to
attribute transactions to a single
SF" making blocks
> signalling for it invalid.
>
> Luke
>
>
> On 12/19/23 20:44, alicexbt via bitcoin-dev wrote:
>
> > Hello World,
> >
> > Note: This is not an attack on bitcoin. This is an email with some text and
> > links. Users can decide what
towards people supporting CTV including me. Maybe one day we will have
covenants on bitcoin to improve scaling and privacy.
/dev/fd0
floppy disk guy
Sent with Proton Mail secure email.
On Friday, December 22nd, 2023 at 1:56 AM, alicexbt via bitcoin-dev
wrote:
> Hi Luke,
>
> This is not
Hello World,
Note: This is not an attack on bitcoin. This is an email with some text and
links. Users can decide what works best for themselves. There is also scope for
discussion about changing method or params.
I want to keep it short and no energy left. I have explored different options
1 - 100 of 103 matches
Mail list logo
