Re: [bitcoin-dev] Bitcoin XT 0.11A

On 08/16/15 23:22, Andrew LeCody via bitcoin-dev wrote: Cam, your scenario makes no sense. 1. Spoil the ballot. Have Bitcoin Core propagate the Bitcoin XT version string. 2. Encourage all miners to false vote for the Bitcoin XT fork. This would obliterate any confidence in Bitcoin Core.

Re: [bitcoin-dev] CLTV/CSV/etc. deployment considerations due to XT/Not-BitcoinXT miners

Wait, why did Bitcoin-XT use that nVersion??? Definitely option 3 is much cleaner technically, and it would be nice to have that code implemented, but I'd be rather concerned about the size of the fork ballooning. It's already four separate features in one fork, which seems pretty big, even if

Re: [bitcoin-dev] Proposed new policy for transactions that depend on other unconfirmed transactions

I dont see any problem with such limits. Though, hell, if you limited entire tx dependency trees (ie transactions and all required unconfirmed transactions for them) to something like 10 txn, maximum two levels deep, I also wouldnt have a problem. Matt On 08/14/15 19:33, Alex Morcos via

Re: [bitcoin-dev] Revisiting NODE_BLOOM: Proposed BIP

Revised copy follows. re: mentioning the HTTP seeding stuff, I'm not sure we want to encourage more people aside from bitcoinj to use that...I thought about adding a DNS seed section to this bip, but decided against it...still, I think we should add the option to select service bits to DNS seeds

Re: [bitcoin-dev] Revisiting NODE_BLOOM: Proposed BIP

which do support bloom filtering. On 08/21/15 05:48, Jeff Garzik wrote: If this is widely deployed + enabled, what is the impact to current wallets in use? On Fri, Aug 21, 2015 at 12:46 AM, Matt Corallo via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org mailto:bitcoin-dev

Re: [bitcoin-dev] Revisiting NODE_BLOOM: Proposed BIP

BIP Editor: Can I get a BIP # for this? On 08/21/15 17:55, Matt Corallo via bitcoin-dev wrote: Revised copy follows. re: mentioning the HTTP seeding stuff, I'm not sure we want to encourage more people aside from bitcoinj to use that...I thought about adding a DNS seed section to this bip

Re: [bitcoin-dev] Revisiting NODE_BLOOM: Proposed BIP

On 08/21/15 22:06, Peter Todd wrote: On Fri, Aug 21, 2015 at 05:55:58PM +, Matt Corallo wrote: Revised copy follows. re: mentioning the HTTP seeding stuff, I'm not sure we want to encourage more people aside from bitcoinj to use that...I thought about adding a DNS seed section to this

Re: [bitcoin-dev] Revisiting NODE_BLOOM: Proposed BIP

I'll just quote what I said on github: Neither this pull nor the BIP has any stated intention of phasing out bloom filtering support in the protocol. As much as I'd love to, I 100% agree with @mikehearn here, that would break any ability of SPV clients to operate on the P2P network (either as a

Re: [bitcoin-dev] Revisiting NODE_BLOOM: Proposed BIP

Its more of a statement of in the future, we expect things to happen which would make this an interesting thing to do, so we state here that it is not against spec to do so. Could reword it as NODE_BLOOM is distinct from NODE_NETWORK, and it is legal to advertise NODE_BLOOM but not NODE_NETWORK

Re: [bitcoin-dev] Libconsensus separated repository (was Bitcoin Core and hard forks)

I dont think a libconsensus would have any kind of networking layer, nor is C++ an antique tool set (hopefully libconsensus can avoid a boost dependency, though thats not antique either). Ideally it would have a simple API to give it blocks and a simple API for it to inform you of what the current

Re: [bitcoin-dev] Libconsensus separated repository (was Bitcoin Core and hard forks)

already obvious performance improvements. BTW, support for refactoring is an example where you see if your tool set is modern. There are a number of good development tools for C++ that allow this Tamas Blummer On Aug 20, 2015, at 19:44, Matt Corallo via bitcoin-dev bitcoin-dev

Re: [bitcoin-dev] Idea: Efficient bitcoin block propagation

On August 6, 2015 8:42:38 PM GMT+02:00, Gregory Maxwell via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: On Thu, Aug 6, 2015 at 6:17 PM, Tom Harding via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: - Will the relay network at least validate block version numbers in the

Re: [bitcoin-dev] Idea: Efficient bitcoin block propagation

No, don't think so, the protocol is, essentially, relay transactions, when you get a block, send header, iterate over transactions, for each, either use two bytes for nth-recent-transaction-relayed, use 0x-3-byte-length-transaction-data. There are quite a few implementation details, and

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

On 08/14/15 00:47, Mark Friedenbach via bitcoin-dev wrote: On Thu, Aug 13, 2015 at 4:42 PM, Joseph Poon via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org mailto:bitcoin-dev@lists.linuxfoundation.org wrote: I haven't tested the details of this, but is there another bit available

Re: [bitcoin-dev] Bitcoin Node Speed Test

You may see much better throughput if you run a few servers around the globe and test based on closest-by-geoip. TCP throughput is rather significantly effected by latency, though I'm not really sure what you should be testing here, ideally. On 07/23/15 14:19, slurms--- via bitcoin-dev wrote: On

[bitcoin-dev] Upcoming Transaction Priority Changes

On the IRC meeting today there was a long discussion on how to handle the old "transaction priority" stuff in 0.12. Over time the "transaction priority" stuff has added a huge amount of code and taken a bunch of otherwise-useful developer effort. There is still some debate about its usefulness

Re: [bitcoin-dev] Bitcoin-NG whitepaper.

That conversation missed a second issue. Namely that there is no way to punish people if there is a double spend in a micro block that happens in key block which reorg'd away the first transaction. eg one miner mines a transaction in a micro block, another miner (either by not having seen the

Re: [bitcoin-dev] Proposed new policy for transactions that depend on other unconfirmed transactions

t; On Fri, Aug 21, 2015 at 3:52 PM, Danny Thorpe ><danny.tho...@gmail.com> >>>> wrote: >>>> >>>>> The limits Alex proposed are generous (bordering on obscene!), but >>>>> dropping that down to allowing only two levels of chained >

Re: [bitcoin-dev] Scaling Bitcoin conference micro-report

I only have one "correction", included inline. On 09/16/15 21:32, Jeff Garzik via bitcoin-dev wrote: > > During Scaling Bitcoin, Bitcoin Core committers and notable contributors > got together and chatted about where a "greatest common denominator" > type consensus might be. The following is a

Re: [bitcoin-dev] Hash of UTXO set as consensus-critical

I believe the discussion here is on improving initial-sync time by simply skipping initial-sync and getting a committed-to utxo set. This is obviously a new security model in between SPV and full-node (I would call it SPV with future validation). Still, I'm not convinced it buys us anything, we

Re: [bitcoin-dev] Weekly development meetings on IRC

Yes, I'm aware, however they are closer to each other than UTC is to either :p. On September 18, 2015 4:31:28 PM EDT, Gregory Maxwell <gmaxw...@gmail.com> wrote: >On Fri, Sep 18, 2015 at 8:27 PM, Matt Corallo via bitcoin-dev ><bitcoin-dev@lists.linuxfoundation.org> wrote:

Re: [bitcoin-dev] Scaling Bitcoin conference micro-report

: > Correction of a correction, in-line: > > On Wed, Sep 16, 2015 at 5:51 PM, Matt Corallo via bitcoin-dev > <bitcoin-dev@lists.linuxfoundation.org > <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote: > > > - Many interested or at least willing to accept a &q

Re: [bitcoin-dev] [BIP Draft] Datastream compression of Blocks and Transactions

My issue is more that its additional complexity and attack surface, and for a very minor gain which should disappear with further optimization elsewhere and less that we absolutely shouldn't add compression because we're definitely gonna have issues. On 12/02/15 20:16, Peter Tschipper via

Re: [bitcoin-dev] [BIP Draft] Datastream compression of Blocks and Transactions

On December 3, 2015 7:02:20 AM GMT+08:00, Peter Tschipper wrote: >On 02/12/2015 2:23 PM, Matt Corallo wrote: >> My issue is more that its additional complexity and attack surface, >> and for a very minor gain >What is a minor gain? 15 to 27% compression sounds good

Re: [bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin

A large part of your argument is that SW will take longer to deploy than a hard fork, but I completely disagree. Though I do not agree with some people claiming we can deploy SW significantly faster than a hard fork, once the code is ready (probably a six month affair) we can get it deployed

Re: [bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin

.com> wrote: >On Wed, Dec 16, 2015 at 12:50 PM, Matt Corallo via bitcoin-dev < >bitcoin-dev@lists.linuxfoundation.org> wrote: > >> A large part of your argument is that SW will take longer to deploy >than a >> hard fork, but I completely disagree. Though I do not agre

Re: [bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin

of Bitcoin is that, if you're running a full node, you are provided reasonable security against accepting invalid transactions. On December 16, 2015 1:51:47 PM PST, Jameson Lopp <jameson.l...@gmail.com> wrote: >On Wed, Dec 16, 2015 at 12:50 PM, Matt Corallo via bitcoin-dev < >bitcoin-dev@

Re: [bitcoin-dev] Time to worry about 80-bit collision attacks or not?

So just because other attacks are possible we should weaken the crypto we use? You may feel comfortable weakening crypto used to protect a few billion dollars of other peoples' money, but I dont. On 01/07/16 23:39, Gavin Andresen via bitcoin-dev wrote: > Thanks, Ethan, that's helpful and I'll

Re: [bitcoin-dev] Time to worry about 80-bit collision attacks or not?

Indeed, anything which uses P2SH is obviously vulnerable if there is an attack on RIPEMD160 which reduces it's security only marginally. While no one thought hard about these attacks when P2SH was designed, we realized later this was not such a good idea to reuse the structure from P2PKH. Hence

Re: [bitcoin-dev] [BIP Draft] Datastream compression of Blocks and Transactions

I'm really not a fan of this at all. To start with, adding a compression library that is directly accessible to the network on financial software is a really, really scary idea. If there were a massive improvement, I'd find it acceptable, but the improvement you've shown really isn't all that

[bitcoin-dev] On Hardforks in the Context of SegWit

Hi all, I believe we, today, have a unique opportunity to begin to close the book on the short-term scaling debate. First a little background. The scaling debate that has been gripping the Bitcoin community for the past half year has taken an interesting turn in 2016. Until recently, there have

Re: [bitcoin-dev] A roadmap to a better header format and bigger block size

As for your stages idea, I generally like the idea (and mentioned it may be a good idea in my proposal), but am worried about scheduling two hard-forks at onceLets do our first hard-fork first with the things we think we will need anytime in the visible future that we have reasonable designs

Re: [bitcoin-dev] On Hardforks in the Context of SegWit

Thanks for keeping on-topic, replying to the proposal, and being civil! Replies inline. On 02/09/16 09:00, Anthony Towns via bitcoin-dev wrote: > On Mon, Feb 08, 2016 at 07:26:48PM +0000, Matt Corallo via bitcoin-dev wrote: >> As what a hard fork should look like in the context of s

Re: [bitcoin-dev] On Hardforks in the Context of SegWit

Oops, forgot to reply to your last point. Indeed, we could push for more place by just always having one 0-byte, but I'm not sure the added complexity helps anything? ASICs can never be designed which use more extra-nonce-space than what they can reasonably assume will always be available, so we

Re: [bitcoin-dev] On Hardforks in the Context of SegWit

On 02/09/16 22:10, Luke Dashjr wrote: > On Tuesday, February 09, 2016 10:00:44 PM Matt Corallo via bitcoin-dev wrote: >> Indeed, we could push for more place by just always having one 0-byte, >> but I'm not sure the added complexity helps anything? ASICs can never be >> de

Re: [bitcoin-dev] Making AsicBoost irrelevant

Yea, I think in any hardfork that we should be talking about, a part of it should include 1) fix the version field so its a static constant, 2) the merkle root becomes hash of the real block header 3) swap first 2 bytes of the merkle root with the timestamp's two high-order bits, 4) swap the next

Re: [bitcoin-dev] Making AsicBoost irrelevant

Replies inline. On 05/10/16 21:43, Sergio Demian Lerner via bitcoin-dev wrote: -snip- > But some ASIC companies already have cores that are better (on power, > cost, rate, temperature, etc.) than competing companies ASICs. Why do > you think a 10% improvement from AsicBoost is different from

Re: [bitcoin-dev] Compact Block Relay BIP

Replies inline. On May 10, 2016 5:23:55 PM EDT, Rusty Russell via bitcoin-dev wrote: >Gregory Maxwell writes: >> On Tue, May 10, 2016 at 5:28 AM, Rusty Russell via bitcoin-dev >> wrote: >>> I used

Re: [bitcoin-dev] Making AsicBoost irrelevant

Indeed, I think the "ASICs are bad, because 1-CPU-1-vote" arguments mostly died out long ago, and, indeed, the goal that many making those arguments had of building "unoptimizeable" ASICs failed with them. I think everyone understands that there will always be some ability to iterate on ASIC

Re: [bitcoin-dev] Making AsicBoost irrelevant

That's the reason for this post! All current major ASIC manufacturers have made warrants that they are not using AsicBoost (with the exception of the 21 Inc Bitcoin computer). The fact that the optimization was patented is what has required that we work to hardfork it out, not that people might

Re: [bitcoin-dev] Making AsicBoost irrelevant

Aside from patents related to the silicon manufacturing process itself and patents not yet published, yes, the process is unencumbered, and setting the correct precedent (that the community will fight large centralization risks) is important in the first case. Matt On May 11, 2016 9:23:21 PM

Re: [bitcoin-dev] Compact Block Relay BIP

Implemented a few of your suggestions. Also opened a formal pull request for the BIP at https://github.com/bitcoin/bips/pull/389 and the code at https://github.com/bitcoin/bitcoin/pull/8068. On 05/09/16 17:06, Pieter Wuille via bitcoin-dev wrote: > On 05/03/2016 12:13 AM, lf-lists at

Re: [bitcoin-dev] Compact Block Relay BIP

13:31:15 +0100 > Subject: Re: [bitcoin-dev] Compact Block Relay BIP > On Monday 02 May 2016 22:13:22 Matt Corallo via bitcoin-dev wrote: > > Thanks for putting in the time to make a spec! > > It looks good already, but I do think some more improvements can be made. > > &

Re: [bitcoin-dev] Anti-transaction replay in a hardfork

header format anyway, so am extra few lines of code to change a transaction version should be trivial. On January 26, 2017 12:21:37 PM EST, Gavin Andresen <gavinandre...@gmail.com> wrote: >On Wed, Jan 25, 2017 at 10:29 PM, Matt Corallo via bitcoin-dev < >bitcoin-dev@lists.linu

Re: [bitcoin-dev] Extension block softfork proposal

Hey Johnson, As you know I've always been a rather large critic of this approach. First a bit of background. Pieter's excellent post on the security of soft forks [1] covers pretty well why soft forks are preferable to hard forks by debunking much of the "soft forks are less secure" arguments.

Re: [bitcoin-dev] Forcenet: an experimental network with a new header format

it anymore, but if there is none left we should take all 4 bytes from the timestamp field). Matt On 01/28/17 02:32, Matt Corallo via bitcoin-dev wrote: > Looks cool, though I have a few comments inline. > > One general note - it looks like you're letting complexity run away fr

