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 wi
<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
ments 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
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 child
ess on it I'm happy to help point people
to specific tasks that need to be done 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
--
@JeremyR
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 w
HTLCS.
--
@JeremyRubin <https://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 c
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
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 place
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)
>
> 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 do
w a certain % of liquidity to be moved 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>
_
yRubin>
<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,
nt of data 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
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
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 ha
t
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
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 protocol
not allow dust 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/J
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
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.
>
&
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
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
maintenan
st 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
pap
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
https
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, tr
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 can
ll 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 an
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 u
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 expensiv
would 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
bes miners
-- potentially even retroactively after a block is formed. 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 &l
on quantifying 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 sha
to other bitcoin
> transactions, 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?
t from your proposal.
> All the 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 is
8/given-op-ver-was-never-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 proposal
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*
precommitted
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,
J
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 meeting i
well.
Protocols which 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, 2
ees overall, since the undoing of your later 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
--
@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 attac
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*
precommitted
to CPFP, you would 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
> 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 confuse
ren't looking for
linearization, then the new linearization won't 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
d, but I'm
merely here to inspire and figured the idea of 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
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 an
48 matches
Mail list logo
