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 t
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 reading an email that was making a bunch
-- 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 informal Google Hangout
for im
-- 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 position. I gave a talk about
it which hopefully gets the points across if
-- 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 Martin,
this is the perfect venue to discuss this, welc
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 wal
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.
http://diyhpl.us/wiki/transcripts/bitcoin-
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 various altcoins aren't able to
> keep
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 is
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
http://diyhpl.us/wiki/transcripts/sf-bitcoin-meetup/2017-07-08
-- 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 the prior mail hit the size limit, sorry f
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 ag
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
-
-- 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 concerning Lightning is: "I have five $2
channels, is it possible
-- 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 least correct :) any e
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
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 s
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 node
-- 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 I
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,
https://lists.l
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 variety
-- 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 mi
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 so
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 1538
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:
http://diyhpl.us/wiki/transcripts/breaking-bitcoin/2019/bitcoin-build-syste
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 sleep
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
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. If
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 parent
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 i
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:
https://li
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:
https://diy
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
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 hav
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 ano
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 anon
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
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
propos
On Wed, Sep 23, 2015 at 10:43 AM, Gavin Andresen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> First: the idea of 'weak blocks' (hat tip to Rusty for the term)
Here are some other "weak blocks" and "near blocks" proposals or mentions:
https://bitcointalk.org/index.php?topic=
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 an ideal place to
store large quantities
On Wed, Oct 14, 2015 at 1:02 PM, Emin Gün Sirer
wrote:
> while the whitepaper has all the nitty gritty details:
> http://arxiv.org/abs/1510.02037
Taking reward compensation back by fraud proofs is not enough to fix
the problems associated with double spending (such as, everyone has to
wait f
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 c
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):
http://gnusha.org/bitco
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/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/fungibility-and-s
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
On Tue, Dec 8, 2015 at 10:27 AM, Akiva Lichtner via bitcoin-dev
wrote:
> and miners would have to round-robin through partitions
At first glance this proposal seems most similar to the sharding proposals:
http://diyhpl.us/wiki/transcripts/scalingbitcoin/sharding-the-blockchain/
https://github.co
On Wed, Dec 9, 2015 at 9:58 PM, Akiva Lichtner wrote:
> Correct me if I am wrong, but the dream of a virtual currency where
> everybody is equal and runs the client on their mobile device went out the
> window long ago. I think that went out with the special mining hardware. If
Mining equipment is
On Thu, Dec 10, 2015 at 12:47 AM, jl2012 wrote:
> 3. SIGHASH_WITHINPUTVALUE [1]: there are many SIGHASH proposals but this one
> has the highest priority as it makes offline signing much easier.
nhashtype proposal:
https://github.com/scmorse/bitcoin-misc/blob/master/sighash_proposal.md
OP_CODESEP
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 th
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":
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/00835
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 1
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 so
On Sat, Jan 2, 2016 at 10:37 AM, Jorge Timón
wrote:
> > Updates from IRC discussion:
>
> Is there a link to the IRC discussion?
prior-block possession proofs, fraud proofs, non-fraud correctness
proofs, commitments and segwit:
https://botbot.me/freenode/bitcoin-core-dev/2015-12-28/?msg=56907496&p
I saw these two repositories through the -wizards IRC channel earlier
today. I have not reviewed any of the source code for quality, security or
functionality, so I don't have word to offer regarding status of these.
https://github.com/LightningNetwork/lnd
https://github.com/LightningNetwork/light
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 a
On Thu, Feb 4, 2016 at 11:56 AM, jl2012 via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> past the triggering block. A block-chain re-org of two thousand or
>> more blocks on the main Bitcoin chain is unthinkable-- the economic
>> chaos would be massive, and the reaction to such a
On Sat, Feb 6, 2016 at 9:37 AM, Gavin Andresen wrote:
> Responding to "28 days is not long enough" :
>
Gavin,
Thank you for the emails. Bitcoin Core has been working with the Bitcoin
ecosystem on developing and now testing a new capacity increasing feature
called segregated witness (segwit). Seg
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
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 a
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 thread
It has occurred to me that some folks may not have seen the link floating
around the other day on IRC.
Transcript:
https://bitcoincore.org/logs/2016-05-zurich-meeting-notes.html
https://bitcoincore.org/logs/2016-05-zurich-meeting-notes.txt
Meeting notes summary:
https://bitcoincore.org/en/meeting
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:
https://botbot.me/freenode/bitcoin-core-dev/2015-12-28/?ms
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,
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
https://www.reddit.com
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 proble
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/
http://diyhpl.us/wiki/transc
-- 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
deniable atomic swaps by pre-shari
On Sun, Mar 26, 2017 at 2:05 PM, Peter R via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> With a tightening of the rule set, a hash power minority that has not
> upgraded will not produce a minority branch; instead they will simply have
> any invalid blocks they produce orphaned,
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 consistent
> with Peter's
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
https:
On Fri, May 5, 2017 at 6:24 AM, Tomas via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> I propose a method to mark blocks to indicate that they were generated
> without verifying the previous block. This can be done by using a bit of
> the version field.
>
see also:
https://lists.
On Thu, Jul 30, 2015 at 9:52 AM, Thomas Zander via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> What makes you think that when there is such a low availability of
> transaction
> space that paying to be included costs you $10, that Bitcoin is not going
> to
> be outcompeted and re
On Thu, Jul 30, 2015 at 11:23 AM, Jameson Lopp via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Stated differently, if the cost or contention of using the network rises
> to the point of excluding the average user from making transactions, then
> they probably aren't going to care
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 use
On Thu, Jul 30, 2015 at 10:55 AM, Gavin Andresen
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 a
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 argume
On Tue, Aug 11, 2015 at 1:46 PM, Michael Naber via bitcoin-dev
wrote:
> Note that lightning / hub and spoke do not meet requirements for users
> wishing to participate in global consensus, because they are not global
> consensus networks, since all participating nodes are not aware of all
> transa
On Sat, Aug 15, 2015 at 3:36 PM, Milly Bitcoin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> These are the people who used to run around saying that Bitcoin
> development is "decentralized" because anyone can fork the code and now
> many of the same people claim a fork will des
On Wed, Aug 19, 2015 at 3:59 AM, Jorge Timón <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Apparently that existed already: http://sourceforge.net/p/bitcoin/mailman/
> But technical people run away from noise while non-technical people
> chase them wherever their voices sounds more loud.
>
FW
Here is a short review of previously-proposed and exotic SIGHASH types.
SIGHASH_MULTIPLE
SIGHASH_LIST:
https://bitcointalk.org/index.php?topic=252960.0
https://bitcointalk.org/index.php?topic=212555.0
SIGHASH_MULTIPLE
SIGHASH_WITHINPUTVALUE:
https://bitcointalk.org/index.php?topic=191003.0
SIGHA
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/
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
"cros
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 objections to committee design. If I
vanish
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
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 reminder
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
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 no
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 a
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 pu
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 "weak
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 w
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 <
lightning-...@lists.lin
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 somewh
93 matches
Mail list logo
