Re: [bitcoin-dev] BIP proposal: Timelocked address fidelity bond for BIP39 seeds

[ZmnSCPxj via bitcoin-dev]

Good morning Chris,

> Hello ZmnSCPxj,
>
> Renting out fidelity bonds is an interesting idea. It might happen in
> the situation where a hodler wants to generate yield but doesn't want
> the hassle of running a full node and yield generator. A big downside of
> it is that the yield generator income is random while the rent paid is a
> fixed cost, so there's a chance that the income won't cover the rent.

The fact that *renting* is at all possible suggests to me that the following 
situation *could* arise:

* A market of lessors arises.
* A surveillor creates multiple identities.
* Each fake identity rents separately from multiple lessors.
* Surveillor gets privacy data by paying out rent money to the lessor market.

In defiads, I and Tamas pretty much concluded that rental would happen 
inevitably.
One could say that defiads was a kind of fidelity bond system.
Our solution for defiads was to prioritize propagating advertisements (roughly 
equivalent to the certificates in your system, I think) with larger bonded 
values * min(bonded_time, 1 year).
However, do note that we did not intend defiads to be used for 
privacy-sensitive applications like JoinMarket/Teleport.


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

[bitcoin-dev] CTV Meeting #8 Reminder + Agenda (Tuesday, May 3rd, 12:00 PT / 7PM UTC)

[Jeremy Rubin via bitcoin-dev]

Developers,

A reminder that the regularly scheduled CTV Meeting is tomorrow at 12:00
Pacific Time in ##ctv-bip-review in Libera.

In terms of agenda, we'll keep it as an open forum for discussion guided by
the participants. Feel free to propose meeting topics in the IRC in advance
of the meeting to aid in allocating time to things that you would like to
have discussed.

Best,

Jeremy

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

Re: [bitcoin-dev] [Pre-BIP] Fee Accounts

[Jeremy Rubin via bitcoin-dev]

Ok, got it. Won't waste anyone's time on terminology pedantism.


The model that I proposed above is simply what *any* correct timestamping
service must do. If OTS does not follow that model, then I suspect whatever
OTS is, is provably incorrect or, in this context, unreliable, even when
servers and clients are honest. Unreliable might mean different things to
different people, I'm happy to detail the types of unreliability issue that
arise if you do not conform to the model I presented above (of which,
linearizability is one way to address it, there are others that still
implement epoch based recommitting that could be conceptually sound without
requiring linearizability).

Do you have any formal proof of what guarantees OTS provides against which
threat model? This is likely difficult to produce without a formal model of
what OTS is, but perhaps you can give your best shot at producing one and
we can carry the conversation on productively from there.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP proposal: Timelocked address fidelity bond for BIP39 seeds

[Chris Belcher via bitcoin-dev]

Hello ZmnSCPxj,

Renting out fidelity bonds is an interesting idea. It might happen in 
the situation where a hodler wants to generate yield but doesn't want 
the hassle of running a full node and yield generator. A big downside of 
it is that the yield generator income is random while the rent paid is a 
fixed cost, so there's a chance that the income won't cover the rent.


JoinMarket takers since the start have checked that a fidelity bond 
doesn't appear twice. The technique doesn't deserve a section in the BIP 
because this BIP is only about specifying the wallets that hold fidelity 
bond UTXOs for makers, not takers which receive fidelity bond messages.


In JoinMarket this is done in this code here:
https://github.com/JoinMarket-Org/joinmarket-clientserver/blob/6b05f65260a487cd22f175ba64d499fbe8122530/jmclient/jmclient/taker.py#L1020-L1021

Best,
CB

On 01/05/2022 12:41, ZmnSCPxj wrote:

Good morning again Chris,

I wonder if there would be an incentive to *rent* out a fidelity bond, i.e. I 
am interested in application A, you are interested in application B, and you 
rent my fidelity bond for application B.
We can use a pay-for-signature protocol now that Taproot is available, so that 
the signature for the certificate for your usage of application B can only be 
completed if I reveal a secret via a signature on another Taproot UTXO that 
gets me the rent for the fidelity bond.

