"James O'Beirne" writes:
> On Sat, Oct 28, 2023 at 12:51 AM Rusty Russell via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> But AFAICT there are multiple perfectly reasonable variants of vaults,
>> too. One would be:
>>
>
Anthony Towns writes:
> On Fri, Oct 20, 2023 at 02:10:37PM +1030, Rusty Russell via bitcoin-dev wrote:
>> I've done an exploration of what would be required (given
>> OP_TX/OP_TXHASH or equivalent way of pushing a scriptPubkey on the
>> stack) to usefully v
Andrew Poelstra writes:
> I had a similar thought. But my feeling is that replacing the stack
> interpreter data structure is still too invasive to justify the benefit.
>
> Also, one of my favorite things about this BIP is the tiny diff.
To be fair, this diff is even smaller than the OP_CAT diff
Andrew Poelstra writes:
> On Mon, Oct 23, 2023 at 12:43:10PM +1030, Rusty Russell via bitcoin-dev wrote:
>> Ethan Heilman via bitcoin-dev writes:
>> > Hi everyone,
>> >
>> > We've posted a draft BIP to propose enabling OP_CAT as Tapscript opcode.
>>
Ethan Heilman via bitcoin-dev writes:
> Hi everyone,
>
> We've posted a draft BIP to propose enabling OP_CAT as Tapscript opcode.
> https://github.com/EthanHeilman/op_cat_draft/blob/main/cat.mediawiki
This is really nice to see!
AFAICT you don't define the order of concatenation, except in the
i
Brandon Black writes:
> On 2023-10-20 (Fri) at 14:10:37 +1030, Rusty Russell via bitcoin-dev wrote:
>> I've done an exploration of what would be required (given
>> OP_TX/OP_TXHASH or equivalent way of pushing a scriptPubkey on the
>> stack) to usefully validate
Hi all,
I've done an exploration of what would be required (given
OP_TX/OP_TXHASH or equivalent way of pushing a scriptPubkey on the
stack) to usefully validate Taproot outputs in Bitcoin Script. Such
functionality is required for usable vaults, at least.
https://rusty.ozlabs.or
Hi!
I've read the start of the paper on my vacation, and am still
digesting it. But even so far, it presents some delightful
possibilities.
As with some other proposals, it's worth noting that the cost of
enforcement is dramatically increased. It's no longer one or two txs,
it's 10+. I
Hi all,
TL;DR: a v1 tapscript opcode for generic covenants, but
OP_SUCCESS unless it's used a-la OP_CHECKTEMPLATEVERIFY. This gives an
obvious use case, with clean future expansion. OP_NOP4 can be
repurposed in future as a shortcut, if experience shows that to be a
useful optimization.
Jeremy Rubin writes:
> Hi Rusty,
>
> Please see my post in the other email thread
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019886.html
>
> The differences in this regard are several, and worth understanding beyond
> "you can iterate CTV". I'd note a few clear example
Jeremy Rubin writes:
> Rusty,
>
> Note that this sort of design introduces recursive covenants similarly to
> how I described above.
>
> Whether that is an issue or not precluding this sort of design or not, I
> defer to others.
Good point!
But I think it's a distinction without meaning: AFAICT
Russell O'Connor via bitcoin-dev writes:
> Given the overlap in functionality between CTV and ANYPREVOUT, I think it
> makes sense to decompose their operations into their constituent pieces and
> reassemble their behaviour programmatically. To this end, I'd like to
> instead propose OP_TXHASH an
Ryan Grant writes:
> On Tue, Apr 6, 2021 at 11:58 PM Rusty Russell via bitcoin-dev
> wrote:
>> The core question always was: what do we do if miners fail to activate?
>>
>> [...] Speedy Trial takes the approach that "let's pretend we didn't
>> *actu
Jeremy via bitcoin-dev writes:
> We had a very productive meeting today. Here is a summary of the meeting --
> I've done my best to
> summarize in an unbiased way. Thank you to everyone who attended.
>
> 1. On the use of a speedy trial variant:
>
> - There are no new objections to speedy trial gen
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
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
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
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
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
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
Rusty Russell writes:
> Accepts
> ---
> Green: ef1662fd2eb736612afb1b60e3efabfdf700b1c4822733d9dbe1bfee607a5b9b
> blockchain.info:
> 64b0fcb22d57b3c920fee1a97b9facec5b128d9c895a49c7d321292fb4156c21
PEBKAC. Pasted wrong address. Here are correct results:
Rejects
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
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.
"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
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 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 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?
"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
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
"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
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
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_
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
es.
Since "must have a non-SIGHASH_NOINPUT" rule addresses the first reuse
scenario (as well as the second), I'd be content with that proposal.
Future segwit versions may choose to relax it.[1]
Cheers,
Rusty.
[1] Must be consensus, not standardness; my prev suggestion was bogus.
Rusty R
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
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
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
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
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:
> 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
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
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 pa
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,
>
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
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
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
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
"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.
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.
>
>
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
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
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
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
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
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
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
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!
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
"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
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
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
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:
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.
__
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
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
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
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
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
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
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
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
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
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
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!
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
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
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, [.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
>&g
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
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
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
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
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/
"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
1 - 100 of 118 matches
Mail list logo
