Nostr notes by

📅 Original date posted:2023-07-26 🗒️ Summary of this ...

2023-07-27T02:26:33+02:00

In reply to nevent1q…7hlu
_________________________

📅 Original date posted:2023-07-26
🗒️ Summary of this message: The author suggests that whenever a public key is transmitted, it should come with a "proof of secret key" to prevent vulnerabilities.
📝 Original message:
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 at 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 <erik at q32.com> 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 at 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 at 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 at lists.linuxfoundation.org
>>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230726/b46458c8/attachment-0001.html>;

📅 Original date posted:2023-07-25 🗒️ Summary of this ...

2023-07-27T02:26:33+02:00

In reply to nevent1q…psc7
_________________________

📅 Original date posted:2023-07-25
🗒️ Summary of this message: The discussion is about the security of the blind MuSig scheme and the potential vulnerabilities it may have.
📝 Original message:
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 at 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 at 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 at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230725/717e4669/attachment-0001.html>;

📅 Original date posted:2023-07-24 🗒️ Summary of this ...

2023-07-24T17:55:41+02:00

In reply to nevent1q…e97l
_________________________

📅 Original date posted:2023-07-24
🗒️ Summary of this message: The email discusses the potential vulnerabilities of a proposed scheme and suggests an alternative approach that may be worth exploring.
📝 Original message:
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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230724/fc27bc0b/attachment-0001.html>;

📅 Original date posted:2023-07-24 🗒️ Summary of this ...

2023-07-24T17:55:40+02:00

In reply to nevent1q…s3r3
_________________________

📅 Original date posted:2023-07-24
🗒️ Summary of this message: The text discusses the implementation of a version of 2-of-2 Schnorr Musig2 for statechains, where the server is fully blinded. The security relies on the server reporting the number of partial signatures generated and verifying the full set of signatures client-side. The protocol involves generating private and public keys, aggregating the public keys, and signing a message using nonces.
📝 Original message:
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 at 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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230724/d9ef0309/attachment.html>;

📅 Original date posted:2023-04-18 🗒️ Summary of this ...

2023-06-08T01:20:34+02:00

In reply to nevent1q…rgth
_________________________

📅 Original date posted:2023-04-18
🗒️ Summary of this message: Bitcoin Core's communication issues have caused frustration among contributors, with poor communication and lack of rationale for merge decisions. BIP 119 and 118 are potential solutions.
📝 Original message: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 at 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 frustrate me with their lack of transparency
> and accountability. But this issue isn't going away and I'm sure we'll
> hear more on this from others in the coming months. To me it is a straight
> choice of taking transparency and accountability much more seriously or
> failing that investing more heavily (time and resources) in consensus
> compatible forks of Core and treating Core like it is a proprietary "open
> source" project where merge decisions are not explained or justified in the
> open.
>
>
> [0]: https://github.com/bitcoin/bitcoin/pull/25871
>
> [1]: https://github.com/bitcoin/bitcoin/pull/21702
>
> [2]:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020386.html
>
> [3]:
> https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718
>
> [4]: https://utxos.org/signals/
>
> [5]:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020921.html
>
> [6]:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020948.html
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230418/bcbd39a5/attachment-0001.html>;

📅 Original date posted:2023-01-31 🗒️ Summary of this ...

2023-06-08T01:18:48+02:00

In reply to nevent1q…ts65
_________________________

📅 Original date posted:2023-01-31
🗒️ Summary of this message: Concerns over limited block space decreasing acceptance of soft fork opcode tech improvements. Schnorr sigs and vault tech seen as useful for anonymity and security.
📝 Original message: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230131/8dfd128b/attachment.html>;

📅 Original date posted:2022-12-05 📝 Original message:> ...

2023-06-08T01:17:30+02:00

In reply to nevent1q…5jvq
_________________________

📅 Original date posted:2022-12-05
📝 Original message:>
>
>
> 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?

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221205/9b947dc5/attachment-0001.html>;

📅 Original date posted:2022-12-05 📝 Original message:note: ...

2023-06-08T01:17:22+02:00

In reply to nevent1q…wn7z
_________________________

📅 Original date posted:2022-12-05
📝 Original message: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 at 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 at 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? It was originally
>> announced
>> hours earlier. From one of my full-rbf nodes:
>>
>> 2022-11-14T14:08:37Z [mempool] replacing tx
>> 764867062b67fea61810c3858d587da83a28290545e882935a32285028084317 with
>> 397dcbe4e95ec40616e3dfc4ff8ffa158d2e72020b7d11fc2be29d934d69138c for
>> 0.00468 additional fees, -1 delta bytes
>>
>> > - 22:35 - block 763189 is mined
>> > - 22:39 - block 763190 is mined
>> > - 23:11 - block 763191 is mined
>> > - 23:17 - block 763192 is mined including 397dcbe4
>> >
>> > miningpool.observer reports both 397dcbe4 and ba967010 as missing in the
>> > first three blocks, and gives similar mempool ages for those txs to what
>> > my logs report:
>> >
>> >
>> https://miningpool.observer/template-and-block/0000000000000000000436aba59d8430061e0e50592215f7f263bfb1073ccac7
>> >
>> https://miningpool.observer/template-and-block/00000000000000000005600404792bacfd8a164d2fe9843766afb2bfbd937309
>> >
>> https://miningpool.observer/template-and-block/00000000000000000004a3073f58c9eae40f251ea7aeaeac870daeac4b238fd1
>> >
>> > That presumably means those pools (AntPool twice and "unknown") are
>> > running with large mempools that didn't kept the earlier 1.2sat/vb txs.
>>
>> To be clear, you think that AntPool and that other exchange is running
>> with a
>> larger than normal max mempool size limit? You mean those miners *did*
>> keep the
>> earlier 1.2sat/vb tx?
>>
>> > The txs were mined by Foundry:
>> >
>> >
>> https://miningpool.observer/template-and-block/00000000000000000001382a226aedac822de80309cca2bf1253b35d4f8144f5
>> >
>> > This seems to be pretty good evidence that we currently don't have any
>> > significant hashrate mining with fullrbf policies (<0.5% if there was a
>> > high fee replacement available prior to every block having been mined),
>> > despite the bounty having been collected.
>>
>> Oh, we can put much lower bounds on that. I've been running OTS calendars
>> with
>> full-rbf replacements for a few months without clear evidence of a
>> full-rbf
>> replacement. While there was good reason to think some miners were mining
>> full-rbf before a few years back, they probably didn't bother to reapply
>> their
>> patches each upgrade. `mempoolfullrbf=1` is much simpler to use.
>>
>> --
>> https://petertodd.org 'peter'[:-1]@petertodd.org
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221205/2bf5f021/attachment-0001.html>;

📅 Original date posted:2022-12-01 📝 Original message:There ...

2023-06-08T01:17:10+02:00

In reply to nevent1q…9mts
_________________________

📅 Original date posted:2022-12-01
📝 Original message: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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221201/cc56e561/attachment.html>;

📅 Original date posted:2022-11-07 📝 Original message:> ...

2023-06-08T01:16:19+02:00

In reply to nevent1q…3d4j
_________________________

📅 Original date posted:2022-11-07
📝 Original message:>
>
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221107/e76ee3c5/attachment.html>;

📅 Original date posted:2022-10-19 📝 Original message:> ...

2023-06-08T01:14:37+02:00

In reply to nevent1q…n530
_________________________

📅 Original date posted:2022-10-19
📝 Original message:> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221019/2a1058ab/attachment-0001.html>;

📅 Original date posted:2022-10-14 📝 Original message:Also, ...

2023-06-08T01:14:32+02:00

In reply to nevent1q…8cpr
_________________________

📅 Original date posted:2022-10-14
📝 Original message: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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221014/3341dfbc/attachment-0001.html>;

📅 Original date posted:2022-07-12 📝 Original message:> ...

2023-06-08T01:11:46+02:00

In reply to nevent1q…4leh
_________________________

📅 Original date posted:2022-07-12
📝 Original message:>
> 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

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220712/df4c711e/attachment.html>;

📅 Original date posted:2022-07-13 📝 Original ...

2023-06-08T01:11:45+02:00

In reply to nevent1q…zkmc
_________________________

📅 Original date posted:2022-07-13
📝 Original message: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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220713/671597fe/attachment.html>;

📅 Original date posted:2022-07-11 📝 Original message:> ...

2023-06-08T01:11:41+02:00

In reply to nevent1q…afsu
_________________________

📅 Original date posted:2022-07-11
📝 Original message:>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220711/4d93ee87/attachment.html>;

📅 Original date posted:2022-07-11 📝 Original message:> ...

2023-06-08T01:11:40+02:00

In reply to nevent1q…xtt9
_________________________

📅 Original date posted:2022-07-11
📝 Original message:> 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 at 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 week but that it's
> reliable would be a reasonable thing to do, but users unfortunately are
> very averse to transactions taking a while.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220711/c357b407/attachment-0001.html>;

📅 Original date posted:2022-07-11 📝 Original message:> ...

2023-06-08T01:11:35+02:00

In reply to nevent1q…c68t
_________________________

📅 Original date posted:2022-07-11
📝 Original message:>
>
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220711/451e1d28/attachment-0001.html>;

📅 Original date posted:2022-07-26 📝 Original message:> ...

2023-06-08T01:11:30+02:00

In reply to nevent1q…qnkg
_________________________

📅 Original date posted:2022-07-26
📝 Original message:> I'm pretty sure we will have a textbook case of Prisoner's Dilemma here.

no, there is no large payoff for betrayal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220726/5f2447ef/attachment-0001.html>;

📅 Original date posted:2022-07-25 📝 Original message:even ...

2023-06-08T01:11:29+02:00

In reply to nevent1q…ghx7
_________________________

📅 Original date posted:2022-07-25
📝 Original message: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 <erik at q32.com> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220725/be53600c/attachment-0001.html>;

📅 Original date posted:2022-07-18 📝 Original message:> ...

2023-06-08T01:11:29+02:00

In reply to nevent1q…vw3g
_________________________

📅 Original date posted:2022-07-18
📝 Original message:>
>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220718/442c400a/attachment.html>;

📅 Original date posted:2022-07-08 📝 Original message:On ...

2023-06-08T01:11:07+02:00

In reply to nevent1q…kfrj
_________________________

📅 Original date posted:2022-07-08
📝 Original message:On Thu, Jul 7, 2022 at 8:29 PM Eric Voskuil <eric at voskuil.org> wrote:

> Value is subjective, though a constraint of 1tx per 10 minutes seems
> unlikey to create a fee of 5000x that of 5000tx. This is of course why I
> stated my assumption. Yet this simple example should make clear that at
> some point a reduction in confirmation rate reduces reward. Otherwise a
> rate of zero implies infinite reward.
>

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 .
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220708/d70ca037/attachment-0001.html>;

📅 Original date posted:2022-06-06 📝 Original ...

2023-06-08T01:10:04+02:00

In reply to nevent1q…k9du
_________________________

📅 Original date posted:2022-06-06
📝 Original message: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 at 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-request at lists.linuxfoundation.org> wrote:
>
>>
>> Date: Fri, 03 Jun 2022 18:39:34 +0000
>> From: alicexbt <alicexbt at protonmail.com>
>> To: Bitcoin Protocol Discussion
>> <bitcoin-dev at lists.linuxfoundation.org>
>> Subject: [bitcoin-dev] Bitcoin covenants are inevitable
>> Message-ID:
>>
>> <QOWIpROGDv5HHP2GsDiSOsTJ9TVZhFeSP3C03_e2Z3XtOKC_4N5GJtxbdlxuhErvhLZXo1Rn_7SWAQ9XRPwHFuYyArZryTVENefDZuGTAYA=@
>> 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220606/cea5b415/attachment.html>;

📅 Original date posted:2022-06-12 📝 Original message:Yes ...

2023-06-08T01:10:04+02:00

In reply to nevent1q…7lgk
_________________________

📅 Original date posted:2022-06-12
📝 Original message: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 <pete at petertodd.org> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220612/b66df85b/attachment.html>;

📅 Original date posted:2022-04-27 📝 Original message:There ...

2023-06-08T01:08:24+02:00

In reply to nevent1q…r3jy
_________________________

📅 Original date posted:2022-04-27
📝 Original message: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 at 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 10000 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 at 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 game theory
>> around how activation works. If we wanted to simply get a better view into
>> consensus, we could allow the same thing, but allow any block to mine any
>> transaction regardless of transaction signaling. Then it would be more
>> purely informational.
>>
>> > Can it be gamed to give us a *worse* view into consensus? How?
>> > Does it measure the right thing? If not, what do you think is the right
>> thing to measure?
>>
>> Doesn't seem like it could be gamed, but as I mentioned above, the honest
>> mechanics of it might be themselves undesirably distorting.
>>
>>
>>
>> On Tue, Apr 26, 2022 at 3:49 PM Bryan Bishop via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> You may be interested in these posts on transaction signalling:
>>>
>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/014193.html
>>>
>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/014202.html
>>>
>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014251.html
>>>
>>>
>>> On Tue, Apr 26, 2022 at 3:12 PM Keagan McClelland via bitcoin-dev <
>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>>> Hi all,
>>>>
>>>> Alongside the debate with CTV right now there's a second debate that
>>>> was not fully hashed out in the activation of Taproot. There is a lot of
>>>> argument around what Speedy Trial is or isn't, what BIP8 T/F is or isn't
>>>> etc. A significant reason for the breakdown in civility around this debate
>>>> is that because we don't have a means of measuring user support for
>>>> proposed sof-fork changes, it invariably devolves into people claiming that
>>>> their circles support/reject a proposal, AND that their circles are more
>>>> broadly representative of the set of Bitcoin users as a whole.
>>>>
>>>> It seems everyone in this forum has at one point or another said "I
>>>> would support activation of ____ if there was consensus on it, but there
>>>> isn't". This statement, in order to be true, requires that there exist a
>>>> set of conditions that would convince you that there is consensus. People
>>>> have tried to dodge this question by saying "it's obvious", but the reality
>>>> is that it fundamentally isn't. My bubble has a different "obvious" answer
>>>> than any of yours.
>>>>
>>>> Secondly, due to the trauma of the block size wars, no one wants to
>>>> utter a statement that could imply that miners have any influence over what
>>>> rulesets get activated or don't. As such "miner signaling" is consistently
>>>> devalued as a signal for market demand. I don't think this is reasonable
>>>> since following the events of '17 miners are aware that they have the
>>>> strong incentive that they understand market demand. Nevertheless, as it
>>>> stands right now the only signal we have to work with is miner signaling,
>>>> which I think is rightly frustrating to a lot of people.
>>>>
>>>> So how can we measure User Support for a proposed rule change?
>>>>
>>>> I've had this idea floating around in the back of my head for a while,
>>>> and I'd like to solicit some feedback here. Currently, all forms of
>>>> activation that are under consideration involve miner signaling in one form
>>>> or another. What if we could make it such that users could more directly
>>>> pressure miners to act on their behalf? After all, if miners are but the
>>>> humble servants of user demands, this should be in alignment with how
>>>> people want Bitcoin to behave.
>>>>
>>>> Currently, the only means users have of influencing miner decisions are
>>>> A. rejection of blocks that don't follow rules and B. paying fees for
>>>> transaction inclusion. I suggest we combine these in such a way that
>>>> transactions themselves can signal for upgrade. I believe (though am not
>>>> certain) that there are "free" bits in the version field of a transaction
>>>> that are presently ignored. If we could devise a mapping between some of
>>>> those free bits, and the signaling bits in the block header, it would be
>>>> possible to have rules as follows:
>>>>
>>>> - A transaction signaling in the affirmative MUST NOT be included in a
>>>> block that does not signal in the affirmative
>>>> - A transaction that is NOT signaling MAY be included in a block
>>>> regardless of that block's signaling vector
>>>> - (Optional) A transaction signaling in the negative MUST NOT be
>>>> included in a block that signals in the affirmative
>>>>
>>>> Under this set of conditions, a user has the means of sybil-resistant
>>>> influence over miner decisions. If a miner cannot collect the fees for a
>>>> transaction without signaling, the user's fee becomes active economic
>>>> pressure for the miner to signal (or not, if we include some variant of the
>>>> negative clause). In this environment, miners could have a better view into
>>>> what users do want, as would the Bitcoin network at large.
>>>>
>>>> Some may take issue with the idea that people can pay for the outcome
>>>> they want and may try to compare a method like this to Proof of Stake, but
>>>> there are only 3 sybil resistant mechanisms I am aware of, and any "real"
>>>> view into what social consensus looks like MUST be sybil resistant:
>>>>
>>>> - Hashpower
>>>> - Proof of personhood (KYC)
>>>> - Capital burn/risk
>>>>
>>>> Letting hashpower decide this is the thing that is currently
>>>> contentious, KYC is dead on arrival both on technical and social grounds,
>>>> which really just leaves some means of getting capital into the process of
>>>> consensus measurement. This mechanism I'm proposing is measurable
>>>> completely en-protocol and doesn't require trust in institutions that fork
>>>> futures would. Additionally it could be an auxiliary feature of the soft
>>>> fork deployment scheme chosen making it something you could neatly package
>>>> all together with the deployment itself.
>>>>
>>>> There are many potential tweaks to the design I propose above:
>>>> 1. Do we include a notion of negative signaling (allowing for the
>>>> possibility of rejection)
>>>> 2. Do we make it such that miner signaling must be congruent with >X%
>>>> of transactions, where congruence is that the signal must match any
>>>> non-neutral signal of transaction.
>>>>
>>>> Some anticipated objections:
>>>>
>>>> 1. signaling isn't voting, no deployment should be made without
>>>> consensus first.
>>>> - yeah well we can't currently measure consensus right now, so that's
>>>> not a super helpful thing to say and is breeding ground for abuse in the
>>>> form of certain people making the unsubstantiated claim that consensus does
>>>> or does not exist for a particular initiative
>>>>
>>>> 2. This is just a proposal for "pay to play", we should not let the
>>>> wealthy make consensus decisions.
>>>> - I agree that wealth should not be able to strong-arm decision making.
>>>> But the status quo seems even worse where we let publicly influential
>>>> people decide consensus in such a way where not only do they not "lose
>>>> ammunition" in the process of campaigning, but actually accrue it, creating
>>>> really bad long-term balances of power.
>>>>
>>>> 3. Enforcing this proposal requires its own soft fork.
>>>> - Yes. It does...and there's a certain cosmic irony to that, but before
>>>> we consider how to make this happen, I'd like to even discuss whether or
>>>> not it's a good idea.
>>>>
>>>> 4. This gives CoinJoin pool operators and L2 protocol implementations
>>>> power over deciding consensus.
>>>> - I see this as an improvement over the status quo
>>>>
>>>> 5. This encourages "spam"
>>>> - If you pay the fees, it's not spam.
>>>>
>>>> The biggest question I'd like to pose to the forum is:
>>>> - Does a scheme like this afford us a better view into consensus than
>>>> we have today?
>>>> - Can it be gamed to give us a *worse* view into consensus? How?
>>>> - Does it measure the right thing? If not, what do you think is the
>>>> right thing to measure? (assuming we could)
>>>> - Should I write a BIP spec'ing this out in detail?
>>>>
>>>> Cheers,
>>>> Keagan
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev at lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>
>>>
>>>
>>> --
>>> - Bryan
>>> https://twitter.com/kanzure
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220427/7302e747/attachment-0001.html>;

📅 Original date posted:2022-04-23 📝 Original message:On ...

2023-06-08T01:07:51+02:00

In reply to nevent1q…w8fw
_________________________

📅 Original date posted:2022-04-23
📝 Original message:On Sat, Apr 23, 2022, 5:05 AM Billy Tetrud via bitcoin-dev <
bitcoin-dev at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220423/5adf57df/attachment.html>;

📅 Original date posted:2022-04-08 📝 Original message:First ...

2023-06-08T01:07:09+02:00

In reply to nevent1q…0wtq
_________________________

📅 Original date posted:2022-04-08
📝 Original message: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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220408/083a525e/attachment.html>;

📅 Original date posted:2021-07-06 📝 Original message:you ...

2023-06-08T00:56:41+02:00

In reply to nevent1q…q8um
_________________________

📅 Original date posted:2021-07-06
📝 Original message: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
<bitcoin-dev at lists.linuxfoundation.org> 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

📅 Original date posted:2021-06-24 📝 Original message:> ...

2023-06-08T00:54:20+02:00

In reply to nevent1q…yvpv
_________________________

📅 Original date posted:2021-06-24
📝 Original message:> 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
<bitcoin-dev at lists.linuxfoundation.org> 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
> > <keagan.mcclelland at gmail.com> 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
> >> <bitcoin-dev at lists.linuxfoundation.org> 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
> >> <bitcoin-dev at lists.linuxfoundation.org> 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 previous
> >> owner of a token for you to have it via transfer or sale, both
> >> choices they never have to make since there are no continuous costs
> >> with producing blocks forcing it. A permission is an infinitely high
> >> barrier to entry if the previous owner, like the premining party,
> >> refuses to give up the token they control.
> >>
> >> You're skipping the part where you depend on a permission of a
> >> central party in control of the authority token before you can
> >> produce blocks on your rasberry Pi.
> >>
> >> Proof of stake is not in any possible way relevant to permissionless
> >> protocols, and thus not possibly relevant to decentralized protocols
> >> where control must be distributed to independent (i.e.
> >> permissionless) parties.
> >>
> >> There's nothing of relevance to discuss and this has been figured
> >> out long long ago.
> >>
> >>
> > https://github.com/libbitcoin/libbitcoin-system/wiki/Proof-of-Stake-Fallacy
> >>
> >>
> > https://medium.com/@factchecker9000/nothing-is-worse-than-proof-of-stake-e70b12b988ca
> >>
> >> On Tue, Jun 15, 2021 at 7:13 AM James MacWhyte via bitcoin-dev
> >> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >>
> >> @Lloyd wrote:
> >>
> >> 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!
> >>
> >> I believe we are talking about a comparison to PoW, correct? If you
> >> want to mine PoW, you need to buy expensive hardware and configure
> >> it to work, and wait a long time to get any return by solo mining.
> >> Or you can join a mining pool, which might use your hashing power
> >> for nefarious purposes. Or you might skip the hardware all together
> >> and fall for some "cloud mining" scheme with a pretty website and a
> >> high rate of advertised return. So as you can see,
> >> Proof-of-SquareSpace exists in PoW as well!
> >>
> >> The PoS equivalent of buying mining hardware is setting up your own
> >> validator and not outsourcing that to anyone else. So both PoW and
> >> PoS have the professional/expert way of participating, and the
> >> fraud-prone, amateur way of participating. The only difference is,
> >> with PoS the professional/expert way is accessible to anyone with a
> >> raspberry Pi and a web connection, which is a much lower barrier to
> >> entry than PoW. _______________________________________________
> >> bitcoin-dev mailing list
> >> bitcoin-dev at lists.linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

📅 Original date posted:2021-06-01 📝 Original message:> ...

2023-06-08T00:54:13+02:00

In reply to nevent1q…vrw7
_________________________

