Without a performance requirement there is no reason you can’t store the BIP39
words in any order you want. So it’s certainly possible, just brute force the
recovery. If you have less than a second vs. a few days then it’s a different
question.
e
> On Jul 7, 2022, at 18:48, Bram Cohen via bitc
Part of the rules of my challenge is that the 'new' words need to be in the
same pool as the 'old' words, so any ordering is okay. Without that
requirement it's mathematically very straightforward.
On Thu, Jul 7, 2022 at 10:52 AM Pavol Rusnak wrote:
> There is. Just encode the index of permutati
Value is subjective, though a constraint of 1tx per 10 minutes seems unlikey to
create a fee of 5000x that of 5000tx. This is of course why I stated my
assumption. Yet this simple example should make clear that at some point a
reduction in confirmation rate reduces reward. Otherwise a rate of ze
On Thu, Jul 07, 2022 at 10:12:41AM -0400, Peter Todd via bitcoin-dev wrote:
> We should not imbue real technology with magical qualities.
That's much more fun if you invert it, and take it as a mission
statement. Advance technology sufficiently!
> The fact of the matter is that the present amount
>Billy,
>
>Proof of work and the difficulty adjustment function solve literally
everything you are talking about already.
>Bitcoin does not need active economic governanance by devs or meddlers.
>Please stop spamming this list with this nonsensical thread.
>
>Love,
>John
Sorry John, but this is a
The relationship between block size and fees is not remotely linear. In a
restricted environment, the fee rewards are much higher.
**the ones moving more sats will win the top spots and will pay as much as
is reasonable**
Smaller blocks produce better security for the network both in validation
It’s not clear how reducing block size changes the fee aspect of the block
reward. Assuming half the space implies twice the fee per avg tx the reward
remains constant.
Any additional cost of processing more or less bytes would not matter, because
of course this is just a cost that gets nulled
But this will require user to distinguish 12 words from error correcting words.
Which is another hassle.
On Thu, Jul 7, 2022, at 10:52 AM, Pavol Rusnak wrote:
> There is. Just encode the index of permutation used to scramble the otherwise
> sorted list. For 12 words you need to store 12! = ~32 b
> > We should not imbue real technology with magical qualities.
> Precisely. It is economic forces (people), not technology, that provide
security.
Yes, and these forces don't prevent double-spend / 51% attacks if the
amounts involved are greater than the incentives.
In addition to "utility", lo
There is. Just encode the index of permutation used to scramble the
otherwise sorted list. For 12 words you need to store 12! = ~32 bits so 3
words should be enough.
Repetitions make this more difficult, though.
On Thu 7. 7. 2022 at 19:41, Bram Cohen via bitcoin-dev <
bitcoin-dev@lists.linuxfound
On Thu, Jul 7, 2022 at 7:43 AM Anton Shevchenko via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> I made a python implementation for a different mnemonic encoding. The
> encoding requires user to remember words but not the order of those words.
> The code is open (MIT license) at h
> On Jul 7, 2022, at 07:13, Peter Todd via bitcoin-dev
> wrote:
>
> On Thu, Jul 07, 2022 at 02:24:39PM +0100, John Carvalho via bitcoin-dev
> wrote:
>> Billy,
>>
>> Proof of work and the difficulty adjustment function solve literally
>> everything you are talking about already.
>
> Unfortu
Hello,
I am new to this list, sorry if it's been discussed earlier.
I made a python implementation for a different mnemonic encoding. The encoding
requires user to remember words but not the order of those words.
The code is open (MIT license) at https://github.com/sancoder/noomnem
-- Anton She
It's the first time I read about the security budget and it definitely
sounds scary to me.
If it only takes a few million dollars to attack BTC and make it completely
unusable for one day, I suppose it's only a matter of time before some
hedge fund actually does it, using a short position to profit
Hi Damian,
Which specific part of the proposal do you think affects the legibility of the
blockchain and the fungibility of UTXOs? Please point out the relevant section
so that we can address your concerns.
Alfred
--- Original Message ---
On Sunday, July 3rd, 2022 at 3:17 PM, KING JAMES
.
>
> My thoughts on this are that we will need to periodically make some
> software change to adjust a *target amount of investment in security*,
> because the
>
I think perhaps you're underestimating the degree to which utility can be
added to the main chain to encourage fees.
For example, li
On Thu, Jul 07, 2022 at 02:24:39PM +0100, John Carvalho via bitcoin-dev wrote:
> Billy,
>
> Proof of work and the difficulty adjustment function solve literally
> everything you are talking about already.
Unfortunately you are quite wrong: the difficulty adjustment function merely
adjusts for cha
Billy,
Proof of work and the difficulty adjustment function solve literally
everything you are talking about already.
Bitcoin does not need active economic governanance by devs or meddlers.
Please stop spamming this list with this nonsensical thread.
Love,
John
On Thu, Jul 7, 2022 at 1:00 PM
> The primary mechanism we have to change how much security we have is to
> change the block size, which changes how much fees miners can collect each
> block. This isn't a linear thing. Its probably a parabola with a peak, where
> at that peak, making the block either smaller and larger would b
@Corey
> Currently there is zero feedback in the Bitcoin system between what we
might think is the optimum amount of security and what actually exists.
I basically agree with this. The pedantic part of my mind does want to
point out that the link between block subsidy and bitcoin's price does
ac
20 matches
Mail list logo
