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

[Anthony Towns via bitcoin-dev]

On Tue, Nov 07, 2023 at 09:37:22AM -0600, Bryan Bishop via bitcoin-dev wrote:
> Web forums are an interesting option, but often don't have good email user
> integration.

> What about bitcointalk.org or delvingbitcoin.org?

delvingbitcoin.org is something I setup; it's a self-hosted discourse
instance. (You don't have to self-host discourse, but not doing so limits
the number of admins/moderators, the plugins you can use, and the APIs you
can access)

For what it's worth, I think (discourse) forums have significant
advantages over email for technical discussion:

 * much better markup: you can write LaTeX for doing maths, you
   can have graphviz or mermaid diagrams generated directly from text,
   you can do formatting without having to worry about HTML email.
   because that's done direct from markup, you can also quote such
   things in replies, or easily create a modified equation/diagram
   if desired, things that are much harder if equations/diagrams are
   image/pdf attachments.

 * consistent threading/quoting: you don't have to rely on email clients
   to get threading/quoting correct in order to link replies with the
   original message

 * having topics/replies, rather than everything being an individual
   email, tends to make it easier to avoid being distracted by followups
   to a topic you're not interested in.

 * you can do reactions (heart / thumbs up / etc) instead of "me too"
   posts, minimising the impact of low-content responses on readers,
   without doing away with those responses entirely.

 * after the fact moderation: with mailing lists, moderation can only
   be a choice between "send this post to every subscriber" or not,
   and the choice obviously has to be made before anyone sees the posts;
   forums allow off-topic/unconstructive posts to be removed or edited.

Compared to mailing-lists-as-a-service, a self-hosted forum has a few
other possible benefits:

 * it's easier to setup areas for additional topics, without worrying
   you're going to be forced into an arbitrarily higher pricing tier

 * you can setup spaces for private working groups. (and those groups can
   make their internal discussions public after the fact, if desired)

 * you can use plugin interfaces/APIs to link up with external resources

There are a few disadvantages too:

 * discourse isn't lightweight -- you need a whole bunch of infrastructure
   to go from the markdown posts to the actual rendered posts/comments;
   so backups of just the markdown text isn't really "complete"

 * discourse is quite actively developed -- so it could be possible
   that posts that use particular features/plugins (eg to generate
   diagrams) will go stale eventually as the software changes, and stop
   being rendered correctly

 * discourse gathers a moderate amount of non-public/potentially private
   data (eg email addresses, passwords, IP addresses, login times) that
   may make backups and admin access sensitive (which is why there's a
   git archive generated by a bot for delvingbitcoin, rather than raw
   database dumps)

There are quite a few open source projects using discourse instances, eg:

  Python: https://discuss.python.org/
  Ruby on Rails: https://discuss.rubyonrails.org/
  LLVM: https://discourse.llvm.org/
  Jupyter: https://discourse.jupyter.org/
  Fedora: https://discussion.fedoraproject.org/
  Ubuntu: https://discourse.ubuntu.com/
  Haskell: https://discourse.haskell.org/

There's also various crypto projects using it:

  Eth research: https://ethresear.ch/
  Chia: https://developers.chia.net/

There's a couple of LWN articles on Python's adoption of discourse
that I found interesting, fwiw:

  https://lwn.net/Articles/901744/  [2022-07-20]
  https://lwn.net/Articles/674271/  [2016-02-03]

I don't think this needs to be an "either-or" question -- better to
have technical discussions about bitcoin in many places and in many
formats, rather than just one -- but I thought I'd take the opportunity
to write out why I thought discourse was worth spending some time on in
this context.

Cheers,
aj
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] OP_Expire and Coinbase-Like Behavior: Making HTLCs Safer by Letting Transactions Expire Safely

[Peter Todd via bitcoin-dev]

On Wed, Nov 08, 2023 at 12:51:31AM +, Peter Todd via bitcoin-dev wrote:
> > In a post-package relay world, I think this is possible. And that
> > replacement cycling attacks are breaking future dynamic fee-bumping of
> > pre-signed transactions concerns me a lot.
> 
> Well the answer here is pretty clear: v3 package relay with anchors is broken.

BTW a subtlety of this that may not be obvious is that in v3 package relay,
with zero value outputs, the outputs must be spent in the same package. Thus
_unlike_ existing anchor-using transactions, there would be only one anchor
output on the commitment transaction.

In existing anchor output transactions, this type of attack wouldn't work as
when broadcasting the transaction, Alice would be spending her anchor output,
which Bob can't double spend. But that doesn't work in v3, which intends to
limit UTXO growth by requiring that anchors be spent in the same package. Thus
unlike existing anchor outputs, an anchor would be truly a OP_1 output without
a signature, and thus belong to either Alice nor Bob uniquely.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org


signature.asc
Description: PGP signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] bitcoin-dev Digest, Vol 102, Issue 15

[Luke Kenneth Casson Leighton via bitcoin-dev]

On Tuesday, November 7, 2023, James Blacklock 
wrote:

> Agreed, email lists are the way. Personally I love reading the email
list; it is a great resource to know what kinds of technical discussions
are going on in the community. I certainly hope we can just migrate to a
different email list.

i have a friend alain williams who runs lists.phcomp.co.uk
and is competent at it. was the UKUUG Chair err 25 years ago?
cc'd.

the other lowest-common-denominator method is of course nntp
newsgroups (eternal-september.org run an excellent spam-free
one) and i do not mean "newsgroups via groups.google.com",
i mean *actual* nntp newsgroups, you know, the ones that have
been running for 40 years and everyone has forgotten even
exist? :)

they were and always have been distributed and distributable
(and spam-free *if* run properly) and i am sure the owner of
eternal-september would be happy to host/distribute bitcoin-dev.

another idea is public-inbox which actually stores
an entire mail archive *in a git repository*
https://github.com/nojb/public-inbox

  public-inbox implements the sharing of an email inbox
  via git to complement or replace traditional mailing lists.
  Readers may read via NNTP, IMAP, Atom feeds or HTML archives.

public-inbox can be "initialised" from a mailman archive
so you can have the entire past history of messages in
the git repo as well.  it's really quite sophisticated.

if anyone doesn't like "email bcuz old", or wants to remain
anonymous, they can always get a protonmail account, use
mail-forwarders, and TOR. and if they are happy to use nntp they can
register
on eternal-september.org, which then allows them to send and
receive... and then use TOR-proxy.

all doable *without* having to install something that will
consume alarmingly high resources and cost a fortune in hosting
every month.

l.

>
>
> On Tuesday, November 7th, 2023 at 3:20 PM, Luke Kenneth Casson Leighton
via bitcoin-dev  wrote:
>
>
>>
>>
>> On Tuesday, November 7, 2023, <
bitcoin-dev-requ...@lists.linuxfoundation.org> wrote:
>>
>> > Rooms can be E2E encrypted.
>>
>> please, NO.
>>
>> there are people who have such valuable skills that their
>> lives are put in danger if they engage in encrypted conversations.
>>
>> additionally the entire point of an open project IS THAT IT IS OPEN.
>>
>> mailing lists are the lowest OPEN common denominator.
>>
>> l.
>>
>>
>> --
>> ---
>> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
>

-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] OP_Expire and Coinbase-Like Behavior: Making HTLCs Safer by Letting Transactions Expire Safely

[Peter Todd via bitcoin-dev]

On Mon, Nov 06, 2023 at 06:45:21PM +, Antoine Riard wrote:
> > I think you are misunderstanding a key point to my OP_Expire proposal:
> because
> > the ability to spend the preimage branch of the HTLC goes away when the
> refund
> > branch becomes available, replacing cycling or any similar technique
> becomes
> > entirely irrelevant.
> 
> > The situation where Carol prevents Bob from learning about the preimage
> in time
> > simply can't happen: either Carol collects the HTLC with knowledge of the
> > preimage, by spending it in a transaction mined prior to the expiration
> time
> > and ensuring that Bob learns the preimage from the blockchain itself. Or
> the
> > HTLC expires and Bob can use the refund branch at his leisure.
> 
> I think I understand the semantic of the OP_Expire proposal overall
> correctly, however I'm not sure it prevents replacing cycling or any
> similar adversarial technique, as the forwarding node might be the attacker
> in some scenario.



> Assuming this advanced scenario is correct, I'm not sure the OP_Expire
> proposal is substantially fixing all the adversarial replacement cycling
> situations.

What you are describing here is a completely different problem than what
OP_Expire aims to solve.

The problem that OP_Expire aims to solve is the fact that Carol could prevent
Bob from learning about the preimage in time, while still getting a chance to
use the preimage herself. OP_Expire thoroughly solves that problem by ensuring
that the preimage is either broadcast in the blockchain in a timely fashion, or
becomes useless.