Re: [bitcoin-dev] Forcenet: an experimental network with a new header format

Looks cool, though I have a few comments inline. One general note - it looks like you're letting complexity run away from you a bit here. If the motivation for something is only weak, its probably not worth doing! A hard fork is something that must be undertaken cautiously because it has so much

Re: [bitcoin-dev] Forcenet: an experimental network with a new header format

Replies inline. On 01/28/17 07:28, Johnson Lau wrote: > >> On 28 Jan 2017, at 10:32, Matt Corallo > > wrote: >> >> Looks cool, though I have a few comments inline. >> >> One general note - it looks like you're letting complexity run

Re: [bitcoin-dev] Anti-transaction replay in a hardfork

"A. For users on both existing and new fork, anti-replay is an option, not mandatory" To maximize fork divergence, it might make sense to require this. Any sensible proposal for a hard fork would include a change to the sighash anyway, so might as well make it required, no? Matt On 01/24/17

Re: [bitcoin-dev] BIP151 protocol incompatibility

For the reasons Pieter listed, an explicit part of our version handshake and protocol negotiation is the exchange of otherwise-ignored messages to set up optional features. Peers that do not support this ignore such messages, just as if they had indicated they wouldn't support it, see, eg BIP

Re: [bitcoin-dev] BIP151 protocol incompatibility

I believe many, if not all, of those messages are sent irrespective of version number. In any case, I fail to see how adding any additional messages which are ignored by old peers amounts to a lack of backward compatibility. On February 13, 2017 11:54:23 AM GMT+01:00, Eric Voskuil

Re: [bitcoin-dev] BIP151 protocol incompatibility

Sorry, I'm still missing it... So your claim is that a) ignoring incoming messages of a type you do not recognize is bad, and thus b) we should be disconnecting/banning peers which send us messages we do not recognize (can you spell out why? Anyone is free to send your host address

Re: [bitcoin-dev] ScalingBitcoin 2015: Retarget - Call For Proposals Now Open

Hi all, For those who missed it, the deadline for submissions has been extended to Sept 9th so be sure to submit before then! We will be doing rolling acceptance this time around to try to get most responses out before the 23rd. Because a few folks seemed to have some confusion, the definition

Re: [bitcoin-dev] About ASICBoost

Replies to comments inline. Matt On 10/02/16 17:13, Sergio Demian Lerner via bitcoin-dev wrote: > Please Peter Todd explain here all what you want to say about a patent > of a hardware design for an ASIC. > > Remember that ASICBoost is not the only patent out there, there are at > least three

[bitcoin-dev] Bitcoin Core 0.13.1 release candidate 3

