> To make it completely transparent to unupgraded wallets, the return outputs
> have to be sent to something that is non-standard today, i.e. not P2PK,
> P2PKH, P2SH, bare multi-sig, and (with BIP141) v0 P2WPKH and v0 P2WSH.
Johnson,
I feel that's not as much of an issue with v0 witness program
To make it completely transparent to unupgraded wallets, the return outputs
have to be sent to something that is non-standard today, i.e. not P2PK, P2PKH,
P2SH, bare multi-sig, and (with BIP141) v0 P2WPKH and v0 P2WSH.
Mainchain segwit is particularly important here, as that allows atomic swap
Johnson,
Yeah, I do still see the issue. I think there are still some reasonable
ways to mitigate it.
I've started revising the extension block specification/code to coexist
with mainchain segwit. I think the benefit of this is that we can
require exiting outputs to only be witness programs. Pres
> On 6 Apr 2017, at 01:43, Christopher Jeffrey wrote:
>
>
>> This hits the biggest question I asked in my January post: do you want
>> to allow direct exit payment to legacy addresses? As a block reorg
>> will almost guarantee changing txid of the resolution tx, that will
>> permanently invalid
On Wednesday, April 05, 2017 4:54:05 PM Christopher Jeffrey via bitcoin-dev
wrote:
> There's understandable confusion about this, but this proposal is not
> meant to be a BIP.
Oh? If this was not meant to be a Bitcoin Improvement Proposal, perhaps you
should clarify somewhere what altcoin you ar
Hi Johnson,
Really appreciate the comments. I know this idea is your baby.
> so the authors don’t consider segwit as a consensus-layer solution to
> increase transaction throughput, or not think segwit is safe? But
> logically speaking if segwit is not safe, this BIP could only be
> worse. OTOH,
> On 5 Apr 2017, at 22:05, Olaoluwa Osuntokun wrote:
>
>
> The concrete parameters chosen in the proposal are: each channel opening
> transaction reserves 700-bytes within _each_ block in the chain until the
> transaction has been closed.
>
>
Why so? It seems you are describing it as a soft
Hi Luke,
Thank you for the review. Many of these points should definitely be
addressed in the spec. Although extension blocks has working code, the
spec is currently still in a draft state now and could really use all
the feedback it can get. A few rules are still up in the air before we
setup a p
On Wed, Apr 05, 2017 at 11:37:22AM -0400, Greg Sanders via bitcoin-dev wrote:
> I'd appreciate the authors chiming in, but I read the PASDA differently:
>
> 1) If a transaction is mined with a certain bit set, it reserves 700 bytes
> for that particular block.
> 2) In that space, 2 transactions ma
I'd appreciate the authors chiming in, but I read the PASDA differently:
1) If a transaction is mined with a certain bit set, it reserves 700 bytes
for that particular block.
2) In that space, 2 transactions may happen:
a) First, a transaction penalizing the "parent" transaction for fraud by
spend
Hi Y'all,
Thanks to luke-jr and jl2012 for publishing your analysis of the
xblocks proposal. I'd like to also present some analysis but instead focus
on the professed LN safety enhancing scheme in the proposal. It's a bit
underspecified, so I've taken the liberty of extrapolating a bit to fill
in
I feel particularly disappointed that while this BIP is 80% similar to my
proposal made 2 months ago (
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013490.html
), Matt Corallo was only the person replied me. Also, this BIP seems ignored
the txid malleability of the resol
Recently there has been some discussion of an apparent work-in-progress
extension block proposal by Christopher Jeffrey, Joseph Poon, Fedor Indutny,
and Steven Pair. Since this hasn't been formally posted on the ML yet, perhaps
it is still in pre-draft stages and not quite ready for review, but
13 matches
Mail list logo