📅 Original date posted:2021-06-01
📝 Original message:> 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
<befreeandopen at protonmail.com> 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
> > befreeandopen at 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 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 solvable, I'm just saying it is importantly missing in the description
> > >
> > > - there seems to be a problem with nothing at stake (nothing at burn maybe?) - How that can be? Again, it seems that every burned coin can be used for free checks at any time after the initial waiting period. These free checks are indeed free and are the core of the nothing at stake problem in PoS. You seem to make those checks for free and you seem to be able to use those burned coins to create arbitrary number of forks build on any parent blocks of your choice, not just the last block of the heaviest chain. I can't see at the moment how is this different from PoS nothing at stake problem. Maybe you can explain?
> > >
> > > - it seems to me that there is a trivial attack against the scheme by a wealthy attacker. Suppose a common size of the burn is 1 BTC per block, suppose you define the heaviest chain rule somehow in relation to total number of burned coins or the cumulative "strength" of the "lowest" hashes, then you can just burn 20 UTXOs, each being 10 BTC in value, so you spent 200 BTC on this attack, but you are in very strong position because after you wait the needed time, you should be able to do pretty nasty reorg. Suppose that the main chain is A-B-C-D-E-F, so what you do at that point is that you just "try for free" all your 20 UTXOs, whether or not they can build on top of block A (which has 5 confs on top, F is the tip of the main chain). Since you have big UTXOs, your chances should be good, of course you can always try many times because you have a "lottery ticket" for every timestampt t. So with this you should be able, with good chance, to find such B' and then you have 19 UTXOs remaining to try to build on B' in the same way. I can't see what prevents this attack in the described scheme.
> > >
> > > - the ability to retroactively try all different kids of timestamp t seems devastating - you again get super easy and somewhat cheap attack (due to nothing at burn problem) that allows you to rewrite even long chains at will.
> > >
> > >
> > > Could you explain what am I missing here, because this actually does not seem better, but rather worse than some PoS schemes?
> > > Sent with ProtonMail Secure Email.
> > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> > > On Friday, May 28, 2021 9:06 PM, Erik Aronesty erik at q32.com wrote:
> > >
> > > > best writeup i know of is here:
> > > > https://en.bitcoin.it/wiki/Proof_of_burn
> > > > no formal proposals or proofs that i know of.
> > > > On Fri, May 28, 2021 at 10:40 AM befreeandopen
> > > > befreeandopen at protonmail.com wrote:
> > > >
> > > > > Erik, I am sorry, I have little knowledge about proof-of-burn, I never found it interesting up until now. Some of your recent claims seem quite strong to me and I'd like to read more.
> > > > > Forgive me if this has been mentioned recently, but is there a full specification of the concept you are referring to? I don't mean just the basic idea description (that much is clear to me), I mean a fully detailed proposal or technical documentation that would give me a precise information about what exactly it is that you are talking about.
> > > > > Sent with ProtonMail Secure Email.
> > > > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> > > > > On Wednesday, May 26, 2021 11:07 PM, Erik Aronesty erik at q32.com wrote:
> > > > >
> > > > > > note: the "nothing at stake" problem you propose is not broken for
> > > > > > proof-of-burn, because the attacker
> > > > > > a) has no idea which past transactions are burns
> > > > > > b) has no way to use his mining power, even 5%, to maliciously improve
> > > > > > his odds of being selected
> > > > > > On Wed, May 26, 2021 at 9:12 AM befreeandopen
> > > > > > befreeandopen at protonmail.com wrote:
> > > > > >
> > > > > > > @befreeandopen I guess I misunderstood your selfish minting attack. Let me make sure I understand it. You're saying it would go as follows?:
> > > > > > >
> > > > > > > 1. The malicious actor comes across an opportunity to mint the next 3 blocks. But they hold off and don't release their blocks just yet.
> > > > > > > 2. They receive a new block minted by someone else.
> > > > > > > 3. The malicious actor then chooses to release their other 2 blocks on on the second from the top block if it gives them more blocks in the future than minting on the top block. And instead lets the top block proceed if it gives them more blocks in the future (also figuring in the 3 blocks they're missing out on minting).
> > > > > > > 4. Profit!
> > > > > > >
> > > > > > > The problem with this attack is that any self respecting PoS system wouldn't have the information available for minters to know how blocks will affect their future prospects of minting. Otherwise this would introduce the problem of stake grinding. This can be done using collaborative randomness (where numbers from many parties are combined to create a random number that no individual party could predict). In fact, that's what the Casper protocol does to decide quorums. In a non quorum case, you can do something like record a hash of a number in the block header, and then have a second step to release that number later. Rewards can be given can be used to ensure minters act honestly here by minting messages that release these numbers and not releasing their secret numbers too early.
> > > > > > > Yes, you misunderstood it. First, let me say that the above thoughts of yours are incorrect, at least for non-quorum case. Since the transition in the blockchain system from S1 to S2 is only by adding new block, and since stakers always need to be able to decide whether or not they can add the next block, it follows that if a staker creates a new block locally, she can decide whether the new state allows her to add another block on top. As you mentioned, this COULD introduce problem of staking, that you are incorrect in that it is a necessity. Usual prevention of the grinding problem in this case is that an "old enough" source of randomness applies for the current block production process. Of course this, as it is typical for PoS, introduces other problems, but let's discard those.
> > > > > > > I will try to explain in detail what you misunderstood before. You start with a chain ending with blocks A-B-C, C being the top, the common feature of PoS system (non-quorum), roughly speaking, is that if N is the total amount of coins that participate in the staking process to create a new block on top of C (let's call that D), then a participant having K*N amount of stake has chance K to be the one who will create the next stake. In other words, the power of stakers is supposed to be linear in the system - you own 10 coins gives you 10x the chance of finding block over someone who has 1 coin.
> > > > > > > What i was claiming is that using the technique I have described, this linearity is violated. Why? Well, it works for honest stakers among the competition of honest stakers - they really do have the chance of K to find the next block. However, the attacker, using nothing at stake, checks her ability to build block D (at some timestamp). If she is successful, she does not propagate D immediately, but instead she also checks whether she can build on top of B and on top of A. Since with every new timestamp, usually, there is a new chance to build the block, it is not uncommon that she finds she is indeed able to build such block C' on top of B. Here it is likely t(C') > t(C) as the attacker has relatively low stake. Note that in order to produce such C', she not only could have tried the current timestamp t(D), but also all previous timestamps up to t(B) (usually that's the consensus rule, but it may depend on a specific consensus). So her chance to produce such C' is greater than her previous chance of producing C (which chance was limited by other stakers in the system and the discovery of block C by one of them). Now suppose that she found such C' and now she continues by trying to prolong this chain by finding D'. And again here, it is quite likely that her chance to find such D' is greater than was her chance of finding D because again there are likely multiple timestamps she could try. This all was possible just because nothing at stake allows you to just try if you can produce a block in certain state of block chain or not. Now if she actually was able to find D', she discards D and only publishes chain A-B-C'-D', which can not be punished despite the fact that she indeed produced two different forks. She can not be punished because this production was local and only the final result of A-B-C'-D' was published, in which case she gained an extra block over the honest strategy which would only give her block D.
> > > > > > > Fun fact tho: there is an attack called the "selfish mining attack" for proof of work, and it reduces the security of PoW by at least 1/3rd.
> > > > > > > How is that relevant to our discussion? This is known research that has nothing to do with PoS except that it is often worse on PoS.
> > > > > > >
> > > > > > > > the problem is not as hard as you think
> > > > > > >
> > > > > > > I don't claim to know just how hard finding the IP address associated with a bitcoin address is. However, the DOS risk can be solved more completely by only allowing the owner of coins themselves to know whether they can mint a block. Eg by determining whether someone can mint a block based on their public key hidden behind hashes (as normal in addresses). Only when someone does in fact mint a block do they reveal their hidden public key in order to prove they are allowed to mint the block.
> > > > > > > This is true, but you are mixing quorum and non-quorum systems. My objection here was towards such system where I specifically said that the list of producers for next epoch is known up front and you confirmed that this is what you meant with "quorum" system. So in such system, I claimed, the known producer is the only target at any given point of time. This of course does not apply to any other type of system where future producers are not known. No need to dispute, again, something that was not claimed.
> > > > > > >
> > > > > > > > I agree that introduction of punishment itself does not imply introducing a problem elsewhere (which I did not claim if you reread my previous message)
> > > > > > >
> > > > > > > I'm glad we agree there. Perhaps I misunderstood what you meant by "you should not omit to mention that by doing so, typically, you have introduced another problem elsewhere."
> > > > > > > Perhaps you should quote the full sentence and not just a part of it:
> > > > > > > "Of course you can always change the rules in a way that a certain specific attack is not doable, but you should not omit to mention that by doing so, typically, you have introduced another problem elsewhere, or you have not solved it completely."
> > > > > > > You can parse this as: (CREATE PROBLEM ELSEWHERE) OR (NOT SOLVE IT COMPLETELY)
> > > > > > > In case of the punishment it was meant to be the not solve it completely part.
> > > > > > > Also "typically" does not imply always.
> > > > > > > But this parsing of English sentences for you seems very off topic here. My point is, in context of Bitcoin, reject such unsupported claims that PoS is a reasonable alternative to PoW, let's stick to that.
> > > > > > >
> > > > > > > > As long as the staker makes sure (which is not that hard) that she does not miss a chance to create a block, her significance in the system will always increase in time. It will increase relative to all normal users who do not stake
> > > > > > >
> > > > > > > Well, if you're in the closed system of the cryptocurrency, sure. But we don't live in that closed system. Minters will earn some ROI from minting just like any other financial activity. Others may find more success spending their time doing things other than figuring out how to mint coins. In that case, they'll be able to earn more coin that they could later decide to use to mint blocks if they decide to.
> > > > > > > This only supports the point I was making. Since the optimal scenario with all existing coins participating is just theoretical, the attacker's position will ever so improve. It seems we are in agreement here, great.
> > > > > > >
> > > > > > > > Just because of the above we must reject PoS as being critically insecure
> > > > > > >
> > > > > > > I think the only thing we can conclude from this is that you have come up with an insecure proof of stake protocol. I don't see how anything you've brought up amounts to substantial evidence that all possible PoS protocols are insecure.
> > > > > > > I have not come up with anything. I'm afraid you've not realized the burden of proof is on your side if you vouch for a design that is not believed and trusted to be secure. It is up to you to show that you know how to solve every problem that people throw at you. So far we have just demonstrated that your claim that nothing at stake is solved was unjustified. You have not described a system that would solve it (and not introduce critical DDOS attack vector as it is in quorum based systems - per the prior definition of such systems).
> > > > > > > Of course the list of problems of PoS systems do not end with just nothing at stake, but it is good enough example that by itself prevents its adoption in decentralized consensus. No need to go to other hard problems without solving nothing at stake.
> > > > > > > On Tue, May 25, 2021 at 11:10 AM befreeandopen befreeandopen at protonmail.com wrote:
> > > > > > >
> > > > > > > > @befreeandopen " An attacker can calculate whether or not she can prolong this chain or not and if so with what timestamp."
> > > > > > > > The scenario you describe would only be likely to happen at all if the malicious actor has a very large fraction of the stake - probably quite close to 50%. At that point, you're talking about a 51% attack, not the nothing at stake problem. The nothing at stake problem is the problem where anyone will mint on any chain. Its clear that if there's a substantial punishment for minting on chains other than the one that eventually wins, every minter without a significant fraction of the stake will be honest and not attempt to mint on old blocks or support someone else's attempt to mint on old blocks (until and if it becomes the heaviest chain). Because the attacker would need probably >45% of the active stake (take a look at the reasoning here for a deeper analysis of that statement), I don't agree that punishment is not a sufficient mitigation of the nothing at stake problem. To exploit the nothing at stake problem, you basically need to 51% attack, at which point you've exceeded the operating conditions of the system, so of course its gonna have problems, just like a 51% attack would cause with PoW.
> > > > > > > > This is not at all the case. The attacker benefits using the described technique at any size of the stake and significantly so with just 5% of the stake. By significantly, I do not mean that the attacker is able to completely take control the network (in short term), but rather that the attacker has significant advantage in the number of blocks she creates compared to what she "should be able to create". This means the attacker's stake increases significantly faster than of the honest nodes, which in long term is very serious in PoS system. If you believe close to 50% is needed for that, you need to redo your math. So no, you are wrong stating that "to exploit nothing at stake problem you basically need to 51% attack". It is rather the opposite - eventually, nothing at stake attack leads to ability to perform 51% attack.
> > > > > > > >
> > > > > > > > > I am not sure if this is what you call quorum-based PoS
> > > > > > > >
> > > > > > > > Yes, pre-selected minters is exactly what I mean by that.
> > > > > > > >
> > > > > > > > > it allows the attacker to know who to attack at which point with powerful DDOS in order to hurt liveness of such system
> > > > > > > >
> > > > > > > > Just like in bitcoin, associating keys with IP addresses isn't generally an easy thing to do on the fly like that. If you know someone's IP address, you can target them. But if you only know their address or public key, the reverse isn't as easy. With a quorum-based PoS system, you can see their public key and address, but finding out their IP to DOS would be a huge challenge I think.
> > > > > > > > I do not dispute that the problem is not trivial, but the problem is not as hard as you think. The network graph analysis is a known technique and it is not trivial, but not very hard either. Introducing a large number of nodes to the system to achieve very good success rate of analysis of area of origin of blocks is doable and has been done in past. So again, I very much disagree with your conclusion that this is somehow secure. It is absolutely insecure.
> > > > > > > > Note, tho, that quorum-based PoS generally also have punishments as part of the protocol. The introduction of punishments do indeed handily solve the nothing at stake problem. And you didn't mention a single problem that the punishments introduce that weren't already there before punishments. There are tradeoffs with introducing punishments (eg in some cases you might punish honest actors), but they are minor in comparison to solving the nothing at stake problem.
> > > > > > > > While I agree that introduction of punishment itself does not imply introducing a problem elsewhere (which I did not claim if you reread my previous message), it does introduce additional complexity which may introduce problem, but more importantly, while it slightly improves resistance against the nothing at stake attack, it solves absolutely nothing. Your claim is based on wrong claim of needed close to 50% stake, but that could not be farther from the truth. It is not true even in optimal conditions when all participants of the network stake or delegate their stake. These optimal conditions rarely, if ever, occur. And that's another thing that we have not mention in our debate, so please allow me to introduce another problem to PoS.
> > > > > > > > Consider what is needed for such optimal conditions to occur - all coins are always part of the stake, which means that they need to somehow automatically part of the staking process even when they are moved. But in many PoS systems you usually require some age (in terms of confirmations) of the coin before you allow it to be used for participation in staking process and that is for a good reason - to prevent various grinding attacks. In some systems the coin must be specifically registered before it can be staked, in others, simply waiting for enough confirmations enables you to stake with the coin. I am not sure if there is a system which does not have this cooling period for a coin that has been moved. Maybe it is possible though, but AFAIK it is not common and not battle tested feature.
> > > > > > > > Then if we admit that achieving the optimal condition is rather theoretical. Then if we do not have the optimal condition, it means that a staker with K% of the total available supply increases it's percentage over time to some amounts >K%. As long as the staker makes sure (which is not that hard) that she does not miss a chance to create a block, her significance in the system will always increase in time. It will increase relative to all normal users who do not stake (if there are any) and relative to all other stakers who make mistakes or who are not wealthy enough to afford not selling any position ever. But powerful attacker is exactly in such position and thus she will gain significance in such a system. The technique I have described, and that you mistakenly think is viable only with huge amounts of stake, only puts the attacker to even greater advantage. But even without the described attack (which exploits nothing at stake), the PoS system converges to a system more and more controlled by powerful entity, which we can assume is the attacker.
> > > > > > > > So I don't think it is at all misleading to claim that "nothing at stake" is a solved problem. I do in fact mean that the solutions to that problem don't introduce any other problems with anywhere near the same level of significance.
> > > > > > > > It still stands as truly misleading claim. I disagree that introducing DDOS opportunity with medium level of difficulty for the attacker to implement it, in case of "quorum-based PoS" is not a problem anywhere near the same level of significance. Such an attack vector allows you to turn off the network if you spend some time and money. That is hardly acceptable.
> > > > > > > > Just because of the above we must reject PoS as being critically insecure until someone invents and demonstrates an actual way of solving these issues.
> > > > > > > > On Tue, May 25, 2021 at 3:00 AM Erik Aronesty erik at q32.com wrote:
> > > > > > > >
> > > > > > > > > > > you burn them to be used at a future particular block height
> > > > > > > > >
> > > > > > > > > > This sounds exploitable. It seems like an attacker could simply focus all their burns on a particular set of 6 blocks to double spend, minimizing their cost of attack.
> > > > > > > > >
> > > > > > > > > could be right. the original idea was to have burns decay over time,
> > > > > > > > > like ASIC's.
> > > > > > > > > anyway the point was not that "i had a magic formula"
> > > > > > > > > the point was that proof of burn is almost always better than proof of
> > > > > > > > > stake - simply because the "proof" is on-chain, not sitting on a node
> > > > > > > > > somewhere waiting to be stolen.
> > > > > > > > > On Mon, May 24, 2021 at 9:53 PM Billy Tetrud billy.tetrud at gmail.com wrote:
> > > > > > > > >
> > > > > > > > > > Is this the kind of proof of burn you're talking about?
> > > > > > > > > >
> > > > > > > > > > > if i have a choice between two chains, one longer and one shorter, i can only choose one... deterministically
> > > > > > > > > >
> > > > > > > > > > What prevents you from attempting to mine block 553 on both chains?
> > > > > > > > > >
> > > > > > > > > > > miners have a very strong, long-term, investment in the stability of the chain.
> > > > > > > > > >
> > > > > > > > > > Yes, but the same can be said of any coin, even ones that do have the nothing at stake problem. This isn't sufficient tho because the chain is a common good, and the tragedy of the commons holds for it.
> > > > > > > > > >
> > > > > > > > > > > you burn them to be used at a future particular block height
> > > > > > > > > >
> > > > > > > > > > This sounds exploitable. It seems like an attacker could simply focus all their burns on a particular set of 6 blocks to double spend, minimizing their cost of attack.
> > > > > > > > > >
> > > > > > > > > > > i can imagine scenarios where large stakeholders can collude to punish smaller stakeholders simply to drive them out of business, for example
> > > > > > > > > >
> > > > > > > > > > Are you talking about a 51% attack? This is possible in any decentralized cryptocurrency.
> > > > > > > > > > On Mon, May 24, 2021 at 11:49 AM Erik Aronesty erik at q32.com wrote:
> > > > > > > > > >
> > > > > > > > > > > > > your burn investment is always "at stake", any redaction can result in a loss-of-burn, because burns can be tied, precisely, to block-heights
> > > > > > > > > > > > > I'm fuzzy on how proof of burn works.
> > > > > > > > > > >
> > > > > > > > > > > when you burn coins, you burn them to be used at a future particular
> > > > > > > > > > > block height: so if i'm burning for block 553, i can only use them to
> > > > > > > > > > > mine block 553. if i have a choice between two chains, one longer
> > > > > > > > > > > and one shorter, i can only choose one... deterministically, for that
> > > > > > > > > > > burn: the chain with the height 553. if we fix the "lead time" for
> > > > > > > > > > > burned coins to be weeks or even months in advance, miners have a very
> > > > > > > > > > > strong, long-term, investment in the stability of the chain.
> > > > > > > > > > > therefore there is no "nothing at stake" problem. it's
> > > > > > > > > > > deterministic, so miners have no choice. they can only choose the
> > > > > > > > > > > transactions that go into the block. they cannot choose which chain
> > > > > > > > > > > to mine, and it's time-locked, so rollbacks and instability always
> > > > > > > > > > > hurt miners the most.
> > > > > > > > > > > the "punishment" systems of PoS are "weird at best", certainly
> > > > > > > > > > > unproven. i can imagine scenarios where large stakeholders can
> > > > > > > > > > > collude to punish smaller stakeholders simply to drive them out of
> > > > > > > > > > > business, for example. and then you have to put checks in place to
> > > > > > > > > > > prevent that, and more checks for those prevention system...
> > > > > > > > > > > in PoB, there is no complexity. simpler systems like this are
> > > > > > > > > > > typically more secure.
> > > > > > > > > > > PoB also solves problems caused by "energy dependence", which could
> > > > > > > > > > > lead to state monopolies on mining (like the new Bitcoin Mining
> > > > > > > > > > > Council). these consortiums, if state sanctioned, could become a
> > > > > > > > > > > source of censorship, for example. Since PoB doesn't require you to
> > > > > > > > > > > have a live, well-connected node, it's harder to censor & harder to
> > > > > > > > > > > trace.
> > > > > > > > > > > Eliminating this weakness seems to be in the best interests of
> > > > > > > > > > > existing stakeholders
> > > > > > > > > > > On Mon, May 24, 2021 at 4:44 PM Billy Tetrud billy.tetrud at gmail.com wrote:
> > > > > > > > > > >
> > > > > > > > > > > > > proof of burn clearly solves this, since nothing is held online
> > > > > > > > > > > >
> > > > > > > > > > > > Well.. the coins to be burned need to be online when they're burned. But yes, only a small fraction of the total coins need to be online.
> > > > > > > > > > > >
> > > > > > > > > > > > > your burn investment is always "at stake", any redaction can result in a loss-of-burn, because burns can be tied, precisely, to block-heights
> > > > > > > > > > > >
> > > > > > > > > > > > So you're saying that if say someone tries to mine a block on a shorter chain, that requires them to send a transaction burning their coins, and that transaction could also be spent on the longest chain, which means their coins are burned even if the chain they tried to mine on doesn't win? I'm fuzzy on how proof of burn works.
> > > > > > > > > > > >
> > > > > > > > > > > > > proof of burn can be more secure than proof-of-stake
> > > > > > > > > > > >
> > > > > > > > > > > > FYI, proof of stake can be done without the "nothing at stake" problem. You can simply punish people who mint on shorter chains (by rewarding people who publish proofs of this happening on the main chain). In quorum-based PoS, you can punish people in the quorum that propose or sign multiple blocks for the same height. The "nothing at stake" problem is a solved problem at this point for PoS.
> > > > > > > > > > > > On Mon, May 24, 2021 at 3:47 AM Erik Aronesty erik at q32.com wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > > 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.
> > > > > > > > > > > > >
> > > > > > > > > > > > > proof of burn clearly solves this, since nothing is held online
> > > > > > > > > > > > >
> > > > > > > > > > > > > > how does proof of burn solve the "nothing at stake" problem in your view?
> > > > > > > > > > > > >
> > > > > > > > > > > > > definition of nothing at stake: in the event of a fork, whether the
> > > > > > > > > > > > > fork is accidental or a malicious, the optimal strategy for any miner
> > > > > > > > > > > > > is to mine on every chain, so that the miner gets their reward no
> > > > > > > > > > > > > matter which fork wins. indeed in proof-of-stake, the proofs are
> > > > > > > > > > > > > published on the very chains mines, so the incentive is magnified.
> > > > > > > > > > > > > in proof-of-burn, your burn investment is always "at stake", any
> > > > > > > > > > > > > redaction can result in a loss-of-burn, because burns can be tied,
> > > > > > > > > > > > > precisely, to block-heights
> > > > > > > > > > > > > as a result, miners no longer have an incentive to mine all chains
> > > > > > > > > > > > > in this way proof of burn can be more secure than proof-of-stake, and
> > > > > > > > > > > > > even more secure than proof of work
> > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Sun, May 23, 2021 at 3:52 AM Lloyd Fournier via bitcoin-dev
> > > > > > > > > > > > > bitcoin-dev at lists.linuxfoundation.org wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > Hi Billy,
> > > > > > > > > > > > > > I was going to write a post which started by dismissing many of the weak arguments that are made against PoS made in this thread and elsewhere.
> > > > > > > > > > > > > > Although I don't agree with all your points you have done a decent job here so I'll focus on the second part: why I think Proof-of-Stake is inappropriate for a Bitcoin-like system.
> > > > > > > > > > > > > > Proof of stake is not fit for purpose for a global settlement layer in a pure digital asset (i.e. "digital gold") which is what Bitcoin is trying to be.
> > > > > > > > > > > > > > PoS necessarily gives responsibilities to the holders of coins that they do not want and cannot handle.
> > > > > > > > > > > > > > In Bitcoin, large unsophisticated coin holders can put their coins in cold storage without a second thought given to the health of the underlying ledger.
> > > > > > > > > > > > > > As much as hardcore Bitcoiners try to convince them to run their own node, most don't, and that's perfectly acceptable.
> > > > > > > > > > > > > > At no point do their personal decisions affect the underlying consensus -- it only affects their personal security assurance (not that of the system itself).
> > > > > > > > > > > > > > In PoS systems this clean separation of responsibilities does not exist.
> > > > > > > > > > > > > > I think that the more rigorously studied PoS protocols will work fine within the security claims made in their papers.
> > > > > > > > > > > > > > People who believe that these protocols are destined for catastrophic consensus failure are certainly in for a surprise.
> > > > > > > > > > > > > > But the devil is in the detail.
> > > > > > > > > > > > > > Let's look at what the implications of using the leading proof of stake protocols would have on Bitcoin:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > ### Proof of SquareSpace (Cardano, Polkdadot)
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Cardano is a UTXO based PoS coin based on Ouroboros Praos3 with an inbuilt on-chain delegation system5.
> > > > > > > > > > > > > > In these protocols, coin holders who do not want to run their node with their hot keys in it delegate it to a "Stake Pool".
> > > > > > > > > > > > > > I call the resulting system Proof-of-SquareSpace since most will choose a pool by looking around for one with a nice website and offering the largest share of the block reward.
> > > > > > > > > > > > > > On the surface this might sound no different than someone with an mining rig shopping around for a good mining pool but there are crucial differences:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 1. The person making the decision is forced into it just because they own the currency -- someone with a mining rig has purchased it with the intent to make profit by participating in consensus.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 2. When you join a mining pool your systems are very much still online. You are just partaking in a pool to reduce your profit variance. You still see every block that you help create and you never help create a block without seeing it first.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 3. If by SquareSpace sybil attack you gain a dishonest majority and start censoring transactions how are the users meant to redelegate their stake to honest pools?
> > > > > > > > > > > > > > I guess they can just send a transaction delegating to another pool...oh wait I guess that might be censored too! This seems really really bad.
> > > > > > > > > > > > > > In Bitcoin, miners can just join a different pool at a whim. There is nothing the attacker can do to stop them. A temporary dishonest majority heals relatively well.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > There is another severe disadvantage to this on-chain delegation system: every UTXO must indicate which staking account this UTXO belongs to so the appropriate share of block rewards can be transferred there.
> > > > > > > > > > > > > > Being able to associate every UTXO to an account ruins one of the main privacy advantages of the UTXO model.
> > > > > > > > > > > > > > It also grows the size of the blockchain significantly.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > ### "Pure" proof of stake (Algorand)
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Algorand's4 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.
> > > > > > > > > > > > > > Cheers,
> > > > > > > > > > > > > > LL
> > > > > > > > > > > > > > On Fri, 21 May 2021 at 19:21, Billy Tetrud via bitcoin-dev bitcoin-dev at 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 thinking omits important facts:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > - The capital required to 51% attack a PoS chain can be made substantially greater than on a PoS chain.
> > > > > > > > > > > > > > > - The capital the attacker stands to lose can be substantially greater as well if the attack is successful.
> > > > > > > > > > > > > > > - The effectiveness of paying miners to raise the honest fraction of miners above 50% may be quite bad.
> > > > > > > > > > > > > > > - Allowing a 51% attack is already unacceptable. It should be considered whether what happens in the case of a 51% may not be significantly different. The currency would likely be critically damaged in a 51% attack regardless of consensus mechanism.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Proof-of-stake 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 honest majority sticking to standard time.
> > > > > > > > > > > > > > > On Wed, May 19, 2021 at 5:32 AM Michael Dubrovsky via bitcoin-dev bitcoin-dev at lists.linuxfoundation.org wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Ah sorry, I didn't realize this was, in fact, a different thread! :)
> > > > > > > > > > > > > > > > On Wed, May 19, 2021 at 10:07 AM Michael Dubrovsky mike at powx.org wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Folks, I suggest we keep the discussion to PoW, oPoW, and the BIP itself. PoS, VDFs, and so on are interesting but I guess there are other threads going on these topics already where they would be relevant.
> > > > > > > > > > > > > > > > > Also, it's important to distinguish between oPoW and these other "alternatives" to Hashcash. oPoW is a true Proof of Work that doesn't alter the core game theory or security assumptions of Hashcash and actually contains SHA (can be SHA3, SHA256, etc hash is interchangeable).
> > > > > > > > > > > > > > > > > Cheers,
> > > > > > > > > > > > > > > > > Mike
> > > > > > > > > > > > > > > > > On Tue, May 18, 2021 at 4:55 PM Erik Aronesty via bitcoin-dev bitcoin-dev at lists.linuxfoundation.org wrote:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > 1. i never suggested vdf's to replace pow.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > 2. my suggestion was specifically in the context of a working
> > > > > > > > > > > > > > > > > > proof-of-burn protocol
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > - vdfs used only for timing (not block height)
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > - blind-burned coins of a specific age used to replace proof of work
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > - the required "work" per block would simply be a competition to
> > > > > > > > > > > > > > > > > > acquire rewards, and so miners would have to burn coins, well in
> > > > > > > > > > > > > > > > > > advance, and hope that their burned coins got rewarded in some far
> > > > > > > > > > > > > > > > > > future
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > - the point of burned coins is to mimic, in every meaningful way, the
> > > > > > > > > > > > > > > > > > value gained from proof of work... without some of the security
> > > > > > > > > > > > > > > > > > drawbacks
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > - the miner risks losing all of his burned coins (like all miners risk
> > > > > > > > > > > > > > > > > > losing their work in each block)
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > - new burns can't be used
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > - old burns age out (like ASICs do)
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > - other requirements on burns might be needed to properly mirror the
> > > > > > > > > > > > > > > > > > properties of PoW and the incentives Bitcoin uses to mine honestly.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > 3. i do believe it is possible that a "burned coin + vdf system"
> > > > > > > > > > > > > > > > > > might be more secure in the long run, and that if the entire space
> > > > > > > > > > > > > > > > > > agreed that such an endeavor was worthwhile, a test net could be spun
> > > > > > > > > > > > > > > > > > up, and a hard-fork could be initiated.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > 4. i would never suggest such a thing unless i believed it was
> > > > > > > > > > > > > > > > > > possible that consensus was possible. so no, this is not an "alt
> > > > > > > > > > > > > > > > > > coin"
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > On Tue, May 18, 2021 at 10:02 AM Zac Greenwood zachgrw at gmail.com wrote:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Hi ZmnSCPxj,
> > > > > > > > > > > > > > > > > > > Please note that I am not suggesting VDFs as a means to save energy, but solely as a means to make the time between blocks more constant.
> > > > > > > > > > > > > > > > > > > Zac
> > > > > > > > > > > > > > > > > > > On Tue, 18 May 2021 at 12:42, ZmnSCPxj ZmnSCPxj at protonmail.com wrote:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Good morning Zac,
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > VDFs might enable more constant block times, for instance by having a two-step PoW:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > 1. Use a VDF that takes say 9 minutes to resolve (VDF being subject to difficulty adjustments similar to the as-is). As per the property of VDFs, miners are able show proof of work.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > 2. Use current PoW mechanism with lower difficulty so finding a block takes 1 minute on average, again subject to as-is difficulty adjustments.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > As a result, variation in block times will be greatly reduced.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > As I understand it, another weakness of VDFs is that they are not inherently progress-free (their sequential nature prevents that; they are inherently progress-requiring).
> > > > > > > > > > > > > > > > > > > > Thus, a miner which focuses on improving the amount of energy that it can pump into the VDF circuitry (by overclocking and freezing the circuitry), could potentially get into a winner-takes-all situation, possibly leading to even worse competition and even more energy consumption.
> > > > > > > > > > > > > > > > > > > > After all, if you can start mining 0.1s faster than the competition, that is a 0.1s advantage where only you can mine in the entire world.
> > > > > > > > > > > > > > > > > > > > Regards,
> > > > > > > > > > > > > > > > > > > > ZmnSCPxj
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > bitcoin-dev mailing list
> > > > > > > > > > > > > > > > > > bitcoin-dev at lists.linuxfoundation.org
> > > > > > > > > > > > > > > > > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > --
> > > > > > > > > > > > > > > > > Michael Dubrovsky
> > > > > > > > > > > > > > > > > Founder; PoWx
> > > > > > > > > > > > > > > > > www.PoWx.org
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > --
> > > > > > > > > > > > > > > > Michael Dubrovsky
> > > > > > > > > > > > > > > > Founder; PoWx
> > > > > > > > > > > > > > > > www.PoWx.org
> > > > > > > > > > > > > > > > bitcoin-dev mailing list
> > > > > > > > > > > > > > > > bitcoin-dev at lists.linuxfoundation.org
> > > > > > > > > > > > > > > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > bitcoin-dev mailing list
> > > > > > > > > > > > > > > bitcoin-dev at lists.linuxfoundation.org
> > > > > > > > > > > > > > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > bitcoin-dev mailing list
> > > > > > > > > > > > > > bitcoin-dev at lists.linuxfoundation.org
> > > > > > > > > > > > > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

📅 Original date posted:2021-06-01 📝 Original message:> ...

2023-06-08T00:54:12+02:00

In reply to nevent1q…mxln
_________________________

📅 Original date posted:2021-06-01
📝 Original message:> 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
<befreeandopen at 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 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 solvable, I'm just saying it is importantly missing in the description
>
> - there seems to be a problem with nothing at stake (nothing at burn maybe?) - How that can be? Again, it seems that every burned coin can be used for free checks at any time after the initial waiting period. These free checks are indeed free and are the core of the nothing at stake problem in PoS. You seem to make those checks for free and you seem to be able to use those burned coins to create arbitrary number of forks build on any parent blocks of your choice, not just the last block of the heaviest chain. I can't see at the moment how is this different from PoS nothing at stake problem. Maybe you can explain?
>
> - it seems to me that there is a trivial attack against the scheme by a wealthy attacker. Suppose a common size of the burn is 1 BTC per block, suppose you define the heaviest chain rule somehow in relation to total number of burned coins or the cumulative "strength" of the "lowest" hashes, then you can just burn 20 UTXOs, each being 10 BTC in value, so you spent 200 BTC on this attack, but you are in very strong position because after you wait the needed time, you should be able to do pretty nasty reorg. Suppose that the main chain is A-B-C-D-E-F, so what you do at that point is that you just "try for free" all your 20 UTXOs, whether or not they can build on top of block A (which has 5 confs on top, F is the tip of the main chain). Since you have big UTXOs, your chances should be good, of course you can always try many times because you have a "lottery ticket" for every timestampt t. So with this you should be able, with good chance, to find such B' and then you have 19 UTXOs remaining to try to build on B' in the same way. I can't see what prevents this attack in the described scheme.
>
> - the ability to retroactively try all different kids of timestamp t seems devastating - you again get super easy and somewhat cheap attack (due to nothing at burn problem) that allows you to rewrite even long chains at will.
>
>
> Could you explain what am I missing here, because this actually does not seem better, but rather worse than some PoS schemes?
>
>
>
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Friday, May 28, 2021 9:06 PM, Erik Aronesty <erik at q32.com> wrote:
>
> > best writeup i know of is here:
> >
> > https://en.bitcoin.it/wiki/Proof_of_burn
> >
> > no formal proposals or proofs that i know of.
> >
> > On Fri, May 28, 2021 at 10:40 AM befreeandopen
> > befreeandopen at protonmail.com wrote:
> >
> > > Erik, I am sorry, I have little knowledge about proof-of-burn, I never found it interesting up until now. Some of your recent claims seem quite strong to me and I'd like to read more.
> > > Forgive me if this has been mentioned recently, but is there a full specification of the concept you are referring to? I don't mean just the basic idea description (that much is clear to me), I mean a fully detailed proposal or technical documentation that would give me a precise information about what exactly it is that you are talking about.
> > > Sent with ProtonMail Secure Email.
> > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> > > On Wednesday, May 26, 2021 11:07 PM, Erik Aronesty erik at q32.com wrote:
> > >
> > > > note: the "nothing at stake" problem you propose is not broken for
> > > > proof-of-burn, because the attacker
> > > > a) has no idea which past transactions are burns
> > > > b) has no way to use his mining power, even 5%, to maliciously improve
> > > > his odds of being selected
> > > > On Wed, May 26, 2021 at 9:12 AM befreeandopen
> > > > befreeandopen at protonmail.com wrote:
> > > >
> > > > > @befreeandopen I guess I misunderstood your selfish minting attack. Let me make sure I understand it. You're saying it would go as follows?:
> > > > >
> > > > > 1. The malicious actor comes across an opportunity to mint the next 3 blocks. But they hold off and don't release their blocks just yet.
> > > > > 2. They receive a new block minted by someone else.
> > > > > 3. The malicious actor then chooses to release their other 2 blocks on on the second from the top block if it gives them more blocks in the future than minting on the top block. And instead lets the top block proceed if it gives them more blocks in the future (also figuring in the 3 blocks they're missing out on minting).
> > > > > 4. Profit!
> > > > >
> > > > > The problem with this attack is that any self respecting PoS system wouldn't have the information available for minters to know how blocks will affect their future prospects of minting. Otherwise this would introduce the problem of stake grinding. This can be done using collaborative randomness (where numbers from many parties are combined to create a random number that no individual party could predict). In fact, that's what the Casper protocol does to decide quorums. In a non quorum case, you can do something like record a hash of a number in the block header, and then have a second step to release that number later. Rewards can be given can be used to ensure minters act honestly here by minting messages that release these numbers and not releasing their secret numbers too early.
> > > > > Yes, you misunderstood it. First, let me say that the above thoughts of yours are incorrect, at least for non-quorum case. Since the transition in the blockchain system from S1 to S2 is only by adding new block, and since stakers always need to be able to decide whether or not they can add the next block, it follows that if a staker creates a new block locally, she can decide whether the new state allows her to add another block on top. As you mentioned, this COULD introduce problem of staking, that you are incorrect in that it is a necessity. Usual prevention of the grinding problem in this case is that an "old enough" source of randomness applies for the current block production process. Of course this, as it is typical for PoS, introduces other problems, but let's discard those.
> > > > > I will try to explain in detail what you misunderstood before. You start with a chain ending with blocks A-B-C, C being the top, the common feature of PoS system (non-quorum), roughly speaking, is that if N is the total amount of coins that participate in the staking process to create a new block on top of C (let's call that D), then a participant having K*N amount of stake has chance K to be the one who will create the next stake. In other words, the power of stakers is supposed to be linear in the system - you own 10 coins gives you 10x the chance of finding block over someone who has 1 coin.
> > > > > What i was claiming is that using the technique I have described, this linearity is violated. Why? Well, it works for honest stakers among the competition of honest stakers - they really do have the chance of K to find the next block. However, the attacker, using nothing at stake, checks her ability to build block D (at some timestamp). If she is successful, she does not propagate D immediately, but instead she also checks whether she can build on top of B and on top of A. Since with every new timestamp, usually, there is a new chance to build the block, it is not uncommon that she finds she is indeed able to build such block C' on top of B. Here it is likely t(C') > t(C) as the attacker has relatively low stake. Note that in order to produce such C', she not only could have tried the current timestamp t(D), but also all previous timestamps up to t(B) (usually that's the consensus rule, but it may depend on a specific consensus). So her chance to produce such C' is greater than her previous chance of producing C (which chance was limited by other stakers in the system and the discovery of block C by one of them). Now suppose that she found such C' and now she continues by trying to prolong this chain by finding D'. And again here, it is quite likely that her chance to find such D' is greater than was her chance of finding D because again there are likely multiple timestamps she could try. This all was possible just because nothing at stake allows you to just try if you can produce a block in certain state of block chain or not. Now if she actually was able to find D', she discards D and only publishes chain A-B-C'-D', which can not be punished despite the fact that she indeed produced two different forks. She can not be punished because this production was local and only the final result of A-B-C'-D' was published, in which case she gained an extra block over the honest strategy which would only give her block D.
> > > > > Fun fact tho: there is an attack called the "selfish mining attack" for proof of work, and it reduces the security of PoW by at least 1/3rd.
> > > > > How is that relevant to our discussion? This is known research that has nothing to do with PoS except that it is often worse on PoS.
> > > > >
> > > > > > the problem is not as hard as you think
> > > > >
> > > > > I don't claim to know just how hard finding the IP address associated with a bitcoin address is. However, the DOS risk can be solved more completely by only allowing the owner of coins themselves to know whether they can mint a block. Eg by determining whether someone can mint a block based on their public key hidden behind hashes (as normal in addresses). Only when someone does in fact mint a block do they reveal their hidden public key in order to prove they are allowed to mint the block.
> > > > > This is true, but you are mixing quorum and non-quorum systems. My objection here was towards such system where I specifically said that the list of producers for next epoch is known up front and you confirmed that this is what you meant with "quorum" system. So in such system, I claimed, the known producer is the only target at any given point of time. This of course does not apply to any other type of system where future producers are not known. No need to dispute, again, something that was not claimed.
> > > > >
> > > > > > I agree that introduction of punishment itself does not imply introducing a problem elsewhere (which I did not claim if you reread my previous message)
> > > > >
> > > > > I'm glad we agree there. Perhaps I misunderstood what you meant by "you should not omit to mention that by doing so, typically, you have introduced another problem elsewhere."
> > > > > Perhaps you should quote the full sentence and not just a part of it:
> > > > > "Of course you can always change the rules in a way that a certain specific attack is not doable, but you should not omit to mention that by doing so, typically, you have introduced another problem elsewhere, or you have not solved it completely."
> > > > > You can parse this as: (CREATE PROBLEM ELSEWHERE) OR (NOT SOLVE IT COMPLETELY)
> > > > > In case of the punishment it was meant to be the not solve it completely part.
> > > > > Also "typically" does not imply always.
> > > > > But this parsing of English sentences for you seems very off topic here. My point is, in context of Bitcoin, reject such unsupported claims that PoS is a reasonable alternative to PoW, let's stick to that.
> > > > >
> > > > > > As long as the staker makes sure (which is not that hard) that she does not miss a chance to create a block, her significance in the system will always increase in time. It will increase relative to all normal users who do not stake
> > > > >
> > > > > Well, if you're in the closed system of the cryptocurrency, sure. But we don't live in that closed system. Minters will earn some ROI from minting just like any other financial activity. Others may find more success spending their time doing things other than figuring out how to mint coins. In that case, they'll be able to earn more coin that they could later decide to use to mint blocks if they decide to.
> > > > > This only supports the point I was making. Since the optimal scenario with all existing coins participating is just theoretical, the attacker's position will ever so improve. It seems we are in agreement here, great.
> > > > >
> > > > > > Just because of the above we must reject PoS as being critically insecure
> > > > >
> > > > > I think the only thing we can conclude from this is that you have come up with an insecure proof of stake protocol. I don't see how anything you've brought up amounts to substantial evidence that all possible PoS protocols are insecure.
> > > > > I have not come up with anything. I'm afraid you've not realized the burden of proof is on your side if you vouch for a design that is not believed and trusted to be secure. It is up to you to show that you know how to solve every problem that people throw at you. So far we have just demonstrated that your claim that nothing at stake is solved was unjustified. You have not described a system that would solve it (and not introduce critical DDOS attack vector as it is in quorum based systems - per the prior definition of such systems).
> > > > > Of course the list of problems of PoS systems do not end with just nothing at stake, but it is good enough example that by itself prevents its adoption in decentralized consensus. No need to go to other hard problems without solving nothing at stake.
> > > > > On Tue, May 25, 2021 at 11:10 AM befreeandopen befreeandopen at protonmail.com wrote:
> > > > >
> > > > > > @befreeandopen " An attacker can calculate whether or not she can prolong this chain or not and if so with what timestamp."
> > > > > > The scenario you describe would only be likely to happen at all if the malicious actor has a very large fraction of the stake - probably quite close to 50%. At that point, you're talking about a 51% attack, not the nothing at stake problem. The nothing at stake problem is the problem where anyone will mint on any chain. Its clear that if there's a substantial punishment for minting on chains other than the one that eventually wins, every minter without a significant fraction of the stake will be honest and not attempt to mint on old blocks or support someone else's attempt to mint on old blocks (until and if it becomes the heaviest chain). Because the attacker would need probably >45% of the active stake (take a look at the reasoning here for a deeper analysis of that statement), I don't agree that punishment is not a sufficient mitigation of the nothing at stake problem. To exploit the nothing at stake problem, you basically need to 51% attack, at which point you've exceeded the operating conditions of the system, so of course its gonna have problems, just like a 51% attack would cause with PoW.
> > > > > > This is not at all the case. The attacker benefits using the described technique at any size of the stake and significantly so with just 5% of the stake. By significantly, I do not mean that the attacker is able to completely take control the network (in short term), but rather that the attacker has significant advantage in the number of blocks she creates compared to what she "should be able to create". This means the attacker's stake increases significantly faster than of the honest nodes, which in long term is very serious in PoS system. If you believe close to 50% is needed for that, you need to redo your math. So no, you are wrong stating that "to exploit nothing at stake problem you basically need to 51% attack". It is rather the opposite - eventually, nothing at stake attack leads to ability to perform 51% attack.
> > > > > >
> > > > > > > I am not sure if this is what you call quorum-based PoS
> > > > > >
> > > > > > Yes, pre-selected minters is exactly what I mean by that.
> > > > > >
> > > > > > > it allows the attacker to know who to attack at which point with powerful DDOS in order to hurt liveness of such system
> > > > > >
> > > > > > Just like in bitcoin, associating keys with IP addresses isn't generally an easy thing to do on the fly like that. If you know someone's IP address, you can target them. But if you only know their address or public key, the reverse isn't as easy. With a quorum-based PoS system, you can see their public key and address, but finding out their IP to DOS would be a huge challenge I think.
> > > > > > I do not dispute that the problem is not trivial, but the problem is not as hard as you think. The network graph analysis is a known technique and it is not trivial, but not very hard either. Introducing a large number of nodes to the system to achieve very good success rate of analysis of area of origin of blocks is doable and has been done in past. So again, I very much disagree with your conclusion that this is somehow secure. It is absolutely insecure.
> > > > > > Note, tho, that quorum-based PoS generally also have punishments as part of the protocol. The introduction of punishments do indeed handily solve the nothing at stake problem. And you didn't mention a single problem that the punishments introduce that weren't already there before punishments. There are tradeoffs with introducing punishments (eg in some cases you might punish honest actors), but they are minor in comparison to solving the nothing at stake problem.
> > > > > > While I agree that introduction of punishment itself does not imply introducing a problem elsewhere (which I did not claim if you reread my previous message), it does introduce additional complexity which may introduce problem, but more importantly, while it slightly improves resistance against the nothing at stake attack, it solves absolutely nothing. Your claim is based on wrong claim of needed close to 50% stake, but that could not be farther from the truth. It is not true even in optimal conditions when all participants of the network stake or delegate their stake. These optimal conditions rarely, if ever, occur. And that's another thing that we have not mention in our debate, so please allow me to introduce another problem to PoS.
> > > > > > Consider what is needed for such optimal conditions to occur - all coins are always part of the stake, which means that they need to somehow automatically part of the staking process even when they are moved. But in many PoS systems you usually require some age (in terms of confirmations) of the coin before you allow it to be used for participation in staking process and that is for a good reason - to prevent various grinding attacks. In some systems the coin must be specifically registered before it can be staked, in others, simply waiting for enough confirmations enables you to stake with the coin. I am not sure if there is a system which does not have this cooling period for a coin that has been moved. Maybe it is possible though, but AFAIK it is not common and not battle tested feature.
> > > > > > Then if we admit that achieving the optimal condition is rather theoretical. Then if we do not have the optimal condition, it means that a staker with K% of the total available supply increases it's percentage over time to some amounts >K%. As long as the staker makes sure (which is not that hard) that she does not miss a chance to create a block, her significance in the system will always increase in time. It will increase relative to all normal users who do not stake (if there are any) and relative to all other stakers who make mistakes or who are not wealthy enough to afford not selling any position ever. But powerful attacker is exactly in such position and thus she will gain significance in such a system. The technique I have described, and that you mistakenly think is viable only with huge amounts of stake, only puts the attacker to even greater advantage. But even without the described attack (which exploits nothing at stake), the PoS system converges to a system more and more controlled by powerful entity, which we can assume is the attacker.
> > > > > > So I don't think it is at all misleading to claim that "nothing at stake" is a solved problem. I do in fact mean that the solutions to that problem don't introduce any other problems with anywhere near the same level of significance.
> > > > > > It still stands as truly misleading claim. I disagree that introducing DDOS opportunity with medium level of difficulty for the attacker to implement it, in case of "quorum-based PoS" is not a problem anywhere near the same level of significance. Such an attack vector allows you to turn off the network if you spend some time and money. That is hardly acceptable.
> > > > > > Just because of the above we must reject PoS as being critically insecure until someone invents and demonstrates an actual way of solving these issues.
> > > > > > On Tue, May 25, 2021 at 3:00 AM Erik Aronesty erik at q32.com wrote:
> > > > > >
> > > > > > > > > you burn them to be used at a future particular block height
> > > > > > >
> > > > > > > > This sounds exploitable. It seems like an attacker could simply focus all their burns on a particular set of 6 blocks to double spend, minimizing their cost of attack.
> > > > > > >
> > > > > > > could be right. the original idea was to have burns decay over time,
> > > > > > > like ASIC's.
> > > > > > > anyway the point was not that "i had a magic formula"
> > > > > > > the point was that proof of burn is almost always better than proof of
> > > > > > > stake - simply because the "proof" is on-chain, not sitting on a node
> > > > > > > somewhere waiting to be stolen.
> > > > > > > On Mon, May 24, 2021 at 9:53 PM Billy Tetrud billy.tetrud at gmail.com wrote:
> > > > > > >
> > > > > > > > Is this the kind of proof of burn you're talking about?
> > > > > > > >
> > > > > > > > > if i have a choice between two chains, one longer and one shorter, i can only choose one... deterministically
> > > > > > > >
> > > > > > > > What prevents you from attempting to mine block 553 on both chains?
> > > > > > > >
> > > > > > > > > miners have a very strong, long-term, investment in the stability of the chain.
> > > > > > > >
> > > > > > > > Yes, but the same can be said of any coin, even ones that do have the nothing at stake problem. This isn't sufficient tho because the chain is a common good, and the tragedy of the commons holds for it.
> > > > > > > >
> > > > > > > > > you burn them to be used at a future particular block height
> > > > > > > >
> > > > > > > > This sounds exploitable. It seems like an attacker could simply focus all their burns on a particular set of 6 blocks to double spend, minimizing their cost of attack.
> > > > > > > >
> > > > > > > > > i can imagine scenarios where large stakeholders can collude to punish smaller stakeholders simply to drive them out of business, for example
> > > > > > > >
> > > > > > > > Are you talking about a 51% attack? This is possible in any decentralized cryptocurrency.
> > > > > > > > On Mon, May 24, 2021 at 11:49 AM Erik Aronesty erik at q32.com wrote:
> > > > > > > >
> > > > > > > > > > > your burn investment is always "at stake", any redaction can result in a loss-of-burn, because burns can be tied, precisely, to block-heights
> > > > > > > > > > > I'm fuzzy on how proof of burn works.
> > > > > > > > >
> > > > > > > > > when you burn coins, you burn them to be used at a future particular
> > > > > > > > > block height: so if i'm burning for block 553, i can only use them to
> > > > > > > > > mine block 553. if i have a choice between two chains, one longer
> > > > > > > > > and one shorter, i can only choose one... deterministically, for that
> > > > > > > > > burn: the chain with the height 553. if we fix the "lead time" for
> > > > > > > > > burned coins to be weeks or even months in advance, miners have a very
> > > > > > > > > strong, long-term, investment in the stability of the chain.
> > > > > > > > > therefore there is no "nothing at stake" problem. it's
> > > > > > > > > deterministic, so miners have no choice. they can only choose the
> > > > > > > > > transactions that go into the block. they cannot choose which chain
> > > > > > > > > to mine, and it's time-locked, so rollbacks and instability always
> > > > > > > > > hurt miners the most.
> > > > > > > > > the "punishment" systems of PoS are "weird at best", certainly
> > > > > > > > > unproven. i can imagine scenarios where large stakeholders can
> > > > > > > > > collude to punish smaller stakeholders simply to drive them out of
> > > > > > > > > business, for example. and then you have to put checks in place to
> > > > > > > > > prevent that, and more checks for those prevention system...
> > > > > > > > > in PoB, there is no complexity. simpler systems like this are
> > > > > > > > > typically more secure.
> > > > > > > > > PoB also solves problems caused by "energy dependence", which could
> > > > > > > > > lead to state monopolies on mining (like the new Bitcoin Mining
> > > > > > > > > Council). these consortiums, if state sanctioned, could become a
> > > > > > > > > source of censorship, for example. Since PoB doesn't require you to
> > > > > > > > > have a live, well-connected node, it's harder to censor & harder to
> > > > > > > > > trace.
> > > > > > > > > Eliminating this weakness seems to be in the best interests of
> > > > > > > > > existing stakeholders
> > > > > > > > > On Mon, May 24, 2021 at 4:44 PM Billy Tetrud billy.tetrud at gmail.com wrote:
> > > > > > > > >
> > > > > > > > > > > proof of burn clearly solves this, since nothing is held online
> > > > > > > > > >
> > > > > > > > > > Well.. the coins to be burned need to be online when they're burned. But yes, only a small fraction of the total coins need to be online.
> > > > > > > > > >
> > > > > > > > > > > your burn investment is always "at stake", any redaction can result in a loss-of-burn, because burns can be tied, precisely, to block-heights
> > > > > > > > > >
> > > > > > > > > > So you're saying that if say someone tries to mine a block on a shorter chain, that requires them to send a transaction burning their coins, and that transaction could also be spent on the longest chain, which means their coins are burned even if the chain they tried to mine on doesn't win? I'm fuzzy on how proof of burn works.
> > > > > > > > > >
> > > > > > > > > > > proof of burn can be more secure than proof-of-stake
> > > > > > > > > >
> > > > > > > > > > FYI, proof of stake can be done without the "nothing at stake" problem. You can simply punish people who mint on shorter chains (by rewarding people who publish proofs of this happening on the main chain). In quorum-based PoS, you can punish people in the quorum that propose or sign multiple blocks for the same height. The "nothing at stake" problem is a solved problem at this point for PoS.
> > > > > > > > > > On Mon, May 24, 2021 at 3:47 AM Erik Aronesty erik at q32.com wrote:
> > > > > > > > > >
> > > > > > > > > > > > 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.
> > > > > > > > > > >
> > > > > > > > > > > proof of burn clearly solves this, since nothing is held online
> > > > > > > > > > >
> > > > > > > > > > > > how does proof of burn solve the "nothing at stake" problem in your view?
> > > > > > > > > > >
> > > > > > > > > > > definition of nothing at stake: in the event of a fork, whether the
> > > > > > > > > > > fork is accidental or a malicious, the optimal strategy for any miner
> > > > > > > > > > > is to mine on every chain, so that the miner gets their reward no
> > > > > > > > > > > matter which fork wins. indeed in proof-of-stake, the proofs are
> > > > > > > > > > > published on the very chains mines, so the incentive is magnified.
> > > > > > > > > > > in proof-of-burn, your burn investment is always "at stake", any
> > > > > > > > > > > redaction can result in a loss-of-burn, because burns can be tied,
> > > > > > > > > > > precisely, to block-heights
> > > > > > > > > > > as a result, miners no longer have an incentive to mine all chains
> > > > > > > > > > > in this way proof of burn can be more secure than proof-of-stake, and
> > > > > > > > > > > even more secure than proof of work
> > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On Sun, May 23, 2021 at 3:52 AM Lloyd Fournier via bitcoin-dev
> > > > > > > > > > > bitcoin-dev at lists.linuxfoundation.org wrote:
> > > > > > > > > > >
> > > > > > > > > > > > Hi Billy,
> > > > > > > > > > > > I was going to write a post which started by dismissing many of the weak arguments that are made against PoS made in this thread and elsewhere.
> > > > > > > > > > > > Although I don't agree with all your points you have done a decent job here so I'll focus on the second part: why I think Proof-of-Stake is inappropriate for a Bitcoin-like system.
> > > > > > > > > > > > Proof of stake is not fit for purpose for a global settlement layer in a pure digital asset (i.e. "digital gold") which is what Bitcoin is trying to be.
> > > > > > > > > > > > PoS necessarily gives responsibilities to the holders of coins that they do not want and cannot handle.
> > > > > > > > > > > > In Bitcoin, large unsophisticated coin holders can put their coins in cold storage without a second thought given to the health of the underlying ledger.
> > > > > > > > > > > > As much as hardcore Bitcoiners try to convince them to run their own node, most don't, and that's perfectly acceptable.
> > > > > > > > > > > > At no point do their personal decisions affect the underlying consensus -- it only affects their personal security assurance (not that of the system itself).
> > > > > > > > > > > > In PoS systems this clean separation of responsibilities does not exist.
> > > > > > > > > > > > I think that the more rigorously studied PoS protocols will work fine within the security claims made in their papers.
> > > > > > > > > > > > People who believe that these protocols are destined for catastrophic consensus failure are certainly in for a surprise.
> > > > > > > > > > > > But the devil is in the detail.
> > > > > > > > > > > > Let's look at what the implications of using the leading proof of stake protocols would have on Bitcoin:
> > > > > > > > > > > >
> > > > > > > > > > > > ### Proof of SquareSpace (Cardano, Polkdadot)
> > > > > > > > > > > >
> > > > > > > > > > > > Cardano is a UTXO based PoS coin based on Ouroboros Praos3 with an inbuilt on-chain delegation system5.
> > > > > > > > > > > > In these protocols, coin holders who do not want to run their node with their hot keys in it delegate it to a "Stake Pool".
> > > > > > > > > > > > I call the resulting system Proof-of-SquareSpace since most will choose a pool by looking around for one with a nice website and offering the largest share of the block reward.
> > > > > > > > > > > > On the surface this might sound no different than someone with an mining rig shopping around for a good mining pool but there are crucial differences:
> > > > > > > > > > > >
> > > > > > > > > > > > 1. The person making the decision is forced into it just because they own the currency -- someone with a mining rig has purchased it with the intent to make profit by participating in consensus.
> > > > > > > > > > > >
> > > > > > > > > > > > 2. When you join a mining pool your systems are very much still online. You are just partaking in a pool to reduce your profit variance. You still see every block that you help create and you never help create a block without seeing it first.
> > > > > > > > > > > >
> > > > > > > > > > > > 3. If by SquareSpace sybil attack you gain a dishonest majority and start censoring transactions how are the users meant to redelegate their stake to honest pools?
> > > > > > > > > > > > I guess they can just send a transaction delegating to another pool...oh wait I guess that might be censored too! This seems really really bad.
> > > > > > > > > > > > In Bitcoin, miners can just join a different pool at a whim. There is nothing the attacker can do to stop them. A temporary dishonest majority heals relatively well.
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > There is another severe disadvantage to this on-chain delegation system: every UTXO must indicate which staking account this UTXO belongs to so the appropriate share of block rewards can be transferred there.
> > > > > > > > > > > > Being able to associate every UTXO to an account ruins one of the main privacy advantages of the UTXO model.
> > > > > > > > > > > > It also grows the size of the blockchain significantly.
> > > > > > > > > > > >
> > > > > > > > > > > > ### "Pure" proof of stake (Algorand)
> > > > > > > > > > > >
> > > > > > > > > > > > Algorand's4 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.
> > > > > > > > > > > > Cheers,
> > > > > > > > > > > > LL
> > > > > > > > > > > > On Fri, 21 May 2021 at 19:21, Billy Tetrud via bitcoin-dev bitcoin-dev at 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 thinking omits important facts:
> > > > > > > > > > > > >
> > > > > > > > > > > > > - The capital required to 51% attack a PoS chain can be made substantially greater than on a PoS chain.
> > > > > > > > > > > > > - The capital the attacker stands to lose can be substantially greater as well if the attack is successful.
> > > > > > > > > > > > > - The effectiveness of paying miners to raise the honest fraction of miners above 50% may be quite bad.
> > > > > > > > > > > > > - Allowing a 51% attack is already unacceptable. It should be considered whether what happens in the case of a 51% may not be significantly different. The currency would likely be critically damaged in a 51% attack regardless of consensus mechanism.
> > > > > > > > > > > > >
> > > > > > > > > > > > > > Proof-of-stake 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 honest majority sticking to standard time.
> > > > > > > > > > > > > On Wed, May 19, 2021 at 5:32 AM Michael Dubrovsky via bitcoin-dev bitcoin-dev at lists.linuxfoundation.org wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > Ah sorry, I didn't realize this was, in fact, a different thread! :)
> > > > > > > > > > > > > > On Wed, May 19, 2021 at 10:07 AM Michael Dubrovsky mike at powx.org wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Folks, I suggest we keep the discussion to PoW, oPoW, and the BIP itself. PoS, VDFs, and so on are interesting but I guess there are other threads going on these topics already where they would be relevant.
> > > > > > > > > > > > > > > Also, it's important to distinguish between oPoW and these other "alternatives" to Hashcash. oPoW is a true Proof of Work that doesn't alter the core game theory or security assumptions of Hashcash and actually contains SHA (can be SHA3, SHA256, etc hash is interchangeable).
> > > > > > > > > > > > > > > Cheers,
> > > > > > > > > > > > > > > Mike
> > > > > > > > > > > > > > > On Tue, May 18, 2021 at 4:55 PM Erik Aronesty via bitcoin-dev bitcoin-dev at lists.linuxfoundation.org wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 1. i never suggested vdf's to replace pow.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 2. my suggestion was specifically in the context of a working
> > > > > > > > > > > > > > > > proof-of-burn protocol
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > - vdfs used only for timing (not block height)
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > - blind-burned coins of a specific age used to replace proof of work
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > - the required "work" per block would simply be a competition to
> > > > > > > > > > > > > > > > acquire rewards, and so miners would have to burn coins, well in
> > > > > > > > > > > > > > > > advance, and hope that their burned coins got rewarded in some far
> > > > > > > > > > > > > > > > future
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > - the point of burned coins is to mimic, in every meaningful way, the
> > > > > > > > > > > > > > > > value gained from proof of work... without some of the security
> > > > > > > > > > > > > > > > drawbacks
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > - the miner risks losing all of his burned coins (like all miners risk
> > > > > > > > > > > > > > > > losing their work in each block)
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > - new burns can't be used
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > - old burns age out (like ASICs do)
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > - other requirements on burns might be needed to properly mirror the
> > > > > > > > > > > > > > > > properties of PoW and the incentives Bitcoin uses to mine honestly.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 3. i do believe it is possible that a "burned coin + vdf system"
> > > > > > > > > > > > > > > > might be more secure in the long run, and that if the entire space
> > > > > > > > > > > > > > > > agreed that such an endeavor was worthwhile, a test net could be spun
> > > > > > > > > > > > > > > > up, and a hard-fork could be initiated.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 4. i would never suggest such a thing unless i believed it was
> > > > > > > > > > > > > > > > possible that consensus was possible. so no, this is not an "alt
> > > > > > > > > > > > > > > > coin"
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Tue, May 18, 2021 at 10:02 AM Zac Greenwood zachgrw at gmail.com wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Hi ZmnSCPxj,
> > > > > > > > > > > > > > > > > Please note that I am not suggesting VDFs as a means to save energy, but solely as a means to make the time between blocks more constant.
> > > > > > > > > > > > > > > > > Zac
> > > > > > > > > > > > > > > > > On Tue, 18 May 2021 at 12:42, ZmnSCPxj ZmnSCPxj at protonmail.com wrote:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Good morning Zac,
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > VDFs might enable more constant block times, for instance by having a two-step PoW:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > 1. Use a VDF that takes say 9 minutes to resolve (VDF being subject to difficulty adjustments similar to the as-is). As per the property of VDFs, miners are able show proof of work.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > 2. Use current PoW mechanism with lower difficulty so finding a block takes 1 minute on average, again subject to as-is difficulty adjustments.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > As a result, variation in block times will be greatly reduced.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > As I understand it, another weakness of VDFs is that they are not inherently progress-free (their sequential nature prevents that; they are inherently progress-requiring).
> > > > > > > > > > > > > > > > > > Thus, a miner which focuses on improving the amount of energy that it can pump into the VDF circuitry (by overclocking and freezing the circuitry), could potentially get into a winner-takes-all situation, possibly leading to even worse competition and even more energy consumption.
> > > > > > > > > > > > > > > > > > After all, if you can start mining 0.1s faster than the competition, that is a 0.1s advantage where only you can mine in the entire world.
> > > > > > > > > > > > > > > > > > Regards,
> > > > > > > > > > > > > > > > > > ZmnSCPxj
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > bitcoin-dev mailing list
> > > > > > > > > > > > > > > > bitcoin-dev at lists.linuxfoundation.org
> > > > > > > > > > > > > > > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > --
> > > > > > > > > > > > > > > Michael Dubrovsky
> > > > > > > > > > > > > > > Founder; PoWx
> > > > > > > > > > > > > > > www.PoWx.org
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > --
> > > > > > > > > > > > > > Michael Dubrovsky
> > > > > > > > > > > > > > Founder; PoWx
> > > > > > > > > > > > > > www.PoWx.org
> > > > > > > > > > > > > > bitcoin-dev mailing list
> > > > > > > > > > > > > > bitcoin-dev at lists.linuxfoundation.org
> > > > > > > > > > > > > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > > > > > > > > > > > >
> > > > > > > > > > > > > bitcoin-dev mailing list
> > > > > > > > > > > > > bitcoin-dev at lists.linuxfoundation.org
> > > > > > > > > > > > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > > > > > > > > > > >
> > > > > > > > > > > > bitcoin-dev mailing list
> > > > > > > > > > > > bitcoin-dev at lists.linuxfoundation.org
> > > > > > > > > > > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

📅 Original date posted:2021-05-25 📝 Original message:> ...

2023-06-08T00:53:01+02:00

In reply to nevent1q…vwem
_________________________

📅 Original date posted:2021-05-25
📝 Original message:> > you burn them to be used at a future particular block height

> This sounds exploitable. It seems like an attacker could simply focus all their burns on a particular set of 6 blocks to double spend, minimizing their cost of attack.

could be right. the original idea was to have burns decay over time,
like ASIC's.

anyway the point was not that "i had a magic formula"

the point was that proof of burn is almost always better than proof of
stake - simply because the "proof" is on-chain, not sitting on a node
somewhere waiting to be stolen.

On Mon, May 24, 2021 at 9:53 PM Billy Tetrud <billy.tetrud at gmail.com> wrote:
>
> Is this the kind of proof of burn you're talking about?
>
> > if i have a choice between two chains, one longer and one shorter, i can only choose one... deterministically
>
> What prevents you from attempting to mine block 553 on both chains?
>
> > miners have a very strong, long-term, investment in the stability of the chain.
>
> Yes, but the same can be said of any coin, even ones that do have the nothing at stake problem. This isn't sufficient tho because the chain is a common good, and the tragedy of the commons holds for it.
>
> > you burn them to be used at a future particular block height
>
> This sounds exploitable. It seems like an attacker could simply focus all their burns on a particular set of 6 blocks to double spend, minimizing their cost of attack.
>
> > i can imagine scenarios where large stakeholders can collude to punish smaller stakeholders simply to drive them out of business, for example
>
> Are you talking about a 51% attack? This is possible in any decentralized cryptocurrency.
>
>
> On Mon, May 24, 2021 at 11:49 AM Erik Aronesty <erik at q32.com> wrote:
>>
>> > > your burn investment is always "at stake", any redaction can result in a loss-of-burn, because burns can be tied, precisely, to block-heights
>> > I'm fuzzy on how proof of burn works.
>>
>> when you burn coins, you burn them to be used at a future particular
>> block height: so if i'm burning for block 553, i can only use them to
>> mine block 553. if i have a choice between two chains, one longer
>> and one shorter, i can only choose one... deterministically, for that
>> burn: the chain with the height 553. if we fix the "lead time" for
>> burned coins to be weeks or even months in advance, miners have a very
>> strong, long-term, investment in the stability of the chain.
>>
>> therefore there is no "nothing at stake" problem. it's
>> deterministic, so miners have no choice. they can *only* choose the
>> transactions that go into the block. they cannot choose which chain
>> to mine, and it's time-locked, so rollbacks and instability always
>> hurt miners the most.
>>
>> the "punishment" systems of PoS are "weird at best", certainly
>> unproven. i can imagine scenarios where large stakeholders can
>> collude to punish smaller stakeholders simply to drive them out of
>> business, for example. and then you have to put checks in place to
>> prevent that, and more checks for those prevention system...
>>
>> in PoB, there is no complexity. simpler systems like this are
>> typically more secure.
>>
>> PoB also solves problems caused by "energy dependence", which could
>> lead to state monopolies on mining (like the new Bitcoin Mining
>> Council). these consortiums, if state sanctioned, could become a
>> source of censorship, for example. Since PoB doesn't require you to
>> have a live, well-connected node, it's harder to censor & harder to
>> trace.
>>
>> Eliminating this weakness seems to be in the best interests of
>> existing stakeholders
>>
>>
>>
>>
>> On Mon, May 24, 2021 at 4:44 PM Billy Tetrud <billy.tetrud at gmail.com> wrote:
>> >
>> > > proof of burn clearly solves this, since nothing is held online
>> >
>> > Well.. the coins to be burned need to be online when they're burned. But yes, only a small fraction of the total coins need to be online.
>> >
>> > > your burn investment is always "at stake", any redaction can result in a loss-of-burn, because burns can be tied, precisely, to block-heights
>> >
>> > So you're saying that if say someone tries to mine a block on a shorter chain, that requires them to send a transaction burning their coins, and that transaction could also be spent on the longest chain, which means their coins are burned even if the chain they tried to mine on doesn't win? I'm fuzzy on how proof of burn works.
>> >
>> > > proof of burn can be more secure than proof-of-stake
>> >
>> > FYI, proof of stake can be done without the "nothing at stake" problem. You can simply punish people who mint on shorter chains (by rewarding people who publish proofs of this happening on the main chain). In quorum-based PoS, you can punish people in the quorum that propose or sign multiple blocks for the same height. The "nothing at stake" problem is a solved problem at this point for PoS.
>> >
>> >
>> >
>> > On Mon, May 24, 2021 at 3:47 AM Erik Aronesty <erik at q32.com> wrote:
>> >>
>> >> > 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.
>> >>
>> >> proof of burn clearly solves this, since nothing is held online
>> >>
>> >> > how does proof of burn solve the "nothing at stake" problem in your view?
>> >>
>> >> definition of nothing at stake: in the event of a fork, whether the
>> >> fork is accidental or a malicious, the optimal strategy for any miner
>> >> is to mine on every chain, so that the miner gets their reward no
>> >> matter which fork wins. indeed in proof-of-stake, the proofs are
>> >> published on the very chains mines, so the incentive is magnified.
>> >>
>> >> in proof-of-burn, your burn investment is always "at stake", any
>> >> redaction can result in a loss-of-burn, because burns can be tied,
>> >> precisely, to block-heights
>> >>
>> >> as a result, miners no longer have an incentive to mine all chains
>> >>
>> >> in this way proof of burn can be more secure than proof-of-stake, and
>> >> even more secure than proof of work
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> >
>> >>
>> >> On Sun, May 23, 2021 at 3:52 AM Lloyd Fournier via bitcoin-dev
>> >> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> >> >
>> >> > Hi Billy,
>> >> >
>> >> > I was going to write a post which started by dismissing many of the weak arguments that are made against PoS made in this thread and elsewhere.
>> >> > Although I don't agree with all your points you have done a decent job here so I'll focus on the second part: why I think Proof-of-Stake is inappropriate for a Bitcoin-like system.
>> >> >
>> >> > Proof of stake is not fit for purpose for a global settlement layer in a pure digital asset (i.e. "digital gold") which is what Bitcoin is trying to be.
>> >> > PoS necessarily gives responsibilities to the holders of coins that they do not want and cannot handle.
>> >> > In Bitcoin, large unsophisticated coin holders can put their coins in cold storage without a second thought given to the health of the underlying ledger.
>> >> > As much as hardcore Bitcoiners try to convince them to run their own node, most don't, and that's perfectly acceptable.
>> >> > At no point do their personal decisions affect the underlying consensus -- it only affects their personal security assurance (not that of the system itself).
>> >> > In PoS systems this clean separation of responsibilities does not exist.
>> >> >
>> >> > I think that the more rigorously studied PoS protocols will work fine within the security claims made in their papers.
>> >> > People who believe that these protocols are destined for catastrophic consensus failure are certainly in for a surprise.
>> >> > But the devil is in the detail.
>> >> > Let's look at what the implications of using the leading proof of stake protocols would have on Bitcoin:
>> >> >
>> >> > ### Proof of SquareSpace (Cardano, Polkdadot)
>> >> >
>> >> > Cardano is a UTXO based PoS coin based on Ouroboros Praos[3] with an inbuilt on-chain delegation system[5].
>> >> > In these protocols, coin holders who do not want to run their node with their hot keys in it delegate it to a "Stake Pool".
>> >> > I call the resulting system Proof-of-SquareSpace since most will choose a pool by looking around for one with a nice website and offering the largest share of the block reward.
>> >> > On the surface this might sound no different than someone with an mining rig shopping around for a good mining pool but there are crucial differences:
>> >> >
>> >> > 1. The person making the decision is forced into it just because they own the currency -- someone with a mining rig has purchased it with the intent to make profit by participating in consensus.
>> >> >
>> >> > 2. When you join a mining pool your systems are very much still online. You are just partaking in a pool to reduce your profit variance. You still see every block that you help create and *you never help create a block without seeing it first*.
>> >> >
>> >> > 3. If by SquareSpace sybil attack you gain a dishonest majority and start censoring transactions how are the users meant to redelegate their stake to honest pools?
>> >> > I guess they can just send a transaction delegating to another pool...oh wait I guess that might be censored too! This seems really really bad.
>> >> > In Bitcoin, miners can just join a different pool at a whim. There is nothing the attacker can do to stop them. A temporary dishonest majority heals relatively well.
>> >> >
>> >> > There is another severe disadvantage to this on-chain delegation system: every UTXO must indicate which staking account this UTXO belongs to so the appropriate share of block rewards can be transferred there.
>> >> > Being able to associate every UTXO to an account ruins one of the main privacy advantages of the UTXO model.
>> >> > It also grows the size of the blockchain significantly.
>> >> >
>> >> > ### "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
>> >> >
>> >> > On Fri, 21 May 2021 at 19:21, Billy Tetrud via bitcoin-dev <bitcoin-dev at 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 thinking omits important facts:
>> >> >> * The capital required to 51% attack a PoS chain can be made substantially greater than on a PoS chain.
>> >> >> * The capital the attacker stands to lose can be substantially greater as well if the attack is successful.
>> >> >> * The effectiveness of paying miners to raise the honest fraction of miners above 50% may be quite bad.
>> >> >> * Allowing a 51% attack is already unacceptable. It should be considered whether what happens in the case of a 51% may not be significantly different. The currency would likely be critically damaged in a 51% attack regardless of consensus mechanism.
>> >> >>
>> >> >> > Proof-of-stake 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 honest majority sticking to standard time.
>> >> >>
>> >> >>
>> >> >> On Wed, May 19, 2021 at 5:32 AM Michael Dubrovsky via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> >> >>>
>> >> >>> Ah sorry, I didn't realize this was, in fact, a different thread! :)
>> >> >>>
>> >> >>> On Wed, May 19, 2021 at 10:07 AM Michael Dubrovsky <mike at powx.org> wrote:
>> >> >>>>
>> >> >>>> Folks, I suggest we keep the discussion to PoW, oPoW, and the BIP itself. PoS, VDFs, and so on are interesting but I guess there are other threads going on these topics already where they would be relevant.
>> >> >>>>
>> >> >>>> Also, it's important to distinguish between oPoW and these other "alternatives" to Hashcash. oPoW is a true Proof of Work that doesn't alter the core game theory or security assumptions of Hashcash and actually contains SHA (can be SHA3, SHA256, etc hash is interchangeable).
>> >> >>>>
>> >> >>>> Cheers,
>> >> >>>> Mike
>> >> >>>>
>> >> >>>> On Tue, May 18, 2021 at 4:55 PM Erik Aronesty via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> >> >>>>>
>> >> >>>>> 1. i never suggested vdf's to replace pow.
>> >> >>>>>
>> >> >>>>> 2. my suggestion was specifically *in the context of* a working
>> >> >>>>> proof-of-burn protocol
>> >> >>>>>
>> >> >>>>> - vdfs used only for timing (not block height)
>> >> >>>>> - blind-burned coins of a specific age used to replace proof of work
>> >> >>>>> - the required "work" per block would simply be a competition to
>> >> >>>>> acquire rewards, and so miners would have to burn coins, well in
>> >> >>>>> advance, and hope that their burned coins got rewarded in some far
>> >> >>>>> future
>> >> >>>>> - the point of burned coins is to mimic, in every meaningful way, the
>> >> >>>>> value gained from proof of work... without some of the security
>> >> >>>>> drawbacks
>> >> >>>>> - the miner risks losing all of his burned coins (like all miners risk
>> >> >>>>> losing their work in each block)
>> >> >>>>> - new burns can't be used
>> >> >>>>> - old burns age out (like ASICs do)
>> >> >>>>> - other requirements on burns might be needed to properly mirror the
>> >> >>>>> properties of PoW and the incentives Bitcoin uses to mine honestly.
>> >> >>>>>
>> >> >>>>> 3. i do believe it is *possible* that a "burned coin + vdf system"
>> >> >>>>> might be more secure in the long run, and that if the entire space
>> >> >>>>> agreed that such an endeavor was worthwhile, a test net could be spun
>> >> >>>>> up, and a hard-fork could be initiated.
>> >> >>>>>
>> >> >>>>> 4. i would never suggest such a thing unless i believed it was
>> >> >>>>> possible that consensus was possible. so no, this is not an "alt
>> >> >>>>> coin"
>> >> >>>>>
>> >> >>>>> On Tue, May 18, 2021 at 10:02 AM Zac Greenwood <zachgrw at gmail.com> wrote:
>> >> >>>>> >
>> >> >>>>> > Hi ZmnSCPxj,
>> >> >>>>> >
>> >> >>>>> > Please note that I am not suggesting VDFs as a means to save energy, but solely as a means to make the time between blocks more constant.
>> >> >>>>> >
>> >> >>>>> > Zac
>> >> >>>>> >
>> >> >>>>> >
>> >> >>>>> > On Tue, 18 May 2021 at 12:42, ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>> >> >>>>> >>
>> >> >>>>> >> Good morning Zac,
>> >> >>>>> >>
>> >> >>>>> >> > VDFs might enable more constant block times, for instance by having a two-step PoW:
>> >> >>>>> >> >
>> >> >>>>> >> > 1. Use a VDF that takes say 9 minutes to resolve (VDF being subject to difficulty adjustments similar to the as-is). As per the property of VDFs, miners are able show proof of work.
>> >> >>>>> >> >
>> >> >>>>> >> > 2. Use current PoW mechanism with lower difficulty so finding a block takes 1 minute on average, again subject to as-is difficulty adjustments.
>> >> >>>>> >> >
>> >> >>>>> >> > As a result, variation in block times will be greatly reduced.
>> >> >>>>> >>
>> >> >>>>> >> As I understand it, another weakness of VDFs is that they are not inherently progress-free (their sequential nature prevents that; they are inherently progress-requiring).
>> >> >>>>> >>
>> >> >>>>> >> Thus, a miner which focuses on improving the amount of energy that it can pump into the VDF circuitry (by overclocking and freezing the circuitry), could potentially get into a winner-takes-all situation, possibly leading to even *worse* competition and even *more* energy consumption.
>> >> >>>>> >> After all, if you can start mining 0.1s faster than the competition, that is a 0.1s advantage where *only you* can mine *in the entire world*.
>> >> >>>>> >>
>> >> >>>>> >> Regards,
>> >> >>>>> >> ZmnSCPxj
>> >> >>>>> _______________________________________________
>> >> >>>>> bitcoin-dev mailing list
>> >> >>>>> bitcoin-dev at lists.linuxfoundation.org
>> >> >>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>> --
>> >> >>>> Michael Dubrovsky
>> >> >>>> Founder; PoWx
>> >> >>>> www.PoWx.org
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>> --
>> >> >>> Michael Dubrovsky
>> >> >>> Founder; PoWx
>> >> >>> www.PoWx.org
>> >> >>> _______________________________________________
>> >> >>> bitcoin-dev mailing list
>> >> >>> bitcoin-dev at lists.linuxfoundation.org
>> >> >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >> >>
>> >> >> _______________________________________________
>> >> >> bitcoin-dev mailing list
>> >> >> bitcoin-dev at lists.linuxfoundation.org
>> >> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >> >
>> >> > _______________________________________________
>> >> > bitcoin-dev mailing list
>> >> > bitcoin-dev at lists.linuxfoundation.org
>> >> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

📅 Original date posted:2021-05-24 📝 Original message:> ...

2023-06-08T00:52:58+02:00

In reply to nevent1q…ulgp
_________________________

📅 Original date posted:2021-05-24
📝 Original message:> > your burn investment is always "at stake", any redaction can result in a loss-of-burn, because burns can be tied, precisely, to block-heights
> I'm fuzzy on how proof of burn works.

when you burn coins, you burn them to be used at a future particular
block height: so if i'm burning for block 553, i can only use them to
mine block 553. if i have a choice between two chains, one longer
and one shorter, i can only choose one... deterministically, for that
burn: the chain with the height 553. if we fix the "lead time" for
burned coins to be weeks or even months in advance, miners have a very
strong, long-term, investment in the stability of the chain.

therefore there is no "nothing at stake" problem. it's
deterministic, so miners have no choice. they can *only* choose the
transactions that go into the block. they cannot choose which chain
to mine, and it's time-locked, so rollbacks and instability always
hurt miners the most.

the "punishment" systems of PoS are "weird at best", certainly
unproven. i can imagine scenarios where large stakeholders can
collude to punish smaller stakeholders simply to drive them out of
business, for example. and then you have to put checks in place to
prevent that, and more checks for those prevention system...

in PoB, there is no complexity. simpler systems like this are
typically more secure.

PoB also solves problems caused by "energy dependence", which could
lead to state monopolies on mining (like the new Bitcoin Mining
Council). these consortiums, if state sanctioned, could become a
source of censorship, for example. Since PoB doesn't require you to
have a live, well-connected node, it's harder to censor & harder to
trace.

Eliminating this weakness seems to be in the best interests of
existing stakeholders

On Mon, May 24, 2021 at 4:44 PM Billy Tetrud <billy.tetrud at gmail.com> wrote:
>
> > proof of burn clearly solves this, since nothing is held online
>
> Well.. the coins to be burned need to be online when they're burned. But yes, only a small fraction of the total coins need to be online.
>
> > your burn investment is always "at stake", any redaction can result in a loss-of-burn, because burns can be tied, precisely, to block-heights
>
> So you're saying that if say someone tries to mine a block on a shorter chain, that requires them to send a transaction burning their coins, and that transaction could also be spent on the longest chain, which means their coins are burned even if the chain they tried to mine on doesn't win? I'm fuzzy on how proof of burn works.
>
> > proof of burn can be more secure than proof-of-stake
>
> FYI, proof of stake can be done without the "nothing at stake" problem. You can simply punish people who mint on shorter chains (by rewarding people who publish proofs of this happening on the main chain). In quorum-based PoS, you can punish people in the quorum that propose or sign multiple blocks for the same height. The "nothing at stake" problem is a solved problem at this point for PoS.
>
>
>
> On Mon, May 24, 2021 at 3:47 AM Erik Aronesty <erik at q32.com> wrote:
>>
>> > 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.
>>
>> proof of burn clearly solves this, since nothing is held online
>>
>> > how does proof of burn solve the "nothing at stake" problem in your view?
>>
>> definition of nothing at stake: in the event of a fork, whether the
>> fork is accidental or a malicious, the optimal strategy for any miner
>> is to mine on every chain, so that the miner gets their reward no
>> matter which fork wins. indeed in proof-of-stake, the proofs are
>> published on the very chains mines, so the incentive is magnified.
>>
>> in proof-of-burn, your burn investment is always "at stake", any
>> redaction can result in a loss-of-burn, because burns can be tied,
>> precisely, to block-heights
>>
>> as a result, miners no longer have an incentive to mine all chains
>>
>> in this way proof of burn can be more secure than proof-of-stake, and
>> even more secure than proof of work
>>
>>
>>
>>
>>
>>
>>
>> >
>>
>> On Sun, May 23, 2021 at 3:52 AM Lloyd Fournier via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> >
>> > Hi Billy,
>> >
>> > I was going to write a post which started by dismissing many of the weak arguments that are made against PoS made in this thread and elsewhere.
>> > Although I don't agree with all your points you have done a decent job here so I'll focus on the second part: why I think Proof-of-Stake is inappropriate for a Bitcoin-like system.
>> >
>> > Proof of stake is not fit for purpose for a global settlement layer in a pure digital asset (i.e. "digital gold") which is what Bitcoin is trying to be.
>> > PoS necessarily gives responsibilities to the holders of coins that they do not want and cannot handle.
>> > In Bitcoin, large unsophisticated coin holders can put their coins in cold storage without a second thought given to the health of the underlying ledger.
>> > As much as hardcore Bitcoiners try to convince them to run their own node, most don't, and that's perfectly acceptable.
>> > At no point do their personal decisions affect the underlying consensus -- it only affects their personal security assurance (not that of the system itself).
>> > In PoS systems this clean separation of responsibilities does not exist.
>> >
>> > I think that the more rigorously studied PoS protocols will work fine within the security claims made in their papers.
>> > People who believe that these protocols are destined for catastrophic consensus failure are certainly in for a surprise.
>> > But the devil is in the detail.
>> > Let's look at what the implications of using the leading proof of stake protocols would have on Bitcoin:
>> >
>> > ### Proof of SquareSpace (Cardano, Polkdadot)
>> >
>> > Cardano is a UTXO based PoS coin based on Ouroboros Praos[3] with an inbuilt on-chain delegation system[5].
>> > In these protocols, coin holders who do not want to run their node with their hot keys in it delegate it to a "Stake Pool".
>> > I call the resulting system Proof-of-SquareSpace since most will choose a pool by looking around for one with a nice website and offering the largest share of the block reward.
>> > On the surface this might sound no different than someone with an mining rig shopping around for a good mining pool but there are crucial differences:
>> >
>> > 1. The person making the decision is forced into it just because they own the currency -- someone with a mining rig has purchased it with the intent to make profit by participating in consensus.
>> >
>> > 2. When you join a mining pool your systems are very much still online. You are just partaking in a pool to reduce your profit variance. You still see every block that you help create and *you never help create a block without seeing it first*.
>> >
>> > 3. If by SquareSpace sybil attack you gain a dishonest majority and start censoring transactions how are the users meant to redelegate their stake to honest pools?
>> > I guess they can just send a transaction delegating to another pool...oh wait I guess that might be censored too! This seems really really bad.
>> > In Bitcoin, miners can just join a different pool at a whim. There is nothing the attacker can do to stop them. A temporary dishonest majority heals relatively well.
>> >
>> > There is another severe disadvantage to this on-chain delegation system: every UTXO must indicate which staking account this UTXO belongs to so the appropriate share of block rewards can be transferred there.
>> > Being able to associate every UTXO to an account ruins one of the main privacy advantages of the UTXO model.
>> > It also grows the size of the blockchain significantly.
>> >
>> > ### "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
>> >
>> > On Fri, 21 May 2021 at 19:21, Billy Tetrud via bitcoin-dev <bitcoin-dev at 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 thinking omits important facts:
>> >> * The capital required to 51% attack a PoS chain can be made substantially greater than on a PoS chain.
>> >> * The capital the attacker stands to lose can be substantially greater as well if the attack is successful.
>> >> * The effectiveness of paying miners to raise the honest fraction of miners above 50% may be quite bad.
>> >> * Allowing a 51% attack is already unacceptable. It should be considered whether what happens in the case of a 51% may not be significantly different. The currency would likely be critically damaged in a 51% attack regardless of consensus mechanism.
>> >>
>> >> > Proof-of-stake 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 honest majority sticking to standard time.
>> >>
>> >>
>> >> On Wed, May 19, 2021 at 5:32 AM Michael Dubrovsky via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> >>>
>> >>> Ah sorry, I didn't realize this was, in fact, a different thread! :)
>> >>>
>> >>> On Wed, May 19, 2021 at 10:07 AM Michael Dubrovsky <mike at powx.org> wrote:
>> >>>>
>> >>>> Folks, I suggest we keep the discussion to PoW, oPoW, and the BIP itself. PoS, VDFs, and so on are interesting but I guess there are other threads going on these topics already where they would be relevant.
>> >>>>
>> >>>> Also, it's important to distinguish between oPoW and these other "alternatives" to Hashcash. oPoW is a true Proof of Work that doesn't alter the core game theory or security assumptions of Hashcash and actually contains SHA (can be SHA3, SHA256, etc hash is interchangeable).
>> >>>>
>> >>>> Cheers,
>> >>>> Mike
>> >>>>
>> >>>> On Tue, May 18, 2021 at 4:55 PM Erik Aronesty via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> >>>>>
>> >>>>> 1. i never suggested vdf's to replace pow.
>> >>>>>
>> >>>>> 2. my suggestion was specifically *in the context of* a working
>> >>>>> proof-of-burn protocol
>> >>>>>
>> >>>>> - vdfs used only for timing (not block height)
>> >>>>> - blind-burned coins of a specific age used to replace proof of work
>> >>>>> - the required "work" per block would simply be a competition to
>> >>>>> acquire rewards, and so miners would have to burn coins, well in
>> >>>>> advance, and hope that their burned coins got rewarded in some far
>> >>>>> future
>> >>>>> - the point of burned coins is to mimic, in every meaningful way, the
>> >>>>> value gained from proof of work... without some of the security
>> >>>>> drawbacks
>> >>>>> - the miner risks losing all of his burned coins (like all miners risk
>> >>>>> losing their work in each block)
>> >>>>> - new burns can't be used
>> >>>>> - old burns age out (like ASICs do)
>> >>>>> - other requirements on burns might be needed to properly mirror the
>> >>>>> properties of PoW and the incentives Bitcoin uses to mine honestly.
>> >>>>>
>> >>>>> 3. i do believe it is *possible* that a "burned coin + vdf system"
>> >>>>> might be more secure in the long run, and that if the entire space
>> >>>>> agreed that such an endeavor was worthwhile, a test net could be spun
>> >>>>> up, and a hard-fork could be initiated.
>> >>>>>
>> >>>>> 4. i would never suggest such a thing unless i believed it was
>> >>>>> possible that consensus was possible. so no, this is not an "alt
>> >>>>> coin"
>> >>>>>
>> >>>>> On Tue, May 18, 2021 at 10:02 AM Zac Greenwood <zachgrw at gmail.com> wrote:
>> >>>>> >
>> >>>>> > Hi ZmnSCPxj,
>> >>>>> >
>> >>>>> > Please note that I am not suggesting VDFs as a means to save energy, but solely as a means to make the time between blocks more constant.
>> >>>>> >
>> >>>>> > Zac
>> >>>>> >
>> >>>>> >
>> >>>>> > On Tue, 18 May 2021 at 12:42, ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>> >>>>> >>
>> >>>>> >> Good morning Zac,
>> >>>>> >>
>> >>>>> >> > VDFs might enable more constant block times, for instance by having a two-step PoW:
>> >>>>> >> >
>> >>>>> >> > 1. Use a VDF that takes say 9 minutes to resolve (VDF being subject to difficulty adjustments similar to the as-is). As per the property of VDFs, miners are able show proof of work.
>> >>>>> >> >
>> >>>>> >> > 2. Use current PoW mechanism with lower difficulty so finding a block takes 1 minute on average, again subject to as-is difficulty adjustments.
>> >>>>> >> >
>> >>>>> >> > As a result, variation in block times will be greatly reduced.
>> >>>>> >>
>> >>>>> >> As I understand it, another weakness of VDFs is that they are not inherently progress-free (their sequential nature prevents that; they are inherently progress-requiring).
>> >>>>> >>
>> >>>>> >> Thus, a miner which focuses on improving the amount of energy that it can pump into the VDF circuitry (by overclocking and freezing the circuitry), could potentially get into a winner-takes-all situation, possibly leading to even *worse* competition and even *more* energy consumption.
>> >>>>> >> After all, if you can start mining 0.1s faster than the competition, that is a 0.1s advantage where *only you* can mine *in the entire world*.
>> >>>>> >>
>> >>>>> >> Regards,
>> >>>>> >> ZmnSCPxj
>> >>>>> _______________________________________________
>> >>>>> bitcoin-dev mailing list
>> >>>>> bitcoin-dev at lists.linuxfoundation.org
>> >>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>> Michael Dubrovsky
>> >>>> Founder; PoWx
>> >>>> www.PoWx.org
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> Michael Dubrovsky
>> >>> Founder; PoWx
>> >>> www.PoWx.org
>> >>> _______________________________________________
>> >>> bitcoin-dev mailing list
>> >>> bitcoin-dev at lists.linuxfoundation.org
>> >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >>
>> >> _______________________________________________
>> >> bitcoin-dev mailing list
>> >> bitcoin-dev at lists.linuxfoundation.org
>> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >
>> > _______________________________________________
>> > bitcoin-dev mailing list
>> > bitcoin-dev at lists.linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

📅 Original date posted:2021-05-24 📝 Original message:> I ...

2023-06-08T00:52:56+02:00

In reply to nevent1q…n0rq
_________________________

📅 Original date posted:2021-05-24
📝 Original message:> 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.

proof of burn clearly solves this, since nothing is held online

> how does proof of burn solve the "nothing at stake" problem in your view?

definition of nothing at stake: in the event of a fork, whether the
fork is accidental or a malicious, the optimal strategy for any miner
is to mine on every chain, so that the miner gets their reward no
matter which fork wins. indeed in proof-of-stake, the proofs are
published on the very chains mines, so the incentive is magnified.

in proof-of-burn, your burn investment is always "at stake", any
redaction can result in a loss-of-burn, because burns can be tied,
precisely, to block-heights

as a result, miners no longer have an incentive to mine all chains

in this way proof of burn can be more secure than proof-of-stake, and
even more secure than proof of work

>

On Sun, May 23, 2021 at 3:52 AM Lloyd Fournier via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Hi Billy,
>
> I was going to write a post which started by dismissing many of the weak arguments that are made against PoS made in this thread and elsewhere.
> Although I don't agree with all your points you have done a decent job here so I'll focus on the second part: why I think Proof-of-Stake is inappropriate for a Bitcoin-like system.
>
> Proof of stake is not fit for purpose for a global settlement layer in a pure digital asset (i.e. "digital gold") which is what Bitcoin is trying to be.
> PoS necessarily gives responsibilities to the holders of coins that they do not want and cannot handle.
> In Bitcoin, large unsophisticated coin holders can put their coins in cold storage without a second thought given to the health of the underlying ledger.
> As much as hardcore Bitcoiners try to convince them to run their own node, most don't, and that's perfectly acceptable.
> At no point do their personal decisions affect the underlying consensus -- it only affects their personal security assurance (not that of the system itself).
> In PoS systems this clean separation of responsibilities does not exist.
>
> I think that the more rigorously studied PoS protocols will work fine within the security claims made in their papers.
> People who believe that these protocols are destined for catastrophic consensus failure are certainly in for a surprise.
> But the devil is in the detail.
> Let's look at what the implications of using the leading proof of stake protocols would have on Bitcoin:
>
> ### Proof of SquareSpace (Cardano, Polkdadot)
>
> Cardano is a UTXO based PoS coin based on Ouroboros Praos[3] with an inbuilt on-chain delegation system[5].
> In these protocols, coin holders who do not want to run their node with their hot keys in it delegate it to a "Stake Pool".
> I call the resulting system Proof-of-SquareSpace since most will choose a pool by looking around for one with a nice website and offering the largest share of the block reward.
> On the surface this might sound no different than someone with an mining rig shopping around for a good mining pool but there are crucial differences:
>
> 1. The person making the decision is forced into it just because they own the currency -- someone with a mining rig has purchased it with the intent to make profit by participating in consensus.
>
> 2. When you join a mining pool your systems are very much still online. You are just partaking in a pool to reduce your profit variance. You still see every block that you help create and *you never help create a block without seeing it first*.
>
> 3. If by SquareSpace sybil attack you gain a dishonest majority and start censoring transactions how are the users meant to redelegate their stake to honest pools?
> I guess they can just send a transaction delegating to another pool...oh wait I guess that might be censored too! This seems really really bad.
> In Bitcoin, miners can just join a different pool at a whim. There is nothing the attacker can do to stop them. A temporary dishonest majority heals relatively well.
>
> There is another severe disadvantage to this on-chain delegation system: every UTXO must indicate which staking account this UTXO belongs to so the appropriate share of block rewards can be transferred there.
> Being able to associate every UTXO to an account ruins one of the main privacy advantages of the UTXO model.
> It also grows the size of the blockchain significantly.
>
> ### "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
>
> On Fri, 21 May 2021 at 19:21, Billy Tetrud via bitcoin-dev <bitcoin-dev at 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 thinking omits important facts:
>> * The capital required to 51% attack a PoS chain can be made substantially greater than on a PoS chain.
>> * The capital the attacker stands to lose can be substantially greater as well if the attack is successful.
>> * The effectiveness of paying miners to raise the honest fraction of miners above 50% may be quite bad.
>> * Allowing a 51% attack is already unacceptable. It should be considered whether what happens in the case of a 51% may not be significantly different. The currency would likely be critically damaged in a 51% attack regardless of consensus mechanism.
>>
>> > Proof-of-stake 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 honest majority sticking to standard time.
>>
>>
>> On Wed, May 19, 2021 at 5:32 AM Michael Dubrovsky via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>> Ah sorry, I didn't realize this was, in fact, a different thread! :)
>>>
>>> On Wed, May 19, 2021 at 10:07 AM Michael Dubrovsky <mike at powx.org> wrote:
>>>>
>>>> Folks, I suggest we keep the discussion to PoW, oPoW, and the BIP itself. PoS, VDFs, and so on are interesting but I guess there are other threads going on these topics already where they would be relevant.
>>>>
>>>> Also, it's important to distinguish between oPoW and these other "alternatives" to Hashcash. oPoW is a true Proof of Work that doesn't alter the core game theory or security assumptions of Hashcash and actually contains SHA (can be SHA3, SHA256, etc hash is interchangeable).
>>>>
>>>> Cheers,
>>>> Mike
>>>>
>>>> On Tue, May 18, 2021 at 4:55 PM Erik Aronesty via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>>>
>>>>> 1. i never suggested vdf's to replace pow.
>>>>>
>>>>> 2. my suggestion was specifically *in the context of* a working
>>>>> proof-of-burn protocol
>>>>>
>>>>> - vdfs used only for timing (not block height)
>>>>> - blind-burned coins of a specific age used to replace proof of work
>>>>> - the required "work" per block would simply be a competition to
>>>>> acquire rewards, and so miners would have to burn coins, well in
>>>>> advance, and hope that their burned coins got rewarded in some far
>>>>> future
>>>>> - the point of burned coins is to mimic, in every meaningful way, the
>>>>> value gained from proof of work... without some of the security
>>>>> drawbacks
>>>>> - the miner risks losing all of his burned coins (like all miners risk
>>>>> losing their work in each block)
>>>>> - new burns can't be used
>>>>> - old burns age out (like ASICs do)
>>>>> - other requirements on burns might be needed to properly mirror the
>>>>> properties of PoW and the incentives Bitcoin uses to mine honestly.
>>>>>
>>>>> 3. i do believe it is *possible* that a "burned coin + vdf system"
>>>>> might be more secure in the long run, and that if the entire space
>>>>> agreed that such an endeavor was worthwhile, a test net could be spun
>>>>> up, and a hard-fork could be initiated.
>>>>>
>>>>> 4. i would never suggest such a thing unless i believed it was
>>>>> possible that consensus was possible. so no, this is not an "alt
>>>>> coin"
>>>>>
>>>>> On Tue, May 18, 2021 at 10:02 AM Zac Greenwood <zachgrw at gmail.com> wrote:
>>>>> >
>>>>> > Hi ZmnSCPxj,
>>>>> >
>>>>> > Please note that I am not suggesting VDFs as a means to save energy, but solely as a means to make the time between blocks more constant.
>>>>> >
>>>>> > Zac
>>>>> >
>>>>> >
>>>>> > On Tue, 18 May 2021 at 12:42, ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>>>>> >>
>>>>> >> Good morning Zac,
>>>>> >>
>>>>> >> > VDFs might enable more constant block times, for instance by having a two-step PoW:
>>>>> >> >
>>>>> >> > 1. Use a VDF that takes say 9 minutes to resolve (VDF being subject to difficulty adjustments similar to the as-is). As per the property of VDFs, miners are able show proof of work.
>>>>> >> >
>>>>> >> > 2. Use current PoW mechanism with lower difficulty so finding a block takes 1 minute on average, again subject to as-is difficulty adjustments.
>>>>> >> >
>>>>> >> > As a result, variation in block times will be greatly reduced.
>>>>> >>
>>>>> >> As I understand it, another weakness of VDFs is that they are not inherently progress-free (their sequential nature prevents that; they are inherently progress-requiring).
>>>>> >>
>>>>> >> Thus, a miner which focuses on improving the amount of energy that it can pump into the VDF circuitry (by overclocking and freezing the circuitry), could potentially get into a winner-takes-all situation, possibly leading to even *worse* competition and even *more* energy consumption.
>>>>> >> After all, if you can start mining 0.1s faster than the competition, that is a 0.1s advantage where *only you* can mine *in the entire world*.
>>>>> >>
>>>>> >> Regards,
>>>>> >> ZmnSCPxj
>>>>> _______________________________________________
>>>>> bitcoin-dev mailing list
>>>>> bitcoin-dev at lists.linuxfoundation.org
>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>
>>>>
>>>>
>>>> --
>>>> Michael Dubrovsky
>>>> Founder; PoWx
>>>> www.PoWx.org
>>>
>>>
>>>
>>> --
>>> Michael Dubrovsky
>>> Founder; PoWx
>>> www.PoWx.org
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

📅 Original date posted:2021-05-21 📝 Original message:proof ...

2023-06-08T00:52:51+02:00

In reply to nevent1q…vwtn
_________________________

📅 Original date posted:2021-05-21
📝 Original message:proof of burn has all the benefits of proof of stake (if there are any)

but it also solves the "nothing at stake" problem

the incentive in POB is that you're making a long-term investment in
mining, and you want a stable protocol, quality network, etc.... to
pay off your investment.

On Thu, May 20, 2021 at 8:04 PM Billy Tetrud <billy.tetrud at gmail.com> 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 thinking omits important facts:
> * The capital required to 51% attack a PoS chain can be made substantially greater than on a PoS chain.
> * The capital the attacker stands to lose can be substantially greater as well if the attack is successful.
> * The effectiveness of paying miners to raise the honest fraction of miners above 50% may be quite bad.
> * Allowing a 51% attack is already unacceptable. It should be considered whether what happens in the case of a 51% may not be significantly different. The currency would likely be critically damaged in a 51% attack regardless of consensus mechanism.
>
> > Proof-of-stake 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 honest majority sticking to standard time.
>
>
> On Wed, May 19, 2021 at 5:32 AM Michael Dubrovsky via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> Ah sorry, I didn't realize this was, in fact, a different thread! :)
>>
>> On Wed, May 19, 2021 at 10:07 AM Michael Dubrovsky <mike at powx.org> wrote:
>>>
>>> Folks, I suggest we keep the discussion to PoW, oPoW, and the BIP itself. PoS, VDFs, and so on are interesting but I guess there are other threads going on these topics already where they would be relevant.
>>>
>>> Also, it's important to distinguish between oPoW and these other "alternatives" to Hashcash. oPoW is a true Proof of Work that doesn't alter the core game theory or security assumptions of Hashcash and actually contains SHA (can be SHA3, SHA256, etc hash is interchangeable).
>>>
>>> Cheers,
>>> Mike
>>>
>>> On Tue, May 18, 2021 at 4:55 PM Erik Aronesty via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>>
>>>> 1. i never suggested vdf's to replace pow.
>>>>
>>>> 2. my suggestion was specifically *in the context of* a working
>>>> proof-of-burn protocol
>>>>
>>>> - vdfs used only for timing (not block height)
>>>> - blind-burned coins of a specific age used to replace proof of work
>>>> - the required "work" per block would simply be a competition to
>>>> acquire rewards, and so miners would have to burn coins, well in
>>>> advance, and hope that their burned coins got rewarded in some far
>>>> future
>>>> - the point of burned coins is to mimic, in every meaningful way, the
>>>> value gained from proof of work... without some of the security
>>>> drawbacks
>>>> - the miner risks losing all of his burned coins (like all miners risk
>>>> losing their work in each block)
>>>> - new burns can't be used
>>>> - old burns age out (like ASICs do)
>>>> - other requirements on burns might be needed to properly mirror the
>>>> properties of PoW and the incentives Bitcoin uses to mine honestly.
>>>>
>>>> 3. i do believe it is *possible* that a "burned coin + vdf system"
>>>> might be more secure in the long run, and that if the entire space
>>>> agreed that such an endeavor was worthwhile, a test net could be spun
>>>> up, and a hard-fork could be initiated.
>>>>
>>>> 4. i would never suggest such a thing unless i believed it was
>>>> possible that consensus was possible. so no, this is not an "alt
>>>> coin"
>>>>
>>>> On Tue, May 18, 2021 at 10:02 AM Zac Greenwood <zachgrw at gmail.com> wrote:
>>>> >
>>>> > Hi ZmnSCPxj,
>>>> >
>>>> > Please note that I am not suggesting VDFs as a means to save energy, but solely as a means to make the time between blocks more constant.
>>>> >
>>>> > Zac
>>>> >
>>>> >
>>>> > On Tue, 18 May 2021 at 12:42, ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>>>> >>
>>>> >> Good morning Zac,
>>>> >>
>>>> >> > VDFs might enable more constant block times, for instance by having a two-step PoW:
>>>> >> >
>>>> >> > 1. Use a VDF that takes say 9 minutes to resolve (VDF being subject to difficulty adjustments similar to the as-is). As per the property of VDFs, miners are able show proof of work.
>>>> >> >
>>>> >> > 2. Use current PoW mechanism with lower difficulty so finding a block takes 1 minute on average, again subject to as-is difficulty adjustments.
>>>> >> >
>>>> >> > As a result, variation in block times will be greatly reduced.
>>>> >>
>>>> >> As I understand it, another weakness of VDFs is that they are not inherently progress-free (their sequential nature prevents that; they are inherently progress-requiring).
>>>> >>
>>>> >> Thus, a miner which focuses on improving the amount of energy that it can pump into the VDF circuitry (by overclocking and freezing the circuitry), could potentially get into a winner-takes-all situation, possibly leading to even *worse* competition and even *more* energy consumption.
>>>> >> After all, if you can start mining 0.1s faster than the competition, that is a 0.1s advantage where *only you* can mine *in the entire world*.
>>>> >>
>>>> >> Regards,
>>>> >> ZmnSCPxj
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev at lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>>
>>>
>>> --
>>> Michael Dubrovsky
>>> Founder; PoWx
>>> www.PoWx.org
>>
>>
>>
>> --
>> Michael Dubrovsky
>> Founder; PoWx
>> www.PoWx.org
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

📅 Original date posted:2021-05-17 📝 Original ...

2023-06-08T00:52:44+02:00

In reply to nevent1q…kvq6
_________________________

📅 Original date posted:2021-05-17
📝 Original message:Verifiable Delay Functions involve active participation of a single
verifier. Without this a VDF decays into a proof-of-work (multiple
verifiers === parallelism).

The verifier, in this case is "the bitcoin network" taken as a whole.
I think it is reasonable to consider that some difficult-to-game
property of the last N blocks (like the hash of the last 100
block-id's or whatever), could be the verification input.

The VDF gets calculated by *every* eligible proof-of-burn miner, and
then this is used to prevent a timing issue.

Seems reasonable to me, but I haven't looked too far into the
requirements of VDF's

nice summary for anyone who is interested:
https://medium.com/@djrtwo/vdfs-are-not-proof-of-work-91ba3bec2bf4

While VDF's almost always lead to a "cpu-speed monopoly", this would
only be helpful for block latency in a proof-of-burn chain. Block
height would be calculated by eligible-miner-burned-coins, so the
monopoly could be easily avoided.

There has been some decent earlier work on blind/uncensorable burns:
https://eprint.iacr.org/2019/1096.pdf

A miner could then reveal A) the VDF and B) proof-of-burn as a part of
a block. Nodes would simply select the block with A) a valid VDF and
B) the highest "qualified" POB.

With most burns running at a loss, and no way to predict the next
"winning burn", and the VDF providing timing, I'm not sure how this is
worse than Bitcoin's existing system.

On Mon, May 10, 2021 at 5:51 PM Jeremy <jlrubin at mit.edu> wrote:
>
> re: 2, there's been some promising developments with Verifiable Delay Functions that make me think that the block regulation problems are solvable without requiring brute-force search proof of work. Are those inapplicable for some reason?
>

📅 Original date posted:2021-05-10 📝 Original ...

2023-06-08T00:52:42+02:00

In reply to nevent1q…khyz
_________________________

📅 Original date posted:2021-05-10
📝 Original message:personally, not speaking for anyone else, i think that proof-of-burn
has a much higher likelihood of being a) good enough security and b)
solving the nothing-at-stake problem

the only issue i see with a quality PoB implementation is a robust
solution to the block-timing problem.

https://grisha.org/blog/2018/01/23/explaining-proof-of-work/

i do think there *could* be other low-energy solutions to verifiable
timing, just haven't seen one

On Fri, May 7, 2021 at 6:50 PM SatoshiSingh via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Hello list,
>
> I am a lurker here and like many of you I worry about the energy usage of bitcoin mining. I understand a lot mining happens with renewable resources but the impact is still high.
>
> I want to get your opinion on implementing proof of stake for bitcoin mining in future. For now, proof of stake is still untested and not battle tested like proof of work. Though someday it will be.
>
> In the following years we'll be seeing proof of stake being implemented. Smaller networks can test PoS which is a luxury bitcoin can't afford. Here's how I see this the possibilities:
>
> 1 - Proof of stake isn't a good enough security mechanism
> 2 - Proof of state is a good security mechanism and works as intended
>
> IF PoS turns out to be good after battle testing, would you consider implementing it for Bitcoin? I understand this would invoke a lot of controversies and a hard fork that no one likes. But its important enough to consider a hard fork. What are your opinions provided PoS does work?
>
> Love from India.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

📅 Original date posted:2021-04-16 📝 Original message:Not ...

2023-06-08T00:51:51+02:00

In reply to nevent1q…rh27
_________________________

📅 Original date posted:2021-04-16
📝 Original message:Not sure of the best place to workshop ideas, so please take this with
a grain of salt.

Starting with 3 assumptions:

- assume that there exists a proof-of-burn that, for Bitcoin's
purposes, accurately-enough models the investment in and development
of ASICs to maintain miner incentive.
- assume the resulting timing problem "how much burn is enough to keep
blocks 10 minutes apart and what does that even mean" is also...
perfectly solvable
- assume "everyone unanimously loves this idea"

The transition *could* look like this:

- validating nodes begin to require proof-of-burn, in addition to
proof-of-work (soft fork)
- the extra expense makes it more expensive for miners, so POW slowly drops
- on a predefined schedule, POB required is increased to 100% of the
"required work" to mine

Given all of that, am I correct in thinking that a hard fork would not
be necessary?

IE: We could transition to another "required proof" - such as a
quantum POW or a POB (above) or something else .... in a back-compat
way (existing nodes not aware of the rules would continue to
validate).

📅 Original date posted:2021-04-09 📝 Original message:is ...

2023-06-08T00:51:37+02:00

In reply to nevent1q…6k3k
_________________________

📅 Original date posted:2021-04-09
📝 Original message:is there any way to specify a maximum block height on a transaction?

ie: this tx is only valid if included in a block with a certain height or less

i feel like this would be useful

📅 Original date posted:2021-04-10 📝 Original ...

2023-06-08T00:51:19+02:00

In reply to nevent1q…nn8d
_________________________

📅 Original date posted:2021-04-10
📝 Original message:here's what we do for multisig:

- each member generates their own public/private key pair first and
publishes the pair to all other members
- members are then verified using a secondary channel, like a phone
call ... where the H128(pubk) is turned into BIP-words for
manual/visual verification
- multi-round DKG is used with appropriate commitments and
verification of components (nice article:
https://link.springer.com/content/pdf/10.1007/s00145-006-0347-3.pdf)

without that, there's simply no guarantee that you're not
communicating with an attacker during setup.

On Tue, Feb 9, 2021 at 2:53 AM Hugo Nguyen via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Hi all,
> I would like to propose a new BIP for Secure Multisig Setup.
> This proposal has taken inputs from folks at Coldcard, Shift Crypto and Cobo -- listed below as co-authors.
>
> This was inspired by my own experience working with hardware wallets on the market, as well as existing research into the challenges of multisig.
>
> Cheers,
> Hugo
>
> <pre>
> BIP: To be determined
> Layer: Applications
> Title: Bitcoin Secure Multisig Setup (BSMS)
> Author: Hugo Nguyen <hugo at nunchuk.io>, Peter Gray <peter at coinkite.com>, Marko Bencun <marko at shiftcrypto.ch>, Aaron Chen <aarondongchen at gmail.com>, Rodolfo Novak <rodolfo at coinkite.com>
> Comments-Summary: No comments yet.
> Comments-URI:
> Status: Proposed
> Type: Standards Track
> Created: 2020-11-10
> License: BSD-2-Clause
> </pre>
>
> ==Introduction==
>
> ===Abstract===
>
> This document proposes a mechanism to set up multisig wallets securely.
>
> ===Copyright===
>
> This BIP is licensed under the 2-clause BSD license.
>
> ===Motivation===
>
> The Bitcoin multisig experience has been greatly streamlined under [https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki BIP-0174 (Partially Signed Bitcoin Transaction)]. However, what is still missing is a standardized process for setting up multisig wallets securely across different vendors.
>
> There are a number of concerns when it comes to setting up a multisig wallet:
>
> # Whether the multisig configuration, such as Signer membership, script type, derivation paths and number of signatures required, is correct and not tampered with.
> # Whether Signer persists the multisig configuration in their respective storage, and under what format.
> # Whether Signer's storage is tamper-proof.
> # Whether Signer subsequently uses the multisig configuration to generate and verify receive and change addresses.
>
> An attacker who can modify the multisig configuration can steal or hold funds to ransom by duping the user into sending funds to the wrong address.
>
> This proposal seeks to address concerns #1 and #2: to mitigate the risk of tampering during the initial setup phase, and to define an interoperable multisig configuration format.
>
> Concerns #3 and #4 should be handled by Signers and is out of scope of this proposal.
>
> ==Specification==
>
> ===Prerequisites===
> This proposal assumes the parties in the multisig support [https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki BIP32], [https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md the descriptor language] and encryption.
>
> ==Roles==
> ===Coordinator===
>
> The Coordinator initiates the multisig setup. The Coordinator determines what type of multisig is used and how many members and signatures are needed. If encryption is enabled, the Coordinator generates a secret token, to be shared among the parties for secure communication. The Coordinator gathers information from the Signers to generate a descriptor record. The Coordinator distributes the descriptor record back to the Signers.
>
> ===Signer===
>
> The Signer is a participating member in the multisig. Its responsibilities include providing its XPUB to the Coordinator, verifying that its XPUB is included in the descriptor record and persisting the descriptor record in its storage.
>
> ==Setup Process==
>
> ===Round 1===
>
> ====Coordinator====
>
> * The Coordinator creates a multisig wallet creation session. The Coordinator determines the type of multisig script used and the signing configuration (<tt>M</tt> and <tt>N</tt>).
> * If encryption is enabled, the Coordinator also generates a secret token, hereby denoted <tt>TOKEN</tt>.
> * TOKEN is in ASCII format and must have a minimum of 8 characters. TOKEN should expire after some time period determined by the Coordinator, e.g., 24 hours.
> * TOKEN acts as an encryption key among the parties. The method of encryption is AES, CTR mode. The encryption key can be calculated by performing a double hash operation on the TOKEN: <tt>ENCRYPTION_KEY = SHA256(SHA256(TOKEN))</tt>.
> * A TOKEN value of <tt>-1</tt> means that encryption is disabled and all the encryption/decryption steps below can be skipped.
> * The Coordinator shares the TOKEN with all participating Signers over a secure channel.
>
> ====Signer====
>
> * The Signer generates a key record by prompting the user for the TOKEN and a derivation path.
> * The first line in the record must be the <tt>TOKEN</tt>. If encryption is disabled, set the TOKEN to -1. The second line must be the <tt>KEY</tt>, whereas KEY is an XPUB. KEY must include key origin information and written in the descriptor-defined format, i.e.: <tt>[{master key fingerprint}/{derivation path}]{XPUB}</tt>. The third line must be a <tt>SIG</tt>, whereas SIG is the signature generated by using the corresponding private key to sign the first two lines. Finally, the Signer encrypts the entire record with ENCRYPTION_KEY.
>
> ===Round 2===
>
> ====Coordinator====
>
> * The Coordinator gathers key records from all participating Signers. Abort the setup if TOKEN has expired.
> * For each key record, the Coordinator decrypts it using ENCRYPTION_KEY. The Coordinator verifies that the included SIG is valid given the KEY.
> * If all key records look good, the Coordinator generates a descriptor record, which is simply the descriptor string plus a <tt>CHECKSUM</tt>, all in one line. The CHECKSUM has BECH32 encoding and is described at [https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md#checksums]. The Coordinator encrypts this descriptor record with ENCRYPTION_KEY.
> * The Coordinator sends the encrypted descriptor record to all participating Signers.
>
> ====Signer====
>
> * The Signer imports the descriptor record, decrypts it by prompting the user for TOKEN.
> * The Signer calculates and verifies the descriptor’s CHECKSUM. Abort the setup if the CHECKSUM is incorrect.
> * The Signer checks whether one of the KEYs in the descriptor belongs to it, using path and fingerprint information included in the descriptor. The check must perform an exact match on the KEYs, and not using shortcuts such as matching fingerprints (which is trivial to spoof). Abort the setup if it doesn’t detect its own KEY.
> * For confirmation, the Signer must display to the user the descriptor's CHECKSUM, plus other configurations, such as M and N. The total number of Signers, N, is important to prevent a KEY insertion attack. All participating Signers should be able to display the same confirmation.
> * If all checks pass, the Signer persists the descriptor record in its storage. The Signer should subsequently use the descriptor to generate and verify receive and change addresses.
>
> This completes the setup.
>
> ==QR Codes==
> For signers that use QR codes to transmit data, key and descriptor records can be converted to QR codes, following [https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-005-ur.md the BCR standard].
>
> ==Security==
>
> This proposal introduce two layers of protection. The first one is a temporary, secret token, used to encrypt the two rounds of communication between the Signers and the Coordinator. The second one is through the descriptor checksum and visual inspection of the descriptor itself.
>
> The token is only needed during the setup phase, and can be safely thrown away afterwards. The token does not guarantee that the Signer membership set is not modified, since that depends on the overall security of all parties in the setup, but it can make it significantly harder for an attacker to do so.
>
> There are three ways an attacker can modify the membership set: by changing an existing member, by removing an existing member, or by adding a new member.
>
> For the first two methods, one of the Signers will be able to detect that its membership has been changed or removed, and reject the final descriptor. Thus, it is vital that all participating Signers check that their membership is intact in the descriptor. Even one Signer failing to check for its membership means that the setup could be compromised.
>
> For the third type of attack, the descriptor checksum and visual inspection of the descriptor itself are the only way to guard against malicious members from being inserted into the set.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

📅 Original date posted:2021-04-10 📝 Original ...

2023-06-07T20:31:16+02:00

In reply to nevent1q…c3pe
_________________________

📅 Original date posted:2021-04-10
📝 Original message:here's what we do for multisig:

- each member generates their own public/private key pair first and
publishes the pair to all other members
- members are then verified using a secondary channel, like a phone
call ... where the H128(pubk) is turned into BIP-words for
manual/visual verification
- multi-round DKG is used with appropriate commitments and
verification of components (nice article:
https://link.springer.com/content/pdf/10.1007/s00145-006-0347-3.pdf)

without that, there's simply no guarantee that you're not
communicating with an attacker during setup.

On Tue, Feb 9, 2021 at 2:53 AM Hugo Nguyen via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Hi all,
> I would like to propose a new BIP for Secure Multisig Setup.
> This proposal has taken inputs from folks at Coldcard, Shift Crypto and Cobo -- listed below as co-authors.
>
> This was inspired by my own experience working with hardware wallets on the market, as well as existing research into the challenges of multisig.
>
> Cheers,
> Hugo
>
> <pre>
> BIP: To be determined
> Layer: Applications
> Title: Bitcoin Secure Multisig Setup (BSMS)
> Author: Hugo Nguyen <hugo at nunchuk.io>, Peter Gray <peter at coinkite.com>, Marko Bencun <marko at shiftcrypto.ch>, Aaron Chen <aarondongchen at gmail.com>, Rodolfo Novak <rodolfo at coinkite.com>
> Comments-Summary: No comments yet.
> Comments-URI:
> Status: Proposed
> Type: Standards Track
> Created: 2020-11-10
> License: BSD-2-Clause
> </pre>
>
> ==Introduction==
>
> ===Abstract===
>
> This document proposes a mechanism to set up multisig wallets securely.
>
> ===Copyright===
>
> This BIP is licensed under the 2-clause BSD license.
>
> ===Motivation===
>
> The Bitcoin multisig experience has been greatly streamlined under [https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki BIP-0174 (Partially Signed Bitcoin Transaction)]. However, what is still missing is a standardized process for setting up multisig wallets securely across different vendors.
>
> There are a number of concerns when it comes to setting up a multisig wallet:
>
> # Whether the multisig configuration, such as Signer membership, script type, derivation paths and number of signatures required, is correct and not tampered with.
> # Whether Signer persists the multisig configuration in their respective storage, and under what format.
> # Whether Signer's storage is tamper-proof.
> # Whether Signer subsequently uses the multisig configuration to generate and verify receive and change addresses.
>
> An attacker who can modify the multisig configuration can steal or hold funds to ransom by duping the user into sending funds to the wrong address.
>
> This proposal seeks to address concerns #1 and #2: to mitigate the risk of tampering during the initial setup phase, and to define an interoperable multisig configuration format.
>
> Concerns #3 and #4 should be handled by Signers and is out of scope of this proposal.
>
> ==Specification==
>
> ===Prerequisites===
> This proposal assumes the parties in the multisig support [https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki BIP32], [https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md the descriptor language] and encryption.
>
> ==Roles==
> ===Coordinator===
>
> The Coordinator initiates the multisig setup. The Coordinator determines what type of multisig is used and how many members and signatures are needed. If encryption is enabled, the Coordinator generates a secret token, to be shared among the parties for secure communication. The Coordinator gathers information from the Signers to generate a descriptor record. The Coordinator distributes the descriptor record back to the Signers.
>
> ===Signer===
>
> The Signer is a participating member in the multisig. Its responsibilities include providing its XPUB to the Coordinator, verifying that its XPUB is included in the descriptor record and persisting the descriptor record in its storage.
>
> ==Setup Process==
>
> ===Round 1===
>
> ====Coordinator====
>
> * The Coordinator creates a multisig wallet creation session. The Coordinator determines the type of multisig script used and the signing configuration (<tt>M</tt> and <tt>N</tt>).
> * If encryption is enabled, the Coordinator also generates a secret token, hereby denoted <tt>TOKEN</tt>.
> * TOKEN is in ASCII format and must have a minimum of 8 characters. TOKEN should expire after some time period determined by the Coordinator, e.g., 24 hours.
> * TOKEN acts as an encryption key among the parties. The method of encryption is AES, CTR mode. The encryption key can be calculated by performing a double hash operation on the TOKEN: <tt>ENCRYPTION_KEY = SHA256(SHA256(TOKEN))</tt>.
> * A TOKEN value of <tt>-1</tt> means that encryption is disabled and all the encryption/decryption steps below can be skipped.
> * The Coordinator shares the TOKEN with all participating Signers over a secure channel.
>
> ====Signer====
>
> * The Signer generates a key record by prompting the user for the TOKEN and a derivation path.
> * The first line in the record must be the <tt>TOKEN</tt>. If encryption is disabled, set the TOKEN to -1. The second line must be the <tt>KEY</tt>, whereas KEY is an XPUB. KEY must include key origin information and written in the descriptor-defined format, i.e.: <tt>[{master key fingerprint}/{derivation path}]{XPUB}</tt>. The third line must be a <tt>SIG</tt>, whereas SIG is the signature generated by using the corresponding private key to sign the first two lines. Finally, the Signer encrypts the entire record with ENCRYPTION_KEY.
>
> ===Round 2===
>
> ====Coordinator====
>
> * The Coordinator gathers key records from all participating Signers. Abort the setup if TOKEN has expired.
> * For each key record, the Coordinator decrypts it using ENCRYPTION_KEY. The Coordinator verifies that the included SIG is valid given the KEY.
> * If all key records look good, the Coordinator generates a descriptor record, which is simply the descriptor string plus a <tt>CHECKSUM</tt>, all in one line. The CHECKSUM has BECH32 encoding and is described at [https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md#checksums]. The Coordinator encrypts this descriptor record with ENCRYPTION_KEY.
> * The Coordinator sends the encrypted descriptor record to all participating Signers.
>
> ====Signer====
>
> * The Signer imports the descriptor record, decrypts it by prompting the user for TOKEN.
> * The Signer calculates and verifies the descriptor’s CHECKSUM. Abort the setup if the CHECKSUM is incorrect.
> * The Signer checks whether one of the KEYs in the descriptor belongs to it, using path and fingerprint information included in the descriptor. The check must perform an exact match on the KEYs, and not using shortcuts such as matching fingerprints (which is trivial to spoof). Abort the setup if it doesn’t detect its own KEY.
> * For confirmation, the Signer must display to the user the descriptor's CHECKSUM, plus other configurations, such as M and N. The total number of Signers, N, is important to prevent a KEY insertion attack. All participating Signers should be able to display the same confirmation.
> * If all checks pass, the Signer persists the descriptor record in its storage. The Signer should subsequently use the descriptor to generate and verify receive and change addresses.
>
> This completes the setup.
>
> ==QR Codes==
> For signers that use QR codes to transmit data, key and descriptor records can be converted to QR codes, following [https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-005-ur.md the BCR standard].
>
> ==Security==
>
> This proposal introduce two layers of protection. The first one is a temporary, secret token, used to encrypt the two rounds of communication between the Signers and the Coordinator. The second one is through the descriptor checksum and visual inspection of the descriptor itself.
>
> The token is only needed during the setup phase, and can be safely thrown away afterwards. The token does not guarantee that the Signer membership set is not modified, since that depends on the overall security of all parties in the setup, but it can make it significantly harder for an attacker to do so.
>
> There are three ways an attacker can modify the membership set: by changing an existing member, by removing an existing member, or by adding a new member.
>
> For the first two methods, one of the Signers will be able to detect that its membership has been changed or removed, and reject the final descriptor. Thus, it is vital that all participating Signers check that their membership is intact in the descriptor. Even one Signer failing to check for its membership means that the setup could be compromised.
>
> For the third type of attack, the descriptor checksum and visual inspection of the descriptor itself are the only way to guard against malicious members from being inserted into the set.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

📅 Original date posted:2021-03-22 📝 Original message:yes ...

2023-06-07T20:30:59+02:00

In reply to nevent1q…0h6k
_________________________

📅 Original date posted:2021-03-22
📝 Original message:yes that would be fine. not sure what your objection to sha3 is tho
(more provably secure) - i guess sticking with bitcoin-lib stuff tho.

On Fri, Mar 19, 2021 at 10:08 PM Arik Sosman <me at arik.io> wrote:
>
> Hi Erik,
>
> Would sha256-hmac(nonce, publicKeyPoint) still be a suitable/safe alternative without relying on sha3? That should at the very least eliminate length extension attacks.
>
> Best,
> Arik
>
> > On Mar 19, 2021, at 6:32 PM, Erik Aronesty via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >
> > use sha3-256. sha256 suffers from certain attacks (length extension,
> > for example) that could make your scheme vulnerable to leaking info,
> > depending on how you concatenate things, etc. better to choose
> > something where padding doesn't matter.
> >
> > On Fri, Mar 19, 2021 at 7:28 PM vjudeu via bitcoin-dev
> > <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >>
> >> I recently found some interesting and simple HD wallet design here: https://bitcointalk.org/index.php?topic=5321992.0
> >> Could anyone see any flaws in such design or is it safe enough to implement it and use in practice?
> >> If I understand it correctly, it is just pure ECDSA and SHA-256, nothing else:
> >>
> >> masterPublicKey = masterPrivateKey * G
> >> masterChildPublicKey = masterPublicKey + ( SHA-256( masterPublicKey || nonce ) mod n ) * G
> >> masterChildPrivateKey = masterPrivateKey + ( SHA-256( masterPublicKey || nonce ) mod n )
> >>
> >> Also, it has some nice properties, like all keys starting with 02 prefix and allows potentially unlimited custom derivation path by using 256-bit nonce.
> >> _______________________________________________
> >> bitcoin-dev mailing list
> >> bitcoin-dev at lists.linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

📅 Original date posted:2021-03-19 📝 Original message:use ...

2023-06-07T20:30:59+02:00

In reply to nevent1q…2uzc
_________________________

📅 Original date posted:2021-03-19
📝 Original message:use sha3-256. sha256 suffers from certain attacks (length extension,
for example) that could make your scheme vulnerable to leaking info,
depending on how you concatenate things, etc. better to choose
something where padding doesn't matter.

On Fri, Mar 19, 2021 at 7:28 PM vjudeu via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> I recently found some interesting and simple HD wallet design here: https://bitcointalk.org/index.php?topic=5321992.0
> Could anyone see any flaws in such design or is it safe enough to implement it and use in practice?
> If I understand it correctly, it is just pure ECDSA and SHA-256, nothing else:
>
> masterPublicKey = masterPrivateKey * G
> masterChildPublicKey = masterPublicKey + ( SHA-256( masterPublicKey || nonce ) mod n ) * G
> masterChildPrivateKey = masterPrivateKey + ( SHA-256( masterPublicKey || nonce ) mod n )
>
> Also, it has some nice properties, like all keys starting with 02 prefix and allows potentially unlimited custom derivation path by using 256-bit nonce.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

📅 Original date posted:2021-03-12 📝 Original ...

2023-06-07T20:30:12+02:00

In reply to nevent1q…jn7u
_________________________

📅 Original date posted:2021-03-12
📝 Original message:secp236k1 isn't a hashing algo. your BIP needs about 10 more pages
and some degree of technical merit.

i suggest you start here:

https://en.bitcoin.it/wiki/Proof_of_burn
https://bitcointalk.org/index.php?topic=225690.0

proof-of-burn is a nice alternative to proof-of-work. i always
suspected that, if designed correctly, it could be a proven
equivalent. you could spin up a fork of bitcoin that allows aged,
burned, coins instead of POW that would probably work just fine.

- erik

On Thu, Mar 11, 2021 at 11:56 AM Lonero Foundation via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Hi, I have submitted the BIP Pull Request here: https://github.com/bitcoin/bips/pull/1084
>
> Hoping to receive a BIP # for the draft prior to development/reference implementation.
>
> Best regards, Andrew
>
> On Mon, Mar 8, 2021, 6:40 PM Lonero Foundation <loneroassociation at gmail.com> wrote:
>>
>> Hi, here is the list to the BIP proposal on my own repo: https://github.com/Mentors4EDU/bip-amkn-posthyb/blob/main/bip-draft.mediawiki
>> Can I submit a pull request on the BIPs repo for this to go into draft mode? Also, I think this provides at least some more insight on what I want to work on.
>>
>> Best regards, Andrew
>>
>> On Sat, Mar 6, 2021, 10:42 AM Lonero Foundation <loneroassociation at gmail.com> wrote:
>>>
>>> [off-list]
>>>
>>> Okay. I will do so and post the link here for discussion before doing a pull request on BIP's repo as the best way to handle it.
>>>
>>> Best regards, Andrew
>>>
>>> On Sat, Mar 6, 2021, 10:21 AM Ricardo Filipe <ricardojdfilipe at gmail.com> wrote:
>>>>
>>>> As said before, you are free to create the BIP in your own repository
>>>> and bring it to discussion on the mailing list. then you can do a PR
>>>>
>>>> Lonero Foundation via bitcoin-dev
>>>> <bitcoin-dev at lists.linuxfoundation.org> escreveu no dia sábado,
>>>> 6/03/2021 à(s) 08:58:
>>>> >
>>>> > I know Ethereum had an outlandishly large percentage of nodes running on AWS, I heard the same thing is for Bitcoin but for mining. Had trouble finding the article online so take it with a grain of salt. The point though is that both servers and ASIC specific hardware would still be able to benefit from the cryptography upgrade I am proposing, as this was in relation to the disinfranchisemet point.
>>>> >
>>>> > That said, I think the best way to move forward is to submit a BIP pull request for a draft via GitHub using BIP #2's draft format and any questions people have can be answered in the reqeust's comments. That way people don't have to get emails everytime there is a reply, but replies still get seen as opposed to offline discussion. Since the instructions say to email bitcoin-dev before doing a bip draft, I have done that. Since people want to see the draft beforehand and it isn't merged manually anyways, I think it is the easiest way to handle this.
>>>> >
>>>> > I'm also okay w/ continuing the discussion on bitcoin-dev but rather form a discussion on git instead given I don't want to accidentally impolitely bother people given this is a moderated list and we already established some interest for at least a draft.
>>>> >
>>>> > Does that seem fine?
>>>> >
>>>> > Best regards, Andrew
>>>> >
>>>> > On Fri, Mar 5, 2021, 7:41 PM Keagan McClelland <keagan.mcclelland at gmail.com> wrote:
>>>> >>
>>>> >> > A large portion of BTC is already mined through AWS servers and non-asic specific hardware anyways. A majority of them would benefit from a hybrid proof, and the fact that it is hybrid in that manner wouldn't disenfranchise currently optimized mining entities as well.
>>>> >>
>>>> >> My instincts tell me that this is an outlandish claim. Do you have supporting evidence for this?
>>>> >>
>>>> >> Keagan
>>>> >>
>>>> >> On Fri, Mar 5, 2021 at 3:22 PM Lonero Foundation via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>> >>>
>>>> >>> Actually I mentioned a proof of space and time hybrid which is much different than staking. Sorry to draw for the confusion as PoC is more commonly used then PoST.
>>>> >>> There is a way to make PoC cryptographically compatible w/ Proof of Work as it normally stands: https://en.wikipedia.org/wiki/Proof_of_space
>>>> >>> It has rarely been done though given the technological complexity of being both CPU compatible and memory-hard compatible. There are lots of benefits outside of the realm of efficiency, and I already looked into numerous fault tolerant designs as well and what others in the cryptography community attempted to propose. The actual argument you have only against this is the Proof of Memory fallacy, which is only partially true. Given how the current hashing algorithm works, hard memory allocation wouldn't be of much benefit given it is more optimized for CPU/ASIC specific mining. I'm working towards a hybrid mechanism that fixes that. BTW: The way Bitcoin currently stands in its cryptography still needs updating regardless. If someone figures out NP hardness or the halting problem the traditional rule of millions of years to break all of Bitcoin's cryptography now comes down to minutes. Bitcoin is going to have to eventually radically upgrade their cryptography and hashing algo in the future regardless. I want to integrate some form of NP complexity in regards to the hybrid cryptography I'm aiming to provide which includes a polynomial time algorithm in the cryptography. More than likely the first version of my BTC hard fork will be coded in a way where integrating such complexity in the future only requires a soft fork or minor upgrade to its chain.
>>>> >>>
>>>> >>> In regards to the argument, "As a separate issue, proposing a hard fork in the hashing algorithm will invalidate the enormous amount of capital expenditure by mining entities and disincentivize future capital expenditure into mining hardware that may compute these more "useful" proofs of work."
>>>> >>>
>>>> >>> A large portion of BTC is already mined through AWS servers and non-asic specific hardware anyways. A majority of them would benefit from a hybrid proof, and the fact that it is hybrid in that manner wouldn't disenfranchise currently optimized mining entities as well.
>>>> >>>
>>>> >>> There are other reasons why a cryptography upgrade like this is beneficial. Theoretically one can argue BItcoin isn't fully decentralized. It is few unsolved mathematical proofs away from being entirely broken. My goal outside of efficiency is to build cryptography in a way that prevents such an event from happening in the future, if it was to ever happen. I have various research in regards to this area and work alot with distributed computing. I believe if the BTC community likes such a proposal, I would single handedly be able to build the cryptographic proof myself (though would like as many open source contributors as I can get :)
>>>> >>>
>>>> >>> Anyways just something to consider. We are in the same space in regards to what warrants a shitcoin or the whole argument against staking.
>>>> >>> https://hackernoon.com/ethereum-you-are-a-centralized-cryptocurrency-stop-telling-us-that-you-arent-pi3s3yjl
>>>> >>>
>>>> >>> Best regards, Andrew
>>>> >>>
>>>> >>> On Fri, Mar 5, 2021 at 4:11 PM Keagan McClelland <keagan.mcclelland at gmail.com> wrote:
>>>> >>>>
>>>> >>>> It is important to understand that it is critical for the work to be "useless" in order for the security model to be the same. If the work was useful it provides an avenue for actors to have nothing at stake when submitting a proof of work, since the marginal cost of block construction will be lessened by the fact that the work was useful in a different context and therefore would have been done anyway. This actually degrades the security of the network in the process.
>>>> >>>>
>>>> >>>> As a separate issue, proposing a hard fork in the hashing algorithm will invalidate the enormous amount of capital expenditure by mining entities and disincentivize future capital expenditure into mining hardware that may compute these more "useful" proofs of work. This is because any change in the POW algorithm will be considered unstable and subject to change in the future. This puts the entire network at even more risk meaning that no entity is tying their own interests to that of the bitcoin network at large. It also puts the developers in a position where they can be bribed by entities with a vested interest in deciding what the new "useful" proof of work should be.
>>>> >>>>
>>>> >>>> All of these things make the Bitcoin network worse off.
>>>> >>>>
>>>> >>>> Keagan
>>>> >>>>
>>>> >>>> On Fri, Mar 5, 2021 at 1:48 PM Lonero Foundation via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>> >>>>>
>>>> >>>>> Also in regards to my other email, I forgot to iterate that my cryptography proposal helps behind the efficiency category but also tackles problems such as NP-Completeness or Halting which is something the BTC network could be vulnerable to in the future. For sake of simplicity, I do want to do this BIP because it tackles lots of the issues in regards to this manner and can provide useful insight to the community. If things such as bigger block height have been proposed as hard forks, I feel at the very least an upgrade regarding the hashing algorithm and cryptography does at least warrant some discussion. Anyways I hope I can send you my BIP, just let me know on the preferred format?
>>>> >>>>>
>>>> >>>>> Best regards, Andrew
>>>> >>>>>
>>>> >>>>> On Fri, Mar 5, 2021, 10:12 AM Lonero Foundation <loneroassociation at gmail.com> wrote:
>>>> >>>>>>
>>>> >>>>>> Hi, this isn't about the energy efficient argument in regards to renewables or mining devices but a better cryptography layer to get the most out of your hashing for validation. I do understand the arbitrariness of it, but do want to still propose a document. Do I use the Media Wiki format on GitHub and just attach it as my proposal?
>>>> >>>>>>
>>>> >>>>>> Best regards, Andrew
>>>> >>>>>>
>>>> >>>>>> On Fri, Mar 5, 2021, 10:07 AM Devrandom <c1.devrandom at niftybox.net> wrote:
>>>> >>>>>>>
>>>> >>>>>>> Hi Ryan and Andrew,
>>>> >>>>>>>
>>>> >>>>>>> On Fri, Mar 5, 2021 at 5:42 AM Ryan Grant via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>> >>>>>>>>
>>>> >>>>>>>>
>>>> >>>>>>>> https://www.truthcoin.info/blog/pow-cheapest/
>>>> >>>>>>>> "Nothing is Cheaper than Proof of Work"
>>>> >>>>>>>> on | 04 Aug 2015
>>>> >>>>>>>>
>>>> >>>>>>>
>>>> >>>>>>> Just to belabor this a bit, the paper demonstrates that the mining market will tend to expend resources equivalent to miner reward. It does not prove that mining work has to expend *energy* as a primary cost.
>>>> >>>>>>>
>>>> >>>>>>> Some might argue that energy expenditure has negative externalities and that we should move to other resources. I would argue that the negative externalities will go away soon because of the move to renewables, so the point is likely moot.
>>>> >>>>>>>
>>>> >>>>> _______________________________________________
>>>> >>>>> bitcoin-dev mailing list
>>>> >>>>> bitcoin-dev at lists.linuxfoundation.org
>>>> >>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>> >>>
>>>> >>> _______________________________________________
>>>> >>> bitcoin-dev mailing list
>>>> >>> bitcoin-dev at lists.linuxfoundation.org
>>>> >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>> >
>>>> > _______________________________________________
>>>> > bitcoin-dev mailing list
>>>> > bitcoin-dev at lists.linuxfoundation.org
>>>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

📅 Original date posted:2021-03-02 📝 Original message:This ...

2023-06-07T20:29:43+02:00

In reply to nevent1q…qk34
_________________________

📅 Original date posted:2021-03-02
📝 Original message:This is the declining percentage of signaling activation.

It has all the benefits of both.

Eventually it becomes a LOT=true, so any argument for LOT=true holds

And all of the arguments for LOT=false are satisfied by the cool down
period.

On Mon, Mar 1, 2021, 12:05 PM yanmaani--- via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> How about a compromise?
>
> With LOT=false, taproot will be activated if at least 95% of the miners
> vote yes.
> With LOT=true, taproot will be activated if at least 0% of the miners
> vote yes.
> ...with LOT=maybe, taproot will be activated if at least ~some% of the
> miners vote yes?
>
> If you want the 'emergency cancel' feature without binding yourself to
> it, couldn't you have some middle-of-the-road solution? "Taproot will be
> enabled if miner support ever goes above 95%, or on flag day if miner
> support is >20% then". That would prevent obstreperous miners from doing
> too much damage, while still hopefully making it possible to bail out of
> a disaster.
>
> On 2021-03-01 15:06, Anthony Towns via bitcoin-dev wrote:
> > On Sun, Feb 28, 2021 at 07:33:30PM +0000, Luke Dashjr via bitcoin-dev
> > wrote:
> >> As we saw in 2017 with BIP 9, coordinating activation by miner signal
> >> alone,
> >> despite its potential benefits, also leaves open the door to a miner
> >> veto.
> >
> > To the contrary, we saw in 2017 that miners could *not* successfully
> > veto a BIP 9 activation. It was certainly more effort and risk than was
> > desirable to override the attempted veto, but the attempt at vetoing
> > nevertheless failed.
> >
> >> It wouldn't be much different than adding back the inflation bug
> >> (CVE-2018-17144) and trusting miners not to exploit it.
> >
> > That is ridiculous FUD.
> >
> >> With LOT=False in the picture, however, things can get messy:
> >
> > LOT=false is always in the picture if we are talking about a soft-fork:
> > the defining feature of a soft-fork is that old node software continues
> > to work, and old node software will be entirely indifferent to whether
> > activation is signalled or not.
> >
> >> some users will
> >> enforce Taproot(eg) (those running LOT=True), while others will not
> >> (those
> >> with LOT=False)
> >
> > If you are following bip8 with lockinontimeout=false, you will enforce
> > taproot rules if activation occurs, you will simply not reject blocks
> > if
> > activation does not occur.
> >
> >> Users with LOT=True will still get all the safety thereof,
> >> but those with LOT=False will (in the event of miners deciding to
> >> produce a
> >> chain split) face an unreliable chain, being replaced by the LOT=True
> >> chain
> >> every time it overtakes the LOT=False chain in work.
> >
> > This assumes anyone mining the chain where taproot does not activate is
> > not able to avoid a reorg, despite having majority hashpower (as
> > implied
> > by the lot=true chain having to overtake them repeatedly). That's
> > absurd;
> > avoiding a reorg is trivially achieved via running "invalidateblock",
> > or
> > via pool software examining block headers, or via a patch along the
> > lines
> > of MUST_SIGNAL enforcement, but doing the opposite. For concreteness,
> > here's a sketch of such a patch:
> >
> >
> https://github.com/ajtowns/bitcoin/commit/f195688bd1eff3780f200e7a049e23b30ca4fe2f
> >
> >> For 2 weeks, users with LOT=False would not have a usable network.
> >
> > That's also ridiculous FUD.
> >
> > If it were true, it would mean the activation mechanism was not
> > acceptable, as non-upgraded nodes would also not have a usable network
> > for the same reason.
> >
> > Fortunately, it's not true.
> >
> > More generally, if miners are willing to lose significant amounts of
> > money mining orphan blocks, they can do that at any time. If they're
> > not inclined to do so, it's incredibly straightforward for them to
> > avoid
> > doing so, whatever a minority of other miners might do.
> >
> >> The overall risk is maximally reduced by LOT=True being the only
> >> deployed
> >> parameter, and any introduction of LOT=False only increases risk
> >> probability
> >> and severity.
> >
> > LOT=false is the default behaviour of everything single piece of node
> > software out there. That behaviour doesn't need to be introduced, it's
> > already universal.
> >
> > Cheers,
> > aj
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210302/1ac9853a/attachment-0001.html>;

📅 Original date posted:2021-03-03 📝 Original ...

2023-06-07T20:29:27+02:00

In reply to nevent1q…p7p4
_________________________

📅 Original date posted:2021-03-03
📝 Original message:taproot does not enable anything that cannot already be done today.

it only enables larger and more complex scripts to be done more
efficiently - using less ledger space.

so any objections you can have should be leveled at bitcoin, not at taproot.

On Wed, Mar 3, 2021 at 6:39 AM LORD HIS EXCELLENCY JAMES HRMH via
bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> "Today I spent approximately $5 at a chip shop in North London in cash. Besides the fact that I have voluntarily chosen to share this information, it is absolutely no concern of yourself or any other party that this transaction has occured."
>
> Good Afternoon,
>
> Requiring little argument I concur, privacy allows that you do not have snoops and researchers following you around looking in your purse as you transact. For the general public, how much you carry in your purse and where you get it from is none of their business. However, your employer is required to report to the government a record of pay, or at least maintain that record, and the store where you made a purchase similarly to keep records so that taxes can be paid. From their perspective, you do not need to know how much they keep in their drawer. Bitcoin directly allows your purse to be private and for the transaction ledger to take the scrutiny anyone should be able to apply to prove the ledger is honest. Maintaining an argument that consensus requires the ledger to be honest does not prove that it is honest.
>
> KING JAMES HRMH
> Great British Empire
>
> Regards,
> The Australian
> LORD HIS EXCELLENCY JAMES HRMH (& HMRH)
> of Hougun Manor & Glencoe & British Empire
> MR. Damian A. James Williamson
> Wills
>
> et al.
>
>
> Willtech
> www.willtech.com.au
> www.go-overt.com
> and other projects
>
> earn.com/willtech
> linkedin.com/in/damianwilliamson
>
>
> m. 0487135719
> f. +61261470192
>
>
> This email does not constitute a general advice. Please disregard this email if misdelivered.
> ________________________________
> From: bitcoin-dev <bitcoin-dev-bounces at lists.linuxfoundation.org> on behalf of Daniel Edgecumbe via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
> Sent: Tuesday, 2 March 2021 12:16 PM
> To: M.K. Safi via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] Taproot NACK
>
> Any "transparency" in the blockchain, beyond that required for a participant to determine valid ownership, can only reasonably be thought of as a bug.
>
> Today I spent approximately $5 at a chip shop in North London in cash. Besides the fact that I have voluntarily chosen to share this information, it is absolutely no concern of yourself or any other party that this transaction has occured.
>
> Bitcoin is digital cash.
>
> Daniel Edgecumbe | esotericnonsense
> email at esotericnonsense.com | https://esotericnonsense.com
>
> On Mon, Mar 1, 2021, at 22:37, Eric Voskuil via bitcoin-dev wrote:
> > To be clear, is this a NACK because Taproot reduces “transparency”
> > (increases privacy) on the chain (“maintaining consensus” is obviously
> > an argument against any protocol change, so that’s a red herring)?
> >
> > And is it your theory that only an “honest” (statute abiding) person
> > should have privacy, and not against the state, and/or that mixers are
> > sufficient privacy?
> >
> > Personally, I’m not moved by such an argument. What do you think is the
> > value proposition of Bitcoin?
> >
> > e
> >
> > > On Mar 1, 2021, at 14:21, LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > >
> > >
> > > Good Afternoon,
> > >
> > > I am going to take tough terms with much of your reply and do appreciate a courteous practice. Having previously made public disclosure of my affiliation with Jambler.io it seems sufficient to disclose my affiliation through the link in my email signature block.
> > >
> > > My concern is not increased privacy it is maintaining consensus values and the transparency of the blockchain wherein all transactions are published in an immutable record and that forbids the redaction of information by any obfuscation. A separate concern is the availability of a privacy suitable for cash should a Bitcoin user desire and especially without disturbing the existing consensus.
> > >
> > > The use of a Bitcoin Mixer is to enable standard equivalent privacy. As you may experience yourself, you do not allow people to follow you around looking in your purse, suppose you are dealing entirely with cash, and to see where and how much you fill it up, and where you spend. Nonetheless, for an honest person, their wallet is available for government audit as are their financial affairs. This is consistent with the existing operation of consensus.
> > >
> > > My full email signature block is a disclosure where I have some affiliation with the referenced website being that it carries at least some information that I have provided or that in some way I am associated perhaps only making use of their services. For example, I hardly make a profit from LinkedIn just my information is there. Also, I have made previous public disclosure of the affiliation. Bitcoin Mixer 2.0 is a partner mixer run by Jambler.io wherein I receive a service referral fee and am not in receipt of any part of the process transaction. The operation block diagram provided by Jambler.io is provided here and attached.
> > > <ip.bitcointalk.org.png>
> > >
> > > [ip.bitcointalk.org.png]-Operation of Jambler.io partner mixer
> > > https://ip.bitcointalk.org/?u=https%3A%2F%2Fjambler.io%2Fimages%2Fscheme-1.png&t=622&c=gTi7r1cfh-yynw
> > > from this thread https://bitcointalk.org/index.php?topic=5267588
> > >
> > >
> > > The installation script provided by Jambler.io that is the basis of my referral website is also publicly published,
> > > https://github.com/jambler-io/bitcoin-mixer
> > >
> > > The disclosure for the partner program is available from Jambler.io however and is made prominently on my referral website. While it may seem lucrative at first I insist all partner profits are reportable on your personal income.
> > > https://jambler.io/become-partner.php
> > >
> > > I am certainly better than confident that you appreciate the difference between an open and transparent blockchain and the ability of the user to not reveal details of the content of their wallet publicly.
> > >
> > > If further clarification is required may I suggest you pay a token and mix some Bitcoin wherein our discussion may then have some point of reference.
> > >
> > > KING JAMES HRMH
> > > Great British Empire
> > >
> > > Regards,
> > > The Australian
> > > LORD HIS EXCELLENCY JAMES HRMH (& HMRH)
> > > of Hougun Manor & Glencoe & British Empire
> > > MR. Damian A. James Williamson
> > > Wills
> > >
> > > et al.
> > >
> > >
> > > Willtech
> > > www.willtech.com.au
> > > www.go-overt.com
> > > and other projects
> > >
> > > earn.com/willtech
> > > linkedin.com/in/damianwilliamson
> > >
> > >
> > > m. 0487135719
> > > f. +61261470192
> > >
> > >
> > > This email does not constitute a general advice. Please disregard this email if misdelivered.
> > > *From:* Ariel Lorenzo-Luaces <arielluaces at gmail.com>
> > > *Sent:* Monday, 1 March 2021 12:07 AM
> > > *To:* LORD HIS EXCELLENCY JAMES HRMH <willtech at live.com.au>; Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org>
> > > *Subject:* Re: [bitcoin-dev] Taproot NACK
> > >
> > > Hello LORD HIS EXCELLENCY JAMES HRMH
> > >
> > > I find a striking dichotomy between your concern of increased privacy in bitcoin and your link to a bitcoin mixer in your signature www.go-overt.com
> > >
> > > At first your concerns seemed genuine but after seeing your promotion of a bitcoin mixer I'm thinking your concerns may be more profit motivated? I can't tell since you failed to disclose your relationship with the mixer.
> > >
> > > Could you please clarify your association with the bitcoin mixer and moving forward could you please always do proper disclosure any time you're publically talking about bitcoin transaction privacy. It's only fair to do so as to not mislead people in an attempt to manipulate at worst and just a courteous practice at best.
> > >
> > > Cheers
> > > Ariel Lorenzo-Luaces
> > > On Feb 28, 2021, at 4:36 AM, LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > >> Good Evening,
> > >>
> > >> Thank-you for your advice @JeremyRubin <https://twitter.com/JeremyRubin>; on the basis you advise, "Taproot does not enable monero-like privacy features", I am prepred to withdraw my NACK notably that the existing feeatures of Bitcoin MUST be maintained, and whereby the UTXO of a transaction is identifiable, the PayTo Address, and the amount all without any obfuscation.
> > >>
> > >> Lightning does not really provide obfuscation, it provides a result of a subset of transactions although the operation of the channel is observable to the parties.
> > >>
> > >> The reports I were reading concerning the supposed operation of Taproot published in a public media channel may have been speculation or misinformation nonetheless it is prudent to conditionally reply as you see that I have. It is important not to allow things to slip through the cracks. As you may believe may astute reviewers could make a full disclosure to this list it is not to be expected.
> > >>
> > >> KING JAMES HRMH
> > >> Great British Empire
> > >>
> > >> Regards,
> > >> The Australian
> > >> LORD HIS EXCELLENCY JAMES HRMH (& HMRH)
> > >> of Hougun Manor & Glencoe & British Empire
> > >> MR. Damian A. James Williamson
> > >> Wills
> > >>
> > >> et al.
> > >>
> > >>
> > >> Willtech
> > >> www.willtech.com.au
> > >> www.go-overt.com
> > >> and other projects
> > >>
> > >> earn.com/willtech
> > >> linkedin.com/in/damianwilliamson
> > >>
> > >>
> > >> m. 0487135719
> > >> f. +61261470192
> > >>
> > >>
> > >> This email does not constitute a general advice. Please disregard this email if misdelivered.
> > >> *From:* Jeremy <jlrubin at mit.edu>
> > >> *Sent:* Sunday, 28 February 2021 3:14 AM
> > >> *To:* LORD HIS EXCELLENCY JAMES HRMH <willtech at live.com.au>; Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org>
> > >> *Subject:* Re: [bitcoin-dev] Taproot NACK
> > >>
> > >> I have good news for you: Taproot does not enable monero-like privacy features any moreso than already exist in Bitcoin today. At its core, taproot is a way to make transactions with embedded smart contracts less expensive, done so in a manner that may marginally improve privacy dependent on user behavior (but not in the monero-like way you mention). For example, it makes it possible for lightning channels to look structurally similar to single key wallets, but it does nothing inherently to obfuscate the transaction graph as in monero.
> > >>
> > >> Such "monero-like" transaction graph obfuscation may already exist in Bitcoin via other techniques (coinjoin, payjoin, coinswap, lightning, etc) with or without Taproot, so the point is further moot.
> > >>
> > >> Do you have a source on your reporting?
> > >>
> > >> You may wish to rescind your nack.
> > >>
> > >>
> > >> --
> > >> @JeremyRubin <https://twitter.com/JeremyRubin>; <https://twitter.com/JeremyRubin>;
> > >>
> > >>
> > >> On Sat, Feb 27, 2021 at 5:46 AM LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev < bitcoin-dev at lists.linuxfoundation.org> wrote:
> > >>> Good Afternoon,
> > >>>
> > >>> It has been reported that Taproot will enable some Monero like features including the ability to hide transactions.
> > >>>
> > >>> If that is the case I offer a full NACK and let me explain.
> > >>>
> > >>> A part of the benefit of using Bitcoin is its honesty. The full transaction is published on the blockchain. If that were to change so that transactions may be obfuscated from scrutiny then any government would have unlimited impetus to ban Bitcoin, and speculation has that is the reason India has been reported to have banned cryptocurrencies already.
> > >>>
> > >>> I am in support of the expanded use case of Bitcoin without harming the established robust fairness and equal equity offered. The core functionality of Bitcoin, its values, must remain unaltered.
> > >>>
> > >>> KING JAMES HRMH
> > >>> Great British Empire
> > >>>
> > >>> Regards,
> > >>> The Australian
> > >>> LORD HIS EXCELLENCY JAMES HRMH (& HMRH)
> > >>> of Hougun Manor & Glencoe & British Empire
> > >>> MR. Damian A. James Williamson
> > >>> Wills
> > >>>
> > >>> et al.
> > >>>
> > >>>
> > >>> Willtech
> > >>> www.willtech.com.au
> > >>> www.go-overt.com
> > >>> and other projects
> > >>>
> > >>> earn.com/willtech
> > >>> linkedin.com/in/damianwilliamson
> > >>>
> > >>>
> > >>> m. 0487135719
> > >>> f. +61261470192
> > >>>
> > >>>
> > >>> This email does not constitute a general advice. Please disregard this email if misdelivered.
> > >>> _______________________________________________
> > >>> bitcoin-dev mailing list
> > >>> bitcoin-dev at lists.linuxfoundation.org
> > >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > >>
> > >> bitcoin-dev mailing list
> > >> bitcoin-dev at lists.linuxfoundation.org
> > >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > > <ip.bitcointalk.org.png>
> > > _______________________________________________
> > > bitcoin-dev mailing list
> > > bitcoin-dev at lists.linuxfoundation.org
> > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

📅 Original date posted:2018-09-11 📝 Original message:- ...

2023-06-07T20:14:30+02:00

In reply to nevent1q…6y6y
_________________________

📅 Original date posted:2018-09-11
📝 Original message:- Musig, by being M of M, is inherently prone to loss.

- Having the senders of the G*x pubkey shares sign their messages with the
associated private key share should be sufficient to prevent them from
using wagner's algorithm to attack the combined key. Likewise, the G*k
nonce fragments should also be signed with the pubkey shares.

On Tue, Sep 11, 2018 at 1:27 PM Gregory Maxwell <greg at xiph.org> wrote:

> On Tue, Sep 11, 2018 at 5:20 PM Erik Aronesty <erik at q32.com> wrote:
> > The security advantages of a redistributable threshold system are huge.
> If a system isn't redistributable, then a single lost or compromised key
> results in lost coins... meaning the system is essetntially unusable.
> >
> > I'm actually worried that Bitcoin releases a multisig that encourages
> loss.
>
> There is no "non- edistributiable multisig" proposed for Bitcoin
> anywhere that I am aware of.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180911/d39149db/attachment.html>;

📅 Original date posted:2018-09-13 📝 Original message:The ...

2023-06-07T20:14:30+02:00

In reply to nevent1q…3xks
_________________________

📅 Original date posted:2018-09-13
📝 Original message:The paper refers to either:

a) building up threshold signatures via concatenation, or. implicitly -
in Bitcoin -
b) by indicating that of M of N are valid, and requiring a validator to
validate one of the permutations of M that signed - as opposed to a scheme,
like a polynomial function, where the threshold is built in to the system.

Maybe there's another mechanism in there that I'm not aware of - because
it's just too simple to mention?

- Erik

On Thu, Sep 13, 2018 at 2:46 PM Andrew Poelstra <apoelstra at wpsoftware.net>
wrote:

> On Tue, Sep 11, 2018 at 01:37:59PM -0400, Erik Aronesty via bitcoin-dev
> wrote:
> > - Musig, by being M of M, is inherently prone to loss.
> >
>
> It has always been possible to create M-of-N threshold MuSig signatures
> for any
> M, N with 0 < M ≤ N. This is (a) obvious, (b) in our paper, (c)
> implemented at
>
>
> https://github.com/apoelstra/secp256k1/blob/2018-04-taproot/src/modules/musig/main_impl.h
>
> --
> Andrew Poelstra
> Research Director, Mathematics Department, Blockstream
> Email: apoelstra at wpsoftware.net
> Web: https://www.wpsoftware.net/andrew
>
> "Make it stop, my love; we were wrong to try
> Never saw what we could unravel in traveling light
> Nor how the trip debrides like a stack of slides
> All we saw was that time is taller than space is wide"
> --Joanna Newsom
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180913/88497b38/attachment.html>;

📅 Original date posted:2018-09-11 📝 Original message:Greg, ...

2023-06-07T20:14:29+02:00

In reply to nevent1q…zk4e
_________________________

📅 Original date posted:2018-09-11
📝 Original message:Greg,

I added, stripped out, and added analogous musig delinearization 3 times in
response to stuff posted here. I'm adding it back now. Not sure why my
head is thick around that issue.

The security advantages of a redistributable threshold system are huge.
If a system isn't redistributable, then a single lost or compromised key
results in lost coins... meaning the system is essetntially unusable.

I'm actually worried that Bitcoin releases a multisig that encourages loss.

On Tue, Sep 11, 2018 at 1:00 PM Gregory Maxwell <greg at xiph.org> wrote:

> On Tue, Sep 11, 2018 at 4:34 PM Erik Aronesty <erik at q32.com> wrote:
>
>> To answer points:
>>
>> - I switched to the medium article so that I could correct, edit and
>> improve things to make them more clear.
>> - I responded to feedback by modifying the protocol to make it work - not
>> by ignoring it.
>>
>
> To this moment there remains no response at your post.
> https://bitcointalk.org/index.php?topic=4973123.0
>
> I'm not sure how I am supposted to have figured out that you wrote a
> somewhat different repost of it elsewhere...
>
> - An M-1 rogue-key attack would require the attacker would to either
>>
>> - attack the hash function to produce a predictable R based on a known
>> mesage
>> - attack the DLP to influence x or k
>>
>> Neither attack gives any particular advantage to someone who has M-1 keys.
>>
>
> You keep asserting this. It isn't true. Asserting it more does not make it
> any more true. I already explained how to attack this style of signature
> (e.g. in the BCT thread).
>
> Set aside your 'interpolation' for a moment, and imagine that you
> construct a 2 of 2 signature by just adding the keys. Your tell me your
> key, P1 and then I tell you that my key P2 which I derived by computing
> -P1 + xG. We now compute P = P1 + P2 = P1 + -P1 + xG = xG ... and now in
> spite adding P1 with an unknown discrete log, I know the discrete log of P
> with respect to G and I did not need to violate the standard DL security
> assumption to achieve that.
>
> With the 'interpolation' in effect the same attack applies but its
> execution is somewhat more complex: instead of adding the negation of P1 I
> must add a number of multiplicities of P1 (like P1*2, P1*3, P1*4...)
> selected so that their interpolation coefficients add up to -1. Finding a
> suitable subset requires solving a randomized modular subset sum problem
> and Wagner's algorithm provides a computationally tractable solution to it.
>
> The potential of rogue keys applies to both the keys themselves and to the
> nonces. There are several ways to prevent these attacks, the musig paper
> describes a delinearization technique which doesn't require additional
> interaction or communication.
>
> I haven't tested whether the R,s version is susceptible though.
>>
>
> There is a perfect bijection between the two encodings which is easily
> computable, so they're the same thing from an abstract security perspective.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180911/1dad3a33/attachment.html>;

📅 Original date posted:2018-09-05 📝 Original ...

2023-06-07T20:14:28+02:00

In reply to nevent1q…88vr
_________________________

📅 Original date posted:2018-09-05
📝 Original message:Correct, there is an interaction step to deduce G*k, when signing, each
participant has to publishes G*ki. I didn't talk about it. That doesn't
break it, but you're correct, it's not non-interactive.

On Wed, Sep 5, 2018 at 9:06 AM Andrew Poelstra <apoelstra at wpsoftware.net>
wrote:

> On Wed, Sep 05, 2018 at 08:26:14AM -0400, Erik Aronesty wrote:
> > Why would you call it FUD? All the weird hemming and hawing about it is
> > really strange to me. The more I look into it and speak to professors
> > about i, the more it seems "so trivial nobody really talks about it".
> >
> > 1. Generate an M of N shared public key (done in advance of signing ....
> > this gets you the bitcoin address)
> > 2. Generate signature fragments (this can be done offline, with no
> > communication between participants)
> >
> > Detailed explanation with code snippets:
> >
> >
> https://medium.com/@simulx/an-m-of-n-bitcoin-multisig-scheme-e7860ab34e7f
> >
>
> The hemming and hawing is because you've been repeatedly told that your
> scheme doesn't work, and to please implement it in some computer algebra
> system so that you can see that (or so we can see where your mistake is),
> and you instead continue to post incomplete/incoherent copies of the same
> thing across multiple mediums - Reddit, this list, Bitcointalk, Medium,
> etc ad nauseum.
>
> It's distracting and offensive to people who have spent a lot of time and
> energy thinking about this stuff, and more importantly it causes confusion
> in the public eye. Phrasings like "weird hemming and hawing" suggest that
> we don't know/don't care about some insight you have, which is not true.
> This is why your posts are FUD.
>
> For example, in your linked post I looked at every single instance of the
> character 'k' and *not one of them* defined the value 'k' from which 'R'
> is derived in the signing procedure.
>
>
> Of course there is no possible value, individual signers cannot learn 'R'
> at signing time without interaction, and your whole scheme is broken. Given
> the number of times you've been told this, I find it hard to believe that
> this was an honest mistake.
>
>
>
> Andrew
>
>
>
> --
> Andrew Poelstra
> Research Director, Mathematics Department, Blockstream
> Email: apoelstra at wpsoftware.net
> Web: https://www.wpsoftware.net/andrew
>
> "Make it stop, my love; we were wrong to try
> Never saw what we could unravel in traveling light
> Nor how the trip debrides like a stack of slides
> All we saw was that time is taller than space is wide"
> --Joanna Newsom
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180905/c737fbbf/attachment-0001.html>;

📅 Original date posted:2018-09-11 📝 Original message:To ...

2023-06-07T20:14:28+02:00

In reply to nevent1q…f2ky
_________________________

📅 Original date posted:2018-09-11
📝 Original message:To answer points:

- I switched to the medium article so that I could correct, edit and
improve things to make them more clear.
- I responded to feedback by modifying the protocol to make it work - not
by ignoring it.
- I coded it up in python so I could be sure it worked, because I was
concerned that it was broken
- Yes, coding it up showed me that it's definitely interactive, and no
different than a "standard shnorr sig" in any meaningful way regarding the
security
- No special protocol support is needed over Schnorr signing itself. The
e, s version can be made at least as secure as schnorr + DLP. I haven't
researched the R,s version.
- An M-1 rogue-key attack would require the attacker would to either

- attack the hash function to produce a predictable R based on a known
mesage
- attack the DLP to influence x or k

Neither attack gives any particular advantage to someone who has M-1 keys.

I haven't tested whether the R,s version is susceptible though.

On Thu, Sep 6, 2018 at 9:15 AM Gregory Maxwell via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> On Wed, Sep 5, 2018 at 1:49 PM Erik Aronesty via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > Detailed explanation with code snippets:
> >
> > https://medium.com/@simulx/an-m-of-n-bitcoin-multisig-scheme-[snip]
>
> This appears to be a repost of the broken scheme you posted about on
> Bitcointalk, but then failed to respond to the response.
>
> https://bitcointalk.org/index.php?topic=4973123.0
>
> > The more I look into it and speak to professors about i, the more it
> seems "so trivial nobody really talks about it".
>
> I think you might be falling into the trap of ignoring feedback you
> don't like and and accepting that which sounds like "yea yea,
> something like that".
>
> Something "like that" does work: and is expressly and explicitly
> anticipated by the BIP but to be both secure and functional requires
> proper delineation (E.g. musig) _and_ interaction. What you're
> proposing is continually vague. My best efforts at making sense of
> what you've written indicate that either it's non-interactive and
> not-actually functional at all, OR it's interactive and just a less
> secure subset (no proper delinearization to prevent rogue key attacks)
> of what we already propose.
>
> When Poelstra suggests a CAS implementation he means something like
> this Sage notebook: http://bitcoin.ninja/secp256k1.ecdsa.sage This
> provides for a method of communicating in both directions which is
> completely precise.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180911/20ed54de/attachment-0001.html>;

📅 Original date posted:2018-09-05 📝 Original message:Why ...

2023-06-07T20:14:27+02:00

In reply to nevent1q…jczq
_________________________

📅 Original date posted:2018-09-05
📝 Original message:Why would you call it FUD? All the weird hemming and hawing about it is
really strange to me. The more I look into it and speak to professors
about i, the more it seems "so trivial nobody really talks about it".

1. Generate an M of N shared public key (done in advance of signing ....
this gets you the bitcoin address)
2. Generate signature fragments (this can be done offline, with no
communication between participants)

Detailed explanation with code snippets:

https://medium.com/@simulx/an-m-of-n-bitcoin-multisig-scheme-e7860ab34e7f

On Sun, Sep 2, 2018 at 8:05 PM Andrew Poelstra <apoelstra at wpsoftware.net>
wrote:

> On Wed, Aug 29, 2018 at 08:09:36AM -0400, Erik Aronesty wrote:
> > Note:
> >
> > This spec cannot be used directly with a shamir scheme to produce
> > single-round threshold multisigs, because shares of point R would need to
> > be broadcast to share participants in order to produce valid single
> > signatures.
> >
> > (R, s) schemes can still be used "online", if share participants publish
> > the R(share).... but, not sure if it matter much, this choice eliminates
> > offline multiparty signing in exchange for batch validation.
> >
>
> Please stop with this FUD. No tradeoff was made. There are no
> non-interactive
> Schnorr signatures.
>
>
> Andrew
>
>
> --
> Andrew Poelstra
> Mathematics Department, Blockstream
> Email: apoelstra at wpsoftware.net
> Web: https://www.wpsoftware.net/andrew
>
> "A goose alone, I suppose, can know the loneliness of geese
> who can never find their peace,
> whether north or south or west or east"
> --Joanna Newsom
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180905/c41fdcc4/attachment-0001.html>;

📅 Original date posted:2018-07-09 📝 Original ...

2023-06-07T20:13:41+02:00

In reply to nevent1q…w5lj
_________________________

📅 Original date posted:2018-07-09
📝 Original message:Because it's non-interactive, this construction can produce multisig
signatures offline. Each device produces a signature using it's own
k-share and x-share. It's only necessary to interpolate M of n shares.

There are no round trips.

The security is Shamir + discrete log.

it's just something I've been tinkering with and I can't see an obvious
problem.

It's basically the same as schnorr, but you use a threshold hash to fix the
need to be online.

Just seems more useful to me.

On Sun, Jul 8, 2018, 10:33 PM Pieter Wuille <pieter.wuille at gmail.com> wrote:

> On Sun, Jul 8, 2018, 19:23 Erik Aronesty via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Pretty sure these non interactive sigs are more secure.
>>
>
> Schnorr signatures are provably secure in the random oracle model assuming
> the discrete logarithm problem is hard in the used group.
>
> What does "more secure" mean? Is your construction secure with weaker
> assumptions?
>
> --
> Pieter
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180709/364d4561/attachment.html>;

📅 Original date posted:2018-07-09 📝 Original ...

2023-06-07T20:13:41+02:00

In reply to nevent1q…mfqa
_________________________

📅 Original date posted:2018-07-09
📝 Original message:Actually, it looks like in order to compute a multiparty signature you will
need to broadcast shares of r first, so it's not offline :(

It is still seems, to me, to be a simpler mechanism than musig - with
security assumptions that match the original Schnorr construction more
closely, and should therefore be easier to prove secure in a multiparty
context.

Shamir/Schnorr threshold multi-signature scheme:

Each party:

- Has a public key g*x', where x' is their private key, and where H(g*x)
can be considered their public index for the purposes of Shamir polynomial
interpolation
- Rolls a random k' and compute r' = g*k'
- Broadcast r' as a share
- Computes g*k, via lagrange interpolation across shares. At this point k
is not known to any party unless Shamir is vulnerable or DL is not hard
- Computes e' = H(M) * r'
- Computes s' = k'-x*e'
- Share of signature is (s', e')

Verification is the same as Scnhorr, but only after using interpolation to
get the needed (s, e, g*x) from shares of s', e' and g*x':

- Using lagrange interpolation, compute the public key g*x
- Again, using lagrange interpolation, compute (s, e)
- Verify the signature as per standard Schnorr

Security assumptions:

- Because this is not additive, and instead we are using Shamir
combination, the additional blinding and masking steps of musig are not
needed to create a secure scheme.
- The scheme is the same as Schnorr otherwise
- The only thing to prove is that H(M) * r does not reveal any information
about k ... which relies on the same DL assumptions as Bitcoin itself
- Overall, this seems, to me at least, to have a smaller attack surface
because there's fewer moving parts

On Mon, Jul 9, 2018 at 8:24 AM, Erik Aronesty <erik at q32.com> wrote:

> I was hoping that nobody in this group saw an obvious problem with it then
> I'd sit down and try to write up a paper.
>
> Not that hard to just reuse the work done on schnorr. And demonstrate
> that there are no additional assumptions.
>
> On Mon, Jul 9, 2018, 12:40 AM Pieter Wuille <pieter.wuille at gmail.com>
> wrote:
>
>> On Sun, Jul 8, 2018, 21:29 Erik Aronesty <erik at q32.com> wrote:
>>
>>> Because it's non-interactive, this construction can produce multisig
>>> signatures offline. Each device produces a signature using it's own
>>> k-share and x-share. It's only necessary to interpolate M of n shares.
>>>
>>> There are no round trips.
>>>
>>> The security is Shamir + discrete log.
>>>
>>> it's just something I've been tinkering with and I can't see an obvious
>>> problem.
>>>
>>> It's basically the same as schnorr, but you use a threshold hash to fix
>>> the need to be online.
>>>
>>> Just seems more useful to me.
>>>
>>
>> That sounds very useful if true, but I don't think we should include
>> novel cryptography in Bitcoin based on your not seeing an obvious problem
>> with it.
>>
>> I'm looking forward to seeing a more complete writeup though.
>>
>> Cheers,
>>
>> --
>> Pieter
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180709/0f0198c0/attachment.html>;

📅 Original date posted:2018-07-08 📝 Original message:Pretty ...

2023-06-07T20:13:40+02:00

In reply to nevent1q…eagm
_________________________

📅 Original date posted:2018-07-08
📝 Original message:Pretty sure these non interactive sigs are more secure.

On Sun, Jul 8, 2018, 5:02 PM Gregory Maxwell via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> On Sun, Jul 8, 2018 at 3:16 PM, Tim Ruffing via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > so what
> > you want is possible already with Schnorr signatures.
>
> As also described in "Multisignatures and Threshold Signatures" in the BIP.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180708/c768e8bd/attachment-0001.html>;

📅 Original date posted:2018-07-08 📝 Original message:You ...

2023-06-07T20:13:40+02:00

In reply to nevent1q…6l8g
_________________________

📅 Original date posted:2018-07-08
📝 Original message:You don't have to treat the hash as a group member for the purposes of
signing.

Everything else about the algorithm works the same.

This just enables signatures to be computed much more simply.

On Sun, Jul 8, 2018, 11:32 AM Tim Ruffing via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Hi Erik,
>
> On Sun, 2018-07-08 at 10:19 -0400, Erik Aronesty via bitcoin-dev wrote:
> > Consider changing the "e" term in the schnorr algorithm to hash of
> > message (elligator style) to the power of r, rather than using
> > concatenation.
>
> How do you compute s = x*e if e is an element of group G?
> (Similar question: How do you verify if e is element of G?)
>
> Are you aware of
> http://cacr.uwaterloo.ca/techreports/2001/corr2001-13.ps ?
> This is a threshold signature scheme for Schnorr signatures, so what
> you want is possible already with Schnorr signatures.
>
> Best,
> Tim
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180708/d7a9e8b4/attachment-0001.html>;

📅 Original date posted:2018-07-08 📝 Original message:To ...

2023-06-07T20:13:39+02:00

In reply to nevent1q…8ly4
_________________________

📅 Original date posted:2018-07-08
📝 Original message:To save space, start with the wiki terminology on schnorr sigs.

Consider changing the "e" term in the schnorr algorithm to hash of message
(elligator style) to the power of r, rather than using concatenation.

I don't think this changes the security. An attacker would need to know k
to either way to compromise the private key.

This would allow m of n devices to sign a transaction without any of them
knowing a private key at all.

IE: each device can roll a random number as a share and the interpolation
of that is the private key.

The public shares can be broadcast and combines. And signature shares can
be broadcast and combined.

The net result of this is it really possible for an arbitrary set of
devices to create a perfectly secure public-private key pair set.

At no point was the private key anywhere.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180708/cbdf80dd/attachment.html>;

📅 Original date posted:2017-08-22 📝 Original message:> ...

2023-06-07T20:04:56+02:00

In reply to nevent1q…ypf6
_________________________

📅 Original date posted:2017-08-22
📝 Original message:> The initial message I replied to stated:

Yes, 3 years is silly. But coin expiration and quantum resistance is
something I've been thinking about for a while, so I tried to steer the
conversation away from stealing old money for no reason ;). Plus I like
the idea of making Bitcoin "2000 year proof".

- I cannot imagine either SHA256 or any of our existing wallet formats
surviving 200 years, if we expect both moores law and quantum computing to
be a thing. I would expect the PoW to be rendered obsolete before the
Bitcoin addresses.

- A PoW change using Keccak and a flexible number of bits can be designed
as a "future hard fork". That is: the existing POW can be automatically
rendered obsolete... but only in the event that difficulty rises to the
level of obsolescence. Then the code for a new algorithm with a flexible
number of bits and a difficulty that can scale for thousands of years can
then automatically kick in.

- A new addresses format and signing protocols that use a flexible number
of bits can be introduced. The maximum number of supported bits can be
configurable, and trivially changed. These can be made immediately
available but completely optional.

- The POW difficulty can be used to inform the expiration of any addresses
that can be compromised within 5 years assuming this power was somehow used
to compromise them. Some mechanism for translating global hashpower to
brute force attack power can be researched, and consesrvative estimates
made. Right now, it's like "heat death of the universe" amount of time to
crack with every machine on the planet. But hey... things change and 2000
years is a long time. This information can be used to inform the
expiration and reclamation of old, compromised public addresses.

- Planning a hard fork 100 to 1000 years out is a fun exercise

On Tue, Aug 22, 2017 at 2:55 PM, Chris Riley <criley at gmail.com> wrote:

> The initial message I replied to stated in part, "Okay so I quite like
> this idea. If we start removing at height 630000 or 840000 (gives us 4-8
> years to develop this solution), it stays nice and neat with the halving
> interval...."
>
> That is less than 3 years or less than 7 years away. Much sooner than it
> is believed QC or Moore's law could impact bitcoin. Changing bitcoin so as
> to require that early coins start getting "scavenged" at that date seems
> unneeded and irresponsible. Besides, your ECDSA is only revealed when you
> spend the coins which does provide some quantum resistance. Hal was just
> an example of people putting their coins away expecting them to be there at
> X years in the future, whether it is for himself or for his kids and wife.
>
> :-)
>
>
>
> On Tue, Aug 22, 2017 at 1:33 PM, Matthew Beton <matthew.beton at gmail.com>
> wrote:
>
>> Very true, if Moore's law is still functional in 200 years, computers
>> will be 2^100 times faster (possibly more if quantum computing becomes
>> commonplace), and so old wallets may be easily cracked.
>>
>> We will need a way to force people to use newer, higher security wallets,
>> and turning coins to mining rewards is better solution than them just being
>> hacked.
>>
>> On Tue, 22 Aug 2017, 7:24 pm Thomas Guyot-Sionnest <dermoth at aei.ca>
>> wrote:
>>
>>> In any case when Hal Finney do not wake up from his 200years
>>> cryo-preservation (because unfortunately for him 200 years earlier they did
>>> not know how to preserve a body well enough to resurrect it) he would find
>>> that advance in computer technology made it trivial for anyone to steal his
>>> coins using the long-obsolete secp256k1 ec curve (which was done long
>>> before, as soon as it became profitable to crack down the huge stash of
>>> coins stale in the early blocks)
>>>
>>> I just don't get that argument that you can't be "your own bank". The
>>> only requirement coming from this would be to move your coins about once
>>> every 10 years or so, which you should be able to do if you have your
>>> private keys (you should!). You say it may be something to consider when
>>> computer breakthroughs makes old outputs vulnerable, but I say it's not
>>> "if" but "when" it happens, and by telling firsthand people that their
>>> coins requires moving every once in a long while you ensure they won't do
>>> stupid things or come back 50 years from now and complain their addresses
>>> have been scavenged.
>>>
>>> --
>>> Thomas
>>>
>>>
>>> On 22/08/17 10:29 AM, Erik Aronesty via bitcoin-dev wrote:
>>>
>>> I agree, it is only a good idea in the event of a quantum computing
>>> threat to the security of Bitcoin.
>>>
>>> On Tue, Aug 22, 2017 at 9:45 AM, Chris Riley via bitcoin-dev <
>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>>> This seems to be drifting off into alt-coin discussion. The idea that
>>>> we can change the rules and steal coins at a later date because they are
>>>> "stale" or someone is "hoarding" is antithetical to one of the points of
>>>> bitcoin in that you can no longer control your own money ("be your own
>>>> bank") because someone can at a later date take your coins for some reason
>>>> that is outside your control and solely based on some rationalization by a
>>>> third party. Once the rule is established that there are valid reasons why
>>>> someone should not have control of their own bitcoins, what other reasons
>>>> will then be determined to be valid?
>>>>
>>>> I can imagine Hal Finney being revived (he was cryo-preserved at Alcor
>>>> if you aren't aware) after 100 or 200 years expecting his coins to be there
>>>> only to find out that his coins were deemed "stale" so were "reclaimed" (in
>>>> the current doublespeak - e.g. stolen or confiscated). Or perhaps he
>>>> locked some for his children and they are found to be "stale" before they
>>>> are available. He said in March 2013, "I think they're safe enough" stored
>>>> in a paper wallet. Perhaps any remaining coins are no longer "safe enough."
>>>>
>>>> Again, this seems (a) more about an alt-coin/bitcoin fork or (b) better
>>>> in bitcoin-discuss at best vs bitcoin-dev. I've seen it discussed many
>>>> times since 2010 and still do not agree with the rational that embracing
>>>> allowing someone to steal someone else's coins for any reason is a useful
>>>> change to bitcoin.
>>>>
>>>>
>>>>
>>>>
>>>> On Tue, Aug 22, 2017 at 4:19 AM, Matthew Beton via bitcoin-dev <
>>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>>
>>>>> Okay so I quite like this idea. If we start removing at height 630000
>>>>> or 840000 (gives us 4-8 years to develop this solution), it stays nice and
>>>>> neat with the halving interval. We can look at this like so:
>>>>>
>>>>> B - the current block number
>>>>> P - how many blocks behind current the coin burning block is. (630000,
>>>>> 840000, or otherwise.)
>>>>>
>>>>> Every time we mine a new block, we go to block (B-P), and check for
>>>>> stale coins. These coins get burnt up and pooled into block B's miner fees.
>>>>> This keeps the mining rewards up in the long term, people are less likely
>>>>> to stop mining due to too low fees. It also encourages people to keep
>>>>> moving their money around the enconomy instead of just hording and leaving
>>>>> it.
>>>>>
>>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170822/7866f6f9/attachment.html>;

📅 Original date posted:2017-08-22 📝 Original message:I ...

2023-06-07T20:04:54+02:00

In reply to nevent1q…nee2
_________________________

📅 Original date posted:2017-08-22
📝 Original message:I agree, it is only a good idea in the event of a quantum computing threat
to the security of Bitcoin.

On Tue, Aug 22, 2017 at 9:45 AM, Chris Riley via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> This seems to be drifting off into alt-coin discussion. The idea that we
> can change the rules and steal coins at a later date because they are
> "stale" or someone is "hoarding" is antithetical to one of the points of
> bitcoin in that you can no longer control your own money ("be your own
> bank") because someone can at a later date take your coins for some reason
> that is outside your control and solely based on some rationalization by a
> third party. Once the rule is established that there are valid reasons why
> someone should not have control of their own bitcoins, what other reasons
> will then be determined to be valid?
>
> I can imagine Hal Finney being revived (he was cryo-preserved at Alcor if
> you aren't aware) after 100 or 200 years expecting his coins to be there
> only to find out that his coins were deemed "stale" so were "reclaimed" (in
> the current doublespeak - e.g. stolen or confiscated). Or perhaps he
> locked some for his children and they are found to be "stale" before they
> are available. He said in March 2013, "I think they're safe enough" stored
> in a paper wallet. Perhaps any remaining coins are no longer "safe enough."
>
> Again, this seems (a) more about an alt-coin/bitcoin fork or (b) better in
> bitcoin-discuss at best vs bitcoin-dev. I've seen it discussed many times
> since 2010 and still do not agree with the rational that embracing allowing
> someone to steal someone else's coins for any reason is a useful change to
> bitcoin.
>
>
>
>
> On Tue, Aug 22, 2017 at 4:19 AM, Matthew Beton via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Okay so I quite like this idea. If we start removing at height 630000 or
>> 840000 (gives us 4-8 years to develop this solution), it stays nice and
>> neat with the halving interval. We can look at this like so:
>>
>> B - the current block number
>> P - how many blocks behind current the coin burning block is. (630000,
>> 840000, or otherwise.)
>>
>> Every time we mine a new block, we go to block (B-P), and check for stale
>> coins. These coins get burnt up and pooled into block B's miner fees. This
>> keeps the mining rewards up in the long term, people are less likely to
>> stop mining due to too low fees. It also encourages people to keep moving
>> their money around the enconomy instead of just hording and leaving it.
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170822/f68d99c8/attachment.html>;

📅 Original date posted:2017-08-21 📝 Original message:1. If ...

2023-06-07T20:04:53+02:00

In reply to nevent1q…t2mh
_________________________

📅 Original date posted:2017-08-21
📝 Original message:1. If it only affects "old dust" UTXO's where the # of coins in the UTXO
aren't sufficient to pay some lower quantile of transaction fees, then
there can be little argument of theft or loss.

2. There's another use-case for demurrage as well.

Computation power may grow rapidly if quantum computing becomes more
common. At some point, Bitcoin may have to change the public key format
for coins and the POW used.

In order to do this, old coins will have to transact on the network, moving
their value to a new format, with many more bits in the public key, for
example. But since quantum computing isn't bounded by moore's law, so
this may need to be a regular upgrade every X years. Rather than a
regular "bit widening hard fork", the number of bits needed in a public
address format could be scaled to the difficulty of the new quantum hashing
algorithm that *also must *now grow in the # of bits over time. To ensure
that coins are secure, those with too few bits must drop off the network.
So the timing for old coin demurrage can effectively be based on the
quantum POW difficulty adjustments. As long as the subsequent exponential
rate of computation increase can be reasonably predicted (quantum version
of moore's law), the new rate of decay can be pegged to a number of years.

On Mon, Aug 21, 2017 at 10:26 AM, Moral Agent via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> A more forgiving option would be to have coins past a certain age
> evaporate into mining rewards at some rate, rather than all at once. People
> might find this approach easier to stomach as it avoids the "I waited 1
> block to many and all of my coins vanished" scenario.
>
> Another approach would to demand that a certain minimum mining fee be
> included that is calculated based on the age of an input like this idea:
> https://www.reddit.com/r/Bitcoin/comments/35ilir/
> prioritizing_utxos_using_a_minimum_mining_fee/
>
> This would result in the coins continuing to exist but not being
> economically spendable, and therefore the UTXO information could be
> archived.
>
> On Mon, Aug 21, 2017 at 9:35 AM, Thomas Guyot-Sionnest via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> On 21/07/17 03:59 PM, Lucas Clemente Vella via bitcoin-dev wrote:
>> > 2017-07-21 16:28 GMT-03:00 Major Kusanagi via bitcoin-dev
>> > <bitcoin-dev at lists.linuxfoundation.org
>> > <mailto:bitcoin-dev at lists.linuxfoundation.org>>:
>> >
>> > [...] But the fact is that if we want to make bitcoins last forever,
>> > we have the accept unbounded UTXO growth, which is unscalable. So
>> > the only solution is to limit UTXO growth, meaning bitcoins cannot
>> > last forever. This proposed solution however does not prevent
>> > Bitcoin from lasting forever.
>> >
>> >
>> > Unless there is a logical contradiction in this phrasing, the proposed
>> > solution does not improves scalability:
>> > - "Bitcoins lasting forever" implies "unscalable";
>> > - "not prevent Bitcoin from lasting forever" implies "Bitcoins lasting
>> > forever";
>> > - Thus: "not prevent Bitcoin from lasting forever" implies
>> "unscalable".
>> >
>> > In practice, the only Bitcoin lost would be those whose owners forgot
>> > about or has lost the keys, because everyone with a significant amount
>> > of Bitcoins would always shift them around before it loses any luster (I
>> > wouldn't bother to move my Bitcoins every 10 years). I don't know how to
>> > estimate the percentage of UTXO is actually lost/forgotten, but I have
>> > the opinion it isn't worth the hassle.
>> >
>> > As a side note, your estimate talks about block size, which is
>> > determines blockchain size, which can be "safely" pruned (if you are not
>> > considering new nodes might want to join the network, in case the full
>> > history is needed to be stored somewhere). But UTXO size, albeit related
>> > to the full blockchain size, is the part that currently can not be
>> > safely pruned, so I don't see the relevance of the analysis.
>>
>> I think if we wanted to burn lost/stale coins a better approach would be
>> returning them to miner's as a fee - there will always be lost coins and
>> miners will be able to get that additional revenue stream as the mining
>> reward halves. I also don't think we need to worry about doing a gradual
>> value loss neither, we should just put a limit on UTXO age in block
>> count (actually I would round it up to 210k blocks as explained below...).
>>
>>
>> So lets say for example we decide to keep 5 210k blocks "generations"
>> (that's over 15 years), then on the first block of the 6th generation
>> all UTXO's from the 1st generation are invalidated and returned into a
>> "pool".
>>
>> Given these (values in satoshis):
>>
>> Pool "P" (invalided UTXO minus total value reclaimed since last halving)
>> Leftover blocks "B" (210,000 minus blocks mined since last halving)
>>
>> Then every mined block can reclaim FLOOR(P/B) satoshi in addition to
>> miner's reward and tx fees.
>>
>> If the last block of a generation does not get the remainder of the pool
>> (FLOOR(P/1) == P) it should get carried over.
>>
>>
>> This would ensure we can clear old blocks after a few generations and
>> that burnt/lost coins eventually get back in circulation. Also it would
>> reduce the reliance of miners on actual TX fees.
>>
>>
>> To avoid excessive miner reward initially, for the first few iterations
>> the value of B could be increased (I haven't calculated the UTXO size of
>> the first 210k blocks but it could be excessively high...) or the value
>> each block can reclaim could be caped (so we would reclaim at an
>> artificial capacity until the pool depletes...).
>>
>>
>> Regards,
>>
>> --
>> Thomas
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170821/6c3b768b/attachment.html>;

📅 Original date posted:2017-07-08 📝 Original message:- The ...

2023-06-07T20:04:03+02:00

In reply to nevent1q…gfpn
_________________________

📅 Original date posted:2017-07-08
📝 Original message:- The BIP91 portion of the fork seems OK to me. There are some issues with
timing, but since this is for miner coordination of segwit activation, and
has little to do with other network users, it could be included as an
option. (I'm a fan of adding options;plugins, etc. to Bitcoin... some
others aren't.)

- This hard fork portion of the proposal is being deployed with "emergency"
speed... even though there is not an emergency on the network today that I
am aware of. If enacted, it will certainly result in two chains - and
with no replay protection.. The results of this will be confusing - two
ledgers with many transactions appearing on both and others appearing only
on one.

- The BIP should be modified to provide evidence and justification for the
timeline that is consistent with the level of risk the network would bear
if it were enacted.

- The coercion used to drive production of this BIP is mired in a
misinterpretation of BIP9 and sets a precedent for Bitcoin that may
undermine the value prospect of all cryptocurrency in general. For this
reason alone - even if all of the engineering concerns and timelines are
improved - even assigning this BIP a number could be considered
irresponsible.

- If you still want to code up a fork for the Bitcoin network, consider
starting with Luke's hard fork code and changing the rates of growth as
needed for your desired effect. Also you might want to read this first
(code references are in there):
https://petertodd.org/2016/hardforks-after-the-segwit-blocksize-increase .
Plans are already underway for a hard fork, for reasons that have nothing
to do with block size, but could include a timeline for a block size growth
consistent with global average residential bandwidth growth.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170708/2ef7883f/attachment.html>;

📅 Original date posted:2017-06-27 📝 Original ...

2023-06-07T20:03:32+02:00

In reply to nevent1q…ud6u
_________________________

📅 Original date posted:2017-06-27
📝 Original message:There's a pull req to core already for part of it:

https://github.com/bitcoin/bitcoin/pull/10444

On Tue, Jun 27, 2017 at 12:31 PM, Jorge Timón via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> First the implementation, then the technical design (BIP)... will the
> analysis come after that?
> Will there be any kind of simulations of tje proposed size or will thag
> come only after activation on mainnet?
> I assume the very last step will be activation on testnet 3 ?
>
>
> On 27 Jun 2017 8:44 am, "Sergio Demian Lerner via bitcoin-dev" <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Currently the only implementation that fulfills the requirements of the
> NYA agreement is the segwit2x/btc1 implementation, which is being finalized
> this week.
>
> Segwit2mb does not fulfill the NYA agreement.
>
> I'm asking now the segwit2x development team when a BIP will be ready so
> that Core has the opportunity to evaluate the technical proposal.
>
>
>
>
> On Wed, Jun 21, 2017 at 1:05 AM, Jacob Eliosoff via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Well, this Saturday's "Chinese roundtable" statement from a bunch of
>> miners (https://pastebin.com/b3St9VCF) says they intend "NYA" in the
>> coinbase as support for "the New York consensus SegWit2x program btc1 (
>> https://github.com/btc1)", whose code includes the (accelerated
>> 336-block) BIP 91 change. So, other facts or interpretations could come to
>> light, but until they do we should probably assume that's what the "NYA"
>> (which just broke 80% over the last 24h) means.
>>
>>
>> On Tue, Jun 20, 2017 at 10:11 PM, Mark Friedenbach <mark at friedenbach.org>
>> wrote:
>>
>>> 80% have set "NYA" in their coinbase string. We have no idea what that
>>> means. People are equating it to BIP 91 -- but BIP 91 did not exist at
>>> the time of the New York agreement, and differs from the actual text
>>> of the NYA in substantive ways. The "Segwit2MB" that existed at the
>>> time of the NYA, and which was explicitly referenced by the text is
>>> the proposal by Sergio Demian Lerner that was made to this mailing
>>> list on 31 March. The text of the NYA grants no authority for
>>> upgrading this proposal while remaining compliant with the agreement.
>>> This is without even considering the fact that in the days after the
>>> NYA there was disagreement among those who signed it as to what it
>>> meant.
>>>
>>> I feel it is a very dangerous and unwarranted assumption people are
>>> making that what we are seeing now is either 80% support for BIP-91 or
>>> for the code in the btc1 repo.
>>>
>>> On Tue, Jun 20, 2017 at 6:36 PM, Erik Aronesty <erik at q32.com> wrote:
>>> > # Jacob Eliosoff:
>>> >
>>> >> will start orphaning non-bit-1 blocks before Aug 1, and we avoid a
>>> split.
>>> >
>>> > Correct. There are 2 short activation periods in BIP91 either of which
>>> > would avoid a split.
>>> >
>>> > # Gregory Maxwell:
>>> >
>>> >> unclear to me _exactly_ what it would need to implement to be
>>> consistent.
>>> >
>>> > This is the relevant pull req to core:
>>> >
>>> > https://github.com/bitcoin/bitcoin/pull/10444
>>> >
>>> > Seems OK. It's technically running now on testnet5. I think it (or a
>>> > -bip148 option) should be merged as soon as feasible.
>>> >
>>> >> previously debunked "XT" and "Classic" hysteria.
>>> >
>>> > apples vs oranges, imo. segwit is not a contentious feature. the
>>> > "bundling" in segwit2x is, but that's not the issue here. the issue
>>> is we
>>> > are indirectly requiring miners that strongly support segwit to install
>>> > consensus protocol changes outside of bitcoin's standard reference.
>>> 80% of
>>> > them have signaled they will do so. these are uncharted waters.
>>> >
>>> >
>>> > On Tue, Jun 20, 2017 at 6:57 PM, Jacob Eliosoff via bitcoin-dev
>>> > <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>> >>
>>> >> I could be wrong, but the latest BIP91 implementation (also included
>>> in
>>> >> Segwit2x) cuts the activation period to 336 blocks (2.33 days).
>>> (This has
>>> >> been updated at
>>> >> https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki.) So
>>> if 80%
>>> >> of hashpower is actually running that code and signaling on bit 4 by
>>> July 25
>>> >> or so, then those 80+% will start orphaning non-bit-1 blocks before
>>> Aug 1,
>>> >> and we avoid a split.
>>> >>
>>> >> There may still be a few non-bit-1 blocks that get orphaned after Aug
>>> 1,
>>> >> because they're mined by old BIP141 nodes. But it seems like very few
>>> >> miners won't be signaling either Segwit2x *or* BIP141 by then...
>>> >>
>>> >> Make sense?
>>> >>
>>> >>
>>> >> On Tue, Jun 20, 2017 at 6:48 PM, Mark Friedenbach <
>>> mark at friedenbach.org>
>>> >> wrote:
>>> >>>
>>> >>> Why do you say activation by August 1st is likely? That would
>>> require an
>>> >>> entire difficulty adjustment period with >=95% bit1 signaling. That
>>> seems a
>>> >>> tall order to organize in the scant few weeks remaining.
>>> >>>
>>> >>> On Jun 20, 2017, at 3:29 PM, Jacob Eliosoff via bitcoin-dev
>>> >>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>> >>>
>>> >>> If segwit is activated before Aug 1, as now seems likely, there will
>>> be
>>> >>> no split that day. But if activation is via Segwit2x (also likely),
>>> and at
>>> >>> least some nodes do & some don't follow through with the HF 3mo later
>>> >>> (again, likely), agreed w/ Greg that *then* we'll see a split -
>>> probably in
>>> >>> Sep/Oct. How those two chains will match up and how the split will
>>> play out
>>> >>> is anyone's guess...
>>> >>>
>>> >>>
>>> >>>
>>> >>> On Jun 20, 2017 6:16 PM, "Hampus Sjöberg via bitcoin-dev"
>>> >>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>> >>>
>>> >>> > Ironically, it looks like most of the segwit2x signaling miners are
>>> >>> > faking it (because they're not signaling segwit which it requires).
>>> >>> > It'll be unfortunate if some aren't faking it and start orphaning
>>> >>> > their own blocks because they are failing to signal segwit.
>>> >>>
>>> >>> Well, they're doing some kind of "pre-signaling" in the coinbase at
>>> the
>>> >>> moment, because the segwit2x project is still in alpha-phase
>>> according to
>>> >>> the timeline. They're just showing commitment.
>>> >>> I'm sure they will begin signaling on version bit 4/BIP91 as well as
>>> >>> actually running a segwit2x node when the time comes.
>>> >>>
>>> >>>
>>> >>> > As far as prevent a chain split goes, all those things
>>> >>> > (148/91/segwit2x(per today)) effectively guarantee a chainsplit--
>>> so I
>>> >>> > don't think that holds.
>>> >>>
>>> >>> Segwit2x/BIP91/BIP148 will orphan miners that do not run a Segwit2x
>>> (or
>>> >>> BIP148) node, because they wouldn't have the new consensus rule of
>>> requiring
>>> >>> all blocks to signal for segwit.
>>> >>> I don't believe there would be any long lasting chainsplit though
>>> >>> (because of the ~80% hashrate support on segwit2x), perhaps 2-3
>>> blocks if we
>>> >>> get unlucky.
>>> >>>
>>> >>> Hampus
>>> >>>
>>> >>> 2017-06-20 23:49 GMT+02:00 Gregory Maxwell via bitcoin-dev
>>> >>> <bitcoin-dev at lists.linuxfoundation.org>:
>>> >>>>
>>> >>>> On Tue, Jun 20, 2017 at 3:44 PM, Erik Aronesty via bitcoin-dev
>>> >>>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>> >>>> > Because a large percentage of miners are indifferent, right now
>>> miners
>>> >>>> > have
>>> >>>> > to choose between BIP148 and Segwit2x if they want to activate
>>> Segwit.
>>> >>>>
>>> >>>> Miners can simply continuing signaling segwit, which will leave them
>>> >>>> at least soft-fork compatible with BIP148 and BIP91 (and god knows
>>> >>>> what "segwit2x" is since they keep changing the actual definition
>>> and
>>> >>>> do not have a specification; but last I saw the near-term behavior
>>> the
>>> >>>> same as BIP91 but with a radically reduced activation window, so the
>>> >>>> story would be the same there in the near term).
>>> >>>>
>>> >>>> Ironically, it looks like most of the segwit2x signaling miners are
>>> >>>> faking it (because they're not signaling segwit which it requires).
>>> >>>> It'll be unfortunate if some aren't faking it and start orphaning
>>> >>>> their own blocks because they are failing to signal segwit.
>>> >>>>
>>> >>>> I don't think the rejection of segwit2x from Bitcoin's developers
>>> >>>> could be any more resolute than what we've already seen:
>>> >>>> https://en.bitcoin.it/wiki/Segwit_support
>>> >>>>
>>> >>>> On Tue, Jun 20, 2017 at 5:22 PM, Mark Friedenbach via bitcoin-dev
>>> >>>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>> >>>> > I think it is very naïve to assume that any shift would be
>>> temporary.
>>> >>>> > We have a hard enough time getting miners to proactively upgrade
>>> to
>>> >>>> > recent versions of the reference bitcoin daemon. If miners
>>> interpret
>>> >>>> > the situation as being forced to run non-reference software in
>>> order
>>> >>>> > to prevent a chain split because a lack of support from Bitcoin
>>> Core,
>>> >>>> > that could be a one-way street.
>>> >>>>
>>> >>>> I think this is somewhat naive and sounds a lot like the repeat of
>>> the
>>> >>>> previously debunked "XT" and "Classic" hysteria.
>>> >>>>
>>> >>>> There is a reason that segwit2x is pretty much unanimously rejected
>>> by
>>> >>>> the technical community. And just like with XT/Classic/Unlimited
>>> >>>> you'll continue to see a strong correlation with people who are
>>> >>>> unwilling and unable to keep updating the software at an acceptable
>>> >>>> level of quality-- esp. because the very founding on their fork is
>>> >>>> predicated on discarding those properties.
>>> >>>>
>>> >>>> If miners want to go off and create an altcoin-- welp, thats
>>> something
>>> >>>> they can always do, and nothing about that will force anyone to go
>>> >>>> along with it.
>>> >>>>
>>> >>>> As far as prevent a chain split goes, all those things
>>> >>>> (148/91/segwit2x(per today)) effectively guarantee a chainsplit--
>>> so I
>>> >>>> don't think that holds.
>>> >>>> _______________________________________________
>>> >>>> bitcoin-dev mailing list
>>> >>>> bitcoin-dev at lists.linuxfoundation.org
>>> >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>> >>>
>>> >>>
>>> >>>
>>> >>> _______________________________________________
>>> >>> bitcoin-dev mailing list
>>> >>> bitcoin-dev at lists.linuxfoundation.org
>>> >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>> >>>
>>> >>>
>>> >>> _______________________________________________
>>> >>> bitcoin-dev mailing list
>>> >>> bitcoin-dev at lists.linuxfoundation.org
>>> >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>> >>
>>> >>
>>> >>
>>> >> _______________________________________________
>>> >> bitcoin-dev mailing list
>>> >> bitcoin-dev at lists.linuxfoundation.org
>>> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>> >>
>>> >
>>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170627/472604e0/attachment-0001.html>;

📅 Original date posted:2017-06-20 📝 Original message:Are we ...

2023-06-07T20:03:26+02:00

In reply to nevent1q…4yxn
_________________________

📅 Original date posted:2017-06-20
📝 Original message:Are we going to merge BIP91 or a -BIP148 option to core for inclusion in
the next release or so?

Because a large percentage of miners are indifferent, right now miners have
to choose between BIP148 and Segwit2x if they want to activate Segwit.

Should we be forcing miners to choose to run non-core code in order to
activate a popular feature?

- Erik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170620/330d7f48/attachment.html>;

📅 Original date posted:2017-06-07 📝 Original message:> ...

2023-06-07T20:02:37+02:00

In reply to nevent1q…m72z
_________________________

📅 Original date posted:2017-06-07
📝 Original message:> But passing it off as the safest defense is bad faith.

Without this option, a miner has to guess whether a split will be
economically impacting. With this option, his miner will automatically
switch to the chain least likely to get wiped out... as soon as a simple
majority of miners supports it.

On Wed, Jun 7, 2017 at 12:44 PM, Jacob Eliosoff <jacob.eliosoff at gmail.com>
wrote:

> This is not the safest defense against a split. If 70% of miners run
> "splitprotection", and 0.1% run BIP148, there's no "safety"/"defense"
> reason for splitprotection to activate segwit. It should only do so if
> *BIP148* support (NB: not just segwit support!) >50%.
>
> The truly defensive logic is "If the majority supports orphaning
> non-segwit blocks starting Aug 1, I'll join them."
>
> If the real goal of this BIP is to induce miners to run segwit, then fair
> enough. But passing it off as the safest defense is bad faith.
>
>
> On Wed, Jun 7, 2017 at 10:10 AM, Erik Aronesty via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> This is, by far, the safest way for miners to quickly defend against a
>> chain split, much better than a -bip148 option. This allows miners to
>> defend themselves, with very little risk, since the defense is only
>> activated if the majority of miners do so. I would move for a very rapid
>> deployment. Only miners would need to upgrade. Regular users would not
>> have to concern themselves with this release.
>>
>> On Wed, Jun 7, 2017 at 6:13 AM, James Hilliard via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> I think even 55% would probably work out fine simply due to incentive
>>> structures, once signalling is over 51% it's then clear to miners that
>>> non-signalling blocks will be orphaned and the rest will rapidly
>>> update to splitprotection/BIP148. The purpose of this BIP is to reduce
>>> chain split risk for BIP148 since it's looking like BIP148 is going to
>>> be run by a non-insignificant percentage of the economy at a minimum.
>>>
>>> On Wed, Jun 7, 2017 at 12:20 AM, Tao Effect <contact at taoeffect.com>
>>> wrote:
>>> > See thread on replay attacks for why activating regardless of
>>> threshold is a
>>> > bad idea [1].
>>> >
>>> > BIP91 OTOH seems perfectly reasonable. 80% instead of 95% makes it more
>>> > difficult for miners to hold together in opposition to Core. It gives
>>> Core
>>> > more leverage in negotiations.
>>> >
>>> > If they don't activate with 80%, Core can release another BIP to
>>> reduce it
>>> > to 75%.
>>> >
>>> > Each threshold reduction makes it both more likely to succeed, but also
>>> > increases the likelihood of harm to the ecosystem.
>>> >
>>> > Cheers,
>>> > Greg
>>> >
>>> > [1]
>>> > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017
>>> -June/014497.html
>>> >
>>> > --
>>> > Please do not email me anything that you are not comfortable also
>>> sharing
>>> > with the NSA.
>>> >
>>> > On Jun 6, 2017, at 6:54 PM, James Hilliard <james.hilliard1 at gmail.com>
>>> > wrote:
>>> >
>>> > This is a BIP8 style soft fork so mandatory signalling will be active
>>> > after Aug 1st regardless.
>>> >
>>> > On Tue, Jun 6, 2017 at 8:51 PM, Tao Effect <contact at taoeffect.com>
>>> wrote:
>>> >
>>> > What is the probability that a 65% threshold is too low and can allow a
>>> > "surprise miner attack", whereby miners are kept offline before the
>>> > deadline, and brought online immediately after, creating potential
>>> havoc?
>>> >
>>> > (Nit: "simple majority" usually refers to >50%, I think, might cause
>>> > confusion.)
>>> >
>>> > -Greg Slepak
>>> >
>>> > --
>>> > Please do not email me anything that you are not comfortable also
>>> sharing
>>> > with the NSA.
>>> >
>>> > On Jun 6, 2017, at 5:56 PM, James Hilliard via bitcoin-dev
>>> > <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>> >
>>> > Due to the proposed calendar(https://segwit2x.github.io/) for the
>>> > SegWit2x agreement being too slow to activate SegWit mandatory
>>> > signalling ahead of BIP148 using BIP91 I would like to propose another
>>> > option that miners can use to prevent a chain split ahead of the Aug
>>> > 1st BIP148 activation date.
>>> >
>>> > The splitprotection soft fork is essentially BIP91 but using BIP8
>>> > instead of BIP9 with a lower activation threshold and immediate
>>> > mandatory signalling lock-in. This allows for a majority of miners to
>>> > activate mandatory SegWit signalling and prevent a potential chain
>>> > split ahead of BIP148 activation.
>>> >
>>> > This BIP allows for miners to respond to market forces quickly ahead
>>> > of BIP148 activation by signalling for splitprotection. Any miners
>>> > already running BIP148 should be encouraged to use splitprotection.
>>> >
>>> > <pre>
>>> > BIP: splitprotection
>>> > Layer: Consensus (soft fork)
>>> > Title: User Activated Soft Fork Split Protection
>>> > Author: James Hilliard <james.hilliard1 at gmail.com>
>>> > Comments-Summary: No comments yet.
>>> > Comments-URI:
>>> > Status: Draft
>>> > Type: Standards Track
>>> > Created: 2017-05-22
>>> > License: BSD-3-Clause
>>> > CC0-1.0
>>> > </pre>
>>> >
>>> > ==Abstract==
>>> >
>>> > This document specifies a coordination mechanism for a simple majority
>>> > of miners to prevent a chain split ahead of BIP148 activation.
>>> >
>>> > ==Definitions==
>>> >
>>> > "existing segwit deployment" refer to the BIP9 "segwit" deployment
>>> > using bit 1, between November 15th 2016 and November 15th 2017 to
>>> > activate BIP141, BIP143 and BIP147.
>>> >
>>> > ==Motivation==
>>> >
>>> > The biggest risk of BIP148 is an extended chain split, this BIP
>>> > provides a way for a simple majority of miners to eliminate that risk.
>>> >
>>> > This BIP provides a way for a simple majority of miners to coordinate
>>> > activation of the existing segwit deployment with less than 95%
>>> > hashpower before BIP148 activation. Due to time constraints unless
>>> > immediately deployed BIP91 will likely not be able to enforce
>>> > mandatory signalling of segwit before the Aug 1st activation of
>>> > BIP148. This BIP provides a method for rapid miner activation of
>>> > SegWit mandatory signalling ahead of the BIP148 activation date. Since
>>> > the primary goal of this BIP is to reduce the chance of an extended
>>> > chain split as much as possible we activate using a simple miner
>>> > majority of 65% over a 504 block interval rather than a higher
>>> > percentage. This BIP also allows miners to signal their intention to
>>> > run BIP148 in order to prevent a chain split.
>>> >
>>> > ==Specification==
>>> >
>>> > While this BIP is active, all blocks must set the nVersion header top
>>> > 3 bits to 001 together with bit field (1<<1) (according to the
>>> > existing segwit deployment). Blocks that do not signal as required
>>> > will be rejected.
>>> >
>>> > ==Deployment==
>>> >
>>> > This BIP will be deployed by "version bits" with a 65%(this can be
>>> > adjusted if desired) activation threshold BIP9 with the name
>>> > "splitprotecion" and using bit 2.
>>> >
>>> > This BIP starts immediately and is a BIP8 style soft fork since
>>> > mandatory signalling will start on midnight August 1st 2017 (epoch
>>> > time 1501545600) regardless of whether or not this BIP has reached its
>>> > own signalling threshold. This BIP will cease to be active when segwit
>>> > is locked-in.
>>> >
>>> > === Reference implementation ===
>>> >
>>> > <pre>
>>> > // Check if Segregated Witness is Locked In
>>> > bool IsWitnessLockedIn(const CBlockIndex* pindexPrev, const
>>> > Consensus::Params& params)
>>> > {
>>> > LOCK(cs_main);
>>> > return (VersionBitsState(pindexPrev, params,
>>> > Consensus::DEPLOYMENT_SEGWIT, versionbitscache) ==
>>> > THRESHOLD_LOCKED_IN);
>>> > }
>>> >
>>> > // SPLITPROTECTION mandatory segwit signalling.
>>> > if ( VersionBitsState(pindex->pprev, chainparams.GetConsensus(),
>>> > Consensus::DEPLOYMENT_SPLITPROTECTION, versionbitscache) ==
>>> > THRESHOLD_LOCKED_IN &&
>>> > !IsWitnessLockedIn(pindex->pprev, chainparams.GetConsensus()) &&
>>> > // Segwit is not locked in
>>> > !IsWitnessEnabled(pindex->pprev, chainparams.GetConsensus()) ) //
>>> > and is not active.
>>> > {
>>> > bool fVersionBits = (pindex->nVersion & VERSIONBITS_TOP_MASK) ==
>>> > VERSIONBITS_TOP_BITS;
>>> > bool fSegbit = (pindex->nVersion &
>>> > VersionBitsMask(chainparams.GetConsensus(),
>>> > Consensus::DEPLOYMENT_SEGWIT)) != 0;
>>> > if (!(fVersionBits && fSegbit)) {
>>> > return state.DoS(0, error("ConnectBlock(): relayed block must
>>> > signal for segwit, please upgrade"), REJECT_INVALID, "bad-no-segwit");
>>> > }
>>> > }
>>> >
>>> > // BIP148 mandatory segwit signalling.
>>> > int64_t nMedianTimePast = pindex->GetMedianTimePast();
>>> > if ( (nMedianTimePast >= 1501545600) && // Tue 01 Aug 2017 00:00:00
>>> UTC
>>> > (nMedianTimePast <= 1510704000) && // Wed 15 Nov 2017 00:00:00 UTC
>>> > (!IsWitnessLockedIn(pindex->pprev, chainparams.GetConsensus()) &&
>>> > // Segwit is not locked in
>>> > !IsWitnessEnabled(pindex->pprev, chainparams.GetConsensus())) )
>>> > // and is not active.
>>> > {
>>> > bool fVersionBits = (pindex->nVersion & VERSIONBITS_TOP_MASK) ==
>>> > VERSIONBITS_TOP_BITS;
>>> > bool fSegbit = (pindex->nVersion &
>>> > VersionBitsMask(chainparams.GetConsensus(),
>>> > Consensus::DEPLOYMENT_SEGWIT)) != 0;
>>> > if (!(fVersionBits && fSegbit)) {
>>> > return state.DoS(0, error("ConnectBlock(): relayed block must
>>> > signal for segwit, please upgrade"), REJECT_INVALID, "bad-no-segwit");
>>> > }
>>> > }
>>> > </pre>
>>> >
>>> > https://github.com/bitcoin/bitcoin/compare/0.14...jameshilli
>>> ard:splitprotection-v0.14.1
>>> >
>>> > ==Backwards Compatibility==
>>> >
>>> > This deployment is compatible with the existing "segwit" bit 1
>>> > deployment scheduled between midnight November 15th, 2016 and midnight
>>> > November 15th, 2017. This deployment is also compatible with the
>>> > existing BIP148 deployment. This BIP is compatible with BIP91 only if
>>> > BIP91 activates before it and before BIP148. Miners will need to
>>> > upgrade their nodes to support splitprotection otherwise they may
>>> > build on top of an invalid block. While this bip is active users
>>> > should either upgrade to splitprotection or wait for additional
>>> > confirmations when accepting payments.
>>> >
>>> > ==Rationale==
>>> >
>>> > Historically we have used IsSuperMajority() to activate soft forks
>>> > such as BIP66 which has a mandatory signalling requirement for miners
>>> > once activated, this ensures that miners are aware of new rules being
>>> > enforced. This technique can be leveraged to lower the signalling
>>> > threshold of a soft fork while it is in the process of being deployed
>>> > in a backwards compatible way. We also use a BIP8 style timeout to
>>> > ensure that this BIP is compatible with BIP148 and that BIP148
>>> > compatible mandatory signalling activates regardless of miner
>>> > signalling levels.
>>> >
>>> > By orphaning non-signalling blocks during the BIP9 bit 1 "segwit"
>>> > deployment, this BIP can cause the existing "segwit" deployment to
>>> > activate without needing to release a new deployment. As we approach
>>> > BIP148 activation it may be desirable for a majority of miners to have
>>> > a method that will ensure that there is no chain split.
>>> >
>>> > ==References==
>>> >
>>> > *[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/20
>>> 17-March/013714.html
>>> > Mailing list discussion]
>>> > *[https://github.com/bitcoin/bitcoin/blob/v0.6.0/src/main.cp
>>> p#L1281-L1283
>>> > P2SH flag day activation]
>>> > *[[bip-0009.mediawiki|BIP9 Version bits with timeout and delay]]
>>> > *[[bip-0016.mediawiki|BIP16 Pay to Script Hash]]
>>> > *[[bip-0091.mediawiki|BIP91 Reduced threshold Segwit MASF]]
>>> > *[[bip-0141.mediawiki|BIP141 Segregated Witness (Consensus layer)]]
>>> > *[[bip-0143.mediawiki|BIP143 Transaction Signature Verification for
>>> > Version 0 Witness Program]]
>>> > *[[bip-0147.mediawiki|BIP147 Dealing with dummy stack element
>>> malleability]]
>>> > *[[bip-0148.mediawiki|BIP148 Mandatory activation of segwit
>>> deployment]]
>>> > *[[bip-0149.mediawiki|BIP149 Segregated Witness (second deployment)]]
>>> > *[https://bitcoincore.org/en/2016/01/26/segwit-benefits/ Segwit
>>> benefits]
>>> >
>>> > ==Copyright==
>>> >
>>> > This document is dual licensed as BSD 3-clause, and Creative Commons
>>> > CC0 1.0 Universal.
>>> > _______________________________________________
>>> > bitcoin-dev mailing list
>>> > bitcoin-dev at lists.linuxfoundation.org
>>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>> >
>>> >
>>> >
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170607/69b8b33e/attachment-0001.html>;

📅 Original date posted:2017-06-07 📝 Original message:This ...

2023-06-07T20:02:35+02:00

In reply to nevent1q…e77r
_________________________

📅 Original date posted:2017-06-07
📝 Original message:This is, by far, the safest way for miners to quickly defend against a
chain split, much better than a -bip148 option. This allows miners to
defend themselves, with very little risk, since the defense is only
activated if the majority of miners do so. I would move for a very rapid
deployment. Only miners would need to upgrade. Regular users would not
have to concern themselves with this release.

On Wed, Jun 7, 2017 at 6:13 AM, James Hilliard via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> I think even 55% would probably work out fine simply due to incentive
> structures, once signalling is over 51% it's then clear to miners that
> non-signalling blocks will be orphaned and the rest will rapidly
> update to splitprotection/BIP148. The purpose of this BIP is to reduce
> chain split risk for BIP148 since it's looking like BIP148 is going to
> be run by a non-insignificant percentage of the economy at a minimum.
>
> On Wed, Jun 7, 2017 at 12:20 AM, Tao Effect <contact at taoeffect.com> wrote:
> > See thread on replay attacks for why activating regardless of threshold
> is a
> > bad idea [1].
> >
> > BIP91 OTOH seems perfectly reasonable. 80% instead of 95% makes it more
> > difficult for miners to hold together in opposition to Core. It gives
> Core
> > more leverage in negotiations.
> >
> > If they don't activate with 80%, Core can release another BIP to reduce
> it
> > to 75%.
> >
> > Each threshold reduction makes it both more likely to succeed, but also
> > increases the likelihood of harm to the ecosystem.
> >
> > Cheers,
> > Greg
> >
> > [1]
> > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/
> 2017-June/014497.html
> >
> > --
> > Please do not email me anything that you are not comfortable also sharing
> > with the NSA.
> >
> > On Jun 6, 2017, at 6:54 PM, James Hilliard <james.hilliard1 at gmail.com>
> > wrote:
> >
> > This is a BIP8 style soft fork so mandatory signalling will be active
> > after Aug 1st regardless.
> >
> > On Tue, Jun 6, 2017 at 8:51 PM, Tao Effect <contact at taoeffect.com>
> wrote:
> >
> > What is the probability that a 65% threshold is too low and can allow a
> > "surprise miner attack", whereby miners are kept offline before the
> > deadline, and brought online immediately after, creating potential havoc?
> >
> > (Nit: "simple majority" usually refers to >50%, I think, might cause
> > confusion.)
> >
> > -Greg Slepak
> >
> > --
> > Please do not email me anything that you are not comfortable also sharing
> > with the NSA.
> >
> > On Jun 6, 2017, at 5:56 PM, James Hilliard via bitcoin-dev
> > <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >
> > Due to the proposed calendar(https://segwit2x.github.io/) for the
> > SegWit2x agreement being too slow to activate SegWit mandatory
> > signalling ahead of BIP148 using BIP91 I would like to propose another
> > option that miners can use to prevent a chain split ahead of the Aug
> > 1st BIP148 activation date.
> >
> > The splitprotection soft fork is essentially BIP91 but using BIP8
> > instead of BIP9 with a lower activation threshold and immediate
> > mandatory signalling lock-in. This allows for a majority of miners to
> > activate mandatory SegWit signalling and prevent a potential chain
> > split ahead of BIP148 activation.
> >
> > This BIP allows for miners to respond to market forces quickly ahead
> > of BIP148 activation by signalling for splitprotection. Any miners
> > already running BIP148 should be encouraged to use splitprotection.
> >
> > <pre>
> > BIP: splitprotection
> > Layer: Consensus (soft fork)
> > Title: User Activated Soft Fork Split Protection
> > Author: James Hilliard <james.hilliard1 at gmail.com>
> > Comments-Summary: No comments yet.
> > Comments-URI:
> > Status: Draft
> > Type: Standards Track
> > Created: 2017-05-22
> > License: BSD-3-Clause
> > CC0-1.0
> > </pre>
> >
> > ==Abstract==
> >
> > This document specifies a coordination mechanism for a simple majority
> > of miners to prevent a chain split ahead of BIP148 activation.
> >
> > ==Definitions==
> >
> > "existing segwit deployment" refer to the BIP9 "segwit" deployment
> > using bit 1, between November 15th 2016 and November 15th 2017 to
> > activate BIP141, BIP143 and BIP147.
> >
> > ==Motivation==
> >
> > The biggest risk of BIP148 is an extended chain split, this BIP
> > provides a way for a simple majority of miners to eliminate that risk.
> >
> > This BIP provides a way for a simple majority of miners to coordinate
> > activation of the existing segwit deployment with less than 95%
> > hashpower before BIP148 activation. Due to time constraints unless
> > immediately deployed BIP91 will likely not be able to enforce
> > mandatory signalling of segwit before the Aug 1st activation of
> > BIP148. This BIP provides a method for rapid miner activation of
> > SegWit mandatory signalling ahead of the BIP148 activation date. Since
> > the primary goal of this BIP is to reduce the chance of an extended
> > chain split as much as possible we activate using a simple miner
> > majority of 65% over a 504 block interval rather than a higher
> > percentage. This BIP also allows miners to signal their intention to
> > run BIP148 in order to prevent a chain split.
> >
> > ==Specification==
> >
> > While this BIP is active, all blocks must set the nVersion header top
> > 3 bits to 001 together with bit field (1<<1) (according to the
> > existing segwit deployment). Blocks that do not signal as required
> > will be rejected.
> >
> > ==Deployment==
> >
> > This BIP will be deployed by "version bits" with a 65%(this can be
> > adjusted if desired) activation threshold BIP9 with the name
> > "splitprotecion" and using bit 2.
> >
> > This BIP starts immediately and is a BIP8 style soft fork since
> > mandatory signalling will start on midnight August 1st 2017 (epoch
> > time 1501545600) regardless of whether or not this BIP has reached its
> > own signalling threshold. This BIP will cease to be active when segwit
> > is locked-in.
> >
> > === Reference implementation ===
> >
> > <pre>
> > // Check if Segregated Witness is Locked In
> > bool IsWitnessLockedIn(const CBlockIndex* pindexPrev, const
> > Consensus::Params& params)
> > {
> > LOCK(cs_main);
> > return (VersionBitsState(pindexPrev, params,
> > Consensus::DEPLOYMENT_SEGWIT, versionbitscache) ==
> > THRESHOLD_LOCKED_IN);
> > }
> >
> > // SPLITPROTECTION mandatory segwit signalling.
> > if ( VersionBitsState(pindex->pprev, chainparams.GetConsensus(),
> > Consensus::DEPLOYMENT_SPLITPROTECTION, versionbitscache) ==
> > THRESHOLD_LOCKED_IN &&
> > !IsWitnessLockedIn(pindex->pprev, chainparams.GetConsensus()) &&
> > // Segwit is not locked in
> > !IsWitnessEnabled(pindex->pprev, chainparams.GetConsensus()) ) //
> > and is not active.
> > {
> > bool fVersionBits = (pindex->nVersion & VERSIONBITS_TOP_MASK) ==
> > VERSIONBITS_TOP_BITS;
> > bool fSegbit = (pindex->nVersion &
> > VersionBitsMask(chainparams.GetConsensus(),
> > Consensus::DEPLOYMENT_SEGWIT)) != 0;
> > if (!(fVersionBits && fSegbit)) {
> > return state.DoS(0, error("ConnectBlock(): relayed block must
> > signal for segwit, please upgrade"), REJECT_INVALID, "bad-no-segwit");
> > }
> > }
> >
> > // BIP148 mandatory segwit signalling.
> > int64_t nMedianTimePast = pindex->GetMedianTimePast();
> > if ( (nMedianTimePast >= 1501545600) && // Tue 01 Aug 2017 00:00:00 UTC
> > (nMedianTimePast <= 1510704000) && // Wed 15 Nov 2017 00:00:00 UTC
> > (!IsWitnessLockedIn(pindex->pprev, chainparams.GetConsensus()) &&
> > // Segwit is not locked in
> > !IsWitnessEnabled(pindex->pprev, chainparams.GetConsensus())) )
> > // and is not active.
> > {
> > bool fVersionBits = (pindex->nVersion & VERSIONBITS_TOP_MASK) ==
> > VERSIONBITS_TOP_BITS;
> > bool fSegbit = (pindex->nVersion &
> > VersionBitsMask(chainparams.GetConsensus(),
> > Consensus::DEPLOYMENT_SEGWIT)) != 0;
> > if (!(fVersionBits && fSegbit)) {
> > return state.DoS(0, error("ConnectBlock(): relayed block must
> > signal for segwit, please upgrade"), REJECT_INVALID, "bad-no-segwit");
> > }
> > }
> > </pre>
> >
> > https://github.com/bitcoin/bitcoin/compare/0.14...
> jameshilliard:splitprotection-v0.14.1
> >
> > ==Backwards Compatibility==
> >
> > This deployment is compatible with the existing "segwit" bit 1
> > deployment scheduled between midnight November 15th, 2016 and midnight
> > November 15th, 2017. This deployment is also compatible with the
> > existing BIP148 deployment. This BIP is compatible with BIP91 only if
> > BIP91 activates before it and before BIP148. Miners will need to
> > upgrade their nodes to support splitprotection otherwise they may
> > build on top of an invalid block. While this bip is active users
> > should either upgrade to splitprotection or wait for additional
> > confirmations when accepting payments.
> >
> > ==Rationale==
> >
> > Historically we have used IsSuperMajority() to activate soft forks
> > such as BIP66 which has a mandatory signalling requirement for miners
> > once activated, this ensures that miners are aware of new rules being
> > enforced. This technique can be leveraged to lower the signalling
> > threshold of a soft fork while it is in the process of being deployed
> > in a backwards compatible way. We also use a BIP8 style timeout to
> > ensure that this BIP is compatible with BIP148 and that BIP148
> > compatible mandatory signalling activates regardless of miner
> > signalling levels.
> >
> > By orphaning non-signalling blocks during the BIP9 bit 1 "segwit"
> > deployment, this BIP can cause the existing "segwit" deployment to
> > activate without needing to release a new deployment. As we approach
> > BIP148 activation it may be desirable for a majority of miners to have
> > a method that will ensure that there is no chain split.
> >
> > ==References==
> >
> > *[https://lists.linuxfoundation.org/pipermail/
> bitcoin-dev/2017-March/013714.html
> > Mailing list discussion]
> > *[https://github.com/bitcoin/bitcoin/blob/v0.6.0/src/main.
> cpp#L1281-L1283
> > P2SH flag day activation]
> > *[[bip-0009.mediawiki|BIP9 Version bits with timeout and delay]]
> > *[[bip-0016.mediawiki|BIP16 Pay to Script Hash]]
> > *[[bip-0091.mediawiki|BIP91 Reduced threshold Segwit MASF]]
> > *[[bip-0141.mediawiki|BIP141 Segregated Witness (Consensus layer)]]
> > *[[bip-0143.mediawiki|BIP143 Transaction Signature Verification for
> > Version 0 Witness Program]]
> > *[[bip-0147.mediawiki|BIP147 Dealing with dummy stack element
> malleability]]
> > *[[bip-0148.mediawiki|BIP148 Mandatory activation of segwit deployment]]
> > *[[bip-0149.mediawiki|BIP149 Segregated Witness (second deployment)]]
> > *[https://bitcoincore.org/en/2016/01/26/segwit-benefits/ Segwit
> benefits]
> >
> > ==Copyright==
> >
> > This document is dual licensed as BSD 3-clause, and Creative Commons
> > CC0 1.0 Universal.
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> >
> >
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170607/881a9a7d/attachment-0001.html>;

📅 Original date posted:2017-05-02 📝 Original message:If the ...

2023-06-07T20:00:38+02:00

In reply to nevent1q…0yxh
_________________________

📅 Original date posted:2017-05-02
📝 Original message:If the flag day for a wtxid commitment is timed before the current segwit
period end, I suspect segwit would activate within the current period.

On Tue, Apr 25, 2017 at 2:46 PM, Luke Dashjr via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> On Tuesday 25 April 2017 6:28:14 PM Gregory Maxwell via bitcoin-dev wrote:
> > > https://github.com/bitcoin/bitcoin/compare/master...
> shaolinfry:uasegwit-f
> > > lagday
> > >
> > > I believe this approach would satisfy the more measured approach
> expected
> > > for Bitcoin and does not have the issues you brought up about BIP148.
> >
> > I have not reviewed it carefully yet, but I agree that it addresses my
> > main concern! I think this is a much better approach. Thanks.
>
> FWIW, I disagree in this case. I think given the circumstances, if we are
> going to do a UASF for segwit at all, we need a clearly decisive outcome,
> which is given by BIP 148. Using the approach in BIP 8 makes sense in many
> cases, but in this case, it is liable to simply create a prolonged
> uncertainty
> where nobody knows the outcome when segwit's rules are challenged by a
> malicious miner.
>
> If BIP 148 fails to achieve widespread support, we could do a BIP 8-based
> UASF
> with Segwit v2 (along with some other changes I suggested in the other
> thread), but I think the tradeoffs right now favour BIP 148 as the best
> UASF
> deployment.
>
> Luke
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170502/0cee5728/attachment.html>;

📅 Original date posted:2017-04-20 📝 Original message:Try to ...

2023-06-07T20:00:18+02:00

In reply to nevent1q…9azx
_________________________

📅 Original date posted:2017-04-20
📝 Original message:Try to find 1TB dedicated server hosting ...

If you want to set up an ecommerce site somewhere besides your living room,
storage costs are still a concern.

On Mon, Apr 17, 2017 at 3:11 AM, Danny Thorpe via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> 1TB HDD is now available for under $40 USD. How is the 100GB storage
> requirement preventing anyone from setting up full nodes?
>
> On Apr 16, 2017 11:55 PM, "David Vorick via bitcoin-dev" <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> *Rationale:*
>>
>> A node that stores the full blockchain (I will use the term archival
>> node) requires over 100GB of disk space, which I believe is one of the most
>> significant barriers to more people running full nodes. And I believe the
>> ecosystem would benefit substantially if more users were running full nodes.
>>
>> The best alternative today to storing the full blockchain is to run a
>> pruned node, which keeps only the UTXO set and throws away already verified
>> blocks. The operator of the pruned node is able to enjoy the full security
>> benefits of a full node, but is essentially leeching the network, as they
>> performed a large download likely without contributing anything back.
>>
>> This puts more pressure on the archival nodes, as the archival nodes need
>> to pick up the slack and help new nodes bootstrap to the network. As the
>> pressure on archival nodes grows, fewer people will be able to actually run
>> archival nodes, and the situation will degrade. The situation would likely
>> become problematic quickly if bitcoin-core were to ship with the defaults
>> set to a pruned node.
>>
>> Even further, the people most likely to care about saving 100GB of disk
>> space are also the people least likely to care about some extra bandwidth
>> usage. For datacenter nodes, and for nodes doing lots of bandwidth, the
>> bandwidth is usually the biggest cost of running the node. For home users
>> however, as long as they stay under their bandwidth cap, the bandwidth is
>> actually free. Ideally, new nodes would be able to bootstrap from nodes
>> that do not have to pay for their bandwidth, instead of needing to rely on
>> a decreasing percentage of heavy-duty archival nodes.
>>
>> I have (perhaps incorrectly) identified disk space consumption as the
>> most significant factor in your average user choosing to run a pruned node
>> or a lite client instead of a full node. The average user is not typically
>> too worried about bandwidth, and is also not typically too worried about
>> initial blockchain download time. But the 100GB hit to your disk space can
>> be a huge psychological factor, especially if your hard drive only has
>> 500GB available in the first place, and 250+ GB is already consumed by
>> other files you have.
>>
>> I believe that improving the disk usage situation would greatly benefit
>> decentralization, especially if it could be done without putting pressure
>> on archival nodes.
>>
>> *Small Nodes Proposal:*
>>
>> I propose an alternative to the pruned node that does not put undue
>> pressure on archival nodes, and would be acceptable and non-risky to ship
>> as a default in bitcoin-core. For lack of a better name, I'll call this new
>> type of node a 'small node'. The intention is that bitcoin-core would
>> eventually ship 'small nodes' by default, such that the expected amount of
>> disk consumption drops from today's 100+ GB to less than 30 GB.
>>
>> My alternative proposal has the following properties:
>>
>> + Full nodes only need to store ~20% of the blockchain
>> + With very high probability, a new node will be able to recover the
>> entire blockchain by connecting to 6 random small node peers.
>> + An attacker that can eliminate a chosen+ 95% of the full nodes running
>> today will be unable to prevent new nodes from downloading the full
>> blockchain, even if the attacker is also able to eliminate all archival
>> nodes. (assuming all nodes today were small nodes instead of archival nodes)
>>
>> Method:
>>
>> A small node will pick an index [5, 256). This index is that node's
>> permanent index. When storing a block, instead of storing the full block,
>> the node will use Reed-Solomon coding to erasure code the block using a
>> 5-of-256 scheme. The result will be 256 pieces that are 20% of the size of
>> the block each. The node picks the piece that corresponds to its index, and
>> stores that instead. (Indexes 0-4 are reserved for archival nodes -
>> explained later)
>>
>> The node is now storing a fragment of every block. Alone, this fragment
>> cannot be used to recover any piece of the blockchain. However, when paired
>> with any 5 unique fragments (fragments of the same index will not be
>> unique), the full block can be recovered.
>>
>> Nodes can optionally store more than 1 fragment each. At 5 fragments, the
>> node becomes a full archival node, and the chosen indexes should be 0-4.
>> This is advantageous for the archival node as the encoded data for the
>> first 5 indexes will actually be identical to the block itself - there is
>> no computational overhead for selecting the first indexes. There is also no
>> need to choose random indexes, because the full block can be recovered no
>> matter which indexes are chosen.
>>
>> When connecting to new peers, the indexes of each peer needs to be known.
>> Once peers totaling 5 unique indexes are discovered, blockchain download
>> can begin. Connecting to just 5 small node peers provides a >95% chance of
>> getting 5 uniques, with exponentially improving odds of success as you
>> connect to more peers. Connecting to a single archive node guarantees that
>> any gaps can be filled.
>>
>> A good encoder should be able to turn a block into a 5-of-256 piece set
>> in under 10 milliseconds using a single core on a standard consumer
>> desktop. This should not slow down initial blockchain download
>> substantially, though the overhead is more than a rounding error.
>>
>> *DoS Prevention:*
>>
>> A malicious node may provide garbage data instead of the actual piece.
>> Given just the garbage data and 4 other correct pieces, it is impossible
>> (best I know anyway) to tell which piece is the garbage piece.
>>
>> One option in this case would be to seek out an archival node that could
>> verify the correctness of the pieces, and identify the malicious node.
>>
>> Another option would be to have the small nodes store a cryptographic
>> checksum of each piece. Obtaining the cryptographic checksum for all 256
>> pieces would incur a nontrivial amount of hashing (post segwit, as much as
>> 100MB of extra hashing per block), and would require an additional ~4kb of
>> storage per block. The hashing overhead here may be prohibitive.
>>
>> Another solution would be to find additional pieces and brute-force
>> combinations of 5 until a working combination was discovered. Though this
>> sounds nasty, it should take less than five seconds of computation to find
>> the working combination given 5 correct pieces and 2 incorrect pieces. This
>> computation only needs to be performed once to identify the malicious peers.
>>
>> I also believe that alternative erasure coding schemes exist which
>> actually are able to identify the bad pieces given sufficient good pieces,
>> however I don't know if they have the same computational performance as the
>> best Reed-Solomon coding implementations.
>>
>> *Deployment:*
>>
>> Small nodes are completely useless unless the critical mass of 5 pieces
>> can be obtained. The first version that supports small node block downloads
>> should default everyone to an archival node (meaning indexes 0-4 are used)
>>
>> Once there are enough small-node-enabled archive nodes, the default can
>> be switched so that nodes only have a single index by default. In the first
>> few days, when there are only a few small nodes, the previously-deployed
>> archival nodes can help fill in the gaps, and the small nodes can be useful
>> for blockchain download right away.
>>
>> ----------------------------------
>>
>> This represents a non-trivial amount of code, but I believe that the
>> result would be a non-trivial increase in the percentage of users running
>> full nodes, and a healthier overall network.
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170420/9e3837a3/attachment-0001.html>;

📅 Original date posted:2017-04-09 📝 Original message:Have ...

2023-06-07T19:59:51+02:00

In reply to nevent1q…hy6k
_________________________

📅 Original date posted:2017-04-09
📝 Original message:Have you read the cuckoo cycle paper? Finding cycles in massive graphs is
just about the worst thing to use an ASIC for.

It might be a hitherto before unknown emergent property of cryptocurrencies
in general that POW *must* change every 7-9 years. Could bake that into
the protocol too...

On Apr 9, 2017 7:51 PM, "David Vorick" <david.vorick at gmail.com> wrote:

>
>
> On Apr 9, 2017 7:00 PM, "Jared Lee Richardson via bitcoin-dev" <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> I can speak from personal experience regarding another very prominent
> altcoin that attempted to utilize an asic-resistant proof of work
> algorithm, it is only a matter of time before the "asic resistant"
> algorithm gets its own Asics. The more complicated the algorithm, the more
> secretive the asic technology is developed. Even without it,
> multi-megawatt gpu farms have already formed in the areas of the world with
> low energy costs. I'd support the goal if I thought it possible, but I
> really don't think centralization of mining can be prevented.
>
> On Apr 9, 2017 1:16 PM, "Erik Aronesty via bitcoin-dev" <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Curious: I'm not sure why a serious discussion of POW change is not on
>> the table as a part of a longer-term roadmap.
>>
>> Done right, a ramp down of reliance on SHA-256 and a ramp-up on some of
>> the proven, np-complete graph-theoretic or polygon manipulation POW would
>> keep Bitcoin in commodity hardware and out of the hands of centralized
>> manufacturing for many years.
>>
>> Clearly a level-playing field is critical to keeping centralization from
>> being a "defining feature" of Bitcoin over the long term. I've heard the
>> term "level playing field" bandied about quite a bit. And it seems to me
>> that the risk of state actor control and botnet attacks is less than
>> state-actor manipulation of specialized manufacturing of "SHA-256 forever"
>> hardware. Indeed, the reliance on a fairly simple hash seems less and
>> less likely a "feature" and more of a baggage.
>>
>> Perhaps regular, high-consensus POW changes might even be *necessary* as
>> a part of good maintenance of cryptocurrency in general. Killing the
>> existing POW, and using an as-yet undefined, but deployment-bit ready POW
>> field to flip-flop between the current and the "next one" every 8 years or
>> or so, with a ramp down beginning in the 7th year.... A stub function that
>> is guaranteed to fail unless a new consensus POW is selected within 7
>> years.
>>
>> Something like that?
>>
>> Haven't thought about it *that* much, but I think the network would
>> respond well to a well known cutover date. This would enable
>> rapid-response to quantum tech, or some other needed POW switch as well...
>> because the mechanisms would be in-place and ready to switch as needed.
>>
>> Lots of people seem to panic over POW changes as "irresponsible", but
>> it's only irresponsible if done irresponsibly.
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> The real bottleneck today is the amount of capex required to achieve
> optimal mining. I am strongly in favor of PoW research that investigates
> better PoW, but I do not think that any obvious strategies are known yet to
> improve substantially on computation heavy hashcash.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170409/7a8d0a1e/attachment.html>;

📅 Original date posted:2017-04-09 📝 Original ...

2023-06-07T19:59:50+02:00

In reply to nevent1q…uuu9
_________________________

📅 Original date posted:2017-04-09
📝 Original message:Curious: I'm not sure why a serious discussion of POW change is not on the
table as a part of a longer-term roadmap.

Done right, a ramp down of reliance on SHA-256 and a ramp-up on some of the
proven, np-complete graph-theoretic or polygon manipulation POW would keep
Bitcoin in commodity hardware and out of the hands of centralized
manufacturing for many years.

Clearly a level-playing field is critical to keeping centralization from
being a "defining feature" of Bitcoin over the long term. I've heard the
term "level playing field" bandied about quite a bit. And it seems to me
that the risk of state actor control and botnet attacks is less than
state-actor manipulation of specialized manufacturing of "SHA-256 forever"
hardware. Indeed, the reliance on a fairly simple hash seems less and
less likely a "feature" and more of a baggage.

Perhaps regular, high-consensus POW changes might even be *necessary* as a
part of good maintenance of cryptocurrency in general. Killing the
existing POW, and using an as-yet undefined, but deployment-bit ready POW
field to flip-flop between the current and the "next one" every 8 years or
or so, with a ramp down beginning in the 7th year.... A stub function that
is guaranteed to fail unless a new consensus POW is selected within 7
years.

Something like that?

Haven't thought about it *that* much, but I think the network would respond
well to a well known cutover date. This would enable rapid-response to
quantum tech, or some other needed POW switch as well... because the
mechanisms would be in-place and ready to switch as needed.

Lots of people seem to panic over POW changes as "irresponsible", but it's
only irresponsible if done irresponsibly.

On Fri, Apr 7, 2017 at 9:48 PM, praxeology_guy via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Jimmy Song,
>
> Why would the actual end users of Bitcoin (the long term and short term
> owners of bitcoins) who run fully verifying nodes want to change Bitcoin
> policy in order to make their money more vulnerable to 51% attack?
>
> If anything, we would be making policy changes to prevent the use of
> patented PoW algorithms instead of making changes to enable them.
>
> Thanks,
> Praxeology Guy
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170409/d885a90e/attachment.html>;

📅 Original date posted:2017-04-07 📝 Original message:It is ...

2023-06-07T19:59:21+02:00

In reply to nevent1q…qtag
_________________________

📅 Original date posted:2017-04-07
📝 Original message:It is *not proof of stake.* when:

a) burn happens regardless of whether you successfully mine.
b) miner cannot know which tx are burns
c) the majority of burns cannot be used for mining and are simply lost
(poisson discovery distribution)
d) burn involves real risk: *every bit as much at stake *

(It's the difference between a computer secured by not being connected to
the internet, and a computer secured by re-imaging from a computer that
was, in the past, not connected to the internet.)

It is possible to craft a burn-network such that the only way for a miner
to prevent a burn is to prevent all transactions other than his own.

This is still a weakness, and I can't see a way around it though.

On Fri, Apr 7, 2017 at 8:59 AM, Jannes Faber via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

>
> On 6 April 2017 at 19:13, Alex Mizrahi via bitcoin-dev <bitcoin-dev at lists.
> linuxfoundation.org> wrote:
>
>>
>> Ethically, this situation has some similarities to the DAO fork.
>>
>>
>> Much better analogy:
>>
>> 1. An ISV make software which makes use of an undocumented OS feature.
>> 2. That feature is no longer present in the next OS release.
>> 3. ISV suffers losses because its software cannot work under new OS, and
>> thus people stop buying it.
>>
>> I think 99% of programmers would agree that this loss was inflicted by a
>> bad decision of ISV, and not by OS vendor changing OS internals. Relying on
>> undocumented features is something you do on your own risk.
>>
>
> Right. And in this case, code still is law: if the code specifies a
> version number field and some miner finds an optimization that only works
> when the version number == 1 then it's his own problem once the network
> upgrades to version 2. In no way is there anything ethical about blocking
> the upgrade.
>
> History is not an indicator of the possible values any field can hold in
> the future. Limiting your operation to some arbitrary subset is at your own
> risk.
>
> Regarding the comparison: I haven't heard anyone even suggest rolling back
> the last year of the blockchain to undo the damage already done, any
> comparison can end there. If Jonathan wants to persist with this comparison
> it would be more like people deciding to stop further funding of the hacked
> contract. Yeah, that evil.
>
> --
> Jannes Faber
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170407/0c0e32b0/attachment-0001.html>;

📅 Original date posted:2017-04-06 📝 Original message:If the ...

2023-06-07T19:59:18+02:00

In reply to nevent1q…qcjq
_________________________

📅 Original date posted:2017-04-06
📝 Original message:If the primary purpose of pow is to destroy value, then a masked proof of
burn to an expanded address that assigns the private key holder the right
to mine only in the next Nth block would be sufficient. Expanding the
address space so that addresses can only be proven invalid only with the
private key. Miners can then not trivially game the system by excluding
tx...without killing the entire system. ( Like POW ... miners lose many
burns since only one valid proof is deterministically selected. Difficult
adjusted upward based on the number of valid proofs per block.)

The other part of "real POW" is that miners take *time* to mine. Proof of
destroyed value us not sufficient. Proof of time spent is critical....
something even a masked burn cannot provide.

On Apr 5, 2017 10:49 PM, "Peter Todd via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> On Wed, Apr 05, 2017 at 07:39:08PM -0700, Bram Cohen wrote:
> > On Wed, Apr 5, 2017 at 7:31 PM, Peter Todd via bitcoin-dev <
> > > While I'm in favour of blocking covert usage of ASICBOOST, there's
> every
> > > reason
> > > to block non-covert usage of it as well. In a low margin business like
> > > mining,
> > > the advatange it gives is enormous - quite possibly 10x your profit
> margin
> > > -
> > > and given that barrier free access to being able to purchase ASICs is
> > > already
> > > an archilles heal for Bitcoin there is every reason to eliminate this
> legal
> > > vulnerability. Additionally, it's a technical vulnerability as well: we
> > > want
> > > getting into the ASIC manufacturing and design business to have as low
> > > barriers
> > > to entry as is feasible, and the ASICBOOST exploit significantly
> increases
> > > the
> > > minimum capital requirements to do so.
> > >
> >
> > Asicboost also has the problem that it isn't treating the hashing as a
> > black box, and thus has impacts on what gets mined. In particular it
> > creates an incentive to make blocks smaller. That's a very unwanted
> effect,
> > and anything like it should be engineered out on principle.
>
> Agreed! There's no benefit to Bitcoin for having it - one way or the other
> miners are going to destroy ~12BTC/block worth of energy. Meanwhile it
> appears
> to have lead to something like a year of stupid political bullshit based
> on a
> secret advantage - there's no reason to invite a repeat of this episode.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170405/5b8d1ed4/attachment-0001.html>;

📅 Original date posted:2016-08-07 📝 Original message:I ...

2023-06-07T19:52:14+02:00

In reply to nevent1q…flfr
_________________________

📅 Original date posted:2016-08-07
📝 Original message:I still feel like you're better off getting rid of "hot wallets" and use
lightning-esqe networks to route orders. I don't think either speed or
flexibility is an issue there.

IMO, the point of Bitcoin is to avoid the centralization that seems to be
happening on the network now. By making "hot wallets" more "secure", we
encourage things to keep heading downhill with massive centralized
crappy-security exchanges.

Because, ultimately, there's no security that will prevent an inside job.
And all of these thefts have, in my opinion, been at least partly inside
jobs.

And centralization is the actually demon that needs slaying here.

A client-side library with P2P order routing, tether.to + bitcoin .... and
you've got a decentralized exchange... with orders matched to users
directly, and channel-trades executed instantly. And "market makers"
running nodes to facilitate routing, etc.

No center... nothing to shut down or sue... and no one holds your funds.
That's a real Bitcoin exchange.

On Sun, Aug 7, 2016 at 1:35 AM, Matthew Roberts via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> I'm wondering if we're fully on the same page here. What I was thinking
> was that this protection mechanism would be applied to the coins in the hot
> wallet (I wasn't talking about moving coins from the cold wallet to the hot
> wallet -- though such a mechanism is also needed.)
>
> With the hot wallet you would have an output script that only allowed
> coins to be sent to a new transaction whose output script was then only
> redeemable after N confirmations (the output is relative time-locked) but
> which can also be recovered to a fixed fail-safe address before the
> time-lock is reached (exactly like TierNolan already listed only the
> time-locked destination shouldn't be completely fixed.) So the private key
> for this hot wallet can still sign valid transactions to withdraw coins to
> any known destination and these transactions still reach the blockchain.
>
> The key difference from a regular transaction is that the destination only
> has access to the coins -after- the relative time-lock is reached (N blocks
> after first confirm) so everyone knows where withdrawals are suppose to be
> going and how many coins are being withdrawn at any given time. Deposits to
> the hot wallet would therefore need to be encumbered by the same protection
> so that from then on this time-lock to redeem coins can be applied to every
> new transaction trying to move coins (withdrawn by a user of the exchange
> or sent to the cold wallet.)
>
> Notice we don't care about the destination in the TX script for the hot
> wallet because to process user's withdrawals we can't know ahead of time
> where they need to be sent (so it isn't possible to use a fixed address
> here – though you might want to remove the clearing phase and set a fixed
> address for coins sent from the hot wallet to the cold wallet.) The benefit
> here comes from being able to see what withdrawals are being cleared,
> matching those up to our expectations, and being able to "cancel"
> withdrawals if they look suspicious, and you get the benefits for transfers
> made from the hot wallet to the cold wallet and visa-versa.
>
>
> This approach is good for a number of crucial services:
>
> 1. Wallets could be built that grouped coins into different "accounts"
> with different time-frames required for clearing / unlocking coins. Your
> savings or investment account would say -- take up to a week to clear --
> whereas your everyday account used for smaller purchases (with less money)
> would only take a few hours. This could all be linked up to services that
> notified you of your money being moved + made any phone calls needed to
> verify any larger transfers.
>
> The service could also be entrusted with the “cancellation” key which can
> only be used to move money to your offline fail-safe address. This would be
> quite an interesting way to mitigate fraud without the user having to be
> trusted to do anything (except I suppose – not storing their recovery keys
> online … but this could be partially solved with BIP 32-style “master”
> public keys + hardware wallets + multi-sig, N factor auth, etc ...)
>
> 2. Gambling websites that process a lot of Bitcoins also have a hot wallet
> which could be better protected by this.
>
> 3. Various other e-commerce websites also accept Bitcoins directly. (Deep
> web markets come to mind -- hey, people breaking the law need good security
> too.)
>
> 4. Provable dead man's switches on the protocol level is another idea --
> no need to keep special time-locked transactions around and rely on them to
> be broadcast = more reliable escrow services.
>
> 5. And obviously exchange hot (and cold) wallets - enemy number 1.
>
> I hope that makes sense. I think I initially managed to confuse a lot of
> people by talking about revoking transactions / “settlement layers”, etc.
> But IMO: all of this needs to take place on the blockchain with a new set
> of OP_CODES and other than the fixed address issue with OP_SPENDTO, I think
> the general idea would still work.
>
>
> tl; dr, A pseudo-reversal mechanism for transactions would mean that
> stolen private keys were no longer such an issue. This is desperately
> needed for exchanges, wallets, and other services that are forced to manage
> private keys, and whose users (I argue) already expect for this to be
> possible (or at least will when they're hacked.)
>
>
>
>
> On Sat, Aug 6, 2016 at 9:13 PM, Tier Nolan via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> On Sat, Aug 6, 2016 at 11:39 AM, s7r via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> * reversal of transactions is impossible
>>>
>>
>> I think it would be more accurate to say that the requirement is that
>> reversal doesn't happen unexpectedly.
>>
>> If it is clear in the script that reversal is possible, then obviously
>> the recipient can take that into consideration.
>>
>>
>>> * keep private keys private and safe. Lose them, it's like losing cash,
>>> you can just forget about it.
>>>
>>
>> Key management is a thing. Managing risk by keeping some keys offline is
>> an important part of that.
>>
>>
>>> * while we try hard to make 0-conf as safe as possible (if there's no
>>> RBF flag on the transaction), we make it almost impossible or very very
>>> expensive to reverse a confirmed transaction.
>>>
>>
>> BitGo has an "instant" system where they promise to only sign one
>> transaction for a given output. If you trust BitGo, then this is safe from
>> double spending, since a double spender can't sign two transactions.
>>
>> If BitGo had actually implemented a daily withdrawal limit, then their
>> system ends up similar to cold storage. Only 10% of the funds at Bitfinex
>> could have been withdrawn before manual intervention was required (with
>> offline keys).
>>
>> Who will accept
>>> such an input and treat it as a payment if it can be reversed during the
>>> settlement layer?
>>
>>
>> Obviously, if a payment is reversible, then you treat it as a reversible
>> payment. The protection here relates to moving coins from the equivalent
>> of cold storage to hot storage.
>>
>> It is OK if it takes longer, since security is more important than
>> convenience for coins in cold storage.
>>
>>
>>> The linked page describes that merchants will never accept payments from
>>> 'vaults', and it will take 24 hours for coins to be irreversible moved
>>> outside the 'vault'.
>>
>>
>> This relates to the reserves held by the exchange. A portion of the
>> funds are in hot storage with live keys. These funds can be stolen by
>> anyone who gets access to the servers. The remaining funds are held in
>> cold storage and they cannot be accessed unless you have the offline keys.
>> These funds are supposed to be hard to reach and require manual
>> intervention.
>>
>> I think this is a wrong approach. hacks and big losses are sad, but all
>>> the time users / exchanges are to blame for wrong implementations or
>>> terrible security practices.
>>>
>>
>> Setting up offline keys to act as firebreaks is part of good security
>> practices.
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160807/528041a5/attachment.html>;

📅 Original date posted:2016-06-22 📝 Original message:> ...

2023-06-07T19:51:27+02:00

In reply to nevent1q…k0rx
_________________________

📅 Original date posted:2016-06-22
📝 Original message:> Only large merchants are able to maintain such an infrastructure; (even
> Coinbase recently failed at it, they forgot to update their
> certificate). For end users that is completely unpractical.
>

Payment protocol is for when you buy stuff from purse.io, not really needed
for face-to face transfers, end users, IMO.

> The same benefit can be achieved without the complexity of BIP70, by
> extending the Bitcoin URI scheme. The requestor is authenticated using
> DNSSEC, and the payment request is signed using an EC private key. A
> domain name and an EC signature are short enough to fit in a Bitcoin URI
> and to be shared by QR code or SMS text.
>
> bitcoin:address?amount=xx&message=yyy&name=john.example.com&sig=zzz
>

I agree. A TXT record at that name could contain the pubkey.

> That extension is sufficient to provide authenticated requests, without
> requiring a https server. The signed data can be serialized from the
> URI, and DNSSEC verification succeeds without requesting extra data from
> the requestor. The only assumption is that the verifier is able to make
> DNS requests.
>

The problem is that there's no way for a merchant to *refuse *a payment
without a direct communication with the merchant's server. Verify first
/ clear later is the rule. Check stock, ensure you can deliver, and clear
the payment on the way out the door.

Also, as a merchant processing monthly subscriptions, you don't want the
first time you hear about a user's payment to be *after *it hits the
blockchain. You could add a refund address to deal with it after the
fact... stuff a refund address int OP_RETURN somehow?

bitcoin:address?amount=xx&currency=ccc&message=yyy&name=john.example.com
&offset=3d&interval=1m&sig=zzz

... But what if the merchant simply goes out of business. No OP_RETURN
will help you here. You'll be posting transactions into a dead wallet.
You could have some way of posting a "ping" transaction, and then
monitoring for a valid response. But this is "spamming the blockchain for
communications".

No, I think BIP075 is fine. You just need to extend the *PaymentAck *with
a single field, instead of just having a memo.

next_payment_days : integer

The wallet, when it sees this field, re-initiates an invoice request after
the selected number of days, after presenting the user with the content of
the memo field which will presumably explain the subscription. Wallet
vendors can let users "auto approve" vendors as needed.

This is, I think, the absolute minimum needed to update BIP0070/0075 for
subscriptions.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160622/69c8ccf9/attachment.html>;

📅 Original date posted:2016-06-21 📝 Original message:> ...

2023-06-07T19:51:18+02:00

In reply to nevent1q…u3q8
_________________________

📅 Original date posted:2016-06-21
📝 Original message:> keybase spam

good point about keybase spam, but i think it's limited to once hash per
hour (?), not really too bad... the tx's are just root signatures, so you
can verify a whole keybase tree (up to the last hour) with very minimal
bitcoin blockchain impact.

> What do you mean by "replacement addresses" and "UI confirms" here?

"Replacement addresses" would take the place of BIP 32/47 support, if
someone thought maybe that was too difficult to deal with. So each time i
paid Alice, Alice could generate a new payment address for the next monthly
payment. If you support BIP 32 pub seed, then there's no need for this.
I don't know any wallets that support a BIP 32 pub seed (and then what,
some random number generator?) as a destination address yet.

> Disagree with hard-coding intervals, or mandating specific policies from
the
service providers.

I think mandating is a harsh word here, but i I'm a strong believer in
providing strict guidelines that if people break, others can call them
on. Giving someone a 12.3 +/- 5 day interval for payments using this
protocol would suck. You should use payment channels for that stuff.
The idea is a lightweight protocol for getting monthly subscriptions
working.

On Tue, Jun 21, 2016 at 4:44 PM, Luke Dashjr <luke at dashjr.org> wrote:

> On Monday, June 20, 2016 5:33:32 PM Erik Aronesty via bitcoin-dev wrote:
> > BIP 0070 has been a a moderate success, however, IMO:
> >
> > - protocol buffers are inappropriate since ease of use and extensibility
> is
> > desired over the minor gains of efficiency in this protocol. Not too
> late
> > to support JSON messages as the standard going forward
>
> IMO JSON is too prone to gratuitous inefficiency (both at network and CPU
> level), parser bugs, etc. Even the best C implementation (jansson) has
> serious
> issues with Number handling.
>
> A few years ago, I looked into binary alternatives to JSON and concluded
> they
> all had problems, while it seems more than reasonable to do even dynamic
> parsing of protobuf messages. So to conclude, I prefer to stick to protobuf
> unless a clearly superior protocol turns up.
>
> > - problematic reliance on merchant-supplied https (X509) as the sole form
> > of mechant identification. alternate schemes (dnssec/netki), pgp and
> > possibly keybase seem like good ideas. personally, i like keybase,
> since
> > there is no reliance on the existing domain-name system (you can sell
> with
> > a github id, for example)
>
> X509 is entrenched, so it should remain supported. PGP might make sense for
> people already using it (it provides no real security for un-WoT-networked
> users), but unforunately, few people use it. Correct me if I'm wrong, but
> IIRC
> Keybase uses blockchain spam, so definitely not something to be encouraged
> if
> so. Namecoin seems like a more than reasonable decentralised solution, but
> will probably take some real work to implement (not that this is avoidable
> for
> a general-usage decentralised solution).
>
> > - missing an optional client supplied identification
>
> What do you mean by this? There's the memo field at least.
>
> > - lack of basic subscription support
> >
> > *Proposed for subscriptions:*
> >
> > - BIP0047 payment codes are recommended instead of wallet addresses when
> > establishing subscriptions. Or, merchants can specify replacement
> > addresses in ACK/NACK responses. UI confirms are *required *when there
> > are no replacement addresses or payment codes used.
>
> I'd discourage anything using BIP 47 due to its serious design flaws.
> No reason a regular BIP 32 pub seed can't be used instead.
>
> What do you mean by "replacement addresses" and "UI confirms" here?
>
> > - Wallets must confirm and store subscriptions, and are responsible for
> > initiating them at the specified interval.
> >
> > - Intervals can *only *be from a preset list: weekly, biweekly, or 1,
> > 2,3,4,6 or 12 months. Intervals missed by more than 3 days cause
> > suspension until the user re-verifies.
>
> Disagree with hard-coding intervals, or mandating specific policies from
> the
> service providers.
>
> > - Wallets *may *optionally ask the user whether they want to be notified
> > and confirm every interval - or not. Wallets that do not ask *must
> > *notify before initiating each payment. Interval confirmations should
> > begin at *least *1 day in advance of the next payment.
>
> This is wallet policy, but maybe makes sense as a "best practices" BIP.
>
> > *Proposed in general:*
> > - JSON should be used instead of protocol buffers going forward. Easier
> to
> > use, explain extend.
> >
> > - "Extendible" URI-like scheme to support multi-mode identity mechanisms
> on
> > both payment and subscription requests. Support for keybase://,
> netki://
> > and others as alternates to https://.
> >
> > - Support for client as well as merchant multi-mode verification
> >
> > - Ideally, the identity verification URI scheme is somewhat
> > orthogonal/independent of the payment request itself
> >
> > Question:
> >
> > Should this be a new BIP? I know netki's BIP75 is out there - but I
> think
> > it's too specific and too reliant on the domain name system.
> >
> > Maybe an identity-protocol-agnostic BIP + solid implementation of a
> couple
> > major protocols without any mention of payment URI's ... just a way of
> > sending and receiving identity verified messages in general?
> >
> > I would be happy to implement plugins for identity protocols, if anyone
> > thinks this is a good idea.
> >
> > Does anyone think https:// or keybase, or PGP or netki all by
> themselves,
> > is enough - or is it always better to have an extensible protocol?
> >
> > - Erik Aronesty
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160621/9920f0c4/attachment.html>;

📅 Original date posted:2016-06-21 📝 Original message:On ...

2023-06-07T19:51:17+02:00

In reply to nevent1q…vzjz
_________________________

📅 Original date posted:2016-06-21
📝 Original message:On Tue, Jun 21, 2016 at 5:43 AM, Andreas Schildbach via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Protobuf vs. JSON was a deliberate decision. Afaik Protobuf was chosen
> because of its strong types, less vulnerability to malleability and very
> good platform support. Having coded both, I can say Protobuf is not more
> difficult than JSON. (Actually the entire Bitcoin P2P protocol should be
> based on Protobuf, but that's another story.)
>

I like protobuf, personally, for C++ stuff. I just imagined it would be
harder on mobile, or in some languages, to implement. I'll focus on the
scheduling issue. Really, that's the only thing I want hashed out.

>
> Yes, all extensions to BIP70 should go into new BIPs. Note the plural
> here: if you have orthogonal ideas I strongly suggest one BIP per idea
> so they can be discussed and implemented (or rejected) separately.
>
>
I think the intervals should *not* be flexible, even at the protocol level,
to prevent attacks designed to confuse users - plus for shorter intervals,
you need payment channels anyway. Also, I think the spec should be rigid
with respect to response times, retry periods, etc.... to encourage
consistency among wallet vendors. Not sure how anyone else feels about
that. I suspect the netki guys should have opinions, since they are
working on similar UI-stuff.

Should UI standards go somewhere else - not in a BIP? I do think there
need to be UI standards. Something with RFC-style should/must/will/wont
language, like "Wallet software *must* show unconfirmed transactions as
distinct from confirmed", and "Wallet software *should *show some visual
indication of other levels of confirmation" .... stuff like that.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160621/3d77b01a/attachment.html>;