The problem you are describing, as Zmm points out below, doesn't actually exist
in Bitcoin right now. But it could exist if we adopted v3 package relay, which
as I've pointed out elsewhere, is inferior to using RBF.


On Tue, Nov 07, 2023 at 03:44:21PM +, Antoine Riard wrote:
> Hi Zeeman,
> 
> > Neither can Bob replace-recycle out the commitment transaction itself,
> because the commitment transaction is a single-input transaction, whose
> sole input requires a signature from
> > Bob and a signature from Carol --- obviously Carol will not cooperate on
> an attack on herself.
> 
> The replacement cycling happens on the commitment transaction spend itself,
> not the second stage, which is effectively locked until block 100.
> 
> If the commitment transaction is pre-signed with 0 sat / vb and all the
> feerate / absolute fee is provided by a CPFP on one of the anchor outputs,
> Bob can replace the CPFP itself. After replacement of its child, the
> commitment transaction has a package feerate of 0 sat / vb and it will be
> trimmed out of the mempool.
> 
> This is actually the scenario tested here on the nversion = 3 new mempool
> policy branch  (non-deployed yet):
> https://github.com/ariard/bitcoin/commits/2023-10-test-mempool-2
> 
> As of today commitment transactions might not propagate if dynamic mempool
> min fee is above pre-signed commitment transaction, which is itself unsafe.
> I think this behavior can currently be opportunistically exploited by
> attackers.

Yes, obviously it can be. For starters, you can easily end up in a situation
where the commitment transaction simply can't get mined, an obvious problem.

> In a post-package relay world, I think this is possible. And that
> replacement cycling attacks are breaking future dynamic fee-bumping of
> pre-signed transactions concerns me a lot.

Well the answer here is pretty clear: v3 package relay with anchors is broken.

My suggestion of pre-signing RBF replacements, without anchor outputs, and with
all outputs rendered unspendable with 1 CSV, is clearly superior: there are
zero degrees of freedom to the attacker, other than the possibility of
increasing the fee paid or broadcasting a revoked commitment. The latter of
course risks the other party punishing the fraud.

This does have the practical problem that a set of refund transactions will
also need to be signed for each fee variant. But, eg, signing 10x of each isn't
so burdensome. And in the future that problem could be avoided with
SIGHASH_NOINPUT, or replacing the pre-signed refund transaction mechanism with
a covenant.

Using RBF rather than CPFP with package relay also has the advantage of being
more efficient, as no blockspace needs to be consumed by the anchor outputs or
transactions spending them. Of course, there are special circumstances where
BIP125 rules can cause CPFP to be cheaper. But we can easily fix that, eg by
reducing the replacement relay fee, or by delta-encoding transaction updates.


As SIGHASH_NOINPUT is desirable for LN-Symmetry, a softfork containing both it
and OP_Expire could make sense.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org


signature.asc
Description: PGP signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Implementing Blake3 in Bitcoin Script

[Robin Linus via bitcoin-dev]

Good morning mailing list,

We implemented a hash function in Bitcoin Script to verify Merkle inclusion 
proofs in the BitVM. This allows the VM to have sheer infinite memory, which 
doesn't have to get represented in expensive bit commitments.

The following transaction demonstrates on-chain a Blake3 hash lock, which is 
unlocked by providing the preimage in the unlocking script: 
https://blockstream.info/tx/d8a091a7f5ffa4993681b3df688968fd274bc76897b8b3953309ffad6055f4b0?expand
 

 If you're curious, here you can find the source code: 
https://github.com/BitVM/BitVM/blob/main/opcodes/examples/blake3.js 

We chose Blake3 as it seems to be one of the most simple modern hash functions 
in terms of instruction count. We implemented only a single round performed 
over a 64 byte message, because that's sufficient for us to verify Merkle 
paths. Our implementation represents u32 words as 4 separate bytes on the 
stack, because that seemed to be the optimal tradeoff to implement u32 
addition, u32 bitwise XOR, and u32 bitwise rotations, as required for Blake3. 

We used JavaScript as templating language, to assemble complex programs from 
relatively simple opcodes. You can find the implementation of our u32 opcodes 
here: https://github.com/BitVM/BitVM/tree/main/opcodes/u32 
 In particular, for the 
bitwise XOR we used some cool hacks with a lookup table for a helper function: 
https://github.com/BitVM/BitVM/blob/main/opcodes/docs/u8_xor.md 


Furthermore, we added a simple memory management, which allows us to have 
identifiers for variables, which we can read and write, and keep track of them 
while they're moved on the stack. For example, this allows us to implement the 
permutations of the Blake state simply by relabeling the identifiers of 
variables, instead of actually moving them around on the stack.

In total, the script is about 100kB or 25k vBytes. That's fine for now to build 
a toy-version of BitVM, but the actual plan is to split up the Blake code, such 
that verifier and prover can reduce the required onchain data significantly by 
bisecting the execution in a challenge-response game instead of executing it 
fully.


Cheers, 
- Robin




Co-Founder and President

ZeroSync
6300 Zug
Switzerland

https://zerosync.org | https://twitter.com/zerosync_

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Peter Todd via bitcoin-dev]

On Tue, Nov 07, 2023 at 09:37:22AM -0600, Bryan Bishop via bitcoin-dev wrote:
> Anti spam has been an issue for the moderators. It's relentless. Without
> access to the underlying server, it has been difficult to fight spam. There
> is some support for filters in mailman2 but it's not great.

Since this is a technical mailing list it would be fine to require people to
pay a non-refundable anti-spam fee, eg via lightning, to gain the ability to
send messages. While this would require some custom software, it's probably
even possible to implement this if a third party is used for hosting, provided
they have some kind of API.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org


signature.asc
Description: PGP signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Peter Todd via bitcoin-dev]

On Tue, Nov 07, 2023 at 11:03:30AM -0600, Ademan via bitcoin-dev wrote:
> Hi Bryan,
> 
> I don't really want my first (and last?) devlist message to be a fairly
> off-the-cuff post on this topic, but here we go anyway.
> 
> At the risk of sounding like a nostr evangelist (I promise I'm not), I want
> to suggest nostr as a potential replacement to the mailing list. A decent
> chunk of software would need to be written, but none of the alternatives
> seem particularly attractive to me. I particularly dislike the idea of
> locking into a single siloed forum service like the bitcointalk forums. I
> realize I may be in the minority of course.

Strong NACK on nostr. It's a badly designed, centralized, protocol that needs a
significant redesign to be usable. While off topic for this mailing list, some
of its many issues include:

* Reliance on single-key, cryptography that often results in people having
  their keys compromised. This is a serious problem in the context of
  bitcoin-dev, where faked messages published could easily have market-moving
  results.

* Inability to mirror relays: since nostr deliberately ignores the lessons of
  blockchains, there is no way to be sure that you have a complete set of
  messages from a given person, for a given topic, etc.

* Highly centralized design: since mirroring relays isn't reliable, in reality
  nostr operates in a highly centralized fashion, dependent on a tiny number of
  relays that can't be easily replaced if taken down.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org


signature.asc
Description: PGP signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Peter Todd via bitcoin-dev]

On Tue, Nov 07, 2023 at 11:41:59AM -0800, Christopher Allen via bitcoin-dev 
wrote:
> As Bitcoin-Core already uses GitHub, another possibility is to use the new
> GitHub discussions feature. We increasingly have been using this at
> Blockchain Commons as everyone is using already using GitHub. We have also
> created some GitHub actions to backup discussions so that GitHub will not
> be a central point of failure -should be possible to create a static page
> archive using GitHub pages (but have not had budget for that).
> 
> For instance, here is the GitHub discussion area for wallet developers
> working together on Bitcoin wallet interoperability specifications:
> https://github.com/BlockchainCommons/Gordian-Developer-Community

Strong NACK.

bitcoin-dev should be independent of Bitcoin Core.

Also, a very useful thing that a mailing list does that GitHub does not is
cryptographic signatures, both obvious like PGP, and less obvious like DKIM. We
should not be moving even more discussion to mediums where authors aren't
properly signing their messages.

The user experience of GitHub and similar web forums is poor too. It's much
nicer to be able to reply to messages offline, asyncronously, regardless of
whether or not you happen to have a good internet connection at the time.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org


signature.asc
Description: PGP signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Keagan McClelland via bitcoin-dev]

I also think that good archives are extremely important. Far more important
than being a medium of discussion is capturing all of that discussion for
posterity. An unbelievable amount of knowledge capital has been built up in
the mailing list over the years and given that Bitcoin is a system that
needs to survive complete turnover in its contributor base, it's of extreme
importance that we have a system that can capture the archive.

