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

On Sun, Oct 16, 2016 at 10:58 AM, Tom Zander via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > The fallow period sounds wy to short. I suggest 2 months at minimum > since anyone that wants to be safe needs to upgrade. > I asked a lot of businesses and individuals how long it

Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes

On Tue, Feb 9, 2016 at 8:59 AM, Yifu Guo wrote: > > There are 406 nodes total that falls under the un-maintained category, > which is below 10% of the network. > Luke also have some data here that shows similar results. >

Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes

On Sat, Feb 6, 2016 at 3:46 PM, Luke Dashjr via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Saturday, February 06, 2016 5:25:21 PM Tom Zander via bitcoin-dev wrote: > > On Saturday, February 06, 2016 06:09:21 PM Jorge Timón via bitcoin-dev > wrote: > > > None of the reasons

Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes

On Sat, Feb 6, 2016 at 12:01 PM, Adam Back wrote: > > It would probably be a good idea to have a security considerations > section Containing what? I'm not aware of any security considerations that are any different from any other consensus rules change. (I can write a

Re: [bitcoin-dev] Hardfork bit BIP

It is always possible I'm being dense, but I still don't understand how this proposal makes a chain-forking situation better for anybody. If there are SPV clients that don't pay attention to versions in block headers, then setting the block version negative doesn't directly help them, they will

Re: [bitcoin-dev] BIP Process: Status, comments, and copyright licenses

On Mon, Feb 1, 2016 at 5:53 PM, Luke Dashjr via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > I've completed an initial draft of a BIP that provides clarifications on > the > Status field for BIPs, as well as adding the ability for public comments on > them, and expanding the list

Re: [bitcoin-dev] Best (block nr % 2016) for hard fork activation?

On Thu, Jan 28, 2016 at 9:31 PM, Jannes Faber via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi, > > Question if you'll allow me. This is not about Gavin's latest hard fork > proposal but in general about any hard (or soft) fork. > > I was surprised to see a period expressed in

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

On Fri, Jan 8, 2016 at 7:02 AM, Rusty Russell wrote: > 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

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

Thanks, Anthony, that works! So... 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? And Ethan or Anthony: can you think of a similar attack scheme if you assume we had switched to Schnorr 2-of-2

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

On Fri, Jan 8, 2016 at 10:50 AM, Gavin Andresen wrote: > But as I said earlier in the thread, there is a tradeoff here between > crypto strength and code complexity, and "the strength of the crypto is all > that matters" is NOT security first. I should be more explicit

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

On Fri, Jan 8, 2016 at 10:46 AM, Gavin Andresen wrote: > And Ethan or Anthony: can you think of a similar attack scheme if you > assume we had switched to Schnorr 2-of-2 signatures by then? Don't answer that, I was being dense again, Anthony's scheme works with

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

And to fend off the messag that I bet somebody is composing right now: Yes, I know about a "security first" mindset. But as I said earlier in the thread, there is a tradeoff here between crypto strength and code complexity, and "the strength of the crypto is all that matters" is NOT security

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

On Thu, Jan 7, 2016 at 6:52 PM, Pieter Wuille wrote: > Bitcoin does have parts that rely on economic arguments for security or > privacy, but can we please stick to using cryptography that is up to par > for parts where we can? It's a small constant factor of data, and

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

On Thu, Jan 7, 2016 at 8:26 PM, Matt Corallo wrote: > 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. > No... I'm

Re: [bitcoin-dev] Capacity increases for the Bitcoin system.

On Fri, Dec 11, 2015 at 11:18 AM, Jorge Timón wrote: > This is basically what I meant by > > struct hashRootStruct > { > uint256 hashMerkleRoot; > uint256 hashWitnessesRoot; > uint256 hashextendedHeader; > } > > but my design doesn't calculate other_root as it appears in your

Re: [bitcoin-dev] Capacity increases for the Bitcoin system.

On Wed, Dec 9, 2015 at 3:03 AM, Gregory Maxwell via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > I think it would be logical to do as part of a hardfork that moved > commitments generally; e.g. a better position for merged mining (such > a hardfork was suggested in 2010 as

Re: [bitcoin-dev] Capacity increases for the Bitcoin system.

Thanks for laying out a road-map, Greg. I'll need to think about it some more, but just a couple of initial reactions: Why segwitness as a soft fork? Stuffing the segwitness merkle tree in the coinbase is messy and will just complicate consensus-critical code (as opposed to making the right side

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

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-specific > compressor. This is the kind of

Re: [bitcoin-dev] OP_CHECKWILDCARDSIGVERIFY or "Wildcard Inputs" or "Coalescing Transactions"

On Tue, Nov 24, 2015 at 12:34 PM, Chris Priest via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > The technical reason for this is that you have to explicitly list each > UTXO individually when making bitcoin transactions. There is no way to > say "all the utxos". This post

Re: [bitcoin-dev] summarising security assumptions (re cost metrics)

On Thu, Nov 5, 2015 at 11:03 PM, Adam Back via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Some thoughts, hope this is not off-topic. > > Maybe we should summarise the security assumptions and design > requirements. It is often easier to have clear design discussions by > first

Re: [bitcoin-dev] A validation-cost metric for aggregate limits and fee determination

I have several thoughts: Weighing CPU validation cost should be reasonably straightforward-- just pick some arbitrary, commonly-available, recent hardware and then benchmark the two things that take the bulk of validation time (hashing to create the signature hash, then ECDSA validation), and

Re: [bitcoin-dev] Compatibility requirements for hard or soft forks

On Sun, Nov 1, 2015 at 6:46 PM, Tier Nolan via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > For guidelines > > * Transaction version numbers will be increased, if possible > * Transactions with unknown/large version numbers are unsafe to use with > locktime > * Reasonable notice

[bitcoin-dev] Is it possible for there to be two chains after a hard fork?

I keep seeing statements like this: On Tue, Sep 29, 2015 at 9:30 AM, Jonathan Toomim (Toomim Bros) via bitcoin-dev wrote: > As a further benefit to hard forks, anybody who is ideologically opposed > to the change can continue to use the old version

Re: [bitcoin-dev] Is it possible for there to be two chains after a hard fork?

We really shouldn't have to go over "Bitcoin 101" on this mailing list, and this discussion should move to the not-yet-created more general discussion list. I started this thread as a sanity check on myself, because I keep seeing smart people saying that two chains could persist for more than a

Re: [bitcoin-dev] Is it possible for there to be two chains after a hard fork?

On Tue, Sep 29, 2015 at 1:24 PM, Allen Piscitello < allen.piscite...@gmail.com> wrote: > I fail to see how always following a majority of miners no matter what > their actions somehow equates to insanity. Ok, I have a hidden assumption: I assume most miners are also not completely insane. I

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

I think three things need to happen: 1) Stop pretending that "everyone must agree to make consensus rule changes." "Rough consensus" is what we've always gone with, and is good enough. 2) Mr. Todd (or somebody) needs to write up a risk/benefit security tradeoff analysis doo-hickey document and

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

On Mon, Sep 28, 2015 at 9:28 AM, Peter Todd wrote: > > 2) Mr. Todd (or somebody) needs to write up a risk/benefit security > > tradeoff analysis doo-hickey document and publish it. I'm reasonably > > confident that the risks to SPV nodes can be mitigated (e.g. by deploying >

[bitcoin-dev] Weak block thoughts...

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 to pre-announce blocks that they're working on,

Re: [bitcoin-dev] Weak block thoughts...

On Wed, Sep 23, 2015 at 3:24 PM, Gregory Maxwell <gmaxw...@gmail.com> wrote: > On Wed, Sep 23, 2015 at 3:43 PM, Gavin Andresen via bitcoin-dev > <bitcoin-dev@lists.linuxfoundation.org> wrote: > [...] > > A miner could try to avoid validation work by just taking

Re: [bitcoin-dev] [BIP Proposal] Version bits with timeout and delay.

I say keep it simple. If the 75% threshold is hit, then support suddenly drops off below 50%, "meh" -- there will be a big ruckus, everybody will freak out, and miners will refuse to build big blocks because they'll worry that they'll get orphaned. Adding more complexity for a case that ain't

Re: [bitcoin-dev] Dynamic limit to the block size - BIP draft discussion

> > 3) Let me put it another way, I've read that both Gavin and yourself are > favorable to a dynamic limit on the block size. In your view, what is > missing from this proposal, or what variables should be adjusted, to get > the rules to a place where you and other Core developers would seriously

Re: [bitcoin-dev] Fees and the block-finding process

On Fri, Aug 7, 2015 at 1:33 PM, Jorge Timón jti...@jtimon.cc wrote: On Aug 7, 2015 5:55 PM, Gavin Andresen gavinandre...@gmail.com wrote: I think there are multiple reasons to raise the maximum block size, and yes, fear of Bad Things Happening as we run up against the 1MB limit is one of

Re: [bitcoin-dev] What Lightning Is

While we're on the subject of payment hubs / lightning network... I'd love to see somebody write up a higher-level description of what the user experience is like, what communication happens underneath, and what new pieces of infrastructure need to get built to make it all work. A use-case to

[bitcoin-dev] Fees and the block-finding process

Popping this into it's own thread: Jorge asked: 1) If not now, when will it be a good time to let the market minimum fee for miners to mine a transaction rise above zero? I answered: 1. If you are willing to wait an infinite amount of time, I think the minimum fee will always be zero

Re: [bitcoin-dev] Fees and the block-finding process

On Fri, Aug 7, 2015 at 11:16 AM, Pieter Wuille pieter.wui...@gmail.com wrote: I guess my question (and perhaps that's what Jorge is after): do you feel that blocks should be increased in response to (or for fear of) such a scenario. I think there are multiple reasons to raise the maximum

Re: [bitcoin-dev] Fwd: Block size following technological growth

On Fri, Aug 7, 2015 at 12:30 PM, Pieter Wuille via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: If the incentives for running a node don't weight up against the cost/difficulty using a full node yourself for a majority of people in the ecosystem, I would argue that there is a

Re: [bitcoin-dev] Block size following technological growth

On Thu, Aug 6, 2015 at 1:15 PM, Jorge Timón jti...@jtimon.cc wrote: So I reformulate the question: 1) If not now, when will it be a good time to let the market minimum fee for miners to mine a transaction rise above zero? Two answers: 1. If you are willing to wait an infinite amount of

