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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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:
> 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
> 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
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
28 matches
Mail list logo