I do not know if this would count as "abuse" or just plain "economic 
sensibility".
But a time may come where people just offer fidelity bonds for lease without 
actually caring about the actual applications it is being used *for*.
If the point is simply to make it costly to show your existence, whether you 
pay for the fidelity bond by renting it, or by acquiring your own Bitcoins and 
foregoing the ability to utilize it for some amount of time (which should cost 
closely to renting the fidelity bond from a provider), should probably not 
matter economically.

You mention that JoinMarket clients now check for fidelity bonds not being used 
across multiple makers, how is this done exactly, and does the technique not 
deserve a section in this BIP?

Regards,
ZmnSCPxj

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

Re: [bitcoin-dev] ANYPREVOUT in place of CTV

[Billy Tetrud via bitcoin-dev]

>   If a QC is able overnight to spend a large fraction of the supply, your
coins in your super non-QC vulnerable-bare-CTV-covenant (that would
eventually become vulnerable when trying to use it) are worthless.[1]

I know this has been debated to death, but I really don't think this
argument is very convincing. First of all, why are we assuming that if for
example, "satoshi's hoard" of 5+ million bitcoins was stolen, that it would
mean bitcoin becomes worthless? To me this is an absurd assumption to make.
The thief almost certainly wouldn't want to just destroy bitcoin. But even
if they did and put it all up for sale overnight, yes it would tank
bitcoin's price *temporarily*. But in the long run, this is less than 1/3
of the supply, and it at worst could be considered monetary inflation of <
30%, and so that's the amount that the price should take a hit of: less
than 30%. Plenty of fiat currencies have survived worse.

Second of all, its incredibly unlikely that someone is suddenly going to be
able to do QC so well that they jump straight to being able to find "a
large fraction" of the private keys out there, or enough private keys to
make up a large fraction of the supply. Its far more likely that the first
quantum computers that are able to derive *any* private keys will still
take a long time (weeks? months?) to do one. If you have your bitcoins in a
segwit address, you know that they can't be stolen by a quantum computer.
You can sit back calmly, and figure out what to do next. By contrast, if
your life savings is in a taproot address, you have to drop everything with
your underwear on fire and recklessly move that stuff ASAP. Chances for
hasty mistakes is high.

But lets say someone *does* jump to being able to derive 1 private key per
minute (pretty darn fast if you ask me). It would currently take such a
machine 152 years to crack all the 80 million UTXOs in existence. By the
time there are practical quantum machines, it'll probably be at least
double that many UTXOs. If it was trying to crack revealed private keys
from mempool transactions, it could only really hit 10 out of 2000
transactions. Hashing the public key is I think is quite an effective
protection to a quantum computing attack in the vast majority of likely QC
emergence scenarios. I honestly don't understand how someone could come to
a different conclusion.

It makes a lot of sense in a world where quantum computers are now a very
real thing, to store large amounts of bitcoin in a possibly slightly less
efficient way in order to ensure that those funds can't be snatched in a QC
disaster scenario. I would be very interested to see a proposal to add the
option of having a taproot address type that doesn't expose the bare public
key.