While Nostr might be good towards the end of being very resilient it isn't
mature enough to have good UX's built up around it wherein people with a
variety of backgrounds can engage it. Personally, I think the email UX
leaves a lot to be desired but at least it's accessible to a lot of people.
I don't think I can say the same for Nostr yet.

I won't opine much further on the solution but I think the properties we
need to solve for are:

1. Archive is effectively permanent
2. Accessible to a wide audience
3. Data format is not proprietary and isn't tied to the success or failure
of a particular organization

In principle I think that Nostr can offer a lot in the long term towards
this goal, but it isn't really an immediate solution to this problem.

Keags

On Tue, Nov 7, 2023 at 12:07 PM David A. Harding via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On 2023-11-07 05:37, Bryan Bishop via bitcoin-dev wrote:
> > What about [...] delvingbitcoin.org?
>
> I'm only willing to consider discussion groups that provide good
> archives, so I think it's worth noting that James O'Beirne has written
> code[1] and is currently maintaining a git repo[2] with a backup of
> Delving Bitcoin discussion.  See his post[3] for additional details.
>
> In addition to providing an archive, I currently find it to be nice way
> to quickly skim all posts made to the forum since I last checked (plus I
> see edits)[4]:
>
> $ cd delving-bitcoin-archive/
> $ git pull
> $ git log -p archive/rendered-topics/
>
> I think some technical discussions were already migrating to Delving
> Bitcoin before the shutdown notice and I expect more discussions to move
> there in the future even if the current mailing list is relocated to a
> new platform.  Knowing that discussions are archived in a way that I can
> easily replicate was key to me feeling comfortable putting significant
> time into reading and writing posts on Delving Bitcoin, so I wanted to
> share that information here.
>
> -Dave
>
> [1] https://github.com/jamesob/discourse-archive
> [2] https://github.com/jamesob/delving-bitcoin-archive
> [3] https://delvingbitcoin.org/t/public-archive-for-delving-bitcoin/87/6
> [4] Plus every commit makes me laugh.  James O'Beirne's commit robot is
> called "jamesobot"
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] bitcoin-dev Digest, Vol 102, Issue 15

[James Blacklock via bitcoin-dev]

Agreed, email lists are the way. Personally I love reading the email list; it 
is a great resource to know what kinds of technical discussions are going on in 
the community. I certainly hope we can just migrate to a different email list.


On Tuesday, November 7th, 2023 at 3:20 PM, Luke Kenneth Casson Leighton via 
bitcoin-dev  wrote:


> 
> 
> On Tuesday, November 7, 2023,  
> wrote:
> 
> > Rooms can be E2E encrypted.
> 
> please, NO.
> 
> there are people who have such valuable skills that their
> lives are put in danger if they engage in encrypted conversations.
> 
> additionally the entire point of an open project IS THAT IT IS OPEN.
> 
> mailing lists are the lowest OPEN common denominator.
> 
> l.
> 
> 
> --
> ---
> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Ryan Breen via bitcoin-dev]

I think GitHub Discussions is a great idea. If we are considering proprietary 
options like Google Groups, then we should definitely consider Discussions.

1. Guaranteed that nearly everyone participating here already has a GH account.
2. Offers many moderation options.
3. Good formatting abilities(tables!).
4. Can @ people.
5. Ability to categorize, close, lock discussions, etc.
6. Many great potential opportunities for automation via Actions.
7. Comes with added benefits such as a wiki, issues, etc.

My one catch is that I do not know what kind of interactions you can have with 
Discussions via email. This seems to be an important feature for many. What 
level of email notifications can you receive? Can you respond via email?

> On Nov 7, 2023, at 3:16 PM, Christopher Allen via bitcoin-dev 
>  wrote:
> 
> 
> As Bitcoin-Core already uses GitHub, another possibility is to use the new 
> GitHub discussions feature. We increasingly have been using this at 
> Blockchain Commons as everyone is using already using GitHub. We have also 
> created some GitHub actions to backup discussions so that GitHub will not be 
> a central point of failure -should be possible to create a static page 
> archive using GitHub pages (but have not had budget for that).
> 
> For instance, here is the GitHub discussion area for wallet developers 
> working together on Bitcoin wallet interoperability specifications: 
> https://github.com/BlockchainCommons/Gordian-Developer-Community
> 
> — Christopher Allen
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Tao Effect via bitcoin-dev]

Hi, I also have faced this same problem, and here’s my solution to it:

Use the latest version of https://www.simplemachines.org/ .

This is the same forum software that powered Bitcointalk, Silk Road, etc.

It has many advantages over every other platform out there:

1. It has great anti-spam prevention tools.
2. It gives you the tools you’ve requested with respect to moderation 
(individual moderation accounts with customizable permissions).
3. It is simple to use.
4. It is pretty and well designed, and allows you to organize threads and 
forums really well (unlike Discourse).
5. It doesn’t make unnecessary use of JavaScript (unlike Discourse), and 
therefore works well with all search engines (present and future).
6. You can self-host it, and migrate it to another server if needed, allowing 
the community to maintain full control over the data (unlike Microsoft/Github).
7. It supports great search functionality.
8. It is open source, and has many community plugins.
9. It runs anywhere PHP runs.
10. It is fast.
11. It has a well established history of powering Bitcoin communities. It has 
been with us from Day 1.

After using phpBB for years, researching other forums software, I switched to 
SMF, and stuck with it. I’m happy I did so. I recommend it.

Kind regards,
Greg Slepak

> On Nov 7, 2023, at 7:37 AM, Bryan Bishop via bitcoin-dev 
>  wrote:
> 
> [moving]

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[ponymontana via bitcoin-dev]

Hi, 

This impellent deadline could be took with enthusiasm from people that are 
anxious to experiment with new protocols and platforms that can replicate 
mailing lists and offer, in theory, better solutions.
I think this enthusiasm is totally positive and I encourage them to work on 
that ideas.

But I also think that this mailing list fills a very particoular need of 
communication in the bitcoin space. 
The stream of ideas hosted here is strictly dependant on the form it assumes 
when formalized in the peculiar format of mails-threads. 
Migrating these technical discussions to a forum or a pseudo-group-chat 
wouldn't replace this mailing list, even if the moderators behind and most of 
the participants would be the same.
It would eventually be a new and unstable solution, with no-guarantee to 
preserve the same goals reached here.

Today exist a lot of places where people can exchange ideas about bitcoin;
if new platforms will emerge as better suited to hosts BIP drafts and technical 
discussions, people will move organically through them.
In my opinion, "finding a new platform" is only marginally correlated to our 
main topic here.


If our problem is helping decide the "future of bitcoin-dev mailing list", the 
only two solutions to me appear to tautologically be:

1) Give continuity to bitcoin-dev mailing list with a ready drop-in 
replacement. 

2) Don't give continuity the bitcoin-dev mailing list.


In the case 1) a solution could be find a new host for the mailing list and 
work around the problems exposed.

In the case 2) is possible to do nothing OR to propose a new solution as a sort 
of "spiritual continuation" of bitcoin-dev mailing list, and eventually see if 
people will converge on it.


Understanding all the difficulty behind the management of the bitcoin-dev 
mailing list, I think it has worked very well for many years, and I hope it 
will work for the years to come.
I also want to say thanks to all the people behind this mailing list for all 
your work and effort.


---PM

Il 7 novembre 2023 16:37:22 CET, Bryan Bishop via bitcoin-dev 
 ha scritto:
>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 somewhere else. We temporarily
>avoided that, but recently LF has informed a moderator that they will cease
>hosting any mailing lists later this year.
>
>In this email, we will go over some of the history, options, and invite
>discussion ahead of the cutoff. We have some ideas but want to solicit
>feedback and proposals.
>
>Background
>==
>
>The bitcoin-dev mailing list was originally hosted on Sourceforge.net. The
>bitcoin development mailing list has been a source of proposals, analysis,
>and developer discussion for many years in the bitcoin community, with many
>thousands of participants. Later, the mailing list was migrated to the
>Linux Foundation, and after that OSUOSL began to help.
>
>Linux Foundation first asked us to move the mailing list in 2017. They
>internally attempted to migrate all LF mailing lists from mailman2 to
>mailman3, but ultimately gave up. There were reports of scalability issues
>with mailman3 for large email communities. Ours definitely qualifies as..
>large.
>
>2019 migration plan: LF was to turn off mailman and all lists would migrate
>to the paid service provider groups.io. Back then we were given accounts to
>try the groups.io interface and administration features. Apparently we were
>not the only dev community who resisted change. To our surprise LF gave us
>several years of reprieve by instead handing the subdomain and server-side
>data to the non-profit OSUOSL lab who instead operated mailman2 for the
>past ~4 years.
>
>OSUOSL has for decades been well known for providing server infrastructure
>for Linux and Open Source development so they were a good fit. This however
>became an added maintenance burden for the small non-profit with limited
>resources. Several members of the Bitcoin dev community contributed funding
>to the lab in support of their Open Source development infrastructure
>goals. But throwing money at the problem isn’t going to fix the ongoing
>maintenance burden created by antiquated limitations of mailman2.
>
>Permalinks
>==
>
>Linux Foundation has either offered or agreed to maintain archive
>permalinks so that content of historic importance is not lost. Fortunately
>for us while lists.linuxfoundation.org mailman will go down, they have
>agreed the read-only pipermail archives will remain online. So all old URLs
>will continue to remain valid. However, the moderators strongly advise that
>the community supplements with public-inbox instances to have canonical
>archive urls that are separate from any particular email software host.
>
>Public-Inbox
>
>
>https://pub

