Thanks, this is good feedback.
I think the main thing then to add to forkd would be some sort of seed
nodes set that you can peer with of other forkd runners? And have forkd be
responsible for making sure you addnode them?
wrt the generation of other problems, my understanding of the *summons
>
>
> I would comment on this point, but I'm not sure I'm "technical enough". I
> have to admit: I've never played tennis.
>
You are technicial enough to read the nacks... everyone is:
https://github.com/JeremyRubin/utxos.org/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc
I can give a summary
Jeremy
> The reason there was not a mailing list post is because that's not a
> committed plan, it was offered up for discussion to a public working group
> for feedback as a potential plan.
In the interests of posterity from your personal blog on April 17th [1]:
"Within a week from today,
- it occurs to me that the real problem we have isn't whether miners lead
or users lead. we know that users lead, we just need miners to be "ready"
and have time to upgrade their software
- in the case of "evil" forks, i also don't need or want miners to
"defend" bitcoin... (if bitcoin is so
On Mon, Apr 25, 2022 at 10:48:20PM -0700, Jeremy Rubin via bitcoin-dev wrote:
> Further, you're representing the state of affairs as if there's a great
> need to scramble to generate software for this, whereas there already are
> scripts to support a URSF that work with the source code I pointed
On Fri, Apr 22, 2022 at 7: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
> can make an informed view on
> > i doubt CTV is necessary nor sufficient for this
> I would be interested to hear more on this.
A lot of people have been conflating vaults and covenants, especially lately. I
believe we should
differentiate more Bitcoin vaults, a scheme that defines a "staged transaction
process" [0], and
"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
I'm a bit confused here. The "personal blog" in question was sent to this
list with an archive link and you saw an replied to it.
The proposal to make an alternative path hadn't gotten buy in sufficient
from those iterating, and given the propensity of people to blow things out
of proportion in
I can't find all of my earlier references around this, I thought I made a
thread on it, but as a reminder, my thoughts for mild tweaks to APO that
make it a bit less hacky are as follows:
- Remove OP_1 key punning and replace it with OP_GENERATOR and
OP_INTERNALKEY (maybe OP_EXTERNALKEY too?).
Hi all,
Alongside the debate with CTV right now there's a second debate that was
not fully hashed out in the activation of Taproot. There is a lot of
argument around what Speedy Trial is or isn't, what BIP8 T/F is or isn't
etc. A significant reason for the breakdown in civility around this debate
You may be interested in these posts on transaction signalling:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/014193.html
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/014202.html
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014251.html
12 matches
Mail list logo