On Fri, Apr 29, 2022 at 6:53 AM Nadav Ivgi via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Correction: thinking about this some more, you can't actually expect to
> have a stable txid if you allow additional inputs at all...
>
> So yes, amending BIP 118 to commit to sha_sequences (which indirectly also
> commits to the number of inputs) as proposed in the OP should be sufficient
> to get stable txids for single-input transactions.
>
> (I initially thought that APO has to cover some additional tx parts for
> this, but it seems that it's really just the scriptSig which is guarrnated
> to be empty if you have a single input that is known to be the taproot APO
> spend.)
>
> So in overall, my (1) and (5) points are only applicable to
> APO-as-currently-spec'd and not to the suggested APO revision.
>
> On Fri, Apr 29, 2022 at 1:21 PM Nadav Ivgi  wrote:
>
>> > This is *literally* what the post you are replying to is proposing to
>> solve.
>>
>> I thought the changes mentioned in the OP (+ committing to the spent
>> input index) only solves the half-spend problem, but not the stable txids
>> one?
>>
>> There can be other inputs with a scriptSig, which doesn't get committed
>> to in the APO hash. I guess this isn't too common, but there might be some
>> cases where you would want to spend some (pre-selected) non-segwit inputs
>> alongside your covenant, maybe for fees. With CTV you would pre-commit to
>> the scriptSig which makes it non-malleable even if the script itself is.
>>
>> > Hmm? You can't have channel factories without Eltoo. (Well, you can in
>> theory but good luck.)
>> > Maybe you are refering to non-interactive channel creation?
>>
>> I was referring to what BIP 119 calls 'Batched Channel Creation' [0],
>> which is a sort of a channel factory construction under a broader
>> definition (and in fact was previously called that in the BIP [1]).
>>
>> > The case for stable txids is less strong if we have APO (and therefore
>> Eltoo).
>>
>> There's merit in using these factory constructs for Poon-Dryja channels
>> even if Eltoo was available.
>> I don't foresee Eltoo taking over the penalty approach entirely, but
>> rather the two living side by side.
>>
>> (It could theoretically be 

Re: [bitcoin-dev] Conjectures on solving the high interactivity issue in payment pools and channel factories

[Billy Tetrud via bitcoin-dev]

Hi Antoine,

Very interesting exploration. I think you're right that there are issues
with the kind of partitioning you're talking about. Lightning works because
all participants sign all offchain states (barring data loss). If a
participant can be excluded from needing to agree to a new state, there
must be an additional mechanism to ensure the relevant state for that
participant isn't changed to their detriment.

To summarize my below email, the two techniques I can think for solving
this problem are:

A. Create sub-pools when the whole group is live that can be used by the
sub- pool participants later without the whole group's involvement. The
whole group is needed to change the whole group's state (eg close or open
sub-pools), but sub-pool states don't need to involve the whole group.
B. Have an always-online system empowered to sign only for group updates
that *do not* change the owner's balance in the group. This could be done
with a hardware-wallet like device, or could be done with some kind of new
set of opcodes that can be used to verify that a particular transaction
isn't to the owner's detriment.

I had some thoughts that I think don't pan out, but here they are anyway:

