Hello everyone,
regarding OP_CTV, I am considering the scaling use case, specifically an
exchange (or similar) who wants to batch pay to OP_CTV to many users, and I
wonder
1) How do you expect the exchange to communicate the proof of the payment to
the user wallets such that they are able to c
Hi Robin.
While your motivation seems reasonable, your solution is not. It is not enough
that a problem exists. Although the solution must be technically sound for the
proposal to be interesting. So I agree it makes sense to consider Bitcoin
sidechains, not sure if with PoS consensus or other,
Hi Robin,
inline...
‐‐‐ Original Message ‐‐‐
On Monday, January 13, 2020 7:47 PM, Robin Linus
wrote:
> Hi Joachim,
>
> Thank you for your detailed feedback!
>
> Regarding Reason #1:
> This proposal is less like Bitcoin vs. Altcoins and much more like Ethereum
> vs. ERC20 tokens, becaus
While I haven't rejected sidechains entirely yet, this particular proposal
seems uninteresting, especially for two reasons.
One – it introduces a new token for each sidechain and suggests atomic swaps to
be used for the exchange of the mainchain token with the sidechain token. Such
a model seem
> Instead of using sidechains, just use channel factories.
I am not familiar enough with the latest advancements in this field. Is it
possible using LN/channel factories to achieve off-line-like participation user
experience without previous registration with any kind of gateway provider? For
e
While I agree on NACKing the proposal as it does not add anything new and
fundamentally misunderstands what scaling is (or is not in this case), I
disagree with the claim that we do not need to deal with block size issue in
the future any more. Segwit increased our possibilities on how to use th
> Anyway, according to the current considerations I explained in this email,
> I’d suggest extending BIP-155 with per-link-direction negotiation, but I’m
> interested in the opinion of the community.
I don't have a strong opinion here but intuitively, it seems to me that
per-link variant makes
> > > > [...] to generate much longer chain with superslow timestamp increase
> > > > (~5 blocks in 1 second) without increasing difficulty (i.e. staying at
> > > > min. diff.). [...]
> > > > In that case, it would take about 7 minutes of block time seconds for
> > > > the next retarget period,
> > [...] First you provide proof of your best block height via coinbase [...]
>
> So I don't think you can use the height in the coinbase for that
> purpose, as it's not possible to validate it without the previous
> headers. That's common for more than just the height.
You can fake it of cours
I like the backwards syncing idea. First you provide proof of your best block
height via coinbase, then sync backwards. It solves lots of related problems.
You know how much you can expect from the given peer.
On different note, one of the problems that I haven't seen mentioned here yet
is the
10 matches
Mail list logo
