Martin Schwarz [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2015-06-14 to 2021-03-23
💬 Posted a total of 6 messages
📚 Participated in the following categories: bitcoin-dev, Lightning-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-09 12:47:27

- reply

📅 Original date posted:2017-08-17
📝 Original message:
Dear all,
currently the chain_id allows to distinguish blockchains by the hash of
their genesis block.
With hardforks branching off of the Bitcoin blockchain, how can Lightning
work on (or across)
distinct, permanent forks of a parent blockchain that share the same
genesis block?
I suppose changing the definition of chain_id to the hash of the first
block of the new
branch and requiring replay and wipe-out protection should be sufficient.
But can we
relax these requirements? Are slow block times an issue? Can we use
Lightning to transact
on "almost frozen" block chains suffering from a sudden loss of hashpower?
Has there been any previous discussion or study of Lightning in the setting
of hardforks?
(Is this the right place to discuss this? If not, where would be the right
place?)
thanks,
Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20170817/6f4f0ddc/attachment.html>

2023-06-09 12:47:27

- reply

2023-06-07 18:30:57

- reply

📅 Original date posted:2021-03-23
📝 Original message:Erik,
> Does anyone think it would it be useful to write up a more official,
and even partly functional plan for Bitcoin to use zero-knowledge
proofs to transition to quantum resistance?
yes, this would be appreciated very much! Andrew Chow's write-up
gives already some high-level idea, but a more detailed exposition
would be essential for further discussion.
thank you,
Martin
On Mon, Mar 22, 2021 at 3:47 PM Erik Aronesty via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> The argument that hashed public addresses provide meaningful quantum
> resistance is flawed *when considered in the context*.of Bitcoin
> itself.
>
> This article by Andrew Chow is easy to read and makes a strong case
> against the quantum utility of hashed public keys:
>
> https://cryptowords.github.io/why-does-hashing-public-keys-not-actually-provide-any-quantum-resistance
>
> And then, of course, one should be mindful of the case against quantum
> computing itself - it is neither inevitable nor "just around the
> corner". Mikhail Dyakonov summarized the arguments well here:
> https://t.co/cgrfrroTTT?amp=1.
>
> My current stance (at my company at least) is that planning for
> quantum computing should be limited to "a provable and written ability
> to upgrade if it becomes clear that it's necessary."
>
> Does anyone think it would it be useful to write up a more official,
> and even partly functional plan for Bitcoin to use zero-knowledge
> proofs to transition to quantum resistance?
>
> - Erik Aronesty
> CTO, Atkama
>
> On Mon, Mar 15, 2021 at 5:48 PM Luke Dashjr via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >
> > I do not personally see this as a reason to NACK Taproot, but it has
> become
> > clear to me over the past week or so that many others are unaware of this
> > tradeoff, so I am sharing it here to ensure the wider community is aware
> of
> > it and can make their own judgements.
> >
> > Mark Friedenbach explains on his blog:
> > https://freicoin.substack.com/p/why-im-against-taproot
> >
> > In short, Taproot loses an important safety protection against quantum.
> > Note that in all circumstances, Bitcoin is endangered when QC becomes a
> > reality, but pre-Taproot, it is possible for the network to "pause"
> while a
> > full quantum-safe fix is developed, and then resume transacting. With
> Taproot
> > as-is, it could very well become an unrecoverable situation if QC go
> online
> > prior to having a full quantum-safe solution.
> >
> > Also, what I didn't know myself until today, is that we do not actually
> gain
> > anything from this: the features proposed to make use of the raw keys
> being
> > public prior to spending can be implemented with hashed keys as well.
> > It would use significantly more CPU time and bandwidth (between private
> > parties, not on-chain), but there should be no shortage of that for
> anyone
> > running a full node (indeed, CPU time is freed up by Taproot!); at
> worst, it
> > would create an incentive for more people to use their own full node,
> which
> > is a good thing!
> >
> > Despite this, I still don't think it's a reason to NACK Taproot: it
> should be
> > fairly trivial to add a hash on top in an additional softfork and fix
> this.
> >
> > In addition to the points made by Mark, I also want to add two more, in
> > response to Pieter's "you can't claim much security if 37% of the supply
> is
> > at risk" argument. This argument is based in part on the fact that many
> > people reuse Bitcoin invoice addresses.
> >
> > First, so long as we have hash-based addresses as a best practice, we can
> > continue to shrink the percentage of bitcoins affected through social
> efforts
> > discouraging address use. If the standard loses the hash, the situation
> > cannot be improved, and will indeed only get worse.
> >
> > Second, when/if quantum does compromise these coins, so long as they are
> > neglected or abandoned/lost coins (inherent in the current model), it
> can be
> > seen as equivalent to Bitcoin mining. At the end of the day, 37% of
> supply
> > minable by QCs is really no different than 37% minable by ASICs. (We've
> seen
> > far higher %s available for mining obviously.)
> >
> > To conclude, I recommend anyone using Bitcoin to read Mark's article, my
> > thoughts, and any other arguments on the topic; decide if this is a
> concern
> > to you, and make your own post(s) accordingly. Mark has conceded the
> argument
> > (AFAIK he doesn't have an interest in bitcoins anyway), and I do not
> consider
> > it a showstopper - so if anyone else out there does, please make yourself
> > known ASAP since Taproot has already moved on to the activation phase
> and it
> > is likely software will be released within the next month or two as
> things
> > stand.
> >
> > Luke
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210323/d5592b95/attachment-0001.html>

2023-06-07 18:20:37

- reply

📅 Original date posted:2019-09-19
📝 Original message:Isn't there some way to "rebase" a relative lock-time to some anchor even
further in the past while cancelling out the intermediate transactions?
best regards,
Martin
On Thu, Sep 19, 2019 at 9:52 AM ZmnSCPxj via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Good morning list,
>
> I was reading transcript of recent talk:
> https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/edgedevplusplus/blockchain-design-patterns/
>
> And in section "Taproot: main idea":
>
> > Q: Can you do timelocks iwth adaptor signatures?
> >
> > ...
> >
> > A: This is one way it's being proposed by mimblewimble; but this
> requires the ability to aggregate signatures across transactions.
> >
> > Q: No, there's two transactions already existing. Before locktime, you
> can spend wit hthe adaptor signature one like atomic swaps. After locktime,
> the other one becomes valid and you can spend with that. They just double
> spend each other.
> >
> > A: You'd have to diagram that out for me. There's a few ways to do this,
> some that I know, but yours isn't one of them.
>
> I believe what is being referred to here is to simply have an `nLockTime`
> transaction that is signed by all participants first, and serves as the
> "timelock" path.
> Then, another transaction is created, for which adaptor signatures are
> given, before completing the ritual to create a "hashlock" path.
>
> I find it surprising that this is not well-known.
> I describe it here tangentially, for instance:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-April/016888.html
> The section "Payjoin2swap Swap Protocol" refers to "pre-swap transaction"
> and "pre-swap backout transaction", which are `nLockTime`d transactions.
> Later transactions then use a Scriptless Script-like construction to
> transfer information about a secret scalar x.
>
> My understanding of MimbleWimble is that:
>
> * There must exist a proof-of-knowledge of the sum of blinding factors
> used.
> This can be trivially had by using a signature of this sum, signing an
> empty message or "kernel".
> * I believe I have seen at least one proposal (I cannot find it again now)
> where the "kernel" is replaced with an `nLockTime`-equivalent.
> Basically, the `nLockTime` would have to be explicitly published, and it
> would be rejected for a block if the `nLockTime` was less than the block
> height.
> * There may or may not exist some kind of proof where the message being
> signed is an integer that is known to be no greater than a particular
> value, and multiple signatures that signed a lower value can somehow be
> aggregated to a higher value, which serves this purpose as well, but is
> compressible.
>
> My understanding is thus that the above `nLockTime` technique is what is
> indeed intended for MimbleWimble cross-system atomic swaps.
>
> --------
>
> However, I believe that Lightning and similar offchain protocols are **not
> possible** on MimbleWimble, at least if we want to retain its "magical
> shrinking blockchain" property.
>
> All practical channel constructions with indefinite lifetime require the
> use of *relative* locktime.
> Of note is that `nLockTime` represents an *absolute* lifetime.
>
> The only practical channel constructions I know of that do not require
> *relative* locktime (mostly various variants of Spilman channels) have a
> fixed lifetime, i.e. the channel will have to be closed before the lifetime
> arrives.
> This is impractical for a scaling network.
>
> It seems to me that some kind of "timeout" is always necessary, similar to
> the timeout used in SPV-proof sidechains, in order to allow an existing
> claimed-latest-state to be proven as not-actually-latest.
>
> * In Poon-Dryja, knowledge of the revocation key by the other side proves
> the published claimed-latest-state is not-actually-latest and awards the
> entire amount to the other party.
> * This key can only be presented during the timeout, a security
> parameter.
> * In Decker-Wattenhofer decrementing-`nSequence` channels, a kickoff
> starts this timeout, and only the smallest-timeout state gets onchain, due
> to it having a time advantage over all other versions.
> * In indefinite-lifetime Spilman channels (also described in the
> Decker-Wattenhofer paper), the absolute-timelock initial backoff
> transaction is replaced with a kickoff + relative-locktime transaction.
> * In Decker-Russell-Osuntokun, each update transaction has an imposed
> `nSequence` that forces a state transaction to be delayed compared to the
> update transaction it is paired with.
>
> It seems that all practical offchain updateable cryptocurrency systems,
> some kind of "timeout" is needed during which participants have an
> opportunity to claim an alternative version of some previous claim of
> correct state.
>
> This timeout could be implemented as either relative or absolute lock
> time, but obviously an absolute locktime would create a limit on the
> lifetime of the channel.
> Thus, if we were to target an indefinite-lifetime channel, we must use
> relative lock times, with the timeout starting only when the unilateral
> close is initiated by one participant.
>
> Now, let us turn back to the MimbleWimble.
> As it happens, we do *not* actually need SCRIPT to implement these
> offchain updateable cryptocurrency systems.
> 2-of-2 is often enough (and with Schnorr and other homomorphic signatures,
> this is possible without explicit script, only pubkeys and signatures,
> which MimbleWimble supports).
>
> * Poon-Dryja revocation can be rewritten as an HTLC-like construct (indeed
> this was the original formulation).
> * Since we have shown that, by use of two transaction alternatives, one
> timelocked and the other hashlocked, we can implement an HTLC-like
> construct on MimbleWimble, that is enough.
> * Relative locktimes in Decker-Wattenhofer are imposed by simple
> `nSequence`, not by `OP_CSV`.
> HTLCs hosted inside such constructions can again use the
> two-transactions construct in MimbleWimble.
> * Ditto with indefinite-lifetime Spilman.
> * Ditto with Decker-Russell-Osuntokun.
> * The paper shows the use of `OP_CSV`, but aj notes it is redundant, and
> I agree:
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-March/001933.html
>
> Thus, it is not the "nonexistence of SCRIPT" that prevents Lightning from
> being deployed on MimbleWimble.
>
> Instead, it is the "nonexistence of **relative** locktime" that prevents
> Lightning over MimbleWimble.
>
> Why would **relative** locktimes not possibly exist?
> In order to **validate** a relative locktime, we need to know the
> blockheight that the output we are spending was confirmed in.
>
> But the entire point of the "magical shrinking blockchain" is that
> already-spent outputs can be removed completely and all that needs to be
> validated by a new node is:
>
> * The coin-creation events.
> * The current UTXO set (plus attached rangeproofs).
> * The blinding keys.
> * Signatures of the blinding keys, and the kernels they sign (if we use
> the "kernels encode `nLockTime`" technique in some way, they should not
> exceed the current supposed blockheight).
>
> The problem is that an output that exists in the UTXO set might be
> invalid, if it appears "too near" to an `nSequence` minimum spend of a
> previous output that was spent in its creation.
> That is, the above does not allow validation of **relative** locktimes,
> only **absolute locktimes**.
> (At least as far as I understand: there may be special cryptographic
> constructs that allow signatures to reliably commit to some relative
> locktime).
>
> This means that relative locktimes need to be implemented by showing the
> transactions that spend previous UTXOS and create the current UTXOs, and so
> no backwards to coin-creation events.
> This forces us back to the old "validate all transactions" model of
> starting a new node (and seriously damaging the entire point of using
> MimbleWimble anyway).
>
> I do not believe it is the lack of SCRIPT that prevents
> Lightning-over-MimbleWimble, but rather the lack of relative locktime,
> which seems difficult to validate without knowing the individual
> transactions and when they were confirmed.
>
> Regards,
> ZmnSCPxj
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190919/28cb2694/attachment.html>

2023-06-07 15:39:40

- reply

📅 Original date posted:2015-06-22
📝 Original message:Gavin,
in 2022 your proposal (BIP as well as code) crosses the 32MB maximum
message size limit. In order to avoid deployment of code that deterministically
fails fatally in 2022, I'd propose to stop the doublings at 32MB for now and fix
the message size limit in the mean time. Since the message size fix requires
a 2nd hard fork anyway, your current 8GB limit could be re-instateted in that
2nd fork as well. Even if you disagree, I'd suggest to address the topic in the BIP.
best regards,
Martin

2023-06-07 15:37:45

- reply

📅 Original date posted:2015-06-14
📝 Original message:Pieter,
Am 13.06.2015 um 16:39 schrieb Pieter Wuille:
> We can reasonably assume that different people's wallet will tend to be distributed uniformly over several sidechains to hold their transactions (if they're not, there is no scaling benefit anyway...). That means that for an average transaction, you will need a cross-chain transfer in order to get the money to the recipient (as their wallet will usually be associated to a chain that is different from your own).
I think we should set the right incentives to invalidate these assumptions. If the fees as well as the security guarantees
on the main chain are highest and fees are dropping with the distance from the main chain on each level of side chains,
wouldn't communities with many internal transactions create their own side chain with low fees? I'd expect geographic
as well as virtual communities to be forming enjoying cheap fees on their 'local' chains and expensive but comparabily rare
'long distance' fees. One would expect geographic chains (e.g. continents) as well as virtual ones (e.g. the Open Bazaar
users' chain) to form. To save fees, a typical user would maintain a wallet in each of her communities which are loaded
and drained with rare expensive transacations, whereas daily business with many transactions is done cheaply within
each community chain. So, indeed, I would argue that side chains equipped with the right cost incentives for cross-chain
transactions would lead to a scalable and efficiently self-organizing network of side chains.
best regards,
Martin