Nostr notes by

📅 Original date posted:2019-02-06 📝 Original ...

2023-06-07T18:16:18Z

In reply to nevent1q…mjua
_________________________

📅 Original date posted:2019-02-06
📝 Original message:It's not quite enough to just do SHA512, you missed out this condition
(incredibly rare as it is):

> In case IL is 0 or ≥n, the master key is invalid.

Also I can't see how I would use this to seed a hardware wallet that
requires a BIP39 seed as mentioned in your abstract.

For both of those reasons, you may want to just invent/formalize a scheme
that takes Cards -> Entropy.
>From that Entropy one can generate BIP39, and non-BIP39 fans can just
continue, generate and store their root xprv.

Prior art: Note that Ian Coleman's BIP39 site already supports Cards (and
Dice), see the logic here:
https://github.com/iancoleman/bip39/blob/master/src/js/entropy.js

[image: image.png]

Note it detected "full deck". It also calculates the Total Bits of Entropy
and can handle card replacement and multiple decks.

PS, you're a bit out on your entropy calculation, log2(52!) ~= 225.58 bits,
not 219.

On Tue, 5 Feb 2019 at 02:08, Devrandom via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> 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 <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>>
>> James
>>
>>
>> On Sun, Feb 3, 2019 at 10:27 AM Ryan Havar via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> Conveniently a shuffled deck of cards also can serve as a physical
>>> backup which is easy to hide in plain sight with great plausible
>>> deniability.
>>>
>>
>> To make sure someone doesn't play with your cards and mix up the order,
>> use a permanent marker to draw a diagonal line on the side of the deck from
>> corner to corner. If the cards ever get mixed up, you can put them back in
>> order by making sure the diagonal line matches up.
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190206/ae1b7d9b/attachment-0001.html>;

📅 Original date posted:2018-01-24 📝 Original message:So, ...

2023-06-07T18:09:58Z

In reply to nevent1q…9ehw
_________________________

📅 Original date posted:2018-01-24
📝 Original message:So, OP, in your scenario, you have 1 transaction in the mempool, A, then
you want to spend the change before confirmation, so you broadcast a new
transaction, B, which replaces A.

> Because the size of the merged transaction is smaller than the original
transactions, unless there is a considerable feerate bump, this rule isn't
possible to observe.

I'm confused, the mempool only sees 1 transaction at a time, first A, then
later B. " the original transactions", plural, should not exist in the
mempool.

B's fee and rate needs to be larger than A's, but B will be greater than or
equal to A anyway. So, just increasing the fee rate will cause a larger fee
anyway.

Am I missing something?

On Wed, Jan 24, 2018 at 3:44 AM, Peter Todd via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> On Tue, Jan 23, 2018 at 10:49:34PM +0000, Gregory Maxwell via bitcoin-dev
> wrote:
> > On Tue, Jan 23, 2018 at 10:19 PM, Rhavar via bitcoin-dev
> > <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > > Interesting. I didn't think about this before, but it seems like
> bip125 is
> > > rather incentive incompatible right now? If we're assuming a
> competitive
> > > mempool, it really doesn't seem generally rational to accept a
> replacement
> > > transaction of a lower fee rate.
> >
> > BIP125 replacement requires that the fee rate increases. The text of
> > the BIP document is written in a confusing way that doesn't make this
> > clear.
>
> In fact I considered only requiring an increase in fee rate, based on the
> theory that if absolute fee went down, the transaction must be smaller and
> thus
> miners could overall earn more from the additional transactions they could
> fit
> into their block. But to do that properly requires considering whether or
> not
> that's actually true in the particular state the mempool as a whole
> happens to
> be in, so I ditched that idea early on for the much simpler criteria of
> both a
> feerate and absolute fee increase.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180124/398e0de6/attachment.html>;

📅 Original date posted:2018-01-22 📝 Original message:> ...

2023-06-07T18:09:55Z

In reply to nevent1q…fpfm
_________________________

📅 Original date posted:2018-01-22
📝 Original message:> So now I still owe John 1 BTC, however it's not immediately clear if it's
safe to send to him

If you spent your change from transaction A, that would be safe. There'd be
no way you John could end up with 2 BTC from you then.

On Mon, Jan 22, 2018 at 1:40 PM, Rhavar via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> So my half-baked idea is very simple:
>
> Allow users to merge multiple unconfirmed transactions, stripping
> extraneous inputs and change as they go.
>
> This is currently not possible because of the bip125 rule:
> "The replacement transaction pays an absolute fee of at least the sum paid
> by the original transactions."
>
> Because the size of the merged transaction is smaller than the original
> transactions, unless there is a considerable feerate bump, this rule isn't
> possible to observe.
>
>
> I my question is: is it possible or reasonable to relax this rule? If this
> rule was removed in its entirety, does it introduce any DoS vectors? Or can
> it be changed to allow my use-case?
>
>
> ---
> Full backstory: I have been trying to use bip125 (Opt-in Full
> Replace-by-Fee) to do "transaction merging" on the fly. Let's say that I
> owe John 1 bitcoin, and have promised to pay him immediately: Instead of
> creating a whole new transaction if I have an in-flight (unconfirmed)
> transaction, I can follow the rules of bip125 to create a replacement that
> accomplishes this goal.
>
> From a "coin selection" point of view, this was significantly easier than
> I had anticipated. I was able to encode the rules in my linear model and
> feed in all my unspent and in-flight transactions and it can solve it
> without difficulty.
>
> However, the real problem is tracking the mess. Consider this sequence of
> events:
> 1) I have unconfirmed transaction A
> 2) I replace it with B, which pays John 1 BTC
> 3) Transaction A gets confirmed
>
> So now I still owe John 1 BTC, however it's not immediately clear if
> it's safe to send to him without waiting $n transactions. However even
> for a small $n, this breaks my promise to pay him immediately.
>
> One possible solution is to only consider a transaction "replaceable" if
> it has change, so if the original transaction confirms -- payments can
> immediately be made that source the change, and provide safety in a reorg.
>
> However, this will only work <50% of the time for me (most transactions
> don't have change) and opens a pandora's box of complexity.
>
> There's a few other hacks you can do to make it work in a few more cases,
> but nothing that is realistic to expect anyone to implement any time soon.
>
> However, if there was a straight foward way to merge N unconfirmed
> transactions, it would be easy get into production, and potentially offer
> some pretty nice savings for everyone.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180122/b5749d54/attachment.html>;