Re: [bitcoin-dev] Bitcoin covenants are inevitable

[Jorge Timón via bitcoin-dev]

Who do you mean by "the non technical folks"?
You don't include alicexbt or yourself as a "technical folk", do you?


On Wed, Jun 8, 2022 at 8:38 AM Billy Tetrud via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Wholeheartedly agree with you alicexbt. There are no technical issues that
> have been shown that I'm aware of. Once the non-technical folks have time
> to discuss it and realize that, I'm hopeful things will move forward.
> Perhaps we can learn from this and figure out how to better catch the
> attention of the larger bitcoin community  for important changes without
> alarming them.
>
> On Sun, Jun 5, 2022 at 2:48 AM alicexbt via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Hi Jorge,
>>
>>
>> Misinformation is false or inaccurate information, especially that which
>> is deliberately intended to deceive. A combination of 'misleading' and
>> 'information'. Here are a few examples and I am sure I missed a lot of
>> others but its difficult for me to keep a track of everything:
>>
>>
>> 1) Sapio is open source and everything mentioned in tweet is false:
>> https://web.archive.org/web/20220503050140/https://twitter.com/coinableS/status/1521354192434073602
>>
>> 2) Personal attacks on author of BIP 119 with false information:
>> https://nitter.net/s3cp256k1/status/1521238634111770624
>>
>> 3) Andreas Antonopoulos shared false things about CTV and explained by
>> Ryan in this email:
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020414.html
>>
>> 4) Misleading things shared in these emails by Michael Folkson:
>>
>>
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019728.html
>>
>>
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020235.html
>>
>>
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020286.html
>>
>>
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020343.html
>>
>>
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020386.html
>>
>> 5) Peter Todd and Zac shared misleading things about BIP 119, bitcoin and
>> L2. I replied in this email:
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020322.html
>>
>> 6) Social media influencers like Peter McCormack tweeted they don't
>> understand BIP 119 but its an attack (this was even retweeted by developers
>> like Peter Todd):
>> https://nitter.net/PeterMcCormack/status/1521253840963653632
>>
>> 7) Some misconceptions about BIP 119 cleared by Bitcoin Magazine:
>> https://bitcoinmagazine.com/technical/what-is-bip-119-bitcoin-controversy-explained
>>
>> 8) There were lies and misinformation about BIP 119 on social media
>> according to this Bitcoin Magazine article:
>> https://bitcoinmagazine.com/technical/analyzing-bip119-and-the-controversy-surrounding-it
>>
>> 9) John Carvalho tweeting false things:
>>
>> https://nitter.net/BitcoinErrorLog/status/1468599535538745359
>>
>> https://nitter.net/BitcoinErrorLog/status/1522652884218822658
>>
>> https://nitter.net/BitcoinErrorLog/status/1442554615967354880
>>
>> https://nitter.net/search?q=MIT%20(from%3ABitcoinErrorLog)
>>
>> 10) Greg Maxwell responding to misinformation related to BIP 119 but
>> adding false things in the comments:
>> https://www.reddit.com/r/Bitcoin/comments/uim560/bip_119/i7dhfpb/
>>
>>
>> I am not surprised by your email but it would be better if the people who
>> are interested in reviewing BIP 119 could raise the bar and not share
>> misleading information.
>>
>>
>> /dev/fd0
>>
>>
>> Sent with Proton Mail secure email.
>> --- Original Message ---
>> On Sunday, June 5th, 2022 at 12:12 AM, Jorge Timón 
>> wrote:
>>
>>
>> > "Some people say CTV is contentious, but they're spreading
>> misinformation"? Really? Seriously?Come on, guys, we can do better than
>> nina jankovich and the "fact checkers".
>> > Please, rise the bar.
>> > On Fri, Jun 3, 2022, 19:44 alicexbt via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>> >
>> > > 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 type

Re: [bitcoin-dev] Bitcoin covenants are inevitable

[Jorge Timón via bitcoin-dev]

"Some people say CTV is contentious, but they're spreading misinformation"?
Really? Seriously?
Come on, guys, we can do better than nina jankovich and the "fact checkers".

Please, rise the bar.

On Fri, Jun 3, 2022, 19:44 alicexbt via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Note: This email is an opinion and not an attack on bitcoin
>
> Covenants on bitcoin will eventually be implemented with a soft fork. CTV
> is the easiest and best possible way OP_TX looks good as well. Apart from
> the technical merits, covenants will improve a few other things:
>
> - Developers can build interesting projects with real demand in market.
> - Students learn Sapio and not just solidity.
> - Better tooling could be available for application developers.
> - Maybe we see bitcoin developer hackathons in different countries.
> - Demand for block space might increase, it wont be just exchanges and
> coinjoin.
> - Funding of bitcoin developers and projects might improve. Wont need to
> convince a few people for grants.
>
> **Why covenants are not contentious?**
>
> Some people may write paragraphs about CTV being contentious, spread
> misinformation and do all types of drama, politics etc. on social media but
> there are zero technical NACKs for CTV. We have discussed other covenant
> proposals in detail on mailing list and IRC meetings with an open minded
> approach.
>
> All the developers that participated in the discussion are either okay
> with CTV or OP_TX or covenants in general.
>
> **How and when should covenants be implemented in Bitcoin?**
>
> I don't think we should wait for years anticipating a proposal that
> everyone will agree on or argue for years to pretend changes are hard in
> Bitcoin. We should improve the review process for soft fork BIPs and share
> honest opinions with agreement, disagreement on technical merits.
>
> I prefer BIP 8 or improved BIP 8 for soft fork but I won't mind anything
> else being used if that improves Bitcoin. Covenants implemented in Bitcoin
> before the next cycle would provide opportunity for developers to build
> interesting things during the bear market. Ossification supporters also
> believe there is some window that will close soon, maybe doing changes
> considering each case individually will be a better approach. CTV is not a
> rushed soft fork, less people followed the research and it was not
> mentioned on social media repeatedly by the respected developers like other
> soft forks.
>
> /dev/fd0
>
>
> Sent with Proton Mail secure email.
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] CTV BIP Meeting #8 Notes

[Jorge Timón via bitcoin-dev]

I think something like visacoin could be kind of feasible without recursive
covenants. But as billy points out, I guess they could kind of do it with
multisig too.

I fail to understand why non recursive covenants are called covenants at
all. Probably I'm missing something, but I guess that's another topic.


On Tue, May 10, 2022 at 5:11 PM Billy Tetrud via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> >  So if you don't want to receive restricted coins, just don't generate
> an address with those restrictions embedded.
>
> This is an interesting point that I for some reason haven't thought of
> before. However...
>
> > Unless governments can mandate that you generate these addresses AND
> force you to accept funds bound by them for your services**, I don't
> actually see how this is a real concern.
>
> Actually, I think only the second is necessary. For example, if there was
> a law that compelled giving a good or service if payment of a publicly
> advertised amount was paid, and someone pays to an address that can be
> shown is spendable by the merchant's keys in a way that the government
> accepts, it doesn't matter whether the recipient can or has generated the
> address.
>
> Regardless I do think its still important to note that a government could
> do that today using multisig.
>
> > This is a reason to oppose legal tender laws for Bitcoin imo.
>
> I agree.
>
> On Mon, May 9, 2022 at 10:23 AM Keagan McClelland <
> keagan.mcclell...@gmail.com> wrote:
>
>> > > > To me the most scary one is visacoin, specially seeing what
>> happened in canada and other places lately and the general censorship in
>> the west, the supposed war on "misinformation" going on (really a war
>> against truth imo, but whatever) it's getting really scary. But perhaps
>> someone else can be more scared about a covenant to add demurrage fees to
>> coins or something, I don't know.
>> > > > https://bitcointalk.org/index.php?topic=278122
>>
>> > > This requires *recursive* covenants.
>>
>> > Actually, for practical use, any walled-garden requires *dynamic*
>> covenants, not recursive covenants.
>>
>> There's actually also a very straight forward defense for those who do
>> not want to receive "tainted" coins. In every covenant design I've seen to
>> date (including recursive designs) it requires that the receiver generate a
>> script that is "compliant" with the covenant provisions to which the sender
>> is bound. The consequence of this is that you can't receive coins that are
>> bound by covenants you weren't aware of*. So if you don't want to receive
>> restricted coins, just don't generate an address with those restrictions
>> embedded. As long as you can specify the spend conditions upon the receipt
>> of your funds, it really doesn't matter how others are structuring their
>> own spend conditions. So long as the verification of those conditions can
>> be predictably verified by the rest of the network, all risk incurred is
>> quarantined to the receiver of the funds. Worst case scenario is that no
>> one wants to agree to those conditions and the funds are effectively burned.
>>
>> It's not hard to make the case that any time funds are being transferred
>> between organizations with incompatible interests (external to a firm),
>> that they will want to be completely free to choose their own spend
>> conditions and will not wish to inherit the conditions of the spender.
>> Correspondingly, any well implemented covenant contract will include
>> provisions for escaping the recursion loop if some sufficiently high bar is
>> met by the administrators of those funds. Unless governments can mandate
>> that you generate these addresses AND force you to accept funds bound by
>> them for your services**, I don't actually see how this is a real concern.
>>
>> *This requires good wallet tooling and standards but that isn't
>> materially different than wallets experimenting with non-standard recovery
>> policies.
>>
>> **This is a reason to oppose legal tender laws for Bitcoin imo.
>>
>> Keagan
>>
>> On Sun, May 8, 2022 at 11:32 AM Billy Tetrud via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> >  This requires *recursive* covenants.
>>>
>>> Actually, for practical use, any walled-garden requires *dynamic*
>>> covenants, not recursive covenants. CTV can get arbitrarily close to
>>> recursive covenants, because you can have an arbitrarily long string of
>>> covenants. But this doesn't help someone implement visacoin because CTV
>>> only allows a specific predefined iteration of transactions, meaning that
>>> while "locked" into the covenant sequence, the coins can't be used in any
>>> way like normal coins - you can't choose who you pay, the sequence is
>>> predetermined.
>>>
>>> Even covenants that allow infinite recursion (like OP_TLUV and OP_CD
>>> )
>>> don't automatically allow for practical wall

Re: [bitcoin-dev] What to do when contentious soft fork activations are attempted

[Jorge Timón via bitcoin-dev]

It is quite ironic that yeah, it is quite ironic that the people who are
constantly basing their arguments on personal attack are also the ones who
complain the most about personal attacks. That's exactly the irony I was
trying to convey.
Just like some people claim that the only people against bip119 are people
ignorant about bip119, I can also claim that everyone against bip8 doesn't
really understand it, can't I?
The same people who spread the misinformation that bip8 "would be perceived
by most users as developers trying to dictate changes" are now complaining
about people spreading misinformation about their own proposals. I
personally find it as ironic as it can get.
I'm glad I'm not the only one who noticed how ironic the whole situation is.
How often are the people claiming to be concerned about misinformation
precisely the ones who spread the most misinformation?
Very ironic indeed.

On Fri, May 6, 2022 at 10:07 PM John Tromp via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Fri, 6 May 2022 7:17PM Jorge Tim?n wrote
> > But let's not personally attack andreas for his opinions.
> > The only reason you don't like bip8 is because you're ignorant about it
> and
> > you haven't reviewed it enough.
>
> Can you see the irony in equating "clueless about BIP119" with a
> personal attack and then calling Jeremy ignorant about BIP8?
>
> -John
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] CTV BIP Meeting #8 Notes

[Jorge Timón via bitcoin-dev]

I think people may be scared of potential attacks based on covenants. For
example, visacoin.
But there was a thread with ideas of possible attacks based on covenants.
To me the most scary one is visacoin, specially seeing what happened in
canada and other places lately and the general censorship in the west, the
supposed war on "misinformation" going on (really a war against truth imo,
but whatever) it's getting really scary. But perhaps someone else can be
more scared about a covenant to add demurrage fees to coins or something, I
don't know.

https://bitcointalk.org/index.php?topic=278122

For example, what if Justin Castro, sorry, Justin Trudeu mandated a
visacoin covenant for all withdrawals from canadian exchanges?
What if ursula von der mengele, sorry, von der leyen wants to do the same
in europe?
What if nina Nina Jankowicz decides visacoin covenants are the best way to
"stop misinformation"?

Covenants can enable many attacks on bitcoin, not just new cool features.

Now, perhaps I am crazy for thinking there's a war against truth going on,
I don't know.
Perhaps most devs and bitcoin users love those lying politicians I
mentioned.
Perhaps I'm too biased because my political views. Or perhaps the people
who don't consider Justin a criminal against humanity are biased.

I guess this goes beyond the scope of this mailing list though. Perhaps we
should go back to the bitcoin forums to discuss this kind of thing.





On Sat, May 7, 2022 at 10:54 AM alicexbt via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi Bitcoin Developers,
>
> Summary for the last CTV meeting:
>
> Topics:
>
> 1)APO version of the simple vault
> 2)APO as alternative to CTV
> 3)fiatjaf's CTV spacechain demo
> 4)Compare CTV with other covenant proposals
> 5)Recursive covenants
> 6)Responding to FUD
>
> ===
> APO version of the simple vault
> ===
>
> - It is vulnerable to the half-spend problem, where multiple vaulted
> outputs (of the same denomination) can be spent together, burning all but
> the first to fees. Fixing this requires amending APOAS to cover the current
> input index.
> - The unvault transaction is third-party malleable (it can have more
> inputs added to it). One practical implication is that you can't hand a
> list of the unvault txids to a watchtower, you have to tell them which
> outpoints to watch which is less privacy-preserving. Fixing this requires
> amending APOAS to cover the number of inputs.
> Both of these issues are fixed by the BIP 118 changes suggested by
> darosior (although they still not officially spec'd afaik), which would
> basically make APO have a CTV-equivalent hash mode (minus scriptSig of
> other inputs)
> - simple-apo-vault could use APO-as-spec'd with
> SIGHASH_SINGLE|SIGHASH_ANYONECANPAY, which would solve the half-spend
> problem (but not malleability) and have some other interesting properties,
> like more natural dynamic fees (add inputs+change) and the ability spend
> multiple vaulted outputs together. This would, however, introduce a tx
> pinning attack vector and prevent rate-limited vaults.
>
> ===
> APO as alternative to CTV
> ===
>
> - Current APO is unusable as a CTV alternative, (revised)APO seems to be
> as useful as CTV is (plus some extra flexibility from existing sighash
> flags)
> - Main drawbacks being the additional witness satisfaction cost, the
> network-side full-node validation costs of checking a signature instead of
> just a hash, and not being segwit0-compatible (meaning, among others, not
> quantumphobic-friendly)
> - Its about 3x for APO-in-taproot vs CTV-in-taproot. CTV-in-segwitv0 and
> CTV-in-bare-spk get you even more savings
> - APO is far from being ready, let alone (revised)APO
> - APOv2 would be both better for Eltoo and better for CTV, since you can
> use a trick to make the signatures smaller
> - "layered commitments" is essential for eltoo to be usable or not is
> unclear. AJ Towns thinks it is required while Christian Decker thinks it is
> not.
>
> ===
> fiatjaf's CTV spacechain demo
> ===
>
> https://github.com/fiatjaf/simple-ctv-spacechain
>
> ===
> Compare CTV with other covenant proposals
> ===
>
> Unlike crypto primitves (e.g., BLS vs Schnorr), there's not really
> actually a defined way to compare them. So one exercise of value would be
> if everyone tries to actually either agree to or come up with their own
> framework for comparing covenants.
>
> Billy Tetrud's email:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020402.html
>
> - Prefers CTV for several reasons. Mainly because of being simple,
> documentation, code, tools, revi

Re: [bitcoin-dev] Speedy covenants (OP_CAT2)

[Jorge Timón via bitcoin-dev]

Thanks a lot for the many clarifications.
Yeah, I forgot it wasn't OP_CAT alone, but in combination with other things.
I guess this wouldn't be a covenants proposal then.
But simplicity would enable covenants too indeed, no?
Or did I get that wrong too?

On Sat, May 7, 2022 at 5:06 AM ZmnSCPxj  wrote:

> Good morning Jorge,
>
> > OP_CAT was removed. If I remember correctly, some speculated that
> perhaps it was removed because it could allow covenants.I don't remember
> any technical concern about the OP besides enabling covenants.Before it was
> a common opinion that covenants shouldn't be enabled in bitcoin because,
> despite having good use case, there are some nasty attacks that are enabled
> with them too. These days it seems the opinion of the benefits being worth
> the dangers is quite generalized. Which is quite understandable given that
> more use cases have been thought since then.
>
> I think the more accurate reason for why it was removed is because the
> following SCRIPT of N size would lead to 2^N memory usage:
>
> OP_1 OP_DUP OP_CAT OP_DUP OP_CAT OP_DUP OP_CAT OP_DUP OP_CAT OP_DUP
> OP_CAT OP_DUP OP_CAT ...
>
> In particular it was removed at about the same time as `OP_MUL`, which has
> similar behavior (consider that multiplying two 32-bit numbers results in a
> 64-bit number, similar to `OP_CAT`ting a vector to itself).
>
> `OP_CAT` was removed long before covenants were even expressed as a
> possibility.
>
> Covenants were first expressed as a possibility, I believe, during
> discussions around P2SH.
> Basically, at the time, the problem was this:
>
> * Some receivers wanted to use k-of-n multisignature for improved security.
> * The only way to implement this, pre-P2SH, was by putting in the
> `scriptPubKey` all the public keys.
> * The sender is the one paying for the size of the `scriptPubKey`.
> * It was considered unfair that the sender is paying for the security of
> the receiver.
>
> Thus, `OP_EVAL` and the P2SH concept was conceived.
> Instead of the `scriptPubKey` containing the k-of-n multisignature, you
> create a separate script containing the public keys, then hash it, and the
> `scriptPubKey` would contain the hash of the script.
> By symmetry with the P2PKH template:
>
> OP_DUP OP_HASH160  OP_EQUALVERIFY OP_CHECKSIG
>
> The P2SH template would be:
>
> OP_DUP OP_HASH160  OP_EQUALVERIFY OP_EVAL
>
> `OP_EVAL` would take the stack top vector and treat it as a Bitcoin SCRIPT.
>
> It was then pointed out that `OP_EVAL` could be used to create recursive
> SCRIPTs by quining using `OP_CAT`.
> `OP_CAT` was already disabled by then, but people were talking about
> re-enabling it somehow by restricting the output size of `OP_CAT` to limit
> the O(2^N) behavior.
>
> Thus, since then, `OP_CAT` has been associated with ***recursive***
> covenants (and people are now reluctant to re-enable it even with a limit
> on its output size, because recursive covenants).
> In particular, `OP_CAT` in combination with `OP_CHECKSIGFROMSTACK` and
> `OP_CHECKSIG`, you could get a deferred `OP_EVAL` and then use `OP_CAT` too
> to quine.
>
> Because of those concerns, the modern P2SH is now "just a template" with
> an implicit `OP_EVAL` of the `redeemScript`, but without any `OP_EVAL`
> being actually enabled.
>
> (`OP_EVAL` cannot replace an `OP_NOP` in a softfork, but it is helpful to
> remember that P2SH was pretty much what codified the difference between
> softfork and hardfork, and the community at the time was small enough (or
> so it seemed) that a hardfork might not have been disruptive.)
>
> > Re-enabling OP_CAT with the exact same OP would be a hardfork, but
> creating a new OP_CAT2 that does the same would be a softfork.
>
> If you are willing to work in Taproot the same OP-code can be enabled in a
> softfork by using a new Tapscript version.
>
> If you worry about quantum-computing-break, a new SegWit version (which is
> more limited than Tapscript versions, unfortunately) can also be used,
> creating a new P2WSHv2 (or whatever version) that enables these opcodes.
>
> > As far a I know, this is the covenants proposal that has been
> implemented for the longest time, if that's to be used as a selection
> criteria.And as always, this is not incompatible with deploying other
> convenant proposals later.
>
> No, it was `OP_EVAL`, not `OP_CAT`.
> In particular if `OP_EVAL` was allowed in the `redeemScript` then it would
> enable covenants as well.
> It was just pointed out that `OP_CAT` enables recursive covenenats in
> combination with `OP_EVAL`-in-`redeemScript`.
>
> In particular, in combination with `OP_CAT`, `OP_EVAL` not only allows
> recursive covenants, but also recursion *within* a SCRIPT i.e. unbounded
> SCRIPT execution.
> Thus, `OP_EVAL` is simply not going to fly, at all.
>
> > Personally I find the simplicity proposal the best one among all the
> covenant proposals by far, including this one.But I understand that despite
> the name, the proposal is harder to review and te

Re: [bitcoin-dev] Speedy covenants (OP_CAT2)

[Jorge Timón via bitcoin-dev]

On Sat, May 7, 2022 at 5:52 AM  wrote:

> > Re-enabling OP_CAT with the exact same OP would be a hardfork, but
> creating a new OP_CAT2 that does the same would be a softfork.
>
> We have TapScript for that. OP_CAT is defined as OP_SUCCESS, it can be
> re-enabled in a soft-fork way. For now, OP_CAT in TapScript simply means
> "anyone can move those coins", so adding some restrictions is all we need
> to re-enable this opcode. Introducing OP_CAT2 is not needed at all, unless
> it will be totally different, but then it should not be named as OP_CAT2,
> but rather as OP_SOMETHING_ELSE, it depends how different it will be from
> OP_CAT.
>

Oh, well, I didn't know any of that. I guess it could be a modification of
OP_SUCCESS if it makes sense instead of a new opcode.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] What to do when contentious soft fork activations are attempted

[Jorge Timón via bitcoin-dev]

So, to be clear, you didn't design speedy trial "to make everyone unhappy"
as Ryan claims, no?
That's a really strange claim on his part.
When the grace period for slower activation after lock in was added, I
don't think it was added to make me or people like me who dislike that
proposal unhappy. On the contrary, I think the goal was precisely to
address some of our concerns.
But it doesn't address them all, as I've tried to explain other times.
I truly think you wanted to make everyone happy with speedy trial, but you
didn't do it, sorry.
I know it' not a lack of capacity because you did impressive and genius
things like simplicity.
But despite your best intentions and your great capacity, I still think
speedy trial is a very bad proposal because you got the analysis wrong.
Let me reiterate that this is not attack against you, but only against one
of your ideas.
Sorry if I sounded sarcastic, but I was trying to be sarcastic with ryan,
not with you.


On Fri, May 6, 2022 at 8:24 PM Russell O'Connor via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Fri, May 6, 2022 at 2:01 PM Jorge Timón via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>>
>> Russell O'Connor wrote the definitive explanation for how ST arose in
>>> the consensus process and how it was designed to make everyone
>>> unhappy.  It's a great explanation of what we went through last year.
>>>
>>>   https://r6.ca/blog/20210615T191422Z.html
>>>
>>> "On Building Consensus and Speedy Trial"
>>>
>>> on | 2021-06-15T19:14:22Z
>>> by | Russell O'Connor
>>>
>>
>> That's a lot of text, are you sure he said in there he designed speedy
>> trial to make everyone unhappy?
>> Well, if we're still talking about it, that proves that it failed at its
>> own design criterion of failing fast.
>>
>
> Quoting from https://r6.ca/blog/20210615T191422Z.html:
>
> > Speedy Trial’s design is not based on any sort of activation philosophy
> about failing fast.
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Speedy covenants (OP_CAT2)

[Jorge Timón via bitcoin-dev]

OP_CAT was removed. If I remember correctly, some speculated that perhaps
it was removed because it could allow covenants.
I don't remember any technical concern about the OP besides enabling
covenants.
Before it was a common opinion that covenants shouldn't be enabled in
bitcoin because, despite having good use case, there are some nasty attacks
that are enabled with them too. These days it seems the opinion of the
benefits being worth the dangers is quite generalized. Which is quite
understandable given that more use cases have been thought since then.

Re-enabling OP_CAT with the exact same OP would be a hardfork, but creating
a new OP_CAT2 that does the same would be a softfork.
As far a I know, this is the covenants proposal that has been implemented
for the longest time, if that's to be used as a selection criteria.
And as always, this is not incompatible with deploying other convenant
proposals later.
Personally I find the simplicity proposal the best one among all the
covenant proposals by far, including this one.
But I understand that despite the name, the proposal is harder to review
and test than other proposals, for it wouldn't simply add covenants, but a
complete new scripting language that is better in many senses.
Speedy covenants, on the other hand, is much simpler and has been
implemented for longer, so in principle, it should be easier to deploy in a
speedy manner.

What are the main arguments against speedy covenants (aka op_cat2) and
against deploying simplicity in bitcoin respectively?

Sorry if this was discussed before.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] What to do when contentious soft fork activations are attempted

[Jorge Timón via bitcoin-dev]

On Tue, May 3, 2022 at 4:36 PM Ryan Grant  wrote:

> On Sun, May 1, 2022 at 8:49 PM Jorge Timón via bitcoin-dev
>  wrote:
> > On Sun, May 1, 2022, 09:22 alicexbt via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> >> [...] Andreas is clueless about BIP 119 and other covenant
> >> proposals.  He is spreading misinformation and [...]
>
> > Clueless and spreading disinformation, you say?  What
> > misinformation, could you explain?
>
> First, OP_CTV covenants cannot restrict any address that the sender
> does not control.  OP_CTV just delivers auditable presigned
> transactions.  That's it!  OP_CTV's primary design constraint is to
> NOT empower new ways to do blacklists (which are already possible
> using unwanted-multisig).  That's not a statement about what Bitcoin
> should ultimately become, but rather what Bitcoin is likely ready for.
> Much like Bitcoin's design, the simplest possible covenant solution
> was chosen, so that it would be "dirt simple" to audit that the code
> does only what it should, and no more.
>
> Andreas used a few words of indecision to make excuses for not
> code-reviewing BIP119 or the pull request, while using a lot of words
> talking about: how dangerous any change is; conservative consensus
> process; and GovCoin blacklists.  This gave the strong impression that
> the change was dangerous and could easily lead to the creation of
> blacklists enforced by L1 consensus itself (rather than enforced by
> other signers in a sidechain or unwanted-multisig).
>
> Andreas also didn't look into the reason that the proposed client was
> safe and would not cause a chain split.  Speedy Trials by themselves
> don't risk chain splits, they poll.  There was no UASF in the planned
> executable.  Some devs hate ST because it puts the initiative in
> miner's hands to gauge **user support and readiness** - which those
> devs feel the miners have no reason to be good at - but that expires
> speedily.  If everyone loved the change and the trial was about to
> pass, except ornery users - who we love when UASF is needed, of
> course - were going to cause a chain split of their own to block it,
> then ST offers miners the capability to - very quickly, faster than a
> release can be pushed out - change their signaling to again prevent a
> chain split.
>

I don't think that's enough of a reason to justify you calling andreas
"clueless". I'm sure whatever andreas said, he said it with the best
intentions.
Remember:

- Avoid personal attacks

Accusing andreas of being clueless is spreading misinformation.

Russell O'Connor wrote the definitive explanation for how ST arose in
> the consensus process and how it was designed to make everyone
> unhappy.  It's a great explanation of what we went through last year.
>
>   https://r6.ca/blog/20210615T191422Z.html
>
> "On Building Consensus and Speedy Trial"
>
> on | 2021-06-15T19:14:22Z
> by | Russell O'Connor
>

That's a lot of text, are you sure he said in there he designed speedy
trial to make everyone unhappy?
Well, if we're still talking about it, that proves that it failed at its
own design criterion of failing fast.
But if you think my judgement about speedy trial (sorry, we discussed it
for so long that I forgot the BIP number, it wasn't eight, I remember that)
and I locked my mind in about speedy trial too soon and without giving
anyone a chance to coordinate about my personal signaling of the
proposal...I guess I can give you a grace period of 6 months to upgrade
your own mind about it and accept my judgment about it, so that concern
about my criticism on the proposal is addressed.
There may be a couple of people trying to create dissent about this opinion
of mine. But once all concerns are addressed...

Andreas also didn't look for a non-attack reason for a separate binary
> release.  (Here I feel like I should be naming a lot of devs as well,
> hmm.)  Let's go back to O'Connor, who reminds us of a faction from the
> last consensus change:
>
>   > The "devs-do-not-decide" faction's concern is regarding the
>   > appearance of Bitcoin developers deciding the rules of Bitcoin.
>   > [...]  This faction would be fine with users building their own
>   > alternative client for forced activation, or a configuration flag
>   > for enabling some kind of forced activation that is not enabled by
>   > default.
>

Yeah, I know, both speedy trial and CTV could be perceived as developers
trying to dictate rules.
I guess that criticism against bip8 can be applied from now on to any
proposal forever. what a great precedent.
It's not always that software designers 

Re: [bitcoin-dev] What to do when contentious soft fork activations are attempted

[Jorge Timón via bitcoin-dev]

On Sun, May 1, 2022, 09:22 alicexbt via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi Michael,
>
> Maybe the whole thing worked as designed. Some users identified what was
> going on, well known Bitcoin educators such as Andreas Antonopoulos, Jimmy
> Song etc brought additional attention to the dangers, a URSF movement
> started to gain momentum and those attempting a contentious soft fork
> activation backed off. (Disappointingly Bitcoin Optech didn't cover my
> previous posts to this mailing list 1
> ,
> 2
> ,
> 3
> 
> highlighting the dangers many months ago or recent posts. Normally Optech
> is very high signal.)
>
>
> Some users have been misled and there is nothing great being achieved by
> doing this on social media. Andreas is clueless about BIP 119 and other
> covenant proposals. He is spreading misinformation and some of the URSF
> enthusiasts do not understand what are they even opposing or going to run
> with risks involved.
>
Clueless and spreading disinformation, you say? What misinformation, could
you explain?


> - Avoid personal attacks
>
Could accusing someone of apreading misinformation without prove and
calling him clueless be considered a personal attack?
What do we do with hypocrites and liars?
People who knowingly lie to push their own agenda, how do we protect
against those?


> /dev/fd0
>
> Sent with ProtonMail  secure email.
>
> --- Original Message ---
> On Saturday, April 30th, 2022 at 3:23 PM, Michael Folkson via bitcoin-dev
> bitcoin-dev@lists.linuxfoundation.org wrote:
>
>
> I’ve been in two minds on whether to completely move on to other topics or
> to formulate some thoughts on the recent attempt to activate a contentious
> soft fork. In the interests of those of us who have wasted
> days/weeks/months of our time on this (with no personal upside) and who
> don’t want to repeat this exercise again I thought I should at least raise
> the issue for discussion of what should be done differently if this is
> tried again in future.
>
> This could be Jeremy with OP_CTV at a later point (assuming it is still
> contentious) or anyone who wants to pick up a single opcode that is not yet
> activated on Bitcoin and try to get miners to signal for it bypassing
> technical concerns from many developers, bypassing Bitcoin Core and
> bypassing users.
>
> Maybe the whole thing worked as designed. Some users identified what was
> going on, well known Bitcoin educators such as Andreas Antonopoulos, Jimmy
> Song etc brought additional attention to the dangers, a URSF movement
> started to gain momentum and those attempting a contentious soft fork
> activation backed off. (Disappointingly Bitcoin Optech didn't cover my
> previous posts to this mailing list 1
> ,
> 2
> ,
> 3
> 
> highlighting the dangers many months ago or recent posts. Normally Optech
> is very high signal.)
>
> Alternatively this was the first time a contentious soft fork activation
> was attempted, we were all woefully unprepared for it and none of us knew
> what we were doing.
>
> I’m unsure on the above. I’d be interested to hear thoughts. What I am
> sure of is that it is totally unacceptable for one individual to bring the
> entire Bitcoin network to the brink of a chain split. There has to be a
> personal cost to that individual dissuading them from trying it again
> otherwise they’re motivated to try it again every week/month. Perhaps the
> personal cost that the community is now prepared if that individual tries
> it again is sufficient. I’m not sure. Obviously Bitcoin is a permissionless
> network, Bitcoin Core and other open source projects are easily forked and
> no authority (I’m certainly no authority) can stop things like this
> happening again.
>
> I’ll follow the responses if people have thoughts (I won't be responding
> to the instigators of this contentious soft fork activation attempt) but
> other than that I’d like to move on to other things than contentious soft
> fork activations. Thanks to those who have expressed concerns publicly (too
> many to name, Bob McElrath was often wording arguments better than I could)
> and who were willing to engage with the URSF conversation. If an individual
> can go directly to miners to get soft forks activated bypassing technical
> concerns from many developers, bypassing Bitcoin Core and bypassing users
> Bitcoin is fundamentally broken. The reason I still have hope that it isn't
> is that during a period of general apathy some people wer

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

[Jorge Timón via bitcoin-dev]

"The only 3 nacks"...I would not call that an accurate "collection of
feedback". Feedback is always more positive when you laregely chose to
ignore any negative feedback, isn't it?

"Largely, the formal critiques of CTV (the 3 NACKs) are based on topics of
whether or not to swing the racquet, not if we should be at the ball. "

I would comment on this point, but I'm not sure I'm "technical enough". I
have to admit: I've never played tennis.
Besides, I'm pretty sure any feedback I give would be ignored.
Following the tennis analogy, one could think Jeremy is trying to win this
match the way Nadal won Djokovich in Australia in 2021 (ie by doing
everything in his hand to make sure his opponent wasn't even allowed to
play, ie not by playing fair nor by playing better than the opppnent).

"Activation parameters like in taproot".
If this was a tennis match, then I would have some sort of ability to slow
time down or something, because I've been seeing this ball slowly coming
since taproot's activation parameters were discussed.

It feels a little bit "deja vu" too. Was ever a controversial hardfork
attempted "just with the same activation mechanism as the last softfork"?
I should look for the exact words, I guess.


On Mon, Apr 25, 2022, 23:45 Michael Folkson via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> The latest I'm hearing (this mailing list appears to be being bypassed in
> favor of personal blogs and messaging apps) is that Speedy Trial miner
> signaling for the contentious CTV soft fork is no longer going to start on
> May 5th (as previously communicated [1]) and may instead now start around
> August 1st 2022.
>
> Hence for now the drama seems to have been averted. I am deeply skeptical
> that in the next 3 months this soft fork activation attempt will obtain
> community consensus and will no longer be contentious (although I guess
> theoretically it is possible). As a result I suspect we'll be in the exact
> same situation with a URSF effort required 2-3 months down the line.
>
> If we are I'll try to keep the mailing list informed. It is important
> there is transparency and ample time to research and prepare before making
> decisions on what software to run. Obviously I have no control over what
> others choose to do. Please don't be rushed into running things you don't
> understand the implications of and please only signal for a soft fork if
> you are convinced it has community consensus (what should precede signaling
> as it did for Taproot) and you are ready to activate a soft fork.
>
> [1]: https://rubin.io/bitcoin/2022/04/17/next-steps-bip119/
>
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>
> --- Original Message ---
> On Saturday, April 23rd, 2022 at 11:03 AM, Michael Folkson via bitcoin-dev
>  wrote:
>
> As I said in my post:
>
> "If you care about Bitcoin's consensus rules I'd request you pay
> attention so you can make an informed view on what to run and what to
> support."
>
> Ideally everyone would come to an informed view independently.
> Unfortunately many people don't have the time to follow Bitcoin drama 24/7
> and hence struggle to separate noise from signal. In this case simple
> heuristics are better than nothing. One heuristic is to listen to those in
> the past who showed good judgment and didn't seek to misinform. Of course
> it is an imperfect heuristic. Ideally the community would be given
> sufficient time to come to an informed view independently on what software
> to run and not be rushed into making decisions. But it appears they are not
> being afforded that luxury.
>
> >  I fear you risk losing respect in the community
>
> I appreciate your concern.
>
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>
> --- Original Message ---
> On Saturday, April 23rd, 2022 at 6:10 AM, Billy Tetrud <
> billy.tet...@gmail.com> wrote:
>
> > assuming people pay attention and listen to the individuals who were
> trusted during that period
>
> Bitcoin is not run by a group of authorities of olde. By asking people to
> trust "those.. around in 2015-2017" you're asking people to blindly trust
> authorities. This, in my strong opinion, goes against the bitcoin ethos,
> and is an incredibly harmful way to push for your agenda. I'd very much
> recommend you reassess the way you're going about what you're trying to do.
> I fear you risk losing respect in the community by implying without any
> evidence that certain people are "taking advantage" of some situation and
> attempting "to confuse".
>
> On Fri, Apr 22, 2022 at 12:33 PM Michael Folkson via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> If the next few weeks go how I fear they will it could get messy. If you
>> care about Bitcoin's consensus rules I'd request you pay attention so you
>

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

[Jorge Timón via bitcoin-dev]

On Sun, Apr 24, 2022 at 2:17 PM Michael Folkson <
michaelfolk...@protonmail.com> wrote:

> Hi Jorge
>
> > Can we agree now that resisting a bip8 proposal is simpler and cleaner
> than resisting a speedy trial proposal?
>
> Personally I'd rather stick to one challenge at a time :) Currently we are
> facing a contentious soft fork activation attempt of CTV using an
> alternative client which we expect [1] to be a Speedy Trial deployment.
> Once this is resolved we can discuss the lessons and observations that come
> out of this.
>

That sounds reasonable to me. Fair enough.


> > Is there any PR to actively resist the proposal on bitcoin core?
>
> Not currently. Unless this becomes really, really messy and starts to pose
> a true existential threat to Bitcoin itself I think it best that attempts
> to actively resist the proposal are done outside of Bitcoin Core in an
> alternative client(s). Contrary to what some CTV proponents say getting
> anything consensus related into Bitcoin Core is extremely difficult
> (especially at short notice). There is no BDFL or Linus Torvalds like
> figure, there are a large number of contributors (and maintainers) who all
> have differing personal views. Hence directing people to have this
> discussion on a particular PR in the Bitcoin Core repo seems to me to be
> counterproductive and a massive distraction to other work that is going on
> on Bitcoin Core. We've already started to see online attacks on Bitcoin
> Core by CTV proponents [2] claiming an "old guard trying to assert
> dictatorship over the Bitcoin protocol". It is nonsense of course but
> directing that nonsense to the Bitcoin Core repo is surely not the right
> way to go.
>
> As I've said in previous emails there is a Libera (and Freenode now) IRC
> channel ##ursf that has been set up to discuss an alternative client. We'll
> get a conversation log up too. And of course we wait for confirmation on
> what the Speedy Trial deployment parameters for this attempted CTV soft
> fork are going to be.
>
> [1]: https://blog.bitmex.com/op_ctv-summer-softfork-shenanigans/
> [2]:
> https://twitter.com/ProofOfKeags/status/1517574210691887105?s=20&t=_jgRh3kkYP3kn1qLuzGXrQ
>
>
I disagree that it shouldn't be on bitcoin core, but I guess such a
proposal would get many nacks.
But if there are no speedy trial parameters yet, I guess we need to wait
for that; whether the code for resisting it ends up in bitcoin core or not.
Thanks for the clarifications.

--
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>
> --- Original Message ---
> On Saturday, April 23rd, 2022 at 21:40, Jorge Timón 
> wrote:
>
> I've been calling them "controversial softforks" for long.
> I hate to be right some times, but I guess I'm happy that I'm not the only
> one who distrusts jeremy rubin anymore.
>
> Can we agree now that resisting a bip8 proposal is simpler and cleaner
> than resisting a speedy trial proposal?
> I guess now we don't need to discuss it in hypothetical terms anymore, do
> we?
>
> Is there any PR to actively resist the proposal on bitcoin core?
>
>
>
>
>
>
> On Thu, Apr 21, 2022 at 8:16 PM Michael Folkson via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Ok so we've had to scramble a bit as I don't think anyone except perhaps
>> Jeremy thought that there would be a Speedy Trial signaling period for a
>> CTV soft fork planned to start on May 5th [1]. That is two weeks away.
>>
>> (I have to take what he says at face value. I can understand why one
>> would be skeptical.)
>>
>> Understandably this has angered and surprised a few people including some
>> of those who have voiced opposition to a CTV soft fork activation being
>> attempted in the first place [2].
>>
>> As I've said in a previous post [3] the Bitcoin Core 23.0 release
>> candidate (and older versions) does not include any CTV code or CTV
>> activation code. If a miner runs Bitcoin Core 23.0 out the box it will not
>> signal for CTV. If by some chance CTV was to activate through some other
>> software release Bitcoin Core releases would not apply CTV rules but they
>> also wouldn't reject blocks that apply CTV rules. Hence it is prudent to
>> prepare for an eventuality where the miner signaling threshold might be
>> reached but the community wants to prevent the attempted soft fork from
>> activating. (I personally don't think a 90 percent miner signaling
>> threshold will be reached but I wouldn't want to bet Bitcoin's future on
>> it.)
>>
>> I've tentatively labelled this effort a User Resisted Soft Fork (URSF)
>> but I'm open to better names. I certainly don't want to discourage those
>> who dislike or oppose UASFs from contributing to this effort and
>> potentially ultimately running a URSF release. If you don't want this
>> rushed CTV soft fork to activate we are all on the same side whatever we
>> call it.
>>
>> For now I've set up a ##ursf channel o

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

[Jorge Timón via bitcoin-dev]

On Sun, Apr 24, 2022 at 2:56 PM Ryan Grant  wrote:

> Michael and Jorge,
>
> It is ethically inappropriate to make personal attacks on the
> trustworthiness of participants on this list, on such vague grounds as
> disliking an activation proposal!
>
>   https://en.wikipedia.org/wiki/Wikipedia:Assume_good_faith
>

I don't think the same principle is being applied to me and other people,
sadly.
Some people disregard dissent on the grounds that it comes from "people who
just loo for dissent".
I don't think it is unethical to say the truth. In fact, I think it is fair
that I clarify my bias against jeremy.
I realize it can be held against me.
What I think is hypocritical and unethical is having rules that are only
expected to be followed by some.

Is everyone assuming good intentions from me?
Is everyone assuming good intentions from luke?
Is everyone assuming good intentions from michael?

I don't think so.

It is against the spirit of the project to base your judgements of a
> technical solution on who presents them!  You should not be so
> technically adrift that you only have reputation left to speak about.
>

I disagree, I think it is against the spirit of the project to trust ideas
based on who they come from.
In that sense, I apologize for not being able to distrust every other
developer as much as I can distrust jeremy.


> If you disagree with ideas, then shoot them down on the technical merits.
>
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-October/011457.html
>

I've tried regarding bip8 and speedy trial. I may be wrong, but I think
those ideas have been discarded not on their technical merits, but based on
who were promoting them. I feel there has been a biased against people like
Luke-jr or me.
That's subjective. Perhaps I'm just being paranoid. But I truly think
Jeremy distrusts me and luke as much as I distrusts him, he just won't say
it.
Anyway, I had said it once before, so I guess there's no need to further
disclaim my bias against jeremy.


> If you disagree with people, then take it to smuttier sections of the
> Internet.
>
>
Yeah, to twitter, right? lol, sorry, I couldn't resist the joke.
Sorry.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Speedy Trial

[Jorge Timón via bitcoin-dev]

You're not even considering user resistance in your cases. You're purely
relying on miners and calling speedy trial superior. I don't know if you're
being obtuse on purpose, I'm explaining myself very badly...

I DON'T WANT TO RELY ON MINERS TO RESIST CHANGES I DON'T WANT TO.
Sorry for the tone, but, please, make sure you understand that before
answering further, or otherwise it is a waste of time.

Note that it doesn't have to be in bitcoin core, speedy trial could be used
for attempting to activate a controversial softfork (it doesn't need to be
an evil fork, even) outside of core. Like what jeremy is trying to do with
his proposal, for example.
Now, go ahead and tell me that if miners reject it, then doesn't matter,
because nobody ever has told me that before, I need to hear it one more
time.
And I'll tell you I don't care about what miners will do, because you
obviously need to hear it one more time as well.
Or just tell the list that you resolved all my concerns, like jeremy does
about any criticism of his proposals, "well, it has consensus because only
people seeking dissent don't like it". Likd with speedy trial.
"Some people conplained, but we told them theur concerns were addressed and
even though they disagreed and claimed we didn't understand their
concerns...it looked like they were seeking dissent, so we told them to f@$k
off and now there's consensus".

Sorry for the aggressive tone, but I when people ignore some of my points
repeteadly, I start to wonder if they do it on purpose. You're not ignoring
my points on purpose, are you?
Nah, of course not, it's just that communication is hard.
Surely it wouldn't be fair if I accused you of being dishonest or
pretending to be dumb.
Most probably, I'm not clear or direct enough.
Whatever the real explanation is for you not understanding me, you're not
understanding me and it feels luke a waste of time for both of us.
So, I'm sorry, it's over.


On Mon, Apr 11, 2022, 14:05 Anthony Towns  wrote:

> On Fri, Apr 08, 2022 at 11:58:48AM +0200, Jorge Timón via bitcoin-dev
> wrote:
> > On Wed, Mar 30, 2022 at 6:21 AM Anthony Towns  wrote:
> > > > Let's discuss those too. Feel free to point out how bip8 fails at
> some
> > > > hypothetical cases speedy trial doesn't.
> > > Any case where a flawed proposal makes it through getting activation
> > > parameters set and released, but doesn't achieve supermajority
> hashpower
> > > support is made worse by bip8/lot=true in comparison to speedy trial
> > I disagree. Also, again, not the hypothetical case I want to discuss.
>
> You just said "Let's discuss those" and "Feel free to point out how bip8
> fails at some hypothetical cases speedy trial doesn't", now you're
> saying it's not what you want to discuss?
>
> But the above does include your "evil soft fork" hypothetical (I mean,
> unless you think being evil isn't a flaw?). The evil soft fork gets
> proposed, and due to some failure in review, merged with activation
> parameters set (via either speedy trial or bip8), then:
>
>  a) supermajority hashpower support is achieved quickly:
>  - both speedy trial and bip8+lot=true activate the evil fork
>
>  b) supermajority hashpower support is achieved slowly:
>  - speedy trial does *not* activate the evil fork, as it times out
>quickly
>  - bip8 *does* activate the fork
>
>  c) supermajority hashpower support support is never achieved:
>  - speedy trial does *not* activate the evil fork
>  - bip8+lot=false does *not* activate the evil fork, but only after a
>long timeout
>  - bip8+lot=true *does* activate the evil fork
>
> In case (a), they both do the same thing; in case (b) speedy trial is
> superior to bip8 no matter whether lot=true/false since it blocks the
> evil fork, and in case (c) speedy trial is better than lot=false because
> it's quicker, and much better than lot=true because lot=true activates
> the evil fork.
>
> > > > >  0') someone has come up with a good idea (yay!)
> > > > >  1') most of bitcoin is enthusiastically behind the idea
> > > > >  2') an enemy of bitcoin is essentially alone in trying to stop it
> > > > >  3') almost everyone remains enthusiastic, despite that guy's
> > > incoherent
> > > > >  raving
> > > > >  4') nevertheless, the enemies of bitcoin should have the power to
> stop
> > > > >  the good idea
> > > > "That guy's incoherent raving"
> > > > "I'm just disagreeing".

Re: [bitcoin-dev] Speedy Trial

[Jorge Timón via bitcoin-dev]

On Sun, Apr 24, 2022 at 2:14 PM Anthony Towns  wrote:

> On Sun, Apr 24, 2022 at 12:13:08PM +0100, Jorge Timón wrote:
> > You're not even considering user resistance in your cases.
>
> Of course I am. Again:
>

No, you're relying on miners to stop bad proposals.


> > > My claim is that for *any* bad (evil, flawed, whatever) softfork, then
> > > attempting activation via bip8 is *never* superior to speedy trial,
> > > and in some cases is worse.
> > >
> > > If I'm missing something, you only need to work through a single
> example
> > > to demonstrate I'm wrong, which seems like it ought to be easy... But
> > > just saying "I disagree" and "I don't want to talk about that" isn't
> > > going to convince anyone.
>
> The "some cases" where bip8 with lot=true is *worse* than speedy trial
> is when miners correctly see that a bad fork is bad.
>
> Under *any* other circumstance, when they're used to activate a bad soft
> fork, speedy trial and bip8 are the same. If a resistance method works
> against bip8, it works against speedy trial; if it fails against speedy
> trial, it fails against bip8.
>

You're wrong.


> > Sorry for the aggressive tone, but I when people ignore some of my points
> > repeteadly, I start to wonder if they do it on purpose.
>
> Perhaps examine the beam in your own eye.
>

Yeah, whether you do that yourself or not: sorry, it's over.


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

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

[Jorge Timón via bitcoin-dev]

I've been calling them "controversial softforks" for long.
I hate to be right some times, but I guess I'm happy that I'm not the only
one who distrusts jeremy rubin anymore.

Can we agree now that resisting a bip8 proposal is simpler and cleaner than
resisting a speedy trial proposal?
I guess now we don't need to discuss it in hypothetical terms anymore, do
we?

Is there any PR to actively resist the proposal on bitcoin core?






On Thu, Apr 21, 2022 at 8:16 PM Michael Folkson via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Ok so we've had to scramble a bit as I don't think anyone except perhaps
> Jeremy thought that there would be a Speedy Trial signaling period for a
> CTV soft fork planned to start on May 5th [1]. That is two weeks away.
>
> (I have to take what he says at face value. I can understand why one would
> be skeptical.)
>
> Understandably this has angered and surprised a few people including some
> of those who have voiced opposition to a CTV soft fork activation being
> attempted in the first place [2].
>
> As I've said in a previous post [3] the Bitcoin Core 23.0 release
> candidate (and older versions) does not include any CTV code or CTV
> activation code. If a miner runs Bitcoin Core 23.0 out the box it will not
> signal for CTV. If by some chance CTV was to activate through some other
> software release Bitcoin Core releases would not apply CTV rules but they
> also wouldn't reject blocks that apply CTV rules. Hence it is prudent to
> prepare for an eventuality where the miner signaling threshold might be
> reached but the community wants to prevent the attempted soft fork from
> activating. (I personally don't think a 90 percent miner signaling
> threshold will be reached but I wouldn't want to bet Bitcoin's future on
> it.)
>
> I've tentatively labelled this effort a User Resisted Soft Fork (URSF) but
> I'm open to better names. I certainly don't want to discourage those who
> dislike or oppose UASFs from contributing to this effort and potentially
> ultimately running a URSF release. If you don't want this rushed CTV soft
> fork to activate we are all on the same side whatever we call it.
>
> For now I've set up a ##ursf channel on Libera IRC to monitor developments
> and discuss working on an additional release that if run may ultimately
> reject blocks that signal for CTV.
>
> The intention of this would be to provide additional direction and
> incentive to miners that the community does not want this soft fork to be
> activated. To repeat running a Bitcoin Core release will not signal for a
> CTV soft fork out the box. If a miner runs a Bitcoin Core release it will
> not signal for CTV.
>
> Apologies that this is rushed. But as always with Jeremy caution and
> conservatism seems to be thrown out the window and we have to react to
> that. It goes without saying that this is not how Bitcoin consensus changes
> should be attempted.
>
> [1]: https://rubin.io/bitcoin/2022/04/17/next-steps-bip119/
> [2]:
> https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718
> [3]:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020235.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@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Speedy Trial

[Jorge Timón via bitcoin-dev]

On Wed, Mar 30, 2022 at 6:21 AM Anthony Towns  wrote:

> On Mon, Mar 28, 2022 at 09:31:18AM +0100, Jorge Timón via bitcoin-dev
> wrote:
> > > In particular, any approach that allows you to block an evil fork,
> > > even when everyone else doesn't agree that it's evil, would also allow
> > > an enemy of bitcoin to block a good fork, that everyone else correctly
> > > recognises is good. A solution that works for an implausible
> hypothetical
> > > and breaks when a single attacker decides to take advantage of it is
> > > not a good design.
> > Let's discuss those too. Feel free to point out how bip8 fails at some
> > hypothetical cases speedy trial doesn't.
>
> Any case where a flawed proposal makes it through getting activation
> parameters set and released, but doesn't achieve supermajority hashpower
> support is made worse by bip8/lot=true in comparison to speedy trial
>

I disagree. Also, again, not the hypothetical case I want to discuss.


> That's true both because of the "trial" part, in that activation can fail
> and you can go back to the drawing board without having to get everyone
> upgrade a second time, and also the "speedy" part, in that you don't
> have to wait a year or more before you even know what's going to happen.
>
> > >  0') someone has come up with a good idea (yay!)
> > >  1') most of bitcoin is enthusiastically behind the idea
> > >  2') an enemy of bitcoin is essentially alone in trying to stop it
> > >  3') almost everyone remains enthusiastic, despite that guy's
> incoherent
> > >  raving
> > >  4') nevertheless, the enemies of bitcoin should have the power to stop
> > >  the good idea
> > "That guy's incoherent raving"
> > "I'm just disagreeing".
>
> Uh, you realise the above is an alternative hypothetical, and not talking
> about you? I would have thought "that guy" being "an enemy of bitcoin"
> made that obvious... I think you're mistaken; I don't think your emails
> are incoherent ravings.
>

Do you realize IT IS NOT the hypothetical case I wanted to discuss. Seems
like that hypothetical case where a crazy person can be safely ignored
covered already.


> It was intended to be the simplest possible case of where someone being
> able to block a change is undesirable: they're motivated by trying to
> harm bitcoin, they're as far as possible from being part of some economic
> majority, and they don't even have a coherent rationale to provide for
> blocking the idea.
>
> Cheers,
> aj
>

Either I'm explaining my self very badly, you don't want to understand me,
or you can't understand me for whatever reason.
I don't feel listened or that "my concerns have been addressed", but at
this point  I feel we're wasting each others time.Perhaps my rational
against speedy trial is not coherent, or perhaps you haven't understand it
yet.
I'm sorry, but I'm tired of trying to explain. and quite, honestly, you
don't seem interested in listening to me and understanding me at all, but
only in "addressing my concerns". Obviously we understand different things
by "addressing concerns".
Perhaps it's the language barrier or something.

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

Re: [bitcoin-dev] Speedy Trial

[Jorge Timón via bitcoin-dev]

On Sat, Mar 26, 2022, 01:45 Anthony Towns  wrote:

> On Thu, Mar 24, 2022 at 07:30:09PM +0100, Jorge Timón via bitcoin-dev
> wrote:
> > Sorry, I won't answer to everything, because it's clear you're not
> listening.
>
> I'm not agreeing with you; that's different to not listening to you.
>

You're disagreeing with thw premises of the example. That's not
disagreeing, that's refusing to understand the example.


> > In the HYPOTHETICAL CASE that there's an evil for, the fork being evil
> > is a PREMISE of that hypothetical case, a GIVEN.
>
> Do you really find people more inclined to start agreeing with you when
> you begin yelling at them? When other people start shouting at you,
> do you feel like it's a discussion that you're engaged in?
>

I just wanted to make sure you catched the PREMISE word.


> > Your claim that "if it's evil, good people would oppose it" is a NON
> > SEQUITUR, "good people" aren't necessarily perfect and all knowing.
> > good people can make mistakes, they can be fooled too.
> > In the hypothetical case that THERE'S AN EVIL FORK, if "good people"
> > don't complain, it is because they didn't realize that the given fork
> > was evil. Because in our hypothetical example THE EVIL FORK IS EVIL BY
> > DEFINITION, THAT'S THE HYPOTHETICAL CASE I WANT TO DISCUSS, not the
> > hypothetical case where there's a fork some people think it's evil but
> > it's not really evil.
>
> The problem with that approach is that any solution we come up with
> doesn't only have to deal with the hypotheticals you want to discuss
>

Sure, but if it doesn't deal with this hypothetical, one canbot pretending
it does by explaing how it does in a different hypothetical.

In particular, any approach that allows you to block an evil fork,
> even when everyone else doesn't agree that it's evil, would also allow
> an enemy of bitcoin to block a good fork, that everyone else correctly
> recognises is good. A solution that works for an implausible hypothetical
> and breaks when a single attacker decides to take advantage of it is
> not a good design.
>

Let's discuss those too. Feel free to point out how bip8 fails at some
hypothetical cases speedy trial doesn't.

And I did already address what to do in exactly that scenario:
>
> > > But hey what about the worst case: what if everyone else in bitcoin
> > > is evil and supports doing evil things. And maybe that's not even
> > > implausible: maybe it's not an "evil" thing per se, perhaps [...]
> > >
> > > In that scenario, I think a hard fork is the best choice: split out a
> new
> > > coin that will survive the upcoming crash, adjust the mining/difficulty
> > > algorithm so it works from day one, and set it up so that you can
> > > maintain it along with the people who support your vision, rather than
> > > having to constantly deal with well-meaning attacks from "bitcoiners"
> > > who don't see the risks and have lost the plot.
> > >
> > > Basically: do what Satoshi did and create a better system, and let
> > > everyone else join you as the problems with the old one eventually
> become
> > > unavoidably obvious.
>
> > Once you understand what hypothetical case I'm talking about, maybe
> > you can understand the rest of my reasoning.
>
> As I understand it, your hypothetical is:
>
>  0) someone has come up with a bad idea
>  1) most of bitcoin is enthusiastically behind the idea
>  2) you are essentially alone in discovering that it's a bad idea
>  3) almost everyone remains enthusiastic, despite your explanations that
> it's a bad idea
>  4) nevertheless, you and your colleagues who are aware the idea is bad
> should have the power to stop the bad idea
>  5) bip8 gives you the power to stop the bad idea but speedy trial does not
>



Again given (0), I think (1) and (2) are already not very likely, and (3)
> is simply not plausible. But in the event that it does somehow occur,
> I disagree with (4) for the reasons I describe above; namely, that any
> mechanism that did allow that would be unable to distinguish between the
> "bad idea" case and something along the lines of
>

Ok, yeah, the bitcoin developers currently paying attention to the mailibg
list being fooled or making a review mistake is completely unfeasible.
They're all way to humble for that, obviously...sigh.

 0') someone has come up with a good idea (yay!)
>  1') most of bitcoin is enthusiastically behind the idea
>  2'

Re: [bitcoin-dev] Speedy Trial

[Jorge Timón via bitcoin-dev]

Sorry, I won't answer to everything, because it's clear you're not listening.
In the HYPOTHETICAL CASE that there's an evil for, the fork being evil
is a PREMISE of that hypothetical case, a GIVEN.
Your claim that "if it's evil, good people would oppose it" is a NON
SEQUITUR, "good people" aren't necessarily perfect and all knowing.
good people can make mistakes, they can be fooled too.
In the hypothetical case that THERE'S AN EVIL FORK, if "good people"
don't complain, it is because they didn't realize that the given fork
was evil. Because in our hypothetical example THE EVIL FORK IS EVIL BY
DEFINITION, THAT'S THE HYPOTHETICAL CASE I WANT TO DISCUSS, not the
hypothetical case where there's a fork some people think it's evil but
it's not really evil.

Repeat with me: in the hypothetical case that there's an evil fork,
then the fork is evil by definition, that's the hypothetical case
we're discussing.

Once you understand what hypothetical case I'm talking about, maybe
you can understand the rest of my reasoning.
But if you don't understand the PREMISES of my example, it is
impossible that you can understand my reasonings about the
hypothetical example.

I'm sorry about the upper cases, but I really don't know how else I
could be clearer about the PREMISES being PREMISES and not just
possibilities. If you can't imagine a scenario where good people don't
oppose an evil fork, then you can't imagine the scenario I'm talking
about, sorry.

Evil fork deployed with speedy trial vs evil fork deployed with BIP8,
that's what I'm talking about.
Please, stop the "then it's not an evil fork" contradiction of the premises.

At this point, I don't think I can be clearer about the main premise
of my example, sorry.

On Wed, Mar 23, 2022 at 12:50 AM Anthony Towns  wrote:
>
> On Thu, Mar 17, 2022 at 03:04:32PM +0100, Jorge Timón via bitcoin-dev wrote:
> > On Tue, Mar 15, 2022 at 4:45 PM Anthony Towns  wrote:
> > > On Fri, Mar 11, 2022 at 02:04:29PM +, Jorge Timón via bitcoin-dev 
> > > wrote:
> > > People opposed to having taproot transactions in their chain had over
> > > three years to do that coordination before an activation method was merged
> > > [0], and then an additional seven months after the activation method was 
> > > merged before taproot enforcement began [1].
> > >
> > > [0] 2018-01-23 was the original proposal, 2021-04-15 was when speedy
> > > trial activation parameters for mainnet and testnet were merged.
> > > [1] 2021-11-14
> > People may be opposed only to the final version, but not the initial
> > one or the fundamental concept.
> > Please, try to think of worse case scenarios.
>
> I mean, I've already spent a lot of time thinking through these worst
> cast scenarios, including the ones you bring up. Maybe I've come up with
> wrong or suboptimal conclusions about it, and I'm happy to discuss that,
> but it's a bit hard to avoid taking offense at the suggestion that I
> haven't even thought about it.
>
> In the case of taproot, the final substantive update to the BIP was PR#982
> merged on 2020-08-27 -- so even if you'd only been opposed to the changes
> in the final version (32B pubkeys perhaps?) you'd have had 1.5 months to
> raise those concerns before the code implementing taproot was merged,
> and 6 months to raise those concerns before activation parameters were
> set. If you'd been following the discussion outside of the code and BIP
> text, in the case of 32B pubkeys, you'd have had an additional 15 months
> from the time the idea was proposed on 2019-05-22 (or 2019-05-29 if you
> only follow optech's summaries) until it was included in the BIP.
>
> > Perhaps there's no opposition until after activation code has been
> > released and miners are already starting to signal.
> > Perhaps at that moment a reviewer comes and points out a fatal flaw.
>
> Perhaps there's no opposition until the change has been deployed and in
> wide use for 30 years. Aborting activation isn't the be-all and end-all
> of addressing problems with a proposal, and it's not going to be able to
> deal with every problem. For any problems that can be found before the
> change is deployed and in use, you want to find them while the proposal
> is being discussed.
>
>
>
> More broadly, what I don't think you're getting is that *any* method you
> can use to abort/veto/revert an activation that's occuring via BIP8 (with
> or without mandatory activation), can also be used to abort/veto/revert
> a speedy trial activation.
>
> Sp

Re: [bitcoin-dev] Speedy Trial

[Jorge Timón via bitcoin-dev]

On Tue, Mar 15, 2022 at 6:25 PM Jeremy Rubin via bitcoin-dev
 wrote:
>
> Boker tov bitcoin devs,

I don't undesrtand what that means, sorry

>> A mechanism of soft-forking against activation exists.  What more do you 
>> want?
>
>
> Agreed -- that should be enough.

No, resistance should ideally be a priori, not a posteriori.

>
>>
>> Are we supposed to write the code on behalf of this hypothetical group of 
>> users who may or may not exist for them just so that they can have a node 
>> that remains stalled on Speedy Trial lockin?
>>
>> That simply isn't reasonable, but if you think it is, I invite you to create 
>> such a fork.
>
>
> Disagree.
>
> It is a reasonable ask.
>
> I've done it in about 40 lines of python: https://github.com/jeremyrubin/forkd
>
> Merry Christmas Jorge, please vet the code carefully before running.

40 lines of python code should be easy to bet even if the author was
very bad at writing readable code and obfuscated his code on purpose.
I don't know if it's the case, because, sorry, I'm not reviewing your
code at the moment.
"Vet the code carefully before running" strikes me as arrogant and
condescending. as if you were implying my engineering capacity was
very limited. If you say these things to me publicly, I can only only
imagine what you have told other devs behind my back about my capacity
(or even my ideology) if they ever asked (or perhaps without them
asking). I really hope you haven't lied to anyone about my ideology,
J.
Perhaps I do have "prosectution complex" with you indeed. Not with
Russel, but with you.
After all, I've publicly say I don't trust you, haven't I?
But, again, what do I know about psychology?

Going back on topic, the reason I won't review your code is because
you have rushed a design before understanding the analysis.
No, I'm not asking for a stalled mechanism for speedy trial, I don't
want speedy trial.
We disagree on the analysis of the problem to solve, that's why we
disagree on the design for the solution.

https://en.wikipedia.org/wiki/Systems_development_life_cycle#Analysis

Anyway, perhaps I look at the code in the future if your proposal
consensus change seems to prosper.

Regarding "merry christmas"...what the f are you talking about? it's
not Christmas time and neither you or me are christians, are you?
If this is some sort of riddle or joke, we really must have very
different senses of humor, because I don't get it.
Come on, J, let's both try to stay on topic or people will start to
correctly point out that we both negatively discriminate each other
for offtopic reasons, be them reasonably justified or not.

> Peace,

Ama, y ensancha el alma.

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

Re: [bitcoin-dev] Speedy Trial

[Jorge Timón via bitcoin-dev]

On Tue, Mar 15, 2022 at 4:45 PM Anthony Towns  wrote:
>
> On Fri, Mar 11, 2022 at 02:04:29PM +, Jorge Timón via bitcoin-dev wrote:
> People opposed to having taproot transactions in their chain had over
> three years to do that coordination before an activation method was merged
> [0], and then an additional seven months after the activation method was 
> merged before taproot enforcement began [1].
>
> [0] 2018-01-23 was the original proposal, 2021-04-15 was when speedy
> trial activation parameters for mainnet and testnet were merged.
> [1] 2021-11-14

People may be opposed only to the final version, but not the initial
one or the fundamental concept.
Please, try to think of worse case scenarios.
Perhaps there's no opposition until after activation code has been
released and miners are already starting to signal.
Perhaps at that moment a reviewer comes and points out a fatal flaw.

> For comparison, the UASF activation attempt for segwit took between 4
> to 6 months to coordinate, assuming you start counting from either the
> "user activated soft fork" concept being raised on bitcoin-dev or the
> final params for BIP 148 being merged into the bips repo, and stop
> counting when segwit locked in.

That was extremely risky and could have been a disaster. It went well,
but in my opinion a BIP8 approach from the beginning would have been
much less risky. Instead of improvising these things we should plan
ahead. But for "user forced" activations and for "user forced"
rejections.
Just remember you may reject your own code.

> > Please, try to imagine an example for an activation that you wouldn't like
> > yourself. Imagine it gets proposed and you, as a user, want to resist it.
>
> Sure. There's more steps than just "fork off onto a minority chain"
> though.
>
>  1) The first and most important step is to explain why you want to
> resist it, either to convince the proposers that there really is
> a problem and they should stand down, or so someone can come up
> with a way of fixing the proposal so you don't need to resist it.
> Ideally, that's all that's needed to resolve the objections. (That's
> what didn't happen with opposition to segwit)

Agreed, for any given proposal, the first approach should be rational
discussion.
Some times we consider other arguments irrational simply because we
don't understand them though.

>  2) If that somehow doesn't work, and people are pushing ahead with a
> consensus change despite significant reasonable opposition; the next
> thing to do would be to establish if either side is a paper tiger
> and setup a futures market. That has the extra benefit of giving
> miners some information about which (combination of) rules will be
> most profitable to mine for.
>
> Once that's setup and price discovery happens, one side or the other
> will probably throw in the towel -- there's not much point have a
> money that other people aren't interested in using. (And that more
> or less is what happened with 2X)

Future markets can be manipulated.
Regarding 2x, that's not how I remember it. If I remember correctly,
"discovered" a price in btc for bcash that was
orders of magnitude higher than what it is today.

> If a futures market like that is going to be setup, I think it's
> best if it happens before signalling for the soft fork starts --
> the information miners will get from it is useful for figuring out
> how much resources to invest in signalling, eg. I think it might even
> be feasible to set something up even before activation parameters are
> finalised; you need something more than just one-on-one twitter bets
> to get meaningful price discovery, but I think you could probably
> build something based on a reasonably unbiassed oracle declaring an
> outcome, without precisely defined parameters fixed in a BIP.

Whatever miners signal, until there are two chains and their real
rewards can be traded, it's hard to know what they will mine
afterwards.
They could signal a change with 100% and then after it is activated on
one chain and resisted on another, they 95% of them may switch to the
old chain simply because its rewards are 20 times more valuable. This
may happen 3 days after activation or 3 months, or more.
It could depend on how fast some relevant information about the new
change spreads.
Which is specially hard to estimate in a censored world like ours.

> So if acting like reasonable people and talking it through doesn't
> work, this seems like the next step to me.

Not to me, but you're free to create your future markets or trade in them.
I wouldn't do any of them, an

Re: [bitcoin-dev] Speedy Trial

[Jorge Timón via bitcoin-dev]

On Sat, Mar 12, 2022 at 7:34 PM Billy Tetrud via bitcoin-dev
 wrote:
>
> >  If I find out I'm in the economic minority then I have little choice but 
> > to either accept the existence of the new rules or sell my Bitcoin
>
> I do worry about what I have called a "dumb majority soft fork". This is 
> where, say, mainstream adoption has happened, some crisis of some magnitude 
> happens that convinces a lot of people something needs to change now. Let's 
> say it's another congestion period where fees spike for months. Getting into 
> and out of lighting is hard and maybe even the security of lightning's 
> security model is called into question because it would either take too long 
> to get a transaction on chain or be too expensive. Panicy people might once 
> again think something like "let's increase the block size to 1GB, then we'll 
> never have this problem again". This could happen in a segwit-like soft fork.

I guess this is a better explained example for a hypothetical "evil
fork" that may sound more concrete and plausible to some people than
my own, which isn't that different. Thanks.

> In a future where Bitcoin is the dominant world currency, it might not be 
> unrealistic to imagine that an economic majority might not understand why 
> such a thing would be so dangerous, or think the risk is low enough to be 
> worth it. At that point, we in the economic minority would need a plan to 
> hard fork away. One wouldn't necessarily need to sell all their majority fork 
> Bitcoin, but they could.
>
> That minority fork would of course need some mining power. How much? I don't 
> know, but we should think about how small of a minority chain we could 
> imagine might be worth saving. Is 5% enough? 1%? How long would the chain 
> stall if hash power dropped to 1%?

In perfect competition the mining power costs per chain tends to equal
the rewards offered by that chain, both in subsidy and transaction
fees.
For example, if chain A gets a reward 10 times as valuable as chain
B's reward, then one should expect it to get 10 times more hashrate
too.
Of course, perfect competition is just a theoretical concept though.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Speedy Trial

[Jorge Timón via bitcoin-dev]

On Sat, Mar 12, 2022 at 2:35 PM Russell O'Connor via bitcoin-dev
 wrote:
>
> On Fri, Mar 11, 2022 at 9:03 AM Jorge Timón  wrote:
> A mechanism of soft-forking against activation exists.  What more do you 
> want? Are we supposed to write the code on behalf of this hypothetical group 
> of users who may or may not exist for them just so that they can have a node 
> that remains stalled on Speedy Trial lockin?  That simply isn't reasonable, 
> but if you think it is, I invite you to create such a fork.

I want BIP+LOT=true to be used. I want speedy trial not to be used.
Luke wrote the code to resist BIP8+LOT=true, and if he didn't, I could
write it myself, yes.
If you think that's not reasonable code to ever run, I don't think
you're really getting the "softfork THAT YOU OPPOSE" part of the
hypothetical right. Let me try to help with an example, although I
hope we don't get derailed in the implementation details of the
hypothetical evil proposal.

Suppose someone proposes a weight size limit increase by a extension
block softfork.
Or instead of that, just imagine the final version of the covenants
proposal has a backdoor in it or something.


Would you rather that proposal be deployed with speedy trial
activation or with BIP8+LOT=true activation?

>>
>> Please, try to imagine an example for an activation that you wouldn't like 
>> yourself. Imagine it gets proposed and you, as a user, want to resist it.
>
>
> If I believe I'm in the economic majority then I'll just refuse to upgrade my 
> node, which was option 2. I don't know why you dismissed it.

Not upgrading your node doesn't prevent the softfork from being
activated in your chain.
A softfork may affect you indirectly even if you don't use the new
features yourself directly.
You may chose to stay in the old chain even if you don't consider
you're "in the economic majority" at that moment.

> Not much can prevent a miner cartel from enforcing rules that users don't 
> want other than hard forking a replacement POW.  There is no effective 
> difference between some developers releasing a malicious soft-fork of Bitcoin 
> and the miners releasing a malicious version themselves.  And when the miner 
> cartel forms, they aren't necessarily going to be polite enough to give a 
> transparent signal of their new rules.  However, without the economic 
> majority enforcing their set of rules, the cartel continuously risks falling 
> apart from the temptation of transaction fees of the censored transactions.

It is true that a mining cartel doesn't need to use speedy trial or
BIP8+LOT=true to apply rule changes they want just because we do.
But they would do if they wanted to maintain the appearance of benevolence.

> On the other hand, If I find out I'm in the economic minority then I have 
> little choice but to either accept the existence of the new rules or sell my 
> Bitcoin.  Look, you cannot have the perfect system of money all by your 
> lonesome self.  Money doesn't have economic value if no one else wants to 
> trade you for it.  Just ask that poor user who YOLO'd his own taproot 
> activation in advance all by themselves.  I'm sure they think they've got 
> just the perfect money system, with taproot early and everything.  But now 
> their node is stuck at block 692261 and hasn't made progress since.  No doubt 
> they are hunkered down for the long term, absolutely committed to their fork 
> and just waiting for the rest of the world to come around to how much better 
> their version of Bitcoin is than the rest of us.

Well, you could also have the option to stay in the old chain with the
economic minority, it doesn't have to be you alone.
We agree that one person alone can't use a currency.

> Even though you've dismissed it, one of the considerations of taproot was 
> that it is opt-in for users to use the functionality.  Future soft-forks 
> ought to have the same considerations to the extent possible.

Well, the same could be said about segwit. And yet all the
consequences of the change are not opt in.
For example, segwit contained a block size limit increase.
Sure, you can just not validate the witnesses, but then you're no
longer a full node.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Speedy Trial

[Jorge Timón via bitcoin-dev]

On Fri, Mar 11, 2022 at 5:32 PM Billy Tetrud via bitcoin-dev
 wrote:
>
> I think involving users more in activation is a good avenue of thought for 
> improving how bitcoin does soft forks. I also think the idea you brought up 
> of some way for people to signal opposition is a good idea. I've suggested a 
> mechanism for signature-based user polling, I've also suggested a mechanism 
> where miners can actively signal for opposing a soft fork. It seems like 
> there should be some common ground between us in those ideas. Where it seems 
> we may perhaps unreconcilably disagree are that A. miners are users too and 
> generally have interests that are important and different than most users, 
> and giving them at least some mechanism to force discussion is appropriate, 
> and B. chain splits are no joke and should almost never be possible 
> accidentally and therefore we should make a significant effort to avoid them, 
> which almost definitely means orderly coordination of miners.

Any user polling system is going to be vulnerable to sybil attacks.

> Do you have anything concrete you want to propose? An example mechanism? Are 
> you simply here advocating your support for BIP8+LOT=true?

Yes, I want BIP+LOT=true (aka the original bip8).
I also want users to be easily able to coordinate resistance to any
given change, as I described in this thread and others and luke has
done many times.
I also generally oppose to speedy trial being used for any consensus
rule change deployment.

Imagine someone comes and proposes a block size increase through
extension block softfork.
Would you like them to use speedy trial or BIP8+LOT=true for deployment?
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Speedy Trial

[Jorge Timón via bitcoin-dev]

On Fri, Mar 11, 2022, 13:47 Russell O'Connor via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Fri, Mar 11, 2022 at 7:18 AM Jorge Timón  wrote:
>
>> I talked about this. But the "no-divergent-rules" faction doesn't like
>> it, so we can pretend we have listened to this "faction" and addressed all
>> its concerns, I guess.
>> Or perhaps it's just "prosectution complex", but, hey, what do I know
>> about psychology?
>>
>
> Your accusations of bad faith on the part of myself and pretty much
> everyone else makes me disinclined to continue this discussion with you.
> I'll reply, but if you want me to continue beyond this, then you need to
> knock it off with the accusations.
>

What accusations of bad faith?
You're accusing me of having prosecution complex.
I'm accusing you of ignoring the "yes-users-veto" faction. But that doesn't
require bad faith, you may simply not understand the "faction".

A major contender to the Speedy Trial design at the time was to mandate
>>> eventual forced signalling, championed by luke-jr.  It turns out that, at
>>> the time of that proposal, a large amount of hash power simply did not have
>>> the firmware required to support signalling.  That activation proposal
>>> never got broad consensus, and rightly so, because in retrospect we see
>>> that the design might have risked knocking a significant fraction of mining
>>> power offline if it had been deployed.  Imagine if the firmware couldn't be
>>> quickly updated or imagine if the problem had been hardware related.
>>>
>>
>> Yes, I like this solution too, with a little caveat: an easy mechanism
>> for users to actively oppose a proposal.
>> Luke alao talked about this.
>> If users oppose, they should use activation as a trigger to fork out of
>> the network by invalidating the block that produces activation.
>> The bad scenario here is that miners want to deploy something but users
>> don't want to.
>> "But that may lead to a fork". Yeah, I know.
>> I hope imagining a scenario in which developers propose something that
>> most miners accept but some users reject is not taboo.
>>
>
> This topic is not taboo.
>
> There are a couple of ways of opting out of taproot.  Firstly, users can
> just not use taproot.  Secondly, users can choose to not enforce taproot
> either by running an older version of Bitcoin Core or otherwise forking the
> source code.  Thirdly, if some users insist on a chain where taproot is
> "not activated", they can always softk-fork in their own rule that
> disallows the version bits that complete the Speedy Trial activation
> sequence, or alternatively soft-fork in a rule to make spending from (or
> to) taproot addresses illegal.
>

Since it's about activation in general and not about taproot specifically,
your third point is the one that applies.
Users could have coordinated to have "activation x" never activated in
their chains if they simply make a rule that activating a given proposal
(with bip8) is forbidden in their chain.
But coordination requires time.
Please, try to imagine an example for an activation that you wouldn't like
yourself. Imagine it gets proposed and you, as a user, want to resist it.


As for mark, he wasn't talking about activation, but quantum computing
>> concerns. Perhaps those have been "addressed"?
>> I just don't know where.
>>
>
> Quantum concerns were discussed.  Working from memory, the arguments were
> (1) If you are worried about your funds not being secured by taproot, then
> don't use taproot addresses, and (2) If you are worried about everyone
> else's funds not being quantum secure by other people choosing to use
> taproot, well it is already too late because over 5M BTC is currently
> quantum insecure due to pubkey reuse <
> https://nitter.net/pwuille/status/1108091924404027392>.  I think it is
> unlikely that a quantum breakthrough will sneak up on us without time to
> address the issue and, at the very least, warn people to move their funds
> off of taproot and other reused addresses, if not forking in some quantum
> secure alternative.  A recent paper <
> https://www.sussex.ac.uk/physics/iqt/wp-content/uploads/2022/01/Webber-2022.pdf>
> suggest that millions physical qubits will be needed to break EC in a day
> with current error correction technology.  But even if taproot were to be
> very suddenly banned, there is still a small possibility for recovery
> because one can prove ownership of HD pubkeys by providing a zero-knowledge
> proof of the chaincode used to derive them.
>

Thank you, perhaps I'm wrong about this and all his concerns were addressed
and all his suggestions heard. I guess I shouldn't have brought that up,
since I cannot talk for Mark.

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

Re: [bitcoin-dev] Speedy Trial

[Jorge Timón via bitcoin-dev]

On Fri, Mar 11, 2022, 00:12 Russell O'Connor via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> On Thu., Mar. 10, 2022, 08:04 Jorge Timón via bitcoin-dev, <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>>
>>
>> You're right, we shouldn't get personal. We shouldn't ignore feedback
>> from me, mark friedenbach or luke just because of who it comes from.
>>
>
> For goodness sake Jorge, enough with the persecution complex.
>

Thanks for answering.

As the person who initially proposed the Speedy Trial deployment design, I
> can say it was designed to take in account those concerns raised by luke-jr
> and the "no-miner-veto" faction.  I also listened to the
> "devs-do-not-decide" faction and the "no-divegent-consensus-rules" faction
> and their concerns.
>

That's great, but it still doesn't take into account my concerns. I'm not
part of any of those "factions". I guess I'm part of the "yes-user-veto"
faction. I know, I know, we don't matter because the "no-divergent-rules"
"faction" matters too much for us to be listened.



The "no-miner-veto" concerns are, to an extent, addressed by the short
> timeline of Speedy Trial.  No more waiting 2 years on the miners dragging
> their feet.  If ST fails to active then we are back where we started with
> at most a few weeks lost.  And those weeks aren't really lost if they would
> have been wasted away anyways trying to find broad consensus on another
> deployment mechanism.
>
> I get that you don't like the design of Speedy Trial.  You may even object
> that it fails to really address your concerns by leaving open how to follow
> up a failed Speedy Trial deployment.  But regardless of how you feel, I
> believe I did meaningfully address the those miner-veto concerns and other
> people agree with me.
>
> If you are so concerned about listening to legitimate criticism, maybe you
> can design a new deployment mechanism that addresses the concerns of the
> "devs-do-not-decide" faction and the "no-divegent-consensus-rules"
> faction.  Or do you feel that their concerns are illegitimate?  Maybe, by
> sheer coincidence, all people you disagree with have illegitimate concerns
> while only your concerns are legitimate.
>

I talked about this. But the "no-divergent-rules" faction doesn't like it,
so we can pretend we have listened to this "faction" and addressed all its
concerns, I guess.
Or perhaps it's just "prosectution complex", but, hey, what do I know about
psychology?

A major contender to the Speedy Trial design at the time was to mandate
> eventual forced signalling, championed by luke-jr.  It turns out that, at
> the time of that proposal, a large amount of hash power simply did not have
> the firmware required to support signalling.  That activation proposal
> never got broad consensus, and rightly so, because in retrospect we see
> that the design might have risked knocking a significant fraction of mining
> power offline if it had been deployed.  Imagine if the firmware couldn't be
> quickly updated or imagine if the problem had been hardware related.
>

Yes, I like this solution too, with a little caveat: an easy mechanism for
users to actively oppose a proposal.
Luke alao talked about this.
If users oppose, they should use activation as a trigger to fork out of the
network by invalidating the block that produces activation.
The bad scenario here is that miners want to deploy something but users
don't want to.
"But that may lead to a fork". Yeah, I know.
I hope imagining a scenario in which developers propose something that most
miners accept but some users reject is not taboo.

Some of these discussions started at the time of segwit activation. Yes,
segwit, not taproot.

As for mark, he wasn't talking about activation, but quantum computing
concerns. Perhaps those have been "addressed"?
I just don't know where.

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

Re: [bitcoin-dev] Meeting Summary & Logs for CTV Meeting #5

[Jorge Timón via bitcoin-dev]

Thank you for explaining. I agree with luke then, I'm against speedy trial.
I explained why already, I think.
In summary: speedy trial kind of means is miners and not users who decide
the rules.
It gives users less opportunities to react and oppose a malevolent change
in case miners want to impose such change on them.


Why specially jeremy?

I personally distrust him more from experience, but that's subjective, and
kind of offtopic. Sorry, I should try to distrust all the other devs as
much as I distrust him in particular.
"Don't trust, verify", right?


On Wed, Mar 9, 2022, 14:42 ZmnSCPxj  wrote:

> Good morning Jorge,
>
> > What is ST? If it may be a reason to oppose CTV, why not talk about it
> more explicitly so that others can understand the criticisms?
>
> ST is Speedy Trial.
> Basically, a short softfork attempt with `lockinontimeout=false` is first
> done.
> If this fails, then developers stop and think and decide whether to offer
> a UASF `lockinontimeout=true` version or not.
>
> Jeremy showed a state diagram of Speedy Trial on the IRC, which was
> complicated enough that I ***joked*** that it would be better to not
> implement `OP_CTV` and just use One OPCODE To Rule Them All, a.k.a.
> `OP_RING`.
>
> If you had actually read the IRC logs you would have understood it, I even
> explicitly asked "ST ?=" so that the IRC logs have it explicitly listed as
> "Speedy Trial".
>
>
> > It seems that criticism isn't really that welcomed and is just explained
> away.
>
> It seems that you are trying to grasp at any criticism and thus fell
> victim to a joke.
>
> > Perhaps it is just my subjective perception.
> > Sometimes it feels we're going from "don't trust, verify" to "just trust
> jeremy rubin", i hope this is really just my subjective perception. Because
> I think it would be really bad that we started to blindly trust people like
> that, and specially jeremy.
>
> Why "specially jeremy"?
> Any particular information you think is relevant?
>
> The IRC logs were linked, you know, you could have seen what was discussed.
>
> In particular, on the other thread you mention:
>
> > We should talk more about activation mechanisms and how users should be
> able to actively resist them more.
>
> Speedy Trial means that users with mining hashpower can block the initial
> Speedy Trial, and the failure to lock in ***should*** cause the developers
> to stop-and-listen.
> If the developers fail to stop-and-listen, then a counter-UASF can be
> written which *rejects* blocks signalling *for* the upgrade, which will
> chainsplit from a pro-UASF `lockinontimeout=true`, but clients using the
> initial Speedy Trial code will follow which one has better hashpower.
>
> If we assume that hashpower follows price, then users who want for /
> against a particular softfork will be able to resist the Speedy Trial, and
> if developers release a UASF `lockinontimeout=true` later, will have the
> choice to reject running the UASF and even running a counter-UASF.
>
>
> Regards,
> ZmnSCPxj
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] CTV Meeting #5 Agenda (Tuesday, March 7th, 12:00 PT)

[Jorge Timón via bitcoin-dev]

ldn't get personal. I shoud
assume the same malevolent intentions I assume jeremy has from everyone
else.

Thanks
> Michael
>
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>
> --- Original Message ---
> On Wednesday, March 9th, 2022 at 11:02 AM, Jorge Timón via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Since this has meetings like taproot, it seems it's going to end up being
> added in bitcoin core no matter what.
>
> Should we start the conversation on how to resist it when that happens?
> We should talk more about activation mechanisms and how users should be
> able to actively resist them more.
>
>
> On Tue, Mar 8, 2022, 03:32 Jeremy Rubin via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> * Tuesday, March 8th.
>>
>> I think Noon PT == 8pm UTC?
>>
>> but dont trust me i cant even tell what day is what.
>> --
>> @JeremyRubin <https://twitter.com/JeremyRubin>
>>
>>
>> On Mon, Mar 7, 2022 at 6:50 PM Jeremy Rubin 
>> wrote:
>>
>>> Hi all,
>>>
>>> There will be a CTV meeting tomorrow at noon PT. Agenda below:
>>>
>>> 1) Sapio Taproot Support Update / Request for Review (20 Minutes)
>>> - Experimental support for Taproot merged on master
>>> https://github.com/sapio-lang/sapio
>>> 2) Transaction Sponsoring v.s CPFP/RBF (20 Minutes)
>>> -
>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019879.html
>>> -
>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html
>>> 3) Jamesob's Non-Recursive Vaults Post (20 minutes)
>>> -
>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020067.html
>>> 4) What the heck is everyone talking about on the mailing list all of
>>> the sudden (30 minutes)
>>> - EVICT, TLUV, FOLD, Lisp, OP_ANNEX, Drivechain Covenants, Jets, Etc
>>> 5) Q&A (30 mins)
>>>
>>> Best,
>>>
>>> Jeremy
>>>
>>>
>>> --
>>> @JeremyRubin <https://twitter.com/JeremyRubin>
>>>
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Meeting Summary & Logs for CTV Meeting #5

[Jorge Timón via bitcoin-dev]

What is ST? If it may be a reason to oppose CTV, why not talk about it more
explicitly so that others can understand the criticisms?
It seems that criticism isn't really that welcomed and is just explained
away.
Perhaps it is just my subjective perception.
Sometimes it feels we're going from "don't trust, verify" to "just trust
jeremy rubin", i hope this is really just my subjective perception. Because
I think it would be really bad that we started to blindly trust people like
that, and specially jeremy.


On Wed, Mar 9, 2022, 00:37 Jeremy Rubin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Logs here: https://gnusha.org/ctv-bip-review/2022-03-08.log
>
> Notes:
>
> 1) Sapio Updates
>
> Sapio has Experimental Taproot Support now.
> See logs for how to help.
> Rust-bitcoin can also use your help reviewing, e.g.
> https://github.com/rust-bitcoin/rust-miniscript/pull/305
> Adding MuSig support for the oracle servers would be really cool, if
> someone wants a challenge.
>
> 2) Transaction Sponsors
>
> What sponsors are vs. RBF/CPFP.
> Why there's not a BIP # assigned (despite it being written up as a
> BIP+impl in
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html,
> should only get a number if it seems like people agree).
>
> 3) James' Vaults Post
>
> James' vaults are similar to prior art on recursive CTV vaults (Kanzure's
> / Jeremy's), where the number of steps = 1.
> Actually ends up being a very good design for many custody purposes, might
> be a good "80% of the benefit 20% of the work" type of thing.
> People maybe want different things out of vaults... how customizable must
> it be?
>
> 4) Mailing list be poppin'
>
> Zmn shared a prepared remark which spurred a nice conversation.
> General sentiment that we should be careful adding crazy amounts of power,
> with great power comes great responsibility...
> Maybe we shouldn't care though -- don't send to scripts you don't like?
> Math is scary -- you can do all sorts of bizarre stuff with more power
> (e.g., what if you made an EVM inside a bitcoin output).
> Things like OP_EVICT should be bounded by design.
> Problem X: Infrastructure issue for all more flexible covenants:
>1) generate a transition function you would like
>2) compile it into a script covenant
>3) request the transition/txn you want to have happen
> 4) produce a satisifaction of the script covenant for that transaction
>5) prove the transition function *is* what you wanted/secure
> Quantifying how hard X is for a given proposal is a good idea.
> You can prototype covenants with federations in Sapio pretty easily...
> more people should try this!
>
> 5) General discuss
> People suck at naming things... give things more unique names for
> protocols!
> Jeremy will name something the Hot Tub Coin Machine
> Some discussion on forking, if theres any kind of consensus forming,
> doing things like
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018833.html
> How much does a shot-on-goal cost / unforced errors of not making an
> activating client available precluding being able to activate
> luke-jr: never ST; ST is a reason enough to oppose CTV
> jamesob:  OP_DOTHETHING
>
> best,
>
> Jeremy
>
> --
> @JeremyRubin 
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] CTV Meeting #5 Agenda (Tuesday, March 7th, 12:00 PT)

[Jorge Timón via bitcoin-dev]

Since this has meetings like taproot, it seems it's going to end up being
added in bitcoin core no matter what.

Should we start the conversation on how to resist it when that happens?
We should talk more about activation mechanisms and how users should be
able to actively resist them more.


On Tue, Mar 8, 2022, 03:32 Jeremy Rubin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> * Tuesday, March 8th.
>
> I think Noon PT == 8pm UTC?
>
> but dont trust me i cant even tell what day is what.
> --
> @JeremyRubin 
>
>
> On Mon, Mar 7, 2022 at 6:50 PM Jeremy Rubin 
> wrote:
>
>> Hi all,
>>
>> There will be a CTV meeting tomorrow at noon PT. Agenda below:
>>
>> 1) Sapio Taproot Support Update / Request for Review (20 Minutes)
>> - Experimental support for Taproot merged on master
>> https://github.com/sapio-lang/sapio
>> 2) Transaction Sponsoring v.s CPFP/RBF (20 Minutes)
>> -
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019879.html
>> -
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html
>> 3) Jamesob's Non-Recursive Vaults Post (20 minutes)
>> -
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020067.html
>> 4) What the heck is everyone talking about on the mailing list all of the
>> sudden (30 minutes)
>> - EVICT, TLUV, FOLD, Lisp, OP_ANNEX, Drivechain Covenants, Jets, Etc
>> 5) Q&A (30 mins)
>>
>> Best,
>>
>> Jeremy
>>
>>
>> --
>> @JeremyRubin 
>>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] On the regularity of soft forks

[Jorge Timón via bitcoin-dev]

On Tue, Oct 12, 2021 at 5:34 PM Prayank via bitcoin-dev
 wrote:
>
> Hi Michael,
>
> Agree with almost everything.
>
> > Miner signaling is a tool for signaling readiness. It is not voting for the 
> > soft fork or expressing support for the soft fork. There should not be any 
> > attempt to facilitate miner signaling until there is sufficient community 
> > consensus (the mining community is a subset of the community) on the soft 
> > fork.
>
> This is really important which gets ignored. I wish there was a way to solve 
> this problem in a way that it is not misinterpreted by users.
>
> During signalling for taproot, there were lots of users in different 
> communities that believed miners are voting for taproot and we need some 
> percentage of miners to agree before making any changes in Bitcoin. It was 
> not just non-technical users but few mining pools, exchanges etc. also 
> considered miners signaling as some voting process.
>
> Best I could do at that moment was share this link: 
> https://bitcoin.stackexchange.com/questions/97043/is-there-an-active-list-of-bips-currently-open-for-voting/
>
> However I am sure there are lot of people who still think miners vote during 
> signaling. Opinions of few developers on MASF vs UASF also adds more 
> confusion to this thing. I could not think of any solution to solve this 
> problem.

Yes, given most of the arguments given against activation at the end
of the period regardless of mining signaling, it seems sadly it's not
just users but developers too. They seem to believe that miners must
chose for users with bip8(false) because (according to them) with
bip8(true) it is developers who decide for users, and they don't want
to decide for users: they want miners to decide for users.
They don't seem to believe users can actually chose for themselves, sadly.
In the next softfork, sadly, probably the same discussions will be
repeated, the same rational arguments will be ignored and activation
will be once again done, in my opinion, the wrong way and most users
(many more, as we grow in numbers) will remain confused in the same
way and confusing the newcomers they explain bitcoin to.



> --
> Prayank
>
> A3B1 E430 2298 178F
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades

[Jorge Timón via bitcoin-dev]

"Softforks arentcompatible without miner enforcement"
Compatible with what?
"Softforks without miner support cause splits".
No, what causes splits are 3 things:

1) bugs
2) coordination mistakes
3) people wanting different rules.

Let me give an example. Let's say all users want change A.

Only 60% miners want it.
When it activates with LOT=true, will this cause a split?

Well, not necessarily. Since all users will be on the chain with change A,
all miners will quickly abandon that useless chain and start building on
the one that actually pays them.

Do you agree that's what would happen in this example given the assumptions?


On Tue, Jun 29, 2021, 20:44 Eric Voskuil  wrote:

>
> On Jun 29, 2021, at 12:28, Jorge Timón  wrote:
>
> 
> "Confirmation" isn't needed for softforks.
>
>
> All transactions require confirmation. Splitting does not change this.
>
> Softforks are not compatible without miner enforcement. So soft forking
> without it has essentially the same effect as hard forking, the chain
> splits.
>
> Miners controlling confirmation doesn't mean miners control the rules,
> they never did.
>
>
> Please define “control” because these statements hinge on that word.
> Nobody “controls” the rules of others, nor did anyone claim that to be the
> case. Majority hash power does have the ability to determine what gets
> confirmed. That is the central design principle of proof of work. It takes
> that decision out of the hands of politicians and places it at the feet of
> the market.
>
> Read section 11 of the bitcoin paper "even with a majority of hashrate one
> cannot arbitrarily change rules or forge signatures.
>
>
> Never claimed that was the case. One can run any rules that one desires.
>
> You may say users chosing the rules is "politicial". Isn't miners deciding
> them for users more political?
>
>
> No, it’s economic. The largest investment in mining (including highest
> fees paid to incentivize it) determines censorship resistance.
>
> Whatever you call it, it is still how free software works: users decide
> what to run.
>
>
> A *person* can run whatever software they want. Money requires that others
> agree (same rules), and to be money bitcoin requires confirmation.
>
> It is extremely disappointing to see how few developers seem to ubderstand
> this, or even care about users deciding or miners not deciding the rules.
>
>
> It’s poorly understood because there are so many who should know better
> making very misleading statements.
>
> How can we expect users to understand bitcoin when most developers don't
> seem to understand it?
>
>
> Clearly we cannot.
>
> It is really sad.
>
> On Tue, Jun 29, 2021, 19:17 Eric Voskuil  wrote:
>
>>
>> > On Jun 29, 2021, at 10:55, Luke Dashjr  wrote:
>> >
>> > The only alternative to a split in the problematic scenarios are 1)
>> concede
>> > centralised miner control over the network,
>>
>> Miners control confirmation, entirely.
>>
>> This is the nature of bitcoin. And merchants control validation,
>> entirely. Anyone can be a miner or a merchant. Neither is inherently
>> “better” than the other. The largest merchants are likely a handful of
>> exchanges, likely at least as centralized as miners are pooled.
>>
>> Splitting does not change this.
>>
>> > and 2) have inconsistent
>> > enforcement of rules by users who don't agree on what the correct rules
>> are,
>>
>> There are no “correct” rules. Whatever rules one enforces determine what
>> network he chooses to participate in.
>>
>> > again leading to centralised miner control over the network.
>>
>> Leading to? Miners control confirmation, always. Whether that is
>> centralized, just as with merchanting, is up to individuals.
>>
>> > In other words, in this context, accepting a split between disagreeing
>> users
>> > is the ONLY way Bitcoin can possibly continue as a decentralised
>> currency.
>>
>> No, it is not. You are proposing splitting as the method of censorship
>> resistance inherent to Bitcoin. Coordinating this split requires
>> coordinated action. The whole point of bitcoin is coordinate that action
>> based on mining (proof of work). Replacing that with a political process is
>> just a reversion to political money.
>>
>> > Making that split as clean and well-defined as possible not only
>> ensures the
>> > best opportunity for both sides of the disagreement,
>>
>> Trivially accomplished, just change a rule. This isn’t about that. It’s
>> about how one gets others to go along with the new coin, or stay with the
>> old. An entirely political process, which is clearly evident from the
>> campaigns around such attempts.
>>
>> > but also minimises the
>> > risk that the split occurs at all (since the "losing" side needs to
>> concede,
>> > rather than passively continue the disagreement ongoing after the
>> attempted
>> > protocol change).
>>
>> Nobody “needs to” concede once a split has occurred, which is evident in
>> existing splits.
>>
>> e
>>
>> > Luke
>> >
>> >
>> >> On Tuesday 29 June 2021 08

Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades

[Jorge Timón via bitcoin-dev]

"Confirmation" isn't needed for softforks. Miners controlling confirmation
doesn't mean miners control the rules, they never did. Read section 11 of
the bitcoin paper "even with a majority of hashrate one cannot arbitrarily
change rules or forge signatures.

You may say users chosing the rules is "politicial". Isn't miners deciding
them for users more political? Whatever you call it, it is still how free
software works: users decide what to run.
It is extremely disappointing to see how few developers seem to ubderstand
this, or even care about users deciding or miners not deciding the rules.
How can we expect users to understand bitcoin when most developers don't
seem to understand it?

It is really sad.

On Tue, Jun 29, 2021, 19:17 Eric Voskuil  wrote:

>
> > On Jun 29, 2021, at 10:55, Luke Dashjr  wrote:
> >
> > The only alternative to a split in the problematic scenarios are 1)
> concede
> > centralised miner control over the network,
>
> Miners control confirmation, entirely.
>
> This is the nature of bitcoin. And merchants control validation, entirely.
> Anyone can be a miner or a merchant. Neither is inherently “better” than
> the other. The largest merchants are likely a handful of exchanges, likely
> at least as centralized as miners are pooled.
>
> Splitting does not change this.
>
> > and 2) have inconsistent
> > enforcement of rules by users who don't agree on what the correct rules
> are,
>
> There are no “correct” rules. Whatever rules one enforces determine what
> network he chooses to participate in.
>
> > again leading to centralised miner control over the network.
>
> Leading to? Miners control confirmation, always. Whether that is
> centralized, just as with merchanting, is up to individuals.
>
> > In other words, in this context, accepting a split between disagreeing
> users
> > is the ONLY way Bitcoin can possibly continue as a decentralised
> currency.
>
> No, it is not. You are proposing splitting as the method of censorship
> resistance inherent to Bitcoin. Coordinating this split requires
> coordinated action. The whole point of bitcoin is coordinate that action
> based on mining (proof of work). Replacing that with a political process is
> just a reversion to political money.
>
> > Making that split as clean and well-defined as possible not only ensures
> the
> > best opportunity for both sides of the disagreement,
>
> Trivially accomplished, just change a rule. This isn’t about that. It’s
> about how one gets others to go along with the new coin, or stay with the
> old. An entirely political process, which is clearly evident from the
> campaigns around such attempts.
>
> > but also minimises the
> > risk that the split occurs at all (since the "losing" side needs to
> concede,
> > rather than passively continue the disagreement ongoing after the
> attempted
> > protocol change).
>
> Nobody “needs to” concede once a split has occurred, which is evident in
> existing splits.
>
> e
>
> > Luke
> >
> >
> >> On Tuesday 29 June 2021 08:44:56 Eric Voskuil wrote:
> >> At least we are now acknowledging that splitting is what it’s about.
> That’s
> >> progress.
> >>
> >> e
> >>
>  On Jun 29, 2021, at 01:32, Jorge Timón  wrote:
> >>>
> >>> 
> >>> I think the option of "permanent failure because miners veto" should
> >>> actually be abandoned. No, I don't think we should avoid splits when
> >>> possible, I don't think we should avoid splits at all costs.
> >>>
>  On Sun, Jun 27, 2021, 19:12 Billy Tetrud 
> wrote:
>  @Luke
> 
> > They can still slow it down.
> 
>  Absolutely. However I think that the option of permanent failure is
>  important. It certainly would be ideal to ensure that enough bitcoin
>  users support the upgrade *before* releasing it, however realistically
>  this can never be more than an estimate, and estimates can sometimes
> be
>  wildly wrong. It would be unfortunate if miners had a substantially
>  different estimate of user support than the people putting in the work
>  to release bitcoin upgrades. Even if upgrades are never released
> before
>  it becomes clear that a large supermajority of users want the upgrade,
>  if miners don't agree with the estimate a harmful chain split could
>  occur. And I agree with Eric that the goal here is to prevent a chain
>  split during an upgrade when possible. This includes permanent failure
>  of an upgrade when there is unexpectedly large miner opposition.
> 
>  This of course does not prevent a UASF-style deployment to be done
> after
>  an initial failure to deploy occurs. My proposal is essentially a
>  mechanism to improve upon the speedy-trial idea, allowing for even
>  speedier releases (than speedy trial) without adding additional risk
> of
>  undesired chain splits.
> 
> > [BIP8] already has the trinary state you seem to be describing
> 
>  It sounds like you're saying the trinary state of BIP8 is A. Follow
> t

Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades

[Jorge Timón via bitcoin-dev]

I think the option of "permanent failure because miners veto" should
actually be abandoned.
No, I don't think we should avoid splits when possible, I don't think we
should avoid splits at all costs.


On Sun, Jun 27, 2021, 19:12 Billy Tetrud  wrote:

> @Luke
> > They can still slow it down.
>
> Absolutely. However I think that the option of permanent failure is
> important. It certainly would be ideal to ensure that enough bitcoin users
> support the upgrade *before* releasing it, however realistically this can
> never be more than an estimate, and estimates can sometimes be wildly
> wrong. It would be unfortunate if miners had a substantially different
> estimate of user support than the people putting in the work to release
> bitcoin upgrades. Even if upgrades are never released before it becomes
> clear that a large supermajority of users want the upgrade, if miners don't
> agree with the estimate a harmful chain split could occur. And I agree with
> Eric that the goal here is to prevent a chain split during an upgrade when
> possible. This includes permanent failure of an upgrade when there is
> unexpectedly large miner opposition.
>
> This of course does not prevent a UASF-style deployment to be done after
> an initial failure to deploy occurs. My proposal is essentially a mechanism
> to improve upon the speedy-trial idea, allowing for even speedier releases
> (than speedy trial) without adding additional risk of undesired chain
> splits.
>
> > [BIP8] already has the trinary state you seem to be describing
>
> It sounds like you're saying the trinary state of BIP8 is A. Follow the
> longest chain, B. Follow the upgrade chain, or C. follow the non-upgraded
> chain. I agree. However the trinary state in my proposal is materially
> different - it is the signaling itself that is trinary, not just which
> chain is being followed. This allows others to know and make programmatic
> decisions (in software) based on that signaling. I'm sure you can agree
> that does not exist in BIP8.
>
> > No additional bit is needed, as softforks are coordinated between users,
> NOT miners
>
> And yet there is miner involvement, as you rightly pointed out. Miners are
> needed to set the nVersion in the header. So when you say "no additional
> bit is needed", could you please be clearer as to what you mean? Do you
> mean that signaling of opposition in a block can be done without any
> "additional bit"? Or are you just saying that it is redundant to consider
> what miners might be opposing an upgrade?
>
> @Jorge
> > If different users want different incompatible things... there's no way
> to avoid the split
>
> I agree. This happened with bcash, and that's fine. It was painful, but
> there were a significant amount of users that disagreed, and they have the
> chain they want now.
>
> But we generally all want to avoid a chain split when possible. Because
> chain splits have a cost, and that cost can be high, its likely that many
> users would rather choose the chain with the most support rather than
> choosing the chain with their preferred rules.
>
> However, the question here is: how do we estimate what fraction of users
> wants which rules? We don't have a divining rod to determine with certainty
> what users want. We can only make polls of various levels of inaccuracy.
> The methods bitcoin has been using is community discussion and social
> consensus estimation as well as miner signaling during the actual
> deployment period. Neither of these are perfect, but they are both
> reasonable enough mechanisms. However, because both of these mechanisms are
> very rough estimates of user sentiment, we need to consider the possibility
> that sometimes the estimate may be substantially inaccurate when we design
> deployment procedures. This inaccuracy is why we need multiple barriers in
> place for an upgrade, and why we need to have higher thresholds of success
> (require larger supermajorities in both consensus and miner signaling).
>
> Developers obviously care about bitcoin and have an incentive (personal
> and probably financial) to do it right. And miners have both an incentive
> to keep the system healthy, as well as an incentive to mine on the chain
> that the economic majority of users is using. But measuring the consensus
> of the bitcoin community can be extraordinarily difficult to do with
> consistent accuracy, and so I think miner signaling as it has been used as
> a second barrier to entry for an upgrade is quite appropriate.
>
> On Sun, Jun 27, 2021 at 2:22 AM Eric Voskuil  wrote:
>
>> I have not objected to anyone splitting. As I said, a split is always
>> possible, and of course has been done on a large scale. It is only the
>> misleading statements about inherent soft fork “compatibility” and the
>> implication that activation without hash power enforcement does not create
>> a split that I object to. People who know better should be honest about it.
>>
>> Far too many people have been led to believe there is so

Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades

[Jorge Timón via bitcoin-dev]

If different users want different incompatible things (enough on each
side), there's no way to avoid the split. We shouldn't try to avoid
such a split.
Users decide the rules, not miners nor developers.

On Sun, Jun 27, 2021 at 12:05 AM Eric Voskuil via bitcoin-dev
 wrote:
>
> Ultimately there is only one answer to this question. Get majority hash power 
> support.
>
> Soft fork enforcement is the same act as any other censorship enforcement, 
> the difference is only a question of what people want. Given that there is no 
> collective “we”, those wants differ. Bitcoin resolves this question of 
> conflicting wants, but it is not a democracy, it’s a market. One votes by 
> trading.
>
> If one wants to enforce a soft fork (or otherwise censor) this is 
> accomplished by mining (or paying others to do so). Anyone can mine, so 
> everyone gets a say. Mining is trading capital now for more later. If enough 
> people want to do that, they can enforce a soft fork. It’s time Bitcoiners 
> stop thinking of miners as other people. Anyone can mine, and that’s your 
> vote.
>
> Otherwise, as mentioned below, anyone can start a new coin. But it’s 
> dishonest to imply that one can do this and all others will surely follow. 
> This cannot be known, it’s merely a gamble. And it’s one that has been shown 
> to not always pay off.
>
> e
>
> > On Jun 26, 2021, at 14:43, Eric Voskuil  wrote:
> >
> > For some definitions of “block”.
> >
> > Without majority hash power support, activation simply means you are off on 
> > a chain split. Anyone can of course split off from a chain by changing a 
> > rule (soft or otherwise) at any time, so this is a bit of an empty claim.
> >
> > Nobody can stop a person from splitting. The relevant question is how to 
> > *prevent* a split. And activation without majority hash power certainly 
> > does not “ensure” this.
> >
> > e
> >
> >> On Jun 26, 2021, at 14:13, Luke Dashjr via bitcoin-dev 
> >>  wrote:
> >>
> >> BIP8 LOT=True just ensures miners cannot block an upgrade entirely. They 
> >> can
> >> still slow it down.
> >>
> >> It also already has the trinary state you seem to be describing (although
> >> perhaps this could be better documented in the BIP): users who oppose the
> >> softfork can and should treat the successful signal (whether MASF or UASF) 
> >> as
> >> invalid, thereby ensuring they do not follow a chain with the rules in 
> >> force.
> >>
> >> No additional bit is needed, as softforks are coordinated between users, 
> >> NOT
> >> miners (who have no particular say in them, aside from their role as also
> >> being users). The miner involvement is only out of necessity (to set the 
> >> bit
> >> in the header, which users coordinate with) and potentially to accelerate
> >> activation by protecting upgrade-lagging users.
> >>
> >> Luke
> >>
> >>
>  On Saturday 26 June 2021 20:21:52 Billy Tetrud via bitcoin-dev wrote:
> >>> Given the recent controversy over upgrade mechanisms for the
> >>> non-controversial taproot upgrade, I have been thinking about ways to 
> >>> solve
> >>> the problems that both sides brought up. In short, BIP8 LOT=true 
> >>> proponents
> >>> make the point that lazy miners failing to upgrade in a timely manner slow
> >>> down releases of bitcoin upgrades, and BIP9 / BIP8 LOT=false
> >>> proponents make the point that LOT=true can lead to undesirable forks that
> >>> might cause a lot of chaos. I believe both points are essentially correct
> >>> and have created a proposal
> >>>  >>> ip-trinary-version-bits.md> for soft fork upgrades that solve both 
> >>> problems.
> >>>
> >>> The proposal uses trinary version signaling rather than binary signaling.
> >>> For any particular prospective soft fork upgrade, this allows for three
> >>> signaling states:
> >>>
> >>> * Actively support the change.
> >>> * Actively oppose the change.
> >>> * Not signaling (neither support or oppose). This is the default state.
> >>>
> >>> Using this additional information, we can release non-contentious upgrades
> >>> much quicker (with a much lower percent of miners signaling support). For
> >>> contentious upgrades, miners who oppose the change are incentivized to
> >>> update their software to a version that can actively signal opposition to
> >>> the change. The more opposition there is, the higher the threshold
> >>> necessary to lock in the upgrade. With the parameters I currently
> >>> recommended in the proposal, this chart shows how much support signaling
> >>> would be necessary given a particular amount of active opposition
> >>> signaling:
> >>>
> >>> [image: thresholdChart.png]
> >>> If literally no one signals opposition, a 60% threshold should be
> >>> relatively safe because it is a supermajority amount that is unlikely to
> >>> change significantly very quickly (ie if 60% of miners support the change
> >>> today, its unlikely that less than a majority of miners would support t

Re: [bitcoin-dev] Improvement on Blockbuilding

[Jorge Timón via bitcoin-dev]

Sounds really interesting, thanks. Making CPFP reliable would be very nice
in my opinion.

On Sat, May 29, 2021, 14:24 Antoine Riard via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi Mark and Clara,
>
> Great research, thanks for it!
>
> Few questions out of mind after a first read.
>
> > This approach enables block building to consider Child Pays For Parent
> (CPFP) constellations.
>
> I think that's a really interesting point, it's likely that such
> transaction graphs with multiple disjunctive branches become far more
> regular in the future. One can think about OP_CTV's style
> congestion-tree, LN's splicing or chain of coinjoins. If this phenomenon
> happens, can you expect CSB feerate perf to improve ?
>
> > CSB is more complex and requires more computation
>
> Let's say a malicious miner identifies and connects to its competitors'
> mempools then starts to broadcast to them hard-to-traverse CPFP
> constellations. Doing so, this malicious miner would prevent them either
> from assembling block templates at all or slow down their assemblage
> computation enough to gain an advantage in fee collection. Following
> current mempools limits, it would be relevant to know by how much CSB makes
> that kind of DoS possible/efficient.
>
> > From the point of view of global blockspace demand, if miners generally
> became DPFA-sensitive,
> it could encourage creation of additional transactions for the sole
> purpose of bumping stuck ancestors.
>
> As ASB's ancestor set and CSB's candidate set, a fee bidder, we'll have to
> pay the feerate to cover the new transaction fields, high enough to catch
> up with the already-present feerate set ? Likely more feerate efficient to
> RBF the first child, though you have to swallow the replacement feerate
> penalty (default 1 sat/vbyte iirc)
>
> Antoine
>
> Le mar. 25 mai 2021 à 10:34, Murch via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> a écrit :
>
>> Hi Bitcoin Devs,
>>
>> We are writing to share with you a suggested improvement to the current
>> bitcoin core block building algorithm. In short, currently Bitcoin Core
>> uses a straightforward greedy algorithm which evaluates each
>> transaction’s effective fee rate in the context of its unconfirmed
>> ancestors. This overlooks situations in which multiple descendant
>> transactions could be grouped with their shared ancestors to form a more
>> attractive transaction set for block inclusion.
>>
>> For example, if we have 4 transactions A,B,C, and D, with fee rates and
>> weights as follows
>>
>> Tx Fee Weight
>> A51
>> B   101
>> C   151
>> D   141
>>
>> And dependencies:
>> • B is a descendant of A
>> • C is a descendant of B
>> • D is a descendant of A
>> The current algorithm will consider {A,B,C} best which has an effective
>> fee rate of 10. Our suggested algorithm will also consider {A,B,C,D},
>> which has an effective fee rate of 11.
>>
>> Experimental data shows that our suggested algorithm did better on more
>> than 94% of blocks (99% for times of high congestion). We have also
>> compared the results to CBC and SAT Linear Programming solvers. The LP
>> solvers did slightly better, at the price of longer running times. Greg
>> Maxwell has also studied LP solvers in the past, and his results suggest
>> that better running times are possible.
>>
>> The full details are given in this document, and we are happy to hear
>> any comment, critic or suggestion!
>>
>> Best,
>> Mark and Clara
>>
>> Full details:
>>
>> https://gist.github.com/Xekyo/5cb413fe9f26dbce57abfd344ebbfaf2#file-candidate-set-based-block-building-md
>>
>> Research Code:
>> https://github.com/Xekyo/blockbuilding
>>
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Consensus protocol immutability is a feature

[Jorge Timón via bitcoin-dev]

Sure, many things that were though only possible with hardforks initially
were later shown to be possible with softforks.

That doesn't mean hardforks should be taboo in my opinion though.


On Mon, May 24, 2021, 01:09 vjudeu via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> > Because the above block header format is hashed to generate the
> `prevBlockHash` for the *next* block, it is almost impossible to change the
> format without a hardfork.
>
> First, assume that everything should be validated as today to be
> backward-compatible. For that reason, removing SHA-256 is impossible. Then,
> notice that breaking SHA-256 would mean that there would be more and more
> leading zeroes in "prevBlockHash". Breaking SHA-256 fully would mean
> reaching all zeroes hash. So, the old client would see "prevBlockHash" with
> all zeroes.
>
> Soft-fork means that previously valid blocks could be invalid, so rules
> should be more strict. And that means we could have two headers, one for
> SHA-256 and one for SHA-3. Normally, it would mean that our 80-byte headers
> would take 160 bytes instead. But we could compress it a little bit if we
> share some data.
>
> > * `nVersion`: 4 bytes
>
> Version would be some higher number than today and validated as today. It
> could be shared for both headers.
>
> > * `prevBlockHash`: 32 bytes, SHA2 of previous block.
>
> Previous block hash in SHA-256 would have more and more leading zeroes, so
> we could reuse them and fill with SHA-3 truncated to N bits. In this way,
> after fully breaking SHA-256 it would be fully replaced by SHA-3. Until
> then, first N bits could refer to truncated SHA-3 and the rest to SHA-256.
> When passing that to old nodes, that bits could be zeroed, but all new
> nodes should see them and perform SHA-3 validation.
>
> Example:
>
> SHA-2 of some block:
> 0019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
> SHA-3 of the same data:
> 95587d55da5108290c46bac70b622715ae380ef7a313febcc27aeb1c51a28d90
> 32 bytes stored for that block:
> 95587d550019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
>
> Of course, we should perform SHA-3 on a different data than used for
> SHA-2, at least merkle root should be recalculated, but it is just an
> example showing how single 32-byte string could store data for both hash
> functions.
>
> > * `merkleTreeRoot`: 32 bytes, SHA2 of topmost Merkle tree node.
>
> If SHA-256 would be broken, then we could use single coinbase transaction
> to prevent doing transactions in the old way. That transaction would
> contain SHA-3 of the new merkle root, as you mentioned. New nodes could
> treat that transaction as some kind of annex to the block header, but still
> doing SHA-2 is needed for backward compatibility. For that reason, storing
> 32 bytes for SHA-2 and 32 bytes for SHA-3 is needed, unless we have some
> fast way to get hash with all zeroes, then we can save that 32 bytes.
>
> > * `nTime`: 4 bytes, miner-imagined time.
>
> Time should be the same in both headers, so there is no need to duplicate
> it.
>
> > * `nBits`: 4 bytes, encoded difficulty target
>
> Difficulty should be different for SHA-2 and SHA-3. Finally when SHA-256
> would be broken, we could reach 0300 for SHA-256 and store only SHA-3
> difficulty.
>
> > * `nonce`: 4 bytes, random number with no other meaning.
>
> Nonce should be also different for SHA-2 and SHA-3. If SHA-256 would be
> fully broken, it could be set to zero for SHA-2 and stored only for SHA-3.
>
> On 2021-05-23 20:12:00 user ZmnSCPxj  wrote:
> > Good morning vjudeu,
> >
> > > > Perhaps the only things that cannot be usefully changed in a
> softfork is the block header format and how proof-of-work is computed from
> the block header.
> > >
> > > Why not? I can imagine a soft fork where the block header would
> contain SHA-256 and SHA-3 hashes in the same place. The SHA-256 would be
> calculated as-is, but the SHA-3 would be truncated only to cover zero bits
> in SHA-256 hashes. In this way, if SHA-256 would be totally broken, old
> nodes would see zero hashes in the previous block hash and the merkle tree
> hash, but the new nodes would see correct SHA-3 hashes in the same place.
> So, for example if we have 1d00 difficulty, the first 32-bits would be
> zeroes for all old nodes, but all new nodes would see SHA-3 truncated to
> 32-bits in the same place. The difficulty could tell us how many zero bits
> we should truncate our SHA-3 result to. Also, in the same way we could
> introduce SHA-4 in the future as a soft-fork if SHA-3 would be broken and
> we would see many zero bits in our mixed SHA-256 plus SHA-3 consensus.
> >
> > I do not think I follow.
> >
> > The block header has a Merkle tree root that is a SHA-256 of some Merkle
> tree node, is that what you refer to?
> > Do you mean the same Merkle tree node has to hash to some common value
> in both SHA-2 and SHA-3?
> >
> > Or do you refer to the `prevBlockHash`?
> > Do you mean the same `prevBlockHash` h

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

[Jorge Timón via bitcoin-dev]

Your analysis is correct.
In perfect competition, profits tend to zero, which means the costs of
mining tend to equal the reward.
Since the reward is fees plus subsidy, reducing the subsidy should reduce
mining costs.

I think convincing other users we need such a softfork to reeuce the
subsidy is going to be hard though.
Even among developers, these proposals seem to be kind of taboo, because
people tene to perceive them as "attacking miners".
Sadly the notion that miners decide consensus rules is pretty extended even
among developers. The recent bip8(true) vs bip8(false) discussions are
anundant evidence that this is the case. Most devs perceive that not giving
miners veto power over proposals somehow means that then developers become
dictators who can unilaterally decide the rules.
They don't accept the fact that it's users who decide the consensus rules.
For them, if it's not miners who decide, then it must be devs. That's
because they see users as a bunch of uninformed imbeciles who can't
understand anything or decide anything. And yet this arrogant position is
coming from people who seemingly don't understand section 11 of the
whitepaper when it says "even with a hashrate majority, that doesn't allow
one to arbitrarily change the rules or forge signatures" which can be
summarized to "miners DO NOT decide the rules.

Given these deeps misunderstandings, most devs (and who knows how many
users) will consider a softfork to reduce mining subsidy "impossible, since
miners will oppose it".
This incredibly sad situation is where we're at.

I personally would be in favor of a softfork to reduce the subsidy. That
would hopefully pacify some of the people concerned with bitcoin's energy
consumption. Bitcoin ecologists should defend this and not "proof of stake"
and other technical nonsense.







On Mon, May 24, 2021, 21:32 Billy Tetrud via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Before we can decide on tradeoffs that reduce security in favor of less
> energy usage, or less inflation, or whatever goal you might have for
> reducing (or delaying) coinbase rewards, we need to decide as a community
> how much security bitcoin *needs*.
>
> Do we need to be secure against an attacker with a budget of $1
> billion/year for an attack? $10 billion/year? More?
>
> An upper limit would be the budget of the largest government: the US. The
> US federal budget is almost $5 trillion/year. But they certainly couldn't
> spend all that budget attacking bitcoin. About $3 trillion of that is
> mandatory spending, which couldn't be allocated to such an attack. About
> $1.5 trillion is discretionary, which includes the military budget. It
> seems like an upper limit on the amount that could be siphoned from that
> budget to attack bitcoin would be 5%. That would take massive political
> cooperation and wheeling and dealing. Likely spending that much would not
> be politically feasible, but it seems possible, since a 5% reduction in
> other activities is something other departments would likely be able to
> sustain with just a bit of downsizing. Or that money could simply come from
> more borrowing. 5% of $1.5 trillion is $75 billion. So that seems like a
> pretty solid upper limit on the amount the US could allocate to an attack
> in a year, in that it seems incredibly unlikely that more money than that
> could be allocated. Such an expenditure might be eventually seen as
> justified since the federal reserve has been inflating the supply of
> dollars by 17.5% on average every year, which would be $1 trillion next
> year (and more the next, etc). A similar story is told if you calculate the
> amount of seigniorage banks get access to by their ability to use
> fractional reserve to inflate the supply of M2 money.  It should be
> considered tho that this seigniorage doesn't give its beneficiaries that
> full value, but rather some fraction of that value - say 5% earned by being
> first to buy with that new money and earning interest on it. So 5% of a
> trillion is $50 billion. Still, over just two years, that's enough to pay
> for an attack of at least that size ($75 billion).
>
> The budget for the government of China is about $3.6 trillion, the second
> largest in the world. And since they're an authoritarian country, they can
> basically do whatever they want with that money. It still seems unlikely
> they would spend more than 5% of that budget on doing something like
> attacking bitcoin. However, consider that China's M2 money supply has been
> increasing at a rate of almost $3 trillion per year. Protecting the ability
> to do this is seems like something worth spending some (printed) money on.
> So perhaps at some point, spending 10 or 20% of their budget for a year or
> two to attack bitcoin might seem like a good idea to some mickey mouse in
> the government. That would be $720 billion/year.
>
> So given the amount of seigniorage taken in every year by these central
> banks, it would seem to justify la

Re: [bitcoin-dev] Consensus protocol immutability is a feature

[Jorge Timón via bitcoin-dev]

Hardforks can be useful too.
But, yes, I agree softforks are preferable whenever possible.

On Sat, May 22, 2021, 20:55 Raystonn .  wrote:

> None of these required a hard fork.  I should rephrase my previous email
> to clarify the intended topic as hard consensus changes, requiring a hard
> fork.  "Soft" forks can be useful.
>
> Raystonn
>
> --
> *From:* Jorge Timón 
> *Sent:* Saturday, May 22, 2021 7:55 AM
> *To:* Raystonn . ; Bitcoin Protocol Discussion <
> bitcoin-dev@lists.linuxfoundation.org>
> *Subject:* Re: [bitcoin-dev] Consensus protocol immutability is a feature
>
> That is clearly not true. People entretain making changes to the protocol
> all the time. Bitcoin is far from perfect and not improving it would be
> stupid in my opinion.
> Some improvements require changes to the consensus rules.
> Recent changes include relative lock time verify or segwit. These are
> important changes that made things like lightning much easier and efficient
> than they could possibly be without them.
> Taproot, which is a recent proposal, could help simplify the lightning
> protocol even further, and make it more efficient and its usage more
> private. And there are more use cases.
>
> There have been consensus rule changes since bitcoin started, and with
> good reason. As a user, you can always oppose new changes. And if enough
> users agree with you, you will be able to maintain your own chain with the
> old rules. At the same time, there's nothing you can do to stop other users
> who want those changes from coordinating with each other to adopt them.
>
> Perhaps you're interested in bip99, which discusses consensus rule changes
> in more detail.
>
>
>
> On Sat, May 22, 2021, 13:09 Raystonn . via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Suggestions to make changes to Bitcoin's consensus protocol will only ever
> be entertained if Bitcoin is completely dead without such a change.  Any
> attempt to change consensus protocol without a clear and convincing
> demonstration to the entire network of participants that Bitcoin will die
> without that change is a waste of your own time.  Bitcoin's resistance to
> consensus changes is a feature that makes it resistant to being coopted and
> corrupted.  I recommend developers focus on making improvements that do not
> attempt to change the consensus protocol.  Otherwise, you are simply
> working on an altcoin, which is off-topic here.
>
> Raystonn
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Consensus protocol immutability is a feature

[Jorge Timón via bitcoin-dev]

That is clearly not true. People entretain making changes to the protocol
all the time. Bitcoin is far from perfect and not improving it would be
stupid in my opinion.
Some improvements require changes to the consensus rules.
Recent changes include relative lock time verify or segwit. These are
important changes that made things like lightning much easier and efficient
than they could possibly be without them.
Taproot, which is a recent proposal, could help simplify the lightning
protocol even further, and make it more efficient and its usage more
private. And there are more use cases.

There have been consensus rule changes since bitcoin started, and with good
reason. As a user, you can always oppose new changes. And if enough users
agree with you, you will be able to maintain your own chain with the old
rules. At the same time, there's nothing you can do to stop other users who
want those changes from coordinating with each other to adopt them.

Perhaps you're interested in bip99, which discusses consensus rule changes
in more detail.



On Sat, May 22, 2021, 13:09 Raystonn . via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Suggestions to make changes to Bitcoin's consensus protocol will only ever
> be entertained if Bitcoin is completely dead without such a change.  Any
> attempt to change consensus protocol without a clear and convincing
> demonstration to the entire network of participants that Bitcoin will die
> without that change is a waste of your own time.  Bitcoin's resistance to
> consensus changes is a feature that makes it resistant to being coopted and
> corrupted.  I recommend developers focus on making improvements that do not
> attempt to change the consensus protocol.  Otherwise, you are simply
> working on an altcoin, which is off-topic here.
>
> Raystonn
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Reminder on the Purpose of BIPs

[Jorge Timón via bitcoin-dev]

> Despite the continual harassment, I have even made two efforts to try to
> (fairly) make things faster, and have been obstructed both times by ST
> advocates. It appears they intend to paint me as "deliberately refusing"
> (to
> use your words) in order to try to put Bitcoin and the BIP process under
> their control, and abuse it in the same manner in which they abused
> Bitcoin
> Core's usual standards (by releasing ST without community consensus).
>

I haven'tpaying attention to the BIPs.
But I just want to say I agree it is the case that speed trial didn't have
consensus and had many good and logical arguments against it.
Sadly discussions around taproot activation I've been lacking logic and
having too many irrational arguments appealing to emotions.

I'm really disapointed at the community right now.
I'm sorry for luke and others defending lot=true (the whole point of bip8
anyway), but I feel ignored and frustrated when I try to participate in
these irrational debates.
I miss the rational debates here.

But if we're gping to turn this list into an irrational place, with ad
hominem fallacies and insults, I guess I can say my subjective personal
opinion about other people too.
I think it is you, Matt, who is playing dumb, not Luke.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Taproot Activation Meeting Reminder: April 6th 19:00 UTC bitcoin/bitcoin-dev

[Jorge Timón via bitcoin-dev]

So the only thing that seemed clear, using height as per bip8, it's not
clear anymore.
And, as usual, we're not talking about activation in general but about
taproot activation, segwit activation...

I won't make it to the meeting because I don't think I have much more to
contribute that I haven't said already beyond perhaps: sigh.
My arguments will probably ignored again, so it doesn't matter.


On Sun, Apr 4, 2021, 06:39 Jeremy via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> We'll be having another meeting this Tuesday, as per
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018699.html.
> If you can't make it feel free to leave a comment on any agenda item below,
> or if you think there are other things to be discussed.
>
> Agenda:
>
> 1. AJ's update to MTP time.
>
> Please review https://github.com/bitcoin/bitcoin/pull/21377 as AJ updated
> it substantially.
>
> The PR is now purely MTP based, and the state machine has been simplified.
> This approach is intended to be compatible with a mandatory signaling
> period (via a LAST_CHANCE change) and makes it easier to deploy ST on
> signets (irrelevant for Taproot, because it is already active on all
> signets).
>
> 2. Selecting between MTP and Height
>
> In the previous meeting, there was no substantial publicly discussed
> benefit to using MTPs over height. Since agenda item 1, there is now a
> tangible benefit to using MTP.
>
> The changes AJ promulgated for MTP neutralizes the argument, mostly, that
> MTP was easier to review. As such, the main conversation in this agenda
> item is around the pros/cons of height or MTP and determining if we can
> reach consensus on either approach.
>
> 3. Timeline Discussion
> In all hope, we will reach consensus around item 2. Should that occur, we
> can use this time to discuss a final selection on parameters, mindful of
> Core's process.
>
> If the meeting doesn't reach rough consensus around item 2, it seems that
> we may fall short on the proposed schedule from last time. In this section,
> we can discuss realities around scheduling.
>
>
> Best,
>
> Jeremy
>
>
>
> --
> @JeremyRubin 
> 
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Straight Flag Day (Height) Taproot Activation

[Jorge Timón via bitcoin-dev]

Concept nack.
This has no advantage over bip8(true).
Bip9(false) is just bip9.
Thr only reasonable argument against bip8(true) is "some people may do
bip8(false) instead", which is a stypid argument applyable to any
activation method.

People against taproot should want code to forbid its activation rather
than limiting themselves to suport bip9/bip8(false) and hope it doesn't get
activated it.

Some other arguments seem to be based on the wrong assumption that miners
should decide the rules.

Thisproposal solves nothing, just adds to the noise and thus is really
disappointing.


On Sat, Mar 6, 2021, 12:33 Anthony Towns via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Wed, Mar 03, 2021 at 11:49:57AM -0500, Matt Corallo wrote:
> > On 3/3/21 09:59, Anthony Towns wrote:
> > > A couple of days ago I would have disagreed with this; but with Luke
> > > now strongly pushing against implementing lot=false, I can at least see
> > > your point...
> > Right. It may be the case that the minority group threatening to fork off
> > onto a lot=true chain is not large enough to give a second thought to.
> > However, I'm not certain that its worth the risk, and, as Chris noted in
> his
> > post this morning, that approach is likely to include more drama.
>
> I think there's two different interpretations of what a "user-activated
> fork" means:
>
>  1) if people try to take bitcoin in a direction that risks destroying
> it, it's possible to ignore both devs and hashpower entirely and force
> a chain split to ensure it's possible to continue transacting with
> "the real bitcoin".
>
>  2) removing miners' influence over consensus rules entirely -- so that
> not only can users overcome miner objections by risking a chain split,
> but so that miners don't have any greater ability to object than
> anyone else in the ecosystem.
>
> In my opinion, bip8's optional lockinontimeout setting and must-signal
> approach is well-designed for case 1; if miners object for good reasons,
> then there is no need to override them (if there's a good reason not to do
> something, it shouldn't be done!), while still having the possibility to
> override them if they object for bad reasons. Because hashpower disagrees,
> there's always a risk of a chain split in that case, so the additional
> risk introduced by a signalling requirement is pretty minimal. That the
> lockinontimeout value is a setting means it can be switched only when
> we're sure there aren't good reasons for the objection.
>
> There is a lot of work to be done to make bitcoind have an acceptable
> chance of gracefully *surviving* a network split introduced by this sort
> of conflict; but provided no one started setting lockinontimeout=true
> until we were six or so months into an activation attempt (and hence
> had the opportunity to judge whether the reasons for not activating
> were bad), that would likely be enough time to start implementing some
> safety mechanisms.
>
> But there seems to be much more signficant support for the case 2 than I
> expected; as evidenced by the "let's do lockinontimeout=true immediately"
> advocacy, eg:
>
>   I am not willing to go to war for Taproot. I'll be honest the reason
>   I'm interested at all is that devs I respect spent a lot of energy and
>   time on it and I was reluctant to let their marginally beneficial work
>   go to waste.
>
>   I am, however, willing to go to war against LOT=False.
>
>-- https://twitter.com/francispouliot_/status/1363876292169465856
>
> I don't think bip8 is well-designed for that approach: most importantly,
> with early adoption of lockinontimeout=true, bip8 *encourages* a consensus
> split in the event that good reasons for not activating are discovered
> afterwards, because lockinontimeout=false nodes remain able to abandon
> the activation attempt. Consensus splits are terrible; they should be
> a last resort used only in the event that bitcoin's fundamental nature
> is threatened, not a standard risk if bugs happened to be discovered
> late. But additionally, if we are worried miners might not be acting
> in the interests of all bitcoin users, there are other games they could
> play, such as "if you want X activated quickly, also give us Y; otherwise
> we'll delay it as long as possible".
>
> Losing the opportunity to abandon an activation attempt, by whatever
> mechanism, also puts a lot more pressure on being absolutely sure of the
> desirability of the change at the point when it's merged; because miners,
> third-party devs, businesses, and users don't even have the option of
> attempting to influence miners, all objections needs to be raised when
> the activation parameters are merged, which raises the stakes for that
> event substantially.
>
> I think my conclusions from that are:
>
>  * as it stands, people are expecting to run bip8/lot=true nodes on the
>network immediately; so deploying bip8/lot=false with compatible
>parameters risks causing con

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

[Jorge Timón via bitcoin-dev]

Just to clarify, I'm not saying bitcoin core should maintain the
"oppose proposal" part of the software. presumably people opposing the
change don't want much of the recent software changes anyway.
But perhaps it wouldn't be so bad, to oppose other proposals, perhaps.
I don't expect anyone to want this, but if people want it I offer
myself to code it,
I mean, just imagine that a day after publishing a bitcoin core
release with activation software for taproot some one, let's say in
New York reach an Agreement to "just use the same activation
mechanism, but for our 32 mb hardfork, it's about time, now computers
are 64 bits anyway". How convenient would it be to just cancel that
with 2 lines in bitcoin core?
Not that I think it will be necessary, but perhaps we want it just in case.

On Mon, Feb 22, 2021 at 5:31 PM Jorge Timón  wrote:
>
> Sorry, I haven't read everything. I just want to say what I think is
> the best option and why.
> Let's say something like 2 years in which miners can signal activation
> after which, the MUST signal it for their blocks to be valid (I think
> this is LOT=true, but I don't remember what LOT stands for).
> Some may argue than it's easier to move from LOT=false to LOT=true
> than viceversa (I think I'm getting this right), but either way
> different clients could interpret things more differently more easily
> and, you know, that's really bad.
> If anyone is against the consensus change itself, what they should do
> is run a client in which the must is turned into a MUST NOT. Whenever
> miners signal activation, blocks aren't valid so that it doesn't
> happen.
> That way both sides can be cleanly separated and both communities
> (assuming there's a community of users opposing the change) can stick
> together with their own in the same chain. That is, having only 2
> chains in total if there are users opposing the change or only one if
> not, but never 2 chains for people who want the change or 2 chains for
> pople who don't want it.
>
> Just my two sats, please nobody ask me "why would anyone oppose
> taproot?" or anything similar. Because I'm trying to generalize here,
> if we're talking about activation, I think the specifics of the change
> are kind of irrelevant.
>
> Separately: thanks to everyone who worked on taproot.
>
>
> On Mon, Feb 22, 2021 at 3:00 PM Matt Corallo via bitcoin-dev
>  wrote:
> >
> >
> >
> > On Feb 22, 2021, at 05:16, Anthony Towns  wrote:
> >
> > If a lockinontimeout=true node is requesting compact blocks from a
> > lockinontimeout=false node during a chainsplit in the MUST_SIGNAL phase,
> > I think that could result in a ban.
> >
> > More importantly, nodes on both sides of the fork need to find each other.
> >
> >
> > (If there was going to be an ongoing fork there'd be bigger things to
> > worry about...)
> >
> >
> > I think it should be clear that a UASF-style command line option to allow 
> > consensus rule changes in the node in the short term, immediately before a 
> > fork carries some risk of a fork, even if I agree it may not persist over 
> > months. We can’t simply ignore that.
> >
> > I think the important specific case of this is something like "if a chain
> > where taproot is impossible to activate is temporarily the most work,
> > miners with lockinontimeout=true need to be well connected so they don't
> > end up competing with each other while they're catching back up".
> >
> >
> > Between this and your above point, I think we probably agree - there is 
> > material  technical complexity hiding behind a “change the consensus rules“ 
> > option. Given it’s not a critical feature by any means, putting resources 
> > into fixing these issues probably isn’t worth it.
> >
> > Matt
> > ___
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

[Jorge Timón via bitcoin-dev]

Sorry, I haven't read everything. I just want to say what I think is
the best option and why.
Let's say something like 2 years in which miners can signal activation
after which, the MUST signal it for their blocks to be valid (I think
this is LOT=true, but I don't remember what LOT stands for).
Some may argue than it's easier to move from LOT=false to LOT=true
than viceversa (I think I'm getting this right), but either way
different clients could interpret things more differently more easily
and, you know, that's really bad.
If anyone is against the consensus change itself, what they should do
is run a client in which the must is turned into a MUST NOT. Whenever
miners signal activation, blocks aren't valid so that it doesn't
happen.
That way both sides can be cleanly separated and both communities
(assuming there's a community of users opposing the change) can stick
together with their own in the same chain. That is, having only 2
chains in total if there are users opposing the change or only one if
not, but never 2 chains for people who want the change or 2 chains for
pople who don't want it.

Just my two sats, please nobody ask me "why would anyone oppose
taproot?" or anything similar. Because I'm trying to generalize here,
if we're talking about activation, I think the specifics of the change
are kind of irrelevant.

Separately: thanks to everyone who worked on taproot.


On Mon, Feb 22, 2021 at 3:00 PM Matt Corallo via bitcoin-dev
 wrote:
>
>
>
> On Feb 22, 2021, at 05:16, Anthony Towns  wrote:
>
> If a lockinontimeout=true node is requesting compact blocks from a
> lockinontimeout=false node during a chainsplit in the MUST_SIGNAL phase,
> I think that could result in a ban.
>
> More importantly, nodes on both sides of the fork need to find each other.
>
>
> (If there was going to be an ongoing fork there'd be bigger things to
> worry about...)
>
>
> I think it should be clear that a UASF-style command line option to allow 
> consensus rule changes in the node in the short term, immediately before a 
> fork carries some risk of a fork, even if I agree it may not persist over 
> months. We can’t simply ignore that.
>
> I think the important specific case of this is something like "if a chain
> where taproot is impossible to activate is temporarily the most work,
> miners with lockinontimeout=true need to be well connected so they don't
> end up competing with each other while they're catching back up".
>
>
> Between this and your above point, I think we probably agree - there is 
> material  technical complexity hiding behind a “change the consensus rules“ 
> option. Given it’s not a critical feature by any means, putting resources 
> into fixing these issues probably isn’t worth it.
>
> Matt
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Modern Soft Fork Activation

[Jorge Timón via bitcoin-dev]

I see how your approach doesn't lose goal 3 while "mine" does.
Regarding goal 4, I don't think any of the approaches loses it. "Use
hashpower enforcement to de-risk the upgrade process, wherever
possible".
Well, in the case of activation while there's "many" non upgrade
miners, they simply can't help to reduce upgrade risks unless they
upgrade. It doesn't matter if the activation is silent or with
mandatory signaling. Am I missing something?

>  in order to nudge miners

That's not the goal at all. All my arguments have been focused on
users, not miners.

> If you want to fork yourself off the network, you can do it in easier ways,

Well, it's not that you want to fork yourself off the network, is that
you don't want change X. Ideally change X wouldn't be activated, but
if it is, you prefer to be in a chain without change X.
Let's say we're using your system to deploy change X you oppose for
legitimate reasons.
What easier thing would you do as a user to resist change X with all
other users who also oppose it?

If there are simpler and better ways to do this, great. It's just
something to think about.





On Fri, Jan 10, 2020 at 11:43 PM Matt Corallo  wrote:
>
> I went back and forth with a few folks on this one. I think the fact that we 
> lose goals 3/4 very explicitly in order to nudge miners seems like a poor 
> trade off. I’ll note that your point 2 here seems a bit disconnected to me. 
> If you want to fork yourself off the network, you can do it in easier ways, 
> and if miners want to maliciously censors transactions to the detriment of 
> users, rejecting a version bit doesn’t really help avoid that.
>
> Your point about upgrade warnings is well-made, but I’m dubious of it’s value 
> over the network chaos many large forks might otherwise cause.
>
> Matt
>
> > On Jan 10, 2020, at 17:22, Jorge Timón  wrote:
> >
> > Well, bip9 doesn't only fall apart in case of unreasonable objection,
> > it also fails simply with miners' apathy.
> > Anyway, your proposed plan should take care of that case too, I think.
> > Overall sounds good to me.
> >
> > Regarding bip8-like activation, luke-jr suggested that instead of
> > simply activating on date x if failed to do so by miners' signaling, a
> > consensus rule could require the blocks to signal for activation in
> > the last activation window.
> > I see 2 main advantages for this:
> >
> > 1) Outdated nodes can implement warnings (like in bip9) and they can
> > see those warnings even if it's activated in the last activation
> > window. Of course this can become counterproductive if miners' squat
> > signaling bits for asicboost again.
> >
> > 2) It is easier for users to actively resist a given change they
> > oppose. Instead of requiring signaling, their nodes can be set to
> > ignore chains that activate it. This will result in a fork, but if
> > different groups of users want different things, this is arguably the
> > best behaviour: a "clean" split.
> >
> > I assume many people won't like this, but I really think we should
> > consider how users should ideally resist an unwanted change, even if
> > the proponents had the best intentions in mind, there may be
> > legitimate reasons to resist it that they may not have considered.
> >
> >> On Fri, Jan 10, 2020 at 10:30 PM Matt Corallo via bitcoin-dev
> >>  wrote:
> >>
> >> There are a series of soft-fork designs which have recently been making
> >> good progress towards implementation and future adoption. However, for
> >> various reasons, activation methods therefor have gotten limited
> >> discussion. I'd like to reopen that discussion here.
> >>
> >> It is likely worth revisiting the goals both for soft forks and their
> >> activation methods to start. I'm probably missing some, but some basic
> >> requirements:
> >>
> >> 1) Avoid activating in the face of significant, reasonable, and directed
> >> objection. Period. If someone has a well-accepted, reasonable use of
> >> Bitcoin that is working today, have no reason to believe wouldn't work
> >> long into the future without a change, and which would be made
> >> impossible or significantly more difficult by a change, that change must
> >> not happen. I certainly hope there is no objection on this point (see
> >> the last point for an important caveat that I'm sure everyone will jump
> >> to point out).
> >>
> >> 2) Avoid activating within a timeframe which does not make high
> >> node-level-adoption likely. As with all "node" arguments, I'll note that
> >> I mean "economically-used" nodes, not the thousand or so spy nodes on
> >> Google Cloud and AWS. Rule changes don't make sense without nodes
> >> enforcing them, whether they happen to be a soft fork, hard fork, or a
> >> blue fork, so activating in a reduced timeframe that doesn't allow for
> >> large-scale node adoption doesn't have any value, and may cause other
> >> unintended side effects.
> >>
> >> 3) Don't (needlessly) lose hashpower to un-upgraded miners. As a part of
> >> Bitcoin's security com

Re: [bitcoin-dev] Modern Soft Fork Activation

[Jorge Timón via bitcoin-dev]

Well, bip9 doesn't only fall apart in case of unreasonable objection,
it also fails simply with miners' apathy.
Anyway, your proposed plan should take care of that case too, I think.
Overall sounds good to me.

Regarding bip8-like activation, luke-jr suggested that instead of
simply activating on date x if failed to do so by miners' signaling, a
consensus rule could require the blocks to signal for activation in
the last activation window.
I see 2 main advantages for this:

1) Outdated nodes can implement warnings (like in bip9) and they can
see those warnings even if it's activated in the last activation
window. Of course this can become counterproductive if miners' squat
signaling bits for asicboost again.

2) It is easier for users to actively resist a given change they
oppose. Instead of requiring signaling, their nodes can be set to
ignore chains that activate it. This will result in a fork, but if
different groups of users want different things, this is arguably the
best behaviour: a "clean" split.

I assume many people won't like this, but I really think we should
consider how users should ideally resist an unwanted change, even if
the proponents had the best intentions in mind, there may be
legitimate reasons to resist it that they may not have considered.

On Fri, Jan 10, 2020 at 10:30 PM Matt Corallo via bitcoin-dev
 wrote:
>
> There are a series of soft-fork designs which have recently been making
> good progress towards implementation and future adoption. However, for
> various reasons, activation methods therefor have gotten limited
> discussion. I'd like to reopen that discussion here.
>
> It is likely worth revisiting the goals both for soft forks and their
> activation methods to start. I'm probably missing some, but some basic
> requirements:
>
> 1) Avoid activating in the face of significant, reasonable, and directed
> objection. Period. If someone has a well-accepted, reasonable use of
> Bitcoin that is working today, have no reason to believe wouldn't work
> long into the future without a change, and which would be made
> impossible or significantly more difficult by a change, that change must
> not happen. I certainly hope there is no objection on this point (see
> the last point for an important caveat that I'm sure everyone will jump
> to point out).
>
> 2) Avoid activating within a timeframe which does not make high
> node-level-adoption likely. As with all "node" arguments, I'll note that
> I mean "economically-used" nodes, not the thousand or so spy nodes on
> Google Cloud and AWS. Rule changes don't make sense without nodes
> enforcing them, whether they happen to be a soft fork, hard fork, or a
> blue fork, so activating in a reduced timeframe that doesn't allow for
> large-scale node adoption doesn't have any value, and may cause other
> unintended side effects.
>
> 3) Don't (needlessly) lose hashpower to un-upgraded miners. As a part of
> Bitcoin's security comes from miners, reducing the hashpower of the
> network as a side effect of a rule change is a needless reduction in a
> key security parameter of the network. This is why, in recent history,
> soft forks required 95% of hashpower to indicate that they have upgraded
> and are capable of enforcing the new rules. Further, this is why recent
> soft forks have not included changes which would result in a standard
> Bitcoin Core instance mining invalid-by-new-rules changes (by relying on
> the standardness behavior of Bitcoin Core).
>
> 4) Use hashpower enforcement to de-risk the upgrade process, wherever
> possible. As a corollary of the above, one of the primary reasons we use
> soft forks is that hashpower-based enforcement of rules is an elegant
> way to prevent network splits during the node upgrade process. While it
> does not make sense to invest material value in systems protected by new
> rules until a significant majority of "economic nodes" is enforcing said
> rules, hashpower lets us neatly bridge the gap in time between
> activation and then. By having a supermajority of miners enforce the new
> rules, attempts at violating the new rules does not result in a
> significant network split, disrupting existing users of the system. If
> we aren't going to take advantage of this, we should do a hard fork
> instead, with the necessarily slow timescale that entails.
>
> 5) Follow the will of the community, irrespective of individuals or
> unreasoned objection, but without ever overruling any reasonable
> objection. Recent history also includes "objection" to soft forks in the
> form of "this is bad because it doesn't fix a different problem I want
> fixed ASAP". I don't think anyone would argue this qualifies as a
> reasonable objection to a change, and we should be in a place, as a
> community (never as developers or purely one group), to ignore such
> objections and make forward progress in spite of them. We don't make
> good engineering decisions by "bundling" unrelated features together to
> enable political football

Re: [bitcoin-dev] OP_DIFFICULTY to enable difficulty hedges (bets) without an oracle and 3rd party.

[Jorge Timón via bitcoin-dev]

The complains I could imagine about this, (apart from being a very
specific use case) are the same complains I heard about op_expiry.
Namely, that in a reorg, the same tx, having been valid in a given
block could potentially become invalid in some other block mining it.
I guess in this case the situation is less likely in this case than
with op_expiry, but it is still possible.
Another complain I could imagine is this kind of forces the
implementation to break some existing encapsulations, but I guess
those are just implementation details not that relevant here.
I personally don't have strong feelings towards this proposal one way
or the other, I'm just imagining what other people may complain about.

On Thu, May 23, 2019 at 8:33 PM Tamas Blummer via bitcoin-dev
 wrote:
>
> Difficulty change has profound impact on miner’s production thereby introduce 
> the biggest risk while considering an investment.
> Commodity markets offer futures and options to hedge risks on traditional 
> trading venues. Some might soon list difficulty futures.
>
> I think we could do much better than them natively within Bitcoin.
>
> A better solution could be a transaction that uses nLocktime denominated in 
> block height, such that it is valid after the difficulty adjusted block in 
> the future.
> A new OP_DIFFICULTY opcode would put onto stack the value of difficulty for 
> the block the transaction is included into.
> The output script may then decide comparing that value with a strike which 
> key can spend it.
> The input of the transaction would be a multi-sig escrow of those who entered 
> the bet.
> The winner would broadcast.
>
> Once signed by both the transaction would not carry any counterparty risk and 
> would not need an oracle to settle according to the bet.
>
> I plan to draft a BIP for this as I think this opcode would serve significant 
> economic interest of Bitcoin economy, and is compatible with Bitcoin’s aim 
> not to introduce 3rd party to do so.
>
> Do you see a fault in this proposal or want to contribute?
>
> Tamas Blummer
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core 0.17.0 released

[Jorge Timón via bitcoin-dev]

It seems we forgot
https://github.com/bitcoin/bitcoin/issues/12391#issuecomment-413653714
since getblockstats is only mentioned in the commits.

On Wed, Oct 3, 2018 at 12:32 PM Wladimir J. van der Laan via
bitcoin-dev  wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Bitcoin Core version 0.17.0 is now available from:
>
>   
>
> or through BitTorrent:
>
>   
> magnet:?xt=urn:btih:1c72f17bc1667a2ce81860b75135e491f6637d05&dn=bitcoin-core-0.17.0&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969&tr=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969&tr=udp%3A%2F%2Fzer0day.ch%3A1337&tr=udp%3A%2F%2Fexplodie.org%3A6969
>
> This is a new major version release, including new features, various bugfixes
> and performance improvements, as well as updated translations.
>
> Please report bugs using the issue tracker at GitHub:
>
>   
>
> To receive security and update notifications, please subscribe to:
>
>   
>
> How to Upgrade
> ==
>
> If you are running an older version, shut it down. Wait until it has 
> completely
> shut down (which might take a few minutes for older versions), then run the
> installer (on Windows) or just copy over `/Applications/Bitcoin-Qt` (on Mac)
> or `bitcoind`/`bitcoin-qt` (on Linux).
>
> If your node has a txindex, the txindex db will be migrated the first time 
> you run 0.17.0 or newer, which may take up to a few hours. Your node will not 
> be functional until this migration completes.
>
> The first time you run version 0.15.0 or newer, your chainstate database will 
> be converted to a
> new format, which will take anywhere from a few minutes to half an hour,
> depending on the speed of your machine.
>
> Note that the block database format also changed in version 0.8.0 and there 
> is no
> automatic upgrade code from before version 0.8 to version 0.15.0. Upgrading
> directly from 0.7.x and earlier without redownloading the blockchain is not 
> supported.
> However, as usual, old wallet versions are still supported.
>
> Downgrading warning
> - ---
>
> The chainstate database for this release is not compatible with previous
> releases, so if you run 0.15 and then decide to switch back to any
> older version, you will need to run the old release with the 
> `-reindex-chainstate`
> option to rebuild the chainstate data structures in the old format.
>
> If your node has pruning enabled, this will entail re-downloading and
> processing the entire blockchain.
>
> Compatibility
> ==
>
> Bitcoin Core is extensively tested on multiple operating systems using
> the Linux kernel, macOS 10.10+, and Windows 7 and newer (Windows XP is not 
> supported).
>
> Bitcoin Core should also work on most other Unix-like systems but is not
> frequently tested on them.
>
> - From 0.17.0 onwards macOS <10.10 is no longer supported. 0.17.0 is built 
> using Qt 5.9.x, which doesn't
> support versions of macOS older than 10.10.
>
> Known issues
> 
>
> - - Upgrading from 0.13.0 or older currently results in memory blow-up during 
> the roll-back of blocks to the SegWit activation point. In these cases, a 
> full `-reindex` is necessary.
>
> - - The GUI suffers from visual glitches in the new MacOS dark mode. This has 
> to do with our Qt theme handling and is not a new problem in 0.17.0, but is 
> expected to be resolved in 0.17.1.
>
> Notable changes
> ===
>
> Changed configuration options
> - -
>
> - - `-includeconf=` can be used to include additional configuration 
> files.
>   Only works inside the `bitcoin.conf` file, not inside included files or from
>   command-line. Multiple files may be included. Can be disabled from command-
>   line via `-noincludeconf`. Note that multi-argument commands like
>   `-includeconf` will override preceding `-noincludeconf`, i.e.
>   ```
>   noincludeconf=1
>   includeconf=relative.conf
>   ```
>
>   as bitcoin.conf will still include `relative.conf`.
>
> GUI changes
> - ---
>
> - - Block storage can be limited under Preferences, in the Main tab. Undoing 
> this setting requires downloading the full blockchain again. This mode is 
> incompatible with -txindex and -rescan.
>
> External wallet files
> - -
>
> The `-wallet=` option now accepts full paths instead of requiring 
> wallets
> to be located in the -walletdir directory.
>
> Newly created wallet format
> - ---
>
> If `-wallet=` is specified with a path that does not exist, it will now
> create a wallet directory at the specified location (containing a wallet.dat
> data file, a db.log file, and database/log.?? files) instead of just
> creating a data file at the path and storing log files in the parent
> directory. This should make ba

Re: [bitcoin-dev] Getting around to fixing the timewarp attack.

[Jorge Timón via bitcoin-dev]

I only knew about ArtForz's fix, which isn't backwards compatible.

https://github.com/bitcoin/bitcoin/compare/0.11...jtimon:hardfork-timewarp-0.11
https://github.com/bitcoin/bips/blob/master/bip-0099.mediawiki#code


On Mon, Aug 20, 2018 at 10:14 PM, Gregory Maxwell via bitcoin-dev
 wrote:
> Since 2012 (IIRC) we've known that Bitcoin's non-overlapping
> difficulty calculation was vulnerable to gaming with inaccurate
> timestamps to massively increase the rate of block production beyond
> the system's intentional design. It can be fixed with a soft-fork that
> further constraints block timestamps, and a couple of proposals have
> been floated along these lines.
>
> I put a demonstration of timewarp early in the testnet3 chain to also
> let people test mitigations against that.  It pegs the difficulty way
> down and then churned out blocks at the maximum rate that the median
> time protocol rule allows.
>
> I, and I assume others, haven't put a big priority into fixing this
> vulnerability because it requires a majority hashrate and could easily
> be blocked if someone started using it.
>
> But there haven't been too many other network consensus rules going on
> right now, and I believe at least several of the proposals suggested
> are fully compatible with existing behaviour and only trigger in the
> presence of exceptional circumstances-- e.g. a timewarp attack.  So
> the risk of deploying these mitigations would be minimal.
>
> Before I dust off my old fix and perhaps prematurely cause fixation on
> a particular approach, I thought it would be useful to ask the list if
> anyone else was aware of a favourite backwards compatible timewarp fix
> proposal they wanted to point out.
>
> Cheers.
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Claiming an OP_RETURN Prefix

[Jorge Timón via bitcoin-dev]

op_return outputs can be pruned because they are not spendable.
putting a hash on in the witness script data won't make things better
(it would actually make them worse) and it definitely doesn't help
"block size bloat".
I think I'm missing some context, but if you're using op_return purely
for timestamping I would recommend using pay 2 contract  instead.

On Tue, Aug 14, 2018 at 8:34 PM, Christopher Allen via bitcoin-dev
 wrote:
> On August 5, 2018 9:11:26 PM UTC, Lautaro Dragan via bitcoin-dev
>  wrote:
>>Should we actually be using the BIP process to claim a prefix?
>
> I recommend against using an op_return prefix, as they allow for transaction
> censorship.
>
> In fact, in our case, where we use an IPFS hash in an op_return, we remove
> the IPFS multihash prefix information to post a “bare” SHA256 hash to look
> like many other hashes being posted in op_returns, to minimize any ability
> for a miner to identify our transaction. The more projects that do this the
> better — a form of herd immunity.
>
> Longer term I’m looking for more responsible ways to publish this hash, for
> instance have the hash be in the witness script data, so that it can be
> easily purged from nodes that do not wish to preserve it and prevent block
> size bloat. However, to do so everyone has to do it the same way, ideally
> have it look like any other transaction. I’ve not quite seen a solid
> proposal for best practices here.
>
> — Christopher Allen
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Making OP_TRUE standard?

[Jorge Timón via bitcoin-dev]

But in prnciple I don't oppose to making it stardard, just want to
understand what's the point.

On Thu, 10 May 2018, 02:16 Jorge Timón,  wrote:

> I fail to see what's the practical difference between sending to op_true
> and giving the coins are fees directly. Perhaps it is ao obvious to you
> that you forget to mention it?
> If you did I honestlt missed it.
>
> On Wed, 9 May 2018, 01:58 Rusty Russell via bitcoin-dev, <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Hi all,
>>
>> The largest problem we are having today with the lightning
>> protocol is trying to predict future fees.  Eltoo solves this elegantly,
>> but meanwhile we would like to include a 546 satoshi OP_TRUE output in
>> commitment transactions so that we use minimal fees and then use CPFP
>> (which can't be done at the moment due to CSV delays on outputs).
>>
>> Unfortunately, we'd have to P2SH it at the moment as a raw 'OP_TRUE' is
>> non-standard.  Are there any reasons not to suggest such a policy
>> change?
>>
>> Thanks!
>> Rusty.
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Making OP_TRUE standard?

[Jorge Timón via bitcoin-dev]

I fail to see what's the practical difference between sending to op_true
and giving the coins are fees directly. Perhaps it is ao obvious to you
that you forget to mention it?
If you did I honestlt missed it.

On Wed, 9 May 2018, 01:58 Rusty Russell via bitcoin-dev, <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi all,
>
> The largest problem we are having today with the lightning
> protocol is trying to predict future fees.  Eltoo solves this elegantly,
> but meanwhile we would like to include a 546 satoshi OP_TRUE output in
> commitment transactions so that we use minimal fees and then use CPFP
> (which can't be done at the moment due to CSV delays on outputs).
>
> Unfortunately, we'd have to P2SH it at the moment as a raw 'OP_TRUE' is
> non-standard.  Are there any reasons not to suggest such a policy
> change?
>
> Thanks!
> Rusty.
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Soft Fork Activation & Enforcement w/o Signaling?

[Jorge Timón via bitcoin-dev]

Yes, in fact, you don't need to lose those bits like bitcoin by
imposing that the version is greater than that. But I guess just doing
the same is simpler.

On Thu, Mar 29, 2018 at 7:14 AM, Samad Sajanlal
 wrote:
> Excellent - Thanks for your response Jorge. This helps us plan out the
> future upgrades properly.
> Since I see 0.15 and 0.16 use block versions as 0x2000, whereas the
> current deployed codebase (based on bitcoin 0.9.4) makes versions 0x0002
> (as seen by a 0.15 client), it appears safe to activate soft forks which
> require a minimum of version 3 and 4 blocks (0x0003 and 0x0004,
> respectively). Would you agree?
>
> On Wed, Mar 28, 2018 at 7:55 AM, Jorge Timón  wrote:
>>
>> Yes, you can activate softforks at a given height.
>> I don't see any reason why you couldn't rebase to 0.16 directly.
>> The block version bumping was a mistake in bip34, you don't really
>> need to bump the version number. In any case, I would recommend
>> reading bip34 and what it activates in the code. IIRC the last thing
>> was bip65.
>>
>> On Wed, Mar 21, 2018 at 11:04 PM, Samad Sajanlal via bitcoin-dev
>>  wrote:
>> > Is it possible to activate soft forks such as BIP65 and BIP66 without
>> > prior
>> > signaling from miners? I noticed in chainparams.cpp that there are block
>> > heights where the enforcement begins.
>> >
>> > I understand this is already active on bitcoin. I'm working on a project
>> > that is a clone of a clone of bitcoin, and we currently do not have
>> > BIP65 or
>> > BIP66 enforced - no signaling of these soft forks either (most of the
>> > network is on a source code fork of bitcoin 0.9). This project does not
>> > and
>> > never intends to attempt to replace bitcoin - we know that without
>> > bitcoin
>> > our project could never exist, so we owe a great deal of gratitude to
>> > the
>> > bitcoin developers.
>> >
>> > If the entire network upgrades to the correct version of the software
>> > (based
>> > on bitcoin 0.15), which includes the block height that has enforcement,
>> > can
>> > we simply skip over the signaling and go straight into
>> > activation/enforcement?
>> >
>> > At this time we are lucky that our network is very small, so it is
>> > reasonable to assume that the whole network will upgrade their clients
>> > within a short window (~2 weeks). We would schedule the activation ~2
>> > months
>> > out from when the client is released, just to ensure everyone has time
>> > to
>> > upgrade.
>> >
>> > We have been stuck on the 0.9 code branch and my goal is to bring it up
>> > to
>> > 0.15 at least, so that we can implement Segwit and other key features
>> > that
>> > bitcoin has introduced. The 0.15 client currently works with regards to
>> > sending and receiving transactions but the soft forks are not active. I
>> > understand that activating them will segregate the 0.15 clients onto
>> > their
>> > own fork, which is why I'd like to understand the repercussions of doing
>> > it
>> > without any signaling beforehand. I also would prefer not to have to
>> > make
>> > intermediate releases such as 0.10, 0.11.. etc to get the soft forks
>> > activated.
>> >
>> > Another related question - does the block version get bumped up
>> > automatically at the time that a soft fork activates, or is there
>> > additional
>> > stuff that I need to do within the code to ensure it bumps up at the
>> > same
>> > time? From what I saw in the code it appears that it will bump up
>> > automatically, but I would like some confirmation on that.
>> >
>> > Regards,
>> > Samad
>> >
>> >
>> >
>> > ___
>> > bitcoin-dev mailing list
>> > bitcoin-dev@lists.linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Soft Fork Activation & Enforcement w/o Signaling?

[Jorge Timón via bitcoin-dev]

Yes, you can activate softforks at a given height.
I don't see any reason why you couldn't rebase to 0.16 directly.
The block version bumping was a mistake in bip34, you don't really
need to bump the version number. In any case, I would recommend
reading bip34 and what it activates in the code. IIRC the last thing
was bip65.

On Wed, Mar 21, 2018 at 11:04 PM, Samad Sajanlal via bitcoin-dev
 wrote:
> Is it possible to activate soft forks such as BIP65 and BIP66 without prior
> signaling from miners? I noticed in chainparams.cpp that there are block
> heights where the enforcement begins.
>
> I understand this is already active on bitcoin. I'm working on a project
> that is a clone of a clone of bitcoin, and we currently do not have BIP65 or
> BIP66 enforced - no signaling of these soft forks either (most of the
> network is on a source code fork of bitcoin 0.9). This project does not and
> never intends to attempt to replace bitcoin - we know that without bitcoin
> our project could never exist, so we owe a great deal of gratitude to the
> bitcoin developers.
>
> If the entire network upgrades to the correct version of the software (based
> on bitcoin 0.15), which includes the block height that has enforcement, can
> we simply skip over the signaling and go straight into
> activation/enforcement?
>
> At this time we are lucky that our network is very small, so it is
> reasonable to assume that the whole network will upgrade their clients
> within a short window (~2 weeks). We would schedule the activation ~2 months
> out from when the client is released, just to ensure everyone has time to
> upgrade.
>
> We have been stuck on the 0.9 code branch and my goal is to bring it up to
> 0.15 at least, so that we can implement Segwit and other key features that
> bitcoin has introduced. The 0.15 client currently works with regards to
> sending and receiving transactions but the soft forks are not active. I
> understand that activating them will segregate the 0.15 clients onto their
> own fork, which is why I'd like to understand the repercussions of doing it
> without any signaling beforehand. I also would prefer not to have to make
> intermediate releases such as 0.10, 0.11.. etc to get the soft forks
> activated.
>
> Another related question - does the block version get bumped up
> automatically at the time that a soft fork activates, or is there additional
> stuff that I need to do within the code to ensure it bumps up at the same
> time? From what I saw in the code it appears that it will bump up
> automatically, but I would like some confirmation on that.
>
> Regards,
> Samad
>
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Rebatable fees & incentive-safe fee markets

[Jorge Timón via bitcoin-dev]

Gmaxwell I think what's new is that in this case, with a single tx you
would take out all txs with fee below 1 btc. With current rules, you would
only remove enoguh txs for that one to fit, not empty the whole block and
mine only a block with that single tx.

On 30 Sep 2017 5:53 am, "Jorge Timón"  wrote:

> I really don't see how this "outlier behaviour" can be prevented. I think
> it would be the norm even with your proposed "fix". Perhaps I'm missing
> something too.
>
> On 29 Sep 2017 5:24 pm, "Mark Friedenbach via bitcoin-dev" <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> This is correct. Under assumptions of a continuous mempool model however
>> this should be considered the outlier behavior, other than a little bit of
>> empty space at the end, now and then. A maximum fee rate calculated as a
>> filter over past block rates could constrain this outlier behavior from
>> ever happening too.
>>
>> > On Sep 29, 2017, at 3:43 AM, Daniele Pinna 
>> wrote:
>> >
>> > Maybe I'm getting this wrong but wouldn't this scheme imply that a
>> miner is incentivized to limit the amount of transactions in a block to
>> capture the maximum fee of the ones included?
>> >
>> > As an example, mined blocks currently carry ~0.8 btc in fees right now.
>> If I were to submit a transaction paying 1 btc in maximal money fees, then
>> the miner would be incentivized to include my transaction alone to avoid
>> that lower fee paying transactions reduce the amount of fees he can earn
>> from my transaction alone. This would mean that I could literally clog the
>> network by paying 1btc every ten minutes.
>> >
>> > Am I missing something?
>> >
>> > Daniele
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Rebatable fees & incentive-safe fee markets

[Jorge Timón via bitcoin-dev]

I really don't see how this "outlier behaviour" can be prevented. I think
it would be the norm even with your proposed "fix". Perhaps I'm missing
something too.

On 29 Sep 2017 5:24 pm, "Mark Friedenbach via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> This is correct. Under assumptions of a continuous mempool model however
> this should be considered the outlier behavior, other than a little bit of
> empty space at the end, now and then. A maximum fee rate calculated as a
> filter over past block rates could constrain this outlier behavior from
> ever happening too.
>
> > On Sep 29, 2017, at 3:43 AM, Daniele Pinna 
> wrote:
> >
> > Maybe I'm getting this wrong but wouldn't this scheme imply that a miner
> is incentivized to limit the amount of transactions in a block to capture
> the maximum fee of the ones included?
> >
> > As an example, mined blocks currently carry ~0.8 btc in fees right now.
> If I were to submit a transaction paying 1 btc in maximal money fees, then
> the miner would be incentivized to include my transaction alone to avoid
> that lower fee paying transactions reduce the amount of fees he can earn
> from my transaction alone. This would mean that I could literally clog the
> network by paying 1btc every ten minutes.
> >
> > Am I missing something?
> >
> > Daniele
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] SF proposal: prohibit unspendable outputs with amount=0

[Jorge Timón via bitcoin-dev]

Tier Nolan, right, a new tx version would be required.

I have to look deeper into the CT as sf proposal.

What futures upgrades could this conflict with it's precisely the
question here. So that vague statement without providing any example
it's not very valuable.

Although TXO commitments are interesting, I don't think they make UTXO
growth a "non-issue" and I also don't think they justify not doing
this.

Yeah, the costs for spammers are very small and doesn't really improve
things all that much, as acknowledged in the initial post.



On Thu, Sep 7, 2017 at 8:00 PM, Peter Todd  wrote:
> On Tue, Sep 05, 2017 at 11:51:45PM +0200, Jorge Timón via bitcoin-dev wrote:
>> This is not a priority, not very important either.
>> Right now it is possible to create 0-value outputs that are spendable
>> and thus stay in the utxo (potentially forever). Requiring at least 1
>> satoshi per output doesn't really do much against a spam attack to the
>> utxo, but I think it would be slightly better than the current
>> situation.
>
> Given that this has a very minimal cost for spammers - just a single satoshi -
> I don't think this is worth the risk of making future upgrades more complex as
> other posters have brought up.
>
> Secondly, I think we have good reason to think that things like my own TXO
> commitments and Bram's related work will make UTXO growth a non-issue in the
> future.
>
> So, I'd NACK such a proposal myself.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] SF proposal: prohibit unspendable outputs with amount=0

[Jorge Timón via bitcoin-dev]

This is not a priority, not very important either.
Right now it is possible to create 0-value outputs that are spendable
and thus stay in the utxo (potentially forever). Requiring at least 1
satoshi per output doesn't really do much against a spam attack to the
utxo, but I think it would be slightly better than the current
situation.

Is there any reason or use case to keep allowing spendable outputs
with null amounts in them?

If not, I'm happy to create a BIP with its code, this should be simple.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Solving the Scalability Problem Part II - Adam Shem-Tov

[Jorge Timón via bitcoin-dev]

Regarding storage space, have you heard about pruning? Probably you should.

On 27 Aug 2017 12:27 am, "Adam Tamir Shem-Tov via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Thank You Christian for your response.
>
> https://bitcointalk.org/index.php?topic=473.0 :  I dont see the relevance.
> https://bitcointalk.org/index.php?topic=52859.0 : This idea does not seem
> to talking about trimming the full node. Trimming the full node is the key,
> the full node is what keeps us secure from hackers. If it can be trimmed
> without losing security, that would be good, that is what I am proposing.
> https://bitcointalk.org/index.php?topic=12376.0 : Same answer as 505.0.
> https://bitcointalk.org/index.php?topic=74559.15 : I think his proposal
> is similar to mine, unfortunately for us his predictions were way off. He
> was trying to fix this problem while believing that in the year 2020 the
> blockchain would be 4GB!!! It is not his fault, his prediction was in 2011.
> But you can see, by his prediction, which was rational at the time, was way
> off. And it stresses my point, we need to fix this now. Too bad, no one
> took him seriously back then, when the block chain i was 1GB.
> *https://bitcointalk.org/index.php?topic=56226.0
> *: Another guy with a
> valid point, who was first acknowledged and then apparently ignored.
> .
> To summarize, this problem was brought up about 6 years ago, when the
> blockchain was 1GB in size, Now it is about 140GB in size. I think it is
> about time we stop ignoring this problem, and realize something needs to
> change, or else the only full-nodes you will have will be with private
> multi-million dollar companies, because no private citizen will have the
> storage space to keep it. That would make bitcoin the worst decentralized
> or uncentralized system in history.
>
>
> On 27 August 2017 at 00:42, Christian Riley  wrote:
>
>> There have been a number of similar (identical?) proposals over the
>> years, some were discussed in these threads:
>> https://bitcointalk.org/index.php?topic=56226.0
>> https://bitcointalk.org/index.php?topic=505.0
>> https://bitcointalk.org/index.php?topic=473.0
>> https://bitcointalk.org/index.php?topic=52859.0
>> https://bitcointalk.org/index.php?topic=12376.0
>> https://bitcointalk.org/index.php?topic=74559.15
>>
>>
>> On Aug 26, 2017, at 5:01 PM, Adam Tamir Shem-Tov via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> Solving the Scalability Problem Part II
>> 
>> 
>> In the previous post I showed a way to minimize the blocks on the block
>> chain, to lower the amount of space it takes on the hard drive, without
>> losing any relevant information.
>> I added a note, saying that the transaction chain needs to be rewritten,
>> but I did not give much detail to it.
>> Here is how that would work:
>> The Genesis Account:
>> -
>> The problem with changing the transaction and block chain, is that it
>> cannot be done without knowing the private key of the sender of the of the
>> funds for each account. There is however a way to circumvent that problem.
>> That is to create a special account called the “Genesis Account”, this
>> account’s Private Key and Public Key will be available to everyone.
>> But this account will not be able to send or receive any funds in a
>> normal block, it will be blocked--blacklisted. So no one can intentionally
>> use it. The only time this account will be used is in the pruning block,
>> a.k.a Exodus Block.
>> When creating the new pruned block chain and transaction chain, all the
>> funds that are now in accounts must be legitimate, and it would be
>> difficult to legitimize them unless they were sent from a legitimate
>> account, with a public key, and a private key which can be verified. That
>> is where the Genesis account comes in. All funds in the Exodus Block will
>> show as though they originated and were sent from the Genesis Account using
>> its privatekey to generate each transaction.
>> The funds which are sent, must match exactly the funds existing in the
>> most updated ledger in block 1000 (the last block as stated in my previous
>> post).
>> In this way the Exodus Block can be verified, and the Genesis Account
>> cannot give free money to anyway, because if someone tried to, it would
>> fail verification.
>>
>> 
>> Now the next problem is that the number of Bitcoins keeps expanding and
>> so the funds in the Genesis Account need to expand as well. That can be
>> done by showing as though this account is the account which is mining the
>> coins, and it will be the only account in the Exodus Block which “mines”
>> the coins, and receives the mining bonus. In the Exodus Block all coins
>> mined by the real miners will show as though they were mined by Genesis and
>> sent to the miners through a regular transaction.
>>
>> 

Re: [bitcoin-dev] A Segwit2x BIP

[Jorge Timón via bitcoin-dev]

On 12 Jul 2017 2:31 pm, "Tom Zander via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

On Monday, 10 July 2017 20:38:08 CEST Jorge Timón via bitcoin-dev wrote:
> I think anything less than 1 year after release of tested code by some
> implementation would be irresponsible for any hardfork, even a very
> simple one.

Good news!

Code to support 2x (the hard fork part of the proposal) has been out and
tested for much longer than that.


Not true. It's different code on top of segwit. The first attempt in btc1
(very recent) didn't even increased the size (because it changed the
meaningless "base size" without touching the weight limit. As for the
current code, I don't think it has been properly tested today, let alone
"for mucj longer than 1 year.
Anyway, I said, one year from tested release. Segwitx2 hasn't been
released, has it? If so, too late to discuss a bip imo, the bip may end up
being different from what has been released due to feedback (unless it is
ignored again, of course).


--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] A Segwit2x BIP

[Jorge Timón via bitcoin-dev]

On Mon, Jul 10, 2017 at 1:50 PM, Sergio Demian Lerner via bitcoin-dev
 wrote:
> Regarding the timeline, its certainly rather short, but also is the UASF BIP
> 148 ultimatum.

This is correct. If you are trying to imply that makes the short
timeline here right, you are falling for a "tu quoque" fallacy.

> More than 80% of the miners and many users are willing to go in the Segwit2x
> direction.

There's no logical reason I can think of (and I've heard many attempts
at explaining it) for miners to consider segwit bad for Bitcoin but
segwitx2 harmless. But I don't see 80% hashrate support for bip141, so
your claim doesn't seem accurate for the segwit part, let alone the
more controversial hardfork part.

I read some people controlling mining pools that control 80% of the
hashrate signed a paper saying they would "support segwit
immediately". Either what I read wasn't true, or the signed paper is
just a proof of the signing pool operators word being something we
cannot trust.

So where does this 80% figure come from? How can we trust the source?

> I want a Bitcoin united. But maybe a split of Bitcoin, each side with its
> own vision, is not so bad.

It would be unfortunate to split the network into 2 coins only because
of lack of patience for deploying non-urgent consensus changes like a
size increase or disagreements about the right time schedule.
I think anything less than 1 year after release of tested code by some
implementation would be irresponsible for any hardfork, even a very
simple one.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Height based vs block time based thresholds

[Jorge Timón via bitcoin-dev]

What if you want height based but lockinontimeout = false ?

On 7 Jul 2017 8:09 am, "shaolinfry via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I have written a height based reference implementation as well as updated
> the BIP text in the following proposals
>
> "lockinontimeout" was just an implementation detail to allow BIP8 the BIP9
> implementation code. With the change to height based, we can dispense with
> it entirely.
>
> So the two changes BIP8 brings is BIP9 modified to use height not time,
> and remove the veto failed state.
>
> Code: https://github.com/bitcoin/bitcoin/compare/master...shaolinfry:bip8-
> height
> BIP: https://github.com/bitcoin/bips/compare/master...
> shaolinfry:bip8-height
>
>
>  Original Message 
> Subject: [bitcoin-dev] Height based vs block time based thresholds
>
> Some people have criticized BIP9's blocktime based thresholds arguing they
> are confusing (the first retarget after threshold). It is also vulnerable
> to miners fiddling with timestamps in a way that could prevent or delay
> activation - for example by only advancing the block timestamp by 1 second
> you would never meet the threshold (although this would come a the penalty
> of hiking the difficulty dramatically).
>
> On the other hand, the exact date of a height based thresholds is hard to
> predict a long time in advance due to difficulty fluctuations. However,
> there is certainty at a given block height and it's easy to monitor.
>
> If there is sufficient interest, I would be happy to amend BIP8 to be
> height based. I originally omitted height based thresholds in the interests
> of simplicity of review - but now that the proposal has been widely
> reviewed it would be a trivial amendment.
>
>
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Height based vs block time based thresholds

[Jorge Timón via bitcoin-dev]

I'm all for using height instead of time. That was my preference for
bip9 all along, but my arguments at the time apparently weren't
convincing.

Regarding luke's proposal, the only advantage I see is that it would
allow nodes that don't know a deployment that gets activated to issue
a warning, like bip9 always does when an unknown deployment is locked
in.

But there's a simpler way to do that which doesn't require to add
consensus rules as to what versionbits should be.
I'm honestly not worried about it being "coersive" and I don't think
it's inherently reckless (although used with short deployment times
like bip148 it can be IMO). But it adds more complexity to the
consensus rules, with something that could merely be "warning code".

You can just use a special bit in versionbits for nodes to get the warning.
My proposal doesn't guarantee that the warning will be signaled, for
example, if the miner that mines the block right after lock in doesn't
know about the deployment, he can't possibly know that he was supposed
to signal the warning bit, even if he has the best intentions. Miners
can also intentionally not signal it out of pure malice. But that's no
worse than the current form, when deployments activated by final date
instead of miner signaling never get a warning.

Shaolinfry had more concerns with my proposed modification, but I
think I answered all of them here:

https://github.com/bitcoin/bitcoin/pull/10462#issuecomment-306266218

The implementation of the proposal is there too. I'm happy to reopen
and rebase to simplify (#10464 was merged and there's at least 1
commit to squash).

> It also enables deploying softforks as a MASF, and only upgrading them to UASF
on an as-needed basis.

You can also do

consensus.vDeployments[Consensus::DEPLOYMENT_MASF].bit = 0;
consensus.vDeployments[Consensus::DEPLOYMENT_MASF].nStartHeight = 50;
consensus.vDeployments[Consensus::DEPLOYMENT_MASF].nTimeoutHeight = 51;
consensus.vDeployments[Consensus::DEPLOYMENT_MASF].lockinontimeout = false;

and "if needed", simply add the following at any time (before the new
nStartHeight, obviously):


consensus.vDeployments[Consensus::DEPLOYMENT_UASF].bit = 0;
consensus.vDeployments[Consensus::DEPLOYMENT_UASF].nStartHeight = 51;
consensus.vDeployments[Consensus::DEPLOYMENT_UASF].nTimeoutHeight = 515000;
consensus.vDeployments[Consensus::DEPLOYMENT_UASF].lockinontimeout = true;


On Wed, Jul 5, 2017 at 9:44 PM, Hampus Sjöberg via bitcoin-dev
 wrote:
> From the PR change:
>
>> Miners must continue setting the bit in LOCKED_IN phase so uptake is
>> visible and acknowledged. Blocks without the applicable bit set are invalid
>> during this period
>
> Luke, it seems like the amendments to BIP8 make it drastically different to
> how it first was designed to work.
> It now looks more akin to BIP148, which was AFAICT not how BIP8 was
> originally intended to work.
> Perhaps this should be made into its own BIP instead, or make it so it's
> possible to decide how the LOCKED_IN state should work when designing the
> softfork.
>
> Hampus
>
> 2017-07-05 6:10 GMT+02:00 Luke Dashjr via bitcoin-dev
> :
>>
>> It's not pointless: it's a wake-up call for miners asleep "at the wheel",
>> to
>> ensure they upgrade in time. Not having a mandatory signal turned out to
>> be a
>> serious bug in BIP 9, and one which is fixed in BIP 148 (and remains a
>> problem
>> for BIP 149 as-is). Additionally, it makes the activation decisive and
>> unambiguous: once the lock-in period is complete, there remains no
>> question as
>> to what the correct protocol rules are.
>>
>> It also enables deploying softforks as a MASF, and only upgrading them to
>> UASF
>> on an as-needed basis.
>>
>> Luke
>>
>>
>> On Wednesday 05 July 2017 4:00:38 AM shaolinfry wrote:
>> > Luke,
>> > I previously explored an extra state to require signalling before
>> > activation in an earlier draft of BIP8, but the overall impression I got
>> > was that gratuitous orphaning was undesirable, so I dropped it. I
>> > understand the motivation behind it (to ensure miners are upgraded), but
>> > it's also rather pointless when miners can just fake signal. A properly
>> > constructed soft fork is generally such that miners have to deliberately
>> > do something invalid - they cannot be tricked into it... and miners can
>> > always chose to do something invalid anyway.
>> >
>> > >  Original Message 
>> > > From: l...@dashjr.org
>> > > To: bitcoin-dev@lists.linuxfoundation.org, shaolinfry
>> > >  I"ve already opened a PR almost 2 weeks ago
>> > > to do this and fix the other issues BIP 9 has.
>> > > https://github.com/bitcoin/bips/pull/550
>> > > It just needs your ACK to merge.
>> > >
>> > > On Wednesday 05 July 2017 1:30:26 AM shaolinfry via bitcoin-dev wrote:
>> > >> Some people have criticized BIP9"s blocktime based thresholds arguing
>> > >> they are confusing (the first retarget after threshold). It is also
>> > >> vulnerable to miners fiddling with timestamps in 

Re: [bitcoin-dev] Miners forced to run non-core code in order to get segwit activated

[Jorge Timón via bitcoin-dev]

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@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@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 
> 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  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
>> >  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 <
>> m...@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
>> >>>  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 

Re: [bitcoin-dev] The BIP148 chain split may be inevitable

[Jorge Timón via bitcoin-dev]

oops s/45%/35%/

On Sun, Jun 11, 2017 at 7:11 PM, Jorge Timón  wrote:
> On Sat, Jun 10, 2017 at 8:04 PM, Jacob Eliosoff via bitcoin-dev
>  wrote:
>> Just a quick follow-up on BIP91's prospects of avoiding a BIP148 chain
>> split, because I may have left an overly pessimistic impression -
>>
>> In short: the timing isn't as dire as I suggested, BUT unless concrete
>> progress on a plan starts taking shape, esp miner support, *the split is
>> indeed coming.*
>>
>> THE GOOD NEWS: several refinements have been noted which could get BIP91 (or
>> splitprotection, Segwit2x, etc) deployed faster:
>> - Of course the 80% threshold could just be reduced, eg to splitprotection's
>> 65%
>
> This still doesn't prevent the split if 45% or more of the hashrate
> keeps blocking segwit, so I don't see how this help.
>
>> - BIP91 nodes could start signaling on bit 1 the moment bit 4 reaches
>> lock-in, rather than waiting another period until it  "activates".
>
> Miners could start signaling bit 1 today, before they use bip91 too
> and signal bit 4 in addition.
> But they aren't doing it, it seems they prefer to block segwit. I
> don't see why changing using bit 4 or reducing the threshold would
> change their mind.
>
>> THE BAD NEWS: no one should underestimate the steps that would need to be
>> completed by that deadline:
>> 1. Coordinate on a solution (BIP91, splitprotection, Segwit2x, BIP148
>> itself, ...)
>> 2. Implement and test it
>> 3. Convince >50% of miners to run it [2]
>> 4. Miners upgrade to the new software and begin signaling
>>
>> In particular, #3: afaict a lot of convincing is still needed before miner
>> support for any of these reaches anything like 50%.  (With the exception of
>> Segwit2x, but it has the additional handicap that it probably needs to
>> include deployable hard fork code, obviously ambitious in 1.5 months.)
>>
>
> Or you can replace this whole plan with the step 3, convincing miners
> to stop blocking segwit, upgrade to segwit capable code if they
> haven't already and signal bit 1 to activate it.
> If you don't get that, there's going to be a split. Unless bip148 is
> aborted in favor of bip149, which seems unlikely.
>
> If we had 51%+ of the hashrate currently signaling segwit, I believe
> there would be no problem convincing people to move from bip148 to
> bip91, but we don't have that.
>
> To me the lesson is not rushed deployments but bip8 and never commit
> the mistake of giving miners the ability to block changes again, like
> we did with csv and segwit, but using bip8 instead of bip9 from now
> on.
>
>> [1] See Saicere's comment:
>> https://github.com/btc1/bitcoin/pull/11#discussion_r121086886, and related
>> discussion at
>> https://github.com/btc1/bitcoin/pull/11#issuecomment-307330011.
>>
>> [2] Note that >50% need to run the *solution*, eg BIP91; old BIP141 nodes
>> signaling segwit support do *not* count, since they won't orphan non-bit-1
>> blocks.  The impending split isn't between nodes that support segwit vs
>> don't, but between those that reject non-segwit-supporting blocks vs don't.
>>
>>
>> On Fri, Jun 9, 2017 at 1:23 AM, Jacob Eliosoff 
>> wrote:
>>>
>>> Ah, two corrections:
>>> 1. I meant to include an option c): of course >50% of hashpower running
>>> BIP148 by Aug 1 avoids a split.
>>> 2. More seriously, I misrepresented BIP148's logic: it doesn't require
>>> segwit *activation*, just orphans non-segwit-*signaling* (bit 1) blocks from
>>> Aug 1.
>>>
>>> I believe that means 80% of hashrate would need to be running BIP91
>>> (signaling bit 4) by ~June 30 (so BIP91 locks in ~July 13, activates ~July
>>> 27), not "a few days ago" as I claimed.  So, tight timing, but not
>>> impossible.
>>>
>>> Sorry about the errors.
>>>
>>>
>>> On Fri, Jun 9, 2017 at 12:40 AM, Jacob Eliosoff 
>>> wrote:

 I've been trying to work out the expected interaction between James
 Hilliard's BIP91 [1] (or splitprotection [2], or Segwit2x [3], which both
 use variants of BIP91 activation) and the BIP148 UASF [4].  Some of this is
 subtle so CORRECTIONS WELCOME, but my conclusions are:
 1. It's extremely unlikely BIP91-type logic can activate segwit in time
 to avoid a BIP148 chain split.
 2. So, in practice all we can do is ensure the BIP148 split is as
 painless as possible.

 REASONING:  First, some dates.  BIP148, whose deadline is already
 deployed and thus unlikely to be postponed, starts orphaning non-segwit
 blocks on midnight (GMT) the morning of August 1.  Meanwhile, here are
 Bitcoin's rough expected next four difficulty adjustment dates (they could
 vary by ~1-3 days depending on block times, but it's unlikely to matter
 here):
 1. June 17
 2. June 30
 3. July 13
 4. July 27

 If Segwit activates on adj date #5 or later (August), it will be too late
 to avoid BIP148's split, which will have occurred the moment August began.
 So, working backwards, and assuming we want compatibility with

Re: [bitcoin-dev] The BIP148 chain split may be inevitable

[Jorge Timón via bitcoin-dev]

On Sat, Jun 10, 2017 at 8:04 PM, Jacob Eliosoff via bitcoin-dev
 wrote:
> Just a quick follow-up on BIP91's prospects of avoiding a BIP148 chain
> split, because I may have left an overly pessimistic impression -
>
> In short: the timing isn't as dire as I suggested, BUT unless concrete
> progress on a plan starts taking shape, esp miner support, *the split is
> indeed coming.*
>
> THE GOOD NEWS: several refinements have been noted which could get BIP91 (or
> splitprotection, Segwit2x, etc) deployed faster:
> - Of course the 80% threshold could just be reduced, eg to splitprotection's
> 65%

This still doesn't prevent the split if 45% or more of the hashrate
keeps blocking segwit, so I don't see how this help.

> - BIP91 nodes could start signaling on bit 1 the moment bit 4 reaches
> lock-in, rather than waiting another period until it  "activates".

Miners could start signaling bit 1 today, before they use bip91 too
and signal bit 4 in addition.
But they aren't doing it, it seems they prefer to block segwit. I
don't see why changing using bit 4 or reducing the threshold would
change their mind.

> THE BAD NEWS: no one should underestimate the steps that would need to be
> completed by that deadline:
> 1. Coordinate on a solution (BIP91, splitprotection, Segwit2x, BIP148
> itself, ...)
> 2. Implement and test it
> 3. Convince >50% of miners to run it [2]
> 4. Miners upgrade to the new software and begin signaling
>
> In particular, #3: afaict a lot of convincing is still needed before miner
> support for any of these reaches anything like 50%.  (With the exception of
> Segwit2x, but it has the additional handicap that it probably needs to
> include deployable hard fork code, obviously ambitious in 1.5 months.)
>

Or you can replace this whole plan with the step 3, convincing miners
to stop blocking segwit, upgrade to segwit capable code if they
haven't already and signal bit 1 to activate it.
If you don't get that, there's going to be a split. Unless bip148 is
aborted in favor of bip149, which seems unlikely.

If we had 51%+ of the hashrate currently signaling segwit, I believe
there would be no problem convincing people to move from bip148 to
bip91, but we don't have that.

To me the lesson is not rushed deployments but bip8 and never commit
the mistake of giving miners the ability to block changes again, like
we did with csv and segwit, but using bip8 instead of bip9 from now
on.

> [1] See Saicere's comment:
> https://github.com/btc1/bitcoin/pull/11#discussion_r121086886, and related
> discussion at
> https://github.com/btc1/bitcoin/pull/11#issuecomment-307330011.
>
> [2] Note that >50% need to run the *solution*, eg BIP91; old BIP141 nodes
> signaling segwit support do *not* count, since they won't orphan non-bit-1
> blocks.  The impending split isn't between nodes that support segwit vs
> don't, but between those that reject non-segwit-supporting blocks vs don't.
>
>
> On Fri, Jun 9, 2017 at 1:23 AM, Jacob Eliosoff 
> wrote:
>>
>> Ah, two corrections:
>> 1. I meant to include an option c): of course >50% of hashpower running
>> BIP148 by Aug 1 avoids a split.
>> 2. More seriously, I misrepresented BIP148's logic: it doesn't require
>> segwit *activation*, just orphans non-segwit-*signaling* (bit 1) blocks from
>> Aug 1.
>>
>> I believe that means 80% of hashrate would need to be running BIP91
>> (signaling bit 4) by ~June 30 (so BIP91 locks in ~July 13, activates ~July
>> 27), not "a few days ago" as I claimed.  So, tight timing, but not
>> impossible.
>>
>> Sorry about the errors.
>>
>>
>> On Fri, Jun 9, 2017 at 12:40 AM, Jacob Eliosoff 
>> wrote:
>>>
>>> I've been trying to work out the expected interaction between James
>>> Hilliard's BIP91 [1] (or splitprotection [2], or Segwit2x [3], which both
>>> use variants of BIP91 activation) and the BIP148 UASF [4].  Some of this is
>>> subtle so CORRECTIONS WELCOME, but my conclusions are:
>>> 1. It's extremely unlikely BIP91-type logic can activate segwit in time
>>> to avoid a BIP148 chain split.
>>> 2. So, in practice all we can do is ensure the BIP148 split is as
>>> painless as possible.
>>>
>>> REASONING:  First, some dates.  BIP148, whose deadline is already
>>> deployed and thus unlikely to be postponed, starts orphaning non-segwit
>>> blocks on midnight (GMT) the morning of August 1.  Meanwhile, here are
>>> Bitcoin's rough expected next four difficulty adjustment dates (they could
>>> vary by ~1-3 days depending on block times, but it's unlikely to matter
>>> here):
>>> 1. June 17
>>> 2. June 30
>>> 3. July 13
>>> 4. July 27
>>>
>>> If Segwit activates on adj date #5 or later (August), it will be too late
>>> to avoid BIP148's split, which will have occurred the moment August began.
>>> So, working backwards, and assuming we want compatibility with old BIP141
>>> nodes:
>>>
>>> - Segwit MUST activate by adj #4 (~July 27)
>>> - Therefore segwit MUST be locked in by adj #3 (~July 13: this is
>>> inflexible, since this logic is in already-deployed 

Re: [bitcoin-dev] The BIP148 chain split may be inevitable

[Jorge Timón via bitcoin-dev]

> I believe that means 80% of hashrate would need to be running BIP91 
> (signaling bit 4) by ~June 30 (so BIP91 locks in ~July 13, activates ~July 
> 27), not "a few days ago" as I claimed.  So, tight timing, but not impossible.

This is not needed, if segwit is locked in by aug 1 (with or without
bip91), no split will happen even if segwit is not active yet.
So the hashrate majority could avoid the split that way (or adopting bip148).

But it doesn't seem like they are planning to do this (with or without
bip91), the last thing I've heard, it's they will wait until
"immediately" before they signal sw (but there must be some language
barrier here, perhaps "immediately" and "inmediatamente" are false
friends). The reason why they will wait until "immediately" instead of
just starting to signal sw today, it's still unclear to me.

The other way to prevent the split is if bip148 users abort bip148
deployment, but unfortunately that seems increasingly unlikely.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP149 timeout-- why so far in the future?

[Jorge Timón via bitcoin-dev]

On Sun, Jun 11, 2017 at 3:44 PM, Martijn Meijering via bitcoin-dev
 wrote:
> Jorge Timón wrote:
> Why not just make sure BIP 149 will never activate unless BIP 141 has
> expired unsuccessfully?

Right, that would be part of it, as well as not removing the BIP141
deployment with bip9.
See 
https://github.com/jtimon/bitcoin/commit/62efd741740f5c75c43d78358d6318941e6d3c04

> If BIP 141 should unexpectly activate, then
> BIP 149 nodes would notice and act as pre-SegWit nodes indefinitely,
> but remain in consensus with BIP 141 nodes.
>
> It might be slightly less convenient for BIP 149 users to upgrade
> again, but then at least we could start deploying BIP 149 sooner.

No, if segwit activates pre nov15, bip149 nodse can detect and
interpret that just fine.
The problem if it activates post nov15, then you need a separate
service bit in the p2p network, for pre-BIP149 will think sw hasn't
activated while post-BIP149 would know it has activated.

If you release it only after nov15, you don't need to test
compatibility between the two for neither of this two cases.
Or do you? Actually you only save testing the easier case of pre-nov15
activation.


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

Re: [bitcoin-dev] BIP149 timeout-- why so far in the future?

[Jorge Timón via bitcoin-dev]

The current proposal assumes that bip149 would only be merged and
released after nov15, so there's not time in one day.

My preference would be a bip149 proposal that could be merged and
released now, but some people complain that would require more
testing, because if you deploy bip149 and then sw gets activated pre
nov15, then you want bip149 nodes to use the old service bit for
segwit, not the new one (you would use that one if it activates post
nov15, so that pre-bip149 nodes don't get confused).

I was slowly modifying shaolinfry's code to try to code that, but I'm
currently not working on it because there doesn't seem there's a lot
of interest in releasing bip149 before nov15...

https://github.com/jtimon/bitcoin/commits/b15-shaolinfry-bip149


On Sun, Jun 11, 2017 at 7:48 AM, Ryan Grant via bitcoin-dev
 wrote:
> Is there any reason that BIP149 activation on November 16th would
> cause a problem?
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Hypothetical 2 MB hardfork to follow BIP148

[Jorge Timón via bitcoin-dev]

On Wed, May 31, 2017 at 1:50 AM, James MacWhyte  wrote:
>
>>
>>  The 1MB classic block size prevents quadratic hashing
>> problems from being any worse than they are today.
>>
>
> Add a transaction-size limit of, say, 10kb and the quadratic hashing problem
> is a non-issue. Donezo.

Why is it 
https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L1661
not enough at this point?
Why the need for a transaction size limit?
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Hypothetical 2 MB hardfork to follow BIP148

[Jorge Timón via bitcoin-dev]

My understanding is that you cannot possibly violate the 1 MB block
size rule without also violating the 4 MB weight rule.
Regarding size alone, the only check we care about if we accept segwit is:

https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L2891 [size4]

If that doesn't fail due to excessive non-witness data, then there's no way that

https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L2681 [size1]

would have failed before due to excessive non-witness data.
If I understood it correctly when I was explained, if I remember
correctly, that last check is really just an optimization or a
protection against DoS invalid blocks. If the size without any witness
data is bigger than 1/4 the max_weight, then the max_weight check is
certain to fail as well without having to look at any witness data at
that validation stage (assuming the failure is due to excessive
non-witness data).

I think you are not referring to the 1 mb size limit but to related
one for sigops:

https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L2704
[sigops1]

whose segwit parallel is in:

https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L1661
[sigops4]

I believe the situation is similar in checking before knowing anything
about the witness data just in case that's already too much. In fact,
here is clearer because MAX_BLOCK_SIGOPS_COST is used for both (and
WITNESS_SCALE_FACTOR is used for the optimization case).

So what I would do in a hardfork after segwit activation would be to
simply equal MAX_BLOCK_BASE_SIZE=MAX_BLOCK_WEIGHT/WITNESS_SCALE_FACTOR
for size1, and increase MAX_BLOCK_WEIGHT and MAX_BLOCK_ SIGOPS_COST
proportionally for size4 and sigops4 respectively (well, the sigops
const for sigops1 as well).

If I understood segwit correctly, I believe that even though it is not
activated yet, you could remove both the size1 and sigops1 checks and
your node would still not accept invalid blocks by pre-bip141 rules,
your node would just spend more time on invalid blocks due to
currently excessive size/sigops, because it would only realize at a
later validation stage. Sorry for the redundancy about the validation
stage.

But it is not unlikely that I'm missing something. If I am wrong about
this I am spreading misinformation about segwit in several channels,
so I'm very interested in corrections to my statements in this mail.

On Tue, May 30, 2017 at 11:24 PM, Mark Friedenbach  wrote:
> The 1MB classic block size is not redundant after segwit activation.
> Segwit prevents the quadratic hashing problems, but only for segwit
> outputs. The 1MB classic block size prevents quadratic hashing
> problems from being any worse than they are today.
>
> Mark
>
> On Tue, May 30, 2017 at 6:27 AM, Jorge Timón via bitcoin-dev
>  wrote:
>> Why not simply remove the (redundant after sw activation) 1 mb size
>> limit check and increasing the weight limit without changing the
>> discount or having 2 limits?
>>
>>
>> On Wed, May 24, 2017 at 1:07 AM, Erik Aronesty via bitcoin-dev
>>  wrote:
>>> Personally, I would prefer if a 2MB lock-in that uses BIP103 for the timing.
>>>
>>> I think up to 20% per year can be absorbed by averages in bandwidth/CPU/RAM
>>> growth, of which bandwidth seems the most constraining.
>>>
>>> - Erik
>>>
>>>
>>> On Tue, May 23, 2017 at 4:23 PM, Luke Dashjr via bitcoin-dev
>>>  wrote:
>>>>
>>>> In light of some recent discussions, I wrote up this BIP for a real 2 MB
>>>> block
>>>> size hardfork following Segwit BIP148 activation. This is not part of any
>>>> agreement I am party to, nor anything of that sort. Just something to
>>>> throw
>>>> out there as a possible (and realistic) option.
>>>>
>>>> Note that I cannot recommend this to be adopted, since frankly 1 MB blocks
>>>> really are still too large, and this blunt-style hardfork quite risky even
>>>> with consensus. But if the community wishes to adopt (by unanimous
>>>> consensus)
>>>> a 2 MB block size hardfork, this is probably the best way to do it right
>>>> now.
>>>> The only possible way to improve on this IMO would be to integrate it into
>>>> MMHF/"spoonnet" style hardfork (and/or add other unrelated-to-block-size
>>>> HF
>>>> improvements).
>>>>
>>>> I have left Author blank, as I do not intend to personally champion this.
>>>> Before it may be assigned a BIP number, someone else will need to step up
>>>> to
>>>> take on that role. Motivation and Rationale are blank because I do not
>>>> personally think there is any legitim

Re: [bitcoin-dev] Hypothetical 2 MB hardfork to follow BIP148

[Jorge Timón via bitcoin-dev]

Why not simply remove the (redundant after sw activation) 1 mb size
limit check and increasing the weight limit without changing the
discount or having 2 limits?


On Wed, May 24, 2017 at 1:07 AM, Erik Aronesty via bitcoin-dev
 wrote:
> Personally, I would prefer if a 2MB lock-in that uses BIP103 for the timing.
>
> I think up to 20% per year can be absorbed by averages in bandwidth/CPU/RAM
> growth, of which bandwidth seems the most constraining.
>
> - Erik
>
>
> On Tue, May 23, 2017 at 4:23 PM, Luke Dashjr via bitcoin-dev
>  wrote:
>>
>> In light of some recent discussions, I wrote up this BIP for a real 2 MB
>> block
>> size hardfork following Segwit BIP148 activation. This is not part of any
>> agreement I am party to, nor anything of that sort. Just something to
>> throw
>> out there as a possible (and realistic) option.
>>
>> Note that I cannot recommend this to be adopted, since frankly 1 MB blocks
>> really are still too large, and this blunt-style hardfork quite risky even
>> with consensus. But if the community wishes to adopt (by unanimous
>> consensus)
>> a 2 MB block size hardfork, this is probably the best way to do it right
>> now.
>> The only possible way to improve on this IMO would be to integrate it into
>> MMHF/"spoonnet" style hardfork (and/or add other unrelated-to-block-size
>> HF
>> improvements).
>>
>> I have left Author blank, as I do not intend to personally champion this.
>> Before it may be assigned a BIP number, someone else will need to step up
>> to
>> take on that role. Motivation and Rationale are blank because I do not
>> personally think there is any legitimate rationale for such a hardfork at
>> this
>> time; if someone adopts this BIP, they should complete these sections. (I
>> can
>> push a git branch with the BIP text if someone wants to fork it.)
>>
>> 
>> BIP: ?
>> Layer: Consensus (hard fork)
>> Title: Post-segwit 2 MB block size hardfork
>> Author: FIXME
>> Comments-Summary: No comments yet.
>> Comments-URI: ?
>> Status: Draft
>> Type: Standards Track
>> Created: 2017-05-22
>> License: BSD-2-Clause
>> 
>>
>> ==Abstract==
>>
>> Legacy Bitcoin transactions are given the witness discount, and a block
>> size
>> limit of 2 MB is imposed.
>>
>> ==Copyright==
>>
>> This BIP is licensed under the BSD 2-clause license.
>>
>> ==Specification==
>>
>> Upon activation, a block size limit of 200 bytes is enforced.
>> The block weight limit remains at 400 WU.
>>
>> The calculation of block weight is modified:
>> all witness data, including both scriptSig (used by pre-segwit inputs) and
>> segwit witness data, is measured as 1 weight-unit (WU), while all other
>> data
>> in the block is measured as 4 WU.
>>
>> The witness commitment in the generation transaction is no longer
>> required,
>> and instead the txid merkle root in the block header is replaced with a
>> hash
>> of:
>>
>> 1. The witness reserved value.
>> 2. The witness merkle root hash.
>> 3. The transaction ID merkle root hash.
>>
>> The maximum size of a transaction stripped of witness data is limited to 1
>> MB.
>>
>> ===Deployment===
>>
>> This BIP is deployed by flag day, in the block where the median-past time
>> surpasses 1543503872 (2018 Nov 29 at 15:04:32 UTC).
>>
>> It is assumed that when this flag day has been reached, Segwit has been
>> activated via BIP141 and/or BIP148.
>>
>> ==Motivation==
>>
>> FIXME
>>
>> ==Rationale==
>>
>> FIXME
>>
>> ==Backwards compatibility==
>>
>> This is a hardfork, and as such not backward compatible.
>> It should not be deployed without consent of the entire Bitcoin community.
>> Activation is scheduled for 18 months from the creation date of this BIP,
>> intended to give 6 months to establish consensus, and 12 months for
>> deployment.
>>
>> ==Reference implementation==
>>
>> FIXME
>>
>>
>>
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Suggested changes to bip8

[Jorge Timón via bitcoin-dev]

Hi, I didn't want to comment on
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013643.html
because it seemed to me that thread was more broad.

I like bip8 very much as an extension to bip9, but I think it could be better.
With bip9, a bip9-ready node that sees a softfork activated that he is
not aware of will see a warning. See the implementation:

https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L1832

But with bip8, if a deployment is made at the end of the period
instead of through 95% signaling, nodes that implement bip8 but don't
implement a certain deployment that is activated can't receive such a
warning.

The solution that comes to mind is to reserve one of the nVersion for
the specific purpose of requiring that the bit is active for one block
when a deployment is locked in in this way (or maybe also when it's
activated with miners' signaling too, maybe that can be used to
simplify the way the current warnings are checked).

I expect the code changes to do this to be simple, and I'm happy to
help with it.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] I do not support the BIP 148 UASF

[Jorge Timón via bitcoin-dev]

On Tue, May 23, 2017 at 2:55 PM, Luke Dashjr via bitcoin-dev
 wrote:
> On Tuesday 23 May 2017 6:30:01 AM Karl Johan Alm via bitcoin-dev wrote:
>> Essentially, if we make a potentially very harmful option easy to
>> enable for users, we are putting them at risk, so yes, this is about
>> protecting users of the base Bitcoin Core implementation.
>
> In this case, NOT enforcing BIP148 puts users at more risk. Since devs are
> divided in opinion, we should at the very least have an option to let users
> decide one way or the other.

Well, it's putting users at more risk only if for those users who
actively decided to put themselves at risk.
I also feel bip148 is rushed and that makes it more risky. I don't
want to reiterate points other have made but I don't fully agree with
all of them.
I prefer the way it is over the way it was (just activating at a given
date without forcing mining signaling), but I still think it's rushed
and unnecessarily risky (unless activating segwit was urgent, which I
think it's not, no matter how much I want it to become active as soon
as possible).
On the other hand, I support uasf and bip8 to replace bip9 for future
deployments, since bip9 made assumptions that weren't correct (like
assuming miners would always signal changes that don't harm any user
and are good for some of them).
Perhaps bip149 can be modified to activate earlier if the current
proposal is perceived as unnecessarily cautious.

Luke, I've seen you say in other forums that "bip148 is less risky
than bip149", but I think that's clearly false.

As a reminder, one of my complains about bip109 was precisely that it
was also rushed in how fast it could activate.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Some real-world results about the current Segwit Discount

[Jorge Timón via bitcoin-dev]

If there's a better factor than 0.25 I would change it now before deploying
segwit instead of leaving it to be changed later with a hf.

On 9 May 2017 10:59 pm, "Sergio Demian Lerner via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I agree with you Matt.
> I'm artificially limiting myself to changing the parameters of Segwit as
> it is..
>
> This is motivated by the idea that a consensual HF in the current state
> would have greater chance of acceptance if it changes the minimum number of
> lines of code.
>
>
>
> On Tue, May 9, 2017 at 5:13 PM, Gregory Maxwell  wrote:
>
>> On Tue, May 9, 2017 at 7:42 PM, Matt Corallo 
>> wrote:
>> > at beast.
>>
>> Rawr.
>>
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] A Small Modification to Segwit

[Jorge Timón via bitcoin-dev]

On Tue, Apr 11, 2017 at 4:40 PM, Jimmy Song via bitcoin-dev
 wrote:
> I've changed the proposal so only 8 bits are given to grinding so something
> like 20 bits are available for signaling.
>
> I have to say I'm at a loss here as to what's next? Should I make a new BIP
> or try to convince the authors of BIP141 to modify their BIP? Could someone
> inform me on the next part of the process?

See bip2, specifically
https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki#bip-workflow

"Following a discussion, the proposal should be submitted to the BIPs
git repository as a pull request. This draft must be written in BIP
style as described below, and named with an alias such as
"bip-johndoe-infinitebitcoins" until the editor has assigned it a BIP
number (authors MUST NOT self-assign BIP numbers)."

But I think it's kind of late to modify bip141, given that there's
code out there with the current specification.
I guess you can propose extensions or alternatives to replace it. I'm
really not sure what's the next step, but I don't think you have
provided enough motivation as to why we would want to maintain
asicboost. You said it makes the network more secure, but that's not
the case, as explained, not even if all honest miners use it.

> On Tue, Apr 11, 2017 at 8:25 AM, Sancho Panza via bitcoin-dev
>  wrote:
>>
>> Tom Zander wrote:
>>
>> > The version field is still needed to actually allow future block version
>> > upgrades. We would cut off our road forward if that were to be blocked.
>>
>> I tend to agree, if all 32 bits were given up to grinding.
>>
>> But it's worth pointing out that BIP9 is purely informational, and the top
>> 3 bits are still reserved for other purposes. One of them could perhaps be
>> used to signal for an extended version field somewhere else, leaving the
>> bottom 29 as entropy?
>>
>> Not a direction I prefer, but just a technical possibility perhaps.
>>
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] A Small Modification to Segwit

[Jorge Timón via bitcoin-dev]

The discussion is going offtopic. Can we please take vague discussions
about changing pow, so called "asic resistance", the environment etc
to bitcoin-disscuss or some other forum?
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] A Small Modification to Segwit

[Jorge Timón via bitcoin-dev]

On 9 Apr 2017 4:01 pm, "Jimmy Song"  wrote:

Jorge,

Why won't the attacker use asicboost too? (Please don't say because of
> patents)
>
>
We're assuming the ASIC optimization in my example is incompatible with
ASICBoost. But if the new optimization were compatible with ASICBoost,
you're right, the network would be in an equivalent situation whether
ASICBoost was banned or not.


Only if all honest miners use asicboost, otherwise the situation for an
attack is not equivalent but worse with asicboost.

I want to point out again that overt ASICBoost can be used on the network
today. My proposal is to bring ASICBoost usage out into the open vs hiding
it. Banning ASICBoost via protocol changes is another issue completely.


Doesn't greg's proposal of disabling covert asicboost "bring asicboost
usage into the open vs hiding it" too? It also does it without making any
assumptions on whether we want to completely disable it later (I want)
while your proposal assumes we do not.

Jimmy


> On 9 Apr 2017 12:26 am, "Jimmy Song"  wrote:
>
>> Jorge,
>>
>> Suppose someone figures out an ASIC optimization that's completely
>> unrelated that gives X% speed boost over your non-ASICBoosted
>> implementation. If you ban ASICBoost, someone with this optimization can
>> get 51% of the network by adding N machines with their new optimization. If
>> you allow ASICBoost and assuming this gets a 20% speed boost over
>> non-ASICBoosted hardware, someone with this optimization would need 1.2N
>> machines to get 51%. The network in that sense is 20% stronger against this
>> attack in terms of cost.
>>
>> Jimmy
>>
>> On Sat, Apr 8, 2017 at 12:22 PM, Jorge Timón  wrote:
>>
>>> To be more specific, why "being higher will secure the Bitcoin network
>>> better against newer optimizations"?
>>> Or, to be more clear, let's forget about future "optimizations", let's
>>> just think of an attacker. Does asicboost being used by all miners
>>> make the system more secure against an attacker? No, for the attacker
>>> can use asicboost too.
>>> What about the case when not all the miners are using asicboost? Then
>>> the attacker can actually get an advantage by suing asicboost.
>>>
>>> Sometimes people compare asicboost with the use of asics in general as
>>> both providing more security for the network and users. But I don't
>>> think this is accurate. The existence of sha256d asics makes an attack
>>> with general purpose computing hardware (or even more specialized
>>> architectures like gpgpu) much more expensive and unlikely. As an
>>> alternative the attacker can spend additional resources investing in
>>> asics himself (again, making many attacks more expensive and
>>> unlikely).
>>>
>>> But as far as I know, asicboost can be implemented with software
>>> running on general purpose hardware that integrates with regular
>>> sha256d asics. There is probably an advantage on having the asicboost
>>> implementation "in the same box" as the sha256d, yet again the
>>> attacker can invest in hardware with the competitive advantage from
>>> having asicboost more intergrated with the sha256d asics too.
>>>
>>> To reiterate, whether all miners use asicboost or only a subset of
>>> them, I remain unconvinced that provides any additional security to
>>> the network (to be more precise whether that makes "tx history harder
>>> to rewrite"), even if it results on the hashrate charts looking "more
>>> secure".
>>>
>>>
>>> On Sat, Apr 8, 2017 at 6:27 PM, Jorge Timón  wrote:
>>> >
>>> >
>>> > On 8 Apr 2017 5:06 am, "Jimmy Song via bitcoin-dev"
>>> >  wrote:
>>> >
>>> > Praxeology Guy,
>>> >
>>> >> 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?
>>> >
>>> >
>>> > Certainly, if only one company made use of the extra nonce space, they
>>> would
>>> > have an advantage. But think of it this way, if some newer ASIC
>>> optimization
>>> > comes up, would you rather have a non-ASICBoosted hash rate to defend
>>> with
>>> > or an ASICBoosted hash rate? Certainly, the latter, being higher will
>>> secure
>>> > the Bitcoin network better against newer optimizations.
>>> >
>>> >
>>> > Why?
>>>
>>
>>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] A Small Modification to Segwit

[Jorge Timón via bitcoin-dev]

Why won't the attacker use asicboost too? (Please don't say because of
patents)

On 9 Apr 2017 12:26 am, "Jimmy Song"  wrote:

> Jorge,
>
> Suppose someone figures out an ASIC optimization that's completely
> unrelated that gives X% speed boost over your non-ASICBoosted
> implementation. If you ban ASICBoost, someone with this optimization can
> get 51% of the network by adding N machines with their new optimization. If
> you allow ASICBoost and assuming this gets a 20% speed boost over
> non-ASICBoosted hardware, someone with this optimization would need 1.2N
> machines to get 51%. The network in that sense is 20% stronger against this
> attack in terms of cost.
>
> Jimmy
>
> On Sat, Apr 8, 2017 at 12:22 PM, Jorge Timón  wrote:
>
>> To be more specific, why "being higher will secure the Bitcoin network
>> better against newer optimizations"?
>> Or, to be more clear, let's forget about future "optimizations", let's
>> just think of an attacker. Does asicboost being used by all miners
>> make the system more secure against an attacker? No, for the attacker
>> can use asicboost too.
>> What about the case when not all the miners are using asicboost? Then
>> the attacker can actually get an advantage by suing asicboost.
>>
>> Sometimes people compare asicboost with the use of asics in general as
>> both providing more security for the network and users. But I don't
>> think this is accurate. The existence of sha256d asics makes an attack
>> with general purpose computing hardware (or even more specialized
>> architectures like gpgpu) much more expensive and unlikely. As an
>> alternative the attacker can spend additional resources investing in
>> asics himself (again, making many attacks more expensive and
>> unlikely).
>>
>> But as far as I know, asicboost can be implemented with software
>> running on general purpose hardware that integrates with regular
>> sha256d asics. There is probably an advantage on having the asicboost
>> implementation "in the same box" as the sha256d, yet again the
>> attacker can invest in hardware with the competitive advantage from
>> having asicboost more intergrated with the sha256d asics too.
>>
>> To reiterate, whether all miners use asicboost or only a subset of
>> them, I remain unconvinced that provides any additional security to
>> the network (to be more precise whether that makes "tx history harder
>> to rewrite"), even if it results on the hashrate charts looking "more
>> secure".
>>
>>
>> On Sat, Apr 8, 2017 at 6:27 PM, Jorge Timón  wrote:
>> >
>> >
>> > On 8 Apr 2017 5:06 am, "Jimmy Song via bitcoin-dev"
>> >  wrote:
>> >
>> > Praxeology Guy,
>> >
>> >> 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?
>> >
>> >
>> > Certainly, if only one company made use of the extra nonce space, they
>> would
>> > have an advantage. But think of it this way, if some newer ASIC
>> optimization
>> > comes up, would you rather have a non-ASICBoosted hash rate to defend
>> with
>> > or an ASICBoosted hash rate? Certainly, the latter, being higher will
>> secure
>> > the Bitcoin network better against newer optimizations.
>> >
>> >
>> > Why?
>>
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] A Small Modification to Segwit

[Jorge Timón via bitcoin-dev]

On 8 Apr 2017 8:31 pm, "praxeology_guy via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

There is the equation:
Power Cost + Captial Rent + Labor ~= block reward + fees


I don't know why many people insist on calling the subsidy the blick
reward. Thw block reward is both the block subsidy plus the block fees.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] A Small Modification to Segwit

[Jorge Timón via bitcoin-dev]

To be more specific, why "being higher will secure the Bitcoin network
better against newer optimizations"?
Or, to be more clear, let's forget about future "optimizations", let's
just think of an attacker. Does asicboost being used by all miners
make the system more secure against an attacker? No, for the attacker
can use asicboost too.
What about the case when not all the miners are using asicboost? Then
the attacker can actually get an advantage by suing asicboost.

Sometimes people compare asicboost with the use of asics in general as
both providing more security for the network and users. But I don't
think this is accurate. The existence of sha256d asics makes an attack
with general purpose computing hardware (or even more specialized
architectures like gpgpu) much more expensive and unlikely. As an
alternative the attacker can spend additional resources investing in
asics himself (again, making many attacks more expensive and
unlikely).

But as far as I know, asicboost can be implemented with software
running on general purpose hardware that integrates with regular
sha256d asics. There is probably an advantage on having the asicboost
implementation "in the same box" as the sha256d, yet again the
attacker can invest in hardware with the competitive advantage from
having asicboost more intergrated with the sha256d asics too.

To reiterate, whether all miners use asicboost or only a subset of
them, I remain unconvinced that provides any additional security to
the network (to be more precise whether that makes "tx history harder
to rewrite"), even if it results on the hashrate charts looking "more
secure".


On Sat, Apr 8, 2017 at 6:27 PM, Jorge Timón  wrote:
>
>
> On 8 Apr 2017 5:06 am, "Jimmy Song via bitcoin-dev"
>  wrote:
>
> Praxeology Guy,
>
>> 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?
>
>
> Certainly, if only one company made use of the extra nonce space, they would
> have an advantage. But think of it this way, if some newer ASIC optimization
> comes up, would you rather have a non-ASICBoosted hash rate to defend with
> or an ASICBoosted hash rate? Certainly, the latter, being higher will secure
> the Bitcoin network better against newer optimizations.
>
>
> Why?
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] A Small Modification to Segwit

[Jorge Timón via bitcoin-dev]

On 8 Apr 2017 5:06 am, "Jimmy Song via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

Praxeology Guy,

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?
>

Certainly, if only one company made use of the extra nonce space, they
would have an advantage. But think of it this way, if some newer ASIC
optimization comes up, would you rather have a non-ASICBoosted hash rate to
defend with or an ASICBoosted hash rate? Certainly, the latter, being
higher will secure the Bitcoin network better against newer optimizations.


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

Re: [bitcoin-dev] BIP proposal: Inhibiting a covert attack on the Bitcoin POW function

[Jorge Timón via bitcoin-dev]

On Thu, Apr 6, 2017 at 4:39 AM, Bram Cohen via bitcoin-dev
 wrote:
>
> 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.

This is an interesting point.

If you have a precise description why it makes an incentive to make
blocks smaller I would love to read it.
Somebody asked and I didn't have an answer.
I imagine you try several reorderings sometimes excluding certain
branches of the merkle tree, permuting the branches you exclude or
something similar, but I really don't know the algorithm in detail and
I didn't want to say something inaccurate.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP proposal: Inhibiting a covert attack on the Bitcoin POW function

[Jorge Timón via bitcoin-dev]

On Thu, Apr 6, 2017 at 2:30 PM, Luv Khemani via bitcoin-dev
 wrote:
>
> Just to add on to the ethical issue of blocking this.
>
>
> If blocking the covert form of ASICBOOST is seen as unethical, then the same 
> can be said about libsecp256k1, various client optimisations, Compactblocks.

This is simply a non sequitur. These optimizations benefit users. On
the other hand, asicboost doesn't benefit users in any way, it only
benefits some miners if and only if not all miners use it. It
obviously harms the miners that aren't using it by making them less
profitable (maybe to the point that they lose money).
If all miners use it or if no one of them uses it is equivalent from
the point of view of the user. In fact, the very fact of allowing it
makes the network less secure unless every single honest miner uses
it, for an attacker could use it against the network.

Even if asicboost was good for users in any way (which as explained
isn't), this proposal doesn't disable it, only the covert form that
cannot be proven to be used.

Therefore there's no rational arguments to oppose this proposal unless
you are (or are invested in):

A) A Miner currently using the covert form of asicboost.

B) A Miner planning to use the covert form of asicboost soon.

C) An attacker using or planning to use the covert form of asicboost.

> All of which seek to reduce the efficacy of large miners and selfish mining.

Asicboost doesn't seek this and doesn't help with this in any way.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For Comments

[Jorge Timón via bitcoin-dev]

Just saying that we can talk in terms of weight alone after segwit. 8 mb
weight is much more clear than 2 mb size to me. 2 mb size seems to
obfuscate the actual new limit with the proposed hf, which simply 8 mb
weight.

On 2 Apr 2017 12:03 pm, "Natanael"  wrote:

> My point, if you missed it, is that there's a mathematical equivalence
> between using two limits (and calculating the ratio) vs using one limit and
> a ratio. The output is fully identical. The only difference is the order of
> operations. Saying there's no blocksize limit with this is pretty
> meaningless, because you're just saying you're using an abstraction that
> doesn't make the limit visible.
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For Comments

[Jorge Timón via bitcoin-dev]

On Sat, Apr 1, 2017 at 5:34 PM, Natanael  wrote:
> Den 1 apr. 2017 16:07 skrev "Jorge Timón" :
> On Sat, Apr 1, 2017 at 3:15 PM, Natanael  wrote:
>> Den 1 apr. 2017 14:33 skrev "Jorge Timón via bitcoin-dev"
>> :
>> Segwit replaces the 1 mb size limit with a weight limit of 4 mb.
>> That would make it a hardfork, not a softfork, if done exactly as you say.
> No, because of the way the weight is calculated, it is impossible to
> create a block that old nodes would perceive as bigger than 1 mb
> without also violating the weight limit.
> After segwit activation, nodes supporting segwit don't need to
> validate the 1 mb size limit anymore as long as they validate the
> weight limit.
>
> https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#Block_size
>
> Huh, that's odd. It really does still count raw blockchain data blocksize.

It's not odd, it's just counter-intuitive. How can "< 4 mb weight" be
a more restrictive rule than "< 1 mb size"? Well, it is, that's why
segwit's size increase is a softfork.
It is not that hard once you look at the actual weight formula:
segregated_sigs_sise + (other_size * 4) < 4 "mb"

It is impossible to produce to produce a block that violates the 1 mb
size limit but doesn't violate the 4 mb weight limit too.
There can be block that are < 1 mb size but 20 mb in weight, but those
are invalid according to the new 4 mb weight rule.
At the same time, any block that violates the < 1 mb rule for old
nodes will be invalid not only to old nodes but also to any node
validating the new 4mb rule. This is not by chance but a design choice
for any block size increase within segwit to remain a softfork, which
is what can be deployed faster.

One extreme example would be any 1 mb block today. 1 "mb" of a block
today times 4 is 4 mb, so it complies with the new 4 mb weight rule.
The opposite extreme example would be 4 mb of signatures and 0 mb of
"other data", but this example is not really possible in practice
because signatures need some tx to be part of to be part of the block
itself.
The most extreme examples I have seen on testnet are 3.7 mb blocks,
but those don't represent the average usage today (whenever you read
this).

One common misunderstanding is that users who aren't using payment
channels (that includes lightning but also other smart contracts) or
users that aren't using mutlisig can't enjoy the so called "discount":
there's no reasonable argument for rejecting the "discount" on your
own transactions once/if segwit gets activated.

I would prefer to call the absence of "discount" *penalization*.
Signatures are unreasonable penalized pre-segwit, and there's more
things that remain unreasonably penalized with respect to their
influence on the current utxo after segwit. But signatures are by far
the biggest in data space and validation time, and the most important
unreasonable yet unintended penalization pre-segwit.

> It just uses a ratio between how many units each byte is worth for block
> data vs signature data, plus a cap to define the maximum. So the current max
> is 4 MB, with 1 MB of non-witness blockchain data being weighted to 4x = 4
> MB. That just means you replaced the two limits with one limit and a ratio.

Exactly, once one maximum limit is defined, no need for two limits.
But the current max is 1 mb size, not 4 mb weight until/unless segwit
is activated.
Some people complain about 4 mb weight not being as much as 4 mb size,
and that is correct, but both are bigger than 1 mb size.

> A hardfork increasing the size would likely have the ratio modified too.

If the single ratio needs to be modified, it can be modified now
before any rule changes are activated, no need to change the consensus
rules more than needed.

> With exactly the same effect as if it was two limits...

If you don't see any disadvantage on having one single limit if/when
segwit gets activated, I don't see the point of maintaining two
limits, but if you're happy to maintain the branch with the redundant
one you may get my ack: I don't see any disadvantage on checking the
same thing twice besides performance,

> Either way, there's still going to be non-segwit nodes for ages.

That's precisely why it's good segwit has been designed to be backward
compatible as a bip9 softfork.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For Comments

[Jorge Timón via bitcoin-dev]

On Sat, Apr 1, 2017 at 3:15 PM, Natanael  wrote:
>
>
> Den 1 apr. 2017 14:33 skrev "Jorge Timón via bitcoin-dev"
> :
>
> Segwit replaces the 1 mb size limit with a weight limit of 4 mb.
>
>
> That would make it a hardfork, not a softfork, if done exactly as you say.
>
> Segwit only separates out signature data. The 1 MB limit remains, but would
> now only cover the contents of the transaction scripts. With segwit that
> means we have two (2) size limits, not one. This is important to remember.
> Even with segwit + MAST for large complex scripts, there's still going to be
> a very low limit to the total number of possible transactions per block. And
> not all transactions will get the same space savings.

No, because of the way the weight is calculated, it is impossible to
create a block that old nodes would perceive as bigger than 1 mb
without also violating the weight limit.
After segwit activation, nodes supporting segwit don't need to
validate the 1 mb size limit anymore as long as they validate the
weight limit. The weight is also the only notion of cost miners need
to consider when comparing txs by feerate (fee per cost, before segwit
tx_fee/tx_size, post-segwit tx_fee/tx_weight).
This is important to remember, because having 2 separated limits or
costs would make block creation and relay policies much harder to
implement.

Therefore a hardfork after segwit can just increase the weight limit
and completely forget about the pre-segwit 1 mb size limit.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For Comments

[Jorge Timón via bitcoin-dev]

Segwit replaces the 1 mb size limit with a weight limit of 4 mb. After
segwit there's no need for MAX_BLOCK_BASE_SIZE anymore, let alone
MAX_BLOCK2_BASE_SIZE.
Thus, by "hf to 2 mb" it seems you just really mean hardforking from 4
mb weight to 8 mb weight.

I would also use the hardfork bit (sign bit in block.nNersion) as matt comments.

> We're in a deadlock and it seems we can't go forward adding more 
> functionality to segwit without the community approval (which include 
> miners). This is obvious to me.Then we have to go back.

If segwit is controversial the way it is (I still don't understand why
despite having insistently asking to users and miners who claim to
oppose it), adding more consensus rule changes won't make it any less
controversial. If anything, it would be removing consensus rule
changes, not adding them that could make it less controversial.

By no means I want to dissuade you from working on this bip proposal,
but I really don't see how it helps getting out of the deadlock at
all.


On Sat, Apr 1, 2017 at 1:44 PM, Sergio Demian Lerner via bitcoin-dev
 wrote:
> Some people have asked me for the current implementation of this patch to
> review. I remind you that the current patch does not implement the hard-fork
> signaling, as requested by Matt.
>
> The Segwit2Mb patch can be found here:
> https://github.com/SergioDemianLerner/bitcoin/commits/master
>
> For now, the segwit2mb repo has a single test file using the old internal
> blockchain building method (test/block_size_tests.cpp). This must be
> replaced soon with a better external test using the bitcoin/qa/rpc-tests
> tests, which I will begin to work on now after I collect all comments from
> the community.
>
>
> regards
>
>
>
> On Sat, Apr 1, 2017 at 3:55 AM, Jared Lee Richardson 
> wrote:
>>
>> > Remember that the "hashpower required to secure bitcoin" is determined
>> > as a percentage of total Bitcoins transacted on-chain in each block
>>
>> Can you explain this statement a little better?  What do you mean by
>> that?  What does the total bitcoins transacted have to do with
>> hashpower required?
>>
>>
>> On Fri, Mar 31, 2017 at 2:22 PM, Matt Corallo via bitcoin-dev
>>  wrote:
>> > Hey Sergio,
>> >
>> > You appear to have ignored the last two years of Bitcoin hardfork
>> > research and understanding, recycling instead BIP 102 from 2015. There
>> > are many proposals which have pushed the state of hard fork research
>> > much further since then, and you may wish to read some of the posts on
>> > this mailing list listed at https://bitcoinhardforkresearch.github.io/
>> > and make further edits based on what you learn. Your goal of "avoid
>> > technical changes" appears to not have any basis outside of perceived
>> > compromise for compromise sake, only making such a hardfork riskier
>> > instead.
>> >
>> > At a minimum, in terms of pure technical changes, you should probably
>> > consider (probably among others):
>> >
>> > a) Utilizing the "hard fork signaling bit" in the nVersion of the block.
>> > b) Either limiting non-SegWit transactions in some way to fix the n**2
>> > sighash and FindAndDelete runtime and memory usage issues or fix them by
>> > utilizing the new sighash type which many wallets and projects have
>> > already implemented for SegWit in the spending of non-SegWit outputs.
>> > c) Your really should have replay protection in any HF. The clever fix
>> > from
>> > Spoonnet for poor scaling of optionally allowing non-SegWit outputs to
>> > be spent with SegWit's sighash provides this all in one go.
>> > d) You may wish to consider the possibility of tweaking the witness
>> > discount and possibly discounting other parts of the input - SegWit went
>> > a long ways towards making removal of elements from the UTXO set cheaper
>> > than adding them, but didn't quite get there, you should probably finish
>> > that job. This also provides additional tuneable parameters to allow you
>> > to increase the block size while not having a blowup in the worst-case
>> > block size.
>> > e) Additional commitments at the top of the merkle root - both for
>> > SegWit transactions and as additional space for merged mining and other
>> > commitments which we may wish to add in the future, this should likely
>> > be implemented an "additional header" ala Johnson Lau's Spoonnet
>> > proposal.
>> >
>> > Additionally, I think your parameters here pose very significant risk to
>> > the Bitcoin ecosystem broadly.
>> >
>> > a) Activating a hard fork with less than 18/24 months (and even then...)
>> > from a fully-audited and supported release of full node software to
>> > activation date poses significant risks to many large software projects
>> > and users. I've repeatedly received feedback from various folks that a
>> > year or more is likely required in any hard fork to limit this risk, and
>> > limited pushback on that given the large increase which SegWit provides
>> > itself buying a ton of time.
>> >
>> > b) Having a significant disco

Re: [bitcoin-dev] Hard fork proposal from last week's meeting

[Jorge Timón via bitcoin-dev]

While Segwit's change from 1 mb size limit to 4 mb weight limit seems to be
controversial among some users (I find that very often it is because they
have been confused about what segwit does or even outright lied about it) I
don't think it's very interesting to discuss further size increases.
I find more interesting to talk to the users and see how they think Segwit
harms them, maybe we missed something in segwit that needs to be removed
for segwit to become uncontroversial, or maybe it is just disinformation.

On the other hand, we may want to have our first uncontroversial hardfork
asap, independently of block size. For example, we could do something as
simple as fixing the timewarp attack as bip99 proposes. I cannot think of a
hf that is easier to implement or has less potential for controversy than
that.

On 29 Mar 2017 8:32 am, "Bram Cohen via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

On Tue, Mar 28, 2017 at 9:59 AM, Wang Chun via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> The basic idea is, as many of us agree, hard fork is risky and should
> be well prepared. We need a long time to deploy it.
>

Much as it may be appealing to repeal the block size limit now with a grace
period until a replacement is needed in a repeal and replace strategy, it's
dubious to assume that an idea can be agreed upon later when it can't be
agreed upon now. Trying to put a time limit on it runs into the possibility
that you'll find that whatever reasons there were for not having general
agreement on a new setup before still apply, and running into the
embarrassing situation of winding up sticking with the status quo after
much sturm and drang.


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

Re: [bitcoin-dev] Fraud proofs for block size/weight

[Jorge Timón via bitcoin-dev]

Great stuff, although the ordering of the sections seems a little bit confusing.

I think it would be clearer to put the "Creation of proofs" section
before "Proof verification", maybe even before "Proof format" if a
high level defintion of "full tx size proof" is provided before.

Also, in "For the full-size proof, each transaction should be assumed
to be at a minimum the stripped-size rather than the fixed 60 bytes."
it seems you are referring to a "full-size block proof" as opposed to
a "full size tx proof", perhaps a better term could be "full-weight
block proof" if what you are referring to is the proof of the weight
instead of only the pre-segwit size.

Perhaps some short definitions for "stripped-size proof", "full tx
size proof", "full-size proof" and maybe also "size component" at the
beginning would be enough.

In "Network protocol", "It should not recheck blocks known to be
valid, " does "known to be valid" include the blocks that the peer
told us where valid (with their hash and 0 in the enumerated varint)?
Those could be invalid too if the peer was lying, no?
Do you mean "It should not recheck blocks known to be invalid,"?

Why do you need to have at least one full tx size?

In Rationale you have:
"
Why must a full tx size proof be included?

This is necessary to establish that the claimed block transaction
count is correct.
"

Why do you need to establish that? If you can establish that the
number of transactions is at least N and that N * 60 bytes is greater
than the size/weight limit, isn't it that enough?


On Wed, Mar 22, 2017 at 10:51 PM, Matt Corallo via bitcoin-dev
 wrote:
> It works today and can be used to prove exact size: the key observation is
> that all you need to show the length and hash of a transaction is the final
> SHA256 midstate and chunk (max 64 bytes). It also uses the observation that
> a valid transaction must be at least 60 bytes long for compression (though
> much of that compression possibility goes away if you're proving something
> other than "too large").
>
>
> On March 22, 2017 1:49:08 PM PDT, Bram Cohen via bitcoin-dev
>  wrote:
>>
>> Some questions:
>>
>> Does this require information to be added to blocks, or can it work today
>> on the existing format?
>>
>> Does this count number of transactions or their total length? The block
>> limit is in bytes rather than number of transactions, but transaction number
>> can be a reasonable proxy if you allow for some false negatives but want a
>> basic sanity check.
>>
>> Does this allow for proofs of length in the positive direction,
>> demonstrating that a block is good, or does it only serve to show that
>> blocks are bad? Ideally we'd like an extension to SPV protocol so light
>> clients require proofs of blocks not being too big, given the credible
>> threat of there being an extremely large-scale attack on the network of that
>> form.
>>
>>
>> On Wed, Mar 22, 2017 at 1:47 AM, Luke Dashjr via bitcoin-dev
>>  wrote:
>>>
>>> Despite the generalised case of fraud proofs being likely impossible,
>>> there
>>> have recently been regular active proposals of miners attacking with
>>> simply
>>> oversized blocks in an attempt to force a hardfork. This specific attack
>>> can
>>> be proven, and reliably so, since the proof cannot be broken without also
>>> breaking their attempted hardfork at the same time.
>>>
>>> While ideally all users ought to use their own full node for validation
>>> (even
>>> when using a light client for their wallet), many bitcoin holders still
>>> do
>>> not. As such, they are likely to need protection from these attacks, to
>>> ensure
>>> they remain on the Bitcoin blockchain.
>>>
>>> I've written up a draft BIP for fraud proofs and how light clients can
>>> detect
>>> blockchains that are simply invalid due to excess size and/or weight:
>>>
>>> https://github.com/luke-jr/bips/blob/bip-sizefp/bip-sizefp.mediawiki
>>>
>>> I believe this draft is probably ready for implementation already, but if
>>> anyone has any idea on how it might first be improved, please feel free
>>> to
>>> make suggestions.
>>>
>>> Luke
>>> ___
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Quadratic hashing solution for a post-segwit hard fork

[Jorge Timón via bitcoin-dev]

Segwit allows old -> old, old -> new, new -> old and of course new -> new
txs.

On 17 Mar 2017 1:47 a.m., "Erik Aronesty via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

Yeah, it does make things harder, and it's easy enough to soft fork to
handle arbitrary opt-in protocol improvements, new much larger block sizes,
whatever you want.   Even OK to migrate to a new system by not allowing
old->old or new->old transactions.



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

Re: [bitcoin-dev] Script Abuse Potential?

[Jorge Timón via bitcoin-dev]

I would assume that the controversial part of op_cat comes from the fact
that it enables covenants. Are there more concerns than that?

On 4 Jan 2017 04:14, "Russell O'Connor via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> For the record, the OP_CAT limit of 520 bytes was added by Satoshi
> 
> on the famous August 15, 2010 "misc" commit, at the same time that OP_CAT
> was disabled.
> The previous limit was 5000 bytes.
>
> On Tue, Jan 3, 2017 at 7:13 PM, Jeremy via bitcoin-dev  linuxfoundation.org> wrote:
>
>> Sure, was just upper bounding it anyways. Even less of a problem!
>>
>>
>> RE: OP_CAT, not as OP_CAT was specified, which is why it was disabled. As
>> far as I know, the elements alpha proposal to reenable a limited op_cat to
>> 520 bytes is somewhat controversial...
>>
>>
>>
>> --
>> @JeremyRubin 
>> 
>>
>> On Mon, Jan 2, 2017 at 10:39 PM, Johnson Lau  wrote:
>>
>>> No, there could only have not more than 201 opcodes in a script. So you
>>> may have 198 OP_2DUP at most, i.e. 198 * 520 * 2 = 206kB
>>>
>>> For OP_CAT, just check if the returned item is within the 520 bytes
>>> limit.
>>>
>>> On 3 Jan 2017, at 11:27, Jeremy via bitcoin-dev <
>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>
>>> It is an unfortunate script, but can't actually
>>> ​do
>>>  that much
>>> ​ it seems​
>>> . The MAX_SCRIPT_ELEMENT_SIZE = 520 Bytes.
>>> ​ Thus, it would seem the worst you could do with this would be to 
>>> (1-520*2)*520*2
>>> bytes  ~=~ 10 MB.
>>>
>>> ​Much more concerning would be the op_dup/op_cat style bug, which under
>>> a similar script ​would certainly cause out of memory errors :)
>>>
>>>
>>>
>>> --
>>> @JeremyRubin 
>>> 
>>>
>>> On Mon, Jan 2, 2017 at 4:39 PM, Steve Davis via bitcoin-dev <
>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>
 Hi all,

 Suppose someone were to use the following pk_script:

 [op_2dup, op_2dup, op_2dup, op_2dup, op_2dup, ...(to limit)...,
 op_2dup, op_hash160, , op_equalverify, op_checksig]

 This still seems to be valid AFAICS, and may be a potential attack
 vector?

 Thanks.


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


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

Re: [bitcoin-dev] Committed bloom filters for improved wallet performance and SPV security

[Jorge Timón via bitcoin-dev]

There were talks about implementing spv mode for bitcoin core without using
bloom filters. Less efficient because it downloads full blocks, but better
for privacy. Perhaps other spv implementations should consider doing the
same instead of committing the filters in the block?

Now I feel I was missing something. I guess you can download the whole
block you're interested in instead of only your txs and that gives you
privacy.
But how do you get to know which blocks are you interested in?

If the questions are too basic or offtopic for the thread, I'm happy
getting answers privately  (but then maybe I get them more than once).


On 4 Jan 2017 09:57, "Aaron Voisine via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

It's easy enough to mark a transaction as "pending". People with bank
accounts are familiar with the concept.

Although the risk of accepting gossip information from multiple random
peers, in the case where the sender does not control the receivers network
is still minimal. Random node operators have no incentive to send fake
transactions, and would need to control all the nodes a client connects to,
and find a non-false-positive address belonging to the victims wallet.

It's not impossible, but it's non trivial, would only temporarily show a
pending transaction, and provide no benefit to the node operator. There are
much juicier targets for an attacker with the ability to sybil attack the
entire bitcoin p2p network.

Aaron

On Tue, Jan 3, 2017 at 11:47 PM Jonas Schnelli  wrote:

> Hi
>
>
>
> > Unconfirmed transactions are incredibly important for real world use.
>
> > Merchants for instance are willing to accept credit card payments of
>
> > thousands of dollars and ship the goods despite the fact that the
>
> > transaction can be reversed up to 60 days later. There is a very large
>
> > cost to losing the ability to have instant transactions in many or
>
> > even most situations. This cost is typically well above the fraud risk.
>
> >
>
> > It's important to recognize that bitcoin serves a wide variety of use
>
> > cases with different profiles for time sensitivity and fraud risk.
>
> >
>
> I agree that unconfirmed transactions are incredibly important, but not
>
> over SPV against random peers.
>
>
>
> If you offer users/merchants a feature (SPV 0-conf against random
>
> peers), that is fundamentally insecure, it will – sooner or later – lead
>
> to some large scale fiasco, hurting Bitcoins reputation and trust from
>
> merchants.
>
>
>
> Merchants using and trusting 0-conf SPV transactions (retrieved from
>
> random peers) is something we should **really eliminate** through
>
> education and by offering different solution.
>
>
>
> There are plenty, more sane options. If you can't run your own full-node
>
> as a merchant (trivial), maybe co-use a wallet-service with centralized
>
> verification (maybe use two of them), I guess Copay would be one of
>
> those wallets (as an example). Use them in watch-only mode.
>
>
>
> For end-users SPV software, I think it would be recommended to...
>
> ... disable unconfirmed transactions during SPV against random peers
>
> ... enable unconfirmed transactions when using SPV against a trusted
>
> peer with preshared keys after BIP150
>
> ... if unconfirmed transactions are disabled, show how it can be enabled
>
> (how to run a full-node [in a box, etc.])
>
> ... educate, inform users that a transaction with no confirmation can be
>
> "stopped" or "redirected" any time, also inform about the risks during
>
> low-conf phase (1-5).
>
>
>
> I though see the point that it's nice to make use of the "incoming
>
> funds..." feature in SPV wallets. But – for the sake of stability and
>
> (risk-)scaling – we may want to recommend to scarify this feature and –
>
> in the same turn – to use privacy-preserving BFD's.
>
>
>
> 
>
>
>
>
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Planned Obsolescence

[Jorge Timón via bitcoin-dev]

On Thu, Dec 15, 2016 at 4:38 AM, Juan Garavaglia via bitcoin-dev
 wrote:
> Older node versions may generate issues because some upgrades will make
> several of the nodes running older protocol versions obsolete and or
> incompatible. There may be other hard to predict behaviors on older versions
> of the client.

Hard to predict or not, you can't force people to run newer software.

> In order to avoid such wide fragmentation of "Bitcoin Core” node versions
> and to help there be a more predictable protocol improvement process, I
> consider it worth it to analyze introducing some planned obsolescence in
> each new version. In the last year we had 4 new versions so if each version
> is valid for about 1 year (52560 blocks) this may be a reasonable time frame
> for node operators to upgrade. If a node does not upgrade it will stop
> working instead of participating in the network with an outdated protocol
> version.

When you introduce anti-features like this in free software they can
be trivially removed and they likely will.

> These changes may also simplify the developer's jobs in some cases by
> avoiding them having to deal with ancient versions of the client.

There's a simpler solution for this which is what is being done now:
stop maintaining and giving support for older versions.
There's limited resources and developers are rarely interested in
fixing bugs for very old versions. Users shouldn't expect things to be
backported to old versions (if developers do it and there's enough
testing, there's no reason not to do more releases of old versions, it
is just rarely the case).
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] New BIP: Hardfork warning system

[Jorge Timón via bitcoin-dev]

On Fri, Dec 2, 2016 at 5:18 AM, Luke Dashjr  wrote:
> On Friday, December 02, 2016 1:42:46 AM Jorge Timón via bitcoin-dev wrote:
>> We can already warn users of a hardfork when a block is invalid (at
>> least) because of the highest bit in nVersion (as you say, because it
>> is forbidden since bip34 was deployed).
>
> The difference is that right now, full nodes will happily follow a shorter
> best-valid chain. This BIP would require them to hold back at the best-common
> block between the best-valid chain and the invalid chain, forcing the user to
> make a decision whether to reject the invalid chain permanently, or upgrade to
> a version which can understand that chain as valid.

Ok, so the goal of the softfork then is to hold on is there is to
"hold on" on the most-work valid chain while there's an even-more-work
invalid chain and for new nodes force a response from the user. This
could be clearer in the motivation section.

We can still notify and force a response from the user with a single
invalid block (or N, or W accumulated work). Note that we don't need
to "hold on" while waiting for the user's response. Therefore I insist
there could be a PIB with all the recommended warnings but not
softfork (which this one could extend from).

Thinking as a full node user, I'm not sure I want my node to "hold on"
on validating new valid blocks just because there's some "longest"
invalid chain out there and I may chose to follow that instead later.
Before paying or copying another address to receive, I would
definitely would want the warning though.

Particularly as a miner (not that I'm one), I think validationless
mining shows us that some miners prefer to throw energy to the abyss
of validation uncertainty rather than stop their mining hardware.
What if when I give the response to the system I decide to pass on the
HF but it means my hardware have been not mining in the valid chain
for hours?
I would account that as "money lost thanks to a 'friendly' interface".
Specially if we're talking about a controversial hardfork.

If we're talking about an uncontroversial hardfork, I would definitely
prefer BIP9 coordination.
I would prefer to receive the warning when, say, 30% of the hashrate
is supporting an unknown change to the consensus rules (regardless of
it being a softfork or a hardfork, which I don't know yet until the hf
bit is used because the change is unknown to me), way before I need to
decide what branch to mine.

In fact, if I was a miner but not a user at the same time, after
knowing about the unknown hardfork and if I consider the hardfork to
be potentially controversial, I would try to coordinate with exchanges
(and pools if no solo mining) to be able to write a program that
chooses the chain likely to be most profitable depending on difficulty
and price feeds for every block.

In the case of a SHF, even more reason to keep mining on the old
chain, perhaps I mine one empty block (assuming that's a rule in the
SHF) out of luck, or maybe I should just start mining empty blocks
whenever I see the SHF bit active for a block whose chain keeps
growing.
Perhaps for a SHF we should use a valid bit instead of an invalid one
(clearing all possible fears with old and older nodes perceiving SHFs
differently as HFs and SFs respectively). We can trivially make old an
older nodes coincide in their perception of good-willing SHFs as
either HFs or SFs as we wish. Choosing divergence of perception from
the 2 versions we're considering makes no sense to me.
I'm reserving my judgement for which one I prefer just in case there's
actually an advantage in this divergence, but I've missed it.

>> It seems the softfork serves only to warn about soft-hardforks, assuming it
>> chooses to use this mechanism (which a malicious soft hardfork may not do).
>
> Note: a malicious "SHF" is not a SHF at all, but an "evil fork".

Terminology, I think you get my point. I'm all for formalizing
definitions but please let's not slow down discussion unnecessarily.
I'm fine saying "evil fork" instead of "malicious SHF" if you prefer
that, but they're just the same thing.

>> In fact, you could reuse another of the prohibited bits to signal a soft-
>> hardfork while distinguishing it from a regular hardfork. And this will also
>> serve for old nodes that have not upgraded to the softfork. But, wait,
>> if you signal a soft-hardfork with an invalid bit, it's not a
>> soft-hardfork anymore, is it? It's simply a hardfork.
>
> Nodes implementing this BIP will see it as a simple hardfork, but will
> intentionally provide equivalent behaviour as older nodes which see it as a
> soft-hardfork. In other words, all [compatible] hardforks will now behave lik

Re: [bitcoin-dev] New BIP: Hardfork warning system

[Jorge Timón via bitcoin-dev]

We can already warn users of a hardfork when a block is invalid (at
least) because of the highest bit in nVersion (as you say, because it
is forbidden since bip34 was deployed). It seems the softfork serves
only to warn about soft-hardforks, assuming it chooses to use this
mechanism (which a malicious soft hardfork may not do). In fact, you
could reuse another of the prohibited bits to signal a soft-hardfork
while distinguishing it from a regular hardfork. And this will also
serve for old nodes that have not upgraded to the softfork. But, wait,
if you signal a soft-hardfork with an invalid bit, it's not a
soft-hardfork anymore, is it? It's simply a hardfork.
Your softfork would result in soft hardforks being hardforks for nodes
that upgraded to this softfork, but softforks for older nodes.
Is this the intended behaviour? if so, why?

I would rather have a simpler BIP that doesn't require a softfork
(whether it recommends soft-hardforks to use one of the currently
invalid bits, but a different one than from hardforks or not, but I
also don't see the reason why soft-hardforks should appear as invalid
blocks for older nodes instead of using regular softfork warning
[besides, in this case, after the "unkown softfork" warning you will
get only empty blocks, which may make you suspicious]).
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] BIP30 and BIP34 interaction (was Re: [BIP Proposal] Buried Deployments)

[Jorge Timón via bitcoin-dev]

On Thu, Nov 17, 2016 at 1:00 AM, Eric Voskuil  wrote:
> This is a misinterpretation of BIP30. Duplicate transaction hashes can
> and will happen and are perfectly valid in Bitcoin. BIP34 does not
> prevent this.

Sorry for moving the topic, but isn't duplication of tx hashes
precisely what BIP30 prevents?
That was my undesrtanding but should read it again.
Since regular txs take inputs, the collision is extremely unlikely
(again, this is my understanding, please correct me when wrong), the
worrying case is coinbase txs (which don't have input to take entropy
from). By introducing the committed height, collisions on coinbase txs
are prevented too.

If I'm wrong on any of this I'm more than happy to learn why.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [BIP Proposal] Buried Deployments

[Jorge Timón via bitcoin-dev]

On Wed, Nov 16, 2016 at 3:18 PM, Thomas Kerin via bitcoin-dev
 wrote:
> BIP30 actually was given similar treatment after a reasonable amount of time
> had passed.
> https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L2392

This is not really the same. BIP30 is not validated after BIP34 is
active because blocks complying with BIP34 will always necessarily
comply with BIP30 (ie coinbases cannot be duplicated after they
include the block height).
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev