Hi all,
This is an alternative to jl2012's BIPZZZ (OP_PUSHTXDATA[1]).
It riffs on the (ab)use of OP_CHECKSIGFROMSTACK that Russell[2]
used to implement covenants[3]. I've been talking about it to random
people for a while, but haven't taken time to write it up.
The idea is to provide a O
I've just re-read BIP 117, and I'm concerned about its flexibility. It
seems to be doing too much.
The use of altstack is awkward, and makes me query this entire approach.
I understand that CLEANSTACK painted us into a corner here :(
The simplest implementation of tail recursion would be a singl
"Russell O'Connor" writes:
> However, if I understand correctly, the situation for BIP 117 is entirely
> different. As far as I understand there is currently no restrictions about
> terminating a v0 witness program with a non-empty alt-stack, and there are
> no restrictions on leaving non-canonic
Hi all!
Since there's activity on new signature types, I think it's
worth considering a more flexible alternative to
SIGHASH_SINGLE|SIGHASH_ANYONECANPAY. See Usefulness for why.
Proposal: Two bits: SIGHASH_BUNDLESTART/SIGHASH_INBUNDLE
A signature needs to indicate that signs on
Anthony Towns via bitcoin-dev writes:
> If you've got one bundle that overpays fees and another that underpays,
> you can safely combine the two only if you can put a SIGHASH_ALL sig in
> the one that overpays (otherwise miners could just make their own tx of
> just the overpaying bundle).
This i
Hi all,
The largest problem we are having today with the lightning
protocol is trying to predict future fees. Eltoo solves this elegantly,
but meanwhile we would like to include a 546 satoshi OP_TRUE output in
commitment transactions so that we use minimal fees and then use CPFP
(which ca
Olaoluwa Osuntokun writes:
> What are the downsides of just using p2wsh? This route can be rolled out
> immediately, while policy changes are pretty "fuzzy" and would require a
> near uniform rollout in order to ensure wide propagation of the commitment
> transactions.
I expect we will, but thoug
Anthony Towns via bitcoin-dev writes:
> On Mon, May 07, 2018 at 09:40:46PM +0200, Christian Decker via bitcoin-dev
> wrote:
>> Given the general enthusiasm, and lack of major criticism, for the
>> `SIGHASH_NOINPUT` proposal, [...]
>
> So first, I'm not sure if I'm actually criticising or playing
Johnson Lau writes:
> You should make a “0 fee tx with exactly one OP_TRUE output” standard, but
> nothing else. This makes sure CPFP will always be needed, so the OP_TRUE
> output won’t pollute the UTXO set
That won't propagate :(
> Instead, would you consider to use ANYONECANPAY to sign the
Luke Dashjr writes:
> An OP_TRUE-only script with a low value seems like a good example of where
> the
> weight doesn't reflect the true cost: it uses a UTXO forever, while only
> costing a weight of 4.
>
> I like Johnson's idea to have some template (perhaps OP_2-only, to preserve
> expected
Jim Posen writes:
> I believe OP_CSV with a relative locktime of 0 could be used to enforce RBF
> on the spending tx?
Marco points out that if the parent is RBF, this child inherits it, so
we're actually good here.
However, Matt Corallo points out that you can block RBF will a
large-but-lowball
Peter Todd writes:
> On Mon, May 21, 2018 at 01:14:06PM +0930, Rusty Russell via bitcoin-dev wrote:
>> Jim Posen writes:
>> > I believe OP_CSV with a relative locktime of 0 could be used to enforce RBF
>> > on the spending tx?
>>
>> Marco points ou
Rusty Russell writes:
> AFAICT the optimal DoS is where:
>
> 1. Attacker sends a 100,000 vbyte tx @1sat/vbyte.
> 2. Replaces it with a 108 vbyte tx @2sat/vbyte which spends one of
> those inputs.
> 3. Replaces that spent input in the 100k tx and does it again.
>
> It takes 3.5 seconds to pr
"David A. Harding" writes:
> On Tue, Jun 19, 2018 at 02:02:51PM -0400, David A. Harding wrote:
>> Anyone can rewrite a SIGHASH_NOINPUT input's outpoint, but the actual
>> transaction containing the settlement is expected to have (at least) two
>> inputs, with the second one originating the fees.
Gregory Maxwell via bitcoin-dev writes:
> On Mon, Apr 30, 2018 at 4:29 PM, Christian Decker via bitcoin-dev
> wrote:
>> Hi all,
>>
>> I'd like to pick up the discussion from a few months ago, and propose a new
>> sighash flag, `SIGHASH_NOINPUT`, that removes the commitment to the previous
>
> I k
DING FENG writes:
> Hi,
>
> I'm a junior developer and a bitcoin user.
> And I have read this thread carefully.
>
> I'm very worried about "SIGHASH_NOINPUT".
>
> Because "SIGHASH_NOINPUT" looks will be widely used, and it makes reuse
> address more dangerous.
No.
A wallet should *never* create a
Matt Corallo writes:
> As an alternative proposal, at various points there have been
> discussions around solving the "RBF-pinning" problem by allowing
> transactors to mark their transactions as "likely-to-be-RBF'ed", which
> could enable a relay policy where children of such transactions woul
Pieter Wuille via bitcoin-dev writes:
> Here is a combined proposal:
> * Three new sighash flags are added: SIGHASH_NOINPUT, SIGHASH_NOFEE,
> and SIGHASH_SCRIPTMASK.
> * A new opcode OP_MASK is added, which acts as a NOP during execution.
> * The sighash is computed like in BIP143, but:
> * If S
Johnson Lau writes:
>> On 12 Dec 2018, at 5:42 PM, Rusty Russell via bitcoin-dev
>> wrote:
>>
>> Pieter Wuille via bitcoin-dev writes:
>>> Here is a combined proposal:
>>> * Three new sighash flags are added: SIGHASH_NOINPUT, SIGHASH_NOFEE,
>
Rusty Russell writes:
>> However, I’m not sure if there is any useful NOINPUT case with unmasked
>> script.
>
> This is *not* true of Eltoo; the script itself need not change for the
> rebinding (Christian, did something change?).
This is wrong, sorry. I re-checked the paper, and the constant f
Anthony Towns via bitcoin-dev writes:
> On Thu, Dec 13, 2018 at 11:07:28AM +1030, Rusty Russell via bitcoin-dev wrote:
>> And is it worthwhile doing the mask complexity, rather than just
>> removing the commitment to script with NOINPUT? It *feels* safer to
>> restrict wha
Johnson Lau writes:
> I don’t think this has been mentioned: without signing the script or masked
> script, OP_CODESEPARATOR becomes unusable or insecure with NOINPUT.
>
> In the new sighash proposal, we will sign the hash of the full script (or
> masked script), without any truncation. To make
Johnson Lau writes:
>> On 16 Dec 2018, at 2:55 PM, Rusty Russell via bitcoin-dev
>> wrote:
>>
>> Anthony Towns via bitcoin-dev writes:
>>> On Thu, Dec 13, 2018 at 11:07:28AM +1030, Rusty Russell via bitcoin-dev
>>> wrote:
>>>> And is it
Johnson Lau writes:
>> On 17 Dec 2018, at 11:10 AM, Rusty Russell wrote:
>> My anti-complexity argument leads me to ask why we'd support
>> OP_CODESEPARATOR at all? Though my argument is weaker here: no wallet
>> need support it.
>
> Because it could make scripts more compact in some cases?
>
>
Matt Corallo writes:
> Ultimately, defining a "near the top of the mempool" criteria is fraught
> with issues. While it's probably OK for the original problem (large
> batched transactions where you don't want a single counterparty to
> prevent confirmation), lightning's requirements are very d
Matt Corallo writes:
>>> Thus, even if you imagine a steady-state mempool growth, unless the
>>> "near the top of the mempool" criteria is "near the top of the next
>>> block" (which is obviously *not* incentive-compatible)
>>
>> I was defining "top of mempool" as "in the first 4 MSipa", ie. ne
Anthony Towns writes:
> If you publish to the blockchain:
...
> 4 can be dropped, state 5 and finish can be altered). Since the CSV delay
> is chosen by the participants, the above is still a possible scenario
> in eltoo, though, and it means there's some risk for someone accepting
> bitcoins that
Sorry AJ, my prior email was not constructive :(
I consider the "my software reused my keys" the most reasonable attack
scenario, though still small compared to other lightning attack surfaces.
But I understand the general wariness of third-parties reusing
SIGHASH_NOINPUT signatures.
Since "must
Anthony Towns via bitcoin-dev writes:
> Hi everybody!
>
> Here is a followup BIP draft that enables SIGHASH_ANYPREVOUT and
> SIGHASH_ANYPREVOUTANYSCRIPT on top of taproot/tapscript. (This is NOINPUT,
> despite the name change)
I really like this proposal, and am impressed with how cleanly it
sep
Anthony Towns writes:
> On Wed, May 22, 2019 at 12:17:31PM +0930, Rusty Russell wrote:
>>I prefer to
>>change the bip introduction to expliclty shout "THESE SIGNATURE
>>HASHES ARE UNSAFE FOR NORMAL WALLET USAGE.", and maybe rename it
>>SIGHASH_UNSAFE_ANYPREVOUT.
>
>> 4. "Rebinding
Hi all,
I want to propose a modification to rules 3, 4 and 5 of BIP 125:
To remind you of BIP 125:
3. The replacement transaction pays an absolute fee of at least the sum
paid by the original transactions.
4. The replacement transaction must also pay for its own bandwidth at
or
"Russell O'Connor" writes:
> Hi Rusty,
>
> On Sun, Jun 2, 2019 at 9:21 AM Rusty Russell via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> The new "emergency RBF" rule:
>>
>> 6. If the original transaction was n
Matt Corallo writes:
> I think this needs significantly improved motivation/description. A few areas
> I'd like to see calculated out:
>
> 1) wrt rule 3, for this to be
> obviously-incentive-compatible-for-the-next-miner, I'd think no evicted
> transactions would be allowed to be in the next bl
"David A. Harding" writes:
> On Thu, Jun 06, 2019 at 02:46:54PM +0930, Rusty Russell via bitcoin-dev wrote:
>> If that's true, I don't think this proposal makes it worse.
>
> Here's a scenario that I think shows it being at least 20x worse.
[ Sn
Hi Gleb,
Minor feedback on reading the draft:
> sendrecon:
> uint32version Must be exactly 1 currently.
At risk of quoting myself[1]: data doesn't have requirements. Actors do.
In this case, I assume you mean "writers must set this to 1". What do
readers do if it's not?
Hi all,
Those who've seen the original versionbits bip, this adds:
1) Percentage checking only on retarget period boundaries.
2) 1 retarget period between 95% and activation.
3) A stronger suggestion for timeout value selection.
https://gist.github.com/rustyrussell/47eb08093373f71f87de
Tier Nolan via bitcoin-dev
writes:
> On Sun, Sep 13, 2015 at 7:56 PM, Rusty Russell via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> '''States'''
>> With every softfork proposal we associate a state BStat
Jorge Timón via bitcoin-dev writes:
> I agree on using height vs time. Rusty, what do you mean by being easier
> for bip writers? How is writing "block x" any harder than writing "date y".
Three years from drafting is reasonable. How many blocks is that? Hmm,
better make it 6 years of blocks ju
Tier Nolan via bitcoin-dev writes:
> On Wed, Sep 16, 2015 at 9:19 PM, Rusty Russell
> wrote:
>> You need a timeout: an ancient (non-mining, thus undetectable) node
>> should never fork itself off the network because someone reused a failed
>> BIP bit.
>>
>
> I meant if the 2nd bit was part of the
Tier Nolan via bitcoin-dev
writes:
> The advantage of enforcing the rule when 75% is reached (but only for
> blocks with the bit set) is that miners get early notification that they
> have implemented the rule incorrectly.They might produce blocks that
> they think are fine, but which aren't.
Mark Friedenbach via bitcoin-dev
writes:
> Eric, that would be, I think, my sequencenumbers2 branch in which nSequence
> is an explicit relative lock-time field (unless the most significant bit is
> set). That has absolutely clear semantics. You should comment on #6312
> where this is being discus
Jorge Timón writes:
> I disagree with the importance of this concern and old soft/hardforks will
> replace this activation mechanism with height, so that's an argument in
> favor of using the height from the start. This is "being discussed" in a
> thread branched from bip99's discussion.
Thanks,
Jorge Timón writes:
> On Sep 20, 2015 10:58 PM, "Rusty Russell" wrote:
>>
>> Jorge Timón writes:
>> > I disagree with the importance of this concern and old soft/hardforks
> will
>> > replace this activation mechanism with height, so that's an argument in
>> > favor of using the height from the
Gavin Andresen via bitcoin-dev
writes:
> I don't see any incentive problems, either. Worst case is more miners
> decide to skip validation and just mine a variation of the
> highest-fee-paying weak block they've seen, but that's not a disaster--
> invalid blocks will still get rejected by all the
Gavin Andresen via bitcoin-dev
writes:
> I've been thinking about 'weak blocks' and SPV mining, and it seems to me
> weak blocks will make things better, not worse, if we improve the mining
> code a little bit.
>
> First: the idea of 'weak blocks' (hat tip to Rusty for the term) is for
> miners t
Hi all,
Pieter and Eric pointed out that the current BIP has miners
turning off the bit as soon as it's locked in (75% testnet / 95%
mainnet). It's better for them to keep setting the bit until activation
(2016 blocks later), so network adoption is visible.
I'm not proposing another sugg
Tom Harding via bitcoin-dev
writes:
> On 9/13/2015 11:56 AM, Rusty Russell via bitcoin-dev wrote:
>> '''Success: Activation Delay'''
>> The consensus rules related to ''locked-in'' soft fork will be enforced in
>> the sec
"Wladimir J. van der Laan via bitcoin-dev"
writes:
> On Sun, Sep 27, 2015 at 02:50:31PM -0400, Peter Todd via bitcoin-dev wrote:
>
>> It's time to deploy BIP65 CHECKLOCKTIMEVERIFY.
>
> There appears to be common agreement on that.
>
> The only source of some controversy is how to deploy: versionbi
John Winslow via bitcoin-dev
writes:
> Two observations from a Bitcoin investor and non-programmer:
Please take this off the -dev list.
Thanks,
Rusty.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/
Adam Back writes:
> I think from discussion with Gavin sometime during the montreal
> scaling bitcoin workshop, XT maybe willing to make things easy and
> adapt what it's doing. For example in relation to versionBits Gavin
> said he'd be willing to update XT with an updated/improved
> versionBits
Gregory Maxwell writes:
> I can, however, argue it the other way (and probably have in the
> past): The bit is easily checked by thin clients, so thin clients
> could use it to reject potentially ill-fated blocks from non-upgraded
> miners post switch (which otherwise they couldn't reject without
Rusty Russell via bitcoin-dev
writes:
> Gregory Maxwell writes:
>> I can, however, argue it the other way (and probably have in the
>> past): The bit is easily checked by thin clients, so thin clients
>> could use it to reject potentially ill-fated blocks from non-upgraded
Peter Todd via bitcoin-dev
writes:
> However I don't think we've done a good job showing why we need to
> implement this feature via nSequence.
It could be implemented in other ways, but nSequence is the neatest and
most straightforward I've seen.
- I'm not aware of any other (even vague) propos
Peter Todd writes:
> On Tue, Oct 06, 2015 at 12:28:49PM +1030, Rusty Russell wrote:
>> Peter Todd via bitcoin-dev
>> writes:
>> > However I don't think we've done a good job showing why we need to
>> > implement this feature via nSequence.
>>
>> It could be implemented in other ways, but nSequen
Btc Drak writes:
> Alex,
>
> I am sorry for not communicating more clearly. Mark and I discussed your
> concerns from the last meeting and he made the change. The BIP text still
> needs to be updated, but the discussed change was added to the PR, albeit
> squashed making it more non-obvious. BIP68
Rusty Russell via bitcoin-dev writes:
>>From a practical perspective: yuck. There's currently no way to play
> with bitcoind's perception of time, so that's a very long sleep to
> blackbox test (which is what my lightning test script does).
>
> So consider this
Hi all,
We aim to make the list more contentful and productive; to get devs to
resubscribe we need to maximize high-value interactions.
- Currently 5 moderators. BtcDrak, me, G1lius, Kanzure and Johnathan.
As far as I know we're entirely unconnected, and we cover Asia/Europe/US.
- Moder
Btc Drak via bitcoin-dev writes:
> I think this thread has gotten to the stage where it should be moved
> to an issue on Github and not continue to CC the bitcoin-dev list (or
> any other list tbh).
Agreed. I couldn't see an issue, so I've opened one. Let's track this
there, please.
https://gi
Gavin Andresen via bitcoin-dev writes:
> Should it be a requirement that ANY one-megabyte transaction that is valid
> under the existing rules also be valid under new rules?
>
> Pro: There could be expensive-to-validate transactions created and given a
> lockTime in the future stored somewhere sa
Peter R via bitcoin-dev writes:
> You are looking at the problem from a “top down” governance
> perspective assuming you know what code is actually being run and what
> rules the market wants.
We have strayed far from both the Subject line and from making progress
on bitcoin development. Please
Eric Lombrozo via bitcoin-dev writes:
>>From an app developer's perspective, I think it is pretty blatantly
> clear that relative timelock is *the* critical exposed functionality
> intended here.
As someone who actually developed scripts using CSV, I agree with Mark
(and Matt). The relative lo
Gavin Andresen via bitcoin-dev
writes:
> On Wed, Dec 2, 2015 at 1:57 PM, Emin Gün Sirer <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> How to Do It
>>
>> If we want to compress Bitcoin, a programming challenge/contest would be
>> one of the best ways to find the best possible, Bitcoin-spec
Gavin Andresen via bitcoin-dev
writes:
> Overall, good idea.
>
> Is there a write-up somewhere describing in detail the 'accidental selfish
> mining' problem that this mitigates? I think a link in the BIP to a fuller
> description of the problem and how validation-skipping makes it go away
> would
Jannes Faber via bitcoin-dev writes:
> Segregated IBLT
>
> I was just wondering if it would make sense when we have SW to also make
> Segregated IBLT? Segregating transactions from signatures and then tune the
> parameters such that transactions have a slightly higher guarantee and save
> a bit of
Jonathan Toomim via bitcoin-dev
writes:
> On Dec 18, 2015, at 10:30 AM, Pieter Wuille via bitcoin-dev
> wrote:
>
>> 1) The risk of an old full node wallet accepting a transaction that is
>> invalid to the new rules.
>>
>> The receiver wallet chooses what address/script to accept coins on.
>> Th
Luke Dashjr via bitcoin-dev writes:
> On Wednesday, December 30, 2015 6:22:59 PM Tomas wrote:
>> > The specification itself looks like an inefficient and bloaty reinvention
>> > of version bits.
>>
>> The actual assignment of version bits isn't clear from the
>> specification. Are you saying that
Pieter Wuille via bitcoin-dev
writes:
> Yes, this is what I worry about. We're constructing a 2-of-2 multisig
> escrow in a contract. I reveal my public key A, you do a 80-bit search for
> B and C such that H(A and B) = H(B and C). You tell me your keys B, and I
> happily send to H(A and B), which
Matt Corallo writes:
> Indeed, anything which uses P2SH is obviously vulnerable if there is
> an attack on RIPEMD160 which reduces it's security only marginally.
I don't think this is true? Even if you can generate a collision in
RIPEMD160, that doesn't help you since you need to create a specif
Gavin Andresen via bitcoin-dev writes:
> How many years until we think a 2^84 attack where the work is an ECDSA
> private->public key derivation will take a reasonable amount of time?
vanitygen can generate keypairs pretty fast (on my CPU it's comparable
with hashing time), and there are ways to
Hi all!
As planned, this is the three month review[1]: discussion of how
moderation should change is encouraged in this thread.
First, thanks to everyone for the restraint shown in sending
(and responding to!) inflammatory or sand-in-the-gears mails, and being
tolerant with our mi
xor--- via bitcoin-dev writes:
> On Thursday, January 21, 2016 11:20:46 AM Rusty Russell via bitcoin-dev wrote:
>> So, what should moderation look like from now on?
>
> The original mail which announced moderation contains this rule:
>> - Generally discouraged: [...], +1s, [.
Dave Scotese via bitcoin-dev writes:
> It is a shame that the moderated messages require so many steps to
> retrieve. Is it possible to have the "downloadable version" from
> https://lists.ozlabs.org/pipermail/bitcoin-dev-moderation/ for each month
> contain the text of the moderated emails? The
Joseph Poon via bitcoin-dev writes:
> Ideally, a 3rd-party can be handed a transaction which can encompass all
> prior states in a compact way. For currently-designed Segregated Witness
> transactions, this requires storing all previous signatures, which can
> become very costly if individuals to
Rune Kjær Svendsen via bitcoin-dev
writes:
> Dear list
>
> I've spent the past couple of months developing a simple protocol for
> working with payment channels. I've written up a specification of how
> it operates, in an attempt to standardize the operations of opening,
> paying and closing.
Hi!
Pieter Wuille via bitcoin-dev writes:
> On 05/03/2016 12:13 AM, lf-lists at mattcorallo.com (Matt Corallo) wrote:
>> Hi all,
>>
>> The following is a BIP-formatted design spec for compact block relay
>> designed to limit on wire bytes during block relay. You can find the
>> latest version of this
Gregory Maxwell writes:
> On Tue, May 10, 2016 at 5:28 AM, Rusty Russell via bitcoin-dev
> wrote:
>> I used variable-length bit encodings, and used the shortest encoding
>> which is unique to you (including mempool). It's a little more work,
>> but for an average n
To quote:
> HMAC_SHA512(key=ecdh_secret|cipher-type,msg="encryption key").
>
> K_1 must be the left 32bytes of the HMAC_SHA512 hash.
> K_2 must be the right 32bytes of the HMAC_SHA512 hash.
This seems a weak reason to introduce SHA512 to the mix. Can we just
make:
K_1 = HMAC_SHA256(key=ecdh
Jonas Schnelli writes:
>> To quote:
>>
>>> HMAC_SHA512(key=ecdh_secret|cipher-type,msg="encryption key").
>>>
>>> K_1 must be the left 32bytes of the HMAC_SHA512 hash.
>>> K_2 must be the right 32bytes of the HMAC_SHA512 hash.
>>
>> This seems a weak reason to introduce SHA512 to the mix. Can
Ethan Heilman writes:
>>It's also not clear to me why the HMAC, vs just SHA256(key|cipher-type|mesg).
>> But that's probably just my crypto ignorance...
>
> SHA256(key|cipher-type|mesg) is an extremely insecure MAC because of
> the length extension property of SHA256.
>
> If I have a tag y = SHA2
Johnson Lau via bitcoin-dev
writes:
> Restriction for segwit OP_IF argument as a policy has got a few concept ACK.
> I would like to have more people to ACK or NACK, especially the real users of
> OP_IF. I think Lightning network would use that at lot.
My current scripts use OP_IF and OP_NOTIF
Luke Dashjr via bitcoin-dev writes:
> This BIP describes a new opcode (OP_CHECKBLOCKATHEIGHT) for the Bitcoin
> scripting system to address reissuing bitcoin transactions when the coins
> they
> spend have been conflicted/double-spent.
>
> https://github.com/luke-jr/bips/blob/bip-cbah/bip-cbah
Russell O'Connor via bitcoin-dev
writes:
> On Sat, May 13, 2017 at 1:26 AM, Luke Dashjr wrote:
>
>> Versionbits change/lose their meaning after the deployment timeout. For
>> this
>> reason, the timeout must be specified so the check is skipped when that
>> occurs.
>>
>
> To add a timeout a user
Gregory Maxwell via bitcoin-dev writes:
> On Tue, May 16, 2017 at 6:17 PM, Pieter Wuille
> wrote:
>> just the first - and one that has very low costs and no normative
>> datastructures at all.
>
> The serialization of the txout itself is normative, but very minimal.
I do prefer the (2) approach
Gregory Maxwell via bitcoin-dev
writes:
> Based on how fast we saw segwit adoption, why is the BIP149 timeout so
> far in the future?
>
> It seems to me that it could be six months after release and hit the
> kind of density required to make a stable transition.
Agreed, I would suggest 16th Decem
Matt Corallo writes:
> A more important consideration than segwit's timeout is when code can be
> released, which will no doubt be several months after SegWit's current
> timeout.
I was assuming it would be included in the next point release.
Cheers,
Rusty.
__
Hi all,
There's a pull request for a lightning payment format which I'd
love wider review on. It's bech32 encoded, with optional parts tagged:
https://github.com/lightningnetwork/lightning-rfc/pull/183
There's an implementation with a less formal description here, too:
Btc Drak via bitcoin-dev writes:
> This BIP has been assigned BIP112 by the BIP repository maintainer. I
> have updated the pull request accordingly.
>
> Regarding the suggestion to cannibalise version, by your own
> disadvantage list, we would lose fine grained control over txins which
> neuters
jl2...@xbt.hk writes:
> Rusty Russell 於 2015-08-26 23:08 寫到:
>> - We should immediately deploy an IsStandard() rule which insists that
>> nSequence is 0x or 0, so nobody screws themselves when we
>> soft fork and they had random junk in there.
>
> This is not needed because BIP68 is not
"David A. Harding via bitcoin-dev"
writes:
> To avoid the excessive wasting of bandwidth. Bitcoin Core's defaults
> require each replacement pay a feerate of 10 nBTC/vbyte over an existing
> transaction or package, and the defaults also allow transactions or
> packages up to 100,000 vbytes in si
Hi all,
I propose an alternative to length restrictions suggested by
Russell in https://github.com/bitcoin/bips/pull/945: use the
https://gist.github.com/sipa/a9845b37c1b298a7301c33a04090b2eb variant,
unless the first byte is 0.
Here's a summary of each proposal:
Length restrictions (fut
"David A. Harding" writes:
> On Thu, Oct 08, 2020 at 10:51:10AM +1030, Rusty Russell via bitcoin-dev wrote:
>> Hi all,
>>
>> I propose an alternative to length restrictions suggested by
>> Russell in https://github.com/bitcoin/bips/pull/945 : us
Pieter Wuille writes:
> Today, no witness v1 receivers exist. So it seems to me the only question
> is what software/infrastructure exist that supports sending to witness v1,
> and whether they (and their userbase) are more or less likely to upgrade
> before receivers appear than those that don't.
Pieter Wuille writes:
> Here is a BIP341 witness v1 address, corresponding to just the generator as
> inner public key (using TapTweak(pubkey) as tweak, as suggested by the BIP):
>
> bc1pmfr3p9 YOU j00pfxjh WILL 0zmgp99y8zf LOSE tmd3s5pmedqhy MONEY
> ptwy6lm87hf5ss52r5n8
Here are my initial resu
Rusty Russell writes:
> Accepts
> ---
> Green: ef1662fd2eb736612afb1b60e3efabfdf700b1c4822733d9dbe1bfee607a5b9b
> blockchain.info:
> 64b0fcb22d57b3c920fee1a97b9facec5b128d9c895a49c7d321292fb4156c21
PEBKAC. Pasted wrong address. Here are correct results:
Rejects
---
c-lightning: "Could
ZmnSCPxj writes:
> I believe this is actually my code, which was later refactored by John
> Barboza when we were standardizing the `param` system.
Ah, sorry!
> This was intended only as a simple precaution against creating non-standard
> transaction, and not an assumption that future versions
Mike Schmidt via bitcoin-dev
writes:
> I am happy to re-test the services Harding listed previously for v1 send
> support next week.
>
> Suggestions of additional services that would be valuable to test are
> welcome as well.
Thanks! I am a little disappointed that I won't get to ask Bitcoin
Twi
Hi Andrew et al,
Very excited to see this progress; thanks for doing all the
work! Sorry for the delayed feedback, I didn't get to this before the
break.
> Additionally, I would like to add a new global field:
> * PSBT_GLOBAL_UNDER_CONSTRUCTION = 0x05
> * Key: empty
> * Value: A si
Andrew Chow writes:
> Hi Rusty,
>
> On 1/6/21 6:26 PM, Rusty Russell wrote:
>> Hi Andrew et al,
>>
>> Very excited to see this progress; thanks for doing all the
>> work! Sorry for the delayed feedback, I didn't get to this before the
>> break.
>>
>>> Additionally, I would like to add a
Perhaps title 'Bech32m address format for native v0-16 segregated
witness outputs' should probably be v1-16?
This is a thorough and clear write up; a superb read.
Side note: I am deeply impressed with your mathematical jujitsu that no
bech32 string is also a valid bech32m string *even with three
Jeremy via bitcoin-dev writes:
> Where I disagree is that I do not believe that BIP8 with LOT configuration
> is the improved long term option we should ossify around either. I
> understand the triumvirate model you desire to achieve, but BIP8 with an
> individually set LOT configuration does not
1 - 100 of 114 matches
Mail list logo
