Good morning David,
> Currently, bitcoin must be redeemed by providing input to a script which
> results in the required output. This causes the attached amount of bitcoin
> to become available for use in the outputs of a transaction. Is there any
> work on creating a shorter "transaction"
Good morning M,
> > > Nodes reject announced blocks that:
> > >
> > > * include transactions that are in contest with any in their mempool
> > > * include transactions that are in contest with any in the contest pool
> >
> > Is this intended to be a consensus rule, i.e. nodes will never accept
Good morning Antoine,
> > On mutual closes, we should probably set `nLockTime` to the current
> > blockheight + 1 as well.
> > This has greater benefit later in a Taproot world.
>
> I assume mutual closes would fall under the aforementioned tx construction
> proposal, so a closing may be a
Good morning LL,
Thank you very much for this work, it seems quite interesting.
> 5. You can completely circumvent this result by using coin-tossing rather
> than MuSig for the key generation protocol. In most cases this doesn't even
> add any extra rounds of communication since you are doing
Good morning Stepan,
> This topic appeared in the list a few times so I would like to discuss it in
> more detail and maybe push forward to standardization.
>
> We have to accept that any hardware wallet or an air-gapped computer we use
> to sign transactions can be compromised. It may happen
Good morning Christopher,
>
> > As a replacement for paper, something like this makes sense v.s. what you
> > do with a ledger presently.
> >
> > However, shamir's shares notoriously have the issue that the key does exist
> > plaintext on a device at some point.
> >
> > Non-interactive multisig
Good morning list,
A few more things to consider:
Probably the correct order for this would be for the payer to instantiate the
Scriptless Script payment to the payee first, then the payee instantiating the
change back to the payer.
By use of some kind of Scriptless Script, it is possible to
Good morning list,
During LNConf 2019, Jack Mallers presented about hedging of onchain fees, which
he argues is necessary in order to have a smooth experience interfacing between
onchain and offchain (in particular, when closing and opening channels).
The exact mechanism proposed was to
Good morning David,
> On Fri, Jan 31, 2020 at 03:42:08AM +0000, ZmnSCPxj via bitcoin-dev wrote:
>
> > Let me then propose a specific mechanism for feerate insurance against
> > onchain feerate spikes.
> > [...]
> > At current blockheight B, Alice an
Good morning M,
What do you mean by this?
> Nodes reject announced blocks that:
>
> * include transactions that are in contest with any in their mempool
> * include transactions that are in contest with any in the contest pool
Is this intended to be a consensus rule, i.e. nodes will never
Good morning The Group,
There are already many excellent arguments presented for Taproot, let me
present a related one.
Notice your example MAST:
>
> /\
> / \
> / \
> / \
> /\ /\
> / \ / \
> /\ /\ /\ /\
> a b c d e f g h
Of particular note is that
Good morning M,
> I don't see how the scenario you outline here has anything to do with the
> mechanism I proposed. An empty block doesn't contain any transactions (by
> definition) so it wont contest any transactions in any given node's mempool.
> The aim isn't to prevent empty nodes, it's
Ggood morning Antoine, and list,
> * nLocktime/nSequence
> ...
> * weird watermark (LN commitment tx obfuscated commitment number)
> ...
> LN (cooperative case):
I notice your post puts little spotlight on unilateral cases.
A thing to note, is that we only use `nSequence` and the weird
Good morning waxwing,
> ‐‐‐ Original Message ‐‐‐
> On Friday, 21 February 2020 22:17, Antoine Riard via bitcoin-dev
> bitcoin-dev@lists.linuxfoundation.org wrote:
>
> > How can a Bitcoin tranaction leak protocol usage ?
> >
> > - the output type (p2sh, p2wsh, ...)
> > - the spending
Good morning Dmitry, and Jeremy,
> There is a principle that some find valuable: "During reorgs of depth
> less than 100, it is always possible to eventually replay transactions
> from the old branch into the new branch as long as no double spends are
> attempted" (quoted from Russel O'Connor
Good morning Robin,
> Good morning ZmnSCPxj,
>
> Thank you for your detailed feedback! Two topics:
>
> Lightning vs Sidechains
>
>
>
> Why an either-or-solution, if we can connect sidechains via the LN to get the
> best of both worlds?
>
> The LN works exceptionally
Good morning Robin,
> Good morning everybody!
>
> Thanks again for your detailed feedback.
>
> Maybe you're right and my solution is just crap :) So back to the drafting
> table!
>
> It seems to be a good idea to separate problem definition and solution. Here
> I tried to nail down LN's
Good morning Max,
It seems similar very closely to TumbleBit, at least in the overall protocol.
A cursory read does not reveal any direct problems with it.
Regards,
ZmnSCPxj
> Hello all!
>
> May I propose you this protocol which seemingly provides a great level
> of privacy for both the sender
As well I would like to point out that in order to receive funds, *something*
has to be online to get the message that receives the data.
In the blockchain layer this is diffused among all fullnodes.
At the Lightning layer, your direct peer could hold off on failing an incoming
payment while
Good morning Robin,
> Hi Joachim,
>
> > > Regarding Reason #1:
> > > This proposal is less like Bitcoin vs. Altcoins and much more like
> > > Ethereum vs. ERC20 tokens, because the derivatives are not in competition
> > > with BTC, but depend on it heavily. You support Bitcoin's growth by
> >
Good morning Robin,
> Hi Joachim,
>
> > if anyone can halt operation of a sidechain with just tiny investment.
>
> It'll be impossible to halt a healthy chain with a tiny investment because
> halting a chain costs you at least as much as the side chain rewards. The
> "invested time value per
Good morning list,
[On a recent post on
lightning-dev](https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-January/002431.html),
I brought up the possibility of using a circular self-payment to hide the
actual direction of payment from third-party snooping nodes.
Basically, instead
Good morning Robin,
> > because all users must process all transactions within the blockchain
>
> Reality shows, that's wrong. Bitcoin's security doesn't require verification
> to scale quadratically with users. Since the whitepaper, Satoshi was explicit
> about that phenomena. We can discuss
Good morning Yuval,
> Additionally (though is a broader criticism of CoinJoin based privacy and not
> specific to unequal amounts, and in particular refers to ZmnSCPxj's assertion
> of 0 linkability) I am very worried that perspectives that focus on
> linkability information revealed by a
Good morning Bob,
> Note that this attack requires collaboration with the current UTXO owner.
> Generally if there's some form of address/payment request, the current holder
> is
> trying to transfer the UXTO to some other (non-statechain) entity, and he
> knows
> the target of the transfer,
Good morning Tom,
>
> We are starting to work on an implementation of the statechains concept
> (https://medium.com/@RubenSomsen/statechains-non-custodial-off-chain-bitcoin-transfer-1ae4845a4a39),
> with particular interest in using the protocol enable the change of
> ownership (novation) of
Good morning Andrew,
>
> > Anyway, yes, your idea is fundamentally broken because a zero block reward
> > happens because creating even one more satoshi will push the amount of
> > bitcoin over 21,000,, breaking the meaning of "bitcoin," or, if you
> > like, creating a fundamental
Good morning Ruben,
> Hey Christian,
>
> Thanks for chiming in :)
>
> >It might be worth adopting the late fee binding we have in eltoo
>
> That is where my thinking originally went as well, but then I remembered that
> this alters the txid, causing the settlement tx to become invalid. What I am
Good morning Ruben,
> >The broadcasting of the kickoff simply means that the first stage cannot be
> >easily changed
>
> I see what you're saying. Yeah, it does ruin the stages. If the kickoff tx
> hits the chain, you'd probably just want to "refresh" the UTXO by agreeing
> with the
Good morning Andrew,
> Here's a better explanation than I could write of the phenomenon I'm talking
> about:
>
> > As a thought experiment, let’s consider aquaculture (fish farming) in a
> > lake.
> > Imagine a lake with a thousand identical fish farms owned by a thousand
> > competing
Good morning Bob,
> Big picture, it seems to me this idea is workable and very interesting. I see
> three likely enhancements that will be necessary or desirable:
> 1. Atomic swap of multiple UTXOs, and binary decomposition of value in lots
> 2. Key exchange ("addresses") to facilitate a secure
Good morning Andrew,
Another thing I did not consider is how miners will actually behave under this
ruleset.
Miners are the direct beneficiaries of any increased inflation rate voted in.
Miners are also ultimately the ones who decide which transactions get added
into blocks, or put another
Good morning Ruben,
> Hi ZmnSCPxj,
>
> > the current owner can ask the statechain entity to sign an alternative to
> > the first stage, with 0 relative locktime
>
> Unless I am misunderstanding something, this seems to run into the problem
> that the original first stage transaction is already
Good morning Andrew,
> > Fortunately in our case, only the top 4,000,000 weight worth of transactions
> > gets in a block. Every bitcoin spender has an incentive to spend as little
> > as possible to get into this top 4,000,000 weight and no more, but they
> > still
> > have to outbid every
Good morning Germán,
> With regards to trying to tackle the problem of value-based correlations,
> wouldn't it be possible to try to model the solution after the
> equal-sum-subset problem (np complete problem)(
>
Good morning lists et al,
Let me try to summarize things a little:
* Suppose we have a forwarding payment A->B->C.
* Suppose B does not want to maintain a mempool and is running in `blocksonly`
mode to reduce operational costs.
* C triggers B somehow dropping the B<->C channel, such as by
Good morning Matt, and list,
> RBF Pinning HTLC Transactions (aka "Oh, wait, I can steal funds, how,
> now?")
> =
>
> You'll note that in the discussion of RBF pinning we were pretty broad,
> and that that discussion seems to in fact cover
> our
lock branch.
* No mempool rule changes needed, can be done with the P2P network of today.
* Probably still resilient even with future changes in mempool rules, as long
as typical RBF behaviors still remain.
Is my understanding correct?
Regards,
ZmnSCPxj
>
> -- Laolu
>
> On Tue, Ap
Good morning Matt,
> > - C directly contacts miners with an out-of-band proposal to replace its
> > transaction with an alternative that is much smaller and has a low fee, but
> > much better feerate.
>
> Or they can just wait. For example in today’s mempool it would not be strange
> for a
Good morning David,
Unfortunately this technique does not look like it is compatible to payment
points rather than hashes, and we would really like to upgrade to payment
points sooner rather than later.
Nobody but B can recognize the signature as revealing the scalar behind a
particular
Good morning CB,
> > This "as long as the inputs that should be separate are not co-spent" is
> > precisely what mixdepths protect against, which is why I think some kind of
> > mixdepth facility will still matter in CoinSwap.
> > Still, you have convinced me that, for the purpose of
Good morning CB,
> Chain analysis doesn't in fact know that 1-input-1-output transfers are
> self-transfers, this is merely a heuristic that can be flawed. For
> example I accept donations in bitcoin and a surprising number of them
> are 1-input-1-output or multi-input-1-output, presumably the
Good morning CB,
I have been thinking about CoinSwap for a good while as well.
Here are some very unorganized thoughts.
It wold be nice to interoperate with JoinMarket, i.e. have a JoinMarket maker
that also provides CoinSwap services using the same UTXOs.
However, this requires us to retain
Good morning CB,
> Equal-output-coinjoins and JoinMarket also have a version of the
> common-input-ownership-heuristic (CIOH), because its often possible to
> separate the inputs into sets of their owners of a equal-output-coinjoin
> using the input amounts. CoinSwap can be combined with
Good morning Germán,
It looks to me like this is CoinSwap with Schnorr Scriptless Scripts.
* https://joinmarket.me/blog/blog/coinswaps/
* https://joinmarket.me/blog/blog/flipping-the-scriptless-script-on-schnorr/
I also recently put up an article on extending such a protocol across 3 or more
Good morning Ruben,
> Hi ZmnSCPxj,
>
> Thanks for your feedback :)
>
> > CoinSwap for privacy is practically a "cross" chain atomic swap with the
> > same chain and token for both sides of the swap
>
> I agree, I didn't mean to imply that was new, only that this protocol
> makes it more
Good morning Ruben,
> >If the shortened refund transaction exists (labeled "refund transaction #1"
> >in the SVG) then the same issue still occurs
>
> Yes, but there is one crucial difference: at that point in the protocol (Bob
> has the success transaction and then stops cooperating) Alice
Good morning Ruben,
> Hi ZmnSCPxj,
>
> >potentially both Alice and Bob know all the secrets on the LTC side and end
> >up competing over it
>
> That's exactly right.
>
> >Bob can thus give a copy of the revoke tx with signature directly to its
> >favorite miner, forcing Alice to take 3
Good morning Ruben,
> >Would this not work?
>
> I considered and rejected that model for the following reason: there are
> moments where both Alice and Bob can claim the BTC. If they both attempt to
> do so, it also reveals both secrets, causing the LTC to also be claimable by
> both parties.
Good morning Richard,
> Thanks for sharing your thoughts ZmnSCPxj. I think I can summarize your
> concern as: A node without direct internet connectivity can not rely on an
> opportunistically incentivized local network peer for blockchain information
> because the off-grid node's direct LN
Good morning ariard and luke-jr
> > Trust-minimization of Bitcoin security model has always relied first and
> > above on running a full-node. This current paradigm may be shifted by LN
> > where fast, affordable, confidential, censorship-resistant payment services
> > may attract a lot of
Good morning Richard, and all,
> 2) a light client can query an ISP connected full node on the same unmetered
> local WiFi network and exchange differences in block headers
> opportunistically or pay for large missing ranges of headers, filters or full
> blocks using a payment channel. Cost
Good morning Ruben,
CoinSwap for privacy is practically a "cross" chain atomic swap with the same
chain and token for both sides of the swap, see also this set of ideas:
https://github.com/AdamISZ/CoinSwapCS/issues/53
"Instead, Bob simply hands secretBob to Alice" is basically the same as
Good morning Antoine,
> While approaching this question, I think you should consider economic weight
> of nodes in evaluating miner consensus-hijack success. Even if you expect a
> disproportionate ratio of full-nodes-vs-SPV, they may not have the same
> economic weight at all, therefore
Good morning Ruben,
> Hi ZmnSCPxj,
>
> >on completion of the protocol, if Bob lets the refund tx#1 become valid
> >(i.e. does not spend the BTC txo) then Alice can broadcast it, putting both
> >their funds into chaos
>
> You forget, refund tx #1 has a script (which btw won't be visible with
>
Good morning Andrew,
> > Hi, noob question here: Is there a long-term plan for if the block reward
> > drops
> > too low to ensure the security of the network?
> >
> > IIUC miners only make profit from block rewards and transaction fees, and
> > once
> > the block reward drop to zero we're
Good morning Thomas,
> So I think the question to ask would be "why can't we just make sure it's not
> 64?"
If we accept a 60-byte tx, then SHA-256 will pad it to 64 bytes, and it may
still be possible to mount CVE-2017-12842 attack with 32-bits of work.
Of course some other details will be
Good morning Karl,
> Hi,
>
> I'd like to revisit the discussion of the digest algorithm used in hashcash.
>
> I believe migrating to new hashing algorithms as a policy would significantly
> increase decentralization and hence security.
Why do you believe so?
My understanding is that there are
Good morning Chris,
> It seems having just one contract transaction which includes anchor
> outputs in the style already used by Lightning is one way to fix both
> these vulnerabilities.
>
> For the first attack, the other side cannot burn the entire balance
> because they only have access to the
Good morning Antoine,
> > This can be arranged by having one side offer partial signatures for the
> > transaction of the other, and once completing the signature, not sharing it
> > with the other until we are ready to actually broadcast the transaction of
> > our own volition.
> > There is
Good morning Chris, and probably also Lightningers,
> However, it might be possible to prevent the maker from learning the
> collateral input at all.
>
> If my understanding of BIP-143 is correct, inputs are hashed separately
> (`hashPrevouts`) from outputs (`hashOutputs`).
> Bob can provide
Good morning Chris,
> > This seems a great solution!
> > Since B is the one offering HTLCs, the taker of a CoinSwap sequence can be
> > B as well.
> > This means, the taker has to have some collateral input, of at least value
> > K, that it cannot swap (because if it tried to swap that amount,
Good morning Tom,
> Here is a high-level description of how this blinding can operate - with the
> aim that the conductor does learn how the ownership of individual coins has
> changed.
> For example, imagine 4 individuals (A,B,C and D) who own equal value
> statecoins utxo1, utxo2, utxo3 and
Good morning Chris,
> A big downside is that it really ruins the property of allowing coins to
> remain unspent indefinitely. That has privacy implications: if a coin
> remains unspent for longer than 2 weeks (or another short locktime) then
> for sure the transaction was not a CoinSwap, and so
Good morning Mr. Lee, and list,
> I can then look at the gossiped channels and see the size of the channel
> between the cut-throat company and the other employee, and from there, guess
> that this is the bi-weekly salary of that employee.
This can be made an argument against always
Good morning Mr. Lee,
> Permanent raises can justify permanently increasing the size of the channel
> with the employee.
On reflection, this is a bad idea.
Suppose I am a cut-throat employee and I want to have an idea of the bi-weekly
salary of another employee.
I make some stupid bet, and
Good morning all,
>
> Below is a novel discussion on block-withholding attacks and FPNC. These are
> two very simple changes being proposed here that will dramatically impact the
> network for the better.
>
> But first of all, I'd like to say that the idea for FPNC came out of a
> conversation
Good morning Thomas,
> Tier, AJ, ZmnSCPxj, thanks!
>
> > On Aug 17, 2020, at 1:04 AM, ZmnSCPxj via bitcoin-dev
> > wrote:
> >
> > Taproot MAST to the rescue.
>
> OK. So, using the tick scheme described by Tier a difficulty futures
> instrument is
Good morning Chris,
> > Absolute timelocks mean that you can set a timer where you put your node to
> > sleep without risk of loss of funds (basically, once the absolute timelocks
> > have resolved, you can forget about CoinSwaps).
> > But I think the ability to spend at any time would be
Good morning,
> Right, so if the taker uses only a single maker then they must have more
> than one UTXO.
Spending one UTXO is fine, it is generating a transaction that has one output
that is problematic.
What needs to happen is that this single UTXO is spent to two outputs: the
CoinSwap
Good morning Nadav,
> Hey Chris and all,
>
> Looking good :) I have one major concern though
>
> > q = EC privkey generated by maker
> > Q = q.G = EC pubkey published by maker
> >
> > p = nonce generated by taker
> > P = p.G = nonce point calculated by taker
> >
> > R = Q + P =
Good morning Antoine,
> Note, I think this is independent of picking up either relative or absolute
> timelocks as what matters is the block delta between two links.
I believe it is quite dependent on relative locktimes.
Relative locktimes *require* a contract transaction to kick off the
Good morning Tier, Thomas, and aj,
> On Sun, Aug 16, 2020 at 4:50 PM Thomas Hartman via bitcoin-dev
> wrote:
>
> > My understanding is that adding a single op_difficulty operation as
> > proposed would enable not true difficulty futures but binary options
> > on difficulty.
> >
> >
Good morning Chris,
Great to see this!
Mostly minor comments.
>
> == Direct connections to Alice ===
>
> Only Alice, the taker, knows the entire route, Bob and Charlie just know
> their previous and next transactions. Bob and Charlie do not have direct
> connections with each other, only with
> At this point very little is stopping us from speeding up block creation
>times. PoS networks are proving that conformations can be a minute or less -
>why not allow for a block formation time that is 6 or 12 times faster than the
>current target and have 1/6th (or 1/12th) of the subsidy to
Good morning Tom,
> Hi ZmnSCPxj,
>
> > I think the entire point of non-custodiality ***is*** trust minimization.
>
> There are also legal and regulatory implications. It is much easier for a
> service to operate without requiring its users to be KYCed if it is
> non-custodial and funds cannot
Good morning Tom,
> Hi ZmnSCPxj,
>
> > The SE can run in a virtual environment that monitors deletion events and
> > records them.
> > Such a virtual environment could be set up by a rootkit that has been
> > installed on the SE hardware.
> > Thus, even if the SE is honest, corruption of the
Good morning Mike,
> ZmnSCPxj,
>
> The growing tare in growing disagreement continues to divide mining capacity
> while the network waits for formation of future blocks - you'll never get to
> complete consensus unless three is a way to avoid ambiguity in disagreement,
> which you have not
Good morning Mike,
An observation to be made is that the current "first seen" is more
incentive-compatible than floating-point Nakamoto consensus.
If a miner A mines a block at height N, then obviously the first block it has
seen is that block.
If due to propagation delays on the network,
Good morning Mike,
That is better than implied name-calling and refusing to lay out your argument
in detail.
It is still sub-optimal since you are still being insulting by labeling me as
"reactionary", when you could have just laid out the exact same argument ***in
the first place*** without
Good morning Chris,
>
> Looking at these equations, I realize that the incentives against
> post-coinswap-theft-attempt still work even if we set K = 0, because the
> extra miner fee paid by Bob could be enough disincentive.
This made me pause for a moment, but on reflection, is correct.
The
Good morning Mr. Lee,
> Lightning network is not much an option because they do not have
> inbound balance to get paid.
Why not?
Your company can open a channel with each employee that has insufficient
inbound liquidity.
The employee is incentivized to reveal their node to your company so you
Good morning Prayank
> I have explained the whole idea with a proof of concept in this link:
> https://medium.com/@prayankgahlot/post-mix-usage-using-multisig-and-cpfp-e6ce1fdd57a1
The article is not clear I think, so please confirm my understanding below.
Participants:
* "Peer 3" - Payee
*
Good morning Kari,
> > > You mention ASICs becoming commoditized. I'd remind you that eventually
> > > there will be a public mathematical breaking of the algorithm, at which
> > > point all ASICs will become obsolete regardless. Would you agree it
> > > would be better to prepare for this
Good morning Prayank,
> 1. Peer 1 doesn't need to be a trusted third party, it can be implemented in
> a way that some peers involved in this system can provide liquidity for
> others and incentives can be a small fee.
It is not clear in the article, but you mention using a 2-of-3, and show 3
Good morning Kari,
> You mention ASICs becoming commoditized. I'd remind you that eventually
> there will be a public mathematical breaking of the algorithm, at which point
> all ASICs will become obsolete regardless. Would you agree it would be
> better to prepare for this by planning
Good morning Ruben and Chris,
> >For a much greater anonymity set we can use 2-party ECDSA to create 2-of-2
> >multisignature addresses that look the same as regular single-signature
> >addresses
>
> This may perhaps be counter-intuitive, but SAS doesn't actually require
> multisig for one of
Good morning Ruben,
>
> That assumes there will be a second transaction. With SAS I believe we can
> avoid that, and make it look like this:
>
> +---+
> Alice ---| |--- Bob
> Alice ---| |
> Bob ---| |
> +---+
If Alice is paying to a non-SAS aware
Good morning Prayank,
> 1. The spending tx of multisig can be decided earlier and all three can
> review the outputs involved in it. All 3 txs involved in the system if we
> consider only one mixer and not a chain will get confirmed in the same block
> as we are using CPFP so child pays for
Good morning Karl,
> > > Reddit claims two entities controlled 62% of the hashrate recently:
> > > https://old.reddit.com/r/CryptoCurrency/comments/gmhuon/in_the_last_24_hours_bitcoins_nakamoto/
> > > . Compromising the systems of these two groups seems like it is all
> > > that is needed to
Good morning Tom,
> Hi ZmnSCPxj,
>
> Thanks for the reply.
>
> > Okay, I suppose this is much too high-level a view, and I have no idea what
> > you mean by "statecoin" exactly.
>
> Sorry, most of the protocol details are in the links, but terminology should
> be made clearer. A "statecoin" is
Good morning Chris,
> On 13/06/2020 15:06, ZmnSCPxj wrote:
>
> > Good morning Chris,
> >
> > > Would it be fair to summarize the idea in this way:
> > > CoinSwappers can slow down the CoinSwap process which will give an
> > > opportunity for makers to use batching.
> >
> > I think so.
> >
Good morning list, BlueMatt and aj,
There is an idea circulating on IRC and elsewhere, which seems to be at least
mildly supported by gmax and roconnor, which I will try to explain here.
(These are my words, so if there is some mistake, I apologize)
Basically:
* Deploy a BIP8
Good morning Hilda,
> Good Day ZmnSCPxj,
>
> Thanks for sharing the idea! I read through the doc and have some concerns
> that might be off the topic or outside the scope. Please bear with me.
>
> The traditional banking system provides more than custodial holding of funds
> in terms of lending
Good morning Mike,
Hard NAK.
The responses to the original posting already pointed out important problems
with this:
* Encourages address reuse, hurting fungibility and privacy.
* Prevents pruning, since access to previous blocks must always be available in
order to validate.
* Optimized
Good morning Matt,
> While I admit I haven’t analyzed the feasibility, I want to throw one
> additional design consideration into the ring.
>
> Namely, it would ideally be trivial, at the p2p protocol layer, to relay a
> transaction to a full node without knowing exactly which input transaction
Good morning Richard,
> Thanks AJ for the updated BIP - very exciting!
>
> I'm also interested in this in the context of a Taproot version of
> Decker-Russell-Osuntokun (eltoo). Thanks ZmnSCPxj for summarizing your
> thoughts on how this would work. I have had some difficulty understanding
>
Good morning Matt,
> Hmm, apologies that little context was provided - this was meant in the
> context of the current crop of relay-based attacks that have been discovered.
> As we learned in those contexts, “just handle it when it confirms” doesn’t
> provide the types of guarantees we were
g a cartel / monopoly, which we know is
detrimental to customers of the monopoly, and is the reason why we prefer
decentralization.
Regards,
ZmnSCPxj
> On Mon, Jun 29, 2020 at 8:05 PM ZmnSCPxj via bitcoin-dev
> wrote:
>
> > Good morning Dave, et al.,
> >
> > &g
Good morning Mr. Lee,
> Sorry. Re-sending with correction to CC bitcoin-dev
>
> I am sorry if this was already brought up in previous threads. If I know
> lightning network correctly then HTLC is used to enforce settlements on
> blockchain if there is a dispute. Could a person lose money if their
201 - 300 of 568 matches
Mail list logo