Re: [bitcoin-dev] bitcoin-dev Digest, Vol 102, Issue 15

[Luke Kenneth Casson Leighton via bitcoin-dev]

On Tuesday, November 7, 2023, 
wrote:

> Rooms can be E2E encrypted.

please, NO.

there are people who have such valuable skills that their
lives are put in danger if they engage in encrypted conversations.

additionally the entire point of an open project IS THAT IT IS OPEN.

mailing lists are the lowest OPEN common denominator.

l.


-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Christopher Allen via bitcoin-dev]

As Bitcoin-Core already uses GitHub, another possibility is to use the new
GitHub discussions feature. We increasingly have been using this at
Blockchain Commons as everyone is using already using GitHub. We have also
created some GitHub actions to backup discussions so that GitHub will not
be a central point of failure -should be possible to create a static page
archive using GitHub pages (but have not had budget for that).

For instance, here is the GitHub discussion area for wallet developers
working together on Bitcoin wallet interoperability specifications:
https://github.com/BlockchainCommons/Gordian-Developer-Community

— Christopher Allen
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Ademan via bitcoin-dev]

Hi Andrew,
Thanks for the thoughtful response. I don't know that you'll find my
responses satisfactory (particularly around moderation), but there are at
least solutions to the objections. Except of course the timeline, which I
got wrong ;-) and means this would be half-baked at best by the time it's
needed.

On Tue, Nov 7, 2023 at 1:06 PM Andrew Chow via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi Dan,
>
> I don't think nostr would be a suitable replacement for the mailing
> list, although this opinion is biased by the fact that I do not use
> nostr and find it to be uninteresting.
>

I felt that way for a long time. I still have a number of reservations
about it technically, but I'm increasingly impressed, though not for
reasons relevant to the discussion.


>  From my limited understanding of how nostr works, it's not clear to me
> how a distributed system that uses message broadcast would work in the
> same way as a mailing list. How would people "subscribe"?


This is already accomplished by existing apps in various ways. There are
multiple options, from using labels, or topic tags (
https://github.com/nostr-protocol/nips/tree/master#standardized-tags ) (my
preference) or the moderated community approach (see below on moderation)


> How would
> archives be searched or otherwise be available to people who are not on
> nostr?


Dumb web portals with a familiar interface, existing nostr apps are
available as web clients in the interim.


> How do you distinguish and filter between legitimate dev posts
> intended for discussion and random crap and shitposting as shows up on
> social media?
>

