On Fri, Sep 16, 2022 at 9:18 PM Antoine Riard via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hi Buck,
>
[...]
>
> I would vote against Slack. IRC is probably the best but maybe too high a
> barrier to entry? Publishing logs at least would counter concerns of it
> being
On Tue, Sep 13, 2022 at 6:03 PM Ryan Grant via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Mon, Sep 12, 2022 at 2:47 AM Buck O Perley via bitcoin-dev
> First just wanted to thank you
> for taking the initiative to
> > put this together. I think that as the community and
> >
This would be very useful for the Validating Lightning Signer project,
since we need to prove to a non-network connected signer that a UTXO has
not been spent. It allows the signer to make sure the channel is still
active.
( the related design doc is at
On Mon, May 17, 2021 at 11:47 PM ZmnSCPxj:
>
> When considering any new proof-of-foo, it is best to consider all effects
> until you reach the base physics of the arrow of time, at which point you
> will realize it is ultimately just another proof-of-work anyway.
>
Let's not simplify away
Hi Erik,
Here's a scheme I posted here a few years ago, which smoothly transitions
using geometric mean chain weight / difficulty:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-November/015236.html
On Fri, Apr 16, 2021 at 11:08 PM Erik Aronesty via bitcoin-dev <
Dear ZmnSCPxj,
On Thu, Jan 14, 2021 at 4:28 PM ZmnSCPxj via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> The primary issue here is that we have a base assumption that the hardware
> wallet cannot be sophisticated enough to have Internet access; "do not
> enter seed words on an
I would suggest 50+ 6-sided dice rolls, giving about 128 bits of entropy.
Compared to a shuffle, it's easier to be sure that you got the right amount
of entropy, even if the dice are somewhat biased.
On Mon, Feb 4, 2019 at 2:33 PM James MacWhyte via bitcoin-dev <
Hi Omer,
Are there any candidates for non-interactive threshold signatures?
Interactive signatures are not very suitable for air-gapped use cases.
On Tue, Nov 27, 2018 at 11:18 AM Omer Shlomovits via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hello all,
>
> I am working for
"Peter Todd via bitcoin-dev" <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> On Wed, Nov 01, 2017 at 05:48:27AM +, Devrandom via bitcoin-dev wrote:
>>
>> Some quick thoughts...
>>
>> > Hi all,
>> >
>> > Feedback is welcome on
>
> Note how you're basically proposing for the block interval to be decreased,
>> which has security implications due to increased orphan rates.
>>
>
> Note that the total transaction rate and block size don't materially
> change, so I don't
> see why the orphan rate will change. Normal blocks
t; --
> Please do not email me anything that you are not comfortable also sharing with
> the NSA.
>
> On Oct 31, 2017, at 10:48 PM, Devrandom via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Hi all,
>
> Feedback is welcome on the draft below.
Hi all,
Feedback is welcome on the draft below. In particular, I want to see if
there is interest in further development of the idea and also interested in
any attack vectors or undesirable dynamics.
(Formatted version available here:
12 matches
Mail list logo