What if the pool state transaction (that returns everyone's money) has each
participant sign the input + their personal output (eg with sighash flags)?
That way the transaction could have outputs swapped out by a subset of
participants as needed. Some kind of eltoo mechanism could then ensure that
the latest transaction can override earlier transactions. As far as the
non-participating members are concerned, they don't care whether the newest
state is published or whether the newest state they participated in is
published - because their output is identical either way. However, I can
see that there might be problems related to separate groups of participants
creating conflicting transactions, ie A B & C create a partition like this,
and so do D E & F, but they don't know about each other's state. If they
have some always-online coordination mechanism, this could be solved as
long as the participants aren't malicious. But it still leaves open the
possibility that some participants could intentionally grief others by
intentionally creating conflicting state transactions. Theoretically it
could be structured so that no funds could be directly stolen, but it seems
unavoidable that some group of members could create a secret transaction
that when published makes the most recent honest state not minable.

Come to think of it tho, this doesn't actually solve the double spending
problem. The fundamental issue is that if you have a subset of participants
creating partitions like this, without the involvement of the whole group,
its impossible for any subset of participants to know for sure that there
isn't a double-spending partition amongst another set of members of the
group.

On-chain bitcoin transactions prevent double spending by ensuring that
everyone knows what outputs have been spent. Payment channels prevent
double spending by ensuring that everyone that's part of the channel knows
what the current channel state is. Any 3rd layer probably needs this exact
property: everyone involved must know the state. So you should be able to
create a partition when the whole group is live, and thereafter the members
of that partition can use that partition without involving the rest of the
group. I think that pattern can work to any level of depth. After thinking
about this, I conjecture it might be a fundamental property of the double
spending problem. All participants must be aware of the whole state
otherwise the double spending problem exists for those who aren't aware of
the whole state.

> this is forcing the pool/factory user to share their key materials with
potentially lower trusted entities, if they don't self-host the tower
instances.

I had a conceptual idea a while back (that I can't find at the moment)
about offline lightning receiving. The concept is that each lightning node
in a channel has two separate keys: a spending-key and a receiving-key. The
spending-key must be used manually by the node owner to send payments,
however the receiving-key can be given to an always-online service that can
use that key only to either receive funds (ie update the state to a more
favorable state).

Right now with just a single-hot-key setup you need to trust your online
system to only sign receiving transactions and would refuse to sign any
proposed channel update not in the owner's favor. However, if the node was
compromised all bets are off - the entire channel balance could be stolen.

You could do this logic inside a hardware-wallet-like device that checks
the proposed updates and verifies the new state is favorable before
signing. This could go a long way to hardening lightning nodes against
potential compromise.

But if we go a step further, what if we enable that logic of ensuring the
state is more favorable with an on-chain 

Re: [bitcoin-dev] Multiple ways to do bitcoin covenants

[Billy Tetrud via bitcoin-dev]

I've been thinking about writing something about covenant proposals from
the viewpoint of wallet vaults specifically (mostly because that's the use
case I care most about).

CTV is basically the minimal covenant opcode you can do that doesn't have
malleability. Everything else either introduces malleability, infinite
recursion, or has interactions with other proposed opcodes that could
introduce potentially undesirable effects like those.

TXHASH+CSFS seems like on its own might enable pretty much
identical capabilities to CTV (including no malleability). But it can also
do other things (mostly because CSFS can do other things), which isn't
necessarily a bad thing, but its more stuff to be analyzed. TXHASH+CSFS in
terms of wallet vaults seems to provide no benefits over CTV as far as I
can imagine.

It seems pretty clear that anything involving OP_CAT is out for the time
being. There are so many things it can enable that it seems most people
aren't comfortable adding it at  the moment.

APO wallet vaults seem rather hacky, inefficient, and limited. Certainly
not easy to reason about. But this is somewhat a function of my limited
understanding of them. Its not clear to me if anyone is actually suggesting
that we should use APO for covenants, but it doesn't feel like the right
approach.

TLUV + IN_OUT_AMOUNT can do infinitely recursive covenants. IN_OUT_AMOUNT
wasn't very clearly specified that I know of, but its not a very robust way
of ensuring the correct amount goes where you want. If TLUV requires a
single input and a single output, IN_OUT_AMOUNT makes sense because you can
simply do opcode math to determine if the output is receiving enough coins
(and not eg being all lost as fees). Maybe it could be extended to allow
multiple outputs, but extending it to allow for multiple inputs would be
difficult and you'd probably want a completely different mechanism for
that. If you're doing any math the script itself around amounts and fees,
this doesn't work well in any scenario where multiple inputs might send to
the same address, or be combined into the same output, since each input's
script can't interact.

But since TLUV at its most basic should be able to say "remove the only
tapleaf in this tree and replace it with this other tap tree", it should be
able to do pretty arbitrary covenants. It ideally should be paired up with
something that has better control over how input amounts flow to outputs
than IN_OUT_AMOUNT allows (see the design considerations here
).


TLUV is built for evictions, but it seems its likely not really very good
at that, as Zman mentioned in his post about OP_EVICT

(which is a covenant opcode that can't be used for wallet vaults, tho
perhaps its characteristics can be used in a kind of TLUV2 opcode that does
evictions better, but also can add tapleaves).

OP_CHECKOUTPUTVERIFY  is
another interesting one. Also has a form that allows recursive covenants.
It also has similar awkwardness as TLUV + IN_OUT_AMOUNT around multi-input
transactions. It has the half-spend problem if two outputs are combined
that specify the same output index and script pattern. It also seems like a
rather expensive opcode to use beyond very simple covenants, since the
scripts basically has to be duplicated in the transaction specifying the
covenant and then again when the subsequent transaction is spent. Its not
very taproot friendly either: would you have to specify the entire taproot
script tree? Any similar opcode that requires specifying the exact
script(s) fundamentally can't take advantage taproot's ability to keep
scripts private until that spend path is actually used.

As far as I can tell, few of these other covenant opcodes have even been
concretely specified, let alone analyzed enough to know whether they're
worth pursuing. It seems like all but CTV (potentially TXHASH+CSFS) have
significant flaws and would need reworking in order to fix them.

I guess in short, I agree with you. Over these other ideas that have gotten
significant attention, none really seem to be of high enough quality to be
put into bitcoin in their current state.




On Thu, Apr 28, 2022 at 3:47 AM alicexbt via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> CTV and other covenant proposals, tradeoffs, and overlapping features are
> among the topics being explored recently. I had some views and questions on
> this subject.:
>
> a) Does bitcoin already have opcodes with overlapping features? Yes
>
> b) Can we have multiple ways with some overlapping features to do bitcoin
> covenants with some tradeoffs? Yes
> _
> c) What are these tradeoffs if we compare CTV, APO, TLUV and TXHASH+CSFS?
>
> I am sure about a) because it was already answered in CTV chat by Jeremy
> and sheshek. Example: 

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

[Billy Tetrud via bitcoin-dev]

>  if you are perfectly rational, you can certainly imagine a "what if"
where your goal is different from your current goal and figure out what you
would do ***if*** that were your goal instead.

I see what you're saying, and I'm a lot more on board with that. I still
think "rational" can't mean "perfect" - like "perfectly rational" is not
the same as "you magically get to the optimal answer". But I think my line
of thinking on this is a lot more pedantic than my previous contention. But
I will agree that for a given specific objective goal (that ignores other
goals), there is an objective set of answers that any logical person should
eventually be able to agree on. Of course, if there's any subjectivity in
the goal, then discussing the goal amongst two different people will really
mean that each of them are discussing slightly different goals, which
breaks the premise. So really for alignment to happen, the goal in question
needs to be really specific in order to remove any significant
subjectivity.

> better-than-human rationality

I like to think of rationality in the following way. Any economic actor is
a being that has goals they want to maximize for, and tools at their
disposal to analyze and affect their world. A rational actor is one that
attempts to use their tools to the best of their ability to maximize their
goals. Perhaps goals is a misleading word to use here, since it implies
something that can be achieved, whereas I really mean a set of weighted
metrics that can hypothetically always be improved upon. But in any case, a
human starts with goals built into their genetics, which in turn build
themselves into the structure of their body. The tools a human has is also
their body and their brain. The brain is not a perfect tool, and neither is
the rest of the body. However, humans use what they have to make decisions
and act on their world. The goals a human has evolve as they have
experiences in the world (which end up physically changing their brain). In
this sense, every human, and every possible actor really, must be a
rational actor. They're all doing the best they can, even if the tools at
their disposal are very suboptimal for maximizing their underlying goals.
What more can you ask of a rational actor than to use the tools they have
to achieve their goals?

So I don't think anyone is more or less "rational" than anyone else. They
just have different goals and different levels of ability to maximize those
goals. In my definition above, the goals are completely arbitrary. They
don't have to be anything in particular. A person could have the goal of
maximizing the number of paper clips in the world, at all other costs. This
would almost certainly be "bad" for that person, and "bad" for the world,
but if that's really what their goals are, then that "badness" is a
subjectivity that you and I would be placing on that goal because our goals
are completely different from it. To the being with that goal, it is a
totally perfect goal.

The idea that someone can be "more rational" than someone else kind of
boils everything down to one dimension. In reality, everyone has their
different skills and proficiencies. In a futures market, you might be
better at predicting the price of salmon, but you might be quite bad at
predicting human population changes over time. Does this mean you're "more
rational" about salmon but "less rational" about how human populations
change? I would say a better way to describe this is proficiency, rather
than rationality.



> a future market

A futures market for predictions is an interesting idea. I haven't really
heard about such a thing really being done other than in little
experiments. Are you suggesting we use one to help make decisions about
bitcoin? One issue is that the questions a futures market answers have to,
like my conclusion in the above paragraph, be completely objective. So a
futures market can't answer the question "what's the best way to design
covenants?" tho it could answer the question "will CTV be activated by
2024?". But as a consequence, I don't think a future's market could help
much in the formulation of appropriate goals for bitcoin. That would need
to be hashed out by making a lot of different compromises amongst
everyone's various subjective opinion's about what is best.

And I think that's really what I'm suggesting here, is that we bitcoiners
discuss what the objective goals of bitcoin should be, or at least what
bounds on those goals there should be. And once we have these objective
goals, we can be aligned on how to appropriately solve them. It wouldn't
avoid the nashing of teeth needed to hash out the subjective parts of our
opinions in getting to those goals, but it could avoid much nashing of
teeth in the other half of the conversation: how to achieve the goals we
have reached consensus on.

Eg, should a goal of bitcoin be that 50% of the world's population should
require spending no more than 1% of their income to be able to run a 

Re: [bitcoin-dev] Working Towards Consensus

[John Carvalho via bitcoin-dev]

Jeremy,

The path to consensus is to propose things that everyone needs. Demand
comes from the market, not the designers.

Designers (engineers) solve problems with designs, but when they speculate
and lead the process, they create problems instead. Bitcoin is not a place
for speculative feature additions. Bitcoin cannot afford a culture of
additive features no one is asking for. Bitcoin thrives in a culture of
"NO." Rejection of change is Bitcoin's primary feature.

There is NO HOPE of EVER getting the majority of Bitcoin users to be able
to grasp, audit, and meaningfully consent to complicated new features, nor
to assess how they may interact with existing features in undesirable ways
or affect Bitcoin's incentive structure. To ignore this is a selfish
egomania that too many devs succumb to. The public already trusts Core devs
more than they probably should, and it is unwise to lean on that trust.

You are of course welcome to try and research and document all of the
details about how this plays out in practice, but you will fail to specify
a path to approval or any sort of clear governance structure for ensuring
that speculative features get into Bitcoin. You will seek and only see a
bias that allows you to get what YOU want. Until you focus on what everyone
wants, you will not reach consensus on anything.

Bitcoin changes should solve obvious problems and provide easy wins on
optimization, security, and privacy. Seek simplicity and efficiency, not
complication.

We have yet to saturate usage of the features we have added already in the
past 5 years. Use those. It is becoming apparent over time that many
features can be accomplished off-chain, or without a blockchain, or by
merely anchoring into currently available bitcoin transaction types.

There is simply no urgency or problem that any of the proposed soft fork
features are trying to address. This includes APO, CTV, sidechain
proposals, etc, etc.

Your aggression to your purpose is the antithesis of consensus, as it
indicates your incentives are external to it.

--
John Carvalho
CEO, Synonym.to 


On Mon, May 2, 2022 at 3:43 AM <
bitcoin-dev-requ...@lists.linuxfoundation.org> wrote:

> Send bitcoin-dev mailing list submissions to
> bitcoin-dev@lists.linuxfoundation.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> or, via email, send a message with subject or body 'help' to
> bitcoin-dev-requ...@lists.linuxfoundation.org
>
> You can reach the person managing the list at
> bitcoin-dev-ow...@lists.linuxfoundation.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of bitcoin-dev digest..."
>
>
> Today's Topics:
>
>1. Re: What to do when contentious soft fork activations are
>   attempted (Billy Tetrud)
>2. Working Towards Consensus (Jeremy Rubin)
>
>
> --
>
> Message: 1
> Date: Sun, 1 May 2022 14:14:29 -0500
> From: Billy Tetrud 
> To: alicexbt ,  Bitcoin Protocol Discussion
> 
> Subject: Re: [bitcoin-dev] What to do when contentious soft fork
> activations are attempted
> Message-ID:
> <
> cagppwdb-t4ob0nkv7o5k9yhdqjtmag1qlqm1jjn9fqmontp...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> +1 alicexbt
>
> We of course want knowledgeable bitcoiners who aren't knowledgeable about a
> certain proposal to be skeptical. But what we don't want is for that
> natural skepticism-from-ignorance to be interpreted as opposition, or
> really a strong signal of any kind. Any thoughts from ignorance, whether
> self-aware or not, should be given small weight. It seems the vast majority
> of push back has been this kind of skepticism from ignorance. And to a
> certain degree I think we want to give time for understanding to those who
> have not participated in the first, second, third, etc round of discussion
> on a proposal. It may not be reasonable to say "you had the last 2 years of
> time to voice your concern".
>
> Now that CTV is being taken seriously as a proposal, we probably should
> give the community who is finally taking a serious look at it time to
> understand, get their questions answered, and come to terms with it. This
> is not to say that CTV as a technology or proposal has been rushed, or has
> not had enough work put into it, but rather that the community as a whole
> has not paid enough attention to it for long enough.
>
> The wrong approach is: "how do I yell more loudly next time I see something
> I'm uncomfortable with?" The right approach is to educate those who aren't
> educated on the proposal and gather consensus on what people think when
> they understand enough about it to contribute to that consensus. If you
> care about consensus, you should respect the consensus process and be ok
> with consensus being not your preferred outcome. If you don't