I lean strongly towards the topic tag or label approach to constructing the
list, which means anyone can post "to the list". Moderation would be
applied client side like all nostr clients already do. This is where PoW (
https://github.com/nostr-protocol/nips/blob/master/13.md ) , and/or
web-of-trust and labeling (
https://github.com/nostr-protocol/nips/blob/master/32.md ) come in.

Moderation comes "for free" in the moderated communities model (
https://github.com/nostr-protocol/nips/blob/master/72.md ) Note that this
approach creates exactly the same moderation burden as the list team
already shoulders, and is overall less desirable imho, but it provides the
same level of control the current list does.


> I also don't think that long form text on nostr (or any similar
> platform) can sufficiently replace email. None of these things seem to
> contain a way to have a separate subject line as email does.


"Subject tag" ( https://github.com/nostr-protocol/nips/blob/master/14.md )


> Subjects
> are immensely important for me as it provides a quick and easy way to
> filter out things I don't care about reading. I don't want to have read
> something in before I can decide that I don't care about reading it.
>
> In general, I strongly prefer email, or a platform that has email as a
> first class user interface, over platforms such as nostr, matrix, or web
> forums. Email is universal - everyone has one and everyone knows how it
> works. It dramatically lowers the barrier of entry.


I think you'd be surprised just how low the barrier to entry in nostr is.
You can navigate to the website of any number of nostr apps and click
"generate key", but your point about the universality of email is well
taken. I think an email bridge would be an essential part of this system.
An email bridge would only be less than first-class because email is not as
rich as nostr* , from the email-user's perspective it could be no worse
than using an existing list server. FWIW I also strongly prefer email over
any web forum.

* Unless you want to go wild with non-standard headers


> Having to make an
> account somewhere or download some specific client in order to
> participate will simply result in only the most dedicated participating.
>

I actually think the barrier to entry is exceedingly low, which is part of
why we have concern about the spam problem.


> Development in open source must be an open process and the barriers to
> entry should be low.
>
> Lastly, IIRC the plan is to shut down the list by the end of this year.
> Any solution that requires custom software and bridges to be created are
> not going to be viable in this time frame.
>

I have to admit I misread the OP as shutdown at the end of 2024, not 2023,
but you're right, barely 2 months is a very tight schedule. Truly
addressing the needs of the list in that time frame is unlikely to be
possible. FWIW a workable "close enough" is basically possible today, but
that is probably unsatisfying.

Certainly if I take the lead, 2024-01-01 is an impossible timeline
(especially given my other obligations), but if there is even moderate
interest (part of why I bothered to share my ramblings), I could start
working on an MVP of the bridge, and a web client for evaluation down the
road.

Cheers,
Dan


>
> Andrew
>
> On 11/07/2023 12:03 PM, Ademan via bitcoin-dev 

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

[David A. Harding via bitcoin-dev]

On 2023-11-07 05:37, Bryan Bishop via bitcoin-dev wrote:

What about [...] delvingbitcoin.org?


I'm only willing to consider discussion groups that provide good 
archives, so I think it's worth noting that James O'Beirne has written 
code[1] and is currently maintaining a git repo[2] with a backup of 
Delving Bitcoin discussion.  See his post[3] for additional details.


In addition to providing an archive, I currently find it to be nice way 
to quickly skim all posts made to the forum since I last checked (plus I 
see edits)[4]:


$ cd delving-bitcoin-archive/
$ git pull
$ git log -p archive/rendered-topics/

I think some technical discussions were already migrating to Delving 
Bitcoin before the shutdown notice and I expect more discussions to move 
there in the future even if the current mailing list is relocated to a 
new platform.  Knowing that discussions are archived in a way that I can 
easily replicate was key to me feeling comfortable putting significant 
time into reading and writing posts on Delving Bitcoin, so I wanted to 
share that information here.


-Dave

[1] https://github.com/jamesob/discourse-archive
[2] https://github.com/jamesob/delving-bitcoin-archive
[3] https://delvingbitcoin.org/t/public-archive-for-delving-bitcoin/87/6
[4] Plus every commit makes me laugh.  James O'Beirne's commit robot is 
called "jamesobot"

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Andrew Chow via bitcoin-dev]

Hi Dan,

I don't think nostr would be a suitable replacement for the mailing 
list, although this opinion is biased by the fact that I do not use 
nostr and find it to be uninteresting.

 From my limited understanding of how nostr works, it's not clear to me 
how a distributed system that uses message broadcast would work in the 
same way as a mailing list. How would people "subscribe"? How would 
archives be searched or otherwise be available to people who are not on 
nostr? How do you distinguish and filter between legitimate dev posts 
intended for discussion and random crap and shitposting as shows up on 
social media?

I also don't think that long form text on nostr (or any similar 
platform) can sufficiently replace email. None of these things seem to 
contain a way to have a separate subject line as email does. Subjects 
are immensely important for me as it provides a quick and easy way to 
filter out things I don't care about reading. I don't want to have read 
something in before I can decide that I don't care about reading it.

In general, I strongly prefer email, or a platform that has email as a 
first class user interface, over platforms such as nostr, matrix, or web 
forums. Email is universal - everyone has one and everyone knows how it 
works. It dramatically lowers the barrier of entry. Having to make an 
account somewhere or download some specific client in order to 
participate will simply result in only the most dedicated participating. 
Development in open source must be an open process and the barriers to 
entry should be low.

Lastly, IIRC the plan is to shut down the list by the end of this year. 
Any solution that requires custom software and bridges to be created are 
not going to be viable in this time frame.


Andrew

On 11/07/2023 12:03 PM, Ademan via bitcoin-dev wrote:
> Hi Bryan,
> 
> I don't really want my first (and last?) devlist message to be a fairly 
> off-the-cuff post on this topic, but here we go anyway.
> 
> At the risk of sounding like a nostr evangelist (I promise I'm not), I 
> want to suggest nostr as a potential replacement to the mailing list. A 
> decent chunk of software would need to be written, but none of the 
> alternatives seem particularly attractive to me. I particularly dislike 
> the idea of locking into a single siloed forum service like the 
> bitcointalk forums. I realize I may be in the minority of course.
> 
> 
> Nostr enables the ML team to outsource all of its biggest burdens, if it 
> chooses:
> 
> - mail server blocking is N/A to nostr
> 
> - Hosting costs are completely outsourced unless the ML team chooses to 
> host a relay.
> 
> - Archives and web portal access can be similarly outsourced because any 
> nostr archive is self-authenticating.
> 
> - The ML team can also choose to completely outsource moderation, as 
> nostr is (more or less) permissionless by nature.
>    I understand if there is a "blessed" communication system, the ML 
> team would probably prefer to keep it high quality. To that end there 
> are proposals for proof-of-work, and web of trust based blocklists for 
> nostr which are optional for end users. There are other options such as 
> the "moderated communities" proposal which would provide tighter control.
> 
> 
> On the user side, the optional moderation is very attractive, allowing 
> controversial threads to exist and continue, without requiring everyone 
> to see them.
> 
> 
> The following do not currently exist (to my knowledge) and would need to 
> be implemented to meet the ML's requirements:
> 
> - an email gateway to satisfy the bulk of existing ML subscribers
>    This reintroduces issues with mail server blocking of course.
> - a long-form oriented nostr client (current plain text clients could be 
> used in the meantime)
> 
> That admittedly is quite a lot of work, but the second item can be 
> deferred, and the first is not particularly technically challenging, the 
> complications are all on the administration side.
> 
> I expect some reflexive NACKs based on the immaturity of the ecosystem 
> but if we have months to prepare, I believe the core requirements can be 
> solidly satisfied in time, the rest can be developed over time, and I 
> believe the advantages are worth careful consideration.
> 
> Cheers,
> Dan
> 
> On Tue, Nov 7, 2023 at 9:38 AM Bryan Bishop via bitcoin-dev 
>  > wrote:
> 
> 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 somewhere
> else. We temporarily avoided that, but recently LF has informed a
> moderator that they will cease hosting any mailing lists later this
> year.
> 
> In this email, we will go over some of the history, options, an

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

[Andreas Schildbach via bitcoin-dev]

On 07/11/2023 16.37, Bryan Bishop via bitcoin-dev wrote:

We would like to request community feedback and proposals on the future 
of the mailing list.

>
> [...]

Have you considered switching to Matrix? It's federated, much like 
e-mail. It's censorship resistant, in the sense that any participating 
homeserver keeps a copy of a room. And everyone can run their own 
homeserver in the Matrix network.


Rooms can be E2E encrypted. For an email list replacement this is 
probably not relevant, however any person-2-person communication would 
benefit from being encrypted.


Synapse is the currently best developed home server that implements the 
Matrix specification. It's much easier to run than an email server + 
mailing list combo.


Much like E-Mail and IRC, there is a huge ecosystem of Matrix clients to 
choose from.


I'm aware the UI of most Matrix clients is more suitable for a chat 
system than lengthy email discussions. However, thanks to "threads", 
there is no reason it could be used like that.


https://matrix.org/
https://github.com/matrix-org/synapse
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] a simple and easy-to-remember personalized mnemonic generation scheme

[symphonicbtc via bitcoin-dev]

Hi Joe,

Happy to see engagement in evolving wallet systems. Unfortunately, BIP39 was 
devised precisely to avoid users picking their own phrases, as that is 
extremely insecure and cannot be expected to generate sufficient entropy to 
protect coins. Humans are inherently bad sources of randomness - all mnemonic 
systems need to be randomly generated.

If you are interested in continuing development in this area, you could try 
devising a system that generates readable sentences as mnemonics. I'm not sure 
if this would work in Chinese, but in English I feel it would be possible.

Symphonic
--- Original Message ---
On Monday, November 6th, 2023 at 8:57 AM, Joe via bitcoin-dev 
 wrote:

> hello,I'm Joe.I have a simple and easy-to-remember personalized mnemonic 
> generation scheme. Users can customize any sentence, support multiple 
> languages without language restrictions, map out the corresponding mnemonic, 
> and thus replace the mnemonic's memory.
> This is an upgraded version based on the BIP-39 proposals, making it easier 
> and more effective for users to obtain their mnemonics, without worrying 
> about forgetting the mnemonic, or even without having to write down the 
> mnemonic. It only requires the user to remember the customized sentence.
> The principle of the code mainly involves processing the user-defined 
> sentence with the sha256 algorithm to generate corresponding entropy, and 
> then obtaining the corresponding mnemonic through entropy. This method is 
> fully compatible with the bip39 proposals.
>
> Reference implementation: https://github.com/zhouxiaofeng-zxf/nico
> ---
>
> https://wx.mail.qq.com/home/index?t=readmail_businesscard_midpage&nocheck=true&name=%E5%91%A8%E5%B0%8F%E9%A3%8E&icon=https%3A%2F%2Fthirdqq.qlogo.cn%2Fg%3Fb%3Doidb%26k%3DEv5NJKUtibRbtmoRaiaRpwyQ%26s%3D0&mail=284282567%40qq.com&code=_hPTMDC-gCCAcZWvOYp01JoWs1wxiWlGQz-q6KHJdLipyQjWY_sAk84MW0qsHdUyKko6M2ebAjVsOC7gHSenPQ
> 周小风
> 284282...@qq.com___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Ademan via bitcoin-dev]

Hi Bryan,

I don't really want my first (and last?) devlist message to be a fairly
off-the-cuff post on this topic, but here we go anyway.

At the risk of sounding like a nostr evangelist (I promise I'm not), I want
to suggest nostr as a potential replacement to the mailing list. A decent
chunk of software would need to be written, but none of the alternatives
seem particularly attractive to me. I particularly dislike the idea of
locking into a single siloed forum service like the bitcointalk forums. I
realize I may be in the minority of course.


Nostr enables the ML team to outsource all of its biggest burdens, if it
chooses:

- mail server blocking is N/A to nostr

- Hosting costs are completely outsourced unless the ML team chooses to
host a relay.

- Archives and web portal access can be similarly outsourced because any
nostr archive is self-authenticating.

- The ML team can also choose to completely outsource moderation, as nostr
is (more or less) permissionless by nature.
  I understand if there is a "blessed" communication system, the ML team
would probably prefer to keep it high quality. To that end there are
proposals for proof-of-work, and web of trust based blocklists for nostr
which are optional for end users. There are other options such as the
"moderated communities" proposal which would provide tighter control.


On the user side, the optional moderation is very attractive, allowing
controversial threads to exist and continue, without requiring everyone to
see them.


The following do not currently exist (to my knowledge) and would need to be
implemented to meet the ML's requirements:

- an email gateway to satisfy the bulk of existing ML subscribers
  This reintroduces issues with mail server blocking of course.
- a long-form oriented nostr client (current plain text clients could be
used in the meantime)

That admittedly is quite a lot of work, but the second item can be
deferred, and the first is not particularly technically challenging, the
complications are all on the administration side.

I expect some reflexive NACKs based on the immaturity of the ecosystem but
if we have months to prepare, I believe the core requirements can be
solidly satisfied in time, the rest can be developed over time, and I
believe the advantages are worth careful consideration.

Cheers,
Dan

On Tue, Nov 7, 2023 at 9:38 AM Bryan Bishop via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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 somewhere else. We temporarily
> avoided that, but recently LF has informed a moderator that they will cease
> hosting any mailing lists later this year.
>
> In this email, we will go over some of the history, options, and invite
> discussion ahead of the cutoff. We have some ideas but want to solicit
> feedback and proposals.
>
> Background
> ==
>
> The bitcoin-dev mailing list was originally hosted on Sourceforge.net. The
> bitcoin development mailing list has been a source of proposals, analysis,
> and developer discussion for many years in the bitcoin community, with many
> thousands of participants. Later, the mailing list was migrated to the
> Linux Foundation, and after that OSUOSL began to help.
>
> Linux Foundation first asked us to move the mailing list in 2017. They
> internally attempted to migrate all LF mailing lists from mailman2 to
> mailman3, but ultimately gave up. There were reports of scalability issues
> with mailman3 for large email communities. Ours definitely qualifies as..
> large.
>
> 2019 migration plan: LF was to turn off mailman and all lists would
> migrate to the paid service provider groups.io. Back then we were given
> accounts to try the groups.io interface and administration features.
> Apparently we were not the only dev community who resisted change. To our
> surprise LF gave us several years of reprieve by instead handing the
> subdomain and server-side data to the non-profit OSUOSL lab who instead
> operated mailman2 for the past ~4 years.
>
> OSUOSL has for decades been well known for providing server infrastructure
> for Linux and Open Source development so they were a good fit. This however
> became an added maintenance burden for the small non-profit with limited
> resources. Several members of the Bitcoin dev community contributed funding
> to the lab in support of their Open Source development infrastructure
> goals. But throwing money at the problem isn’t going to fix the ongoing
> maintenance burden created by antiquated limitations of mailman2.
>
> Permalinks
> ==
>
> Linux Foundation has either offered or agreed to maintain archive
> permalinks so that content of historic importance is not lost. Fortunately
> for us while lists.linuxfoundation.org m

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

[Andrew Chow via bitcoin-dev]

Thanks for writing this up.

I would prefer that we continue to have a mailing list where email is a 
functional and first class user interface. So that would be to migrate 
to groups.io or Google Groups. I think Google Groups is probably the 
better choice of the two.

Although there are concerns that Google would shut down Google Groups or 
specifically target a bitcoin-dev group, I think both are unlikely to 
happen. Both Chromium and Android use Google Groups for their mailing 
lists, so unless those go somewhere else, I doubt Google would 
unceremoniously kill Google Groups. As for shutting down a bitcoin-dev 
group specifically, given that there appears to be several thousand 
groups whose sole purpose is to distribute spam, I don't think Google is 
in the habit of shutting down groups.

Regardless of what we do, there's always the risk that someone will shut 
down or stop maintaining the servers for any discussion medium. Even 
self hosting requires someone to keep the servers up and do maintenance, 
and that person (or people) could get bored of it, run out of money, get 
hit by a bus, etc. We're experiencing that right now with the Linux 
Foundation, and I don't think fear of that should prevent us from moving 
to a different third party host.


Andrew Chow

On 11/07/2023 10:37 AM, Bryan Bishop via bitcoin-dev wrote:
> 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 somewhere else. We 
> temporarily avoided that, but recently LF has informed a moderator that 
> they will cease hosting any mailing lists later this year.
> 
> In this email, we will go over some of the history, options, and invite 
> discussion ahead of the cutoff. We have some ideas but want to solicit 
> feedback and proposals.
> 
> Background
> ==
> 
> The bitcoin-dev mailing list was originally hosted on Sourceforge.net. 
> The bitcoin development mailing list has been a source of proposals, 
> analysis, and developer discussion for many years in the bitcoin 
> community, with many thousands of participants. Later, the mailing list 
> was migrated to the Linux Foundation, and after that OSUOSL began to help.
> 
> Linux Foundation first asked us to move the mailing list in 2017. They 
> internally attempted to migrate all LF mailing lists from mailman2 to 
> mailman3, but ultimately gave up. There were reports of scalability 
> issues with mailman3 for large email communities. Ours definitely 
> qualifies as.. large.
> 
> 2019 migration plan: LF was to turn off mailman and all lists would 
> migrate to the paid service provider groups.io . Back 
> then we were given accounts to try the groups.io  
> interface and administration features. Apparently we were not the only 
> dev community who resisted change. To our surprise LF gave us several 
> years of reprieve by instead handing the subdomain and server-side data 
> to the non-profit OSUOSL lab who instead operated mailman2 for the past 
> ~4 years.
> 
> OSUOSL has for decades been well known for providing server 
> infrastructure for Linux and Open Source development so they were a good 
> fit. This however became an added maintenance burden for the small 
> non-profit with limited resources. Several members of the Bitcoin dev 
> community contributed funding to the lab in support of their Open Source 
> development infrastructure goals. But throwing money at the problem 
> isn’t going to fix the ongoing maintenance burden created by antiquated 
> limitations of mailman2.
> 
> Permalinks
> ==
> 
> Linux Foundation has either offered or agreed to maintain archive 
> permalinks so that content of historic importance is not lost. 
> Fortunately for us while lists.linuxfoundation.org 
>  mailman will go down, they have 
> agreed the read-only pipermail archives will remain online. So all old 
> URLs will continue to remain valid. However, the moderators strongly 
> advise that the community supplements with public-inbox instances to 
> have canonical archive urls that are separate from any particular email 
> software host.
> 
> Public-Inbox
> 
> 
> https://public-inbox.org/README.html 
> 
> “Public Inbox” decentralized archiving - no matter what mailing list 
> server solution is used, anyone can use git to maintain their own 
> mailing list archive and make it available to read on the web.
> 
> Public Inbox is a tool that you can run yourself. You can transform your 
> mbox file and it makes it browsable and viewable online. It commits 
> every post to a git repository. It's kind of like a decentralized mail 
> archiving tool. Anyone can publish the mail archive to any web server 
> they wi

Re: [bitcoin-dev] [Lightning-dev] OP_Expire and Coinbase-Like Behavior: Making HTLCs Safer by Letting Transactions Expire Safely

[Antoine Riard via bitcoin-dev]

Hi Zeeman,

> Neither can Bob replace-recycle out the commitment transaction itself,
because the commitment transaction is a single-input transaction, whose
sole input requires a signature from
> Bob and a signature from Carol --- obviously Carol will not cooperate on
an attack on herself.

The replacement cycling happens on the commitment transaction spend itself,
not the second stage, which is effectively locked until block 100.

If the commitment transaction is pre-signed with 0 sat / vb and all the
feerate / absolute fee is provided by a CPFP on one of the anchor outputs,
Bob can replace the CPFP itself. After replacement of its child, the
commitment transaction has a package feerate of 0 sat / vb and it will be
trimmed out of the mempool.

This is actually the scenario tested here on the nversion = 3 new mempool
policy branch  (non-deployed yet):
https://github.com/ariard/bitcoin/commits/2023-10-test-mempool-2

As of today commitment transactions might not propagate if dynamic mempool
min fee is above pre-signed commitment transaction, which is itself unsafe.
I think this behavior can currently be opportunistically exploited by
attackers.

In a post-package relay world, I think this is possible. And that
replacement cycling attacks are breaking future dynamic fee-bumping of
pre-signed transactions concerns me a lot.

Best,
Antoine

Le mar. 7 nov. 2023 à 11:12, ZmnSCPxj  a écrit :

> Good morning Antoine,
>
>
> > Once the HTLC is committed on the Bob-Caroll link, Caroll releases the
> preimage off-chain to Bob with an `update_fulfill_htlc` message, though Bob
> does _not_ send back his signature for the updated channel state.
> >
> > Some blocks before 100, Caroll goes on-chain to claim the inbound HTLC
> output with the preimage. Her commitment transaction propagation in network
> mempools is systematically "replaced cycled out" by Bob.
>
> I think this is impossible?
>
> In this scenario, there is an HTLC offered by Bob to Carol.
>
> Prior to block 100, only Carol can actually create an HTLC-success
> transaction.
> Bob cannot propagate an HTLC-timeout transaction because the HTLC timelock
> says "wait till block 100".
>
> Neither can Bob replace-recycle out the commitment transaction itself,
> because the commitment transaction is a single-input transaction, whose
> sole input requires a signature from Bob and a signature from Carol ---
> obviously Carol will not cooperate on an attack on herself.
>
> So as long as Carol is able to get the HTLC-success transaction confirmed
> before block 100, Bob cannot attack.
> Of course, once block 100 is reached, `OP_EXPIRE` will then mean that
> Carol cannot claim the fund anymore.
>
> Regards,
> ZmnSCPxj
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] a simple and easy-to-remember personalized mnemonic generation scheme

[Joe via bitcoin-dev]

hello,I'm Joe.I have a simple and easy-to-remember personalized mnemonic 
generation scheme. Users can customize any sentence, support multiple languages 
without language restrictions, map out the corresponding mnemonic, and thus 
replace the mnemonic's memory.
This is an upgraded version based on the BIP-39 proposals, making it easier and 
more effective for users to obtain their mnemonics, without worrying about 
forgetting the mnemonic, or even without having to write down the mnemonic. It 
only requires the user to remember the customized sentence.
The principle of the code mainly involves processing the user-defined sentence 
with the sha256 algorithm to generate corresponding entropy, and then obtaining 
the corresponding mnemonic through entropy. This method is fully compatible 
with the bip39 proposals.

