Re: [bitcoin-dev] Playing with full-rbf peers for fun and L2s security

[alicexbt via bitcoin-dev]

Hi Peter,

> Point is, the attacker is thousands of UTXOs can also DoS rounds by simply
> failing to complete the round. In fact, the double-spend DoS attack requires
> more resources, because for a double-spend to be succesful, BTC has to be 
> spent
> on fees.
>
> It's just a fact of life that a motivated attacker can DoS attack Wasabi by
> spending money. That's a design choice that's serving them well so far.


There are 2 things:

1) Based on my understanding, round will not be aborted if a threshold is met 
for inputs and will continue irrespective of attacker trying different things 
in the initial phases of round. I need to confirm this by testing although not 
feeling well today so it can take a few days.

2) Points mentioned by Greg Sanders are reasonable: There can be a different 
'mempool view' for coordinator, users and attacker. Attacker could use minimum 
fee rate required for relay and this works differently when there is enough 
demand for blockspace.

Double spend attack requires only one laptop and a few UTXOs. Even if spent in 
some cases, would pay a few sats per transaction which won't be an issue for 
governments or competitors that normally perform such attacks.

The vulnerability reported is different from the things being discussed and 
hopefully I will do a public disclosure this month. I observed some interesting 
things which I wanted to discuss. Full RBF pull request is already merged in 
bitcoin core and available in bitcoin knots if some users want to experiment.


/dev/fd0

Sent with Proton Mail secure email.

--- Original Message ---
On Friday, July 8th, 2022 at 2:53 PM, Peter Todd  wrote:


> On Tue, Jul 05, 2022 at 08:46:51PM +, alicexbt wrote:
>
> > Hi Peter,
> >
> > > Note that Wasabi already has a DoS attack vector in that a participant 
> > > can stop
> > > participating after the first phase of the round, with the result that the
> > > coinjoin fails. Wasabi mitigates that by punishing participating in future
> > > rounds. Double-spends only create additional types of DoS attack that 
> > > need to
> > > be detected and punished as well - they don't create a fundamentally new
> > > vulerability.
> >
> > I agree some DoS vectors are already mitigated however punishment in this 
> > case will be difficult because the transaction is broadcasted after signing 
> > and before coinjoin tx broadcast.
> >
> > Inputs are already checked multiple times for double spend during coinjoin 
> > round: https://github.com/zkSNACKs/WalletWasabi/pull/6460
> >
> > If all the inputs in the coinjoin transaction that failed to relay are 
> > checked and one or more are found to be spent later, what will be punished 
> > and how does this affect the attacker with thousands of UTXOs or normal 
> > users?
>
>
> Point is, the attacker is thousands of UTXOs can also DoS rounds by simply
> failing to complete the round. In fact, the double-spend DoS attack requires
> more resources, because for a double-spend to be succesful, BTC has to be 
> spent
> on fees.
>
> It's just a fact of life that a motivated attacker can DoS attack Wasabi by
> spending money. That's a design choice that's serving them well so far.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] TAPLEAF_UPDATE_VERIFY covenant opcode

[Tim Ruffing via bitcoin-dev]

Hi aj,

I think there's another workaround for the x-only issue with
TAPLEAF_UPDATE_VERIFY.

So the opcode will need a function f that ensures that the new internal
key f(P'), where P' = P + X, has even y. You describe what happens for
the canonical choice of
f(P') = if has_even_y(P') then P' else -P'.

This leads to issues because negation turns around the signs of A and B
if say P' = A + B. Or more generally, negation is multiplicative
tweaking with a tweak -1, and that changes the coefficients of A und B.

But what if we use additive tweaking, which won't change the
coefficients? For example, you could try adding the generator until you
hit an even point, i.e., 
f(P') = if has_even_y(P') then P' else f(P' + G).

Then you may get a chain like
 * Pabc = A + B + C
 * Pab  = A + B      + 2G
* Pa = A + 2G + 1G = A + 3G

Pool members will simply need to track the accumulated tweak t and take
the tweak into account when signing. For example, A and B would sign
with t = 2 and A alone would sign with t = 3. 

