Re: [bitcoin-dev] BIP Draft: Minimum Viable TXIn Hash

On Thursday, July 23, 2015 8:12:19 PM Jeremy Rubin via bitcoin-dev wrote: Please see the following draft BIP which should decrease the amount of bytes needed per transaction. This is very much a draft BIP, as the design space for this type of improvement is large. This BIP can be rolled out

Re: [bitcoin-dev] [Bitcoin-development] Reusable payment codes

On Friday, April 24, 2015 8:00:46 PM Justus Ranvier wrote: > This link contains an RFC for a new type of Bitcoin address called a > "payment code" Sorry for the late review. I'm concerned with the "notification address" requirement, which entails address reuse and blockchain spam. Since it

Re: [bitcoin-dev] [Bitcoin-development] Reusable payment codes

On Thursday, October 22, 2015 8:58:58 PM Justus Ranvier wrote: > I strongly disagree with this statement. Well, I strongly disagree with adopting the BIP as it stands. > Version 1 payment codes are designed to be deployable by wallet > implementers today, without requiring them to wait on any

Re: [bitcoin-dev] [Bitcoin-development] Reusable payment codes

On Thursday, October 22, 2015 2:55:14 PM Justus Ranvier wrote: > On 22/10/15 00:53, Luke Dashjr wrote: > > Sorry for the late review. I'm concerned with the "notification address" > > requirement, which entails address reuse and blockchain spam. Since it > > entails address reuse, the recipient is

Re: [bitcoin-dev] Composite priority: combining fees and bitcoin-days into one number

On Wednesday, October 28, 2015 4:26:52 AM Jonathan Toomim via bitcoin-dev wrote: > Assigning 5% of block space based on bitcoin-days destroyed (BDD) and the > other 95% based on fees seems like a rather awkward approach to me. For > one thing, it means two code paths in pretty much every

Re: [bitcoin-dev] [patch] Switching Bitcoin Core to sqlite db

On Thursday, October 29, 2015 6:57:39 AM telemaco via bitcoin-dev wrote: > Why not allow two options: > > 1/ a default RocksDB/SQLite/LevelDB (whatever is decided) > 2/ alternative provide instructions for connection to any other rdbms > using odbc or jdbc. I predict this would be a disaster.

Re: [bitcoin-dev] Composite priority: combining fees and bitcoin-days into one number

On Wednesday, October 28, 2015 10:41:39 PM Jonathan Toomim wrote: > On Oct 28, 2015, at 12:13 AM, Luke Dashjr wrote: > > On Wednesday, October 28, 2015 4:26:52 AM Jonathan Toomim via bitcoin-dev > > wrote: > > > > This is all in the realm of node policy, which must be easy to >

Re: [bitcoin-dev] Upcoming Transaction Priority Changes

On Thursday, November 12, 2015 7:47:50 PM Matt Corallo via bitcoin-dev wrote: > With the mempool limiting stuff already in git master, high-priority > relay is disabled when mempools are full. In addition, there was > agreement to take the following steps for 0.12: > > * Mining code will use

Re: [bitcoin-dev] Upcoming Transaction Priority Changes

On Thursday, November 12, 2015 8:20:45 PM Chun Wang wrote: > The sort by priority part in the block is always the best place for spam > nowadays. What are you saying here? Spammers generally can't use the priority space at all, and it is a major way for legitimate users to get their transactions

Re: [bitcoin-dev] BIP - Block size doubles at each reward halving with max block size of 32M

On Friday, November 13, 2015 9:50:47 AM John Sacco wrote: > * 2 MB, height 420,000 < 630,000; (fork active when 75% of last 1,000 blocks > signal support and block 420,000 reached, ~July 2016) I'd leave out the block signalling. It isn't really useful, complicates the whole BIP, and mistakenly

Re: [bitcoin-dev] BIP - Block size doubles at each reward halving with max block size of 32M

On Friday, November 13, 2015 4:01:09 PM digi...@gmail.com wrote: > Forgive the frankness but I don't see why signaling your intent to support > an upgrade to one side of a hard fork can be seen as a bad thing. If for > nothing else doesn't this make for a smoother flag day? (Because once you >

Re: [bitcoin-dev] [patch] Switching Bitcoin Core to sqlite db

On Sunday, November 15, 2015 1:02:33 AM Peter R via bitcoin-dev wrote: > A group of us have been exploring this “meta-cognition” idea with Bitcoin > Unlimited. For example, Bitcoin Unlimited can be (optionally) made to > automatically fork to the longest chain if it “gets stuck” and can neither >

[bitcoin-dev] BIP 113: Median time-past is a HARDfork, not a softfork!

BIP 113 makes things valid which currently are not (any transaction with a locktime between the median time past, and the block nTime). Therefore it is a hardfork. Yet the current BIP describes and deploys it as a softfork. Furthermore, Bitcoin Core one week ago merged #6566 adding BIP 113

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

On Monday, November 02, 2015 12:23:27 AM Justus Ranvier via bitcoin-dev wrote: > It's a lot easier to justify the position: "nobody has the right to > change the meaning of someone else's outputs", than it is to justify, > "some small group of people gets to decide what's standard and what >

Re: [bitcoin-dev] BIP 113: Median time-past is a HARDfork, not a softfork!

On Monday, November 02, 2015 4:27:50 AM jl2...@xbt.hk wrote: > Currently, a tx maybe included in a block only if its locktime (x) is > smaller than the timestamp of a block (y) > > BIP113 says that a tx maybe included in a block only if x is smaller > than the median-time-past (z) > > It is

Re: [bitcoin-dev] [BIP] Normalized transaction IDs

On Tuesday, November 03, 2015 9:44:02 PM Christian Decker wrote: > Ok, so assuming we can get a connected component of upgraded nodes that > relay both the transaction and the associated external scripts then we > could just piggyback the external scripts on top of the normal messages. >

Re: [bitcoin-dev] [BIP] Normalized transaction IDs

On Thursday, November 05, 2015 3:27:37 PM Jorge Timón wrote: > On Tue, Nov 3, 2015 at 11:01 PM, Luke Dashjr via bitcoin-dev > > <bitcoin-dev@lists.linuxfoundation.org> wrote: > > On Tuesday, November 03, 2015 9:44:02 PM Christian Decker wrote: > >> So this is indeed

Re: [bitcoin-dev] Proposed list moderation policy and conduct

On Thursday, October 15, 2015 12:02:21 AM Jeff Garzik via bitcoin-dev wrote: > 2. If someone asks for help it is because they need it. Politely suggest > specific documentation or more appropriate venues where appropriate. Avoid > aggressive or vague responses. This could get noisy. Clarification

Re: [bitcoin-dev] [BIP] Normalized transaction IDs

On Wednesday, October 21, 2015 7:39:45 AM Christian Decker wrote: > On Wed, Oct 21, 2015 at 8:19 AM Luke Dashjr wrote: > > This doesn't completely close malleability (which should be documented in > > the BIP), so I'm not sure it's worth the cost, especially if closing > >

Re: [bitcoin-dev] This thread is not about the soft/hard fork technical debate

Copyright doesn't care how notices are written. They are merely informative to humans reading them. Anyhow, this is not development related, so please direct any further discussion of it to me directly (with any applicable CCs) and NOT to the mailing list. Thanks, Luke On Tuesday, October

Re: [bitcoin-dev] This thread is not about the soft/hard fork technical debate

On Tuesday, October 06, 2015 3:39:59 AM Milly Bitcoin via bitcoin-dev wrote: > In any case if I could get a list of "Core Developers" as referenced in > the copyright notice that would also be good since that is a legal notice. The copyright notice refers to the fact that each contributor owns

Re: [bitcoin-dev] RFC: HD Bitmessage address derivation based on BIP-43

On Friday, September 04, 2015 5:48:48 PM Justus Ranvier wrote: > On 09/03/2015 07:06 PM, Luke Dashjr via bitcoin-dev wrote: > > Since BIP 43 is still a draft, I propose modifying it to refer non- > > > > Bitcoin purpose codes to the SLIP repository: > > https:

Re: [bitcoin-dev] [BIP/Draft] BIP Acceptance Process

On Friday, September 04, 2015 8:13:18 PM Andy Chase via bitcoin-dev wrote: > Who makes high-level Bitcoin decisions? Miners, client devs, merchants, or > users? Let's set up a system where everyone has a say and clear acceptance > can be reached. For hardforks (removing consensus rules), economic

Re: [bitcoin-dev] BIP 100 repo

On Wednesday, September 02, 2015 11:58:54 PM Jeff Garzik via bitcoin-dev wrote: > The repo: https://github.com/jgarzik/bip100 What is the purpose of the newly added 1 MB floor? It seems clear from the current information available that 1 MB is presently too high for the limit, and it is

Re: [bitcoin-dev] [BIP/Draft] BIP Acceptance Process

On Friday, September 04, 2015 9:36:42 PM Andy Chase wrote: > I understand your concerns. What kinds of changes do you think should go > through a process like this? Just hard forks? The process loses meaning if it doesn't reflect reality. So only hardforks should go through the hardfork process;

Re: [bitcoin-dev] RFC: HD Bitmessage address derivation based on BIP-43

On Tuesday, June 30, 2015 5:53:05 PM Justus Ranvier wrote: > Monetas has developed a Bitmessage address derivation method from an > HD seed based on BIP-43. > > https://github.com/monetas/bips/blob/bitmessage/bip-bm01.mediawiki > > We're proposing this as a BIP per the BIP-43 recommendation in

Re: [bitcoin-dev] [BIP/Draft] BIP Acceptance Process

On Friday, September 04, 2015 12:30:50 AM Andy Chase via bitcoin-dev wrote: > Here's a BIP. I wrote the BIP mostly to stir the pot on ideas of > governance, but I’m moderately serious about it. Sigh. There is *no governance at all*. Any such a BIP like this needs to document the natural forces

Re: [bitcoin-dev] URI scheme for signing and verifying messages

On Monday, September 14, 2015 6:57:01 PM Arthur - bitcoin-fr.io via bitcoin- dev wrote: > Hi,I realized that there isn't any way to ask for a signature (or to verify > a message) as easily you can do when requesting a payment using a bitcoin > URI scheme (BIP0021).I think a URI scheme to use the

Re: [bitcoin-dev] URI scheme for signing and verifying messages

On Tuesday, September 15, 2015 10:49:36 AM Arthur - bitcoin-fr.io wrote: > September 15 2015 6:04 AM, "Luke Dashjr" wrote: > > I think probably the whole signed message thing needs to be rethought. > > The most common "uses" today seem to be insecure cases that it doesn't > >

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

On Friday, September 18, 2015 1:07:10 AM Wladimir J. van der Laan via bitcoin-dev wrote: > At Monday's code sprint we had a good idea to schedule a regular developer > meeting in #bitcoin-dev. > > Attendance is of course voluntary, but it may be good to have a time that > many people are

Re: [bitcoin-dev] Bitcoin Core 0.12.0 release schedule

On Thursday, September 24, 2015 11:25:56 AM Wladimir J. van der Laan via bitcoin-dev wrote: > 2015-12-01 > --- > - Feature freeze Where is "Consensus freeze"? Shouldn't this be put off until after the HK workshop in case a hardfork is decided on? Or have we de-coupled it from the

Re: [bitcoin-dev] Fwd: Bitcoin Core 0.12.0 release schedule

On Thursday, October 01, 2015 9:41:25 AM Marcel Jamin via bitcoin-dev wrote: > I guess the question then becomes why bitcoin still is <1.0.0 > > I'd say it's safe to say that it's used in production. But it's not *ready* to be used in production. :( For 1.0, I would expect:

Re: [bitcoin-dev] Dev-list's stance on potentially altering the PoW algorithm

On Friday, October 02, 2015 8:02:43 AM Daniele Pinna via bitcoin-dev wrote: > I am however interested in the dev-list's stance on potentially > altering the bitcoin PoW protocol should an algorithm that guarantees > protection from ASIC/FPGA optimization be found. > > I assume that, given the

Re: [bitcoin-dev] Fill-or-kill transaction

On Thursday, September 17, 2015 7:14:38 PM Jorge Timón via bitcoin-dev wrote: > As Mark points out this can be made safe by requiring that all the outputs > of a transaction that can expire have op_maturity/csv/rcltv of 100. That > makes them as reorg-safe as coinbase transactions. Not quite as

Re: [bitcoin-dev] This thread is not about the soft/hard fork technical debate

On Monday, October 05, 2015 3:56:33 PM Sergio Demian Lerner via bitcoin-dev wrote: > Some of the people on this mailing list are blindly discussing the > technicalities of a soft/hard fork without realizing that is not Mike's > main intention. At least I perceive (and maybe others too) something

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

On Tuesday, December 08, 2015 11:40:42 PM Jonathan Toomim via bitcoin-dev wrote: > Agree. This data does not belong in the coinbase. That space is for miners > to use, not devs. This has never been guaranteed, nor are softforks a "dev action" in the first place. > I also think that a hard fork

Re: [bitcoin-dev] [BIP Draft] Decentralized Improvement Proposals

On Wednesday, December 30, 2015 4:35:17 PM Tomas via bitcoin-dev wrote: > In an attempt to reduce developer centralization, and to reduce the risk > of forks introduced by implementation other than bitcoin-core, I have > drafted a BIP to support changes to the protocol from different >

Re: [bitcoin-dev] BIP141 segwit consensus rule update: extension of witness program definition

On Wednesday, June 08, 2016 8:23:51 AM Johnson Lau wrote: > If someday 32 bytes hash is deemed to be unsafe, the txid would also be > unsafe and a hard fork might be needed. Therefore, I don’t see how a > witness program larger than 40 bytes would be useful in any case (as it is > more expensive

Re: [bitcoin-dev] BIP141 segwit consensus rule update: extension of witness program definition

On Wednesday, June 08, 2016 5:57:36 AM Johnson Lau via bitcoin-dev wrote: > Why not make it even bigger, e.g. 75 bytes? I don't see a sufficient answer to this question. Pieter explained why >75 would be annoying, but 75 seems like it should be fine. > In any case, since scripts with a 1-byte

Re: [bitcoin-dev] RFC for BIP: Best Practices for Heterogeneous Input Script Transactions

On Thursday, May 19, 2016 4:18:15 AM Kristov Atlas via bitcoin-dev wrote: > BIP: TBD This is assigned BIP 126. > * '''Heterogenous input script transaction (HIT)''': A transaction > containing multiple inputs where not all inputs have identical scripts > (e.g. a transaction spending from more

Re: [bitcoin-dev] BIP draft: Memo server

First of all, and most importantly, I like the idea/concept. The first issue I see is that this scheme exposes private information in the form of which inputs/outputs are related to the user. But IMO this information should also be private and kept encrypted, so memo servers don't have anything

Re: [bitcoin-dev] Even more proposed BIP extensions to BIP 0070

On Tuesday, June 21, 2016 9:42:39 PM Erik Aronesty wrote: > > What do you mean by "replacement addresses" and "UI confirms" here? > > "Replacement addresses" would take the place of BIP 32/47 support, if > someone thought maybe that was too difficult to deal with. So each time i > paid Alice,

Re: [bitcoin-dev] Even more proposed BIP extensions to BIP 0070

On Monday, June 20, 2016 5:33:32 PM Erik Aronesty via bitcoin-dev wrote: > BIP 0070 has been a a moderate success, however, IMO: > > - protocol buffers are inappropriate since ease of use and extensibility is > desired over the minor gains of efficiency in this protocol. Not too late > to

Re: [bitcoin-dev] [BIP/Draft] BIP Acceptance Process

On Saturday, September 05, 2015 9:19:51 PM Andy Chase wrote: > Okay for sure yeah writing another proposal that reflects the current state > of affairs as people see it might provide some interesting perspective on > this proposal. I would welcome that. Are you saying your proposal is

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

rusted to not increase the block size until necessary (which is not likely to be any time soon, despite the massive misinformation campaigns out there). > On Sat, Feb 6, 2016 at 1:12 AM, Luke Dashjr via bitcoin-dev > > > > Miners express their support for this BIP by ... > > &g

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

On Thursday, February 04, 2016 5:45:38 PM Ryan Grant wrote: > [BIP 2:] > > A process BIP may change status from Draft to Active when it > > achieves rough consensus on the mailing list. > > Is this mix of wiki and mailing list intentional? If so, the wiki > talk page is meant to be a

[bitcoin-dev] Pre-BIP Growth Soft-hardfork

Here's a draft BIP I wrote almost a year ago. I'm going to look into revising and completing it soon, and would welcome any suggestions for doing so. This hardfork BIP aims to accomplish a few important things: - Finally deploying proper merge-mining as Satoshi suggested before he left. -

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

On Sunday, February 07, 2016 2:16:02 PM Gavin Andresen wrote: > 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: > > > If you hav

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

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 > designed which use more extra-nonce-space than what they can

[bitcoin-dev] BIP Final status

https://github.com/bitcoin/bips/pull/314 proposes updating the status of many Accepted BIPs to Final: BIP 11: M-of-N Standard Transactions BIP 14: Protocol Version and User Agent BIP 21: URI Scheme BIP 22: getblocktemplate - Fundamentals BIP 23: getblocktemplate - Pooled Mining BIP 31: Pong

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

On Friday, February 05, 2016 8:51:08 PM Gavin Andresen via bitcoin-dev wrote: > Blog post on a couple of the constants chosen: > http://gavinandresen.ninja/seventyfive-twentyeight Can you put this in the BIP's Rationale section (which appears to be mis-named "Discussion" in the current draft)?

Re: [bitcoin-dev] SegWit GBT updates

On Monday, February 01, 2016 6:41:06 PM Cory Fields wrote: > Noticeably absent here is the "default_witness_commitment" key, as > added by the current reference implementation[0]. > > I assume (please correct me if I'm wrong) that this has been omitted > for the sake of having clients create the

Re: [bitcoin-dev] [BIP Draft] Allow zero value OP_RETURN in Payment Protocol

On Tuesday, February 02, 2016 5:16:30 PM Pieter Wuille via bitcoin-dev wrote: > On Feb 2, 2016 18:04, "Peter Todd via bitcoin-dev" < > > bitcoin-dev@lists.linuxfoundation.org> wrote: > > On Tue, Jan 26, 2016 at 09:44:48AM -0800, Toby Padilla via bitcoin-dev > > wrote: > > > I really don't like

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

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 of allowable BIP licenses. https://github.com/luke-jr/bips/blob/bip-biprevised/bip-biprevised.mediawiki I plan

Re: [bitcoin-dev] SegWit GBT updates

On Tuesday, February 02, 2016 1:40:49 AM Cory Fields wrote: > On Mon, Feb 1, 2016 at 6:08 PM, Luke Dashjr wrote: > > On Monday, February 01, 2016 9:43:33 PM Cory Fields wrote: > >> On Mon, Feb 1, 2016 at 2:46 PM, Luke Dashjr wrote: > >> > Allowing for simpler

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

On Tuesday, February 02, 2016 3:58:21 PM Gavin Andresen wrote: > I don't like the definition of "consensus". I think the definition > described gives too much centralized control to whoever controls the > mailing list and the wiki. How can I improve this? Inevitably, every medium of

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

On Monday, February 01, 2016 10:53:16 PM Luke Dashjr via bitcoin-dev 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 of allowable BIP

[bitcoin-dev] SegWit GBT updates

I've completed an initial draft of a BIP for updating getblocktemplate for segregated witness here: https://github.com/luke-jr/bips/blob/segwit_gbt/bip-segwit-gbt.mediawiki Please review and comment (especially with regard to the changes in the sigoplimits handling). (Note: libblkmaker's

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

On Tuesday, February 02, 2016 11:28:40 PM Dave Scotese wrote: > How about "defining" (rules, code, etc.) Such code and rules define what > bitcoin is. It does require consensus and it ends up being a concord, but > all that can come after the fact (just as it did after bitcoin was first >

Re: [bitcoin-dev] [BIP Draft] Allow zero value OP_RETURN in Payment Protocol

This is a bad idea. OP_RETURN attachments are tolerated (not encouraged!) for the sake of the network, since the spam cannot be outright stopped. If it could be outright stopped, it would not be reasonable to allow OP_RETURN. When it comes to the payment protocol, however, changing the current

Re: [bitcoin-dev] [BIP Draft] Allow zero value OP_RETURN in Payment Protocol

On Tuesday, January 26, 2016 2:54:16 AM Toby Padilla wrote: > Luke - As stated in the Github thread, I totally understand where you're > coming from but the fact is people *will* encode data on the blockchain > using worse methods. For all of the reasons that OP_RETURN was a good idea > in the

Re: [bitcoin-dev] [BIP Draft] Allow zero value OP_RETURN in Payment Protocol

On Tuesday, January 26, 2016 3:01:13 AM Toby Padilla wrote: > > As I explained, none of those reasons apply to PaymentRequests. > > As they exist today PaymentRequests allow for essentially the same types of > transactions as non-PaymentRequest based transactions with the limitation > that

Re: [bitcoin-dev] [BIP Draft] Allow zero value OP_RETURN in Payment Protocol

On Tuesday, January 26, 2016 3:17:12 AM Toby Padilla wrote: > I don't think every application of OP_RETURN could be classified as "spam". Perhaps not, but in this context I cannot think of any non-spam use cases. Use cases should come before changes to support them. > I also don't think burning

Re: [bitcoin-dev] [BIP Proposal] New "feefilter" p2p message

On Tuesday, February 16, 2016 8:20:26 PM Alex Morcos via bitcoin-dev wrote: > # The feefilter message is defined as a message containing an int64_t where > pchCommand == "feefilter" What happened to extensibility? And why waste 64 bits for what is almost certainly a small number? > # The fee

Re: [bitcoin-dev] [BIP Proposal] New "feefilter" p2p message

On Wednesday, February 17, 2016 2:28:31 AM Alex Morcos wrote: > On Tue, Feb 16, 2016 at 6:46 PM, Luke Dashjr wrote: > > On Tuesday, February 16, 2016 8:20:26 PM Alex Morcos via bitcoin-dev wrote: > > > # The feefilter message is defined as a message containing an int64_t > > >

Re: [bitcoin-dev] BIP 2 promotion to Final

On Thursday, March 10, 2016 2:02:15 PM Mustafa Al-Bassam wrote: > On 10/03/16 00:53, Luke Dashjr wrote: > > On Thursday, March 10, 2016 12:29:16 AM Mustafa Al-Bassam wrote: > >>> A hard-fork BIP requires adoption from the entire Bitcoin economy, > >>> particularly including those selling desirable

Re: [bitcoin-dev] BIP 2 promotion to Final

On Wednesday, March 16, 2016 8:43:09 PM Btc Drak wrote: > I have an objection about "BIP comments" in BIP2. I think BIPs should be > self contained, but the specification recommends posting comments to the > Bitcoin Wiki (bitcoin.it). I think this is a bad idea and external sources > are bound to

Re: [bitcoin-dev] Proposed BIP extension to BIP 0070

Is there a way for Joe Mobile Wallet User to upload a set of N PaymentRequests authenticated by his key to an untrusted server, which encrypts and passes them on in response to InvoiceRequests? Or does this necessarily require the recipient to be online? On Tuesday, March 01, 2016 6:58:16 PM

Re: [bitcoin-dev] Hardfork to fix difficulty drop algorithm

On Wednesday, March 02, 2016 3:05:08 PM Pavel Janík wrote: > > the network. This would result in a significantly longer block interval, > > which also means a higher per-block transaction volume, which could > > cause the block size limit to legitimately be hit much sooner than > > expected. > >

[bitcoin-dev] Bitcoin Knots 0.12.0.knots20160226 release candidate 1 available

Binaries for Bitcoin Knots version 0.12.0.knots20160226.rc1 are available from: https://bitcoinknots.org/files/0.12.x/0.12.0.knots20160226/test/rc1/ Source code can be found on GitHub under the signed tag: https://github.com/bitcoinknots/bitcoin/tree/v0.12.0.knots20160226.rc1 This is a

[bitcoin-dev] BIP 2 promotion to Final

It has been about 1 month since BIP 2 finished receiving comments, so I believe it is an appropriate time to begin the process of moving it to Final Status. Toward this end, I have opened a pull request: https://github.com/bitcoin/bips/pull/350 The current requirement for this is that "the

Re: [bitcoin-dev] Making AsicBoost irrelevant

On Wednesday, May 11, 2016 12:20:55 PM Sergio Demian Lerner via bitcoin-dev wrote: > On Tue, May 10, 2016 at 6:43 PM, Sergio Demian Lerner < > sergio.d.ler...@gmail.com> wrote: > > You can find it here: > > https://bitslog.wordpress.com/2014/03/18/the-re-design-of-the-bitcoin-blo > > ck-header/ >

Re: [bitcoin-dev] Holdup on Block Alerts / Fraud Proofs ?

On Saturday, July 30, 2016 11:18:36 PM Paul Sztorc via bitcoin-dev wrote: > In my view, "alerts" are relatively straightforward: a new OP CODE (details > below) st. the txn only succeeds if it references invalid block content on > a "pretender block". > > However, my background reading seems to

Re: [bitcoin-dev] BIP Number Request: Addresses over Audio

On Tuesday, August 09, 2016 11:06:20 PM Daniel Hoffman via bitcoin-dev wrote: > Is this good enough to warrant an official BIP number? Yeah, let's call it BIP 170. Next step is to: - Fix the BIP number in the file - Format it in the usual BIP mediawiki format instead of markdown - Add it to a

Re: [bitcoin-dev] BIP clearing house addresses

On Wednesday, August 03, 2016 6:16:20 PM Matthew Roberts via bitcoin-dev wrote: > In light of the recent hack: what does everyone think of the idea of > creating a new address type that has a reversal key and settlement layer > that can be used to revoke transactions? This isn't something that

Re: [bitcoin-dev] General bitcoin users mailing list?

On Sunday, August 14, 2016 3:41:25 AM Cannon via bitcoin-dev wrote: > I understand this mailing list is for topics relating to development. Is > there a general users mailing list for bitcoin related things such as > questions that are not necessarily related to dev?

[bitcoin-dev] Bitcoin Knots 0.13.0.knots20160814 released

Bitcoin Knots version 0.13.0.knots20160814 is now available from: This is a new major version release, including new features, various bugfixes and performance improvements, as well as updated translations. Please report bugs using

Re: [bitcoin-dev] BIP draft: HTLC transactions

On Wednesday, July 20, 2016 5:46:54 AM Peter Todd via bitcoin-dev wrote: > On Tue, Jul 19, 2016 at 10:35:39PM -0600, Sean Bowe via bitcoin-dev wrote: > > I'm requesting feedback for Hash Time-Locked Contract (HTLC) transactions > > in Bitcoin. > > > > HTLC transactions allow you to pay for the

[bitcoin-dev] Status updates for BIP 9, 68, 112, and 113

Daniel Cousens opened the issue a few weeks ago, that BIP 9 should progress to Accepted stage. However, as an informational BIP, it is not entirely clear on whether it falls in the Draft/Accepted/Final classification of proposals requiring implementation, or the Draft/Active classification like

Re: [bitcoin-dev] New BIP: Low S values signatures

On Tuesday, August 16, 2016 10:10:01 AM Johnson Lau via bitcoin-dev wrote: > Specification > > Every signature passed to OP_CHECKSIG, OP_CHECKSIGVERIFY, OP_CHECKMULTISIG, > or OP_CHECKMULTISIGVERIFY, to which ECDSA verification is applied, Not 20-byte witness v0 programs? > These operators all

Re: [bitcoin-dev] Hardware Wallet Standard

On Tuesday, August 16, 2016 2:10:04 PM Jonas Schnelli via bitcoin-dev wrote: > The BIP describes two approaches how to communicate (pipe and > URI-scheme) with the signing-devices app, although, in my opinion, all > major platform do support the URI approach (maybe we could drop the pipe >

Re: [bitcoin-dev] New BIP: Dealing with OP_IF and OP_NOTIF malleability in P2WSH

On Tuesday, August 16, 2016 5:53:08 PM Johnson Lau via bitcoin-dev wrote: > A new BIP is prepared to deal with OP_IF and OP_NOTIF malleability in > P2WSH: > https://github.com/jl2012/bips/blob/minimalif/bip-minimalif.mediawiki > https://github.com/bitcoin/bitcoin/pull/8526 I am not sure this

Re: [bitcoin-dev] A Modified Version of Luke-jr's Block Size BIP

My BIP draft didn't make progress because the community opposes any block size increase hardfork ever. Your version doesn't address the current block size issues (ie, the blocks being too large). So you've retained the only certain- DOA parts of my proposal, and removed the most useful part...

Re: [bitcoin-dev] Three hardfork-related BIPs

On Friday, January 27, 2017 11:53:02 PM Andrew Johnson via bitcoin-dev wrote: > I don't think that the 17% yearly increase is too far off base considering > current global trends(although I still don't particularly like the idea of > centrally planning the limit, especially not that far into the

Re: [bitcoin-dev] Three hardfork-related BIPs

On Saturday, January 28, 2017 10:36:16 AM Natanael wrote: > Den 28 jan. 2017 05:04 skrev "Luke Dashjr via bitcoin-dev" < > bitcoin-dev@lists.linuxfoundation.org>: > > Satoshi envisioned a system where full nodes could publish proofs of > > invalid blocks that woul

Re: [bitcoin-dev] Three hardfork-related BIPs

On Friday, January 27, 2017 3:04:50 AM Andrew Johnson wrote: > Comment on #1. You're dropping the blocksize limit to 300KB and only > reaching the limit that we have in place today 7 years later? The limit only drops all the way to 300k if it activates before 2017 April. Considering that this

[bitcoin-dev] Three hardfork-related BIPs

I've put together three hardfork-related BIPs. This is parallel to the ongoing research into the MMHF/SHF WIP BIP, which might still be best long-term. 1) The first is a block size limit protocol change. It also addresses three criticisms of segwit: 1) segwit increases the block size limit

[bitcoin-dev] Bitcoin Knots 0.14.0 release candidate 1 available

Release candidate 1 of a new major Bitcoin Knots release, version 0.14.0, has been made available. This is a release candidate for a new major version release, including new features, various bugfixes and performance improvements. Preliminary release notes for the release can be found here:

Re: [bitcoin-dev] New BIP: Dealing with OP_IF and OP_NOTIF malleability in P2WSH

On Wednesday, August 17, 2016 3:02:53 AM Johnson Lau via bitcoin-dev wrote: > To completely replicate the original behaviour, one may use: > "DEPTH TOALTSTACK IFDUP DEPTH FROMALTSTACK NUMNOTEQUAL IF 2DROP {if script} > ELSE DROP {else script} ENDIF" This is much uglier than expected. IMO if

[bitcoin-dev] Bitcoin Knots 0.14.0 release candidate 2 available

Release candidate 2 of a new major Bitcoin Knots release, version 0.14.0, has been made available. This is a release candidate for a new major version release, including new features, various bugfixes and performance improvements. Preliminary release notes for the release can be found here:

Re: [bitcoin-dev] Moving towards user activated soft fork activation

Without at least a majority hashrate validating blocks, it is possible just a single invalid block could split the chain such that the majority continue building a most-work on that invalid block. This failure to validate a softfork is similar in some respects to a hardfork, but with one

Re: [bitcoin-dev] BIP draft: OP_CHECKBLOCKATHEIGHT

is valid in the reorganized blockchain if it again confirms the UTXO 1-B double-spend. Luke On Friday, September 23, 2016 2:37:39 PM Tom via bitcoin-dev wrote: > On Friday 23 Sep 2016 09:57:01 Luke Dashjr via bitcoin-dev wrote: > > This BIP describes a new opcode (OP_CHECKBLOC

Re: [bitcoin-dev] BIP draft: OP_CHECKBLOCKATHEIGHT

ould destroy this > property. > > On Fri, Sep 23, 2016 at 5:57 AM, Luke Dashjr via bitcoin-dev < > > bitcoin-dev@lists.linuxfoundation.org> wrote: > > This BIP describes a new opcode (OP_CHECKBLOCKATHEIGHT) for the Bitcoin > > scripting system to address reissuin

[bitcoin-dev] BIP 2 revival and rework

I've revived BIP 2 (from Deferred Status) and given it some updates. Most notably, I have reworked it to be a *replacement* for BIP 1 rather than an addendum. https://github.com/luke-jr/bips/blob/bip0002_squash/bip-0002.mediawiki Please review it. If things go well, hopefully we can get this

Re: [bitcoin-dev] Simple tx ID malleability fix, opcode proposal: OP_TXHASHVERIFY

On Saturday, September 17, 2016 8:45:17 PM Rune K. Svendsen via bitcoin-dev wrote: > I would really like to be able to create transactions that are immune to > transaction ID malleability now, so I have been thinking of the simplest > solution possible, in order to get a BIP through without too

Re: [bitcoin-dev] Requesting BIP assignment; Flexible Transactions.

On Tuesday, September 20, 2016 5:15:45 PM Tom via bitcoin-dev wrote: > As the title suggests, I would like to formally request the assignment of a > BIP number for my FT spec. Please open a pull request on the bitcoin/bips repo after this has been discussed a bit on the ML. Note that at least a

Re: [bitcoin-dev] Status updates for BIP 9, 68, 112, and 113

On Friday, July 15, 2016 4:46:57 PM Wladimir J. van der Laan wrote: > On Fri, Jul 15, 2016 at 03:52:37PM +, Luke Dashjr wrote: > > On Friday, July 15, 2016 3:46:28 PM Wladimir J. van der Laan wrote: > > > I'm not sure why it is labeled as only "Informational" in the first > > > place, as BIP9

[bitcoin-dev] BIP Status updates (including to Active/Final Status) - BIP 39, BIP 43, BIP 44, BIP 67, BIP 111, BIP 125, BIP 130

A number of BIPs seem ready for updating to Final Status. If there are no objections, I will update these in 2 weeks: BIP 39: Mnemonic code for generating deterministic keys - Used by many wallets and hundreds of thousands of users. BIP 44: Multi-Account Hierarchy for Deterministic Wallets -

Re: [bitcoin-dev] BIP Status updates (including to Active/Final Status) - BIP 39, BIP 43, BIP 44, BIP 67, BIP 111, BIP 125, BIP 130

On Wednesday, August 24, 2016 1:47:08 PM Andreas Schildbach via bitcoin-dev wrote: > FWIW, BIP44 also doesn't encode a seed birthday. This needed so that SPV > wallets do not need to scan from the beginning of the blockchain. > > That doesn't mean BIP44 could not be final. There are some wallets

Re: [bitcoin-dev] Drivechain proposal using OP_COUNT_ACKS

On Sunday, October 02, 2016 5:18:08 PM Andrew Johnson via bitcoin-dev wrote: > Is this particular proposal encumbered by a licensing type, patent, or > pending patent which would preclude it from being used in the bitcoin > project? If not, you're wildly off topic. I think that's the concern: we

  1   2   3   >