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
f abstracting the ratchet was
novel.
Best,
Jeremy
--
@JeremyRubin <https://twitter.com/JeremyRubin>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
be a breaking change for
old clients, just calendar servers. And new clients can benefit from
linearization.
--
@JeremyRubin <https://twitter.com/JeremyRubin>
On Fri, Apr 15, 2022 at 7:52 AM Peter Todd wrote:
> On Mon, Apr 11, 2022 at 09:18:10AM -0400, Jeremy Rubin wrote:
> > >
> nonsense marketing
I'm sure the people who are confused about "blockchain schemes as \"world
computers\" and other nonsense
marketing" are avid and regular readers of the bitcoin devs mailing list so
I offer my sincerest apologies to all members of the intersection of those
sets who were
uld need a separate output just for CPFPing
that is not subject to these restrictions, or some sort of RBF-able addable
input/output. Or, Sponsors.
Jeremy
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
opt-in or explicit tagging of fee account is a bad design IMO.
As pointed out by James O'Beirne in the other email, having an explicit key
required means you have to pre-plan suppose you're building a vault
meant to distribute funds over many years, do you really want a *specific*
--
@JeremyRubin <https://twitter.com/JeremyRubin>
On Sat, Feb 19, 2022 at 1:39 AM Peter Todd wrote:
> On Fri, Feb 18, 2022 at 04:38:27PM -0800, Jeremy Rubin wrote:
> > > As I said, it's a new kind of pinning attack, distinct from other types
> > of pinning attack.
opt-in or explicit tagging of fee account is a bad design IMO.
As pointed out by James O'Beirne in the other email, having an explicit key
required means you have to pre-plan suppose you're building a vault
meant to distribute funds over many years, do you really want a *specific*
ater RBF surely returned some
satoshis to your wallet.
Best,
Jeremy
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
ich depend on in mempool replacements before confirmation
already must be happy (should they be secure) with any prior state being
mined. If a third party pays the fee you might even be happier since the
execution wasn't on your dime.
Cheers,
Jeremy
On Wed, Feb 9, 2022, 10:59 PM Peter Todd via b
Reminder:
This is in ~24 hours.
There have been no requests to add content to the agenda.
Best,
Jeremy
--
@JeremyRubin <https://twitter.com/JeremyRubin>
On Wed, Feb 2, 2022 at 12:29 PM Jeremy Rubin
wrote:
> Bitcoin Developers,
>
> The 3rd instance of the recurring meeti
in advance of the meeting to make the best use of everyone's time.
Please send me any feedback, proposed topic changes, additions, or
questions you would like to pre-register on the agenda.
I will send a reminder to this list with a finalized Agenda in advance of
the meeting.
Best,
Jeremy
ever-used-is-disabled-and-not-considered-useful-can-its-meani>?
> Is that related to your fee account idea?
>
>
> On Wed, Jan 19, 2022 at 1:32 AM Jeremy wrote:
>
>> Ah my bad i misread what you were saying as being about SIGHASH_BUNDLE
>> like proposals.
>>
>&
problems of fee revenue optimization and feerate rules that you
> mentioned seem like they'd also exist for your proposal, or for cpfp. Let
> me know if I should clarify further.
>
> On Tue, Jan 18, 2022 at 8:51 PM Jeremy wrote:
>
>> The issue with sighash flags is that because y
ansactions, and no special account would need to be created. Any
> transaction could specify this. At least that's the first thought I would
> have in designing a way to arbitrarily bump fees. Have you compared your
> solution to something more familiar like that?
>
> On Tue, Jan 18,
fying how much this would
> improve the situation vs existing methods (eg cpfp)?
>
>
>
> On Sat, Jan 1, 2022 at 2:04 PM Jeremy via bitcoin-dev <
> bitcoin-...@lists.linuxfoundation.org> wrote:
>
>> Happy new years devs,
>>
>> I figured I would share some th
That might be
sufficient to prove the concept works before a consensus upgrade is
deployed, but such an approach does mean there is a centralizing layer
interfering with normal mining.
Happy new year!!
Jeremy
--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRu
make channel opening much more efficient, especially when paired with
the payment pool concept shared the other day.
Best,
Jeremy
--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>
___
Lightning-dev
IMO this is not a big problem. The problem is not if a 0 value ever enters
the mempool, it's if it is never spent. And even if C2/P1 goes in, C1 still
can be spent. In fact, it increases it's feerate with P1's confirmation so
it's somewhat likely it would go in. C2 further has to be pretty
Bastien,
The issue is that with Decker Channels you either use SIGHASH_ALL / APO and
don't allow adding outs (this protects against certain RBF pinning on the
root with bloated wtxid data) and have anchor outputs or you do allow them
and then are RBF pinnable (but can have change).
Assuming you
as things like spacechains.
Such a rule -- if it's not clear -- presupposes a fully working package
relay system.
I believe that this addresses all the issues with allowing 0 value outputs
to be created for the narrow case of immediately spendable outputs.
Cheers,
Jeremy
p.s. why another post
Hi zmnscpxj,
>
>> Just a minor curiosity I figured was worth mentioning on the composition
of delegations and anyprevout...
>>
>> DA: Let full delegation be a script S such that I can sign script R and
then R may sign for a transaction T.
>> DB: Let partial delegation be a script S such that I
Just a minor curiosity I figured was worth mentioning on the composition of
delegations and anyprevout...
DA: Let full delegation be a script S such that I can sign script R and
then R may sign for a transaction T.
DB: Let partial delegation be a script S such that I can sign a tuple
(script R,
John let me know that he's posted some responses in his Github repo
https://github.com/JohnLaw2/btc-iids
probably easiest to respond to him via e.g. a github issue or something.
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
post to the mailing list without
compromising their identity (perhaps we should publish a guideline on how
to do so?).
Best,
Jeremy
Hi,
I'd like to propose an alternative to BIP-118 [1] that is both safer and
more
powerful. The proposal is called Inherited IDs (IIDs) and is described in a
paper that
one interesting point that came up at the bitdevs in austin today that
favors remove that i believe is new to this discussion (it was new to me):
the argument can be reduced to:
- dust limit is a per-node relay policy.
- it is rational for miners to mine dust outputs given their cost of
You might be interested in https://eprint.iacr.org/2017/1066.pdf which
claims that you can make CT computationally hiding and binding, see section
4.6.
with respect to utreexo, you might review
https://github.com/mit-dci/utreexo/discussions/249?sort=new which discusses
tradeoffs between different
some additional answers/clarifications
> Question for Jeremy: would you also allow zero-value outputs? Or would
> you just move the dust limit down to a fixed 1-sat?
>
I would remove it entirely -- i don't think there's a difference between
the two realistically.
>
> Allowi
Under no circumstances do I think we should *increase* the dust limit. That
would have a mildly confiscatory effect on current Lightning Channel
operators, among others.
Generally, the UTXO set will grow. We should work to accommodate the worst
case scenario under current consensus rules. I think
creation is that:
1) dust is spam
2) dust fingerprinting attacks
1 is (IMO) not valid given the 5 reasons above, and 2 is preventable by
well behaved wallets to not redeem outputs that cost more in fees than they
are worth.
cheers,
jeremy
--
@JeremyRubin <https://twitter.com/JeremyRubin>
Just my 2 cents:
I think worrying about the size of a resolution during a contested close
scenario (too much) is not worth it. Encoding the state needed (e.g., in
op_return or whatever) is the safest option because then you guarantee the
availability of the closing transaction data in the
the relevant data for what PK_si signed off on.
--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>
On Mon, Jul 12, 2021 at 3:16 PM Jeremy wrote:
> Without an exact implementation, one thing you could do to fix the lost
> state issue would be t
Without an exact implementation, one thing you could do to fix the lost
state issue would be to make the scripts something like:
[` CLTV DROP PKu CHECKSIGVERIFY GETLOCKTIME
BIP32DERIVE CHECKTRANSACTIONSIGNEDFROMSTACK`, `2016 CSV DROP PK_si
CHECKSIG`]
In order to upgrade to state M>= N+1 you'd
On Sun, Jul 11, 2021 at 10:01 PM Anthony Towns wrote:
> On Thu, Jul 08, 2021 at 08:48:14AM -0700, Jeremy wrote:
> > This would disallow using a relative locktime and an absolute
> locktime
> > for the same input. I don't think I've seen a use case for that so
> fa
for the script
leaves may only gets you 5 bits of added sequence space.
--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>
On Sat, Jul 10, 2021 at 4:25 PM Jeremy wrote:
> on further reflection, i think you can get around the restriction of CSV
&g
myRubin>
<https://twitter.com/JeremyRubin>
On Sat, Jul 10, 2021 at 2:07 PM Jeremy wrote:
> Let's say you're about to hit your sequence limits on a Eltoo channel...
> Do you have to go on chain?
>
> No, you could do a continuation where for your *final* update, you sign a
>
ved during a burst -- e.g.,
any time the delta in balance goes above a threshold, force a higher order
channel state update.
Best,
Jeremy
--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>
___
Lightnin
>
> This would disallow using a relative locktime and an absolute locktime
> for the same input. I don't think I've seen a use case for that so far,
> but ruling it out seems suboptimal.
I think you meant disallowing a relative locktime and a sequence locktime?
I agree it is suboptimal.
What
I made a comment on
https://github.com/bitcoin/bips/pull/943#issuecomment-876034559 but it
occurred to me it is more ML appropriate.
In general, one thing that strikes me is that when anyprevout is used for
eltoo you're generally doing a script like:
```
IF
10 CSV DROP
1::musigkey(As,Bs)
I'd be excited to join. Recommend bumping the date to mid June, if that's
ok, as many Americans will be at Bitcoin 2021.
I was thinking about reviving the sponsors proposal with a 100 block lock
on spending a sponsoring tx which would hopefully make less controversial,
this would be a great
s though :).
--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>
On Sun, Jun 21, 2020 at 6:20 PM Olaoluwa Osuntokun
wrote:
> Hi Jeremy,
>
> The up-front costs can be further mitigated even without something like CTV
> (which makes things more efficient) b
tps://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>
On Sat, Jun 20, 2020 at 8:34 PM ZmnSCPxj wrote:
> Good morning Jeremy,
>
> > I am not steeped enough in Lightning Protocol issues to get the full
> design space, but I'm fairly certain BIP-119 Congestion
I am not steeped enough in Lightning Protocol issues to get the full design
space, but I'm fairly certain BIP-119 Congestion Control trees would help
with this issue.
You can bucket a tree by doing a histogram of HTLC size, so that all small
HTLCs live in a common CTV subtree and don't interfere
ne in order to accelerate this and help
serialize the work so that we can not get into rebase hell.
Originally I had the plug at the top as a closing note, but I figured
people might miss it.
Best,
Jeremy
--
@JeremyRubin <https://twitter.com/JeremyRubin>
Johan,
The issues with mempool limits for OP_SECURETHEBAG are related, but have
distinct solutions.
There are two main categories of mempool issues at stake. One is relay
cost, the other is mempool walking.
In terms of relay cost, if an ancestor can be replaced, it will invalidate
all it's
the elements on the stack and compare to a known hash.
How is that sort of thing weak to midstateattacks?
--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>
On Fri, Oct 4, 2019 at 4:16 AM Peter Todd wrote:
> On Thu, Oct 03, 2019 at 10:02:14PM -0700, J
<https://twitter.com/JeremyRubin>
On Fri, Oct 4, 2019 at 12:00 AM ZmnSCPxj via Lightning-dev <
lightning-dev@lists.linuxfoundation.org> wrote:
> Good morning Jeremy,
>
> > Awhile back, Ethan and I discussed having, rather than OP_CAT, an
> OP_SHA256STREAM that uses the
Awhile back, Ethan and I discussed having, rather than OP_CAT, an
OP_SHA256STREAM that uses the streaming properties of a SHA256 hash
function to allow concatenation of an unlimited amount of data, provided
the only use is to hash it.
You can then use it perhaps as follows:
// start a new hash
48 matches
Mail list logo
