Re: [bitcoin-dev] Block size following technological growth

On Fri, Jul 31, 2015 at 7:15 AM, Mike Hearn via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: He is not saying that. Whatever the reasons for centralization are, it is obvious that increasing the size won't help. It's not obvious. Quite possibly bigger blocks == more users ==

Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn'ttemporary

On Thu, Jul 30, 2015 at 10:55 AM, Gavin Andresen gavinandre...@gmail.com wrote: On Thu, Jul 30, 2015 at 11:24 AM, Bryan Bishop via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: Because any decentralized system is going to have high transaction costs and scarcity anyway

Re: [bitcoin-dev] Fees and the block-finding process

On Fri, Aug 7, 2015 at 1:17 PM, jl2012 via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: No, I'm not trolling. I really want someone to tell me why we should/shouldn't reduce the block size. Are we going to have more or less full nodes if we reduce the block size? Some arguments

Re: [bitcoin-dev] summarising security assumptions (re cost metrics)

On Sun, Nov 8, 2015 at 8:54 AM, Gavin Andresen via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > I'm very disappointed you don't mention the tradeoff at "the other end of > the bathtub" -- Key-holder versus Validator decentralization balance Gavin, could you please provide some

Re: [bitcoin-dev] Lightning Network's effect on miner fees

On Wed, Oct 14, 2015 at 10:19 AM, Paul Sztorc via bitcoin-dev wrote: > However, the two are also perfect compliments, as LN transactions cannot take > place at all without periodic on-chain transactions. Additionally, lightning network hot wallets are not

Re: [bitcoin-dev] Open Block Chain Licence, BIP[xxxx] Draft

On Tue, Sep 1, 2015 at 8:30 AM, Ahmed Zsales via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > We believe the network requires a block chain licence Here is a previous discussion of this topic (2012): https://bitcointalk.org/index.php?topic=117663.0 - Bryan http://heybryan.org/

Re: [bitcoin-dev] [BIP/Draft] BIP Acceptance Process

On Thu, Sep 3, 2015 at 7:30 PM, Andy Chase via bitcoin-dev wrote: > I wrote the BIP mostly to stir the pot on ideas of governance Some quick comments: I have some objects that I am not ready to put into words, but I do think there are easily some major

[bitcoin-dev] Multi-chain payment channel nodes

Here is a brief overview of a way to use something like the lightning network, or another multi-hop payment channel network, to handle more transactions per second. These ideas were mentioned yesterday in #bitcoin-wizards and my email does not significantly elaborate on any of it (search for

[bitcoin-dev] Some transcripts from the Scaling Bitcoin workshops

Hey while I was listening to the talks I also typed most of the words down. Here are some talks from the Hong Kong workshop: http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/bip99-and-uncontroversial-hard-forks/

Re: [bitcoin-dev] Capacity increases for the Bitcoin system.

On Mon, Dec 7, 2015 at 4:02 PM, Gregory Maxwell wrote: > The Scaling Bitcoin Workshop in HK is just wrapping up. Many fascinating > proposals were presented. I think this would be a good time to share my > view of the near term arc for capacity increases in the Bitcoin system. I > believe we’re in

Re: [bitcoin-dev] fork types (Re: An implementation of BIP102 as a softfork.)

On Wed, Dec 30, 2015 at 5:05 PM, Adam Back via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > There is also another type of fork a firm hard fork that can do the > same but for format changes that are not possible with a soft-fork. > I was drafting an email for a new thread with

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

On Sat, Dec 26, 2015 at 5:15 PM, Justus Ranvier via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On 12/26/2015 05:01 PM, Pieter Wuille via bitcoin-dev wrote: > > I think the shortest reasonable timeframe for an uncontroversial > > hardfork is somewhere in the range between 6 and

Re: [bitcoin-dev] On the security of softforks

On Fri, Dec 18, 2015 at 6:18 AM, Peter Todd via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Anyway, we should write this up as a BIP - there's been a tremendous > amount of misinformation, even flat out lies, floating around on this > subject. > Er, this sounds like something

Re: [bitcoin-dev] Increasing the blocksize as a (generalized) softfork.

On Sun, Dec 20, 2015 at 4:56 AM, joe2015--- via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > An Arbitrary Block-size Increase Via a Generalized Softfork > This seems conceptually similar to "extension blocks":

Re: [bitcoin-dev] OP_CHECKWILDCARDSIGVERIFY or "Wildcard Inputs" or "Coalescing Transactions"

On Tue, Nov 24, 2015 at 11:34 AM, Chris Priest via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > **OP_CHECKWILDCARDSIGVERIFY** Some (minor) discussion of this idea in -wizards earlier today starting near near "09:50" (apologies for having no anchor links):

Re: [bitcoin-dev] SIGHASH_NOINPUT in Segregated Witness

On Thu, Feb 25, 2016 at 7:07 PM, Joseph Poon wrote: > This would be achieved using a SIGHASH flag, termed SIGHASH_NOINPUT. It > does not include as part of the signature, the outpoint being spent > (txid and index), nor the amount. It however, would include the spent > outpoint's script as part of

Re: [bitcoin-dev] Segregated Witness App Development

On Tue, Jan 19, 2016 at 10:27 AM, Mark Friedenbach via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Wouldn't this be entirely on topic for #bitcoin-dev? It's probably better > not to fragment the communication channels and associated infrastructure > (logs, bots, etc.) Yeah, I

Re: [bitcoin-dev] Hardfork to fix difficulty drop algorithm

On Wed, Mar 2, 2016 at 8:56 AM, Luke Dashjr wrote: > We are coming up on the subsidy halving this July, and there have been some > Luke, One reason "hard-fork to fix difficulty drop algorithm" could be controversial is that the proposal involves a hard-fork (perhaps necessarily so, at my first

Re: [bitcoin-dev] Compact Block Relay BIP

On Mon, May 9, 2016 at 8:57 AM, Tom via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > The moderators failed to catch his aggressive tone while moderating my post > (see archives) for being too aggressive. > IIRC you were previously informed by moderators (on the same reddit

Re: [bitcoin-dev] Holdup on Block Alerts / Fraud Proofs ?

On Sat, Jul 30, 2016 at 6:18 PM, Paul Sztorc via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > I've also heard that segwit will help, but don't understand why. > There are some helpful discussions that happened over here:

[bitcoin-dev] Mimblewimble: non-interactive coinjoin, signature aggregation and confidential transactions

Someone dropped this document in -wizards the other day: http://5pdcbgndmprm4wud.onion/mimblewimble.txt http://diyhpl.us/~bryan/papers2/bitcoin/mimblewimble.txt Some commentary: http://gnusha.org/bitcoin-wizards/2016-08-02.log http://gnusha.org/bitcoin-wizards/2016-08-03.log

[bitcoin-dev] A conversation with Dan Boneh (2016-08-01)

Some Bitcoin developers and miners went to visit with Dan Boneh at Stanford earlier today, and I thought I would share what we talked about. Transcript: http://diyhpl.us/wiki/transcripts/2016-july-bitcoin-developers-miners-meeting/dan-boneh/ Topics discussed include elliptic curve crypto, ECDSA,

Re: [bitcoin-dev] Hardware Wallet Standard

On Tue, Aug 16, 2016 at 7:14 PM, Peter Todd via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > The other serious problem - and this is a problem with smartcards in > general > anyway - is that without Bitcoin-specific logic you're just signing > blindly; we > recently saw the

[bitcoin-dev] Some transcripts from Scaling Bitcoin 2016

Previously: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011862.html Here are some talks from Milan: http://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/fungibility-overview/ http://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/joinmarket/

Re: [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover?

On Sun, Mar 26, 2017 at 3:37 PM, Trevin Hofmann wrote: > He stated that "any invalid blocks they produce" will be orphaned. This is > not false. If non-upgraded miners do not produce blocks that are invalid > per the new rules, their blocks will not be orphaned. This is

[bitcoin-dev] Fwd: [Mimblewimble] Lightning in Scriptless Scripts

-- Forwarded message -- From: Andrew Poelstra Date: Mon, Mar 20, 2017 at 5:11 PM Subject: [Mimblewimble] Lightning in Scriptless Scripts To: mimblewim...@lists.launchpad.net In my last post about scriptless scripts [2] I described a way to do

Re: [bitcoin-dev] BIP proposal: Inhibiting a covert attack on the Bitcoin POW function

On Thu, Apr 6, 2017 at 7:02 AM, Luv Khemani via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Could you elaborate on why you consider ASICBOOST to be an attack? Attack > here implies ill-intent by the practitioner towards the network as a > primary motivating factor. > > See

[bitcoin-dev] Fwd: [Lightning-dev] Lightning in the setting of blockchain hardforks

-- Forwarded message -- From: Christian Decker Date: Thu, Aug 17, 2017 at 5:39 AM Subject: Re: [Lightning-dev] Lightning in the setting of blockchain hardforks To: Martin Schwarz , lightning-...@lists.linuxfoundation.org Hi

[bitcoin-dev] Fwd: [Lightning-dev] Lightning Developers Biweekly Meeting Announce

-- Forwarded message -- From: Rusty Russell Date: Wed, Jul 12, 2017 at 6:27 PM Subject: [Lightning-dev] Lightning Developers Biweekly Meeting Announce To: lightning-...@lists.linuxfoundation.org Hi all! Every two weeks we've been running an

Re: [bitcoin-dev] Updating the Scaling Roadmap

On Tue, Jul 11, 2017 at 8:40 PM, Paul Sztorc via bitcoin-dev wrote: > it, etc. But I am not willing to press the issue. Some of your other > comments I also find confusing but there is little to be gained in > clarifying them. ) To me it looked as if I was

[bitcoin-dev] Fwd: [Mimblewimble] proofs of position and UTXO set commitments

-- Forwarded message -- From: Bram Cohen Date: Thu, Jul 27, 2017 at 1:21 PM Subject: Re: [Mimblewimble] Switch to Blake2 To: Ignotus Peverell Cc: Bryan Bishop I have quite a few thoughts about proofs of

Re: [bitcoin-dev] Updating the Scaling Roadmap

I can't help but notice that I have read Greg's email before-- all the way back in 2016. It would have been impossible for him to write a reply to Paul's current email back then... but I also notice that Greg did not indicate that he was copy-pasting until the very end (and even then his aside at

Re: [bitcoin-dev] [BIP Proposal] Partially Signed Bitcoin Transaction (PSBT) format

On Fri, Aug 18, 2017 at 5:11 PM, Andrew Chow via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > I would like to propose a standard format for unsigned and partially > signed transactions. > Just a quick note but perhaps you and other readers would find this thread (on hardware

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

On Mon, Sep 11, 2017 at 9:03 PM, Mark Friedenbach via bitcoin-dev wrote: > I believe you meant "unclean stack," and you are correct. This was > also pointed out last tuesday by a participant at the in-person > CoreDev meetup where the idea was presented.

Re: [bitcoin-dev] Responsible disclosure of bugs

On Mon, Sep 11, 2017 at 10:37 PM, Anthony Towns via bitcoin-dev wrote: > All of those things seem like they'd help not just altcoins but bitcoin > investors/traders too, so it's not even a trade-off between classes of > bitcoin core users. And if in the end

Re: [bitcoin-dev] Revising BIP 2 to expand editorial authority

On Wed, Sep 27, 2017 at 1:56 PM, Luke Dashjr via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > What do people think about modifying BIP 2 to allow editors to merge these > kinds of changes without involving the Authors? Strictly speaking, BIP 2 > shouldn't be changed now that it

[bitcoin-dev] Fwd: [Lightning-dev] General question on routing difficulties

-- Forwarded message -- From: Olaoluwa Osuntokun Date: Sat, Nov 25, 2017 at 1:16 PM Subject: Re: [Lightning-dev] General question on routing difficulties To: Pedro Moreno Sanchez Cc: lightning-...@lists.linuxfoundation.org (final try as

Re: [bitcoin-dev] Protocol-Level Pruning

It's not clear to me if you are have looked at the previous UTXO set commitment proposals. some utxo set commitment bookmarks (a little old) http://diyhpl.us/~bryan/irc/bitcoin/utxo-commitments-or-fraud-proofs.stdout.txt TXO bitfields

Re: [bitcoin-dev] Miner dilution attack on Bitcoin - is that something plausible?

On Mon, Jun 18, 2018 at 3:40 PM, Bram Cohen via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Not sure what you're saying here. The block rate can't be particularly > increased or decreased in the long run due to the work difficulty > adjustment getting you roughly back where you

[bitcoin-dev] Alert key retirement?

Alert key has yet to be disclosed. The alert system itself has been retired for quite a while now. More information about this can be found here: https://bitcoin.org/en/alert/2016-11-01-alert-retirement https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-September/013104.html Recently it

[bitcoin-dev] Alert key disclosure

The bitcoin alert keys are disclosed in this email, followed by a disclosure of various known vulnerabilities in what was once the alert system. The bitcoin alert system has been completely retired. The network is not at risk and this warning may be safely ignored if you do not have an ancient

Re: [bitcoin-dev] Single signature for all transactions in a block?

On Sun, Dec 31, 2017 at 5:39 PM, CANNON via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > I had a question relating to scaling and privacy enhancements. > I believe that segwit combined with aggregated signatures > and coinjoin can potentially achieve such. The idea is to > use

Re: [bitcoin-dev] How accurate are the Bitcoin timestamps?

On Mon, Jan 29, 2018 at 7:34 AM, Neiman via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > But how accurate are Bitcoins timestamps? > A perspective on block timestamp and opentimestamps can be found here: https://lists.w3.org/Archives/Public/public-blockchain/2016Sep/0076.html

[bitcoin-dev] Fwd: [Lightning-dev] AMP: Atomic Multi-Path Payments over Lightning

-- Forwarded message -- From: Olaoluwa Osuntokun Date: Mon, Feb 5, 2018 at 11:26 PM Subject: [Lightning-dev] AMP: Atomic Multi-Path Payments over Lightning To: lightning-dev Hi Y'all, A common question I've seen

[bitcoin-dev] Fwd: [Lightning-dev] Post-Schnorr lightning txes

-- Forwarded message -- From: Anthony Towns Date: Mon, Feb 19, 2018 at 4:59 PM Subject: [Lightning-dev] Post-Schnorr lightning txes To: lightning-...@lists.linuxfoundation.org Hi *, My understanding of lightning may be out of date, so please forgive (or at

[bitcoin-dev] CVE-2018-17144 disclosure (inflation vulnerability) (copy-paste)

It has been informed to me that the writeup for the recent vulnerability was not distributed to this mailing list. Please find details at the following blog post: https://bitcoincore.org/en/2018/09/20/notice/ I believe a release notice was posted but not information about the bug,

[bitcoin-dev] Fwd: [bitcoin-core-dev] On the initial notice of CVE-2018-17144

-- Forwarded message -- From: Gregory Maxwell via bitcoin-core-dev < bitcoin-core-...@lists.linuxfoundation.org> Date: Sat, Sep 22, 2018 at 12:12 PM Subject: [bitcoin-core-dev] On the initial notice of CVE-2018-17144 To: bitcoin-core-...@lists.linuxfoundation.org For some reason

[bitcoin-dev] Mailing list downtime, archive, and its future

Hi all, Just fyi, but this bitcoin-dev mailing list has been down for a few weeks. It's currently hosted by Linux Foundation, and they are slowly deprecating their support for email. We will have to find an alternative service provider for the mailing list moving forward. I have received a

[bitcoin-dev] Transcripts from coredev.tech Amsterdam 2019 meeting

Hi, The following are some notes from the coredev.tech Amsterdam 2019 meeting. Any mistakes are my probably my own. Here is a conversation about the code review process in Bitcoin Core: http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2019-06-05-code-review/ Here is a conversation with

Re: [bitcoin-dev] testnet4

Be greeted Emil, On Sat, Jun 8, 2019 at 9:21 AM Emil Engler via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hello, I tried myself with some Bitcoin development. For this I used of > course the Bitcoin testnet. However it took me one hour to sync the > blockchain with around

[bitcoin-dev] Fwd: [ots-dev] miniOTS: ots proofs that fit in a tweet

-- Forwarded message - From: William Casarin Date: Wed, Jun 5, 2019 at 9:13 AM Subject: [ots-dev] miniOTS: ots proofs that fit in a tweet To: Hello OTS people, Following from my previous post about cleartext OTS proof sharing[1], I've been working on a new OTS format called

[bitcoin-dev] Transcripts from Breaking Bitcoin 2019

Hi all, The following are some notes I took during Breaking Bitcoin 2019, selected for relevance. Any mistakes are most likely my own. Carl Dong gave an excellent talk on guix as a replacement for the gitian build system:

Re: [bitcoin-dev] Bitcoin vaults with anti-theft recovery/clawback mechanisms

On Mon, Aug 12, 2019 at 10:01 AM Peter Todd wrote: > The key difference being it's not important that this be a *public* > notification: that the public can see just happens to be an (unfortunate) > implementation detail. For example, you could imagine a system where the > "prepare to spend" tx

[bitcoin-dev] Transcripts from Scaling Bitcoin 2019

Hi, Here are some transcripts of talks from Scaling Bitcoin 2019 Tel Aviv. Any errors are most likely my own. Training material Training materials for bitcoin developers: https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/edgedevplusplus/ Foundation topics:

Re: [bitcoin-dev] [BIP-able idea] Regular testnet reset

On Sun, Sep 15, 2019 at 8:49 AM Emil Engler via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hello, I'm thinking about writing a BIP about resetting the testnet on > regular/scheduled basis > As a reminder, here is where you last brought up the idea, and the feedback:

[bitcoin-dev] Bitcoin vaults with anti-theft recovery/clawback mechanisms

Hi, I have a proposal for implementing bitcoin vaults in a way that does not require any soft-forks or other software upgrades, although it could benefit from SIGHASH_NOINPUT which I'll describe later. I call them pre-signed vaults. Vault definition Here, a vault is defined as

Re: [bitcoin-dev] Bitcoin vaults with anti-theft recovery/clawback mechanisms

Hi, One of the biggest problems with the vault scheme (besides all of the setup data that has to be stored for a long time) is an attacker that silently steals the hot wallet private key and waits for the vault's owner to make a delayed-spend transaction to initiate a withdrawal from the vault.

Re: [bitcoin-dev] Bitcoin vaults with anti-theft recovery/clawback mechanisms

Replying to two emails below. On Wed, Aug 7, 2019 at 7:27 PM ZmnSCPxj wrote: > > - Re-vaulting transaction. This is where the magic happens. The > re-vaulting > > transaction is signed during transaction tree setup, before > constructing the > > delayed-spend transaction for the

Re: [bitcoin-dev] [Meta] bitcoin-dev moderation

On Thu, Aug 1, 2019 at 10:50 PM Emil Engler via bitcoin-dev wrote: > The current situation is that the moderation is slow and takes around > >24h for a E-Mail to be on the mailing list It really shouldn't be 24 hours. Our strategy was to have a few moderators in different timezones to cover

Re: [bitcoin-dev] ChainWallet - A way to prevent loss of funds by physical violence

Since the user can't prove that they are using this technique, or petertodd's timelock encryption for that matter, an attacker has little incentive to stop physically attacking until they have a spendable UTXO. I believe you can get the same effect with on-chain timelocks, or delete-the-bits plus

[bitcoin-dev] An alternative deployment path for taproot technology (Re: Taproot (and graftroot) complexity)

The following is a message forwarded from an anonymous email that, for whatever reason, couldn't be relayed through the mailing list without my assistance. This is message (2/3). This email is the second of a collection of sentiments from a group of developers who in aggregate prefer to remain

[bitcoin-dev] Taproot public NUMS optimization (Re: Taproot (and graftroot) complexity)

The following is a message forwarded from an anonymous email that, for whatever reason, couldn't be relayed through the mailing list without my assistance. This is message (3/3). This email is the third of a collection of sentiments from a group of developers who in aggregate prefer to remain

[bitcoin-dev] Taproot (and graftroot) complexity (reflowed)

Apologies for my previous attempt at relaying the message- it looks like the emails got mangled on the archive. I am re-sending them in this combined email with what I hope will be better formatting. Again this is from some nym that had trouble posting to this mailing list; I didn't see any emails

[bitcoin-dev] Taproot (and graftroot) complexity

The following is a message forwarded from an anonymous email that, for whatever reason, couldn't be relayed through the mailing list without my assistance. This email is the first of a collection of sentiments from a group of developers who in aggregate prefer to remain anonymous. These emails

[bitcoin-dev] On-chain vaults prototype

Hi, High-security protection against theft depends on multisig and timelocks, but more tools are possible. Last year I discussed one method where would-be attackers are discouraged by specially designed vault covenants [1] allowing re-vaulting transactions, where a watchtower can override a

Re: [bitcoin-dev] Libre/Open blockchain / cryptographic ASICs

On Sat, Feb 13, 2021 at 4:18 AM Luke Kenneth Casson Leighton wrote: > ... actually i don't see them in the bounces. what's happening there? > > On Saturday, February 13, 2021, Luke Kenneth Casson Leighton < > l...@lkcl.net> wrote: > > On Sat, Feb 13, 2021 at 6:10 AM ZmnSCPxj > wrote: > >> Good

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

On Fri, Feb 19, 2021 at 5:31 PM Matt Corallo via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > (off-list) > > Your email client didn't thread correctly, so I'm not sure if you saw my > responses to Adam's email, but note that there That was not off-list; by the way, as a

[bitcoin-dev] Future of the bitcoin-dev mailing list

Hello, We would like to request community feedback and proposals on the future of the mailing list. Our current mailing list host, Linux Foundation, has indicated for years that they have wanted to stop hosting mailing lists, which would mean the bitcoin-dev mailing list would need to move

Re: [bitcoin-dev] Towards a means of measuring user support for Soft Forks

You may be interested in these posts on transaction signalling: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/014193.html https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/014202.html https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014251.html

Re: [bitcoin-dev] [BIP proposal] Private Payments

Hi, On Mon, Jun 27, 2022 at 2:14 PM Alfred Hodler via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > 2. Notification transactions still exist but no longer leave a privacy > footprint on the blockchain. Instead, a notification transaction is simply > a single OP_RETURN containing

Re: [bitcoin-dev] Why OpenTimestamps does not "linearize" its transactions

On Tue, Jun 14, 2022 at 8:48 AM Undiscussed Horrific Abuse, One Victim of Many via bitcoin-dev wrote: > OTS needlessly adds the requirement that the user publicize their .ots > files to everybody who will make use of the timestamp. Publication is not a component of the OTS system. This does

Re: [bitcoin-dev] brickchain

Hi, On Wed, Oct 19, 2022 at 6:34 AM mm-studios via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Fully filled brick B0, with a hash that doesn't meet the difficulty rule, > would be broadcasted and nodes would have it on in a separate fork as usual. > Check out the previous

Re: [bitcoin-dev] Trustless Address Server – Outsourcing handing out addresses to prevent address reuse

On Mon, Oct 17, 2022 at 7:05 PM rot13maxi via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Unbeknownst to them, the clipboard contents have been replaced with an > address controlled by some bad actor. > [snip] > Now imagine instead that the wallet has some address book with a

Re: [bitcoin-dev] [Lightning-dev] Bitcoin mail list needs an explicit moderation policy

Hi Maxim, This is exceedingly boring. This is not a good use of your time. There are thousands of developers subscribed to this mailing list, and we should not waste their time, including this discussion. On Fri, Jun 2, 2023 at 6:44 PM Dr Maxim Orlovsky via Lightning-dev <

Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions

On Sun, May 7, 2023 at 12:36 PM David A. Harding via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On 2023-05-06 21:03, Michael Folkson via bitcoin-dev wrote: > > Essentially my concern is going forward current maintainers will > > decide which proposed new maintainers to add and