Due to a relatively trivial fix for an out-of-place assertion in rc2 (see https://github.com/bitcoin/bitcoin/commit/58d4fa7da30cb57e5fc3dca62f49a64e126c76cd), 0.13.1rc3 was tagged and is now available on github either via git or at https://github.com/bitcoin/bitcoin/releases/tag/v0.13.1rc3.

Re: [bitcoin-dev] Start time for BIP141 (segwit)

This start time seems reasonable to me. It is mostly in line with BIP 9's proposed defaults, which seems like an appropriate choice. On October 16, 2016 10:31:55 AM EDT, Pieter Wuille via bitcoin-dev wrote: >Hello all, > >We're getting ready for Bitcoin

Re: [bitcoin-dev] On the security of soft forks

I highly recommend you read the excellent thread on soft fork risks at https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012014.html and respond there instead of getting off topic for this thread. Matt On 10/16/16 16:42, Tom Zander via bitcoin-dev wrote: > On Sunday, 16

Re: [bitcoin-dev] (no subject)

You keep calling flexible transactions "safer", and yet you haven't mentioned that the current codebase is riddled with blatant and massive security holes. For example, you seem to have misunderstood C++'s memory model - you would have no less than three out-of-bound, probably exploitable memory

Re: [bitcoin-dev] Planned Obsolescence

One thing which hasn't been addressed yet in this thread is developer centralization. Unlike other applications we want to ensure that it's not only possible for users to refuse an upgrade, but easy. While this by no means lessens the retirement that users run up to date software for security

Re: [bitcoin-dev] Issolated Bitcoin Nodes

I haven't investigated, but you may be seeing segwit-invalid blocks...0.13.0+ nodes will enforce segwit as it activated some time ago on testnet, 0.12.X nodes will not. On March 23, 2017 3:37:34 PM PDT, Juan Garavaglia via bitcoin-dev wrote: >We notice

Re: [bitcoin-dev] Segregated witness p2p layer compatibility

Just to expand a tiny bit here, while the testnet setup of only a few nodes acting as "bridges", mainnet already has many systems which act as effective bridges today - there are several relay networks in use which effectively bypass the P2P network, including my legacy relay network (which

Re: [bitcoin-dev] Fraud proofs for block size/weight

It works today and can be used to prove exact size: the key observation is that all you need to show the length and hash of a transaction is the final SHA256 midstate and chunk (max 64 bytes). It also uses the observation that a valid transaction must be at least 60 bytes long for compression

Re: [bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For Comments

Hey Sergio, You appear to have ignored the last two years of Bitcoin hardfork research and understanding, recycling instead BIP 102 from 2015. There are many proposals which have pushed the state of hard fork research much further since then, and you may wish to read some of the posts on this

Re: [bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For Comments

Hey Sergio, You appear to have ignored the last two years of Bitcoin hardfork research and understanding, recycling instead BIP 102 from 2015. There are many proposals which have pushed the state of hard fork research much further since then, and you may wish to read some of the posts on this

Re: [bitcoin-dev] A Segwit2x BIP

This is horribly under-specified (ie not possible to implement from what you've written, and your implementation doesn't match at all, last I heard). > Specification > The plain block size is defined as the serialized block size without > witness programs. > Deploy a modified BIP91 to activate

Re: [bitcoin-dev] Full node "tip" function

If we ever have a problem getting blocks, we could consider adding something to pay to receive historical blocks but luckily that isn't a problem we have today - the available connection slots and bandwidth on the network today appears to be more than sufficient to saturate nearly any

Re: [bitcoin-dev] Some real-world results about the current Segwit Discount

I'm not sure who wrote segwit.org, but I wouldn't take it as authoritative reasoning why we must do X over Y. You seem to be claiming that there is not cost for a miner to fill "extra witness space", but this is very untrue - in order to do so they must forgo fees on other transactions. Your

Re: [bitcoin-dev] Some real-world results about the current Segwit Discount

I'm highly unconvinced of this point. Sure, you can change fewer lines of code, but if the result is, lets be honest, shit, how do you believe its going to have a higher chance of getting acceptance from the broader community? I think you're over-optimizing in the wrong direction. Matt On

Re: [bitcoin-dev] Some real-world results about the current Segwit Discount

I highly disagree about the "not shit" part. You're advocating for throwing away one of the key features of Segwit, something that is very important for Bitcoin's long-term reliability! If you think doing so is going to somehow help get support in a divided community, I don't understand how -

Re: [bitcoin-dev] Some real-world results about the current Segwit Discount

There is something in between throwing the SegWit goals out the window (as Sergio seems to be advocating for) and having a higher discount ratio (which is required for the soft fork version to be useful). When I first started looking at the problem I very much wanted to reduce the worst-case

Re: [bitcoin-dev] Reduced signalling threshold activation of existing segwit deployment

Given the overwhelming support for SegWit across the ecosystem of businesses and users, this seems reasonable to me. On May 22, 2017 6:40:13 PM EDT, James Hilliard via bitcoin-dev wrote: >I would like to propose an implementation that accomplishes the

Re: [bitcoin-dev] Barry Silbert segwit agreement

While I'm not 100% convinced there are strict technical reasons for needing to wait till after segwit is active before a hard fork can be started (you can, after all, activate segwit as a part of the HF), there are useful design and conservatism reasons (not causing massive discontinuity in fee

Re: [bitcoin-dev] BIP149 timeout-- why so far in the future?

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. Greg's proposed 6 months seems much more reasonable to me, assuming its still many months after the formal release of code implementing it.

Re: [bitcoin-dev] Barry Silbert segwit agreement

Your proposal seems to be simply BIP 91 tied to the as-yet-entirely-undefined hard fork Barry et al proposed. Using James' BIP 91 instead of the Barry-bit-4/5/whatever proposal, as you propose, would make the deployment on the incredibly short timeline Barry et al proposed slightly more

Re: [bitcoin-dev] BIP Proposal: Compact Client Side Filtering for Light Clients

Quick comment before I finish reading it completely, looks like you have no way to match the input prevouts being spent, which is rather nice from a "watch for this output being spent" pov. On June 1, 2017 3:01:14 PM EDT, Olaoluwa Osuntokun via bitcoin-dev

Re: [bitcoin-dev] Responsible disclosure of bugs

I believe there continues to be concern over a number of altcoins which are running old, unpatched forks of Bitcoin Core, making it rather difficult to disclose issues without putting people at risk (see, eg, some of the dos issues which are preventing release of the alert key). I'd encourage the

Re: [bitcoin-dev] Rebatable fees & incentive-safe fee markets

I'm somewhat curious what the authors envisioned the real-world implications of this model to be. While blindly asking users to enter what they're willing to pay always works in theory, I'd imagine in such a world the fee selection UX would be similar to what it is today - users are provided a

Re: [bitcoin-dev] Making OP_CODESEPARATOR and FindAndDelete in non-segwit scripts non-standard

Indeed, the PR in question does *not* change the semantics of OP_CODESEPARATOR within SegWit redeemScripts, where it is still allowed (and Nicolas Dorier pointed out that he was using it in TumbleBit), so there are still ways to use it, but only in places, like SegWit, where the potential

Re: [bitcoin-dev] Two Drivechain BIPs

Process note: It looks like the BIPs have never been posted to bitcoin-dev, only high-level discussion around the idea. As I understand it, this is *not* sufficient for BIP number assignment nor (realistically) sufficient to call it a hard "proposal" for a change to consensus rules. Would love to

Re: [bitcoin-dev] Simplicity: An alternative to Script

I admittedly haven't had a chance to read the paper in full details, but I was curious how you propose dealing with "jets" in something like Bitcoin. AFAIU, other similar systems are left doing hard-forks to reduce the sigops/weight/fee-cost of transactions every time they want to add useful

Re: [bitcoin-dev] Simplicity: An alternative to Script

in-formally-verified-equivalent-replacements?). Matt On 10/30/17 17:56, Mark Friedenbach wrote: > Script versions makes this no longer a hard-fork to do. The script > version would implicitly encode which jets are optimized, and what their > optimized cost is. > >> On Oct

Re: [bitcoin-dev] Simplicity: An alternative to Script

-formally-verified-equivalent-replacements?). >> >> Matt >> >>> On 10/30/17 17:56, Mark Friedenbach wrote: >>> Script versions makes this no longer a hard-fork to do. The script >>> version would implicitly encode which jets are optimized, and what their

Re: [bitcoin-dev] UHS: Full-node security without maintaining a full UTXO set

Hey Cory, I'm generally a fan of having an option to "prove a block is valid when relaying it" instead of "just relay it", but I am concerned that this proposal is overfitting the current UTXO set. Specifically, because UTXO entries are (roughly) 32 bytes per output plus 32 bytes per transaction

Re: [bitcoin-dev] BIP 158 Flexibility and Filter Size

. On May 17, 2018 3:43:15 PM UTC, Peter Todd <p...@petertodd.org> wrote: >On Thu, May 17, 2018 at 11:25:12AM -0400, Matt Corallo via bitcoin-dev >wrote: >> BIP 158 currently includes the following in the "basic" filter: 1) >> txids, 2) output scripts, 3) input pr

[bitcoin-dev] BIP 158 Flexibility and Filter Size

BIP 158 currently includes the following in the "basic" filter: 1) txids, 2) output scripts, 3) input prevouts. I believe (1) could be skipped entirely - there is almost no reason why you'd not be able to filter for, eg, the set of output scripts in a transaction you know about and (2) and (3)

Re: [bitcoin-dev] BIP 158 Flexibility and Filter Size

Maxwell wrote: > On Thu, May 17, 2018 at 3:25 PM, Matt Corallo via bitcoin-dev > <bitcoin-dev@lists.linuxfoundation.org> wrote: >> I believe (1) could be skipped entirely - there is almost no reason why >> you'd not be able to filter for, eg, the set of output scripts in a >&

[bitcoin-dev] [BIP Proposal] BetterHash Mining Protocol Replacements

Been working on this one for a while, so its already been through a few rounds of feeback (thanks to all those who already have provided feedback)! At a high level, this meets a few goals: 1) Replace getblocktemplate with something that is both more performant (no JSON encoding, no full

Re: [bitcoin-dev] [BIP Proposal] BetterHash Mining Protocol Replacements

> quite a bit less data than polling the request endpoint. > > > On 06/05/2018 02:44 PM, Matt Corallo via bitcoin-dev wrote: >> Been working on this one for a while, so its already been through a few >> rounds of feeback (thanks to all those who already have provided >>

Re: [bitcoin-dev] BetterHash status

Things go into production when people decide to adopt them, not before. You're welcome to contribute to the implementation at https://github.com/TheBlueMatt/mining-proxy On June 26, 2018 2:32:06 PM UTC, "Casciano, Anthony via bitcoin-dev" wrote: >What is the status of Matt Corallo's

Re: [bitcoin-dev] BIP-21 amendment proposal: -no125

While the usability of non-RBF transactions tends to be quite poor, there are some legitimate risk-analysis-based reasons why people use them (eg to sell BTC based on a incoming transaction which you will need to convert to fiat, which has low cost if the transaction doesn't confirm), and if

Re: [bitcoin-dev] Ivy: a higher-level language targeting Bitcoin Script

I'm curious if you've considered adding some form of compiler-time enforcement to prevent witness malleability? With that, Ivy could help to resolve for it's users one of the things that can make Bitcoin scripts more complicated to write, instead of simply type-checking and providing a

Re: [bitcoin-dev] Satoshilabs secret shared private key scheme

Or make it a part of your secret-split logic... Gotta love how fast GF(2^8) is: https://github.com/TheBlueMatt/shamirs/blob/master/main.c#L57 On January 17, 2018 3:31:44 PM UTC, Gregory Maxwell via bitcoin-dev wrote: >If the generalization isn't obvious,

Re: [bitcoin-dev] Taproot: Privacy preserving switchable scripting

Gah, please no. I see no material reason why cross-input signature aggregation shouldn't have the signatures in the first n-1 inputs replaced with something like a single-byte push where a signature is required to indicate aggregation, and the combined signature in the last input at whatever

Re: [bitcoin-dev] A BIP proposal for transactions that are 'cancellable'

I think a simple approach to what you want to accomplish is to simply have a multisig option with a locktime pre-signed transaction which is broadcastable at the 24h mark and has different spendability. This avoids introducing reorg-induced invalidity. On September 6, 2018 9:19:24 AM UTC,

[bitcoin-dev] A BIP proposal for transactions that are 'cancellable'

I think you misunderstood my proposal. What you'd do is the transaction is spendable by either Bob OR (Bob AND Alice) and before broadcast/during construction/whatever sign a new transaction that spends it and is only spendable by Alice, but is timelocked for 24 hours. At the 24h mark, Alice

Re: [bitcoin-dev] Taproot: Privacy preserving switchable scripting

t;<https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015537.html> >[2] >https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-September/015029.html ><https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-September/015029.html> > >> On Jan 22

[bitcoin-dev] CPFP Carve-Out for Fee-Prediction Issues in Contracting Applications (eg Lightning)

(cross-posted to both lists to make lightning-dev folks aware, please take lightning-dev off CC when responding). As I'm sure everyone is aware, Lightning (and other similar systems) work by exchanging pre-signed transactions for future broadcast. Of course in many cases this requires either

Re: [bitcoin-dev] CPFP Carve-Out for Fee-Prediction Issues in Contracting Applications (eg Lightning)

some form of package relay. Matt On 11/30/18 5:38 PM, Russell O'Connor wrote: On Fri, Nov 30, 2018 at 9:50 AM Matt Corallo via bitcoin-dev <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote: To partially-address the CPFP security model considerations, a next step might

Re: [bitcoin-dev] [Lightning-dev] CPFP Carve-Out for Fee-Prediction Issues in Contracting Applications (eg Lightning)

I responded to a few things in-line before realizing I think we're out of sync on what this alternative proposal actually implies. In my understanding is it, it does *not* imply that you are guaranteed the ability to RBF as fees change. The previous problem is still there - your counterparty

Re: [bitcoin-dev] [Lightning-dev] CPFP Carve-Out for Fee-Prediction Issues in Contracting Applications (eg Lightning)

Sorry for the late reply. Hmm, I included the old RBF-pinning proposal as a comparison. Personally, I find it both less clean and less convincingly secure. Ultimately, defining a "near the top of the mempool" criteria is fraught with issues. While it's probably OK for the original problem

  1   2   3   >