This choice of f will succeed after 1 addition on average. (I don't
know if this can be proven but even if not, experiments show that it's
true and that's good enough.) So the actual running time is
probabilistic. I don't think that's an issue but if it is an issue,
other choices of f are possible, e.g., let the spender provide the
tweak t explicitly and set
f(P',t) = if 0 <= t < 128 and has_even_y(P'+tG) then P'+tG else fail.

This workaround is not exactly elegant either but it may be better than
the other suggestions.

Best,
Tim

On Thu, 2021-09-09 at 16:53 +1000, Anthony Towns via bitcoin-dev wrote:
> Moving on to the pooled scheme and actually updating the internal
> pubkey
> is, unfortunately, where things start to come apart. In particular,
> since taproot uses 32-byte x-only pubkeys (with implicit even-y) for
> the
> scriptPubKey and the internal public key, we have to worry about what
> happens if, eg, A,B,C and A+B+C all have even-more elegy, but
> (A+B)=(A+B+C)-C does
> not have even-y. In that case allowing C to remove herself from the
> pool,
> might result in switching from the scriptPubKey Qabc to the
> scriptPubKey
> Qab as follows:
> 
>  Qabc = (A+B+C) + H(A+B+C, (Sa, (Sb, Sc)))*G
>  Qab = -(A+B) + H( -(A+B), (Sa, Sb)*G
> 
> That's fine so far, but what happens if B then removes himself from
> the
> pool? You take the internal public key, which turns out to be -(A+B)
> since (A+B) did not have even y, and then subtract B, but that gives
> you
> -A-2B instead of just A. So B obtains his funds, but B's signature
> hasn't
> been cancelled out from the internal public key, so is still required
> in order to do key path spends, which is definitely not what we want.
> 
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] BIP draft: Half-Aggregation of BIP-340 Signatures

[Jonas Nick via bitcoin-dev]

Half-aggregation has been mentioned several times on this list in various
contexts. To have a solid basis for discussing applications of half-aggregation,
I think it's helpful to have a concrete specification of the scheme and a place
for collecting supplemental information like references to cryptographic
security proofs. You can find the BIP draft at

https://github.com/ElementsProject/cross-input-aggregation/blob/master/half-aggregation.mediawiki

Similar to BIP-340, this BIP draft specifies only the cryptographic scheme and
does not prescribe specific applications. It has not received an extensive
security review yet. Thanks to Elliott Jin and Tim Ruffing for the review so
far. One new feature that the specified scheme has is "incremental aggregation"
which allows aggregating additional BIP-340 signatures into an existing
half-aggregate signature.

While BIP-340 has a pseudocode specification and a reference implementation in
python, this BIP draft has a formal specification written in hacspec [0] and
auxiliary pseudocode. The formal specification is a mathematically precise
description of the scheme, which paves the way for computer-aided formal proofs.
Software tools ("proof assistants") allow proving properties about the formal
specification ("no integer overflow") and apply formal software verification
("implementation is behaviorally equivalent to the spec"). I don't have concrete
plans (nor the skillset) to use these techniques. Still, I think this is an
exciting area to explore because it has the potential to increase the Bitcoin
ecosystem's robustness significantly and has little downside. Since hacspec's
syntax is a subset of Rust's syntax, one can use the standard rust toolchain to
compile, execute and test the specification.

You can find a blog post that gives a broader context at
https://blog.blockstream.com/half-aggregation-of-bip-340-signatures/

[0] https://github.com/hacspec/hacspec
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin covenants are inevitable

[Erik Aronesty via bitcoin-dev]

On Thu, Jul 7, 2022 at 8:29 PM Eric Voskuil  wrote:

> 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 zero implies infinite reward.
>

Like i said, it's not linear.   So no, a rate of 0 does not imply an
infinite reward.  A number of papers on the Nash equilibrium of mining
rewards and block size have been written.   There are block sizes that
are optimal for fees, and they obviously not zero, where the system
collapses, and they are obviously not infinite... where all bidders pay 1
sat/byte.


>
> You cannot support the blanket statement (and absent any assumption) that
> lower confirmation rates produce “much higher fees” or “better security”.
>

You can look at the research and the history of zero-size block impact on
fees and see that this is true.



>
> What you call a “bidding war” is merely market pricing, as it occurs with
> any good. People *always* will pay as much as they will pay. This is
> tautological. What you cannot say is how much more someone will pay at any
> given time for any given good, until they have done it. And I’m pretty sure
> Bitcoin hasn’t done it.
>

If there is infinite supply, then there is zero value.   Infinite blocks
have lower fees.  This is impossible to argue against.


> You cannot prove what the price of anything will be, nor can any “papers”.
> The absurdity of S2F should have clearly demonstrated that by now. Value is
> an individual human preference.
>

A trivial example: block sizeof 10, and 10 people want to transact, all can
bid 1 SAT/byte, 2 tx are moving 100 mil sats, the other 8 are moving 10 mil
sats.   Block size of 2.  Now the two transactions moving 100 mil sats will
bid, they can easily pay 400 sats/byte.

You can show, from history, that when block sizes are more constrained, due
to the mining of zero byte blocks, total fees were higher.   People will
always pay for "next confirm" if the cost of that is very reasonable (less
than 0.1%).

>
> If everyone pays 1 sat, then either miners are profitable at 1 sat, or
> these people are not getting confirmed (economic rationality always
> assumed).
>

Yes, and if miners are not profitable at 1 sat, then they will not mine,
and the hash rate will drop.   And this reduces the security of the coin.
 Hashrate is an index of security.

But there is of course no real issue here. Simply fork off an inflation
> coin and test your theory. I mean, that’s the only way it can happen anyway.
>

I would argue inflation is not a good solution.   Instead, being cautious
about block-compressing tech, like mweb, and being more aggressive about
fee-driving tech, makes more sense .
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Playing with full-rbf peers for fun and L2s security

[Greg Sanders via bitcoin-dev]

The attacker isn't guaranteed to spend *any* funds to disrupt the protocol
indefinitely, that's the issue here. In this scenario, her input double
spend is at an impractical feerate, and is never included in a block,
sitting at the bottom of the mempool.

The other users' only practical choice is to double-spend their own input
to get their money back(at competitive rates much higher than the
attacker), or wait and hope you win a propagation race somewhere.



On Fri, Jul 8, 2022 at 10:53 AM Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Tue, Jul 05, 2022 at 08:46:51PM +, alicexbt wrote:
> > Hi Peter,
> >
> > > Note that Wasabi already has a DoS attack vector in that a participant
> can stop
> > > participating after the first phase of the round, with the result that
> the
> > > coinjoin fails. Wasabi mitigates that by punishing participating in
> future
> > > rounds. Double-spends only create additional types of DoS attack that
> need to
> > > be detected and punished as well - they don't create a fundamentally
> new
> > > vulerability.
> >
> > I agree some DoS vectors are already mitigated however punishment in
> this case will be difficult because the transaction is broadcasted after
> signing and before coinjoin tx broadcast.
> >
> > Inputs are already checked multiple times for double spend during
> coinjoin round: https://github.com/zkSNACKs/WalletWasabi/pull/6460
> >
> > If all the inputs in the coinjoin transaction that failed to relay are
> checked and one or more are found to be spent later, what will be punished
> and how does this affect the attacker with thousands of UTXOs or normal
> users?
>
> Point is, the attacker is thousands of UTXOs can also DoS rounds by simply
> failing to complete the round. In fact, the double-spend DoS attack
> requires
> more resources, because for a double-spend to be succesful, BTC has to be
> spent
> on fees.
>
> It's just a fact of life that a motivated attacker can DoS attack Wasabi by
> spending money. That's a design choice that's serving them well so far.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> ___
> 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] Playing with full-rbf peers for fun and L2s security

[Peter Todd via bitcoin-dev]

On Tue, Jul 05, 2022 at 08:46:51PM +, alicexbt wrote:
> Hi Peter,
> 
> > Note that Wasabi already has a DoS attack vector in that a participant can 
> > stop
> > participating after the first phase of the round, with the result that the
> > coinjoin fails. Wasabi mitigates that by punishing participating in future
> > rounds. Double-spends only create additional types of DoS attack that need 
> > to
> > be detected and punished as well - they don't create a fundamentally new
> > vulerability.
> 
> I agree some DoS vectors are already mitigated however punishment in this 
> case will be difficult because the transaction is broadcasted after signing 
> and before coinjoin tx broadcast.
> 
> Inputs are already checked multiple times for double spend during coinjoin 
> round: https://github.com/zkSNACKs/WalletWasabi/pull/6460
> 
> If all the inputs in the coinjoin transaction that failed to relay are 
> checked and one or more are found to be spent later, what will be punished 
> and how does this affect the attacker with thousands of UTXOs or normal users?

Point is, the attacker is thousands of UTXOs can also DoS rounds by simply
failing to complete the round. In fact, the double-spend DoS attack requires
more resources, because for a double-spend to be succesful, BTC has to be spent
on fees.

It's just a fact of life that a motivated attacker can DoS attack Wasabi by
spending money. That's a design choice that's serving them well so far.

-- 
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] No Order Mnemonic

[James MacWhyte via bitcoin-dev]

> What do you do if the "first" word (of 12), happens to be the last word in
> the list alphabetically?
>

That couldn't happen. If one word is the very last from the wordlist, it
would end up at the end of your mnemonic once you rearrange your 12 words
alphabetically.

However!

(@vjudeu) Choosing 11 random words and then sorting them alphabetically
before assigning a checksum would reduce entropy considerably. If you think
about it, to bruteforce the entire keyspace one would only need to come up
with every possible combination of 11 words + 1 checksum. I'm not the best
at napkin math, but I think that leaves you with around 10 trillion
combinations, which would only take a couple months to exhaust with
hardware that can do 1 million guesses per second.

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

Re: [bitcoin-dev] No Order Mnemonic

[Paul Sztorc via bitcoin-dev]

What do you do if the "first" word (of 12), happens to be the last word in
the list alphabetically? So that seems like a dead end.

Since users are never expected to memorize the "whole list" (of 2048 words)
in any case, it seems that the smarter thing to do (if this "order"
criterion is desirable) may have been to just make the whole list 12x
longer and cut it into 12 sections. Each of the 12 slots would have 2048
distinct words. Then the computer would handle the order; the user could
neglect it.

I can guess why people weren't particularly interested in this: words
always have to be written down in some order or another. Even if you write
them down in a 3x4 grid, there are very few combinations needed to guess
the one true ordering. I wonder how obscure the words would have to be, by
the 12th list of 2048? But still it might be fun - the 4th word might
always be a nautical word, the 5th word a farm word, etc. And no one would
confuse it with a bip39 phrase -- in fact since they are just lists of
integers 1 to 2048, it would be pretty easy to make them interoperable.
Very easy but perhaps still not worth doing.

Paul

On Fri, Jul 8, 2022, 4:48 AM vjudeu via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Isn't it enough to just generate a seed in the same way as today, then
> sort the words alphabetically, and then use that as a seed? I know, the
> last word is a checksum, but there are only 2048 words, so it is not a big
> deal to get any checksum we want. If that is insecure, because of lower
> possible combinations, then it is always possible to increase the number of
> words to compensate that.
>
>
> On 2022-07-08 04:27:21 user Eric Voskuil via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>
> 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 bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> 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 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.linuxfoundation.org> wrote:
> 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 https://github.com/sancoder/noomnem
>
>
>
> Thanks Anton. There's an interesting mathematical question of whether it's
> possible to make a code like this which always uses the BIP-39 words for
> the same key as part of its encoding, basically adding a few words as error
> correction in case the order is lost or confused. If the BIP-39 contains a
> duplicate you can add an extra word.
> ___
> 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
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin covenants are inevitable

[John Carvalho via bitcoin-dev]

vju...@gazeta.pl, what you describe is not possible without a hard fork,
just like Eric said. There is no atomic way to move Bitcoin off of Bitcoin.

You can use Bitcoin txns, or you can use trust/custody, or you can make a
shitcoin. There is no way to actually divide or transfer sats to another
network.

This talk of inflation is absurd and forced and ignores all understanding
of Bitcoin and economic primitives. You would all do better to listen to
Eric and appreciate him taking the time to elaborate.

In the end, I will reiterate. Proof of work and the difficulty adjustment
scheme already solve all of these issues. When blockspace demand increases,
fees increase, more miners mine, security goes up. Thus any theoretical
supply increase would have the opposite effect.

All of these arguments for inflation amount to "That restaurant is too
popular, nobody goes there anymore." If people are using Bitcoin, miners
will mine. If all Bitcoin users are hodling only, then demand is gone, and
miners will leave. It is elegant.

Stop trying to fix Bitcoin, it isn't broken.

--
John Carvalho
CEO, Synonym.to 


On Fri, Jul 8, 2022 at 5:59 AM  wrote:

> > Simply fork off an inflation coin and test your theory. I mean, that’s
> the only way it can happen anyway.
>
> That would be an altcoin. But it can be done in a simpler way: we have 21
> million coins. It doesn't matter if it is 21 million, if it is 100 million,
> or if it is in some normalized range from 0 to 1, where you can always
> know, what fraction of the total supply you have. So, if the total supply
> is constant, then it is all about proportions. And that means, you can
> create some system on top of Bitcoin, that would move coins from users to
> miners. It is all about that: if all coins are mined, then they can move
> only if users will move them. So if you want to change that, it is all
> about encouraging them to put their coins in some evil Lightning channel,
> when they will lose their coins over time. That's how inflation works.
>
> So, imagine some evil channel, where you can put for example 0.01 BTC, and
> have a time-based fee, so you will pay 1000 satoshis per day. Guess what:
> 1000 days, and your coins are gone! That means, if anyone want to test
> inflation, it is possible right here and right now. Good luck to convince
> people to use your inflationary system in a non-obfuscated way, because
> that's how it truly looks like: if you double coin supply, you can reach
> the same by halving all amounts.
>
>
> On 2022-07-08 02:29:20 user Eric Voskuil via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>
> 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 zero implies infinite reward.
>
>
> You cannot support the blanket statement (and absent any assumption) that
> lower confirmation rates produce “much higher fees” or “better security”.
>
>
> What you call a “bidding war” is merely market pricing, as it occurs with
> any good. People *always* will pay as much as they will pay. This is
> tautological. What you cannot say is how much more someone will pay at any
> given time for any given good, until they have done it. And I’m pretty sure
> Bitcoin hasn’t done it.
>
>
> You cannot prove what the price of anything will be, nor can any “papers”.
> The absurdity of S2F should have clearly demonstrated that by now. Value is
> an individual human preference.
>
>
> If everyone pays 1 sat, then either miners are profitable at 1 sat, or
> these people are not getting confirmed (economic rationality always
> assumed).
>
>
> The assumption of 1 sat txs filling blocks is based on a
> disproportionately high subsidy. A subsidy of 50btc would imply somewhere
> in the neighborhood of $200 per tx in fees today, and as $680. As that
> falls, fees will continue to keep miners at the same profit level. If
> demand does not rise to compensate (as it always has) then hash rate will
> fall.
>
>
> Propping up hash rate with subsidy will not be “inflationary”, as Bitcoin
> is a market money. Like gold it is produced at market cost. Yet it will
> prevent Bitcoin from achieving any meaningful level of censorship
> resistance. This of course should make people look closely at such
> arguments.
>
>
> Of course, once you have a censor, block space gets really small for those
> who want to resist the censor. Then of course only fees can offset the
> censorship. Without fee-based tx confirmation (for anonymity), and/or with
> a disproportionate subsidy going to the censor, a censor can operate
> profitably and indefinitely (under the assumption of constant demand).
> There is no reason to assume demand for censored txs wouldn’t even
> increase, given the white market blessing which so many seem 

Re: [bitcoin-dev] Bitcoin covenants are inevitable

[vjudeu via bitcoin-dev]

> Simply fork off an inflation coin and test your theory. I mean, that’s the 
> only way it can happen anyway.

That would be an altcoin. But it can be done in a simpler way: we have 21 
million coins. It doesn't matter if it is 21 million, if it is 100 million, or 
if it is in some normalized range from 0 to 1, where you can always know, what 
fraction of the total supply you have. So, if the total supply is constant, 
then it is all about proportions. And that means, you can create some system on 
top of Bitcoin, that would move coins from users to miners. It is all about 
that: if all coins are mined, then they can move only if users will move them. 
So if you want to change that, it is all about encouraging them to put their 
coins in some evil Lightning channel, when they will lose their coins over 
time. That's how inflation works.

So, imagine some evil channel, where you can put for example 0.01 BTC, and have 
a time-based fee, so you will pay 1000 satoshis per day. Guess what: 1000 days, 
and your coins are gone! That means, if anyone want to test inflation, it is 
possible right here and right now. Good luck to convince people to use your 
inflationary system in a non-obfuscated way, because that's how it truly looks 
like: if you double coin supply, you can reach the same by halving all amounts.


On 2022-07-08 02:29:20 user Eric Voskuil via bitcoin-dev 
 wrote:


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 zero implies 
infinite reward. 


You cannot support the blanket statement (and absent any assumption) that lower 
confirmation rates produce “much higher fees” or “better security”.


What you call a “bidding war” is merely market pricing, as it occurs with any 
good. People *always* will pay as much as they will pay. This is tautological. 
What you cannot say is how much more someone will pay at any given time for any 
given good, until they have done it. And I’m pretty sure Bitcoin hasn’t done it.


You cannot prove what the price of anything will be, nor can any “papers”. The 
absurdity of S2F should have clearly demonstrated that by now. Value is an 
individual human preference.


If everyone pays 1 sat, then either miners are profitable at 1 sat, or these 
people are not getting confirmed (economic rationality always assumed).


The assumption of 1 sat txs filling blocks is based on a disproportionately 
high subsidy. A subsidy of 50btc would imply somewhere in the neighborhood of 
$200 per tx in fees today, and as $680. As that falls, fees will continue to 
keep miners at the same profit level. If demand does not rise to compensate (as 
it always has) then hash rate will fall.


Propping up hash rate with subsidy will not be “inflationary”, as Bitcoin is a 
market money. Like gold it is produced at market cost. Yet it will prevent 
Bitcoin from achieving any meaningful level of censorship resistance. This of 
course should make people look closely at such arguments.


Of course, once you have a censor, block space gets really small for those who 
want to resist the censor. Then of course only fees can offset the censorship. 
Without fee-based tx confirmation (for anonymity), and/or with a 
disproportionate subsidy going to the censor, a censor can operate profitably 
and indefinitely (under the assumption of constant demand). There is no reason 
to assume demand for censored txs wouldn’t even increase, given the white 
market blessing which so many seem to want.


But there is of course no real issue here. Simply fork off an inflation coin 
and test your theory. I mean, that’s the only way it can happen anyway.


e


On Jul 7, 2022, at 14:11, Erik Aronesty  wrote:



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, and 
in fees.


Without a bidding war for space, everyone can post 1 SAT/byte


With a bidding war for space, larger transactions will pay much higher rates.   
There have been a number of papers written on this but you can concoct a 
trivial example to prove it.




On Thu, Jul 7, 2022 at 3:58 PM Eric Voskuil  wrote:



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 out by difficulty — average 
profit (net income) is the cost of capital.


The reason for smaller vs. larger blocks is to ensure that individuals can 
afford to 

Re: [bitcoin-dev] Bitcoin covenants are inevitable

[Billy Tetrud via bitcoin-dev]

@vjudeu
> better to allow transaction joining.. to make fees more smoothly

I'm not familiar with RSK transaction joining. However, I don't think this
addresses the issues Corey brought up - which is that the
appropriate amount of security (ie miner revenue) isn't linked with any
bitcoin market behavior. It sounds like you're suggesting something that
could smooth out the fee market and potentially lower fees, however it
doesn't sound like a mechanism that could be used to target a particular
security level.

>  I think the market should adjust fees, and finding the right balance
between on-chain and off-chain should be left to the users, just by
providing them options like transaction joining

The market has an incentive to minimize fees. So I don't see how this would
be sufficient if it ends up that miner revenue from fees is too low.

@Erik
> I think perhaps you're  underestimating the degree to which utility can
be added to the main chain to encourage fees.

It seems you've misinterpreted me to be saying that fees will be too low. I
have no idea if fees will be too low or not. And you might be right that
fees are likely to remain high enough. However, fees might also remain *too
high* which itself could be a problem. As I noted above, since market
forces all incentivize driving fees down, what do we do if that force
drives it below a sufficient level? How will we know when that happens
until we know what the sufficient level of security is (eg in terms of
total miner revenue).

@Guiseppe
> If it only takes a few million dollars to attack BTC and make it
completely unusable for one day

It would take much more than a few million to 51% attack bitcoin. Bitcoin's
blockchain security is primarily based on the capital cost of buying up a
massive amount of hashpower. The ongoing maintenance and electricity costs
of mining are actually not very relevant to security because all those
ongoing costs are directly offset by mining revenues. Its the upfront costs
that serve as the primary barrier an attacker must surpass. Acquiring the
mining hardware, finding places where energy costs are low enough, setting
up the equipment, etc. To do that costs billions of dollars, not millions.


On Thu, Jul 7, 2022 at 9:44 AM Giuseppe B via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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
> from the huge panic sell wave and global loss of confidence that would
> result from it.
> It seems even cheaper to do than the recent attack to Terra, unless I'm
> missing something.
>
>
> On Wed, Jul 6, 2022, 1:10 PM  wrote:
>
>> > If the only realistic (fair, efficient & proportionate) way to pay for
>> Bitcoin's security was by having some inflation scheme that violated the 21
>> million cap, then agreeing to break the limit would probably be what makes
>> sense, and in the economic interest of its users and holders.
>>
>> So, Paul Sztorc was right again, there are three options: Enormous Block
>> Size Increases, Violate 21M Coin Limit, or >50% Miner Fee-Revenues Come
>> From Merged Mining: https://www.truthcoin.info/images/sb-trilemma.png.
>> And I think using Merged Mining is the best option. More about that:
>> https://www.truthcoin.info/blog/security-budget-ii-mm/
>>
>> > Another option, if we were to decide we are over-secured in the short
>> term, would be to soft-fork in a reduction in the current and near-future
>> mining rewards, by somehow locking the coins in a contract that deprived
>> the miner of the full reward, and then using that contract to pay the
>> rewards out far in the future, should at some point we feel the security
>> budget was insufficient.
>>
>> Yes, that's also possible, RSK uses that. And making some kind of
>> soft-fork for that is also possible, but I don't know if miners will agree
>> to send some coinbase reward to " OP_CHECKLOCKTIMEVERIFY
>> OP_DROP OP_TRUE".
>>
>> On 2022-07-06 06:29:18 user Corey Haddad via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>> >Bitcoin's finite supply is the main argument for people investing in it,
>> the whole narrative around bitcoin is based on its finite supply. While it
>> has its flaws and basically condemns bitcoin to be only used as a store >of
>> value (and not as a currency), I don't think it's worth questioning it at
>> this point.
>> >
>> >Just my 2 sats.
>> >
>> >Giuseppe.
>>
>>
>> A finite supply alone is not enough to give something value, as it must
>> also be useful in some way. In the case of Bitcoin, various forms of
>> cryptographic security must all work - and work together - to make Bitcoin
>> useful. If the only realistic (fair, efficient & proportionate) way to pay
>> for Bitcoin's security was by having some 

Re: [bitcoin-dev] No Order Mnemonic

[vjudeu via bitcoin-dev]

Isn't it enough to just generate a seed in the same way as today, then sort the 
words alphabetically, and then use that as a seed? I know, the last word is a 
checksum, but there are only 2048 words, so it is not a big deal to get any 
checksum we want. If that is insecure, because of lower possible combinations, 
then it is always possible to increase the number of words to compensate that.


On 2022-07-08 04:27:21 user Eric Voskuil via bitcoin-dev 
 wrote:


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 bitcoin-dev 
 wrote:
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 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 
 wrote:
On Thu, Jul 7, 2022 at 7:43 AM Anton Shevchenko via bitcoin-dev 
 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 https://github.com/sancoder/noomnem



Thanks Anton. There's an interesting mathematical question of whether it's 
possible to make a code like this which always uses the BIP-39 words for the 
same key as part of its encoding, basically adding a few words as error 
correction in case the order is lost or confused. If the BIP-39 contains a 
duplicate you can add an extra word.
___
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