Re: [bitcoin-dev] Block size following technological growth

On Wed, Aug 5, 2015 at 9:26 PM, Jorge Timón bitcoin-dev@lists.linuxfoundation.org wrote: This is a much more reasonable position. I wish this had been starting point of this discussion instead of the block size limit must be increased as soon as possible or bitcoin will fail. It REALLY

Re: [bitcoin-dev] Block size following technological growth

On Thu, Aug 6, 2015 at 10:06 AM, Pieter Wuille pieter.wui...@gmail.com wrote: But you seem to consider that a bad thing. Maybe saying that you're claiming that this equals Bitcoin failing is an exaggeration, but you do believe that evolving towards an ecosystem where there is competition for

[bitcoin-dev] Fwd: Block size following technological growth

On Thu, Aug 6, 2015 at 10:53 AM, Pieter Wuille pieter.wui...@gmail.com wrote: So if we would have 8 MB blocks, and there is a sudden influx of users (or settlement systems, who serve much more users) who want to pay high fees (let's say 20 transactions per second) making the block chain

Re: [bitcoin-dev] Block size following technological growth

On Thu, Aug 6, 2015 at 11:25 AM, Jorge Timón jti...@jtimon.cc wrote: 1) If not now when will it be a good time to let fees rise above zero? Fees are already above zero. See http://gavinandresen.ninja/the-myth-of-not-full-blocks 2) When will you consider a size to be too dangerous for

Re: [bitcoin-dev] Superluminal communication and the consensus block size limit

On Wed, Aug 5, 2015 at 7:24 PM, Jorge Timón bitcoin-dev@lists.linuxfoundation.org wrote: Miner A is able to process 100 M tx/block while miner B is only able to process 10 M tx/block. Will miner B be able to maintain itself competitive against miner B? The answer is: it depends on the

Re: [bitcoin-dev] Block size following technological growth

On Tue, Aug 4, 2015 at 7:27 AM, Pieter Wuille via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: I would say that things already demonstrately got terrible. The mining landscape is very centralized, with apparently a majority depending on agreements to trust each other's announced

[bitcoin-dev] Eli Dourado on governance

I haven't seen this excellent recent blog post by Eli Dourado referenced here: https://readplaintext.com/how-should-bitcoin-be-governed-680192fcd92b I agree with his conclusions: we need better communication/organization mechanisms among 'stakeholders' and between the various factions

Re: [bitcoin-dev] Eli Dourado on governance

On Mon, Aug 3, 2015 at 6:13 PM, GJB ba...@auspira.com wrote: Do you mean something like a Foundation? No, I think one of the fundamental problems with the Foundation is it tries to represent everybody's interests. The interests of exchanges are not necessarily the same as end-users or miners,

Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn'ttemporary

On Thu, Jul 30, 2015 at 11:24 AM, Bryan Bishop via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: Because any decentralized system is going to have high transaction costs and scarcity anyway. This is a meme that keeps coming up that I think just isn't true. What other

Re: [bitcoin-dev] For discussion: limit transaction size to mitigate CVE-2013-2292

After thinking about it, implementing it, and doing some benchmarking, I'm convinced replacing the existing, messy, ad-hoc sigop-counting consensus rules is the right thing to do. The last two commits in this branch are an implementation:

Re: [bitcoin-dev] Bitcoin Core and hard forks

On Thu, Jul 23, 2015 at 12:17 PM, Tom Harding via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: On 7/23/2015 5:17 AM, Jorge Timón via bitcoin-dev wrote: they will simply advance the front and start another battle, because their true hidden faction is the not ever side. Please,

Re: [bitcoin-dev] For discussion: limit transaction size to mitigate CVE-2013-2292

On Mon, Jul 20, 2015 at 4:55 PM, Gregory Maxwell gmaxw...@gmail.com wrote: On Mon, Jul 20, 2015 at 7:10 PM, Gavin Andresen via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: Mitigate a potential CPU exhaustion denial-of-service attack by limiting the maximum size of a transaction

[bitcoin-dev] For discussion: limit transaction size to mitigate CVE-2013-2292

Draft BIP to prevent a potential CPU exhaustion attack if a significantly larger maximum blocksize is adopted: Title: Limit maximum transaction size Author: Gavin Andresen gavinandre...@gmail.com Status: Draft Type: Standards Track Created: 2015-07-17 ==Abstract== Mitigate a potential

Re: [bitcoin-dev] For discussion: limit transaction size to mitigate CVE-2013-2292

On Mon, Jul 20, 2015 at 3:43 PM, Tier Nolan via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: This could render transactions with a locktime in the future as unspendable. It is pretty low probability that someone has created a 100kB locked transaction though. It violates the