Reference implementation:  https://github.com/zhouxiaofeng-zxf/nico


??
284282...@qq.com



 ___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Bryan Bishop via bitcoin-dev]

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 somewhere else. We temporarily
avoided that, but recently LF has informed a moderator that they will cease
hosting any mailing lists later this year.

In this email, we will go over some of the history, options, and invite
discussion ahead of the cutoff. We have some ideas but want to solicit
feedback and proposals.

Background
==

The bitcoin-dev mailing list was originally hosted on Sourceforge.net. The
bitcoin development mailing list has been a source of proposals, analysis,
and developer discussion for many years in the bitcoin community, with many
thousands of participants. Later, the mailing list was migrated to the
Linux Foundation, and after that OSUOSL began to help.

Linux Foundation first asked us to move the mailing list in 2017. They
internally attempted to migrate all LF mailing lists from mailman2 to
mailman3, but ultimately gave up. There were reports of scalability issues
with mailman3 for large email communities. Ours definitely qualifies as..
large.

2019 migration plan: LF was to turn off mailman and all lists would migrate
to the paid service provider groups.io. Back then we were given accounts to
try the groups.io interface and administration features. Apparently we were
not the only dev community who resisted change. To our surprise LF gave us
several years of reprieve by instead handing the subdomain and server-side
data to the non-profit OSUOSL lab who instead operated mailman2 for the
past ~4 years.

OSUOSL has for decades been well known for providing server infrastructure
for Linux and Open Source development so they were a good fit. This however
became an added maintenance burden for the small non-profit with limited
resources. Several members of the Bitcoin dev community contributed funding
to the lab in support of their Open Source development infrastructure
goals. But throwing money at the problem isn’t going to fix the ongoing
maintenance burden created by antiquated limitations of mailman2.

Permalinks
==

Linux Foundation has either offered or agreed to maintain archive
permalinks so that content of historic importance is not lost. Fortunately
for us while lists.linuxfoundation.org mailman will go down, they have
agreed the read-only pipermail archives will remain online. So all old URLs
will continue to remain valid. However, the moderators strongly advise that
the community supplements with public-inbox instances to have canonical
archive urls that are separate from any particular email software host.

Public-Inbox


https://public-inbox.org/README.html

“Public Inbox” decentralized archiving - no matter what mailing list server
solution is used, anyone can use git to maintain their own mailing list
archive and make it available to read on the web.

Public Inbox is a tool that you can run yourself. You can transform your
mbox file and it makes it browsable and viewable online. It commits every
post to a git repository. It's kind of like a decentralized mail archiving
tool. Anyone can publish the mail archive to any web server they wish.

We should try to have one or more canonical archives that are served using
public-inbox. But it doesn't matter if these are lost because anyone else
can archive the mailing list in the same way and re-publish the archives.

These git commits can also be stamped using opentimestamps, inserting their
hashes into the bitcoin blockchain.

LKML mailing list readers often use public-inbox's web interface, and they
use the reply-to headers to populate their mail client and reply to threads
of interest. This allows their reply to be properly threaded even if they
were not a previous subscriber to that mailing list to receive the headers.

public-inbox makes it so that it doesn't really matter where the list is
hosted, as pertaining to reading the mailing list. There is still a
disruption if the mailing list goes away, but the archives live on and then
people can post elsewhere. The archive gets disconnected from the mailing
list host in terms of posting. We could have a few canonical URLs for the
hosts, separate from the mailing list server.

mailman problems


Over the years we have identified a number of problems with mailman2
especially as it pertains to content moderation. There are presently a
handful of different moderators, but mailman2 only has a single password
for logging into the email management interface. There are no moderator
audit logs to see which user (there is no concept of different users) acted
on an email. There is no way to mark an email as being investigated by one
or more of the moderators. Sometimes, while investigating the veracity of
an email, another moderator would come in and approv

Re: [bitcoin-dev] ossification and misaligned incentive concerns

[JK via bitcoin-dev]

With an enormous annual inflation rate at the beginning, stakeholders 
were able to survive such a harsh for them phase only because of the 
system's expansion where "numbers go up" (e.g., almost no one from 
outside Turkey would like to buy and just hold the turkish lira).


Now we are in a completely different situation, without such room as 
before because we are approaching the saturation of the system (and 
"Change the code, not the climate" action assures us of it).


Unfortunately, noone can predict everything decades ahead, and the 
system is designed in a way (incorrectly, no need to sugarcoat it) that 
with each halving, we shift from one extreme (edge case) to the opposite 
(from infinite inflation to zero inflation). We move along this axis 
without any control, without any feedback. If anything is controversial 
here, it's this fact. And that means: favoritism of one group over 
another, with clear conflict of interest.


It's a truism to say that stakeholders want transacting users to pay for 
Bitcoin's security, and transacting users want stakeholders to pay for 
Bitcoin's security. And this has been the case for many years - yes, as 
active users, we were all free-riders, paying almost nothing for 
transactions, with terawatt-hours annually dedicated to the system's 
operation.


And there's really no better evidence for what I've written above than 
the storm that erupted due to high fees caused by Ordinals - even here, 
even with ideas to censor the paid transactions...


I have to agree with Peter Todd: "21 million is a stupid meme." ;)
Yes, it's a harmful, silly meme that has turned everything upside down...

Because we realize that "Houston, we have a problem..." - but by 
promoting this meme, we've created a situation where more controversial 
is not the problem itself, but talking about it...


Overtaxed active users will not pay endlessly for the entire network's 
security, including "free lunches" for passive free-riders - that's as 
clear as crystal.


And it's impossible to build a healthy second layer if the first layer 
isn't healthy.


By the way, the first layer may become doubly unhealthy at some point 
due to the threat from quantum computers.
A hard fork to save Bitcoin from a future quantum threat will be 
instantly accepted, without any discussion.

And this might be the only chance to fix both issues at once.

If we introduce a change involving delay of the halving by another 4 
years, but only in case of a 4-years long network regression, we finally 
have a free market with an unpredictable variable where passive users 
won't become free riders. The new and old code will be perfectly 
compatible with each other until such a critical event occurs.


And this is a critical event with no doubt, because a 4-year network 
regression caused by an earlier halving, doomed yet by every next 
halving - is a slippery slope, it's the end of the Store-of-Value story 
(as I demonstrated you above with the fate of rai stones), and 
unfortunately, probably the end of Bitcoin (at least in the form we've 
been dreaming of all along...)



W dniu 07.11.2023 o 09:58, vju...@gazeta.pl pisze:
 > Imagine a system that tries to maintain a constant level of 
difficulty and reacts flexibly to changes in difficulty, by modulating 
the block reward level accordingly (using negative feedback).
This is exactly what I did, when experimenting with LN-based mining. CPU 
power was too low to get a full block reward out of that. But getting 
single millisatoshis from a channel partner? This is possible, and I 
started designing my model from that assumption. Also, because channel 
partner usually don't want to explicitly pay, I created it in a form of 
"LN transaction fee discount". Which means, a CPU miner just received 
cheaper LN transactions through the channel partner, instead of getting 
paid explicitly. Which also caused better network connectivity, because 
then you have an upper bound for your mining (it won't be cheaper LN 
transaction than for free). Which means, if you mine so many shares, 
that you have free LN transactions, then you have to sell them, or open 
another channel, and then instead of having "one channel with free 
transactions", you have many.

 > The free market is more important than finite supply.
I would say, the backward compatibility is more important than increased 
(no matter if still constant or not) supply. Which means, you can 
"increase" the supply, just by introducing millisatoshis on-chain. Or 
add any "tail supply", or anything like that, what was discussed in the 
past. The only thing that matters is: can you make it compatible with 
the current system? Hard-fork will be instantly rejected, without any 
discussion. Soft-fork will be stopped at best, exactly in the same way, 
how other soft-fork proposals were stopped, when achieving consensus was 
hard, and the topic was controversial. So, what is left? Of course 
no-forks and second layers. This is the only 

Re: [bitcoin-dev] Proposed BIP for MuSig2 Descriptors

[Salvatore Ingala via bitcoin-dev]

Hi Andrew,

Thank you for putting this together; these standards will be of great
help for implementations.

The only concern I have is about the utility of supporting KEY
expressions inside musig to contain ranged derivations with `/*`.

Consider a wallet described as follows:

  musig(key1/<0;1>/*, key2/<0;1>/*, ..., keyN/<0;1>/*)

With such a setup, for each input being spent, each signer is required
to derive the child xpub for each key, and then execute the KeyAgg
algorithm [1] (which includes N scalar multiplications).

Instead, a policy like:

  musig(key1, key2, ..., keyN)/<0;1>/*

is more succinct, and KeyAgg is executed only once for all the inputs.
I think the performance impact is substantial for signing devices.

Therefore, unless there are known use cases, I would suggest keeping
the standard minimal and supporting only the second form, avoiding
both the performance overhead and the additional complexity when
writing descriptor parsers.

If, on the contrary, there are legitimate use cases, a discussion
about them (and the above mentioned tradeoffs) might be worth adding
to the BIP proposal.

Best,
Salvatore


[1] - BIP-327 MuSig2: https://github.com/bitcoin/bips/blob/master/bip-0327
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] ossification and misaligned incentive concerns

[vjudeu via bitcoin-dev]

> Imagine a system that tries to maintain a constant level of difficulty and 
> reacts flexibly to changes in difficulty, by modulating the block reward 
> level accordingly (using negative feedback).
 
This is exactly what I did, when experimenting with LN-based mining. CPU power 
was too low to get a full block reward out of that. But getting single 
millisatoshis from a channel partner? This is possible, and I started designing 
my model from that assumption. Also, because channel partner usually don't want 
to explicitly pay, I created it in a form of "LN transaction fee discount". 
Which means, a CPU miner just received cheaper LN transactions through the 
channel partner, instead of getting paid explicitly. Which also caused better 
network connectivity, because then you have an upper bound for your mining (it 
won't be cheaper LN transaction than for free). Which means, if you mine so 
many shares, that you have free LN transactions, then you have to sell them, or 
open another channel, and then instead of having "one channel with free 
transactions", you have many.
 
> The free market is more important than finite supply.
 
I would say, the backward compatibility is more important than increased (no 
matter if still constant or not) supply. Which means, you can "increase" the 
supply, just by introducing millisatoshis on-chain. Or add any "tail supply", 
or anything like that, what was discussed in the past. The only thing that 
matters is: can you make it compatible with the current system? Hard-fork will 
be instantly rejected, without any discussion. Soft-fork will be stopped at 
best, exactly in the same way, how other soft-fork proposals were stopped, when 
achieving consensus was hard, and the topic was controversial. So, what is 
left? Of course no-forks and second layers. This is the only way, that is 
wide-open today, and which requires no support from the community. And that's 
why Ordinals are so strong: because they are a no-fork. Better or worse 
designed, it doesn't matter, but still a no-fork. Which means, they exist in 
the wild, no matter if you like them or not.___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] OP_Expire and Coinbase-Like Behavior: Making HTLCs Safer by Letting Transactions Expire Safely

[Antoine Riard via bitcoin-dev]

> I think you are misunderstanding a key point to my OP_Expire proposal:
because
> the ability to spend the preimage branch of the HTLC goes away when the
refund
> branch becomes available, replacing cycling or any similar technique
becomes
> entirely irrelevant.

> The situation where Carol prevents Bob from learning about the preimage
in time
> simply can't happen: either Carol collects the HTLC with knowledge of the
> preimage, by spending it in a transaction mined prior to the expiration
time
> and ensuring that Bob learns the preimage from the blockchain itself. Or
the
> HTLC expires and Bob can use the refund branch at his leisure.

I think I understand the semantic of the OP_Expire proposal overall
correctly, however I'm not sure it prevents replacing cycling or any
similar adversarial technique, as the forwarding node might be the attacker
in some scenario.

Consider the following: you have Alice, Bob, Caroll sharing lightning
channels.

Alice forwards a HTLC of 1 BTC to Caroll by the intermediary of Bob.

On the Bob-Caroll link, the HTLC expires at block 100.

According to OP_Expire semantics, Caroll shouldn't be able to claim the
htlc-preimage spends on the Bob-Caroll link, after block 100.

However, this situation offers the ability to Bob the routing node to steal
HTLC payment between Alice and Caroll.

Once the HTLC is committed on the Bob-Caroll link, Caroll releases the
preimage off-chain to Bob with an `update_fulfill_htlc` message, though Bob
does _not_ send back his signature for the updated channel state.

Some blocks before 100, Caroll goes on-chain to claim the inbound HTLC
output with the preimage. Her commitment transaction propagation in network
mempools is systematically "replaced cycled out" by Bob.

At block 100, Caroll cannot claim the payment sent to her by Alice.

Bob claims the htlc-refund path on the Bob-Caroll link and claims the
htlc-preimage path on the Alice-Bob link, as such making a gain of 1 BTC.

If Caroll is a lightning mobile client, it is easy for Bob to claim
publicly that the lack of success in signature exchange to update channels
state is a liveliness mistake of her own.

Assuming this advanced scenario is correct, I'm not sure the OP_Expire
proposal is substantially fixing all the adversarial replacement cycling
situations.

Best,
Antoine

Le sam. 4 nov. 2023 à 07:26, Peter Todd  a écrit :

> On Fri, Nov 03, 2023 at 05:25:24AM +, Antoine Riard wrote:
> > > To be clear, are you talking about anchor channels or non-anchor
> channels?
> > > Because in anchor channels, all outputs other than the anchor outputs
> > provided
> > > for fee bumping can't be spent until the commitment transaction is
> mined,
> > which
> > > means RBF/CPFP isn't relevant.
> >
> > I think the distinction is irrelevant here as pre-anchor channel if I
> have
> > one spendable HTLC output spend and I gain knowledge of my counterparty
> > commitment transaction from networks mempools, the spend is malleable and
> > can be used as a CPFP. If you assume anchor channels, you have 2 anchor
> > outputs as long both parties have balance outputs or pending HTLCs.
> >
> > Though pre-anchor, legacy channels the counterparty commitment
> transaction
> > will have to be attached with a fee under min mempool fee for the
> > replacement cycling to happen, and let network congestion happen.
>
> I think you are misunderstanding a key point to my OP_Expire proposal:
> because
> the ability to spend the preimage branch of the HTLC goes away when the
> refund
> branch becomes available, replacing cycling or any similar technique
> becomes
> entirely irrelevant.
>
> The situation where Carol prevents Bob from learning about the preimage in
> time
> simply can't happen: either Carol collects the HTLC with knowledge of the
> preimage, by spending it in a transaction mined prior to the expiration
> time
> and ensuring that Bob learns the preimage from the blockchain itself. Or
> the
> HTLC expires and Bob can use the refund branch at his leisure.
>
> > I think the more interesting case is a future world with package relay
> > deployed at the p2p level and anchor output on the lightning-side. Here
> the
> > most advanced replacement as illustrated in the test can happen (where
> > commitment has an anchor output - see L125).
>
> Again, with OP_Expire, whether or not package relay or anything similar
> exists
> is irrelevant. Replacement cycling is totally useless because there is a
> defined time window in which the HTLC can be spent with the preimage, after
> which only the refund branch can be used.
>
> Indeed, with OP_Expire Lightning nodes will no longer need to monitor
> mempools
> for preimages at all. If the preimage is used, it is guaranteed to end up
> in
> the chain, and the Lightning node is guaranteed to see it provided they
> have
> access to up-to-date blockchain data.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
___
bitcoin-dev mailing 

Re: [bitcoin-dev] [Lightning-dev] OP_Expire and Coinbase-Like Behavior: Making HTLCs Safer by Letting Transactions Expire Safely

[ZmnSCPxj via bitcoin-dev]

Good morning Antoine,


> Once the HTLC is committed on the Bob-Caroll link, Caroll releases the 
> preimage off-chain to Bob with an `update_fulfill_htlc` message, though Bob 
> does _not_ send back his signature for the updated channel state.
> 
> Some blocks before 100, Caroll goes on-chain to claim the inbound HTLC output 
> with the preimage. Her commitment transaction propagation in network mempools 
> is systematically "replaced cycled out" by Bob.

I think this is impossible?

In this scenario, there is an HTLC offered by Bob to Carol.

Prior to block 100, only Carol can actually create an HTLC-success transaction.
Bob cannot propagate an HTLC-timeout transaction because the HTLC timelock says 
"wait till block 100".

Neither can Bob replace-recycle out the commitment transaction itself, because 
the commitment transaction is a single-input transaction, whose sole input 
requires a signature from Bob and a signature from Carol --- obviously Carol 
will not cooperate on an attack on herself.

So as long as Carol is able to get the HTLC-success transaction confirmed 
before block 100, Bob cannot attack.
Of course, once block 100 is reached, `OP_EXPIRE` will then mean that Carol 
cannot claim the fund anymore.

Regards,
ZmnSCPxj
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev