Re: [bitcoin-dev] Ordinal Inscription Size Limits

[Erik Aronesty via bitcoin-dev]

Onchain capacity is a red herring.  There are so many problems with it and
we don't need to go into it here if it's already been beaten to death.


 What we need are the op codes necessary to create a trustless,
disconnected graph of layer two solution.

We all know that some form of covenant technology is the right way to do
this

Some way of revokably sharing UTXOs, such that the incentives keep
coordinators in line

That can get us to global scale on a layer two that isn't custodial







On Wed, Jan 3, 2024, 4:12 AM Brad Morrison  wrote:

> Erik/all,
>
> Are you saying that node capacity is the primary technical limiting factor
> to increasing adoption of bitcoin payments?
>
> UBER & Lyft payments are actually poor examples because they are not
> regular/monthly and I should not have used them (unless refilling existing
> accounts, like gift cards). But utility bills would be a much better
> example of an opportunity for bitcoin payments to compete with existing
> credit card payment systems because processing timing has the potential to
> be less urgent.
>
> Sharing UTXOs seems pretty minor compared to lowering transaction costs.
>
> Brad
>
>
>
> On 2024-01-01 08:08, Erik Aronesty wrote:
>
> .
>>
>> In the USA, where I am, large businesses like UBER, Lyft, and many major
>> telecom, cable, & electric utilities process huge volumes of regular and
>> irregular credit card payments on a monthly basis. Almost none oft hose
>> transactions are completed in bitcoin.
>>
>
>
> Unfortunately block size is not the limiting factor
>
> Main chain transactions have to be broadcast and stored on every node in
> the network which, as you know, cannot scale to the level of Uber payments
>
> Lighting and possibly ark are solutions to this problem
>
> Both require covenant tech of some kind to scale properly (nonrecursive is
> fine)
>
> Covenant tech (any will do, arguing about which is bike shedding at this
> point) allows people to share utxos and yet still maintain sovereignty over
> their assets
>
>
>
>
>
>>
>>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Swift Activation - CTV

[Erik Aronesty via bitcoin-dev]

On Tue, Jan 2, 2024, 8:52 AM Michael Folkson 
wrote:

> In the interests of time I'll just pick two to respond to but I don't
> agree with any of your points.
>
> > Covenants allow trustless utxos sharing and also are needed for
> vaulting. The numerous use cases are documented, built out and on signet to
> my knowledge. Check out utxos.org for a good list
>
> Your knowledge is incorrect. As far as I know in the getting on for 2
> years since the first CTV activation talk/attempt literally no one has
> built out a CTV use case and demonstrated it on signet with the possible
> exception of James O'Beirne's OP_VAULT which requires other new opcodes in
> addition to CTV.
>

Nice example, thanks.

>
> > 4. "Best tool for the job" is not the bar. "Safe for all" and "useful
> for some" is the bar.
>

This is the bar, ant CTV has passed it with vaulting alone.

If you want to avoid a chain split with an activation attempt (it is
> possible you don't care but if you do) you have to address concerns others
> have with a particular proposal.
>

You haven't mentioned one safety concern.  It's hard to tell if you have
any.  There is, of course, the elephant in the room with CTV that is a true
concern that nobody talks about.

The real danger of CTV isn't whether it's the best, and we know it's
nonrecursive.  And we can use BIP8, so that isn't an issue either.

And we already have shitcoins on BTC, so sapio shouldn't be your issue (
https://github.com/sapio-lang/sapio)

Why exactly is your problem?  You yourself have admitted it's useful for
vaulting, and for reducing the cost of lightning onboarding, even though
you ignored the dozens of other use cases enumerated in detail on utxos.org
and elsewhere.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Ordinal Inscription Size Limits

[Erik Aronesty via bitcoin-dev]

>
> .
>
> In the USA, where I am, large businesses like UBER, Lyft, and many major
> telecom, cable, & electric utilities process huge volumes of regular and
> irregular credit card payments on a monthly basis. Almost none oft hose
> transactions are completed in bitcoin.
>


Unfortunately block size is not the limiting factor

Main chain transactions have to be broadcast and stored on every node in
the network which, as you know, cannot scale to the level of Uber payments

Lighting and possibly ark are solutions to this problem

Both require covenant tech of some kind to scale properly (nonrecursive is
fine)

Covenant tech (any will do, arguing about which is bike shedding at this
point) allows people to share utxos and yet still maintain sovereignty over
their assets





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

Re: [bitcoin-dev] Swift Activation - CTV

[Erik Aronesty via bitcoin-dev]

1. Claiming that something that isn't activated (unusable) isn't used as a
non-argument

2. Talking about activation methods is orthogonal.  Bip8 is fine.

3. Covenants allow trustless utxos sharing and also are needed for
vaulting.  The numerous use cases are documented, built out and on signet
to my knowledge.  Check out utxos.org for a good list

3. No need to discuss wild extremes that are unrelated to ctvs well
documented utility.  Plus multi-sig allows governments to encumber (or
accidentally ruin) destination addresses just like covenants.

4. "Best tool for the job" is not the bar. "Safe for all" and "useful for
some" is the bar. Like any opcodes or tech Bitcoin has deployed in the
past.  Changing the bar is not up for discussion.


CTV has already been demonstrated "useful for some".  The question that
needs to be answered is whether there are any specific objections to safety.









On Mon, Jan 1, 2024, 11:37 AM Michael Folkson 
wrote:

> Hi Erik
>
> > So what exactly are the risks of CTV over multi-sig?
>
> It is a strange comparison. Multisig is active onchain and is being used
> today for all sorts of things including Lightning and setups that address
> risk of single key loss or malicious signing. When discussing risks of CTV
> there are all sorts of risks that don't apply to multisig. These include
> that it is never used for any of its speculated use cases (multisig is
> being used today), other proposals end up being used instead of it (I'm not
> sure there were or are competing proposals so that multisig stops being
> used, MuSig2 maybe?), chain split risks with activation if there isn't
> consensus to activate it etc. Plus usage of complex (non covenant) scripts
> that fully utilize Taproot trees is still low today. Going straight to
> covenants (imposing restrictions on *where*​ funds can be sent) and not
> bothering with imposing all the restrictions you'd like on *how*​ funds
> can be spent in the first place seems to me to be putting the cart before
> the horse. Covenants don't ultimately solve the key management issue, they
> just move it from the pre spending phase to the post spending phase. So the
> benefits (although non-zero) aren't as obvious as some of the covenant
> advocates are suggesting. And although CTV is a limited covenant (some
> argue too limited) covenants taken to wild extremes could create all sorts
> of second order effects where funds can't be spent because of complex
> combinations of covenants. Even the strongest CTV proponent seems to
> suggest that the introduction of covenants wouldn't end with CTV.
>
> The way to reduce implementation risk for a use case of a particular
> proposal is to build out that use case and see if CTV is the best tool for
> the job. Repeatedly trying to activate CTV when there isn't consensus for
> it to be activated does not reduce that implementation risk in any way,
> shape or form.
>
> Thanks
> Michael
>
>
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
>
> Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
>
> On Saturday, 30 December 2023 at 08:59, Erik Aronesty via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> So what exactly are the risks of CTV over multi-sig?
>
>
>>
>>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Ordinal Inscription Size Limits

[Erik Aronesty via bitcoin-dev]

Bitcoin already has a spam prevention system called "fees".   I don't
believe it's insufficient.  The only issue is the stochastic nature of its
effectiveness

Which can be resolved with things like payment pools, tree payments (
https://utxos.org/uses/scaling/), etc.



On Fri, Dec 29, 2023, 9:33 AM Greg Tonoski via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> > Unfortunately, as near as I can tell there is no sensible way to
> > prevent people from storing arbitrary data in witnesses ...
>
> To prevent "from storing arbitrary data in witnesses" is the extreme
> case of the size limit discussed in this thread. Let's consider it along
> with other (less radical) options in order not to lose perspective,
> perhaps.
>
> > ...without incentivizing even worse behavior and/or breaking
> > legitimate use cases.
>
> I can't find evidence that would support the hypothesis. There had not
> been "even worse behavior and/or breaking legitimate use cases" observed
> before witnesses inception. The measure would probably restore
> incentives structure from the past.
>
> As a matter of fact, it is the current incentive structure that poses
> the problem - incentivizes worse behavior ("this sort of data is toxic
> to the network") and breaks legitimate use cases like a simple transfer
> of BTC.
>
> > If we ban "useless data" then it would be easy for would-be data
> > storers to instead embed their data inside "useful" data such as dummy
> > signatures or public keys.
>
> There is significant difference when storing data as dummy signatures
> (or OP_RETURN) which is much more expensive than (discounted) witness.
> Witness would not have been chosen as the storage of arbitrary data if
> it cost as much as alternatives, e.g. OP_RETURN.
>
> Also, banning "useless data" seems to be not the only option suggested
> by the author who asked about imposing "a size limit similar to OP_RETURN".
>
> > But from a technical point of view, I don't see any principled way to
> > stop this.
>
> Let's discuss ways that bring improvement rather than inexistence of a
> perfect technical solution that would have stopped "toxic data"/"crap on
> the chain". There are at least a few:
> - https://github.com/bitcoin/bitcoin/pull/28408
> - https://github.com/bitcoin/bitcoin/issues/29146
> - deprecate OP_IF opcode.
>
> I feel like the elephant in the room has been brought up. Do you want to
> maintain Bitcoin without spam or a can't-stop-crap alternative, everybody?
> ___
> 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] Swift Activation - CTV

[Erik Aronesty via bitcoin-dev]

So what exactly are the risks of CTV over multi-sig?


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

Re: [bitcoin-dev] ossification and misaligned incentive concerns

[Erik Aronesty via bitcoin-dev]

I don't believe the narrative that miners provide network security

they provide double spend insurance

and that's it

so that limits the size of the transaction and the number of confirmations
that are required before that transaction is cleared

But it doesn't provide security for the rest of the network.  My private
keys are private and my note is fully validating  ..  and there's nothing
miners can do about that

let's ditch that narrative please



On Sun, Nov 5, 2023, 9:40 AM JK  wrote:

>
> I'm worried even more about something else, but still fits into the same
> topic category.
>
>
> A tax in the form of a direct tax is less acceptable to people than a
> hidden tax. This is human nature, as the saying goes, "What the eye
> doesn't see, the heart doesn't grieve over." A high direct tax (e.g., on
> a one-time transaction) is much more irritating than a tax of the same
> amount but hidden (especially when it affects all cash holders equally,
> as in the case of inflation).
>
> There is no reason to believe that in any alternative financial system,
> it will be different ("This time is different." No, it is not.)
>
> The analogy is clear: a transaction tax is on-chain fee, an inflation
> tax is the block reward. And just in case: miners are only able to
> collect payment for providing network security in an amount equal to the
> sum collected in both of these taxes, and no single satoshi more (the
> principle that "There's no such thing as a free lunch" applies).
>
> Now, a little thought experiment:
> 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).
>
> It is known that the system will oscillate around a certain level of the
> block reward value (around a certain level of inflation) that provides
> the desired level of network security.
>
> Furthermore, Earth is a closed system with finite resources, making it
> hard to imagine a situation where Bitcoin is responsible for e.g. 95%
> of global energy consumption (while complaints already arise at 0.1%).
>
> In other words, the level of network security is de facto limited from
> the top, whether we like it or not.
>
> And for a naturally limited and still acceptable level of network
> security (vide: "Change the code, not the climate") - there is a
> corresponding level of inflation.
>
>
> To sum this up, the most important conclusion to remember is:
>
> For a natural level of network security, there is a natural level of
> inflation.
>
>
>
> I'll add a very relevant comment I know from the internet:
>
> "It makes sense. Something akin to what the central banks do by setting
> interest rates, but algorithmic, leading to a 'natural' (rather than
> manipulated) level of inflation. But different, because it's directly
> tied to security. I haven't thought whether it would be an issue if it
> works in one direction only (halvings, but no doublings), but it might.
> When I was learning about Bitcoin, I heard "It costs you nothing to
> store your bitcoin (as opposed to, say, gold). You get security for
> free." and thought it sounded wonderful, but too good to be true. There
> is no free lunch and all that... I understand a lack of inflation is
> aligned with Austrian economics, but the Austrians didn't know a
> monetary system whose security was tied to inflation. So it's a new
> concept to wrap one's head around."
> https://stacker.news/items/291420
>
>
> There is growing awareness of the lack of a free market between active
> and passive participants in Bitcoin and growing awareness of the
> inevitability of the problem that will arise in the future as a result.
> And there is slowly growing acceptance of well-thought-out proposals to
> fix this situation.
> The free market is more important than finite supply.
>
>
> Regards
> Jaroslaw
>
>
> W dniu 03.11.2023 o 19:24, Erik Aronesty via bitcoin-dev pisze:
> > currently, there are providers of anonymity services, scaling services,
> > custody, and other services layered on top of bitcoin using trust-based
> > and federated models.
> >
> > as bitcoin becomes more popular, these service providers have
> > increasingly had a louder "voice" in development and maintenance of the
> > protocol
> >
> > holders generally want these features
> >
> > but service providers have an incentive to maintain a "moat" around
> > their services
> >
> > in summary, making privac

[bitcoin-dev] ossification and misaligned incentive concerns

[Erik Aronesty via bitcoin-dev]

currently, there are providers of anonymity services, scaling services,
custody, and other services layered on top of bitcoin using trust-based and
federated models.

as bitcoin becomes more popular, these service providers have increasingly
had a louder "voice" in development and maintenance of the protocol

holders generally want these features

but service providers have an incentive to maintain a "moat" around their
services

in summary, making privacy, scaling and vaulting "hard" for regular users,
keeping it off-chain and federated...  is now incentivised among a vocal,
but highly technical, minority

is anyone else worried about this?
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Scaling Lightning With Simple Covenants

[Erik Aronesty via bitcoin-dev]

>
> replacing CTV usage with Musig2
>
>
this changes the trust model to a federated one vs trustless and also
increases the on-chain footprint of failure, correct?

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

Re: [bitcoin-dev] Concern about "Inscriptions"

[Erik Aronesty via bitcoin-dev]

indeed, i once added a proof-of work requirement to public keys on an open
relay server protocol, in additon to posk, in order to make it harder to
roll new keys and access the network as a spammer/scammer.   not hard to
embed anything in a public key, but you can't embed too much, especially if
you want mobile devices to be able to generate a new key in under a few
minutes.

On Mon, Aug 21, 2023 at 6:46 PM symphonicbtc via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> It is important to also note that proof of secret key schemes are highly
> data inefficient and likely would have a higher cost for users than simply
> allowing arbitrary data to continue. In ECDSA, purposely re-using k values
> allows you to encode data in both k and the entire secret key, as both
> become computable. Or, one could bruteforce a k value to encode data in a
> sig, as is done in some compromised hardware key exfiltration attacks.
> Additionally, one can bruteforce keys in order to encode data in the public
> key.
>
> It is very difficult and expensive to attempt to limit the storage of
> arbitrary data in a system where the security comes from secret keys being
> arbitrary data.
>
> Symphonic
>
> --- Original Message ---
> On Monday, August 21st, 2023 at 4:28 PM, John Tromp via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>
> > > If we ban "arbitrary data", however you want to define it, then actors
> will
> > > simply respond by encoding their data within sets of public keys.
> Public
> > > key data is indistinguishable from random data, and, unless we are
> willing
> > > to pad the blockchain with proof of knowledge of secret keys, there
> will be
> > > no way to tell a priori whether a given public key is really a public
> key
> > > or whether it is encoding an inscription or some other data.
> >
> >
> > Note that in the Mimblewimble protocol, range proofs already prove
> > knowledge of blinding factor in Pedersen commitments, and thus no
> > additional padding is needed there to prevent the encoding of spam
> > into cryptographic material. This makes pure MW blockchains the most
> > inscription/spam resistant [1].
> >
> > [1]
> https://bitcointalk.org/index.php?topic=5437464.msg61980991#msg61980991
> > ___
> > 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] Blinded 2-party Musig2

[Erik Aronesty via bitcoin-dev]

correct.  you cannot select R if it is shipped with a POP

On Wed, Jul 26, 2023, 4:35 PM Tom Trevethan  wrote:

> Not 'signing' but 'secret' i.e. the r values (ephemeral keys). Proof of
> knowledge of the r values used to generate each R used prevents the Wagner
> attack, no?
>
> On Wed, Jul 26, 2023 at 8:59 PM Jonas Nick  wrote:
>
>> None of the attacks mentioned in this thread so far (ZmnSCPxj mentioned an
>> attack on the nonces, I mentioned an attack on the challenge c) can be
>> prevented
>> by proving knowledge of the signing key (usually known as proof of
>> possession,
>> PoP).
>>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Blinded 2-party Musig2

[Erik Aronesty via bitcoin-dev]

personally, i think *any* time a public key is transmitted, it should come
with a "proof of secret key".   it should be baked-in to low level
protocols so that people don't accidentally create vulns.  alt discussion
link:  https://gist.github.com/RubenSomsen/be7a4760dd4596d06963d67baf140406

On Tue, Jul 25, 2023 at 5:18 PM Tom Trevethan via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Thanks for the replies. As I understand it, the v=2 nonces signing
> protocol of musig2 prevents the Wagner attack. Also, that the challenge
> value c must be blinded from the server to prevent the server from being
> able to determine the signature from the on-chain state.
>
> In addition, in order to update the server (party 1) keyshare when a
> statecoin is transferred between users, the key aggregation coefficient
> must be set to 1 for each key. The purpose of this coefficient in the
> Musig2 protocol is to prevent 'rogue key attacks' where one party can
> choose a public key derived from both their own secret key and the inverse
> of the other party's public key giving them the ability to unilaterally
> produce a valid signature over the aggregate key. However this can be
> prevented by the party producing a proof of knowledge of the private key
> corresponding to their supplied public key. This can be a signature, which
> is produced in any case by signing the statechain state in the mercury
> protocol. This signature must be verified by the receiver of a coin (who
> must also verify the server pubkey combines with the sender pubkey to get
> the coin address) which proves that the server is required to co-sign to
> generate any signature for this address.
>
> Here is a modified protocol:
>
> Keygen:
>
> Server generates private key x1 and public key X1 = x1.G and sends X1 to
> user (party 2)
> User generates private key x2 and public key X2 = x2.G and (random)
> blinding nonce z and computes the aggregate public key X = z.(X1 + X2)
> (server never learns of X, X2 or z).
>
> Signing:
>
> Server generates nonces r11 and r12 and R11 = r11.G and R12 = r12.G and
> sends R11 and R12 to the user.
> User generates nonces r21 and r22 and R21 = r21.G and R22 = r22.G
> User computes R1 = R11 + R21 and R2 = R12 + R22 and b = H(X,(R1,R2),m) and
> R = R1 + b.R2 and c = (X,R,m)
> User sends the values y = cz and b to the server.
> Server computes s1 = yx1 + r11 + br12 and sends it to the user.
> User computes s2 = yx2 + r21 + br22 and s = s1 + s2 and signature (s,R)
>
> Transfer:
>
> In a statecoin transfer, when receiving a statecoin, in order to verify
> that the coin address (i.e. aggregate public key) is shared correctly
> between the previous owner and the server, the client must verify the
> following:
>
> Retrieve the CURRENT public key from the server for this coin X1.
> Retrieve the public key X2 and the blinding nonce z from the sender.
> Verify that z.X1 + X2 = P the address of the statecoin.
> Verify that the sender has the private key used to generate X2: this is
> done by verifying the statechain signature over the receiver public key X3
> from X2.
> This proves that the address P was generated (aggregated) with the server
> and can only be signed with cooperation with the server, i.e. no previous
> owner can hold the full key.
>
> In order to update the key shares on transfer, the following protocol can
> be used:
>
> Server (party 1) generates a random blinding nonce e and sends it to user.
> User adds their private key to the nonce: t1 = e + x2
> Client sends t1 and z to the reciever as part of transfer_msg (encrypted
> with the receiver public key X3 = x3.G).
> Receiver client decrypts t1 and then subtracts their private key x3: t2 =
> e + x2 - x3.
> Receiver client sends t2 to the server as part of transfer_receiver.
> Server the updates the private key share x1_2 = x1 + t2 - e = x1 + e + x2
> - x3 - e = x1 + x2 - x3
> So now, x1_2 + x3 (the aggregation of the new server key share with the
> new client key share) is equal to x1 + x2 (the aggregation of the old
> server key share with the old client key share).
> The server deletes x1.
>
> On Tue, Jul 25, 2023 at 3:12 PM Erik Aronesty  wrote:
>
>> posk is "proof of secret key".   so you cannot use wagner to select R
>>
>> On Mon, Jul 24, 2023 at 1:59 PM AdamISZ via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> @ZmnSCPxj:
>>>
>>> yes, Wagner is the attack you were thinking of.
>>>
>>> And yeah, to avoid it, you should have the 3rd round of MuSig1, i.e. the
>>> R commitments.
>>>
>>> @Tom:
>>> As per above it seems you were more considering MuSig1 here, not MuSig2.
>>> At least in this version. So you need the initial commitments to R.
>>>
>>> Jonas' reply clearly has covered a lot of what matters here, but I
>>> wanted to mention (using your notation):
>>>
>>> in s1 = c * a1 * x1 + r1, you expressed the idea that the challenge c
>>> could be given to the server, to construct s1, but since a1 = H(L, X1) and
>>> L is the serial

Re: [bitcoin-dev] Blinded 2-party Musig2

[Erik Aronesty via bitcoin-dev]

posk is "proof of secret key".   so you cannot use wagner to select R

On Mon, Jul 24, 2023 at 1:59 PM AdamISZ via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> @ZmnSCPxj:
>
> yes, Wagner is the attack you were thinking of.
>
> And yeah, to avoid it, you should have the 3rd round of MuSig1, i.e. the R
> commitments.
>
> @Tom:
> As per above it seems you were more considering MuSig1 here, not MuSig2.
> At least in this version. So you need the initial commitments to R.
>
> Jonas' reply clearly has covered a lot of what matters here, but I wanted
> to mention (using your notation):
>
> in s1 = c * a1 * x1 + r1, you expressed the idea that the challenge c
> could be given to the server, to construct s1, but since a1 = H(L, X1) and
> L is the serialization of all (in this case, 2) keys, that wouldn't work
> for blinding the final key, right?
> But, is it possible that this addresses the other problem?
> If the server is given c1*a1 instead as the challenge for signing (with
> their "pure" key x1), then perhaps it avoids the issue? Given what's on the
> blockchain ends up allowing calculation of 'c' and the aggregate key a1X1 +
> a2X2, is it the case that you cannot find a1 and therefore you cannot
> correlate the transaction with just the quantity 'c1*a1' which the server
> sees?
>
> But I agree with Jonas that this is just the start, i.e. the fundamental
> requirement of a blind signing scheme is there has to be some guarantee of
> no 'one more forgery' possibility, so presumably there has to be some proof
> that the signing request is 'well formed' (Jonas expresses it below as a
> ZKP of a SHA2 preimage .. it does not seem pretty but I agree that on the
> face of it, that is what's needed).
>
> @Jonas, Erik:
> 'posk' is probably meant as 'proof of secret key' which may(?) be a mixup
> with what is sometimes referred to in the literature as "KOSK" (iirc they
> used it in FROST for example). It isn't clear to me yet how that factors
> into this scenario, although ofc it is for sure a potential building block
> of these constructions.
>
> Sent with Proton Mail secure email.
>
> --- Original Message ---
> On Monday, July 24th, 2023 at 08:12, Jonas Nick via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>
> > Hi Tom,
> >
> > I'm not convinced that this works. As far as I know blind musig is still
> an open
> > research problem. What the scheme you propose appears to try to prevent
> is that
> > the server signs K times, but the client ends up with K+1 Schnorr
> signatures for
> > the aggregate of the server's and the clients key. I think it's possible
> to
> > apply a variant of the attack that makes MuSig1 insecure if the nonce
> commitment
> > round was skipped or if the message isn't determined before sending the
> nonce.
> > Here's how a malicious client would do that:
> >
> > - Obtain K R-values R1[0], ..., R1[K-1] from the server
> > - Let
> > R[i] := R1[i] + R2[i] for all i <= K-1
> > R[K] := R1[0] + ... + R1[K-1]
> > c[i] := H(X, R[i], m[i]) for all i <= K.
> > Using Wagner's algorithm, choose R2[0], ..., R2[K-1] such that
> > c[0] + ... + c[K-1] = c[K].
> > - Send c[0], ..., c[K-1] to the server to obtain s[0], ..., s[K-1].
> > - Let
> > s[K] = s[0] + ... + s[K-1].
> > Then (s[K], R[K]) is a valid signature from the server, since
> > s[K]G = R[K] + c[K]a1X1,
> > which the client can complete to a signature for public key X.
> >
> > What may work in your case is the following scheme:
> > - Client sends commitment to the public key X2, nonce R2 and message m
> to the
> > server.
> > - Server replies with nonce R1 = k1G
> > - Client sends c to the server and proves in zero knowledge that c =
> > SHA256(X1 + X2, R1 + R2, m).
> > - Server replies with s1 = k1 + c*x1
> >
> > However, this is just some quick intuition and I'm not sure if this
> actually
> > works, but maybe worth exploring.
> > ___
> > 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] Blinded 2-party Musig2

[Erik Aronesty via bitcoin-dev]

You can't choose R if you provide posk

On Mon, Jul 24, 2023 at 10:31 AM Jonas Nick via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi Tom,
>
> I'm not convinced that this works. As far as I know blind musig is still
> an open
> research problem. What the scheme you propose appears to try to prevent is
> that
> the server signs K times, but the client ends up with K+1 Schnorr
> signatures for
> the aggregate of the server's and the clients key. I think it's possible to
> apply a variant of the attack that makes MuSig1 insecure if the nonce
> commitment
> round was skipped or if the message isn't determined before sending the
> nonce.
> Here's how a malicious client would do that:
>
> - Obtain K R-values R1[0], ..., R1[K-1] from the server
> - Let
>  R[i] := R1[i] + R2[i] for all i <= K-1
>  R[K] := R1[0] + ... + R1[K-1]
>  c[i] := H(X, R[i], m[i]) for all i <= K.
>Using Wagner's algorithm, choose R2[0], ..., R2[K-1] such that
>  c[0] + ... + c[K-1] = c[K].
> - Send c[0], ..., c[K-1] to the server to obtain s[0], ..., s[K-1].
> - Let
>  s[K] = s[0] + ... + s[K-1].
>Then (s[K], R[K]) is a valid signature from the server, since
>  s[K]*G = R[K] + c[K]*a1*X1,
>which the client can complete to a signature for public key X.
>
> What may work in your case is the following scheme:
> - Client sends commitment to the public key X2, nonce R2 and message m to
> the
>server.
> - Server replies with nonce R1 = k1*G
> - Client sends c to the server and proves in zero knowledge that c =
>SHA256(X1 + X2, R1 + R2, m).
> - Server replies with s1 = k1 + c*x1
>
> However, this is just some quick intuition and I'm not sure if this
> actually
> works, but maybe worth exploring.
> ___
> 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] Blinded 2-party Musig2

[Erik Aronesty via bitcoin-dev]

as long as all parties provide a proof of secret key along with their
public key, that should not be possible

or you can do it as a two-step process where all parties provide a
commitment to the public key and nobody reveals a public key until that
commitment is received

or if you want to be paranoid you can do both

On Mon, Jul 24, 2023, 7:00 AM ZmnSCPxj via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Good morning Tom,
>
> Would this allow party 2 to itself be composed of N >= 2 parties?
>
> MuSig2 (as opposed to MuSig1) requires that signatories provide multiple
> `R` points, not just one each, which are finally aggregated by first
> combining them using the MuSig() public key compose function.
> This prevents party 2 from creating an `R` that may allow it to perform
> certain attacks whose name escapes me right now but which I used to know.
> (it is the reason why MuSig1 requires 3 round trips, and why MuSig2
> requires at least 2 `R` nonces per signatory)
>
> Your scheme has only one `R` per party, would it not be vulnerably to that
> attack?
>
> Regards,
> ZmnSCPxj
>
>
> Sent with Proton Mail secure email.
>
> --- Original Message ---
> On Monday, July 24th, 2023 at 7:46 AM, Tom Trevethan via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>
> > We are implementing a version of 2-of-2 Schnorr Musig2 for statechains
> where the server (party 1 in the 2-of-2) will be fully 'blinded' - in that
> it can hold a private key that is required to generate an aggregate
> signature on an aggregate public key, but that it does not learn either: 1)
> The aggregate public key 2) The aggregate signature and 3) The message (m)
> being signed.
> >
> > In the model of blinded statechains, the security rests on the
> statechain server being trusted to report the NUMBER of partial signatures
> it has generated for a particular key (as opposed to being trusted to
> enforce rules on WHAT it has signed in the unblinded case) and the full set
> of signatures generated being verified client side
> https://github.com/commerceblock/mercury/blob/master/doc/merc_blind.md#blinding-considerations
> >
> > Given the 2-of-2 musig2 protocol operates as follows (in the following
> description, private keys (field elements) are denoted using lower case
> letters, and elliptic curve points as uppercase letters. G is the generator
> point and point multiplication denoted as X = xG and point addition as A =
> G + G):
> >
> > Party 1 generates private key x1 and public key X1 = x1G. Party 2
> generates private key x2 and public key X2 = x2G. The set of pubkeys is L =
> {X1,X2}. The key aggregation coefficient is KeyAggCoef(L,X) = H(L,X). The
> shared (aggregate) public key X = a1X1 + a2X2 where a1 = KeyAggCoef(L,X1)
> and a2 = KeyAggCoef(L,X2).
> >
> > To sign a message m, party 1 generates nonce r1 and R1 = r1G. Party 2
> generates nonce r2 and R2 = r2G. These are aggregated into R = R1 + R2.
> >
> > Party 1 then computes 'challenge' c = H(X||R||m) and s1 = c.a1.x1 + r1
> > Party 2 then computes 'challenge' c = H(X||R||m) and s2 = c.a2.x2 + r2
> >
> > The final signature is then (R,s1+s2).
> >
> > In the case of blinding this for party 1:
> >
> > To prevent party 1 from learning of either the full public key or final
> signature seems straightforward, if party 1 doesn't not need to
> independently compute and verify c = H(X||R||m) (as they are blinded from
> the message in any case).
> >
> > 1) Key aggregation is performed only by party 2. Party 1 just sends X1
> to party 2.
> > 2) Nonce aggregation is performed only by party 2. Party 1 just sends R1
> to party 2.
> > 3) Party 2 computes c = H(X||R||m) and sends it to party 1 in order to
> compute s1 = c.a1.x1 + r1
> >
> > Party 1 never learns the final value of (R,s1+s2) or m.
> >
> > Any comments on this or potential issues would be appreciated.
> >
> > Tom
> ___
> 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] ZeroSync: Introducing Validity Proofs to Bitcoin

[Erik Aronesty via bitcoin-dev]

"The sender
could store redundant copies of the encrypted transaction data with
multiple trust-
minimized middlemen, for the recipient to download when they come back
online."

sounds like a nostr event sent to a half dozen relays


On Fri, May 12, 2023, 9:15 AM Robin Linus via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi all,
>
> Today we are publishing a summary of our research on "ZeroSync:
> Introducing Validity Proofs to Bitcoin".
>
>
> Here's the preface:
>
> *We introduce ZeroSync, the first-ever proof system addressing Bitcoin’s
> scalability challenges with Succinct Non-Interactive Argument of Knowledge
> (SNARKs). ZeroSync compresses the entire Bitcoin blockchain into a compact
> proof of validity, enabling instant verification and unlocking various
> innovative applications. We discuss our prototype implementation of a chain
> state proof, utilizing the Cairo language, Utreexo, and recursive STARKs.
> Our work enables diverse applications, including quick bootstrapping of
> full nodes, trustless light clients, enhanced Lightning Network privacy,
> and secure cross-chain bridges. Chain state proofs require no consensus
> changes, which is crucial as forks in Bitcoin are challenging to implement
> and achieve consensus for. Despite the existing bottleneck of prover
> performance, we present a range of optimization strategies and demonstrate
> the practicality of generating a complete chain state proof. *
> *Finally, we introduce zkCoins, a client-side validation protocol combined
> with zeroknowledge SNARKs, drastically improving privacy and throughput of
> token transactions. In combination with future Bitcoin features, such as
> Simplicity, zkCoins also enables private and more scalable BTC
> transactions. *
> *The groundbreaking compression capabilities of SNARKs initiated a
> paradigm shift in cryptocurrency design, and ZeroSync is pioneering their
> application to Bitcoin.*
>
>
> You can find the full paper here: https://zerosync.org/zerosync.pdf
> Happy to receive any comments and answer any questions the bitcoin dev
> community may have about the paper!
>
>
>
> Best regards,
> Robin Linus
> ___
> 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 Core maintainers and communication on merge decisions

[Erik Aronesty via bitcoin-dev]

i agree 100%.   effective communication is challenging, especially in an
environment like this.   that being said, alicexbt is probably right that
we

 - probably need a well written spec, RFC-style perhaps
 - need more anon or nym maintainers where the online reputation isn't
trivially linked to real-world reputation
 - github should be replaced with something p2p (maybe move to
https://radicle.xyz/)

meta-stuff like that is probably just as important as picking the next cool
covenant opcode to ignore

On Thu, May 11, 2023 at 2:06 PM Steve Lee via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I don't see any reason to be antagonistic in your responses.
>
> One piece of advice I'd offer to you and Michael is to consider whether
> your responses are effective. To persuade other people it takes more than
> making good points or being right, but you need to find a communication
> style and communication path that is effective. My observation is that your
> styles need reflection.
>
>
> On Thu, May 11, 2023 at 10:15 AM alicexbt via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Hi Andrew,
>>
>> We can take a look at how previous maintainers were added to see how this
>> has played out in the past.
>>
>>
>> Can we learn something from past?
>>
>> Bitcoin's initial release was in 2009 with one developer and few others
>> experimenting with it. It is considered decentralized in 2023 however we
>> have 99% of nodes using bitcoin core, 5 developers deciding what's merged
>> or not and this includes some trying to implement their ideas without soft
>> fork using mempool policies.
>>
>> We need better process to add maintainers. I am disappointed with the way
>> last last pull request was merged. It says more about maintainers and
>> leader Michael Ford. If you are so scared about opinions on a pull request
>> why not just make him maintainer without pull request?
>>
>> Maybe you will understand this if your PR to add maintainer was kept open
>> for 4 months.
>>
>> /dev/fd0
>> floppy disk
>>
>>
>> Sent with Proton Mail  secure email.
>>
>> --- Original Message ---
>> On Thursday, May 11th, 2023 at 2:54 AM, Andrew Chow via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> On 05/07/23 03:03 AM, Michael Folkson via bitcoin-dev wrote:
>>
>>
>> The decision process for adding a new maintainer was according to the IRC
>> meeting that the maintainers decided privately there was a need for a
>> maintainer “who understood our interfaces and modularization efforts well”
>> and that ryanofsky was a “good fit for that”. I don’t know whether this was
>> decided in a private IRC channel or was decided at the recent in person
>> Core Dev meeting. Regardless, many have had no input into the discussion on
>> what kind of maintainer the project needs going forward and it seems the
>> maintainers do not want to discuss that aspect of the decision.
>>
>> Since the project began, the decision to seek out and then add a
>> maintainer has always been made by existing maintainers. When the
>> maintainers feel that there is a need for additional maintainers, they may
>> have an open call for volunteers, or may have a candidate already in mind
>> and suggest that specific person for maintainership. Contributors generally
>> are not consulted in the decision to seek a new maintainer as they would
>> not know whether there are things that are being overlooked or that there
>> is maintainership load that needs to be distributed. Even so, it wouldn't
>> be appropriate to add a maintainer if many contributors disagreed with it,
>> just as with any other PR.
>>
>> We can take a look at how previous maintainers were added to see how this
>> has played out in the past. I think our modern concept of maintainers with
>> nominal scopes began in 2015 with Jonas Schnelli. Both Jonas Schnelli and
>> Marco Falke were simply announced by Wladimir. There was no public
>> discussion, and some IRC logs refer to private emails between the them and
>> the current maintainers at that time. After that, meshcollider was added as
>> a maintainer after a public "call for maintainers" where a recurring topic
>> for a while was finding a maintainer for the wallet. He had volunteered to
>> do it by contacting Wladimir privately before it was discussed during an
>> IRC meeting and then on Github. Fanquake was added as a maintainer during a
>> CoreDev event in Amsterdam during a discussion initiated and led by the
>> maintainers. This was also "private" insofar as the discussion was limited
>> to those in attendance, although there was some opportunity for public
>> discussion in the PR opened on Github. For myself, it was also initially
>> private as I messaged Wladimir to volunteer for it after meshcollider
>> stepped down. There was some discussion on IRC and on Github, but it was
>> also obvious that many already expected me to be the wallet maintainer
>> after meshcollider. Hebasto was

Re: [bitcoin-dev] tx max fee

[Erik Aronesty via bitcoin-dev]

confused.   the rule was "cannot pay a fee > sum of outputs with
consideration of cpfp in the mempool"

your example is of someone paying a fee "< sum"  which wouldn't be blocked

note: again, i'm not a fan of this, i like the discussion of "bitcoin as
money only" and using fee as a lever to do that

show me how someone could move 1 btc and pay 2 btc as fees... i think we
can block it at the network or even the consensus layer, and leave anything
but "non-monetary use cases" intact.   the only way around it is to
maintain balances and use change addresses.   which would force nft and
timestamp users to maintain these balances and would be a deterrent

im am much more in favor of doing something like op_ctv which allows many
users to pool fees and essentially "share" a single utxo.
.


On Wed, May 10, 2023 at 12:19 PM  wrote:

> > possible to change tx "max fee"  to output amounts?
>
> Is it possible? Yes. Should we do that? My first thought was "maybe", but
> after thinking more about it, I would say "no", here is why:
>
> Starting point: 1 BTC on some output.
> Current situation: A single transaction moving 0.9000 BTC as fees, and
> creating 1000 satoshis as some output (I know, allowed dust values are
> lower and depend on address type, but let's say it is 1k sats to make
> things simpler).
>
> And then, there is a room for other solutions, for example your rule,
> mentioned in other posts, like this one:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021626.html
>
> > probably easier just to reject any transaction where the fee is higher
> than the sum of the outputs
>
> Possible situation after introducing your proposal, step-by-step:
>
> 1) Someone wants to move 1 BTC, and someone wants to pay 0.9000 BTC as
> fees. Assuming your rules are on consensus level, the first transaction
> creates 0.5 BTC output and 0.5 BTC fee.
> 2) That person still wants to move 0.5 remaining BTC, and still is willing
> to pay 0.4000 BTC as fees. Guess what will happen: you will see another
> transaction, creating 0.25 BTC output, and paying 0.25 BTC fee.
> ...
> N) Your proposal replaced one transaction, consuming maybe one kilobyte,
> with a lot of transactions, doing exactly the same, but where fees are
> distributed between many transactions.
>
> Before thinking about improving that system, consider one simple thing: is
> it possible to avoid "max fee rule", no matter in what way it will be
> defined? Because as shown above, the answer seems to be "yes", because you
> can always replace a single transaction moving 1 BTC as fees with multiple
> transactions, each paying one satoshi per virtual byte, and then instead of
> consuming around one kilobyte, it would consume around 1 MvB per 0.01 BTC,
> so 100 MvB per 1 BTC mentioned in the example above.
>
>
>
> On 2023-05-08 13:55:18 user Erik Aronesty via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> possible to change tx "max fee"  to output amounts?
>
>
> seems like the only use case that would support such a tx is spam/dos type
> stuff that satoshi warned about
>
>
> its not a fix for everything, but it seems could help a bit with certain
> attacks
>
>
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes?

[Erik Aronesty via bitcoin-dev]

>
>
> > no data at all


exactly, which is why a relationship between "cpfp-inclusive outputs" and
"fees" makes sense.   it's clear that's a good definition of dust, and not
too hard to get a working pr up for the network-layer.   i get that your
node will still route.   i get that it would break timestamps, indeed, it
would break all non-economic use cases if we made it a consensus change.

but that's the point of the discussion.

the question is whether breaking all non-economic use cases is the right
move, given the game-theory of what underpins bitcoin

i'm sad (honestly) to say that it might be

it may very well be that bitcoin *cannot* be a "global ledger of all
things" in order to remain useful and decentralized, and instead the
monetary use case must be it's only goal

also, i'm not really advocating for this solution so much as i would like a

- rational conversation about the incentives
- whether this solution would be an effective enough barrier to keep most
non-economic tx off bitcoin

obviously it's easy enough to evade if every non-economic user simply keeps
enough bitcoin around and sends it back to himself

so maybe it's a useless idea?   but maybe that's enough of a hassle to stop
people (it certainly breaks ordinals, since it can never be 1 sat)
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes?

[Erik Aronesty via bitcoin-dev]

I would like to point out that I'm not an advocate for doing anything at
this point aside from working on l2

just to make it inconvenient for people

I just think the discussion of outputs and fees is interesting and related
to the game theory portion of Bitcoin



On Tue, May 9, 2023, 8:23 AM Jaroslaw via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
>
> Ok, I need to highlight one important thing well proven by this discussion
> (like it or not)...
>
> Not the spam itself is the real reason of feeling: "something must be done"
> The reason is: $30 fee per transaction (I hope you all agree)
>
>
> Let me paraphrase some quotes used in this discussion, then:
>
> 1. Lack of block subsidy long term and necessity of $40 tx fee to
> compensate it - "threaten the smooth and normal use of the Bitcoin network
> as a peer-to-pear digital currency, as it was intended to be used as."
>
> 2. "the harmony of Bitcoin transactions is being disrupted right now" due
> to lack of block subsidy and due to exorbitant $40 tx fees as an effect
> necessary to keep the network security untouched
>
> 3. "Fee spikes aren't fun" and it's obvious that keeping the network
> security only on enormous tx fees of active users and having passive users
> as free-riders - isn't fun, too
>
> 4. by ignoring Bitcoin long-term security budget problem - "we indirectly
> allowed this to happen, which previously wasn't possible before. So we also
> have a responsibility to do something to ensure that this kind of
> tremendous $40 tx fees can never happen again"
>
> 5. "Action against exorbitant fees should have been taken months ago.
> (...) It's a mistake that the" tail emission or other necessary solution -
> weren't implemented on time
>
> 6. "we need to find a solution for long-term horrible fees problem - that
> fits everyone's common ground."
>
>
> Yes, we need - instead of being still in a heavy denial state.
>
> No additional comment then, except this little one:
> Delay of halving in case of 4 years long network difficulty regression
> situation.
>
>
> Regards,
> Jaroslaw
>
>
>
>
>
> W dniu 2023-05-09 00:37:57 użytkownik Luke Dashjr via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> napisał:
>
> Action should have been taken months ago. Spam filtration has been a
> standard part of Bitcoin Core since day 1. It's a mistake that the existing
> filters weren't extended to Taproot transactions. We can address that, or
> try a more narrow approach like OP_RETURN (ie, what "Ordisrespector" does).
> Since this is a bugfix, it doesn't really even need to wait for a major
> release.
>
> (We already have pruning. It's not an alternative to spam filtering.)
>
> Luke
>
>
>
>
> On 5/7/23 13:22, Ali Sherief via bitcoin-dev wrote:
> Hi guys,
>
>
> I think everyone on this list knows what has happened to the Bitcoin
> mempool during the past 96 hours. Due to side projects such as BRC-20
> having such a high volume, real bitcoin transactions are being priced out
> and that is what is causing the massive congestion that has arguable not
> been seen since December 2017. I do not count the March 2021 congestion
> because that was only with 1-5sat/vbyte.
>
>
> Such justifiably worthless ("worthless" is not even my word - that's how
> its creator described them[1]) tokens threaten the smooth and normal use of
> the Bitcoin network as a peer-to-pear digital currency, as it was intended
> to be used as.
>
>
> If the volume does not die down over the next few weeks, should we take an
> action? The bitcoin network is a triumvirate of developers, miners, and
> users. Considering that miners are largely the entities at fault for
> allowing the system to be abused like this, the harmony of Bitcoin
> transactions is being disrupted right now. Although this community has a
> strong history of not putting its fingers into pies unless absolutely
> necessary - an example being during the block size wars and Segwit - should
> similar action be taken now, in the form of i) BIPs and/or ii) commits into
> the Bitcoin Core codebase, to curtail the loophole in BIP 342 (which
> defines the validation rules for Taproot scripts) which has allowed these
> unintended consequences?
>
>
> An alternative would be to enforce this "censorship" at the node level and
> introduce a run-time option to instantly prune all non-standard Taproot
> transactions. This will be easier to implement, but won't hit the road
> until minimum next release.
>
>
> I know that some people will have their criticisms about this,
> absolutists/libertarians/maximum-freedom advocates, which is fine, but we
> need to find a solution for this that fits everyone's common ground. We
> indirectly allowed this to happen, which previously wasn't possible before.
> So we also have a responsibility to do something to ensure that this kind
> of congestion can never happen again using Taproot.
>
>
> -Ali
>
>
> ---
>
>
> [1]:
> https://www.coindesk.com/consensus-magazine/2023/05/05/pump-the-brcs-the

Re: [bitcoin-dev] tx max fee

[Erik Aronesty via bitcoin-dev]

fair.   i suppose you could support cpfp in any dust filtering.   im not a
fan, but I think its the only legit way to defend the chain from non money
use cases

On Mon, May 8, 2023, 7:58 PM Peter Todd  wrote:

> On Sun, May 07, 2023 at 07:59:40PM -0400, Erik Aronesty via bitcoin-dev
> wrote:
> > possible to change tx "max fee"  to output amounts?
> >
> > seems like the only use case that would support such a tx is spam/dos
> type
> > stuff that satoshi warned about
> >
> > its not a fix for everything, but it seems could help a bit with certain
> > attacks
>
> With CPFP it often makes sense for a transaction to have a fee larger than
> the
> output amounts.
>
> This proposal would also screw over applications like my OpenTimestamps
> service.
>
> --
> 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] [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes?

[Erik Aronesty via bitcoin-dev]

> value you can from these Lightning channel(s) onchain even if it means
paying a higher fee than the amount you are receiving.

in that case, you're not getting any value - you're losing value.   the
only benefit i could imagine would be to prevent the other party from
having access to the funds should the channel expire.

regardless, this is an edge case.   it's clear that a utxo whose value is
less than the fee paid to move it is dust, and we already have plenty of
code to censor dust transactions

> no reason to prevent

the reason to prevent them is to prevent something that has more value than
the bitcoin itself from being stored on-chain.  that is to say:
real-estate ownership, nfts, or any other thing that isn't "using bitcoin
as money"

by going at the "incentive/economic layer", rather than pointlessly forcing
brc-20 and ordinals users to obfuscate their transactions, we can provide a
permanent incentive to keep that stuff off of bitcoin

personally, i'm not sure it's desirable to keep it off of bitcoin, but if
it is, the only sure way to disincentivize it is to go at it in this way or
similar

i suspect all the opcode validation suggestions are just silly.   ordinals
can time their fork to the same moment, and store data in a less efficient,
but still functional, way using any number of mechanisms.   we've had
similar things posted on-chain since 2010 (my favorite was a software
license key - in an attempt to make bitcoin nodes illegal.   it's still in
there)


On Mon, May 8, 2023 at 4:36 PM Michael Folkson <
michaelfolk...@protonmail.com> wrote:

> > im unclear as to the purpose paying an onchain transaction fee greater
> than the amount receiving could possibly serve.
>
> If you expect fees to continue to rise and be sustained at abnormally high
> levels for a long period of time you might seek to close your Lightning
> channel(s) and move whatever value you can from these Lightning channel(s)
> onchain even if it means paying a higher fee than the amount you are
> receiving.
>
> I don't necessarily recommend doing this (it would depend on a number of
> factors, both personal and external) but there is no reason to prevent
> someone in say the consensus rules from doing this if they wish.
>
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
>
> Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
>
> --- Original Message ---
> On Monday, May 8th, 2023 at 20:47, Erik Aronesty  wrote:
>
> im unclear as to the purpose paying an onchain transaction fee greater
> than the amount receiving could possibly serve.
>
> what benefit do you get aside from losing bitcoin?
>
> are there any, non-theoretical, benefits to facilitating dust transactions?
>
> we could, of course, have it be non-consensus (no route dust) to start with
>
>
>
>
>
> On Mon, May 8, 2023 at 1:13 PM Michael Folkson <
> michaelfolk...@protonmail.com> wrote:
>
>> > probably easier just to reject any transaction where the fee is higher
>> than the sum of the outputs
>>
>> And prevent perfectly reasonable transfers of value and attempted
>> Lightning channel closes during fee spikes? If I *want*​ to close my
>> Lightning channel during a protracted fee spike where I have to pay an
>> onchain transaction fee greater than the amount I am receiving you want to
>> stop me doing that? You are impinging on a valid use case as well as
>> requiring a consensus rule change.
>>
>> --
>> Michael Folkson
>> Email: michaelfolkson at protonmail.com
>> GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
>>
>> Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
>>
>> --- Original Message ---
>> On Monday, May 8th, 2023 at 13:58, Erik Aronesty via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> probably easier just to reject any transaction where the fee is higher
>> than the sum of the outputs
>>
>>
>>
>> On Mon, May 8, 2023, 7:55 AM Ali Sherief via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> Hi guys,
>>>
>>> I think everyone on this list knows what has happened to the Bitcoin
>>> mempool during the past 96 hours. Due to side projects such as BRC-20
>>> having such a high volume, real bitcoin transactions are being priced out
>>> and that is what is causing the massive congestion that has arguable not
>>> been seen since December 2017. I do not count the March 2021 congestion
>>> because that was only with 1-5sat/vbyte.
>>>
>>> Such justifiably 

Re: [bitcoin-dev] [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes?

[Erik Aronesty via bitcoin-dev]

the more i think about it, the more that this is essential.   consider that
bitcoin is secured by mining and mining is secured by fees.   all of that
is relative to the value of bitcoin itself.   but consider the incentive
for a reorg if a single ordinal is worth 1 billion dollars and is being
transferred.  now all the incentive logic is thrown to the wind.
 non-monetary use is quite dangerous to network stability, and the game
theory underpinning it, imo.

On Mon, May 8, 2023 at 4:59 PM Erik Aronesty  wrote:

> > value you can from these Lightning channel(s) onchain even if it means
> paying a higher fee than the amount you are receiving.
>
> in that case, you're not getting any value - you're losing value.   the
> only benefit i could imagine would be to prevent the other party from
> having access to the funds should the channel expire.
>
> regardless, this is an edge case.   it's clear that a utxo whose value is
> less than the fee paid to move it is dust, and we already have plenty of
> code to censor dust transactions
>
> > no reason to prevent
>
> the reason to prevent them is to prevent something that has more value
> than the bitcoin itself from being stored on-chain.  that is to say:
> real-estate ownership, nfts, or any other thing that isn't "using bitcoin
> as money"
>
> by going at the "incentive/economic layer", rather than pointlessly
> forcing brc-20 and ordinals users to obfuscate their transactions, we can
> provide a permanent incentive to keep that stuff off of bitcoin
>
> personally, i'm not sure it's desirable to keep it off of bitcoin, but if
> it is, the only sure way to disincentivize it is to go at it in this way or
> similar
>
> i suspect all the opcode validation suggestions are just silly.   ordinals
> can time their fork to the same moment, and store data in a less efficient,
> but still functional, way using any number of mechanisms.   we've had
> similar things posted on-chain since 2010 (my favorite was a software
> license key - in an attempt to make bitcoin nodes illegal.   it's still in
> there)
>
>
> On Mon, May 8, 2023 at 4:36 PM Michael Folkson <
> michaelfolk...@protonmail.com> wrote:
>
>> > im unclear as to the purpose paying an onchain transaction fee greater
>> than the amount receiving could possibly serve.
>>
>> If you expect fees to continue to rise and be sustained at abnormally
>> high levels for a long period of time you might seek to close your
>> Lightning channel(s) and move whatever value you can from these Lightning
>> channel(s) onchain even if it means paying a higher fee than the amount you
>> are receiving.
>>
>> I don't necessarily recommend doing this (it would depend on a number of
>> factors, both personal and external) but there is no reason to prevent
>> someone in say the consensus rules from doing this if they wish.
>>
>> --
>> Michael Folkson
>> Email: michaelfolkson at protonmail.com
>> GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
>>
>> Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
>>
>> --- Original Message ---
>> On Monday, May 8th, 2023 at 20:47, Erik Aronesty  wrote:
>>
>> im unclear as to the purpose paying an onchain transaction fee greater
>> than the amount receiving could possibly serve.
>>
>> what benefit do you get aside from losing bitcoin?
>>
>> are there any, non-theoretical, benefits to facilitating dust
>> transactions?
>>
>> we could, of course, have it be non-consensus (no route dust) to start
>> with
>>
>>
>>
>>
>>
>> On Mon, May 8, 2023 at 1:13 PM Michael Folkson <
>> michaelfolk...@protonmail.com> wrote:
>>
>>> > probably easier just to reject any transaction where the fee is
>>> higher than the sum of the outputs
>>>
>>> And prevent perfectly reasonable transfers of value and attempted
>>> Lightning channel closes during fee spikes? If I *want* to close my
>>> Lightning channel during a protracted fee spike where I have to pay an
>>> onchain transaction fee greater than the amount I am receiving you want to
>>> stop me doing that? You are impinging on a valid use case as well as
>>> requiring a consensus rule change.
>>>
>>> --
>>> Michael Folkson
>>> Email: michaelfolkson at protonmail.com
>>> GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
>>>
>>> Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
>>>
>>> --- Original Message ---
>>> On Monday, May 8th, 2023 at 13:

Re: [bitcoin-dev] [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes?

[Erik Aronesty via bitcoin-dev]

im unclear as to the purpose paying an onchain transaction fee greater than
the amount receiving could possibly serve.

what benefit do you get aside from losing bitcoin?

are there any, non-theoretical, benefits to facilitating dust transactions?

we could, of course, have it be non-consensus (no route dust) to start with





On Mon, May 8, 2023 at 1:13 PM Michael Folkson <
michaelfolk...@protonmail.com> wrote:

> > probably easier just to reject any transaction where the fee is higher
> than the sum of the outputs
>
> And prevent perfectly reasonable transfers of value and attempted
> Lightning channel closes during fee spikes? If I *want*​ to close my
> Lightning channel during a protracted fee spike where I have to pay an
> onchain transaction fee greater than the amount I am receiving you want to
> stop me doing that? You are impinging on a valid use case as well as
> requiring a consensus rule change.
>
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
>
> Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
>
> --- Original Message ---
> On Monday, May 8th, 2023 at 13:58, Erik Aronesty via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> probably easier just to reject any transaction where the fee is higher
> than the sum of the outputs
>
>
>
> On Mon, May 8, 2023, 7:55 AM Ali Sherief via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Hi guys,
>>
>> I think everyone on this list knows what has happened to the Bitcoin
>> mempool during the past 96 hours. Due to side projects such as BRC-20
>> having such a high volume, real bitcoin transactions are being priced out
>> and that is what is causing the massive congestion that has arguable not
>> been seen since December 2017. I do not count the March 2021 congestion
>> because that was only with 1-5sat/vbyte.
>>
>> Such justifiably worthless ("worthless" is not even my word - that's how
>> its creator described them[1]) tokens threaten the smooth and normal use of
>> the Bitcoin network as a peer-to-pear digital currency, as it was intended
>> to be used as.
>>
>> If the volume does not die down over the next few weeks, should we take
>> an action? The bitcoin network is a triumvirate of developers, miners, and
>> users. Considering that miners are largely the entities at fault for
>> allowing the system to be abused like this, the harmony of Bitcoin
>> transactions is being disrupted right now. Although this community has a
>> strong history of not putting its fingers into pies unless absolutely
>> necessary - an example being during the block size wars and Segwit - should
>> similar action be taken now, in the form of i) BIPs and/or ii) commits into
>> the Bitcoin Core codebase, to curtail the loophole in BIP 342 (which
>> defines the validation rules for Taproot scripts) which has allowed these
>> unintended consequences?
>>
>> An alternative would be to enforce this "censorship" at the node level
>> and introduce a run-time option to instantly prune all non-standard Taproot
>> transactions. This will be easier to implement, but won't hit the road
>> until minimum next release.
>>
>> I know that some people will have their criticisms about this,
>> absolutists/libertarians/maximum-freedom advocates, which is fine, but we
>> need to find a solution for this that fits everyone's common ground. We
>> indirectly allowed this to happen, which previously wasn't possible before.
>> So we also have a responsibility to do something to ensure that this kind
>> of congestion can never happen again using Taproot.
>>
>> -Ali
>>
>> ---
>>
>> [1]:
>> https://www.coindesk.com/consensus-magazine/2023/05/05/pump-the-brcs-the-promise-and-peril-of-bitcoin-backed-tokens/
>> <https://www.coindesk.com/consensus-magazine/2023/05/05/pump-the-brcs-the-promise-and-peril-of-bitcoin-backed-tokens/?outputType=amp>
>> ___
>> 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] [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes?

[Erik Aronesty via bitcoin-dev]

probably easier just to reject any transaction where the fee is higher than
the sum of the outputs



On Mon, May 8, 2023, 7:55 AM Ali Sherief via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi guys,
>
> I think everyone on this list knows what has happened to the Bitcoin
> mempool during the past 96 hours. Due to side projects such as BRC-20
> having such a high volume, real bitcoin transactions are being priced out
> and that is what is causing the massive congestion that has arguable not
> been seen since December 2017. I do not count the March 2021 congestion
> because that was only with 1-5sat/vbyte.
>
> Such justifiably worthless ("worthless" is not even my word - that's how
> its creator described them[1]) tokens threaten the smooth and normal use of
> the Bitcoin network as a peer-to-pear digital currency, as it was intended
> to be used as.
>
> If the volume does not die down over the next few weeks, should we take an
> action? The bitcoin network is a triumvirate of developers, miners, and
> users. Considering that miners are largely the entities at fault for
> allowing the system to be abused like this, the harmony of Bitcoin
> transactions is being disrupted right now. Although this community has a
> strong history of not putting its fingers into pies unless absolutely
> necessary - an example being during the block size wars and Segwit - should
> similar action be taken now, in the form of i) BIPs and/or ii) commits into
> the Bitcoin Core codebase, to curtail the loophole in BIP 342 (which
> defines the validation rules for Taproot scripts) which has allowed these
> unintended consequences?
>
> An alternative would be to enforce this "censorship" at the node level and
> introduce a run-time option to instantly prune all non-standard Taproot
> transactions. This will be easier to implement, but won't hit the road
> until minimum next release.
>
> I know that some people will have their criticisms about this,
> absolutists/libertarians/maximum-freedom advocates, which is fine, but we
> need to find a solution for this that fits everyone's common ground. We
> indirectly allowed this to happen, which previously wasn't possible before.
> So we also have a responsibility to do something to ensure that this kind
> of congestion can never happen again using Taproot.
>
> -Ali
>
> ---
>
> [1]:
> https://www.coindesk.com/consensus-magazine/2023/05/05/pump-the-brcs-the-promise-and-peril-of-bitcoin-backed-tokens/
> 
> ___
> 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] tx max fee

[Erik Aronesty via bitcoin-dev]

possible to change tx "max fee"  to output amounts?

seems like the only use case that would support such a tx is spam/dos type
stuff that satoshi warned about

its not a fix for everything, but it seems could help a bit with certain
attacks
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions

[Erik Aronesty via bitcoin-dev]

i think the w3c is a very good example of a slow train wreck, and we should
do everything possible to avoid the decisions they made

On Thu, Apr 20, 2023 at 7:09 AM Aymeric Vitte via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Personnally I will never criticize the maintainers, but my comment was
> about the global process, I thought that for something important like
> bitcoin there were many devs/maintainers, and as you point out, a PR
> must be done by certified people
>
> I don't get very well why every company involved in bitcoin do not put
> at least one person in this process (a bit like W3C specs), with
> different time zone so every time you wake up you don't have to look
> at/handle hundreds of requests/comments
>
> And we can read in the press that bitcoin maintenance is supposed to
> cost 200M per year, probably false then, but this is worrying to see
> that devs/maintainers are stepping down one after the other
>
>
> Le 19/04/2023 à 23:33, Andrew Chow via bitcoin-dev a écrit :
> > Responses in-line.
> > Note that the opinions expressed in this email are my own and are not
> > representative of what other maintainers think or believe.
> >
> > On 04/18/2023 08:40 AM, Michael Folkson via bitcoin-dev wrote:
> >  >
> >  > Communication has been a challenge on Bitcoin Core for what I can
> > tell the entire history of the project. Maintainers merge a pull request
> > and provide no commentary on why they’ve merged it.
> >
> > What commentary does there need to be?
> > It's self evident that the maintainer believes the code is ready to be
> > merged, and has observed enough ACKs from contributors that they are
> > comfortable to do so.
> > You're welcome to ask for clarification, but frankly, I don't think
> > having any commentary on merges is going to be helpful or more elaborate
> > in any way.
> > Requiring maintainers to have to write explanations for every single
> > merge is simply going to increase the burden on them and increase the
> > rate of burnout and resignations.
> > We've had too many maintainers step down already.
> > It'll end up being a bunch of boilerplate comments that don't say
> > anything meaningful.
> >
> > There are certainly situations where PRs are merged very quickly or with
> > otherwise little apparent review.
> > But, as I said, if you ask a maintainer why it was merged, the answer
> > will be "I thought it was ready and had enough review".
> > There may be other reasons that made the maintainer think it was ready
> > sooner, such as the PR fixes a critical bug or security vulnerability,
> > but these reasons aren't going to be stated publicly.
> >
> >  > Maintainers leave a pull request with many ACKs and few (if any)
> > NACKs for months and provide no commentary on why they haven't merged it.
> >
> > There are currently 320 open PRs and 366 open issues.
> > I wake up every morning to 150+ email notifications containing
> > everything that went on overnight, and throughout the day, I typically
> > get hundreds more.
> > It's impossible to keep up with everything that goes on throughout the
> repo.
> > ACKs come in sporadically, PRs are updated, reviews are posted, etc.
> > Often times PRs are not merged simply because the maintainers were not
> > aware that a PR was ready to be merged.
> > Things can simply fall through the cracks.
> >
> > Of course there are other reasons why something might not be merged, and
> > these generally fall into the camp of "I don't think it has had enough
> > review".
> > It's the maintainer's judgement call to make as to whether something has
> > been sufficiently reviewed, and part of the judgement call is to
> > consider the quality and competence of the reviewers.
> > If a PR had 100 ACKs but all from random people who have never
> > contributed to the project in any capacity, then it's not going to be
> > merged because those reviewers would be considered low quality.
> > It's not just about the numbers, but also about whether the reviewers
> > are people the maintainers think are familiar enough with an area and
> > have had a history of thoroughly reviewing PRs.
> > For example, if a reviewer who primarily works on the mempool reviewed a
> > PR in the wallet, I would consider their review and ACK with less weight
> > because they are unlikely to be familiar with the intricacies of the
> wallet.
> > Obviously that changes over time as they make more reviews.
> > For another example, if I see an ACK from a reviewer who posts reviews
> > that primarily contain nits on code style and other trivialities, I
> > would consider that ACK with less weight.
> >
> > Furthermore, the maintainers are not necessarily the ones who block a
> merge.
> > Part of evaluating if something is ready to be merged is to read the
> > comments on a PR.
> > Other frequent contributors may have commented or asked questions that
> > haven't been resolved yet.
> > PRs will often not be merged (even if they have ACKs) until a maintainer
> > dee

Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions

[Erik Aronesty via bitcoin-dev]

yes, the code itself was far less contentious than the weird stab at
forking the network

there remains a real chance that bip 119 is the simplest and most flexible
and reasonably safe covenant tech for many use cases

although im partial to 118 as well because lightning is a killer app and it
makes batch channels more efficient



On Tue, Apr 18, 2023, 7:39 PM Michael Folkson via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Communication has been a challenge on Bitcoin Core for what I can tell the
> entire history of the project. Maintainers merge a pull request and provide
> no commentary on why they’ve merged it. Maintainers leave a pull request
> with many ACKs and few (if any) NACKs for months and provide no commentary
> on why they haven't merged it. I can only speculate on why and it probably
> depends on the individual maintainer. Sometimes it will be poor
> communication skills, sometimes it will be a desire to avoid
> accountability, sometimes it will be fear of unreasonable and spiteful
> legal action if they mistakenly merge a pull request that ends up
> containing a bug. But search through the pull requests on Bitcoin Core and
> you will rarely see a rationale for a merge decision. The difference
> between say previous maintainers like Wladimir and some of the current
> maintainers is that previous maintainers were extremely responsive on IRC.
> If you disagreed with a merge decision or thought it had been merged
> prematurely they would be happy to discuss it on IRC. In present times at
> least a subset of the current maintainers are not responsive on IRC and
> will refuse to discuss a merge decision. One farcical recent example [0]
> was the pull request to add Vasil Dimov as a maintainer where despite many
> ACKs from other maintainers and other long term contributors two
> maintainers (fanquake and Gloria) refused to discuss it on the pull request
> or on IRC. It took almost 5 months for Gloria to comment on the pull
> request despite many requests from me on the PR and on IRC. I even
> requested that they attend the weekly Core Dev IRC meeting to discuss it
> which they didn’t attend.
>
>
> A pull request to add a maintainer isn’t a normal pull request. Generally
> pull requests contain a lot more lines of code than a single line adding a
> trusted key. Not merging a pull request for a long period of time can be
> extremely frustrating for a pull request author especially when maintainers
> and long term contributors don’t comment on the pull request and the pull
> request is stuck in “rebase hell”. Clearly it is the lesser evil when
> compared to merging a harmful or bug ridden pull request but poor
> non-existent communication is not the only way to prevent this. Indeed it
> creates as many problems as it solves.
>
>
> Another farcical recent(ish) example was the CTV pull request [1] that
> ultimately led to a contentious soft fork activation attempt that was
> called off at the last minute. If you look at the comments on the pull
> request there were 3 individuals (including myself) who NACKed the pull
> request and I think it is fair to say that none of us would be considered
> long term contributors to Bitcoin Core. I have criticised Jeremy Rubin
> multiple times for continuing to pursue a soft fork activation attempt when
> it was clear it was contentious [3] but if you look at the pull request
> comments it certainly isn’t clear it was. Maintainers and long term
> contributors (if they commented at all) were gently enthusiastic (Concept
> ACKing etc) without ACKing that it was ready to merge. A long term observer
> of the Core repo would have known that it wasn’t ready to merge or ready to
> attempt to activate (especially given it was a consensus change) but a
> casual observer would have only seen Concept ACKs and ACKs with 3 stray
> NACKs. Many of these casual observers inflated the numbers on the
> utxos.org site [4] signalling support for a soft fork activation attempt.
>
>
> I set out originally to write about the controls and processes around
> merges on the default signet (bitcoin-inquisition [5]) but it quickly
> became obvious to me that if communication around Core merges/non-merges is
> this weak you can hardly expect it to be any better on
> bitcoin-inquisition/default signet where there is no real monetary value at
> stake. I will probably write about bitcoin-inquisition/default signet in a
> future email as I do think the perception that it is “the one and only”
> staging ground for consensus changes is dangerous [6] if the maintainer(s)
> on that project have the same inclinations as a subset of the Core
> maintainers.
>
>
> As I stated at the beginning there is an element to this which is not
> individual(s) specific and an adverse reaction to outright malicious actors
> external to any of these projects. I do not think any of the current
> maintainers on Core or bitcoin-inquisition are outright malicious even if a
> subset of them consistently fr

Re: [bitcoin-dev] Refreshed BIP324

[Erik Aronesty via bitcoin-dev]

you can always do what protocols usually do.   1 byte is fine for now, but
reserve the top bit for "this is a two byte id" (128 choices).   then when
you run out of room, set the top bit which means "this is a 2 byte id
(again with one reserved) and so-on.   ie: how protobuf stores integers.

On Tue, Feb 28, 2023 at 1:42 PM Dhruv M via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> The relevant changes from this discussion about short 1-byte message
> type IDs are now in a PR for the bips repo:
> https://github.com/bitcoin/bips/pull/1428
>
> On 2/21/23 08:03, Anthony Towns via bitcoin-dev wrote:
> > On Mon, Feb 20, 2023 at 03:22:30PM +, Pieter Wuille via bitcoin-dev
> wrote:
> >> On Sunday, February 19th, 2023 at 6:56 PM, Anthony Towns <
> a...@erisian.com.au> wrote:
> >>> On Fri, Feb 17, 2023 at 10:13:05PM +, Pieter Wuille via
> bitcoin-dev wrote:
> > I think it's probably less complex to close some of the doors?
> > 2) are short ids available/meaningful to send prior to VERACK being
> > completed?
> > Ah, I hadn't considered this nuance. If we don't care about them
> being available before VERACK negotiation, then it may be possible to
> introduce a way to negotiate a different short id mapping table without
> needing a mechanism for re-negotiating.
> >>> I think you still need/want two negotiation steps -- once to tell each
> >>> other what tables you know about, once to choose a mutually recognised
> >>> table and specify any additions.
> >> Right, I wasn't talking about how many steps/messages the negotiation
> takes. I just meant that if all negotiation of the mapping table happens
> just once (before VERACK) and that negotiation itself happens without use
> of short commands, then there is no need for re-negotiating short commands
> after they are already in use. Nothing concrete, but I can imagine that
> that may simplify some implementations.
> > Yeah; I was just thinking of the fact that currently the negotiation is:
> >
> >   * send your VERSION message
> >   * see what their VERSION message is
> >
> >   * announce a bunch of features, depending on the version (or service
> > flags)
> >   * send the VERACK (and GETADDR and final ALERT)
> >
> >   * wait for their announcements and VERACK
> >   * negotiation is finished; we know everything; we're ready to go
> >
> > which only gets you two steps if you send the short id stuff as part of
> > the VERSION message. Obviously you could just add an extra phase either
> > just before or just after the VERACK, though.
> >
> > I suppose being able to choose your own short id mapping from day 0 would
> > mean that every bip324 node could use a single short id mapping for all
> > outgoing messages, which might also make implementation marginally easier
> > (no need to use one table for modern nodes, but also support the original
> > table for old bip324 implementations)...
> >
> > Cheers,
> > aj
> > ___
> > 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] Ordinal Inscription Size Limits

[Erik Aronesty via bitcoin-dev]

there are already images encoded in the chain using multisig.  when we
eliminated the max-witness size in 2017, that made it a bit cheaper, that's
all (one tx instead of many)

https://www.righto.com/2014/02/ascii-bernanke-wikileaks-photographs.html

my favorite one is the javascript exploit for people that like to render
untrusted blockchain data in their browser

the script to interpret these is trivial, and it's not much harder to add a
mime type



On Mon, Feb 6, 2023 at 12:34 PM Claus Ehrenberg via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> The inscriptions are designed to be easy to use, they even specify that
> mime types should be used. I'd say, the way the data is stored is anything
> but 'obscure'. UIs will be popping up to make this really easy. The main
> chain can't be censored, what's in a block is in a block. I'm predicting a
> huge success.
>
> So, are we ready to accept that we'll likely see the first pictures with
> insults or worse in the Bitcoin chain? I really like the idea, but the risk
> is pretty obvious. I think it would be prudent to have at least an opt-out
> feature for the data. So that it's possible to use the chain without the
> potentially malicious content. That means the content shouldn't live in the
> essential data of the main chain. Better would be something like the
> extension blocks in Litecoin.
>
> Best Regards
> Claus
>
> On Fri, Jan 27, 2023 at 1:47 PM Robert Dickinson via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> I'm curious what opinions exist and what actions might be taken by core
>> developers regarding storing unlimited amounts of NFT (or other?) content
>> as witness data (https://docs.ordinals.com/inscriptions.html). The
>> ordinal scheme is elegant and genius IMHO, but when I think about the
>> future disk use of all unpruned nodes, I question whether unlimited storage
>> is wise to allow for such use cases. Wouldn't it be better to find a way to
>> impose a size limit similar to OP_RETURN for such inscriptions?
>>
>> I think it would be useful to link a sat to a deed or other legal
>> construct for proof of ownership in the real world, so that real property
>> can be transferred on the blockchain using ordinals, but storing the
>> property itself on the blockchain seems nonsensical to me.
>> ___
>> 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] Ordinal Inscription Size Limits

[Erik Aronesty via bitcoin-dev]

its trivial to store images in such a way that they look like legit
transactions.

this was done, in the past, using large numbers of multisig output
addresses that encode the images.

given the goals of the project, introducing this sort of censorship into
bitcoin seems fundamentally undesirable
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Ordinal Inscription Size Limits

[Erik Aronesty via bitcoin-dev]

my only concern is that as block space gets limited the likelihood of soft
fork opcode tech improvement proposals getting accepted by the community
goes down

schnorr sigs are extremely useful to me (anon, cheap multisig)

and some sort of vault tech would be very helpful as well
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] A proposal for Full RBF to not exclude Zero Conf use case

[Erik Aronesty via bitcoin-dev]

> 0-conf on Bitcoin with its understood risks is a significant use case

and that use case doesn't change, at all, with full rbf.   the risk profile
will, likely, remain the same.   observation of the fee paid, history of
doing business with the customer, transaction size are all needed.

On Mon, Jan 16, 2023 at 1:50 PM Daniel Lipshitz via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Some further clarity on our unique trx hashes queried to our platform, our
> initial and followup numbers on unique trx hashes queried were not accurate
> - apologies. Bitcoin addresses queried and Usd value and unique were
> accurate. This is as a result of our platform viewing each queried bitcoin
> address as a transaction from our point of view.
>
>  November 2022
>   Total queried unique bitcoin address- circa 1.5m trxs
>   Unique Bitcoin trx hashes queried- circa 500k
>   USD value - circa 220m
>   December 2022
>Total queried unique bitcoin address- circa 1.7m trxs
>Unique Bitcoin trx hashes queried - circa 500k
>USD value - circa 200m
>
> There are further merchants and service providers who enable 0-conf on
> Bitcoin who are not working via our platform - I do not know their numbers
> but believe they are significant. 0-conf on Bitcoin with its understood
> risks is a significant use case.
>
> For third party clarification please see
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021239.html
> and
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021238.html
> 
>
> Daniel Lipshitz
> GAP600| www.gap600.com
>
>
>
>
> On Sat, Jan 14, 2023 at 10:15 PM Daniel Lipshitz 
> wrote:
>
>>
>>
>>
>> On Sat, Jan 14, 2023 at 1:53 AM Peter Todd  wrote:
>>
>>> On Sun, Dec 18, 2022 at 10:06:15AM +0200, Daniel Lipshitz wrote:
>>> > GAP600 is not a trxs processor or liquidity provider we service
>>> merchants,
>>> > payment processors & non-custodial liquidity providers - our service is
>>> > purely the 0-conf enabling our clients to accept 0-conf. Clients
>>> access our
>>> > service via API - sending us the Trx hash & output address. Our
>>> service is
>>> > not based on AML/KYC it is purely an analysis of the Bitcoin network.
>>>
>>> I checked and to sign up for your service, you ask for the name, phone
>>> number,
>>> email, and company name.
>>>
>>> That is an example of AML/KYC. By learning the tx hash and output
>>> address, you
>>> learn which addresses are associated with what real world entity is
>>> paying for
>>> your service. You learning that information for what you claim is ~10%
>>> of all
>>> transactions is a significant privacy concern. On that basiss alone, I
>>> would
>>> argue that full-rbf should be implemented specifically to destroy your
>>> business
>>> and stop the collection of that data.
>>>
>>> We have standard commercial information about the payment processors,
>> non custodial liquidity providers and merchants which become our clients -
>> we do not have any kyc/aml information or telephone number on who is
>> sending our clients the bitcoin for deposit.  For us these are just bitcoin
>> Trx which our clients choose to benefit from 0-conf deposit recognition.
>> Our service is provided via API with the only information our clients share
>> with us, regarding a specific bitcoin transaction, being public bitcoin
>> information like trx hash and output address.
>>
>> > I am not at liberty to share names of other services which have
>>> developed
>>> > their own 0-conf service - they include a payment processor on a
>>> gambling
>>> > platform which services multiple gambling operators, a standalone
>>> gaming
>>> > payment processor, and a payment processor recently I have come
>>> across. We
>>> > also do not have a significant presence in Asia - so I don't have
>>> > visibility there.
>>>
>>> No, I asked you for information on what companies are actually using
>>> *your*
>>> service. You claim to be involved with a huge % of all transactions. If
>>> that is
>>> in fact true, obviously it shouldn't be hard to provide some examples of
>>> merchants using GAP600 to accept unconfirmed txs.
>>>
>>
>> As already posted here
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021240.html
>> Max CEO from Coinspaid who has provided Cpoinspaid address clusters, see
>> link, is available to discuss further and may choose to share further
>> information on the merchants they support.
>>
>>>
>>> > I don't see it being necessarily an either/or approach here. The risk
>>> > looking to be mitigated with FullRBF seems to be able to be mitigated
>>> with
>>> > FullRBF but with a swop limitation of at least the Inputs of Trx1
>>> being in
>>> > Trx2 - no flagging required. Added to this all these trxs always have
>>> the
>>> > OptinRBF so if these platforms need to be able to recreate completely
>>> their
>>> > trxs they have that option as well. The option to Swop out or bump up
>>> trxs
>>> > se

Re: [bitcoin-dev] A proposal for Full RBF to not exclude Zero Conf use case

[Erik Aronesty via bitcoin-dev]

NACK

support for 0-conf is harmful for reasons already stated ad nauseum



On Wed, Dec 14, 2022 at 4:58 AM Daniel Lipshitz via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> A 0-conf double spend caused by FSS-RBF would be harmless since the
> original output (address and amounts) remain in the double spending trx.
>
> So all a merchant would need to do is monitor  block inclusion for the
> relevant output. Addition of some wallet logic would resolve it easily.
>
> Technically the only difference is that a FSS-RBF requires an additional
> input trx to be included in the second trx.
>
> Not clear to me, why the limitation of adding an additional input hinders
> the added value of FullRBF and how significant that hinderance is.
>
>
>
> On Tue, 13 Dec 2022 at 11:59 John Carvalho  wrote:
>
>> Why wasn't this solution put in place back then? Are there problems with
>> the design?
>>
>> While I still think there are unhealthy side-effects of Full-RBF (like
>> more doublespending at unknowing merchants, after years of FSS protection)
>> I think discussion of this FSS-RBF feature is worth considering.
>>
>> --
>> John Carvalho
>> CEO, Synonym.to 
>>
>>
>> On Tue, Dec 13, 2022 at 8:09 AM Daniel Lipshitz 
>> wrote:
>>
>>> Thank you for bringing that to my attention, apologies for not being
>>> aware of it.
>>>
>>> First-seen-safe replace-by-fee as detailed here
>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008248.html
>>> by Peter Todd  seems to be a very suitable option and route
>>> which balances FullRBF while retaining  the significant 0-conf use case.
>>>
>>> This would seem like a good way forward.
>>>
>>>
>>>
>>> 
>>>
>>>
>>>
>>> On Tue, Dec 13, 2022 at 6:20 AM Yuval Kogman 
>>> wrote:
>>>

 https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008248.html

>>> --
> 
> Daniel Lipshitz
> GAP600
> www.Gap600.com
>
>
> ___
> 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] [Opt-in full-RBF] Zero-conf apps in immediate danger (angus)

[Erik Aronesty via bitcoin-dev]

>
>
>
> Many zero-conf proponents work on the bleeding edge of supporting
> Lightning, including myself. Lightning is not risk-free and the base layer
> should not be assuming it as a primary dependency for commercial payments.
>

for low-value payments, lightning is the only workable version because the
current low-fee environment is not scalable and never will be

for high valued payments, zero conf was never valuable or useful and never
can be - it was always the beneficence of users you are relying on   low
fee/high fee double spends of a zero conf with no rbf flag has
been demonstrated, repeatedly ad nauseum.

... so there is no long term scenario where zero conf is valuable.

right *now* with low fees it might "seem nice", but really it just
incentivises network-wide surveillance, increased peer burden on nodes, and
unsustainable practices that are akin to a "mev" bounty hanging over
merchant's heads.

also, i've been using bitcoin for years without zero conf.   selling and
buying online.   operating merchants with millions in transactions.   the
20 minute wait before i ship is meaningless, and the only risk i take on is
that a user replaces a transaction with a different destination.   which
i've never observed.   even with the flag on (which i dont care about, and
never have).

and if i do observe it ... i just won't ship.   it was easy to code up.
 the user will have to initiate a new tx.   i have no objection to a user
being able to cancel their order.   why would i?


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

Re: [bitcoin-dev] Announcement: Full-RBF Miner Bounty

[Erik Aronesty via bitcoin-dev]

note: if it was possible to enforce this, we wouldn't need proof of work at
all.   since it isn't possible, proof of work is strictly necessary.


On Mon, Dec 5, 2022 at 9:53 AM Rijndael via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Good morning,
>
> That sounds like a very dangerous mode of operation. You can already hand
> a transaction to a miner privately. I hand a transaction to a miner with
> some reasonable fee, and then I go and broadcast a different transaction
> with a minimal fee that spends the same inputs. The whole network
> (including the miner I handed the tx to) could all be running with a strict
> first-seen mempool policy, but we can still have a situation where the
> miner creates a block with a different transaction from what you see in
> your mempool. If anytime this happens, the nodes running your proposed rule
> drop the block, then anyone can fork those nodes off the network whenever
> they want.
>
> Even outside of adversarial settings, Bitcoin doesn't (and doesn't attempt
> to) promise consistency across mempools. Making a consensus rule that
> enforces mempool consistency is a recipe for (unintended?) chainsplits.
>
> - rijndael
>
>
> On 12/5/22 7:20 AM, El_Hoy via bitcoin-dev wrote:
>
> The only option I see against the attack Peter Todd is doing to opt-in RBF
> and 0Conf bitcoin usage is working on a bitcoin core implementation that
> stops propagation of full-rbf replaced blocks. Running multiple of such
> nodes on the network will add a risk to miners that enable full-rbf that
> would work as an incentive against that.
>
> Obviously that would require adding an option on bitcoin core (that is not
> technically but politically difficult to implement as Petter Todd already
> have commit access to the main repository).
>
> That said, a sufficiently incentivized actor (like Daniel Lipshitz or Muun
> wallet developers) could work on a fork and run several nodes with such
> functionality. As far as I understand the percolation model, with 10 to 20
> nodes running such a rule would create a significant risk for full-rbf
> miners.
>
> Regards.
>
> ---  Eloy
>
>
> On Tue, Nov 15, 2022 at 11:43 AM Peter Todd via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> On Tue, Nov 15, 2022 at 03:36:08PM +1000, Anthony Towns via bitcoin-dev
>> wrote:
>> > On Tue, Nov 08, 2022 at 01:16:13PM -0500, Peter Todd via bitcoin-dev
>> wrote:
>> > > FYI I've gotten a few hundred dollars worth of donations to this
>> effort, and
>> > > have raised the reward to about 0.02 BTC, or $400 USD at current
>> prices.
>> >
>> > Seems like this has been mostly claimed (0.014btc / $235, 9238sat/vb):
>>
>> I'm turning it back on when (if) the mempool settles down. I've got more
>> than
>> enough donations to give another run at it (the majority was donated
>> privately
>> FWIW). There's a risk of the mempool filling up again of course; hard to
>> avoid
>> that.
>>
>> Right now of course it's really easy to double spend with the obvious
>> low-fee/high-fee method as the min relay fee keeps shifting.
>>
>> >
>> https://mempool.space/tx/397dcbe4e95ec40616e3dfc4ff8ffa158d2e72020b7d11fc2be29d934d69138c
>> >
>> > The block it was claimed in seems to have been about an hour after the
>> > default mempool filled up:
>> >
>> > https://twitter.com/murchandamus/status/1592274621977477120
>> >
>> > That block actually seems to have included two
>> > alice.btc.calendar.opentimestamps.org txs, the other paying $7.88
>> > (309sat/vb):
>> >
>> >
>> https://mempool.space/tx/ba9670109a6551458d5e1e23600c7bf2dc094894abdf59fe7aa020ccfead07cf
>>
>> The second is because I turned down the full-rbf reward to more normal fee
>> levels. There's also another full-rbf double-spend from the Bob calendar,
>> along
>> the same lines:
>> 7e76b351009326a574f3120164dbbe6d85e07e04a7bbdc40f0277fcb008d2cd2
>>
>> I double-spent the txin of the high fee tx that got mined. But I
>> mistakenly had
>> RBF enabled in that double-spend, so while it propagated initially, I
>> believe
>> it was replaced when something (someone?) rebroadcast the high-fee 397dcb
>> tx.
>>
>> > Timeline (utc) to me looks like:
>> >
>> >  - 13:12 - block 763148 is mined: last one that had a min fee <
>> 1.5sat/vb
>> >  - 13:33 -
>> f503868c64d454c472859b793f3ee7cdc8f519c64f8b1748d8040cd8ce6dc6e1
>> >is announced and propogates widely (1.2sat/vb)
>> >  - 18:42 -
>> 746daab9bcc331be313818658b4a502bb4f3370a691fd90015fabcd7759e0944
>> >is announced and propogates widely (1.2sat/vb)
>> >  - 21:52 - ba967010 tx is announced and propogates widely, since
>> >conflicting tx 746daab9 has been removed from default
>> >  mempools
>> >  - 21:53 - murch tweets about default mempool filling up
>> >  - 22:03 - 397dcbe4 tx is announced and propogates widely, since
>> >conflicting tx f503868 has already been removed from default
>> >  mempools
>>
>> Is that 22:03 time for 397 from your node's logs?

Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger

[Erik Aronesty via bitcoin-dev]

There has never been any enforcement of miner preferences.   The convention
is changing quickly, since miners are squeezed for cash and want to
capture every nickel, plus there are bounties for full rbf being posted
every day.

I would suggest considering to continue doing business, as usual, as if
full rbf is present.

This means:

- managing risk
- waiting for confirmations if the risk is too high
- using lightning if possible

No other coin or chain offers a safer way to do business than lightning
over bitcoin.




On Thu, Dec 1, 2022 at 7:32 AM Daniel Lipshitz via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> HI All
>
> I am the CEO of GAP600. We guarantee zero confirmed Bitcoin and other
> crypto  transactions, BTC is a primary part of our business. Our guarantee
> enables our customers to recognise zero-conf deposits. We reimburse our
> clients value of the trx should we get it wrong and a transaction we
> confirmed gets double spent.
>
> Should full RBF become default enabled and significantly adopted this
> would have a major impact on the capacity to accept zerof confs on mainnet.
> With the end result being this use case will be forced to move to a
> different chain, with lightning being just another option.
>
> I wanted to share some statistics about how significant this use case is.
> GAP600 clients are primarily payment processors and non custodial
> liquidity providers; you can see some of our clients on our site
> www.gap600.com. There are also merchants who have developed their own
> tools so GAP600 statistics are only a subset of the full use case.
>
> I do not know of any wallet, exchange or custodian who accepts zero conf
> without having some sort of solution in place. The market seems to be fully
> aware of the risks of zero-conf. The opt-RBF seems to be a solution which
> gives a clear free choice for actors.
>
> Statistics for consideration as a sample of the zero conf use case -
>
>
>1. As of end of Nov 2022 - GAP600 has processed i.e responded to circa
>15M transactions
>2. These transactions have a cumulative value of 2.3B USD value.
>3. We currently are seeing circa 1.5M transactions queired per month.
>
>
> It's a sizable amount of trxs on mainet and we are by no means the full
> market of platforms accepting zero-conf.  I realise there are other
> considerations which BTC has,  I would urge you to take into account the
> major risk being placed on this significant market share when deciding to
> make this feature default enabled and encouraging full adoption.
>
> Thank you for your consideration
> Daniel
> 
>
> Daniel Lipshitz
> GAP600| www.gap600.com
>
> ___
> 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] brickchain

[Erik Aronesty via bitcoin-dev]

> I think it's pretty clear that the "competitive nature of PoW" is not
referring to verification nodes

cool, so we can agree there is no accepted centralization pressure for
validating nodes then

> layers also add fees to users

source?  i feel like it's obvious that the tree-like efficiencies should
reduce fees, but i'd appreciate your research on that topic


On Tue, Nov 8, 2022 at 9:25 AM mm-studios  wrote:

>
> --- Original Message ---
> On Tuesday, November 8th, 2022 at 2:16 PM, Erik Aronesty 
> wrote:
>
> > A) to not increase the workload of full-nodes
>
> yes, this is critical
>
> > given the competitive nature of PoW itself
>
> validating nodes do not compete with PoW, i think maybe you are not sure
> of the difference between a miner and a node
>
> nodes do validation of transactions, they do this for free, and many of
> them provide essential services, like SPV validation for mobile
>
>
>
> I think it's pretty clear that the "competitive nature of PoW" is not
> referring to verification nodes (satoshi preferred this other word).
>
> B) to not undermine L2 systems like LN.
>
> yes, as a general rule, layered financial systems are vastly superior. so
> that risks incurred by edge layers are not propagated fully to the inner
> layers. For example L3 projects like TARO and RGB are building on lightning
> with less risk
>
>
> layers also add fees to users
>
>
> On Wed, Oct 19, 2022 at 12:04 PM mm-studios  wrote:
>
>> Thanks all for your responses.
>> so is it a no-go is because "reduced settlement speed is a desirable
>> feature"?
>>
>> I don';t know what weights more in this consideration:
>> A) to not increase the workload of full-nodes, being "less difficult to
>> operate" and hence reduce the chance of some of them giving up which would
>> lead to a negative centralization effect. (a bit cumbersome reasoning in my
>> opinion, given the competitive nature of PoW itself, which introduce an
>> accepted centralization, forcing some miners to give up). In this case the
>> fact is accepted because is decentralized enough.
>> B) to not undermine L2 systems like LN.
>>
>> in any case it is a major no-go reason, if there is not intention to
>> speed up L1.
>> Thanks
>> M
>> --- Original Message ---
>> On Wednesday, October 19th, 2022 at 3:24 PM, Erik Aronesty 
>> wrote:
>>
>> > currently, a miner produce blocks with a limited capacity of
>> transactions that ultimately limits the global settlement throughput to a
>> reduced number of tx/s.
>>
>> reduced settlement speed is a desirable feature and isn't something we
>> need to fix
>>
>> the focus should be on layer 2 protocols that allow the ability to hold &
>> transfer, uncommitted transactions as pools / joins, so that layer 1's
>> decentralization and incentives can remain undisturbed
>>
>> protocols like mweb, for example
>>
>>
>>
>>
>> On Wed, Oct 19, 2022 at 7:34 AM mm-studios via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> Hi Bitcoin devs,
>>> I'd like to share an idea of a method to increase throughput in the
>>> bitcoin network.
>>>
>>> Currently, a miner produce blocks with a limited capacity of
>>> transactions that ultimately limits the global settlement throughput to a
>>> reduced number of tx/s.
>>>
>>> Big-blockers proposed the removal of limits but this didn't come with
>>> undesirable effects that have been widely discussed and rejected.
>>>
>>> The main feature we wanted to preserve is 'small blocks', providing
>>> 'better network effects' I won't focus on them.
>>>
>>> The problem with small blocks is that, once a block is filled
>>> transactions, they are kept back in the mempool, waiting for their turn in
>>> future blocks.
>>>
>>> The following changes in the protocol aim to let all transactions go in
>>> the current block, while keeping the block size small. It requires changes
>>> in the PoW algorithm.
>>>
>>> Currently, the PoW algorithm consists on finding a valid hash for the
>>> block. Its validity is determined by comparing the numeric value of the
>>> block hash with a protocol-defined value difficulty.
>>>
>>> Once a miner finds a nonce for the block that satisfies the condition
>>> the new block becomes valid and can be propagated. All nodes would update
>>> their blockchains with it. (assuming no conflict resolution (orphan blocks,
>>> ...) for clarity).
>>>
>>> This process is meant to happen every 10 minutes in average.
>>>
>>> With this background information (we all already know) I go on to
>>> describe the idea:
>>>
>>> Let's allow a miner to include transactions until the block is filled,
>>> let's call this structure (coining a new term 'Brick'), B0. [brick=block
>>> that doesn't meet the difficulty rule and is filled of tx to its full
>>> capacity]
>>> Since PoW hashing is continuously active, Brick B0 would have a nonce
>>> corresponding to a minimum numeric value of its hash found until it got
>>> filled.
>>>
>>> Fully filled brick B0, with a hash that doesn't meet the 

Re: [bitcoin-dev] brickchain

[Erik Aronesty via bitcoin-dev]

> A) to not increase the workload of full-nodes

yes, this is critical

>  given the competitive nature of PoW itself

validating nodes do not compete with PoW, i think maybe you are not sure of
the difference between a miner and a node

nodes do validation of transactions, they do this for free, and many of
them provide essential services, like SPV validation for mobile


B) to not undermine L2 systems like LN.

yes, as a general rule, layered financial systems are vastly superior.  so
that risks incurred by edge layers are not propagated fully to the inner
layers.  For example L3 projects like TARO and RGB are building on
lightning with less risk

On Wed, Oct 19, 2022 at 12:04 PM mm-studios  wrote:

> Thanks all for your responses.
> so is it a no-go is because "reduced settlement speed is a desirable
> feature"?
>
> I don';t know what weights more in this consideration:
> A) to not increase the workload of full-nodes, being "less difficult to
> operate" and hence reduce the chance of some of them giving up which would
> lead to a negative centralization effect. (a bit cumbersome reasoning in my
> opinion, given the competitive nature of PoW itself, which introduce an
> accepted centralization, forcing some miners to give up). In this case the
> fact is accepted because is decentralized enough.
> B) to not undermine L2 systems like LN.
>
> in any case it is a major no-go reason, if there is not intention to speed
> up L1.
> Thanks
> M
> --- Original Message ---
> On Wednesday, October 19th, 2022 at 3:24 PM, Erik Aronesty 
> wrote:
>
> > currently, a miner produce blocks with a limited capacity of
> transactions that ultimately limits the global settlement throughput to a
> reduced number of tx/s.
>
> reduced settlement speed is a desirable feature and isn't something we
> need to fix
>
> the focus should be on layer 2 protocols that allow the ability to hold &
> transfer, uncommitted transactions as pools / joins, so that layer 1's
> decentralization and incentives can remain undisturbed
>
> protocols like mweb, for example
>
>
>
>
> On Wed, Oct 19, 2022 at 7:34 AM mm-studios via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Hi Bitcoin devs,
>> I'd like to share an idea of a method to increase throughput in the
>> bitcoin network.
>>
>> Currently, a miner produce blocks with a limited capacity of transactions
>> that ultimately limits the global settlement throughput to a reduced number
>> of tx/s.
>>
>> Big-blockers proposed the removal of limits but this didn't come with
>> undesirable effects that have been widely discussed and rejected.
>>
>> The main feature we wanted to preserve is 'small blocks', providing
>> 'better network effects' I won't focus on them.
>>
>> The problem with small blocks is that, once a block is filled
>> transactions, they are kept back in the mempool, waiting for their turn in
>> future blocks.
>>
>> The following changes in the protocol aim to let all transactions go in
>> the current block, while keeping the block size small. It requires changes
>> in the PoW algorithm.
>>
>> Currently, the PoW algorithm consists on finding a valid hash for the
>> block. Its validity is determined by comparing the numeric value of the
>> block hash with a protocol-defined value difficulty.
>>
>> Once a miner finds a nonce for the block that satisfies the condition the
>> new block becomes valid and can be propagated. All nodes would update their
>> blockchains with it. (assuming no conflict resolution (orphan blocks, ...)
>> for clarity).
>>
>> This process is meant to happen every 10 minutes in average.
>>
>> With this background information (we all already know) I go on to
>> describe the idea:
>>
>> Let's allow a miner to include transactions until the block is filled,
>> let's call this structure (coining a new term 'Brick'), B0. [brick=block
>> that doesn't meet the difficulty rule and is filled of tx to its full
>> capacity]
>> Since PoW hashing is continuously active, Brick B0 would have a nonce
>> corresponding to a minimum numeric value of its hash found until it got
>> filled.
>>
>> Fully filled brick B0, with a hash that doesn't meet the difficulty rule,
>> would be broadcasted and nodes would have it on in a separate fork as usual.
>>
>> At this point, instead of discarding transactions, our miner would start
>> working on a new brick B1, linked with B0 as usual.
>>
>> Nodes would allow incoming regular blocks and bricks with hashes that
>> don't satisfy the difficulty rule, provided the brick is fully filled of
>> transactions. Bricks not fully filled would be rejected as invalid to
>> prevent spam (except if constitutes the last brick of a brickchain,
>> explained below).
>>
>> Let's assume that 10 minutes have elapsed and our miner is in a state
>> where N bricks have been produced and the accumulated PoW calculated using
>> mathematics (every brick contains a 'minimum hash found', when a series of
>> 'minimum hashes' is computationally equivalen

Re: [bitcoin-dev] On mempool policy consistency

[Erik Aronesty via bitcoin-dev]

>
>
> With full-rbf, who saw what transaction first doesn't matter: the higher
> fee paying transaction will always(*) replace the lower fee one. With
> opt-in RBF, spamming the network can beat out the alternative.
>

incentivised predictability is critical when designing low level protocols,
like bitcoin.   the knock-on effects of deeper, network-wide predictability
are likely beneficial in ways that are hard to predict.   for example stuff
like the "sabu" protocol might even work if full-rbf is the norm.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Announcement: Full-RBF Miner Bounty

[Erik Aronesty via bitcoin-dev]

actually, peter makes an important point here

technically, all we need is for *miners* to consistently mine "full rbf"

as long as they do, businesses that accept 0conf will have to adjust their
risk accordingly, and the problem of misaligned incentives is resolved

i don't think it matters what non-mining users do nearly as much


On Wed, Nov 2, 2022 at 3:05 PM alicexbt via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi Peter,
>
> > tl;dr: I'm broadcasting full-RBF replacements paying extremely high fees
> to
> > reward miners that turn on full-RBF. I'm starting small, just
> ~$100/block in
> > times of congestion. Miner and pool profit margins are pretty small, on
> the
> > order of $1k/block in many cases, so I know it doesn't take that much
> more
> > money to make a difference.
>
> I appreciate this effort and perhaps this was all that was needed in
> addition to Bitcoin Core's inclusion of full rbf support. Making it default
> right away or enabling preferential peering with service flag in a bitcoin
> core release was unnecessary.
>
> > If you'd like to donate to this effort, send BTC to
> > bc1qagmufdn6rf80kj3faw4d0pnhxyr47sevp3nj9m
>
> Sorry, I don't trust you based on some of the things you support on
> Twitter. Hopefully, others will donate and help this bounty.
>
> /dev/fd0
>
> Sent with Proton Mail secure email.
>
> --- Original Message ---
> On Wednesday, November 2nd, 2022 at 2:56 PM, Peter Todd via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>
> > I'm now running a full-RBf bounty program for miners.
> >
> > tl;dr: I'm broadcasting full-RBF replacements paying extremely high fees
> to
> > reward miners that turn on full-RBF. I'm starting small, just
> ~$100/block in
> > times of congestion. Miner and pool profit margins are pretty small, on
> the
> > order of $1k/block in many cases, so I know it doesn't take that much
> more
> > money to make a difference.
> >
> > Why should you do this? Full-RBF/zeroconf has been discussed to death.
> But
> > tl;dr: You'll earn more money, and help transition Bitcoin to a more
> secure
> > mempool policy based on economic incentives rather than trust.
> >
> >
> > If you're a miner and want to participate, the easiest way to so is to
> use the
> > mempoolfullrbf=1 option in the upcoming Bitcoin Core v24 release (eg the
> > 24.0rc3 tag), or use the mempoolreplacement=fee option in Bitcoin Knots.
> >
> > You can also just modify the code yourself by removing the opt-in RBF
> check.
> > For example against the v23.0 tag:
> >
> > $ git diff
> > diff --git a/src/validation.cpp b/src/validation.cpp
> > index 214112e2b..44c364623 100644
> > --- a/src/validation.cpp
> > +++ b/src/validation.cpp
> > @@ -736,7 +736,7 @@ bool MemPoolAccept::PreChecks(ATMPArgs& args,
> Workspace& ws)
> > // check all unconfirmed ancestors; otherwise an opt-in ancestor
> > // might be replaced, causing removal of this descendant.
> > if (!SignalsOptInRBF(*ptxConflicting)) {
> > - return state.Invalid(TxValidationResult::TX_MEMPOOL_POLICY,
> "txn-mempool-conflict");
> > + // return state.Invalid(TxValidationResult::TX_MEMPOOL_POLICY,
> "txn-mempool-conflict");
> > }
> >
> > ws.m_conflicts.insert(ptxConflicting->GetHash());
> >
> >
> > Once you've enabled full-RBF, you need a full-RBF peer. I'm running a
> few of
> > them:
> >
> > cup.nop.lol
> > mug.nop.lol
> > jar.nop.lol
> > jug.nop.lol
> >
> > These nodes run a preferential peering patch (
> https://github.com/bitcoin/bitcoin/pull/25600)
> > to ensure that full-RBF nodes are interconnected to each other and
> replacements
> > can easily propagate. Also feel free to contact me if you'd like to peer
> with a
> > private node.
> >
> >
> > If you'd like to donate to this effort, send BTC to
> > bc1qagmufdn6rf80kj3faw4d0pnhxyr47sevp3nj9m
> >
> >
> > ...and yes, I'm well aware that miners could collect this bounty in
> other ways,
> > eg by raising minimum fees. Doing that also breaks zeroconf, so I'm not
> too
> > concerned.
> >
> > --
> > 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
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy

[Erik Aronesty via bitcoin-dev]

>
> (the only way to replace a transaction is Replace-By-Fee but this
> implies the transaction that IS TO BE REPLACED has a certain flag set,
> and it is optional).
>

1. full rbf is becoming standard.   tx without full rbf can just be
rejected as a part of the sabu protocol

2. that's fine.  watchtowers can be used to fix this that only have the
ability to stop attacks in progress.   guarantee transactions can include a
small watchtower fee for your favorite always-on watchtower service

3. all parties need to maintain sabu state (it's just another mempool)
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger

[Erik Aronesty via bitcoin-dev]

> Currently Lightning is somewhere around 15% of our total bitcoin
payments. This is very much not nothing, and all of us here want Lightning
to grow, but I think it warrants a serious discussion on whether we want
Lightning adoption to go to 100% by means of disabling on-chain commerce.

Is this about disabling "on-chain instant commerce"?

 - Waiting for confirmation on-chain before shipping a product won't
change, normally it's 15 minutes or so.  This doesn't change that.

 - An easy way to cancel/rbf a transaction doesn't exist - like you said,
there's no UX for this now, and I don't anticipate one being broadly used
except by inter-exchange transfers, etc.

So what does this change?

 - In the rare event that an RBF transaction is received where the fee
level means confirmation times will be slow a merchant will have to wait
very long for at least 1 confirmation, the merchant should alert the user
that the transaction may take longer than the BTC FX rate guarantee window,
and may require additional funds if FX rates change.

 - Users with wallets that support RBF can now be encouraged to accelerate
the tx, with help and advice depending on their wallet, in order to lock in
the FX rates

 - 0 conf is still viable strategy for releasing an order, as long as fees
are very high, and it's very likely to be included in the next block.
 More fee analysis is needed to validate 0 conf and mitigate risks, but now
it is, at least, more "honest" to the true risks.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] brickchain

[Erik Aronesty via bitcoin-dev]

> currently, a miner produce blocks with a limited capacity of transactions
that ultimately limits the global settlement throughput to a reduced number
of tx/s.

reduced settlement speed is a desirable feature and isn't something we need
to fix

the focus should be on layer 2 protocols that allow the ability to hold &
transfer, uncommitted transactions as pools / joins, so that layer 1's
decentralization and incentives can remain undisturbed

protocols like mweb, for example




On Wed, Oct 19, 2022 at 7:34 AM mm-studios via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi Bitcoin devs,
> I'd like to share an idea of a method to increase throughput in the
> bitcoin network.
>
> Currently, a miner produce blocks with a limited capacity of transactions
> that ultimately limits the global settlement throughput to a reduced number
> of tx/s.
>
> Big-blockers proposed the removal of limits but this didn't come with
> undesirable effects that have been widely discussed and rejected.
>
> The main feature we wanted to preserve is 'small blocks', providing
> 'better network effects' I won't focus on them.
>
> The problem with small blocks is that, once a block is filled
> transactions, they are kept back in the mempool, waiting for their turn in
> future blocks.
>
> The following changes in the protocol aim to let all transactions go in
> the current block, while keeping the block size small. It requires changes
> in the PoW algorithm.
>
> Currently, the PoW algorithm consists on finding a valid hash for the
> block. Its validity is determined by comparing the numeric value of the
> block hash with a protocol-defined value difficulty.
>
> Once a miner finds a nonce for the block that satisfies the condition the
> new block becomes valid and can be propagated. All nodes would update their
> blockchains with it. (assuming no conflict resolution (orphan blocks, ...)
> for clarity).
>
> This process is meant to happen every 10 minutes in average.
>
> With this background information (we all already know) I go on to describe
> the idea:
>
> Let's allow a miner to include transactions until the block is filled,
> let's call this structure (coining a new term 'Brick'), B0. [brick=block
> that doesn't meet the difficulty rule and is filled of tx to its full
> capacity]
> Since PoW hashing is continuously active, Brick B0 would have a nonce
> corresponding to a minimum numeric value of its hash found until it got
> filled.
>
> Fully filled brick B0, with a hash that doesn't meet the difficulty rule,
> would be broadcasted and nodes would have it on in a separate fork as usual.
>
> At this point, instead of discarding transactions, our miner would start
> working on a new brick B1, linked with B0 as usual.
>
> Nodes would allow incoming regular blocks and bricks with hashes that
> don't satisfy the difficulty rule, provided the brick is fully filled of
> transactions. Bricks not fully filled would be rejected as invalid to
> prevent spam (except if constitutes the last brick of a brickchain,
> explained below).
>
> Let's assume that 10 minutes have elapsed and our miner is in a state
> where N bricks have been produced and the accumulated PoW calculated using
> mathematics (every brick contains a 'minimum hash found', when a series of
> 'minimum hashes' is computationally equivalent to the network difficulty is
> then the full 'brickchain' is valid as a Block.
>
> This calculus shall be better defined, but I hope that this idea can serve
> as a seed to a BIP, or otherwise deemed absurd, which might be possible and
> I'd be delighted to discover why a scheme like this wouldn't work.
>
> If it finally worked, it could completely flush mempools, keep
> transactions fees low and increase throughput without an increase in the
> block size that would raise other concerns related to propagation.
>
> Thank you.
> I look forward to your responses.
>
> --
> Marcos Mayorga
> https://twitter.com/KatlasC
>
> ___
> 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] Does Bitcoin require or have an honest majority or a rational one? (re rbf)

[Erik Aronesty via bitcoin-dev]

not sure if this is helpful, but when i'm code reviewing a change to an
existing, functioning and very complex system, i rarely go back to "first
principles" to analyze that change independently, and instead try to decide
if it's better or worse than what we have now

you can introduce a new feature, for example, that has a bunch of
noncritical bugs, especially in ux, and then you can weigh in on whether
its better to get it out now for the people that need it, or bikeshed ux
for another 2 releases

i'm often a fan of the former

if someone proposes a change to bitcoin, we should probably review it as
"better or worse than what we have", rather than "has perfectly aligned
incentives promoting honest behavior even among selfish actors"

we know bitcoin functions now with a complex series of incentives,
especially regarding node operators

in other words, does the change "improve what we have" is a better bar than
"stands on its own"

in that way the system can slowly improve over time, rather than be stuck


On Tue, Oct 18, 2022 at 12:28 PM Jeremy Rubin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I think the issue with
>
> I still think it is misguided to think that the "honest" (i.e. rule
>> following) majority is to just be accepted as an axiom and if it is
>> violated, well, then sorry.  The rules need to be incentive compatible for
>> the system to be functional.  The honest majority is only considered an
>> assumption because even if following the rules were clearly the 100%
>> dominant strategy, this doesn't prove that the majority is honest, since
>> mathematics cannot say what is happening in the real world at any given
>> time.  Still, we must have a reason to think that the majority would be
>> honest, and that reasoning should come from an argument that the rule set
>> is incentive compatible.
>
>
> epistemically is that even within the game that you prove the dominant
> strategy, you can't be certain that you've captured (except maybe through
> clever use of exogenous parameters, which reduces to the same thing as %
> honest) the actual incentives of all players. For example, you would need
> to capture the existence of large hegemonic governments defending their
> legacy currencies by attacking bitcoin.
>
>
> I think we may be talking past each other if it is a concern / valuable
> exercise to decrease the assumptions that Bitcoin rests on to make it more
> secure than it is as defined in the whitepaper. That's an exercise of
> tremendous value. I think my point is that those things are aspirational
> (aspirations that perhaps we should absolutely achieve?) but to the extent
> that we need to fix things like the fee market, selfish mining, mind the
> gap, etc, those are modifying Bitcoin to be secure (or more fair is perhaps
> another way to look at it) in the presence of deviations from a
> hypothesized "incentive compatible Bitcoin", which is a different thing
> that "whitepaper bitcoin". I think that I largely fall in the camp -- as
> evidenced by some past conversations I won't rehash -- that all of Bitcoin
> should be incentive compatible and we should fix it if not. But from those
> conversations I also learned that there are large swaths of the community
> who don't share that value, or only share it up to a point, and do feel
> comfortable resting on honest majority assumptions at one layer of the
> stack or another. And I think that prior / axiom is a pretty central one to
> debug or comprehend when dealing with, as is happening now, a fight over
> something that seems obviously not incentive compatible.
>
> --
> @JeremyRubin 
>
>
> On Tue, Oct 18, 2022 at 10:30 AM Russell O'Connor <
> rocon...@blockstream.com> wrote:
>
>> On Tue, Oct 18, 2022 at 9:07 AM Jeremy Rubin via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>>
>>> However, what *is* important about what Satoshi wrote is that it is sort
>>> of the "social contract" of what Bitcoin is that we can all sort of
>>> minimally agree to. This makes it clear, when we try to describe Bitcoin
>>> with differing assumptions than in the whitepaper, what the changes are and
>>> why we think the system might support those claims. But if we can't prove
>>> the new description sound, such as showing tip mining to be rational in a
>>> fully adversarial model, it doesn't mean Bitcoin doesn't work as promised,
>>> since all that was promised originally is functioning under an honest
>>> majority. Caveat Emptor!
>>>
>>
>> I still think it is misguided to think that the "honest" (i.e. rule
>> following) majority is to just be accepted as an axiom and if it is
>> violated, well, then sorry.  The rules need to be incentive compatible for
>> the system to be functional.  The honest majority is only considered an
>> assumption because even if following the rules were clearly the 100%
>> dominant strategy, this doesn't prove that the majority is honest, since
>> mathematics can

Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger

[Erik Aronesty via bitcoin-dev]

Also, lightning works fine and is readily available in convenient mobile
apps used by millions of people, or in .   So the need for a 0conf has been
mitigated by other solutions for fast payments with no need for a trust
relationship.  And for people that don't like mobile risks, core lightning
and other solutions are now easily installed and configured for use in fast
payments.

some references:

https://muun.com/ (easy!)
https://github.com/ElementsProject/lightning (reference, works well with
core)
https://lightning.network/ (more info)


On Fri, Oct 14, 2022 at 11:11 AM Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Fri, Oct 14, 2022 at 12:03:21PM +0200, John Carvalho via bitcoin-dev
> wrote:
> > In support of Dario's concern, I feel like there is a degree of
> gaslighting
> > happening with the advancement of RBF somehow being okay, while merchants
> > wanting to manage their own 0conf risk better being not okay.
>
> The way merchants try to manage 0conf risk is quite harmful to Bitcoin.
> Connecting to large numbers of nodes to try to risk-manage propagation
> _is_ an
> attack, albeit a mild one. Everyone doing that is very harmful; only a few
> merchants being able to do it is very unfair/centralized.
>
> ...and of course, in the past this has lead to merchants trying to make
> deals
> with miners directly, even going as far as to suggest reorging out
> double-spends. I don't need to explain why that is obviously extremely
> harmful.
>
> --
> 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] Surprisingly, Tail Emission Is Not Inflationary

[Erik Aronesty via bitcoin-dev]

1...
>  Degradation

Remember, if hash rate declines (no sign that it will so far), the
net-effect is longer clearance times for large transactions.

It's not "failure" or "breaking"

2...
Certainly, if demand for blockspace isn't high enough to support clearance
then the *first *thing to do would be to improve the utility of the chain
so that demand for blockspace is high.

This is one of the strong reasons to support research like covenants and
rgb and taro.   If those tools become popular, we will see rising fees.
 Indeed, large miners should be *paying* researchers to advance these
tools.   It's in their own best interests.

3...
> and on the other side I put game theory and well defined Prisoner's
Dilemma.

The prisoner's dilemma does not state that zero stakeholders will
mine, just far fewer.   Real world experiments with actual prisoners and
students show cooperation rates of 33%.  Plus there are incentives.
Stakeholders who want to move large amounts in a reasonable amount of time
are incentivised to mine.

4...
Changing issuance is a non-starter, forte very game-theoretic reasons you
refer to

it would destroy the value proposition of the chain, fork the coin and i
have every confidence that the surviving fork would be the one without the
new issuance


On Wed, Aug 17, 2022 at 9:43 AM  wrote:

>
> On one scale you puts the Trust to the large stakeholders (why we avoid
> plenty of small stakeholders, btw),
> and on the other side I put game theory and well defined Prisoner's
> Dilemma.
>
> Again: large stakeholders WILL NOT incentivised to mine, they will have
> the hundreds excuses why not to switch-on Antminers back.
> That's how it simply works.  Bitcoin would fail miserably if Satoshi was
> based his concept mainly on existence of idealists.
>
> If we will observe lack of hashrate recovery four years after some halving
> and still unprepared like today
> - means the trust in large stakeholders was a very costly mistake.
>
>
> Superiority of Proof of Work against Proof of Stake has been discussed
> enough either
> The overall conclusion with what I fully agree  is: swapping PoW to PoS -
> would be a degradation.
> You can stop talking about degradation to proof of stake, but just:
> degradation.
>
> Degradation of Bitcoin, due to human greed.
>
> Now you mine and you have an INSTANT gratification.
> Then you will mine and it will cost you real money, but simple switch -
> and you have a DELAYED, maybe some day in the future, maybe only a tiny -
> punishment.
> And The Punishment Won't Be Tiny.
>
>
> "If the pain after hitting the hand with a hammer would appear after a
> month - people would notoriously walk with swollen fingers"
> 100% (^2)
>
> Regards
> Jaroslaw
>
>
>
> W dniu 2022-08-17 13:10:38 użytkownik Erik Aronesty 
> napisał:
>
> > you can stop talking about  the "security of the system" as meaningful
> > this has been discussed enough
> > if fees are not sufficient, clearance times increase and large
> stakeholders are incentivised to mine
> > in the best case, fees are sufficient
> > in the worst case, it degrades to proof of stake
> > i'm sure you can see how that's fine either way
>
>
>
> ___
> 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] Surprisingly, Tail Emission Is Not Inflationary

[Erik Aronesty via bitcoin-dev]

you can stop talking about  the "security of the system" as meaningful

this has been discussed enough

if fees are not sufficient, clearance times increase and large stakeholders
are incentivised to mine

in the best case, fees are sufficient

in the worst case, it degrades to proof of stake

i'm sure you can see how that's fine either way


On Mon, Aug 15, 2022 at 9:59 PM Jaroslaw via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> > New blog post:
> >
> https://petertodd.org/2022/surprisingly-tail-emission-is-not-inflationary
>
>
> Tail emission is inevitable, Milton Friedman says...
>
>
> The key thing here in my opinion is to properly understand the seriousness
> of the situation.
> "There is no such thing as a free lunch" - is definitely helpful quote
> here.
>
> There are two edge cases.
>
> 1. while starting given cryptocurrency
> - the annual inflation is huge, nobody (in developed/mature monetary
> system) would like to keep such kind of money with e.g. 100% annual
> inflation rate, but from the other side there is no problem for transaction
> fee to be free of charge here
>
> 2. while given cryptocurrency is switching off the block reward, in
> supposed "mature phase":
> - the annual inflation is zero, everyone want to hoard such money,
> transaction fees must carry the whole security of the system
>
>
> In the first edge case: active users have got "free lunches" and passive
> users (i.e. holders) are paying for it (by "inflation tax")
> In the second edge case: passive users have got "free lunches" and active
> users should pay for it (by "transactional tax")
>
> So far I only highlighted some maybe not very well recognized, but pure
> facts (it's not comfortable to contradict the facts...)
>
>
> The reason people do pay in the first phase - is a hope/promise of system
> growth (future coin price appreciation = profit)
> The problem in the second phase is that there is no real incentive for
> people to pay for other's free lunches.
>
>
> Any wishful thinking that most (or even: any significant part) of holders
> will resign from a free lunch and will buy and run ASIC mining equipment at
> loss - is just a delusional perspective. It's well proven by game theory
> and what says us the Prisoner's Dilemma about it. For better understanding
> - here is my modified version of Prisoner's Dilemma short description:
>
> "The Prisoner's Dilemma is a standard example of a game analyzed in game
> theory that shows why completely rational large holders might not
> cooperate, even if it appears that it is in their best interests to do so."
>
> I'm pretty sure we will have a textbook case of Prisoner's Dilemma here.
>
> As a useful example - let's assume that fees don't compensate low block
> reward. Btw, right now a single transaction fee need to be $60 to
> compensate that (and it will only get worse in time). System is not
> inclusive with $60 per transaction fee. Only rich people will use it.
> Another possible scenario is a x100 drop of network hashrate to catch a
> previous fee levels. The network is x100 less secure, then. It really
> doesn't matter if this process is spread over the long run...
>
> So, for example - let every 10 BTC holding needs to be secured by one
> Antminer S19 running.
>
> In an ideal world every large bitcoin holder will run proper amount of
> ASICs and run it at loss.
> The holders of less than 10 BTC - will organize "group pays", this time
> for sharing loss (electricity costs)
> Exactly the same way like people made "group buys" of ASIC hardware in
> 2013.
>
> I hope it's clear that in the real world it WILL NOT work. People will
> simply think, that there is only a tiny punishment for betrayal.
> Noone will waste his renewable energy on unprofitable Antminer while
> he/she can sell this energy for the market price. Even Bitcoin can't beat
> the human nature.
>
>
> Thanks to Milton Friedman - we can easily say that situation with "free
> lunches" (at least for some part of users) - is an unhealthy state of
> financial system.
> And may last only exceptionally for short period of time, and definitely
> not as a default state. System must be sustainable and time to accept that
> there is a real problem here (or: an elephant in the room - but maybe not
> such invisible like was before).
>
> The good news is a natural solution exists. Bitcoin can solve this issue
> natural way.
>
> While decreasing block reward and moving from the first edge case to the
> second one - the system naturally cross the Area of Balance.
> And healthy system should stay somewhere in such area. And that's exactly
> what Monero did. But they did it arbitrally, at 0.9% level.
> Bitcoin is able to do it much better - because empirically.
>
> There is a simple trigger if the system is leaving an Area of Balance and
> cross the line of Phase 2 with "free lunches". The network difficulty /
> global network hashrate chart.
> Four years after some particular halving (in 2028, 2032 or later - n

Re: [bitcoin-dev] Surprisingly, Tail Emission Is Not Inflationary

[Erik Aronesty via bitcoin-dev]

> I'm pretty sure we will have a textbook case of Prisoner's Dilemma here.

no, there is no large payoff for betrayal
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Surprisingly, Tail Emission Is Not Inflationary

[Erik Aronesty via bitcoin-dev]

even with zero block reward and minimal fees, large holders who perform
zero transactions will still mine in order to preserve the value of the
network

this is not "mining your own tx", it is unrelated

this is "mining at a small loss to preserve your stake"

not only don't we need issuance or fees, but also the censorship resistance
is not meaningfully improved with issuance


On Mon, Jul 18, 2022 at 3:14 PM Erik Aronesty  wrote:

>
>> subsidy to directly tie miner revenue to the total value of Bitcoin
>> makes it not exactly how we want to incentivise a service that keeps
>>
>>
> again, this is meaningless.   if the fees aren't enough to keep  bitcoin
> secure for large transactions, then large holders are incentivised to mine
>
> that's it.
>
> it's not complicated
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Surprisingly, Tail Emission Is Not Inflationary

[Erik Aronesty via bitcoin-dev]

>
>
> subsidy to directly tie miner revenue to the total value of Bitcoin
> makes it not exactly how we want to incentivise a service that keeps
>
>
again, this is meaningless.   if the fees aren't enough to keep  bitcoin
secure for large transactions, then large holders are incentivised to mine

that's it.

it's not complicated
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Security problems with relying on transaction fees for security

[Erik Aronesty via bitcoin-dev]

it's in line with the values of

 - immutable supply
 - enforced by the game theory of hard money

and no, it's not only "rich holders"... i mine, and lots of people i know do

it's certainly more decentralized than the alternatives




On Thu, Jul 14, 2022 at 7:43 AM Gino Pinuto  wrote:

> This is not an argument in line with bitcoin values, on that scenario only
> rich people will be able to mine and participate to the consensus process.
> Like George Soros today, he use its financial reserves to monopolize ONG
> in order to manipulate nation states. I would not define this a "tax",
> moreover a cost to maintain control over the network.
>
> Those rich holders could crate a cartel and without market dynamics all
> game theory stop to work and the bitcoin network value drop.
>
> We should think about how to maximise the network value instead of trying
> to preserve it with corruptible practices outside of market dynamics
> principles.
>
> On Thu, 14 Jul 2022, 12:53 Erik Aronesty via bitcoin-dev, <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Fees and miner rewards are not needed at all for security at all since
>> long term holders can simply invest in mining to secure the value of their
>> stake.
>>
>> Isn't it enough that the protocol has a mechanism to secure value?
>>
>> Sure fees *might* be enough.
>>
>> But in the event that they are not, large holders can burn a bit to make
>> sure the hashrate stays high.
>>
>> I know, I know it's a tax on the rich and it's not fair because smaller
>> holders are less likely to do it, but it's a miniscule tax even in the
>> worst case
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Thu, Jul 14, 2022, 5:35 AM vjudeu via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> > This specific approach would obviously not work as most of those
>>> outputs would be dust and the miner would need to waste an absurd amount of
>>> block space just to grab them, but maybe there's a smarter way to do it.
>>>
>>> There is a smarter way. Just send 0.01 BTC per block to the timelocked
>>> outputs. Now, we have 6.25 BTC, so it means less than 0.2%. But that
>>> percentage will grow over time, as basic block reward will shrink, and we
>>> will have mandatory 0.01 BTC endlessly moved, until it will wrap. And guess
>>> what: if it will be 0.01 BTC per block, wrapped every 210,000 blocks, it
>>> simply means you can lock 2,100 BTC in an endless circulation loop, and
>>> avoid this "tail supply attack".
>>>
>>> So, fortunately, even if "tail supply attackers" will win, we will still
>>> have a chance to counter-attack by burning those coins, or (even better) by
>>> locking them in an endless circulation loop, just to satisfy their
>>> malicious soft-fork, whatever amount it will require. Because even if it
>>> will be mandatory to timelock 0.01 BTC to the current block number plus
>>> 210,000, then it is still perfectly valid to move that amount endlessly,
>>> without taking it, just to resist this "tail supply attack".
>>>
>>>
>>> On 2022-07-13 20:01:39 user Manuel Costa via bitcoin-dev <
>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>> > What about burning all fees and keep a block reward that will smooth
>>> out while keeping the ~21M coins limit ?
>>>
>>> This would be a hard fork afaict as it would go against the rules of the
>>> coinbase transaction following the usual halving schedule.
>>>
>>> However, if instead we added a rule that fees have to be sent to an
>>> anyone can spend output with a timelock we might be able to achieve a
>>> similar thing.
>>>
>>> Highly inefficient example:
>>>
>>> - Split blocks into 144 (about a day)
>>> - A mined block takes all the fees and distributes them equally into 144
>>> new outputs (anyone can spend) time locked to each of the 144 blocks of the
>>> next day.
>>> - Next day, for each block, we'd have available an amount equivalent to
>>> the previous day total fees / 144. So we deliver previous day's fees
>>> smoothed out.
>>>
>>> Notes:
>>> 144 is arbitrary in the example.
>>> This specific approach would obviously not work as most of those outputs
>>> would be dust and the miner would need to waste an absurd amount of block
>>> space just to grab them, but maybe there

Re: [bitcoin-dev] Security problems with relying on transaction fees for security

[Erik Aronesty via bitcoin-dev]

Fees and miner rewards are not needed at all for security at all since long
term holders can simply invest in mining to secure the value of their stake.

Isn't it enough that the protocol has a mechanism to secure value?

Sure fees *might* be enough.

But in the event that they are not, large holders can burn a bit to make
sure the hashrate stays high.

I know, I know it's a tax on the rich and it's not fair because smaller
holders are less likely to do it, but it's a miniscule tax even in the
worst case









On Thu, Jul 14, 2022, 5:35 AM vjudeu via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> > This specific approach would obviously not work as most of those outputs
> would be dust and the miner would need to waste an absurd amount of block
> space just to grab them, but maybe there's a smarter way to do it.
>
> There is a smarter way. Just send 0.01 BTC per block to the timelocked
> outputs. Now, we have 6.25 BTC, so it means less than 0.2%. But that
> percentage will grow over time, as basic block reward will shrink, and we
> will have mandatory 0.01 BTC endlessly moved, until it will wrap. And guess
> what: if it will be 0.01 BTC per block, wrapped every 210,000 blocks, it
> simply means you can lock 2,100 BTC in an endless circulation loop, and
> avoid this "tail supply attack".
>
> So, fortunately, even if "tail supply attackers" will win, we will still
> have a chance to counter-attack by burning those coins, or (even better) by
> locking them in an endless circulation loop, just to satisfy their
> malicious soft-fork, whatever amount it will require. Because even if it
> will be mandatory to timelock 0.01 BTC to the current block number plus
> 210,000, then it is still perfectly valid to move that amount endlessly,
> without taking it, just to resist this "tail supply attack".
>
>
> On 2022-07-13 20:01:39 user Manuel Costa via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> > What about burning all fees and keep a block reward that will smooth out
> while keeping the ~21M coins limit ?
>
> This would be a hard fork afaict as it would go against the rules of the
> coinbase transaction following the usual halving schedule.
>
> However, if instead we added a rule that fees have to be sent to an anyone
> can spend output with a timelock we might be able to achieve a similar
> thing.
>
> Highly inefficient example:
>
> - Split blocks into 144 (about a day)
> - A mined block takes all the fees and distributes them equally into 144
> new outputs (anyone can spend) time locked to each of the 144 blocks of the
> next day.
> - Next day, for each block, we'd have available an amount equivalent to
> the previous day total fees / 144. So we deliver previous day's fees
> smoothed out.
>
> Notes:
> 144 is arbitrary in the example.
> This specific approach would obviously not work as most of those outputs
> would be dust and the miner would need to waste an absurd amount of block
> space just to grab them, but maybe there's a smarter way to do it.
>
>
>
>
> Gino Pinuto via bitcoin-dev 
> escreveu no dia quarta, 13/07/2022 à(s) 13:19:
> What about burning all fees and keep a block reward that will smooth out
> while keeping the ~21M coins limit ?
>
>
> Benefits :
> - Miners would still be incentivized to collect higher fees transaction
> with the indirect perspective to generate more reward in future.
> - Revenues are equally distributed over time to all participants and we
> solve the overnight discrepancy.
> - Increased velocity of money will reduce the immediate supply of bitcoin
> cooling down the economy.
> - Reduction of velocity will have an impact on miners only if it persevere
> in the long term but short term they will still perceive the buffered
> reward.
>
>
> I don't have ideas yet on how to elegantly implement this.
>
>
>
> On Wed, 13 Jul 2022, 12:08 John Tromp via bitcoin-dev, <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> > The emission curve lasts over 100 years because Bitcoin success state
> requires it to be entrenched globally.
>
> It effectively doesn't. The last 100 years from 2040-2140 only emits a
> pittance of about 0.4 of all bitcoin.
>
> What matters for proper distribution is the shape of the emission
> curve. If you emit 99% in the first year and 1% in the next 100 years,
> your emission "lasts" over 100 years, and you achieve a super low
> supply inflation rate immediately after 1 year, but it's obviously a
> terrible form of distribution.
>
> This is easy to quantify as the expected time of emission which would
> be 0.99 * 0.5yr + 0.01* 51yr = 2 years.
> Bitcoin is not much better in that the expected time of emission of an
> bitcoin satisfies x = 0.5*2yr + 0.5*(4+x) and thus equals 6 years.
>
> Monero appears much better since its tail emission yields an infinite
> expected time of emission, but if we avoid infinities by looking at
> just the soft total emission [1], which is all that is emitted before
> a 1% yearly inflation, then Monero i

Re: [bitcoin-dev] Security problems with relying on transaction fees for security

[Erik Aronesty via bitcoin-dev]

Bitcoin doesn't rely on fees.  It relys on users protecting the network out
of self interest

- running nodes now
- mining later

It has always been incentivised by holders acting out of self interest

If large holders allocating a small percentage to mining to protect their
interest, that's all Bitcoin needs

Although I can think of other protocols that work that way and people don't
like them







On Wed, Jul 13, 2022, 4:06 AM Tom Harding via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On 7/11/22 15:26, Peter Todd via bitcoin-dev wrote:
> >
> > Anyway, designing protocols for "price go up forever" hopium is a bad
> idea.
>
> Yet that is the design, and it's a good one.  It is equivalent to
> relying on bitcoin to steadily grow in utility vs. fiat currencies.
>
> If it fails to do that, there's no point anyway.
>
> ___
> 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] Security problems with relying on transaction fees for security

[Erik Aronesty via bitcoin-dev]

>
>  we can expect mining to transition to a public service from the current
> for-profit business model
>

I get it now

Game theory would predict all of the major players mining in the future
will be large holders

If you're holding a hundred Bitcoin you should take one, sell it for mining
equipment and use it  to ensure the rest is stable

I guess that's perfectly reasonable

Yeah I'm on board with the idea that this is a non-issue

Interested parties will continue to maintain the security of the chain with
the same basic game theoretic stuff

Bitcoin doesn't need a security budget

Existing holders have the ability the means and the incentive to secure
their funds

Probably the only thing Bitcoiners should do is to advertise this rather
than to make it some sort of secret
















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

Re: [bitcoin-dev] Security problems with relying on transaction fees for security

[Erik Aronesty via bitcoin-dev]

>
> Miners will learn to create anyone-can-spend outputs to bribe other miners
> to build on their block rather than reorg it.  (Due to the coinbase
> maturity, this will require some amount of floating capital.)
>

(reward + avg fee) * 144 * 365 (one year) == approximate investment needed
to reorg the chain for a double-spend attack

in 30 years, assuming fees are still negligible (why wouldn't they be?
layer 2 works and layer 3 is coming), that's only 1200 bitcoin.  not really
a lot.

there's only few things that allow that security budget to be ok

 - we assume the price goes up a lot
 - we assume transactions get a lot more expensive
 - we don't care about double-spend attacks for very large transactions

i'd rather engineer block demand than ignore it
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Security problems with relying on transaction fees for security

[Erik Aronesty via bitcoin-dev]

> If in the future Bitcoin is entirely dependent on fees for security
(scheduled very strongly) and this pattern keeps up (overwhelmingly likely)
then this is going to become a serious problem.

We should carefully define "when" this becomes an issue.

Suppose the reward is 1.5625 BTC.   That's not very far away.   Assume you
need a 12-month investment in hardware.   One-year * 100% mining capacity
at that time is thus incentivised with 82125 bitcoin in losses against a
double spend.   If the price remains the same as it is now, that's 1.6
billion.  Is that a sufficient security budget?

As the rewards drop, the security of Bitcoin increasingly relies on "price
increases" and "fee pressure".  Obviously "price increases" isn't something
anyone should rely on.   Therefore the correct thing to address is "fee
pressure".

> There are a few possible approaches to fixes. One would be to drag most
of east asia eastward to a later time zone thus smoothing out the day/night
cycle but that's probably unrealistic. Another would be to hard fork in
fixed rewards in perpetuity...

There is abundant evidence that modifying on-chain utility alters fees.
There is little doubt that the lightning network has cut into the security
budget.  Future privacy protocols, such as mweb, will cut in even further.

Therefore another solution would be to simply *increase on-chain utility*,
driving up fees in response to the growth of layered transactions.

Proposals like "payment codes" and protocols like "omni" and "omnibolt" all
use on-chain resources without needing a soft fork.   Other proposals, like
covenants, may increase fee pressure more.   And, of course, promoting the
use of Bitcoin & Lightning in transactions - not just "holding", helps
promote fee growth and helps maintain the security budget.

Even if it's less fixed and predictable than tail-emissions, this approach
seems to make much more sense.


On Mon, Jul 11, 2022 at 2:19 PM Bram Cohen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> If transaction fees came in at an even rate over time all at the exact
> same level then they work fine for security, acting similarly to fixed
> block rewards. Unfortunately that isn't how it works in the real world.
> There's a very well established day/night cycle with fees going to zero
> overnight and even longer gaps on weekends and holidays. If in the future
> Bitcoin is entirely dependent on fees for security (scheduled very
> strongly) and this pattern keeps up (overwhelmingly likely) then this is
> going to become a serious problem.
>
> What's likely to happen is that at first there will simply be no or very
> few blocks mined overnight. There are likely to be some, as miners at first
> turn off their mining rigs completely overnight then adopt the more
> sophisticated strategy of waiting until there are enough fees in the
> mempool to warrant attempting to make a block and only then doing it.
> Unfortunately the gaming doesn't end there. Eventually the miners with
> lower costs of operation will figure out that they can collectively reorg
> the last hour (or some time period) of the day overnight and this will be
> profitable. That's likely to cause the miners with more expensive
> operations to stop attempting mining the last hour of the day preemptively.
>
> What happens after that I'm not sure. There are a small enough number of
> miners with a quirky enough distribution of costs of operation and
> profitability that the dynamic is heavily dependent on those specifics, but
> the beginnings of a slippery slope to a mining cabal which reorgs everyone
> else out of existence and eventually 51% attacks the whole thing have
> begun. It even gets worse than that because once there's a cabal
> aggressively reorging anyone else out when they make a block other miners
> will shut down and rapidly lose the ability to quickly spin up again, so
> the threshold needed for that 51% attack will keep going down.
>
> In short, relying completely on transaction fees for security is likely to
> be a disaster. What we can say from existing experience is that having
> transaction fees be about 10% of rewards on average works well. It's enough
> to incentivize collecting fees but not so much that it makes incentives get
> all weird. 90% transaction fees is probably very bad. 50% works but runs
> the risk of spikes getting too high.
>
> There are a few possible approaches to fixes. One would be to drag most of
> east asia eastward to a later time zone thus smoothing out the day/night
> cycle but that's probably unrealistic. Another would be to hard fork in
> fixed rewards in perpetuity, which is slightly less unrealistic but still
> extremely problematic.
>
> Much more actionable are measures which smooth out fees over time. Having
> wallets opportunistically collect their dust during times of low
> transaction fees would help and would save users on fees. Also making UX
> which clarifies when things are likely to take a day or 

Re: [bitcoin-dev] No Order Mnemonic

[Erik Aronesty via bitcoin-dev]

Sorry, I totally forgot the checksum.

You can take my ops-per-second and multiply it by about 16 (because of the
4 check bits), making a delete + two swaps or 4 swaps, etc. still pretty
reasonable.



On Mon, Jul 11, 2022 at 9:11 AM Erik Aronesty  wrote:

> 1. You can swap two positions, and then your recovery algorithm can
> brute-force the result by trying all 132 possible swaps.
> 2. You can make a single deletion and only have to brute 2048
> 3. You can keep doing these, being aware that it becomes geometrically
> more difficult each time (deletion + swap = 270k ops)
> 4. A home PC can make 20k secpk256 operations per second per core, so try
> to keep your number under a few million ops and it's still a decent UX
> (under a minute)
>
>
> On Sat, Jul 9, 2022 at 8:01 PM Anton Shevchenko via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> I would say removing ordering from 12-word seed reduces 25 bits of
>> entropy, not 29. Additional 4 bits come from checksum (12 words encode 132
>> bits, not 128).
>>
>> My idea [for developing this project] was to feed its output to some kind
>> of AI story generator (GPT-3 based?) so a user can remember a story, not
>> ordered words. But as others pointed out, having 12 words without order is
>> probably good enough. So at this point there's not much sense of using the
>> proposed encoding. Unless a remembered story has wholes/errors. In this
>> case recovering few words would be easier with unordered encoding. Any
>> thoughts?
>>
>> --  Anton Shevchenko
>>
>>
>> On Sat, Jul 9, 2022, at 1:31 PM, Zac Greenwood via bitcoin-dev wrote:
>>
>> Sorting a seed alphabetically reduces entropy by ~29 bits.
>>
>> A 12-word seed has (12, 12) permutations or 479 million, which is
>> ln(469m) / ln(2) ~= 29 bits of entropy. Sorting removes this entropy
>> entirely, reducing the seed entropy from 128 to 99 bits.
>>
>> Zac
>>
>>
>> On Fri, 8 Jul 2022 at 16:09, James MacWhyte via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>
>> 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
>>
>> ___
>> 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] No Order Mnemonic

[Erik Aronesty via bitcoin-dev]

1. You can swap two positions, and then your recovery algorithm can
brute-force the result by trying all 132 possible swaps.
2. You can make a single deletion and only have to brute 2048
3. You can keep doing these, being aware that it becomes geometrically more
difficult each time (deletion + swap = 270k ops)
4. A home PC can make 20k secpk256 operations per second per core, so try
to keep your number under a few million ops and it's still a decent UX
(under a minute)


On Sat, Jul 9, 2022 at 8:01 PM Anton Shevchenko via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I would say removing ordering from 12-word seed reduces 25 bits of
> entropy, not 29. Additional 4 bits come from checksum (12 words encode 132
> bits, not 128).
>
> My idea [for developing this project] was to feed its output to some kind
> of AI story generator (GPT-3 based?) so a user can remember a story, not
> ordered words. But as others pointed out, having 12 words without order is
> probably good enough. So at this point there's not much sense of using the
> proposed encoding. Unless a remembered story has wholes/errors. In this
> case recovering few words would be easier with unordered encoding. Any
> thoughts?
>
> --  Anton Shevchenko
>
>
> On Sat, Jul 9, 2022, at 1:31 PM, Zac Greenwood via bitcoin-dev wrote:
>
> Sorting a seed alphabetically reduces entropy by ~29 bits.
>
> A 12-word seed has (12, 12) permutations or 479 million, which is ln(469m)
> / ln(2) ~= 29 bits of entropy. Sorting removes this entropy entirely,
> reducing the seed entropy from 128 to 99 bits.
>
> Zac
>
>
> On Fri, 8 Jul 2022 at 16:09, James MacWhyte via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>
> 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
>
> ___
> 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] Surprisingly, Tail Emission Is Not Inflationary

[Erik Aronesty via bitcoin-dev]

>
>
> Alternatively, losses could be at a predictable rate that's entirely
> different to the one Peter assumes.
>

No, peter only assumes that there *is* a rate.

Regardless of what the rate is, if it is any value for which there exists
*any fixed central tendency*, tail emission is *evenually* non inflationary.

But you are correct about the other two things:

1. If people are improving custody faster than 1/(N(t)*P) than tail
emission can still be inflationary.  This seems far-fetched, imo.

2. The rate will be somewhat stochastic ("black swan envets").  Plausible
(popular wallet loses keys in coding error), but also... "true no matter
what".  And not really relevant to tail-emission  being non-inflationary.
 Over a long enough time period, even these events can be factored into a
fixed central tendency.   Even if it's 100 years, etc.
___
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] Bitcoin covenants are inevitable

[Erik Aronesty via bitcoin-dev]

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 validate. That’s a threshold criteria.
>
> Given unlimited size blocks, miners would still have to fix a point in
> time to mine, gathering as much fee as they can optimize in some time
> period presumably less than 10 minutes. The produces a limit to transaction
> volume, yet neither reward nor profit would be affected given the above
> assumptions. The difference would be in a tradeoff of per tx fee against
> the threshold.
>
> Given Moore’s Law, that threshold is constantly decreasing, which will
> make it  cheaper over time for more individuals to validate. But the
> difference for miners for smaller blocks is largely inconsequential
> relative to their other costs.
>
> Increasing demand is the only thing that increases double spend security
> (and censorship resistance assuming fee-based reward). With rising demand
> there is rising overall hash rate, despite block reward and profit
> remaining constant. This makes the cost of attempting to orphan a block
> higher, therefore lowering the depth/time requirement implied to secure a
> given tx amount.
>
> These are the two factors, demand and time. Less demand implies more time
> to secure a given amount against double spend, and also implies a lower
> cost to subsidize a censorship regime. But the latter requires a
> differential in reward between the censor and non-censoring miners. While
> this could be paid in side fees, that is a significant anonymity issue.
>
> e
>
> On Jul 7, 2022, at 10:37, Erik Aronesty  wrote:
>
> 
> > > 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", lowering the block size could help prevent this
> issue as well... increasing fee pressure and double-spend security while
> reducing the burden on node operators.
>
> Changes to inflation are, very likely, off the table.
>
>
>
> On Thu, Jul 7, 2022 at 12:24 PM Eric Voskuil via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>>
>>
>> > On Jul 7, 2022, at 07:13, Peter Todd via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> 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.
>> >
>> > Unfortunately you are quite wrong: the difficulty adjustment function
>> merely
>> > adjusts for changes in the amount of observable, non-51%-attacking,
>> hashing
>> > power. In the event of a chain split, the difficulty adjustment
>> function does
>> > nothing; against a 51% attacker, the difficulty adjustment does nothing;
>> > against a censor, the difficulty adjustment does nothing.
>>
>> Consider falling hash rate due to a perpetual 51% attack. Difficulty
>> falls, possibly to min difficulty if all non-censors stop mining and with
>> all censors collaborating (one miner). Yet as difficulty falls, so does the
>> cost of countering the censor. At min difficulty everyone can CPU mine
>> again.
>>
>> Given the presumption that fees rise on unconfirmed transactions, there
>> is inherent economic incentive to countering at any level of difficulty.
>> Consequently the censor is compelled to subsidize the loss resulting from
>> forgoing higher fee transactions that are incentivizing its competition.
>>
>> With falling difficulty this incentive is compounded.
>>
>> Comparisons of security in different scenarios presume a consistent level
>> of demand. If that demand is insufficient to offset the censor’s subsidy,
>> there is no security in any scenario.
>>
>> Given that the block subsidy (inflation) is paid equally to censoring and
>> non-censoring miners, it offers no secur

Re: [bitcoin-dev] Bitcoin covenants are inevitable

[Erik Aronesty via bitcoin-dev]

> > 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", lowering the block size could help prevent this
issue as well... increasing fee pressure and double-spend security while
reducing the burden on node operators.

Changes to inflation are, very likely, off the table.



On Thu, Jul 7, 2022 at 12:24 PM Eric Voskuil via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
>
> > On Jul 7, 2022, at 07:13, Peter Todd via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> 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.
> >
> > Unfortunately you are quite wrong: the difficulty adjustment function
> merely
> > adjusts for changes in the amount of observable, non-51%-attacking,
> hashing
> > power. In the event of a chain split, the difficulty adjustment function
> does
> > nothing; against a 51% attacker, the difficulty adjustment does nothing;
> > against a censor, the difficulty adjustment does nothing.
>
> Consider falling hash rate due to a perpetual 51% attack. Difficulty
> falls, possibly to min difficulty if all non-censors stop mining and with
> all censors collaborating (one miner). Yet as difficulty falls, so does the
> cost of countering the censor. At min difficulty everyone can CPU mine
> again.
>
> Given the presumption that fees rise on unconfirmed transactions, there is
> inherent economic incentive to countering at any level of difficulty.
> Consequently the censor is compelled to subsidize the loss resulting from
> forgoing higher fee transactions that are incentivizing its competition.
>
> With falling difficulty this incentive is compounded.
>
> Comparisons of security in different scenarios presume a consistent level
> of demand. If that demand is insufficient to offset the censor’s subsidy,
> there is no security in any scenario.
>
> Given that the block subsidy (inflation) is paid equally to censoring and
> non-censoring miners, it offers no security against censorship whatsoever.
> Trading fee-based block reward for inflation-based is simply trading
> censorship resistance for the presumption of double-spend security. But of
> course, a censor can double spend profitably in any scenario where the
> double spend value (to the censor) exceeds that of blocks orphaned (as the
> censor earns 100% of all block rewards).
>
> Banks and state monies offer reasonable double spend security. Not sure
> that’s a trade worth making.
>
> It’s not clear to me that Satoshi understood this relation. I’ve seen no
> indication of it. However the decision to phase out subsidy, once a
> sufficient number of units (to assure divisibility) had been issued, is
> what transitions Bitcoin from a censorable to a censorship resistant money.
> If one does not believe there is sufficient demand for such a money, there
> is no way to reconcile that belief with a model of censorship resistance.
>
> > We should not imbue real technology with magical qualities.
>
> Precisely. It is economic forces (people), not technology, that provide
> security.
>
> e
>
> >> Bitcoin does not need active economic governanance by devs or meddlers.
> >
> > Yes, active governance would definitely be an exploitable mechanism. On
> the
> > other hand, the status quo of the block reward eventually going away
> entirely
> > is obviously a risky state change too.
> >
>  There is also zero agreement on how much security would constitute
> such
> >>> an optimum.
> >>>
> >>> This is really step 1. We need to generate consensus on this long
> before
> >>> the block subsidy becomes too small. Probably in the next 10-15 years.
> I
> >>> wrote a paper
> >
> > The fact of the matter is that the present amount of security is about
> 1.7% of
> > the total coin supply/year, and Bitcoin seems to be working fine. 1.7%
> is also
> > already an amount low enough that it's much smaller than economic
> volatility.
> >
> > Obviously 0% is too small.
> >
> > There's zero reason to stress about finding an "optimal" amount. An
> amount low
> > enough to be easily affordable, but non-zero, is fine. 1% would be fine;
> 0.5%
> > would probably be fine; 0.1% would probably be fine.
> >
> > Over a lifetime - 75 years - 0.5% yearly inflation works out to be a 31%
> tax on
> > savings; 0.1% works out to be 7.2%
> >
> > These are all amounts that are likely to be dwarfed by economic shifts.
> >
> > --
> > https://petertodd.org 'peter'[:-1]@petertodd.org
> > ___
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-

Re: [bitcoin-dev] Bitcoin covenants are inevitable

[Erik Aronesty via bitcoin-dev]

.

>
> 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, lightning channel open and close transactions are more
valuable, via aggregation, than simple money transfers.

The value of higher utility transactions goes up fairly quickly.

There is no end of the possibility of fee levels in response to increased
utility

Other networks have clearly proven the extremes of this, with rampant fees
appearing rapidly in response to higher utility levels

Because this has already been proven on other networks, we can plan to
gradually  increase the utility of on-chain transactions in response to
reward reductions

This should be more than sufficient to offset and maintain sufficient
security

... Hence the title of this thread.
___
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]

>
> Anyway, demurrage and inflation have identical economic properties. They're
>> both a tax on savings. The only difference is the way that tax is
>> implemented.
>
>
the fact that a conversation on inflation is continuing without being
ignored is probably an indicator that the utility of on-chain services as
an incentive to drive fees is a worthwhile consideration.  i especially
like the proposed and very simple on-chain "payment codes" idea, for
example.   if a light-touch is used, bitcoin operators can thread the
needle allowing utility to grow a bit in response to halvings.  i suspect
lightning ate a lot of the on-chain fees.   future "compression and
privacy" protocols, like mweb, should keep this concern in mind.
___
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 Sun, Jun 19, 2022 at 2:04 PM Manuel Costa via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>  if we start seeing issues with block rewards being too low to maintain
> acceptable security, we're going to have multiple solutions being
> implemented for it, and definitely a hard fork to indefinitely maintain
> some degree of block subsidy
>

if we failed to first try increasing block demand with advanced transaction
support, it would seem like we were just throwing money and growth away to
support one narrative (simplicty of function), while destroying another
(finite supply)

if stuff like covenant support and mweb gets us higher fees, with stuff
like on-chain mixing protocols, vaults, and higher utility, it might be
more than enough to sustain bitcoin on fees alone forever
___
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]

Yes


Although I'm guessing most would agree that would be worse.

I certainly would choose to add fee generating features over inflation

Probably most other people would too



On Sat, Jun 11, 2022, 11:36 PM Peter Todd  wrote:

> On Mon, Jun 06, 2022 at 09:02:18AM -0400, Erik Aronesty via bitcoin-dev
> wrote:
> > Maintaining the security of the protocol is squarely the responsibility
> of
> > the Bitcoin software and the core developers
> >
> > Continued demand for block space is critical for Bitcoin's security.
>
> Only because the block reward goes away. If it was made to continue
> indefinitely - most likely with an inflation hard fork - demand for block
> space
> would not be critical to Bitcoin's security.
>
> --
> 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] Bitcoin covenants are inevitable

[Erik Aronesty via bitcoin-dev]

Maintaining the security of the protocol is squarely the responsibility of
the Bitcoin software and the core developers

Continued demand for block space is critical for Bitcoin's security.

Therefore it *is* the responsibility of Bitcoin software and core
developers to maintain a continued demand for block space - which underpins
the game-theoretical security of the protocol.

While I'm personally confident that demand is still high, enough to
reasonably secure the protocol, I do think that this is a matter not best
left up to stern opinions.   Whether covenant tech is essential for that
security or not is a matter for simulations and proofs, not hype and
speculation - on either side of the issue.


On Sat, Jun 4, 2022 at 8:36 AM John Carvalho via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Core development is not a hackathon project.
>
> None of the quoted following items are features or responsibilities of the
> Bitcoin software, nor Core developers.
>
> Quoted:
> "- Developers can build interesting projects with real demand in market.
> - Students learn Sapio and not just solidity.
> - Better tooling could be available for application developers.
> - Maybe we see bitcoin developer hackathons in different countries.
> - Demand for block space might increase, it wont be just exchanges and
> coinjoin.
> - Funding of bitcoin developers and projects might improve. Wont need to
> convince a few people for grants."
>
> Whether you are a child or an attacker, none of us should care, but CTV,
> nor any change to Bitcoin software, will never be justifiable simply
> because you and some of your friends think it is totally cool and might
> make more people like you or give your friends funding.
>
> Please stop making noise about CTV, this is not a place for spamming.
>
> --
> John Carvalho
>
>
>
> On Sat, Jun 4, 2022 at 1:00 PM <
> bitcoin-dev-requ...@lists.linuxfoundation.org> wrote:
>
>>
>> Date: Fri, 03 Jun 2022 18:39:34 +
>> From: alicexbt 
>> To: Bitcoin Protocol Discussion
>> 
>> Subject: [bitcoin-dev] Bitcoin covenants are inevitable
>> Message-ID:
>>
>> > protonmail.com>
>>
>> Content-Type: text/plain; charset=utf-8
>>
>> Note: This email is an opinion and not an attack on bitcoin
>>
>> Covenants on bitcoin will eventually be implemented with a soft fork. CTV
>> is the easiest and best possible way OP_TX looks good as well. Apart from
>> the technical merits, covenants will improve a few other things:
>>
>> - Developers can build interesting projects with real demand in market.
>> - Students learn Sapio and not just solidity.
>> - Better tooling could be available for application developers.
>> - Maybe we see bitcoin developer hackathons in different countries.
>> - Demand for block space might increase, it wont be just exchanges and
>> coinjoin.
>> - Funding of bitcoin developers and projects might improve. Wont need to
>> convince a few people for grants.
>>
>> **Why covenants are not contentious?**
>>
>> Some people may write paragraphs about CTV being contentious, spread
>> misinformation and do all types of drama, politics etc. on social media but
>> there are zero technical NACKs for CTV. We have discussed other covenant
>> proposals in detail on mailing list and IRC meetings with an open minded
>> approach.
>>
>> All the developers that participated in the discussion are either okay
>> with CTV or OP_TX or covenants in general.
>>
>> **How and when should covenants be implemented in Bitcoin?**
>>
>> I don't think we should wait for years anticipating a proposal that
>> everyone will agree on or argue for years to pretend changes are hard in
>> Bitcoin. We should improve the review process for soft fork BIPs and share
>> honest opinions with agreement, disagreement on technical merits.
>>
>> I prefer BIP 8 or improved BIP 8 for soft fork but I won't mind anything
>> else being used if that improves Bitcoin. Covenants implemented in Bitcoin
>> before the next cycle would provide opportunity for developers to build
>> interesting things during the bear market. Ossification supporters also
>> believe there is some window that will close soon, maybe doing changes
>> considering each case individually will be a better approach. CTV is not a
>> rushed soft fork, less people followed the research and it was not
>> mentioned on social media repeatedly by the respected developers like other
>> soft forks.
>>
>> /dev/fd0
>>
>>
>> Sent with Proton Mail secure email.
>>
>>
>> --
>>
> ___
> 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] signature abstraction

[Erik Aronesty via bitcoin-dev]

was thinking it might be possible to create a protocol for signatures where
some bounded elliptic curve parameters are in the script, allowing the
efficient verification of a broad range of elliptic curves schnorr
signatures... rather than a fixed curve

has anyone proposed this sort of thing before?

seems like it could allow higher bitness, broad hsm compatibility, and a
"decentralization and competitiveness" of security parameters for different
environments

would be useful to me, but not sure how many people care about this
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Silent Payments – Non-interactive private payments with no on-chain overhead

[Erik Aronesty via bitcoin-dev]

i like the  00 || X_spend || X_scan + mandate address reuse prevention.

might as well start with something strict

easy to loosen it later - if needed - harder to tighten it later because of
back-compatibility with addresses in-use


On Tue, May 24, 2022 at 11:02 AM alicexbt via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi woltx,
>
> Thanks for implementing silent payments in Bitcoin Core. I tried the steps
> shared in tutorial and everything works as expected.
>
> I have updated the silent payment address (signet) as TXT record for
> domain alice.silentbitco.in
>
> $ dig -t txt alice.silentbitco.in +short
> "tb1px3kma8e8y8z9l7e640v0x2chzrzww9cu06mqvwyrz805ffletu3s067sgh"
>
> I have also added basic information about silent payments proposal,
> implementation and tutorial on https://silentbitco.in
>
> I had no issues with performance of the UTXO Set and the blocks scan. I
> don't mind using flag but a new address/descriptor format should be a
> better approach. I could not review the code in detail or test edge cases
> however these suggestions by Pavol Rusnak make sense:
> https://gist.github.com/RubenSomsen/c43b79517e7cb701ebf77eec6dbb46b8?permalink_comment_id=4177027#gistcomment-4177027
>
>
> /dev/fd0
>
> Sent with ProtonMail  secure email.
>
> --- Original Message ---
> On Tuesday, May 24th, 2022 at 7:01 AM, woltx via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> I created a short and simple tutorial on how to make silent payments on
> signet.
> https://gist.github.com/w0xlt/72390ded95dd797594f80baba5d2e6ee
>
> In this tutorial, the user will generate an address, publish it, receive
> and spend coins from it and still no transactions are shown from this
> address in a blockchain explorer.
>
>
> ___
> 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] Speedy covenants (OP_CAT2)

[Erik Aronesty via bitcoin-dev]

>
>
>
> FWIW, I think the rmain reasons to do CAT+CSFS is to validate oracle
> messages and pubkey delegation.  The ability to covenants would be
> secondary and would mostly serve to get us some real user data about what
> sort of covenants users find especially valuable.
>

I don't think this should be discounted.   I think it's worthwhile to
willingly include possibly less-than-awesome, but proven perfectly-safe
opcodes, knowing we will have to validate them forever, even if new, cooler
and more widely-used ones replace them years from now.

I honestly don't think the development of the latter will happen without
some version of the former.

Personally I am satisfied:

  - the safety of covenants, in general, is covered by how addresses are
generated
  - fears of forced forward-encumbrance are not any worse than can be
easily done today
  - ctv+apo, cat+csfs are fine, but we should pick ones that everyone
thinks are "good enough for everyone who cares about them"
  - they are not an undue burden on nodes in terms of
validate-cpu-cycles-per-byte (have we proven this?)
  - the complexity is low, code is easy to validate
  - won't introduce DDOS attack vectors (also needs to be proven i think?)
  - the game theory underpinning selfish miner support of the chain won't
be altered by causing a widespread use of on-chain leveraging instruments
(shorting bitcoin on-chain would be dangerous, for example)




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

Re: [bitcoin-dev] Towards a means of measuring user support for Soft Forks

[Erik Aronesty via bitcoin-dev]

>
>
>
> Have you taken a look at my proposal
> ?
> The proposal is, to be clear, *not* "voting" but rather polling that isn't
> programmatically connected to activation. The intention is for people
> (developers) to look at the polling results and make an educated analysis
> of it as far as how it should contribute to consensus gathering.
>

it's cool, and i agree it's somewhat censorship resistant


> Let's say everyone who participates in polling broadcasts it along the
> bitcoin network (a separate network would probably be better, so as to not
> interfere with normal bitcoin, but I digress),
>

right, anyone can then publish a json file with polling aggregates at a
certain block height and anyone can quickly check to see if they are lying
or missing data


> Similar structures could be added to any script configuration to allow
> signing of polls without any significant exposure.
>

rubin's suggestion around tapscript anon voting could help with anonymity

 all of this is cool ...

but it doesn't address the "what about people who don't know there's a vote
going on"  or other the other social issues with "weighted polling" in
general, like how nonexperts can "have a say" when they simply don't
understand the relevant issues.  i personally feel like i'm "only a very
little bit up on the issues" and i have more tech knowledge than most
people i know

also, it will just be a poll of "people who pay attention to the dev list
and maybe some irc rooms"

might be worth experimenting with... but unless there's a great ux around
the tooling my guess is that it won't garner a lot of meaningful data:

open source, simple cli, gitian build, installs easily on all platforms,
works well with bitcoind rpc, works with ledger, can import a seed, etc.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Towards a means of measuring user support for Soft Forks

[Erik Aronesty via bitcoin-dev]

There are many challenges with on-chain voting, here are a few:

- We may not want votes on-chain, because it creates miner incentives for
contentious BIP's to drive up fees
- Miners can block votes from the chain
- Cold storage votes are probably the most important for certain proposals
(like vaulting), but are the least-likely to vote
- Awareness and participation in blockchain voting is typically very low
and is mostly limited to big exchanges

And off chain voting is even worse:

- We can collect votes off-chain by signing messages and publishing them
"somewhere", but where would that be?
- How do you make this censorship-resistant?
- Suppose someone's coins are protected by a hot/cold covenant, like TLUV
or CTV: parse scripts?  Ick.

Although I do wish sometimes that this were not the case, I feel like the
verbal wrangling and rough/messy-consensus building remains our best choice.

On Wed, Apr 27, 2022 at 10:07 AM Chris Riley via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> >> we should not let the wealthy make consensus decisions.
>
> >We shouldn't let the wealthy continue to control our governments.
> However, bitcoin is not a government. Its a financial network.
> >The fact of the matter is that fundamentally, the economic majority
> controls where the chain goes. Its very likely that the wealthy
> >are disproportionately represented in the economic majority. Attempting
> to subvert the economic majority seems like a bad idea.
> >The reality of control there will come out one way or another, and being
> honest about it is probably the best way to avoid major schisms in the
> future.
>
> Yes, the economic majority is important:  Who else has more incentive to
> protect the security and thus the value embodied in the network than people
> who have invested money and time in the network?  A group of people with
> 1/10/100/1000 bitcoins each has more economic incentive to do so than a
> similar sized group with 1/10/100/1000 satoshis each.  Likewise, it is
> significantly easier to mobilize 1 million people "voting" with 100
> satoshis each - a total of 1 BTC -  vs 1 people each voting with 100
> bitcoins each - a total of 1 million BTC.  I don't think anyone would say
> that even if those 1 million people, for example, thought that we should
> increase the number of bitcoins via perpetual inflation it would be a good
> idea to listen to it however the vote was done whether via transaction
> flags or something else.  Of course they could fork off.
>
> Cheers,:-)
> Chris
>
>
>
>
>
> On Wed, Apr 27, 2022 at 4:11 AM Billy Tetrud via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> >   A transaction signaling in the affirmative MUST NOT be included in a
>> block that does not signal in the affirmative
>>
>> I feel like I've heard this idea somewhere before. Its an interesting
>> idea.
>>
>> It should be noted that there is a consequence of this: holders wouldn't
>> have much say. People that transact a lot (or happen to be transacting a
>> lot during the signaling time period) would have a very disproportionate
>> ability to pressure miners than people who aren't transacting much. This
>> would probably be a pretty good proxy for future mining revenue that
>> supports (or is against) a particular thing. However, the network does do
>> more than just transact, so I would be a bit worried that such a mechanism
>> would bias the system towards things that are good for transactors and bad
>> for holders. Things like more coin inflation, larger blocks, etc.
>>
>> Another consideration is that miners are already incentivized to follow
>> the money here. Adding an *additional* incentive might be distorting the
>> market, so to speak.
>>
>> An alternative I proposed was a way to do weighted polling of holders:
>>
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020146.html
>>
>> The polling wouldn't be directly connected to the activation mechanism in
>> any way, but would just be a mechanism to gauge some portion of consensus.
>> If enough people were involved, theoretically it could be hooked up to
>> activation, but I would be pretty wary of doing that directly as well.
>>
>> > we should not let the wealthy make consensus decisions.
>>
>> We shouldn't let the wealthy continue to control our governments.
>> However, bitcoin is not a government. Its a financial network. The fact of
>> the matter is that fundamentally, the economic majority controls where the
>> chain goes. Its very likely that the wealthy are disproportionately
>> represented in the economic majority. Attempting to subvert the economic
>> majority seems like a bad idea. The reality of control there will come out
>> one way or another, and being honest about it is probably the best way to
>> avoid major schisms in the future.
>>
>> > Does a scheme like this afford us a better view into consensus than we
>> have today?
>>
>> It does more than provide a view. It directly changes the g

Re: [bitcoin-dev] What to expect in the next few weeks

[Erik Aronesty via bitcoin-dev]

>
>
> I would comment on this point, but I'm not sure I'm "technical enough". I
> have to admit: I've never played tennis.
>

You are technicial enough to read the nacks... everyone is:
https://github.com/JeremyRubin/utxos.org/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc

I can give a summary of the nack arguments here on one sentence:"I am
resisting a consensus change because we don't have consensus"

It's lovely recursive logic

--

The most cogent *technical* arguments against ctv seem fall into 3 camps:

1. APO is better for eltoo:
https://twitter.com/rusty_twit/status/1518007923896578048?s=20&t=8IUgni_i5jcfSlJ1Gy7T1A

2. CTV doesn't have recursion, but i want recursion... which are swiftly
followed by arguments against recursion:
https://bitcoinops.org/en/newsletters/2022/03/09/#limiting-script-language-expressiveness

(I usually ignore this one)

3. TLUV is super cool for vaults, so why are we even talking about CTV when
TLUV is better?

I like this (positive vibes) summary:

https://raymonddurk.medium.com/bitcoin-after-taproot-86c93fe5cc0c

Nowhere in there would anyone say CTV is "bad".

Just that other opcodes will wind up being used more because they are more
purpose-fit for 

If only we had unlimited resources we could have APO/TLUV;/CTV all ready to
go and be able to evaluate them on a level playing field / signet.

Does this sound about right?   Am I missing something?


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

Re: [bitcoin-dev] Speedy Trial

[Erik Aronesty via bitcoin-dev]

- it occurs to me that the real problem we have isn't whether miners lead
or users lead.   we know that users lead, we just need miners to be "ready"
and have time to upgrade their software

 - in the case of "evil" forks, i also don't need or want miners to
"defend" bitcoin... (if bitcoin is so broken that a bad fork gets past all
of the users, the miners have lost their purpose, so that is a fallacy of
reification and should be ignored)

 - we cannot measure user consensus in any systematic way, or else we
resort to gaming the system or centralization

- wallet votes (sign a message signalling... ), can cause
centralization pressures
- node signals (node published signal) will be sybil attacked
- eyeballs... (lol)

 - can we all agree that this verbal and social wrangling and chest
pounding seems, right now, to remain the best system of achieving
consensus?  or can we do better?










On Tue, Apr 26, 2022 at 1:42 AM Anthony Towns via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Mon, Apr 25, 2022 at 11:26:09AM -0600, Keagan McClelland via
> bitcoin-dev wrote:
> > > Semi-mandatory in that only "threshold" blocks must signal, so if
> > only 4% or 9% of miners aren't signalling and the threshold is set
> > at 95% or 90%, no blocks will be orphaned.
> > How do nodes decide on which blocks are orphaned if only some of them
> have
> > to signal, and others don't? Is it just any block that would cause the
> > whole threshold period to fail?
>
> Yes, exactly those. See [0] or [1].
>
> [0]
> https://github.com/bitcoin/bips/blob/master/bip-0008.mediawiki#Mandatory_signalling
>
> [1] https://github.com/bitcoin/bips/pull/1021
> (err, you apparently acked that PR)
>
> Cheers,
> aj
>
> ___
> 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] ANYPREVOUT in place of CTV

[Erik Aronesty via bitcoin-dev]

>
>
> useful!), using APO-AS covers it. And it's not a couple dozen more virtual
> bytes that are going to matter for
> a potential vault user.
>

makes sense that byte-efficiency would be likely less important to vault
users vs lightning noninteractive channel users


>
> the meantime others will have been able to deploy new applications
> leveraging ANYPREVOUT (Eltoo, blind
> statechains, etc..[1]).
>

a smaller code change that seems much less controversial
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] User Resisted Soft Fork for CTV

[Erik Aronesty via bitcoin-dev]

On Sat, Apr 23, 2022, 5:05 AM Billy Tetrud via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> @Zac
> >  More use cases means more blockchain usage which increases the price of
> a transaction for *everyone*.
>
> This is IMO a ridiculous opposition. Anything that increases the utility
> of the bitcoin network will increase usage of the blockchain and increase
> the price of a transaction on average. It is absurd to say such a thing is
> bad for bitcoin. Its like the old saying: "nobody goes there any more -
> its too crowded".
>
> > I like the maxim of Peter Todd: any change of Bitcoin must benefit *all*
> users.
>
> This is a fair opinion to take on the face of it. However, I completely
> disagree with it. Why must any change benefit *all* users? Did segwit
> benefit all users? Did taproot? What if an upgrade benefits 90% of users
> a LOT and at the same time doesn't negatively affect the other 10%? Is that
> a bad change? I think you'd find it very difficult to argue it is.
>
> Regardless of the above, I think CTV *does *in fact likely provide
> substantial benefit to all users in the following ways:
>
> 1. CTV allows much easier/cheaper ways of improving their security via
> wallet vaults,
>


Maybe.  But there are enough security caveats that it probably needs other
opcodes too to be useful.


DLCs, channels
>

APO (BIP118) handles these with a smaller footprint


and many other use cases.
>

Someone want to volunteer to make a table of use cases, proposed opcodes
(CTV, APO)  and a maturity and efficiency rating at each intersection?

Hard to juggle all this.

I'm not a fan of the squeaky wheel method of consensus.

I do think most people believe some form of restricted, well-tested
covenants that don't allow for recursion should make it into Bitcoin at
some point.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Simple step one for quantum

[Erik Aronesty via bitcoin-dev]

FWICT: Streamlined NTRU Prime (sntrup) has no known patent issues.

Should be fine.

Regardless, a "double-wrapped bitcoin address of some kind" can be
specified, coded up and the relevant module replaced whenever the dust
settles.

I know Bitcoin doesn't (yet) have fee "weights", but i still think these
addresses should be called "heavier" if they are at al significantly slower
to validate.

On Mon, Apr 11, 2022 at 2:07 PM Olaoluwa Osuntokun 
wrote:

> The NIST Post-Quantum Cryptography competition [1] results should be
> published "soon":
>
> https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/fvnhyQ25jUg/m/-pYN2nshBgAJ
> .
>
> The last reply on that thread promised results by the end of March, but
> since that has come and gone, I think it's safe to expect results by the
> end
> of this month (April). FWIW, NTRU and NTRU Prime both made it to round 3
> for
> the public key encryption/exchange and digital signature categories, but
> both of them seem to be mired in some sort of patent controversy atm...
>
> -- Laolu
>
> [1]: https://csrc.nist.gov/Projects/post-quantum-cryptography
>
> On Fri, Apr 8, 2022 at 5:36 PM Erik Aronesty via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> First step could be just implementing a similar address type
>> (secp26k1+NTRU) and associated validation as a soft fork
>>
>> https://www.openssh.com/releasenotes.html#9.0
>>
>> Then people can opt-in to quantum safe addresses
>>
>> Still should work with schnorr and other things
>>
>> It's a lot of work to fold this in and it's a some extra validation work
>> for nodes
>>
>> Adding a fee premium for using these addresses in order to address that
>> concern seems reasonable
>>
>> I'm not saying I endorse any action at all.  Personally I think this is
>> putting the cart like six and a half miles in front of the horse.
>>
>> But if there's a lot of people that are like yeah please do this, I'd be
>> happy to make an NTRU bip or something.
>>
>>
>>
>>
>> ___
>> 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] Simple step one for quantum

[Erik Aronesty via bitcoin-dev]

First step could be just implementing a similar address type
(secp26k1+NTRU) and associated validation as a soft fork

https://www.openssh.com/releasenotes.html#9.0

Then people can opt-in to quantum safe addresses

Still should work with schnorr and other things

It's a lot of work to fold this in and it's a some extra validation work
for nodes

Adding a fee premium for using these addresses in order to address that
concern seems reasonable

I'm not saying I endorse any action at all.  Personally I think this is
putting the cart like six and a half miles in front of the horse.

But if there's a lot of people that are like yeah please do this, I'd be
happy to make an NTRU bip or something.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt

[Erik Aronesty via bitcoin-dev]

> note how ETH has quite high on chain fees for basic transactions,
> because there are so many use-cases where the per-tx value can afford much
> higher fees. That kind of expansion of use-case also arguably harms
Bitcoin as
> a whole by providing more fuel for a future contentious blocksize debate.

i second this argument

ideally, all extensions should be explicit use cases, not generic/implicit
layers that can be exploited for unknown and possibly harmful use cases

also timing is critical for all bitcoin innovation.   look at how lightning
ate up fees

to keep bitcoin stable, we can't "scale" too quickly either

i'm a fan of, eventually (timing is critical), a lightning-compatible
mimblewible+dandelion on-chain soft fork can reduce tx size, move us from
l2 to l3, vastly improve privacy, and get more small transactions off-chain.

but it probably shouldn't be released for another 2 years


On Fri, Feb 18, 2022 at 6:41 PM Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Tue, Jan 18, 2022 at 02:57:30AM +0100, Prayank wrote:
> > Hi Peter,
> >
> > > that current lacks compelling use-cases clearly beneficial to all users
> >
> > All the use cases shared in below links look compelling enough to me and
> we can do anything that a programmer could think of using such restrictions:
> >
> >  https://utxos.org/uses/
> >
> > https://rubin.io/archive/
>
> Again, what I said was "compelling use-cases _clearly_ beneficial to _all_
> users", not just a small subset. I neither think the use-cases in those
> links
> are clearly compelling in the current form, and they of course, don't
> benefit
> all users. Indeed, the Drivechains use-case arguably *harms* all users, as
> Drivechains is arguably harmful to the security of Bitcoin as a whole.
> Similarly, the various new uses for on-chain transactions mentioned as a
> use-case arguably harms all existing users by competing for scarce
> blockchain
> space - note how ETH has quite high on chain fees for basic transactions,
> because there are so many use-cases where the per-tx value can afford much
> higher fees. That kind of expansion of use-case also arguably harms
> Bitcoin as
> a whole by providing more fuel for a future contentious blocksize debate.
>
> Bitcoin is an almost $1 trillion dollar system. We have to very carefully
> weigh
> the benefits of making core consensus changes to that system against the
> risks.
> Both for each proposal in isolation, as well as the precedent making that
> change sets.
>
> --
> 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] `OP_EVICT`: An Alternative to `OP_TAPLEAFUPDATEVERIFY`

[Erik Aronesty via bitcoin-dev]

> As I understand your counterproposal, it would require publishing one
transaction per evicted participant.

if you also pre-sign (N-2, N-3, etc), you can avoid this

> In addition, each participant has to store `N!` possible orderings in
which participants can be evicted, as you cannot predict the future and
cannot predict which partiicpants will go offline first.

why would the ordering matter?  these are unordered pre commitments to move
funds, right?   you agree post the one that represents "everyone that's
offline"

> But yes, certainly that can work, just as pre-signed transactions can be
used instead of `OP_CTV`

i don't see how multiple users can securely share a channel (allowing
massive additional scaling with lighting) without op_ctv


On Fri, Feb 18, 2022 at 9:48 AM ZmnSCPxj  wrote:

> Good morning Erik,
>
> > hey, i read that whole thing, but i'm confused as to why it's necessary
> >
> > seems like N of N participants can pre-sign an on-chain transfer of
> funds for each participant to a new address that consists of (N-1) or (N-1)
> participants, of which each portion of the signature is encrypted for the
> same (N-1) participants
> >
> > then any (N-1) subset of participants can collude publish that
> transaction at any time to remove any other member from the pool
> >
> > all of the set up  (dkg for N-1), and transfer (encryption of partial
> sigs) is done offchain, and online with the participants that are online
>
>
> As I understand your counterproposal, it would require publishing one
> transaction per evicted participant.
> In addition, each participant has to store `N!` possible orderings in
> which participants can be evicted, as you cannot predict the future and
> cannot predict which partiicpants will go offline first.
>
> Finally, please see also the other thread on lightning-dev:
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-February/003479.html
> In this thread, I point out that if we ever use channel factories, it
> would be best if we treat each channel as a 2-of-2 that participates in an
> overall N-of-N (i.e. the N in the outer channel factory is composed of
> 2-of-2).
> For example, instead of the channel factory being signed by participants
> `A`, `B`, `C`, `D`, instead the channel factory is signed by `AB`, `AC`,
> `AD`, `BC`, `BD`, `CD`, so that if e.g. participant B needs to be evicted,
> we can evict the signers `AB`, `BC`, and `BD`.
> This means that for the channel factory case, already the number of
> "participants" is quadratic on the number of *actual* participants, which
> greatly increases the number of transactions that need to be evicted in
> one-eviction-at-a-time schemes (which is how I understand your proposal) as
> well as increasing the `N!` number of signatures that need to be exchanged
> during setup.
>
>
> But yes, certainly that can work, just as pre-signed transactions can be
> used instead of `OP_CTV` or pretty much any non-`OP_CHECKMULTISIG` opcode,
> xref Smart Contracts Unchained.
>
> Regards,
> ZmnSCPxj
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] `OP_EVICT`: An Alternative to `OP_TAPLEAFUPDATEVERIFY`

[Erik Aronesty via bitcoin-dev]

hey, i read that whole thing, but i'm confused as to why it's necessary

seems like N of N participants can pre-sign an on-chain transfer of funds
for each participant to a new address that consists of (N-1) or (N-1)
participants, of which each portion of the signature is encrypted for the
same (N-1) participants

then any (N-1) subset of participants can collude publish that transaction
at any time to remove any other member from the pool

all of the set up  (dkg for N-1), and transfer (encryption of partial sigs)
is done offchain, and online with the participants that are online



On Thu, Feb 17, 2022 at 9:45 PM ZmnSCPxj via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> `OP_EVICT`: An Alternative to `OP_TAPLEAFUPDATEVERIFY`
> ==
>
> In late 2021, `aj` proposed `OP_TAPLEAFUPDATEVERIFY` in order to
> implement CoinPools and similar constructions.
>
> `Jeremy` observed that due to the use of Merkle tree paths, an
> `OP_TLUV` would require O(log N) hash revelations in order to
> reach a particular tapleaf, which, in the case of a CoinPool,
> would then delete itself after spending only a particular amount
> of funds.
> He then observed that `OP_CTV` trees also require a similar
> revelation of O(log N) transactions, but with the advantage that
> once revealed, the transactions can then be reused, thus overall
> the expectation is that the number of total bytes onchain is
> lesser compared to `OP_TLUV`.
>
> After some thinking, I realized that it was the use of the
> Merkle tree to represent the promised-but-offchain outputs of
> the CoinPool that lead to the O(log N) space usage.
> I then started thinking of alternative representations of
> sets of promised outputs, which would not require O(log N)
> revelations by avoiding the tree structure.
>
> Promised Outputs
> 
>
> Fundamentally, we can consider that a solution for scaling
> Bitcoin would be to *promise* that some output *can* appear
> onchain at some point in the future, without requiring that the
> output be shown onchain *right now*.
> Then, we can perform transactional cut-through on spends of the
> promised outputs, without requiring onchain activity ("offchain").
> Only if something Really Bad (TM) happens do we need to actually
> drop the latest set of promised outputs onchain, where it has to
> be verified globally by all fullnodes (and would thus incur scaling
> and privacy costs).
>
> As an example of the above paradigm, consider the Lightning
> Network.
> Outputs representing the money of each party in a channel are
> promised, and *can* appear onchain (via the unilateral close
> mechanism).
> In the meantime, there is a mechanism for performing cut-through,
> allowing transfers between channel participants; any number of
> transactions can be performed that are only "solidified" later,
> without expensive onchain activity.
>
> Thus:
>
> * A CoinPool is really a way to commit to promised outputs.
>   To change the distribution of those promised outputs, the
>   CoinPool operators need to post an onchain transaction, but
>   that is only a 1-input-1-output transaction, and with Schnorr
>   signatures the single input requires only a single signature.
>   But in case something Really Bad (TM) happens, any participant
>   can unilaterally close the CoinPool, instantiating the promised
>   outputs.
> * A statechain is really just a CoinPool hosted inside a
>   Decker-Wattenhofer or Decker-Russell-Osuntokun construction.
>   This allows changing the distribution of those promised outputs
>   without using an onchain transaction --- instead, a new state
>   in the Decker-Wattenhofer/Decker-Russell-Osuntokun construction
>   is created containing the new state, which invalidates all older
>   states.
>   Again, any participant can unilaterally shut it down, exposing
>   the state of the inner CoinPool.
> * A channel factory is really just a statechain where the
>   promised outputs are not simple 1-of-1 single-owner outputs,
>   but are rather 2-of-2 channels.
>   This allows graceful degradation, where even if the statechain
>   ("factory") layer has missing participants, individual 2-of-2
>   channels can still continue operating as long as they do not
>   involve missing participants, without requiring all participants
>   to be online for large numbers of transactions.
>
> We can then consider that the base CoinPool usage should be enough,
> as other mechanisms (`OP_CTV`+`OP_CSFS`, `SIGHASH_NOINPUT`) can be
> used to implement statechains and channels and channel factories.
>
> I therefore conclude that what we really need is "just" a way to
> commit ourselves to exposing a set of promised outputs, with the
> proviso that if we all agree, we can change that set (without
> requiring that the current or next set be exposed, for both
> scaling and privacy).
>
> (To Bitcoin Cashers: this is not an IOU, this is *committed* and
> can be enforced onchain, that is eno

[bitcoin-dev] bip39

[Erik Aronesty via bitcoin-dev]

really don't like that art, work, and artwork are 3 different words

would be nice to clean up adjacent ambiguity

it's not a big deal, but it can lead to confusion when writing things down


dup: ('canal', 'arm') ('can', 'alarm')
dup: ('canal', 'one') ('can', 'alone')
dup: ('canal', 'ready') ('can', 'already')
dup: ('card', 'anger') ('car', 'danger')
dup: ('card', 'ice') ('car', 'dice')
dup: ('card', 'inner') ('car', 'dinner')
dup: ('card', 'raw') ('car', 'draw')
dup: ('cart', 'able') ('car', 'table')
dup: ('cart', 'ask') ('car', 'task')
dup: ('cart', 'hat') ('car', 'that')
dup: ('cart', 'hen') ('car', 'then')
dup: ('cart', 'issue') ('car', 'tissue')
dup: ('cart', 'one') ('car', 'tone')
dup: ('cart', 'own') ('car', 'town')
dup: ('cart', 'rack') ('car', 'track')
dup: ('cart', 'rain') ('car', 'train')
dup: ('cart', 'win') ('car', 'twin')
dup: ('catch', 'air') ('cat', 'chair')
dup: ('erase', 'arch') ('era', 'search')
dup: ('fatal', 'arm') ('fat', 'alarm')
dup: ('fatal', 'one') ('fat', 'alone')
dup: ('fatal', 'ready') ('fat', 'already')
dup: ('feed', 'anger') ('fee', 'danger')
dup: ('feed', 'ice') ('fee', 'dice')
dup: ('feed', 'inner') ('fee', 'dinner')
dup: ('feed', 'raw') ('fee', 'draw')
dup: ('feel', 'earn') ('fee', 'learn')
dup: ('feel', 'end') ('fee', 'lend')
dup: ('gasp', 'act') ('gas', 'pact')
dup: ('gasp', 'age') ('gas', 'page')
dup: ('gasp', 'air') ('gas', 'pair')
dup: ('gasp', 'ill') ('gas', 'pill')
dup: ('gasp', 'raise') ('gas', 'praise')
dup: ('gasp', 'rice') ('gas', 'price')
dup: ('gasp', 'ride') ('gas', 'pride')
dup: ('gasp', 'roof') ('gas', 'proof')
dup: ('kite', 'merge') ('kit', 'emerge')
dup: ('kite', 'motion') ('kit', 'emotion')
dup: ('kite', 'state') ('kit', 'estate')
dup: ('lawn', 'arrow') ('law', 'narrow')
dup: ('lawn', 'either') ('law', 'neither')
dup: ('lawn', 'ice') ('law', 'nice')
dup: ('legal', 'arm') ('leg', 'alarm')
dup: ('legal', 'one') ('leg', 'alone')
dup: ('legal', 'ready') ('leg', 'already')
dup: ('seat', 'able') ('sea', 'table')
dup: ('seat', 'ask') ('sea', 'task')
dup: ('seat', 'hat') ('sea', 'that')
dup: ('seat', 'hen') ('sea', 'then')
dup: ('seat', 'issue') ('sea', 'tissue')
dup: ('seat', 'one') ('sea', 'tone')
dup: ('seat', 'own') ('sea', 'town')
dup: ('seat', 'rack') ('sea', 'track')
dup: ('seat', 'rain') ('sea', 'train')
dup: ('seat', 'win') ('sea', 'twin')
dup: ('skin', 'arrow') ('ski', 'narrow')
dup: ('skin', 'either') ('ski', 'neither')
dup: ('skin', 'ice') ('ski', 'nice')
dup: ('tent', 'able') ('ten', 'table')
dup: ('tent', 'ask') ('ten', 'task')
dup: ('tent', 'hat') ('ten', 'that')
dup: ('tent', 'hen') ('ten', 'then')
dup: ('tent', 'issue') ('ten', 'tissue')
dup: ('tent', 'one') ('ten', 'tone')
dup: ('tent', 'own') ('ten', 'town')
dup: ('tent', 'rack') ('ten', 'track')
dup: ('tent', 'rain') ('ten', 'train')
dup: ('tent', 'win') ('ten', 'twin')
dup: ('used', 'anger') ('use', 'danger')
dup: ('used', 'ice') ('use', 'dice')
dup: ('used', 'inner') ('use', 'dinner')
dup: ('used', 'raw') ('use', 'draw')
dup: ('wine', 'merge') ('win', 'emerge')
dup: ('wine', 'motion') ('win', 'emotion')
dup: ('wine', 'state') ('win', 'estate')
dup: ('wing', 'host') ('win', 'ghost')
dup: ('wing', 'love') ('win', 'glove')
dup: ('wing', 'old') ('win', 'gold')
dup: ('wing', 'own') ('win', 'gown')
dup: ('wing', 'race') ('win', 'grace')
dup: ('wing', 'rain') ('win', 'grain')
dup: ('wink', 'now') ('win', 'know')
dup: ('youth', 'under') ('you', 'thunder')
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit

[Erik Aronesty via bitcoin-dev]

mostly thinking out loud

suppose there is a "lightweight" node:

1. ignores utxo's below the dust limit
2. doesn't validate dust tx
3. still validates POW, other tx, etc.

these nodes could possibly get forked - accepting a series of valid,
mined blocks where there is an invalid but ignored dust tx, however
this attack seems every bit as expensive as a 51% attack

On Fri, Oct 1, 2021 at 3:45 AM Pieter Wuille via bitcoin-dev
 wrote:
>
> Jumping in late to this thread.
>
> I very much agree with how David Harding presents things, with a few comments 
> inline.
>
> ‐‐‐ Original Message ‐‐‐
> On Sunday, August 8th, 2021 at 5:51 PM, David A. Harding via bitcoin-dev 
>  wrote:
>
> > > 1.  it's not our business what outputs people want to create
> >
> > Every additional output added to the UTXO set increases the amount of
> > work full nodes need to do to validate new transactions. For miners
> > for whom fast validation of new blocks can significantly affect their
> > revenue, larger UTXO sets increase their costs and so contributes
> > towards centralization of mining.
> > Allowing 0-value or 1-sat outputs minimizes the cost for polluting the
> > UTXO set during periods of low feerates.
> > If your stuff is going to slow down my node and possibly reduce my
> > censorship resistance, how is that not my business?
>
> Indeed - UTXO set size is an externality that unfortunately Bitcoin's 
> consensus rules fail to account
> for. Having a relay policy that avoids at the very least economically 
> irrational behavior makes
> perfect sense to me.
>
> It's also not obvious how consensus rules could deal with this, as you don't 
> want consensus rules
> with hardcoded prices/feerates. There are possibilities with designs like 
> transactions getting
> a size/weight bonus/penalty, but that's both very hardforky, and hard to get 
> right without
> introducing bad incentives.
>
> > > 2.  dust outputs can be used in various authentication/delegation smart
> > > contracts
> >
> > > 3.  dust sized htlcs in lightning (
> > > 
> > > https://bitcoin.stackexchange.com/questions/46730/can-you-send-amounts-that-would-typically-be-considered-dust-through-the-light)
> > > force channels to operate in a semi-trusted mode
> >
> > > 4.  thinly divisible colored coin protocols might make use of sats as 
> > > value
> > > markers for transactions.
>
> My personal, and possibly controversial, opinion is that colored coin 
> protocols have no business being on the Bitcoin chain, possibly
> beyond committing to an occasional batched state update or so. Both because 
> there is little benefit for tokens with a trusted
> issuer already, and because it competes with using Bitcoin for BTC - the 
> token that pays for its security (at least as long as
> the subsidy doesn't run out).
>
> Of course, personal opinions are no reason to dictate what people should or 
> can use the chain for, but I do think it's reason to
> voice hesitancy to worsening the system's scalability properties only to 
> benefit what I consider misguided use.
>
> > > 5.  should we ever do confidential transactions we can't prevent it 
> > > without
> > > compromising privacy / allowed transfers
> >
> > I'm not an expert, but it seems to me that you can do that with range
> > proofs. The range proof for >dust doesn't need to become part of the
> > block chain, it can be relay only.
>
> Yeah, range proofs have a non-hidden range; the lower bound can be nonzero, 
> which could be required as part of a relay policy.
>
> Cheers,
>
> --
> Pieter
>
> ___
> 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] Drivechain: BIP 300 and 301

[Erik Aronesty via bitcoin-dev]

drivechain is a cool proposal.   i don't think there's a ton of
obvious risk to the network itself (not slow, not too much work for
nodes, etc), but it seems to encourage "bad behavior", not sure the
incentives line up to prevent thefts, and not sure that won't turn
around and bite bitcoin's main chain.

of course stacks can do this even without drivechain, so not sure what
we're hiding from there

if you're talking about extensions there's lightning-compatible
mimblewimble, which is probably more important, since it gets bitcoin
to global-scale payments, while improving fungibility, and probably
can't be implemented safely via drivechain



On Thu, Sep 2, 2021 at 2:24 PM Prayank via bitcoin-dev
 wrote:
>
> printf("Hello, World!");
>
> What are your thoughts on Drivechain and associated BIPs?
>
> This article compares Liquid and Lightning: 
> https://blog.liquid.net/six-differences-between-liquid-and-lightning/. Two 
> things from it that I am interested in while evaluating Drivechain:
>
> 1.Trust model
> 2.On-Ramps and Off-Ramps
>
> Other things:
>
> 1.Security of Bitcoin (Layer 1)
> 2.Bitcoin transactions and fees expected on layer 1 because of Drivechain
>
> Similarities and Differences between RSK and Ethereum: 
> https://medium.com/iovlabs-innovation-stories/similarities-and-differences-between-rsk-and-ethereum-e480655eff37
>
> Paul Sztorc had mentioned few things about fees in this video: 
> https://youtu.be/oga8Pwbq9M0?t=481 I am interested to know same for LN, 
> Liquid and Rootstock as well so asked a question on Bitcoin Stackexchange 
> today: 
> https://bitcoin.stackexchange.com/questions/109466/bitcoin-transactions-associated-with-layer-2-projects
>
> Two critiques are mentioned here: 
> https://www.drivechain.info/peer-review/peer-review-new/ with lot of names. I 
> don't agree with everything mentioned on project website although any 
> comments on technical things that can help Bitcoin and Bitcoin projects will 
> be great.
>
> Why discuss here and not on Twitter?
>
> 1.Twitter is not the best place for such discussions. There are some 
> interesting threads but Its mostly used for followers, likes, retweets etc. 
> and people can write anything for it.
> 2.Avoid misinformation, controversies etc.
>
> My personal opinion:
>
> We should encourage sidechain projects. I don't know much about Drivechain to 
> form a strong opinion but concept looks good which can help in making better 
> sidechains.
>
> --
>
>
> The website used in the slides of above YouTube video is misleading for few 
> reasons:
>
> 1.Blocks mined everyday (in MB) for Bitcoin is ~150 MB. It is ~600 MB for 
> Ethereum. Block limits for Bitcoin is ~4 MB per 10 minutes and ~500 MB for 
> Ethereum. If full nodes will be run by few organizations on AWS we can 
> basically do everything on chain. However the main goal isn't too make money 
> and create an illusion to do something innovative, primary goal was/is 
> decentralized network that allows settlement of payments.
>
> 2.Bitcoin uses UTXO model while Ethereum uses Account model. Basic difference 
> in transactions for two is explained in an article 
> https://coinmetrics.io/on-data-and-certainty/. Irony is the website in the 
> slides for screenshot is using Coinmetrics API and this misleading website is 
> even shared by Coinmetrics team on Twitter. So in some cases you are doing 
> more transactions, paying more fees for work which could have been done with 
> less. Inefficiency.
>
> 3.Failed transactions paying fees on Ethereum everyday, no such transactions 
> on Bitcoin.
>
> 4.Other improvements that affect fees: Segwit, Layer 2, Batching, UTXO 
> consolidation, Fee estimation, Coin selection, Exchanges, Wallets etc.
>
>
> --
> Prayank
>
> A3B1 E430 2298 178F
> ___
> 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] PSA: Taproot loss of quantum protections

[Erik Aronesty via bitcoin-dev]

Noe: for A. Chow's upgrade to work, there obviously has to be an
effort to deliberately-blacklist unupgraded coins, say after 10-20
years of opportunity to upgrade, or something like that, as long as
the transition to quantum isn't so fast that there's no way to do
this.

On Mon, Mar 22, 2021 at 10:24 AM Erik Aronesty  wrote:
>
> The argument that hashed public addresses provide meaningful quantum
> resistance is flawed *when considered in the context*.of Bitcoin
> itself.
>
> This article by Andrew Chow is easy to read and makes a strong case
> against the quantum utility of hashed public keys:
> https://cryptowords.github.io/why-does-hashing-public-keys-not-actually-provide-any-quantum-resistance
>
> And then, of course, one should be mindful of the case against quantum
> computing itself - it is neither inevitable nor "just around the
> corner".   Mikhail Dyakonov summarized the arguments well here:
> https://t.co/cgrfrroTTT?amp=1.
>
> My current stance (at my company at least) is that planning for
> quantum computing should be limited to "a provable and written ability
> to upgrade if it becomes clear that it's necessary."
>
> Does anyone think it would it be useful to write up a more official,
> and even partly functional plan for Bitcoin to use zero-knowledge
> proofs to transition to quantum resistance?
>
> - Erik Aronesty
>   CTO, Atkama
>
> On Mon, Mar 15, 2021 at 5:48 PM Luke Dashjr via bitcoin-dev
>  wrote:
> >
> > I do not personally see this as a reason to NACK Taproot, but it has become
> > clear to me over the past week or so that many others are unaware of this
> > tradeoff, so I am sharing it here to ensure the wider community is aware of
> > it and can make their own judgements.
> >
> > Mark Friedenbach explains on his blog:
> > https://freicoin.substack.com/p/why-im-against-taproot
> >
> > In short, Taproot loses an important safety protection against quantum.
> > Note that in all circumstances, Bitcoin is endangered when QC becomes a
> > reality, but pre-Taproot, it is possible for the network to "pause" while a
> > full quantum-safe fix is developed, and then resume transacting. With 
> > Taproot
> > as-is, it could very well become an unrecoverable situation if QC go online
> > prior to having a full quantum-safe solution.
> >
> > Also, what I didn't know myself until today, is that we do not actually gain
> > anything from this: the features proposed to make use of the raw keys being
> > public prior to spending can be implemented with hashed keys as well.
> > It would use significantly more CPU time and bandwidth (between private
> > parties, not on-chain), but there should be no shortage of that for anyone
> > running a full node (indeed, CPU time is freed up by Taproot!); at worst, it
> > would create an incentive for more people to use their own full node, which
> > is a good thing!
> >
> > Despite this, I still don't think it's a reason to NACK Taproot: it should 
> > be
> > fairly trivial to add a hash on top in an additional softfork and fix this.
> >
> > In addition to the points made by Mark, I also want to add two more, in
> > response to Pieter's "you can't claim much security if 37% of the supply is
> > at risk" argument. This argument is based in part on the fact that many
> > people reuse Bitcoin invoice addresses.
> >
> > First, so long as we have hash-based addresses as a best practice, we can
> > continue to shrink the percentage of bitcoins affected through social 
> > efforts
> > discouraging address use. If the standard loses the hash, the situation
> > cannot be improved, and will indeed only get worse.
> >
> > Second, when/if quantum does compromise these coins, so long as they are
> > neglected or abandoned/lost coins (inherent in the current model), it can be
> > seen as equivalent to Bitcoin mining. At the end of the day, 37% of supply
> > minable by QCs is really no different than 37% minable by ASICs. (We've seen
> > far higher %s available for mining obviously.)
> >
> > To conclude, I recommend anyone using Bitcoin to read Mark's article, my
> > thoughts, and any other arguments on the topic; decide if this is a concern
> > to you, and make your own post(s) accordingly. Mark has conceded the 
> > argument
> > (AFAIK he doesn't have an interest in bitcoins anyway), and I do not 
> > consider
> > it a showstopper - so if anyone else out there does, please make yourself
> > known ASAP since Taproot has already moved on to the activation phase and it
> > is likely software will be released within the next month or two as things
> > stand.
> >
> > Luke
> > ___
> > 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] Proof of reserves - recording

[Erik Aronesty via bitcoin-dev]

you should check out some of the earlier work done here:

https://github.com/olalonde/proof-of-solvency#assets-proof

to be honest, if any exchange supported that proof, it would be more
than enough.

there's really no way to prevent a smash-and-grab, but this does
prevent a slow-leak


On Mon, Jul 5, 2021 at 5:10 PM Billy Tetrud via bitcoin-dev
 wrote:
>
> I had the idea recently for proof of reserves done in a way that can be used 
> to verify reserves are sufficient on an ongoing basis. I'm curious if there 
> are any current approaches out there to proof of reserves that are similar.
>
> The idea is to have users create actual private keys using a seed in pretty 
> much the normal way. Users would generate a public key from this seed to 
> represent their account, and would give the public key to the custodian to 
> represent their account in a public record of account balances.
>
> When a user's account is credited, the custodian would update a map of 
> addresses (created from the public key of each account) to balances - this 
> map could be structured into a merkle tree in the usual "merkle approach". 
> The custodian would also store funds on one or more HD wallets (each with 
> many addresses) and create a proof that they own each HD wallet. The proof 
> could be as simple as a single signature created with the xpub for the 
> wallet, which would be sufficient for proving ownership over the whole 
> list/tree of addresses.
>
> These two structures (the map and the HD wallet) would be combined and 
> hashed, and the hash published in an on chain transaction (possibly along 
> with a URI where the full data can be found), on something like a daily 
> basis. Software for each user could continuously validate that their account 
> has a balance that matches what it's supposed to have, and could also verify 
> that owned addresses have funds that have at least as many coins as promised 
> to accounts. If these things aren't verifiable (either because the balances 
> total to more than the HD wallet contains, or because of data 
> unavailability), people can raise hell about it.
>
> To give user's additional proving ability, a receipt system could be added. 
> Users could request a receipt for any balance update. Eg the user would 
> create a message with a timestamp, their custodial "address", and the new 
> balance. The user would sign this receipt and send it to the custodian, who 
> would also sign it and send it back. This way, if something goes wrong, a 
> user can use this signed receipt to show that the custodian did in fact 
> promise a new updated balance at a particular time (which would cover the 
> case that the custodian records the wrong value in their map). Conversely, 
> the receipt would be useful to honest custodians as well, since they could 
> show the user's signed receipt request in the case a user is trying to lie 
> about what balance they should have. There is still the case that the 
> custodian simply refuses to return a signed receipt, in which case the user's 
> only recourse is to yell about it immediately and demand a receipt or a 
> refund.
>
> Why record it on chain? Doing that gives a clear record of proof of reserves 
> that can be verified later by anyone in the future. It prevents a custodian 
> from being able to change history when it suits them (by creating a new 
> records with false timestamps in the past). Many of these records could be 
> aggregated together and recorded in the same transaction (with a single 
> hash), so a single transaction per day could record the records of all 
> participating custodians. If all custodians are using a standard system, one 
> can cross verify that addresses claimed by one custodian aren't also claimed 
> by another custodian.
>
> Even tho the user is responsible for their keys in order to properly verify, 
> losing the keys isn't that big of a deal, since they could simply create a 
> new seed and give a new public key to the custodian - who would have other 
> identifying information they could use to validate that they own the account. 
> So it places less responsibility on the user, while still introducing people, 
> in a light-weight way, to self custody of keys.
>
> Having a record like this every day would reduce the possibility of 
> shenanigans like taking a short term loan of a large amount of 
> cryptocurrency. Sure, they could take a 10 minute loan once per day, but it 
> would also be possible to trace on-chain transactions so you could tell if 
> such a thing was going on. I wonder if there would be some way to include the 
> ability to prove balances held on the lightning network, but I suspect that 
> isn't generally possible.
>
> In any case, I'm curious what people think of this kind of thing, and if 
> systems with similar properties are already out there.
>
>
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfou

Re: [bitcoin-dev] CheckSigFromStack for Arithmetic Values

[Erik Aronesty via bitcoin-dev]

i may be ignorant here but i have a question:

Given that schnorr signatures now allow signers to perform complex
arithmetic signing operations out-of-band using their own communications
techniques, couldn't you just perform the publishing and accumulation of
these signature components without using a bitcoin script?

In other words, push the effort of combination and computation off of the
bitcoin network and nodes.


On Sat, Jul 3, 2021 at 12:01 AM Jeremy via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Yep -- sorry for the confusing notation but seems like you got it. C++
> templates have this issue too btw :)
>
> One cool thing is that if you have op_add for arbitrary width integers or
> op_cat you can also make a quantum proof signature by signing the signature
> made with checksig with the lamport.
>
> There are a couple gotchas wrt crypto assumptions on that but I'll write
> it up soon 🙂 it also works better in segwit V0 because there's no keypath
> spend -- that breaks the quantum proofness of this scheme.
>
> On Fri, Jul 2, 2021, 4:58 PM ZmnSCPxj  wrote:
>
>> Good morning Jeremy,
>>
>> > Dear Bitcoin Devs,
>> >
>> > It recently occurred to me that it's possible to do a lamport signature
>> in script for arithmetic values by using a binary expanded representation.
>> There are some applications that might benefit from this and I don't recall
>> seeing it discussed elsewhere, but would be happy for a citation/reference
>> to the technique.
>> >
>> > blog post here, https://rubin.io/blog/2021/07/02/signing-5-bytes/,
>> text reproduced below
>> >
>> > There are two insights in this post:
>> > 1. to use a bitwise expansion of the number
>> > 2. to use a lamport signature
>> > Let's look at the code in python and then translate to bitcoin script:
>> > ```python
>> > def add_bit(idx, preimage, image_0, image_1):
>> > s = sha256(preimage)
>> > if s == image_1:
>> > return (1 << idx)
>> > if s == image_0:
>> > return 0
>> > else:
>> > assert False
>> > def get_signed_number(witnesses : List[Hash], keys : List[Tuple[Hash,
>> Hash]]):
>> > acc = 0
>> > for (idx, preimage) in enumerate(witnesses):
>> > acc += add_bit(idx, preimage, keys[idx][0], keys[idx][1])
>> > return x
>> > ```
>> > So what's going on here? The signer generates a key which is a list of
>> pairs of
>> > hash images to create the script.
>> > To sign, the signer provides a witness of a list of preimages that
>> match one or the other.
>> > During validation, the network adds up a weighted value per preimage
>> and checks
>> > that there are no left out values.
>> > Let's imagine a concrete use case: I want a third party to post-hoc
>> sign a sequence lock. This is 16 bits.
>> > I can form the following script:
>> > ```
>> >  checksigverify
>> > 0
>> > SWAP sha256 DUP  EQUAL IF DROP <1> ADD ELSE 
>> EQUALVERIFY ENDIF
>> > SWAP sha256 DUP  EQUAL IF DROP <1<<1> ADD ELSE 
>> EQUALVERIFY ENDIF
>> > SWAP sha256 DUP  EQUAL IF DROP <1<<2> ADD ELSE 
>> EQUALVERIFY ENDIF
>> > SWAP sha256 DUP  EQUAL IF DROP <1<<3> ADD ELSE 
>> EQUALVERIFY ENDIF
>> > SWAP sha256 DUP  EQUAL IF DROP <1<<4> ADD ELSE 
>> EQUALVERIFY ENDIF
>> > SWAP sha256 DUP  EQUAL IF DROP <1<<5> ADD ELSE 
>> EQUALVERIFY ENDIF
>> > SWAP sha256 DUP  EQUAL IF DROP <1<<6> ADD ELSE 
>> EQUALVERIFY ENDIF
>> > SWAP sha256 DUP  EQUAL IF DROP <1<<7> ADD ELSE 
>> EQUALVERIFY ENDIF
>> > SWAP sha256 DUP  EQUAL IF DROP <1<<8> ADD ELSE 
>> EQUALVERIFY ENDIF
>> > SWAP sha256 DUP  EQUAL IF DROP <1<<9> ADD ELSE 
>> EQUALVERIFY ENDIF
>> > SWAP sha256 DUP  EQUAL IF DROP <1<<10> ADD ELSE 
>> EQUALVERIFY ENDIF
>> > SWAP sha256 DUP  EQUAL IF DROP <1<<11> ADD ELSE 
>> EQUALVERIFY ENDIF
>> > SWAP sha256 DUP  EQUAL IF DROP <1<<12> ADD ELSE 
>> EQUALVERIFY ENDIF
>> > SWAP sha256 DUP  EQUAL IF DROP <1<<13> ADD ELSE 
>> EQUALVERIFY ENDIF
>> > SWAP sha256 DUP  EQUAL IF DROP <1<<14> ADD ELSE 
>> EQUALVERIFY ENDIF
>> > SWAP sha256 DUP  EQUAL IF DROP <1<<15> ADD ELSE 
>> EQUALVERIFY ENDIF
>> > CHECKSEQUENCEVERIFY
>> > ```
>>
>> This took a bit of thinking to understand, mostly because you use the
>> `<<` operator in a syntax that uses `< >` as delimiters, which was mildly
>> confusing --- at first I thought you were pushing some kind of nested
>> SCRIPT representation, but in any case, replacing it with the actual
>> numbers is a little less confusing on the syntax front, and I think (hope?)
>> most people who can understand `1<<1` have also memorized the first few
>> powers of 2
>>
>> > ```
>> >  checksigverify
>> > 0
>> > SWAP sha256 DUP  EQUAL IF DROP <1> ADD ELSE 
>> EQUALVERIFY ENDIF
>> > SWAP sha256 DUP  EQUAL IF DROP <2> ADD ELSE 
>> EQUALVERIFY ENDIF
>> > SWAP sha256 DUP  EQUAL IF DROP <4> ADD ELSE 
>> EQUALVERIFY ENDIF
>> > SWAP sha256 DUP  EQUAL IF DROP <8> ADD ELSE 
>> EQUALVERIFY ENDIF
>> > SWAP sha256 DUP  EQUAL IF DROP <16> ADD ELSE 
>> EQUALVERIFY ENDIF
>> > SWAP sha256 DUP  EQUAL IF DROP <32> ADD ELSE 
>> EQUALVERIFY ENDIF

Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy

[Erik Aronesty via bitcoin-dev]

your protocol should always assume the email system is fully
compromised, and only send public information over email:

- public keys / addresses are sent
- other routing data encrypted with public keys (not sure how data is
routed in sabu)

your end user should be able to verify public keys  / addresses

 - use QR-codes
 - phone calls with users reading BIP words out loud
 - other in-person information exchange

separate the Sabu protocol from the app... allow others to implement
desktop version, or other versions that use other routing systems

-  you can allow direct-entry of a BIP-word-representation of a public
key/address to avoid privacy/central system concerns

On Thu, Jul 1, 2021 at 4:20 PM raymo via bitcoin-dev
 wrote:
>
> Hi Billy,
> Sorry for late reply. Let’s jump in proposal.
>
> > Some more information about the benefits of this approach vs alternatives 
> > (mainly lightning)
> The most important different is unlike the lightning, in Sabu no one
> have to open a channel and pay Bitcoin transaction fee, subsequently no
> one has to close channel and pay another Bitcoin transaction fee. It is
> the huge improvement since it drops the overhead cost of transactions.
> So, it will be more convenience to trade under Sabu protocol.
> In Sabu none of parties of a transaction are obliged to block money in
> any kind of smart contract or any other m of n signature accounts
> on-chain, so it provides more privacy.
> Since Sabu protocol is designed to motivate people to circulate
> transactions (AKA debt documents) in Sabu network, if every actor act
> rationally no one will aware how much money transferred from who to
> whom.
> In case of fraudulent activity by issuer, the creditor will send
> Guarantee Transaction (GT) to Bitcoin network in order to recapture the
> part of his credit. So, in this case the transaction is literally
> recorded on bitcoin blockchain.
> There is only one another reason to recording transaction on Bitcoin
> blockchain. Where one creditor eager to pay Bitcoin transaction fee in
> order to aggregate thousands or even millions different small amount
> debt-documents in a single transaction on Bitcoin blockchain.
> despite these two cases, the rest of transactions all occur in the Sabu
> network (supposed to be over 99%). Thus, no footprint no bottleneck and
> no over process.
>
> Another important power point of Sabu is its pure-peer-to-peer network
> architecture. In Sabu the mobile wallets communicating to each other
> directly without any central server. There is no centralization at all.
> As a result, there will be no routing as well.
> Since only issuer and creditors are aware of the content of transaction
> (who pay how much to whom) it is a huge privacy improvement, which
> doesn’t exist in other layer 2 solutions.
>
> About the usability of Sabu, although the protocol based on the
> collaborating 2 different peer-to-peer network and 3 classic
> server/client networks, but the end user (mobile wallet user) doesn’t
> see any of these complexities.
> The end user simply installs the mobile/desktop wallet and add her/his
> friends to his phonebook by adding their email address or scanning their
> email (and/or PGP public key). After that s/he can immediately start to
> send/receive Bitcoin through Sabu network. Entire communications between
> wallets are PGP encrypted.
> Another good point in Sabu design is, the 12 seed words are using for
> both Bitcoin wallet private key and the PGP private key. So, it is the
> key of user wealth and its identity as well. For more details, please
> read my previous answer to Alex Schoof.
> The issuer, by using his UTXOs and selling them to creditors earn money.
> the issuer creates the debt document (transaction) by which promises to
> creditor an amount of satoshi. These debt documents are valid Bitcoin
> transaction. The only difference is these transactions are intended to
> circulate in Sabu protocol instead of sending to Bitcoin blockchain.
> Each transaction is a small money transfer. 40,000 Satoshi as input and
> maximum 20,000 Satoshi as credit and minimum 10,000 Satoshi as Bitcoin
> transaction fee.
> The creditors will use these received transactions as money and will pay
> it in exchange of goods or services. For each transaction the creditor
> pays 10 Satoshi as Sabu-transaction-fee to issuer.
> Sabu is not custodial service and the UXTOs are always under issuer
> control, unless issuer or creditor send the signed transaction to
> Bitcoin network. When the transaction was recorded in Bitcoin
> blockchain, the creditor can spend proper UTXO in Bitcoin network.
> Imagine million people use their UTXOs in Sabu, they are issuer and
> issue/update/cancel million transactions per second. All they need is a
> mobile wallet. On the other hand, every one by knowing an issuer can buy
> some Satoshi (whit absolutely no KYC), even 1 Dollar or less, and spend
> it, this time Alice really can buy caffe by Bitcoin ;)
> The Bar can install

Re: [bitcoin-dev] Opinion on proof of stake in future

[Erik Aronesty via bitcoin-dev]

> PoS is not suitable for use as a consensus system, because
it is constitutionally incapable of producing a consensus.

true - but only for a system that is starting from nothing.

since bitcoin already exists, and we have a consensus, you can use
bitcoin's existing consensus to maintain that consensus using
references to prior state.  and yes, you simply have to limit reorgs
to not go back before PoW was abandoned in favor of PoS/PoB (assuming
all incentive problems are solved).

ie: once you have uses PoW to bootstrap the system, you can "recycle" that work.

On Thu, Jun 24, 2021 at 4:41 PM yanmaani--- via bitcoin-dev
 wrote:
>
> No, 51% of the *coin holders* can't do diddly squat. 51% of miners can,
> but in PoW, that's a different set to the coin holders.
>
> The basic problem with PoS, anyway, is that it's not actually a
> consensus system ("weak subjectivity"). Either you allow long reorgs,
> and then you open the door to long-range attacks, or you don't, and then
> you're not guaranteed that all nodes agree on the state of the chain,
> which was the purpose of the system to begin with.
>
> To put it more plainly: for PoS to work, you need a consensus on which
> block was seen first. But if you had that, you could presumably apply
> that method to determine which *transaction* was seen first, in which
> case you could do away with the blockchain entirely. (Real-world
> implementations of PoS, such that they are, do away with this
> requirement, scrapping the global consensus on ordering in favor of
> having each node decide for itself which block came first.)
>
> In other words, even if you solved all the incentive problems, the fact
> remains that PoS is not suitable for use as a consensus system, because
> it is constitutionally incapable of producing a consensus.
>
> On 2021-06-24 00:14, Billy Tetrud via bitcoin-dev wrote:
> >>  This is not true in a Proof of Work system and this difference
> > absolutely should not be trivialized.
> >
> > That is in fact true of Proof of Work as well. If a colluding
> > coalition of miners with more than 50% of the hashrate want to censor
> > transactions, they absolutely can do that by orphaning blocks that
> > contain transactions they want to censor. This is not different in
> > proof of stake.
> >
> > On Wed, Jun 23, 2021 at 11:14 AM Keagan McClelland
> >  wrote:
> >
> >>> Premise: There is a healthy exchange market for PoS Coin X with
> >> tens of thousands of participants bidding to buy and sell the coin
> >> for other currencies on the market.
> >>
> >> The difference here though is that Proof of Stake allows the quorum
> >> of coin holders to block the exchange of said coins if they are
> >> going to a particular destination. Nothing requires these staking
> >> nodes to include particular transactions into a block. With that in
> >> mind, it isn't just that you require the permission of the person
> >> who sold you the coins, which I can agree is a less dangerous form
> >> of permission, but you must also require the permission of at least
> >> 51% of the coin holders to even receive those coins in the first
> >> place. This is not true in a Proof of Work system and this
> >> difference absolutely should not be trivialized.
> >>
> >> Keagan
> >>
> >> On Wed, Jun 23, 2021 at 2:30 AM Billy Tetrud via bitcoin-dev
> >>  wrote:
> >>
> >>> Barrier to entry in PoS is being given permission by the previous
> >> owner of a token
> >>
> >> The idea that proof of stake is not permissionless is completely
> >> invalid. It pains me to see such an argument here. Perhaps we can
> >> come to an agreement by being more specific. I'd like to propose the
> >> following:
> >>
> >> Premise: There is a healthy exchange market for PoS Coin X with tens
> >> of thousands of participants bidding to buy and sell the coin for
> >> other currencies on the market.
> >>
> >> If the premise above is true, then there is no significant
> >> permission needed to enter the market for minting blocks for PoS
> >> Coin X. If you make a bid on someone's coins and they don't like you
> >> and refuse, you can move on to any one of the other tens of
> >> thousands of people in that marketplace. Would you agree, Cloud
> >> Strife, that this situation couldn't be considered "permissioned"?
> >>
> >> If not, consider that participation in *any* decentralized system
> >> requires the permission of at least one user in that system. If
> >> there are thousands of bitcoin public nodes, you require the
> >> permission of at least one of them to participate in bitcoin. No one
> >> considers bitcoin "permissioned" because of this. Do you agree?
> >>
> >> On Thu, Jun 17, 2021 at 1:15 PM Cloud Strife via bitcoin-dev
> >>  wrote:
> >>
> >> Barrier to entry in PoW is matter for hardware and energy is
> >> permissionless and exist all over the universe, permissionless cost
> >> which exists for everyone no matter who because it's unforgeable.
> >>
> >> Barrier to entry in PoS is being given permission by the pr

Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy

[Erik Aronesty via bitcoin-dev]

ser only sees its wallet is ready. So
> these 12 worlds are users wealth protector and identity sovereignty as
> well. User adds friends wallet email address or scan its QR code. The
> rest is PGP encrypted emails(handshake, agreement and transactions)
> between two wallets. No one needs to ask a central service to have an
> account. Pure Cypher punk users can run their personal email server or
> even better their freedombox https://freedomboxfoundation.org. So no one
> can stop user from using this system(Bitcoin + Sabu + Gazin) or ban his
> account. The wallet owner can easily and fast immigrate to new email
> address (or even different email service provider) and sign new address
> and notify to his friends circle with no real barrier.
> While these are all benefits of using email as a user identifier in
> system, there could be some privacy issue in some levels. For example
> most email service provider impose some sort of KYC or ask user mobile
> number, but there are other providers which are respecting users
> privacy. implicitly prevalence of Sabu users creates more demands for
> this privacy-respector-companies, so these companies will be increased.
> Another issue would be global passive spying or full-pipe project will
> find who do transaction with who. Since communications are PGP encrypted
> it won't be clear who is sender or receiver or how much is transferred
> or even if they are really parties in a transaction or it is just a fake
> noise connection! The forward secrecy also would be another issues.
> although these are mostly the privacy issues rather than Sabu intrinsic
> problems.
> Some other disadvantage of email is latency, so some third parties would
> easily provide the optional alternate communication services for wallet,
> e.g Matrix, Nym network, Onion, I2P, classic central servers, etc to
> compensate the speed and/or privacy issues. These are all communication
> means and the wallet can simply use one or more methods in parallel.
> Later we will see the wallet users will choose which solution. Speed vs
> privacy, sovereignty and independence.
>
> Regards
> Raymo
>
> On 2021-06-18 13:44, Alex Schoof wrote:
> > A few questions/comments:
> >
> > Why is there a 10 sat fee on each tx? Where does that fee go?
> >
> > I don’t think this design sufficiently protects against double
> > spends by the “issuer” (the person who actually has the UTXO).
> > Your guarantee tx mechanism only really covers the case where someone
> > tries to double spend part of a UTXO balance (in other words, if the
> > penalty lost is less than the value gained by doing a double spend,
> > its worth it to double spend, and in a world where you’re passing
> > around digital IOUs, it’s easy to make it worth it). Later in the
> > post, you mention that there will be a p2p network to gossip fund
> > transfers and that will prevent an issuer from double spending. The
> > problem there is that network latency is non-zero, large network
> > partitions are both real and common, and nodes can come and go anytime
> > (hardware failure, power failure, network partition healing, just
> > because they feel like it, etc). Different nodes on the network might
> > hear about different, conflicting transactions. Nodes will need a way
> > to all come to consensus on what the right set of “sent notes” is.
> > I think you will end up reinventing a lot of the problems solved by
> > bitcoin.
> >
> > Why did you pick email as the RPC mechanism to transfer these notes?
> > Email is going to add variable amounts of latency and things like spam
> > filters will cause issues.
> >
> > Alex
> >
> > On Fri, Jun 18, 2021 at 4:23 AM Erik Aronesty via bitcoin-dev
> >  wrote:
> >
> >> for very small transactions, this seems to make a hell of a lot of
> >> sense.
> >>
> >> it's like lightning, but with no limits, no routing protocols...
> >> everything is guaranteed by relative fees and the cost-of-theft.
> >>
> >> pretty cool.
> >>
> >> On Thu, Jun 17, 2021 at 4:14 PM raymo via bitcoin-dev
> >>  wrote:
> >>>
> >>> Hi,
> >>> I have a proposal for improve Bitcoin TPS and privacy, here is the
> >> post.
> >>>
> >>
> >
https://raymo-49157.medium.com/time-to-boost-bitcoin-circulation-million-transactions-per-second-and-privacy-1eef8568d180
> >>> https://bitcointalk.org/index.php?topic=5344020.0
> >>> Can you please read it and share your idea about it.
> >>>
> >>> Cheers
> >>> Raymo
> >>> ___
> >>> 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
> >  --
> >
> > Alex Schoof
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy

[Erik Aronesty via bitcoin-dev]

It is vulnerable to sybil attacks or where the recipient is a victim of a
proxy attack.  If the recipient is not connected to a valid Network, then
double spends could be allowed.

 as long as this protocol is intended for use of transactions around a
dollar or so I don't see that being a financially lucrative attack.

However consider a large department store.  If I put a "fence" around that
store and control all of its outbound peer connections, I can then allow
double spends for the duration of my visit at the store.

In order to defend against this large retailers would have to use
distributed / trusted nodes and certificates.











On Thu, Jun 17, 2021, 4:14 PM raymo via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi,
> I have a proposal for improve Bitcoin TPS and privacy, here is the post.
>
> https://raymo-49157.medium.com/time-to-boost-bitcoin-circulation-million-transactions-per-second-and-privacy-1eef8568d180
> https://bitcointalk.org/index.php?topic=5344020.0
> Can you please read it and share your idea about it.
>
> Cheers
> Raymo
> ___
> 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] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy

[Erik Aronesty via bitcoin-dev]

for very small transactions, this seems to make a hell of a lot of sense.

it's like lightning, but with no limits, no routing protocols...
everything is guaranteed by relative fees and the cost-of-theft.

pretty cool.

On Thu, Jun 17, 2021 at 4:14 PM raymo via bitcoin-dev
 wrote:
>
> Hi,
> I have a proposal for improve Bitcoin TPS and privacy, here is the post.
> https://raymo-49157.medium.com/time-to-boost-bitcoin-circulation-million-transactions-per-second-and-privacy-1eef8568d180
> https://bitcointalk.org/index.php?topic=5344020.0
> Can you please read it and share your idea about it.
>
> Cheers
> Raymo
> ___
> 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] Opinion on proof of stake in future

[Erik Aronesty via bitcoin-dev]

>  the classical debate with PoS supporters - I explain an attack and they 
> "patch it", creating problem elsewhere

i agree.   my original post was:

"assume that we can accurately mimic the investment in ASIC's and the
expenditure of electricity with "burns" of coin representing that
investment"

only given that assumption can i state with confidence:

- proof of burn is better than proof of stake

and only because

- your stake is sitting on a node somewhere, able to be stolen

everything else is speculation about my original assumption.

overall a good PoB would have a

- large, up front buy-in event (buying the ASIC)
- delay function (timing)
- block-specific burn (electricity use... lost if burn is not selected)
- burns linked to specific buy-ins (can only burn the ASIC's i bought in)
- max-burn === max-buy-in (ASICs have capacity)
- max-burn decays over time (ASIC's become less valuable over time)

block-height === sum of block-specific burn

On Tue, Jun 1, 2021 at 3:26 PM befreeandopen
 wrote:
>
> Comments inline.
>
>
>
> > > Could you explain what am I missing here, because this actually does not 
> > > seem better, but rather worse than some PoS schemes?
> >
> > Given your example, if !BTC is needed to burn, that's a $50k
> > investment in an ASIC needed to mine a block. That's not anywhere
> > near current levels. It's not even approaching the current PoW. A
> > $50k investment to be a large amount of hash power is ... well,
> > somewhere more than 10 years ago.
>
> This is +- true with todays prices, that was not my point. We all know that 
> today's total block revenue is nowhere near 1 BTC. If it is say 7 BTC, then 
> we would expect that the miners spend roughly just about 7 BTC to produce the 
> block - in long term, on average. Right? Today, this 7 BTC is supposed to be 
> some average of investment into the mining rig, the building in which the rig 
> exists (or its rent) and then some electricity. So when I said 1 BTC I meant 
> that amount of BTC that is the sum of the block subsidy and fees at the time 
> of this imagined switch to PoB. Use 7 BTC if you want to talk today. And yes, 
> that seems very weak. But can you explain why it is not the case after 
> switching to PoB that the cost of producing the block should roughly converge 
> to to the revenue? Because I do not see why would miners spend more than what 
> they can earn.
>
>
>
>
>
> > My original proof-of-burn concept was designed to mimic ASICs as much
> > as possible:
> >
> > 1.  large initial investment (burn to acquire power)
> > 2.  continued investment (burn to activate power in each block, lost if
> > block is not found)
> >
> > Ideally, the attacker would have to keep burning for each lottery
> > ticket, which can only be used once. Committing that burn to a
> > particular block for example.
> >
> > Any attack you propose for a "assumed well designed PoB" can also 
> > attack PoW.
> > Any attack you propose for a "assumed well designed PoB" can also 
> > attack PoS.
> >
> > But there are some things PoB can do that PoS can't... which is really
> > my original point.
>
> This is the problem that I wanted to avoid. You refer to some "my original 
> PoB", but I am strictly talking about the concept described in wiki because 
> nothing else was provided to me. If we do not have a reference description of 
> what you are talking about the debate will quickly turn into the classical 
> debate with PoS supporters - I explain an attack and they "patch it", 
> creating problem elsewhere. Then I explain an attack against that and they 
> patch it there. And this goes infinitely.
>
> So if there is some other version, better one than the one described in wiki, 
> please let me know. If there is not, there is nothing to talk about really. 
> You'd first need to define your model properly and describe very details of 
> how it should work and then we can analyze it. It does not make much sense to 
> me to analyze a ghost protocol that I always only see a tiny part of.
>
> For example here above in the quoted text you mention some continual lost (if 
> block is not found). If that is not the exponential decay as described in the 
> wiki, then I have no idea what it is. I do not say that I can't imagine for 
> myself what it could be, but it is up to you to define it, so we can be sure 
> we are talking about the same thing.
>
> Same with those early unblinding of burns - nothing about that in the wiki, 
> so that concept is alien to me and it can not be subject to a debate before 
> it is precisely described.
>
>
>
>
> >
> >
> > -   sunk costs/lost investment
> > -   "hashpower" is "offline", and cannot be seized.
> >
> > On Tue, Jun 1, 2021 at 4:21 AM befreeandopen
> > befreeando...@protonmail.com wrote:
> >
> >
> > > Erik, thanks for the link. So referring to 
> > > https://en.bitcoin.it/wiki/Proof_of_burn, I do not really understand how 
> > > this is supposed to be that much better over 

Re: [bitcoin-dev] Opinion on proof of stake in future

[Erik Aronesty via bitcoin-dev]

> Could you explain what am I missing here, because this actually does not seem 
> better, but rather worse than some PoS schemes?

Given your example, if !BTC is needed to burn, that's a $50k
investment in an ASIC needed to mine a block.  That's not anywhere
near current levels.   It's not even approaching the current PoW.   A
$50k investment to be a large amount of hash power is ... well,
somewhere more than 10 years ago.

Then you compute a ratio of 200x, where someone is spending 200x the
cost needed to mine a block.   Let's use real numbers.   Look,
instead, at the global investment in ASIC's required to mine a block.
 Now assume that in PoB, miners would spend the same amount they are
today, burning coins rather than buying ASICs.

In real life, PoB is always an "equivalent defense" to PoW, because no
matter what scenario you throw at me, one can continue to tweak the
numbers until PoB *is* equivalent.

For example, If an attacker decided to amass proof-of-burn enough to
perform a reorg, they would have to essentially spend as much money as
a 51% attack today.   And they would have to do so well in advance.
We could also require a time-locked "reveal" phase where burns are
revealed to be burns well after they are incorporated - ie: it will be
public knowledge that someone is amassing a large amount of
hashpower-equivlent.   That is one of the current advantages of PoW.

My original proof-of-burn concept was designed to mimic ASICs as much
as possible:

1. large initial investment (burn to acquire power)
2. continued investment (burn to activate power in each block, lost if
block is not found)

Ideally, the attacker would have to keep burning for each lottery
ticket, which can only be used once.   Committing that burn to a
particular block for example.

Any attack you propose for a "assumed well designed PoB" can also attack PoW.
Any attack you propose for a "assumed well designed PoB" can also attack PoS.

But there are some things PoB can do that PoS can't... which is really
my original point.

- sunk costs/lost investment
- "hashpower" is "offline", and cannot be seized.






On Tue, Jun 1, 2021 at 4:21 AM befreeandopen
 wrote:
>
> Erik, thanks for the link. So referring to 
> https://en.bitcoin.it/wiki/Proof_of_burn, I do not really understand how this 
> is supposed to be that much better over many proof of stake proposals. If 
> there is more research on PoB, please note I'm not commenting on that as I 
> only read this wiki article and my comments are purely related to this only.
>
> I hope we can agree that the idea with manual insertion of entropy every week 
> can be discarded, but at the same time I don't think it is a crucial point of 
> the whole idea. So we can just focus on the rest of it.
>
> Then the whole idea seems just like certain proof of stake implementations 
> with just small differences, which I try to summarize:
>
> - in PoB, in order to use the coin for block production, you burn it in the 
> past and wait some time -- in the certain PoS I'm talking about, in order to 
> use the coin, you do not move the coin for some time - so in both there is 
> the same idea - you somehow make the coin eligible for the block creation 
> process by first doing some action followed by some inaction for some time; 
> the difference here is that if later you use such coin in PoS, then after 
> waiting more time, you can use the coin again (for whatever purpose), while 
> in PoB the coin is gone forever (it is burned); this does not seem to be 
> fundamentally different
>
> - in PoB, the author suggests there is an exponential decay of the power of 
> the coin to create a block; in some PoS schemas, there historically was an 
> era of so called CoinAge mechanism, which was somewhat inverse to this 
> exponential decay, it was that the coin gets more power the older it is 
> untouched, some implementations were for linear increase in the power, some 
> exponential. Usually there was a certain limit - i.e. a maximum power the 
> coin may have reached. It turned out quite quickly that such property is 
> making attacks easier. PoB reverses the idea, but I don't think that helps 
> that much. In any case, there seems to be an optimal period of time for each 
> used coin, in both PoS and PoB, where the coin is most suitable for block 
> production. I admit PoB version is better, but the crucial property here is 
> that some coins are more powerful than other.
>
> - in both PoB and PoS it seems there is linear increase of the ability of the 
> coin to produce blocks with the size of the coin (more BTC you burn/stake, 
> the better your chance)
>
> This characteristic of PoB does not suggest that it would have that much 
> different properties than PoS. So it should suffer from same problems as PoS. 
> Namely, the problems I see now, with the given proposal from wiki, are:
>
> - there seems to be lack of definition of the heaviest chain and difficulty 
> adjustment - this seems crucial, but likely 

Re: [bitcoin-dev] Opinion on proof of stake in future

[Erik Aronesty via bitcoin-dev]

gt; > > > > for simplicity and desperately want to avoid extraneous 
> > > > > > > > > > responsibilities for the holder of the coin.
> > > > > > > > > > After all, gold is an inert element on the periodic table 
> > > > > > > > > > that doesn't confer responsibilities on the holder to 
> > > > > > > > > > maintain the quality of all the other bars of gold out 
> > > > > > > > > > there.
> > > > > > > > > > Bitcoin feels like this too and in many ways is more inert 
> > > > > > > > > > and beautifully boring than gold.
> > > > > > > > > > For Bitcoin to succeed I think we need to keep it that way 
> > > > > > > > > > and Proof-of-Stake makes everything a bit too exciting.
> > > > > > > > > > I suppose in the end the market will decide what is real 
> > > > > > > > > > digital gold and whether these bad technical trade offs are 
> > > > > > > > > > worth being able to say it uses less electricity. It goes 
> > > > > > > > > > without saying that making bad technical decisions to 
> > > > > > > > > > appease the current political climate is an anathema to 
> > > > > > > > > > Bitcoin.
> > > > > > > > > > Would be interested to know if you or others think 
> > > > > > > > > > differently on these points.
> > > > > > > > > > Cheers,
> > > > > > > > > > LL
> > > > > > > > > > On Fri, 21 May 2021 at 19:21, Billy Tetrud via bitcoin-dev 
> > > > > > > > > > bitcoin-dev@lists.linuxfoundation.org wrote:
> > > > > > > > > >
> > > > > > > > > > > I think there is a lot of misinformation and bias against 
> > > > > > > > > > > Proof of Stake. Yes there have been lots of shady coins 
> > > > > > > > > > > that use insecure PoS mechanisms. Yes there have been 
> > > > > > > > > > > massive issues with distribution of PoS coins (of course 
> > > > > > > > > > > there have also been massive issues with PoW coins as 
> > > > > > > > > > > well). However, I want to remind everyone that there is a 
> > > > > > > > > > > difference between "proved to be impossible" and "have 
> > > > > > > > > > > not achieved recognized success yet". Most of the 
> > > > > > > > > > > arguments levied against PoS are out of date or rely on 
> > > > > > > > > > > unproven assumptions or extrapolation from the analysis 
> > > > > > > > > > > of a particular PoS system. I certainly don't think we 
> > > > > > > > > > > should experiment with bitcoin by switching to PoS, but 
> > > > > > > > > > > from my research, it seems very likely that there is a 
> > > > > > > > > > > proof of stake consensus protocol we could build that has 
> > > > > > > > > > > substantially higher security (cost / capital required to 
> > > > > > > > > > > execute an attack) while at the same time costing far 
> > > > > > > > > > > less resources (which do translate to fees on the 
> > > > > > > > > > > network) without compromising any of the critical 
> > > > > > > > > > > security properties bitcoin relies on. I think the 
> > > > > > > > > > > critical piece of this is the disagreements around 
> > > > > > > > > > > hardcoded checkpoints, which is a critical piece solving 
> > > > > > > > > > > attacks that could be levied on a PoS chain, and how that 
> > > > > > > > > > > does (or doesn't) affect the security model.
> > > > > > > > > > > @Eric Your proof of stake fallacy seems to be saying that 
> > > > > > > > > > > PoS is worse when a 51% attack happens. While I agree, I 
> > > > > > > > > > > think that line of thin

Re: [bitcoin-dev] Opinion on proof of stake in future

[Erik Aronesty via bitcoin-dev]

n keys are delegated off-chain and so are not making 
>>>> >> >> > as much of a mess.
>>>> >> >> >
>>>> >> >> > ### Conclusion
>>>> >> >> >
>>>> >> >> > I don't see a way to get around the conflicting requirement that 
>>>> >> >> > the keys for large amounts of coins should be kept offline but 
>>>> >> >> > those are exactly the coins we need online to make the scheme 
>>>> >> >> > secure.
>>>> >> >> > If we allow delegation then we open up a new social attack surface 
>>>> >> >> > and it degenerates to Proof-of-SquareSpace.
>>>> >> >> >
>>>> >> >> > For a "digital gold" like system like Bitcoin we optimize for 
>>>> >> >> > simplicity and desperately want to avoid extraneous 
>>>> >> >> > responsibilities for the holder of the coin.
>>>> >> >> > After all, gold is an inert element on the periodic table that 
>>>> >> >> > doesn't confer responsibilities on the holder to maintain the 
>>>> >> >> > quality of all the other bars of gold out there.
>>>> >> >> > Bitcoin feels like this too and in many ways is more inert and 
>>>> >> >> > beautifully boring than gold.
>>>> >> >> > For Bitcoin to succeed I think we need to keep it that way and 
>>>> >> >> > Proof-of-Stake makes everything a bit too exciting.
>>>> >> >> >
>>>> >> >> > I suppose in the end the market will decide what is real digital 
>>>> >> >> > gold and whether these bad technical trade offs are worth being 
>>>> >> >> > able to say it uses less electricity. It goes without saying that 
>>>> >> >> > making bad technical decisions to appease the current political 
>>>> >> >> > climate is an anathema to Bitcoin.
>>>> >> >> >
>>>> >> >> > Would be interested to know if you or others think differently on 
>>>> >> >> > these points.
>>>> >> >> >
>>>> >> >> > [1]: 
>>>> >> >> > https://developer.algorand.org/docs/run-a-node/participate/generate_keys/
>>>> >> >> > [2]: https://staking.staked.us/algorand-staking
>>>> >> >> > [3]: https://eprint.iacr.org/2017/573.pdf
>>>> >> >> > [4]: 
>>>> >> >> > https://algorandcom.cdn.prismic.io/algorandcom%2Fece77f38-75b3-44de-bc7f-805f0e53a8d9_theoretical.pdf
>>>> >> >> > [5]: 
>>>> >> >> > https://hydra.iohk.io/build/790053/download/1/delegation_design_spec.pdf
>>>> >> >> >
>>>> >> >> > Cheers,
>>>> >> >> >
>>>> >> >> > LL
>>>> >> >> >
>>>> >> >> > On Fri, 21 May 2021 at 19:21, Billy Tetrud via bitcoin-dev 
>>>> >> >> >  wrote:
>>>> >> >> >>
>>>> >> >> >> I think there is a lot of misinformation and bias against Proof 
>>>> >> >> >> of Stake. Yes there have been lots of shady coins that use 
>>>> >> >> >> insecure PoS mechanisms. Yes there have been massive issues with 
>>>> >> >> >> distribution of PoS coins (of course there have also been massive 
>>>> >> >> >> issues with PoW coins as well). However, I want to remind 
>>>> >> >> >> everyone that there is a difference between "proved to be 
>>>> >> >> >> impossible" and "have not achieved recognized success yet". Most 
>>>> >> >> >> of the arguments levied against PoS are out of date or rely on 
>>>> >> >> >> unproven assumptions or extrapolation from the analysis of a 
>>>> >> >> >> particular PoS system. I certainly don't think we should 
>>>> >> >> >> experiment with bitcoin by switching to PoS, but from my 
>>>> >> >> >> research, it seems very likely that there is a proof of stake 
>>>> >>

Re: [bitcoin-dev] Opinion on proof of stake in future

[Erik Aronesty via bitcoin-dev]

t;> >> >> >
>>> >> >> > ### "Pure" proof of stake (Algorand)
>>> >> >> >
>>> >> >> > Algorand's[4] approach is to only allow online stake to participate 
>>> >> >> > in the protocol.
>>> >> >> > Theoretically, This means that keys holding funds have to be online 
>>> >> >> > in order for them to author blocks when they are chosen.
>>> >> >> > Of course in reality no one wants to keep their coin holding keys 
>>> >> >> > online so in Alogorand you can authorize a set of "participation 
>>> >> >> > keys"[1] that will be used to create blocks on your coin holding 
>>> >> >> > key's behalf.
>>> >> >> > Hopefully you've spotted the problem.
>>> >> >> > You can send your participation keys to any malicious party with a 
>>> >> >> > nice website (see random example [2]) offering you a good return.
>>> >> >> > Damn it's still Proof-of-SquareSpace!
>>> >> >> > The minor advantage is that at least the participation keys expire 
>>> >> >> > after a certain amount of time so eventually the SquareSpace 
>>> >> >> > attacker will lose their hold on consensus.
>>> >> >> > Importantly there is also less junk on the blockchain because the 
>>> >> >> > participation keys are delegated off-chain and so are not making as 
>>> >> >> > much of a mess.
>>> >> >> >
>>> >> >> > ### Conclusion
>>> >> >> >
>>> >> >> > I don't see a way to get around the conflicting requirement that 
>>> >> >> > the keys for large amounts of coins should be kept offline but 
>>> >> >> > those are exactly the coins we need online to make the scheme 
>>> >> >> > secure.
>>> >> >> > If we allow delegation then we open up a new social attack surface 
>>> >> >> > and it degenerates to Proof-of-SquareSpace.
>>> >> >> >
>>> >> >> > For a "digital gold" like system like Bitcoin we optimize for 
>>> >> >> > simplicity and desperately want to avoid extraneous 
>>> >> >> > responsibilities for the holder of the coin.
>>> >> >> > After all, gold is an inert element on the periodic table that 
>>> >> >> > doesn't confer responsibilities on the holder to maintain the 
>>> >> >> > quality of all the other bars of gold out there.
>>> >> >> > Bitcoin feels like this too and in many ways is more inert and 
>>> >> >> > beautifully boring than gold.
>>> >> >> > For Bitcoin to succeed I think we need to keep it that way and 
>>> >> >> > Proof-of-Stake makes everything a bit too exciting.
>>> >> >> >
>>> >> >> > I suppose in the end the market will decide what is real digital 
>>> >> >> > gold and whether these bad technical trade offs are worth being 
>>> >> >> > able to say it uses less electricity. It goes without saying that 
>>> >> >> > making bad technical decisions to appease the current political 
>>> >> >> > climate is an anathema to Bitcoin.
>>> >> >> >
>>> >> >> > Would be interested to know if you or others think differently on 
>>> >> >> > these points.
>>> >> >> >
>>> >> >> > [1]: 
>>> >> >> > https://developer.algorand.org/docs/run-a-node/participate/generate_keys/
>>> >> >> > [2]: https://staking.staked.us/algorand-staking
>>> >> >> > [3]: https://eprint.iacr.org/2017/573.pdf
>>> >> >> > [4]: 
>>> >> >> > https://algorandcom.cdn.prismic.io/algorandcom%2Fece77f38-75b3-44de-bc7f-805f0e53a8d9_theoretical.pdf
>>> >> >> > [5]: 
>>> >> >> > https://hydra.iohk.io/build/790053/download/1/delegation_design_spec.pdf
>>> >> >> >
>>> >> >> > Cheers,
>>> >> >> >
>>> >> >> > LL
>>> >> >> >
>>> >>

Re: [bitcoin-dev] Opinion on proof of stake in future

[Erik Aronesty via bitcoin-dev]

take tends towards oligopolistic control
>> >> >>
>> >> >> People repeat this often, but the facts support this. There is no 
>> >> >> centralization pressure in any proof of stake mechanism that I'm aware 
>> >> >> of. IE if you have 10 times as much coin that you use to mint blocks, 
>> >> >> you should expect to earn 10x as much minting revenue - not more than 
>> >> >> 10x. By contrast, proof of work does in fact have clear centralization 
>> >> >> pressure - this is not disputed. Our goal in relation to that is to 
>> >> >> ensure that the centralization pressure remains insignifiant. Proof of 
>> >> >> work also clearly has a lot more barriers to entry than any proof of 
>> >> >> stake system does. Both of these mean the tendency towards 
>> >> >> oligopolistic control is worse for PoW.
>> >> >>
>> >> >> > Energy usage, in-and-of-itself, is nothing to be ashamed of!!
>> >> >>
>> >> >> I certainly agree. Bitcoin's energy usage at the moment is I think 
>> >> >> quite warranted. However, the question is: can we do substantially 
>> >> >> better. I think if we can, we probably should... eventually.
>> >> >>
>> >> >> > Proof of Stake is only resilient to ⅓ of the network demonstrating a 
>> >> >> > Byzantine Fault, whilst Proof of Work is resilient up to the ½ 
>> >> >> > threshold
>> >> >>
>> >> >> I see no mention of this in the pos.pdf you linked to. I'm not aware 
>> >> >> of any proof that all PoS systems have a failure threshold of 1/3. I 
>> >> >> know that staking systems like Casper do in fact have that 1/3 
>> >> >> requirement. However there are PoS designs that should exceed that up 
>> >> >> to nearly 50% as far as I'm aware. Proof of work is not in fact 
>> >> >> resilient up to the 1/2 threshold in the way you would think. IE, if 
>> >> >> 100% of miners are currently honest and have a collective 100 
>> >> >> exahashes/s hashpower, an attacker does not need to obtain 100 
>> >> >> exahashes/s, but actually only needs to accumulate 50 exahashes/s. 
>> >> >> This is because as the attacker accumulates hashpower, it drives 
>> >> >> honest miners out of the market as the difficulty increases to beyond 
>> >> >> what is economically sustainable. Also, its been shown that the best 
>> >> >> proof of work can do is require an attacker to obtain 33% of the 
>> >> >> hashpower because of the selfish mining attack discussed in depth in 
>> >> >> this paper: https://arxiv.org/abs/1311.0243. Together, both of these 
>> >> >> things reduce PoW's security by a factor of about 83% (1 - 50%*33%).
>> >> >>
>> >> >>  > Proof of Stake requires other trade-offs which are incompatible 
>> >> >> with Bitcoin's objective (to be a trustless digital cash) — 
>> >> >> specifically the famous "security vs. liveness" guarantee
>> >> >>
>> >> >> Do you have a good source that talks about why you think proof of 
>> >> >> stake cannot be used for a trustless digital cash?
>> >> >>
>> >> >> > You cannot gain tokens without someone choosing to give up those 
>> >> >> > coins - a form of permission.
>> >> >>
>> >> >> This is not a practical constraint. Just like in mining, some nodes 
>> >> >> may reject you, but there will likely be more that will accept you, 
>> >> >> some sellers may reject you, but most would accept your money as 
>> >> >> payment for bitcoins. I don't think requiring the "permission" of one 
>> >> >> of millions of people in the market can be reasonably considered a 
>> >> >> "permissioned currency".
>> >> >>
>> >> >> > 2. Proof of stake must have a trusted means of timestamping to 
>> >> >> > regulate overproduction of blocks
>> >> >>
>> >> >> Both PoW and PoS could mine/mint blocks twice as fast if everyone 
>> >> >> agreed to double their clock speeds. Both systems rely on an ho

Re: [bitcoin-dev] Reducing block reward via soft fork

[Erik Aronesty via bitcoin-dev]

>  > I don't think 99% of transactions need that level of security

>  Well you can't get security for the 1% of transactions that need it without 
> giving that security to all transactions on the chain. Also, the blockchain 
> security created by miners isn't really a per transaction thing anyway. An 
> attack would affect all bitcoins regardless of what transactions they do or 
> do not take part in.

yes, and this is what lightning is for.   to secure the 99% of
transactions that *don't* need billions of dollars and years in lead
time of security.

at current prices, and even with the current known issues, lightning
is perfectly acceptable for small transactions.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev