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 that's

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 makes

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 > approach

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 p

[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] 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? https://lists.linuxfoundation.

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 for

Re: [bitcoin-dev] *Changing* the blocksize limit

This is exactly what segwit does... On Saturday, August 06, 2016 2:15:22 PM Chris Priest via bitcoin-dev wrote: > Because the blocksize limit is denominated in bytes, miners choose > transactions to add to a block based on fee/byte ratio. This mean that > if you make a transaction with a lot of in

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 ma

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

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 pre

[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] BIP Number Request: Open Asset

On Tuesday, July 05, 2016 5:46:36 PM Peter Todd wrote: > On Thu, May 26, 2016 at 03:53:04AM +0000, Luke Dashjr via bitcoin-dev wrote: > > On Thursday, May 26, 2016 2:50:26 AM Nicolas Dorier via bitcoin-dev wrote: > > > Author: Flavien Charlon > > What's the s

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, Al

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 support

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 an

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 pu

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] BIP Number Request: Open Asset

On Thursday, May 26, 2016 2:50:26 AM Nicolas Dorier via bitcoin-dev wrote: > Author: Flavien Charlon Is he the author of this BIP, or merely the protocol described in it? Would it perhaps make sense to include yourself in the author list? > The ID of an asset is the RIPEMD-160 hash of the SHA-

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 t

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] p2p authentication and encryption BIPs

On Wednesday, March 23, 2016 3:24:12 PM Jonas Schnelli via bitcoin-dev wrote: > I have just PRed a draft version of two BIPs I recently wrote. > https://github.com/bitcoin/bips/pull/362 In the future, please submit BIP drafts to the mailing list for comment and initial peer review before opening

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

On Friday, March 18, 2016 9:42:16 AM Btc Drak wrote: > On Wed, Mar 16, 2016 at 10:24 PM, Luke Dashjr wrote: > > BIP Comments are not a part of the BIP itself, merely post-completion > > notes from various external parties. So having them external does not > > make the BIP > > any less self-contain

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 g

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] 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 Ju

[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] Services bit for xthin blocks

On Tuesday, March 08, 2016 2:35:21 AM G. Andrew Stone via bitcoin-dev wrote: > Not an unreasonable request, however while I personally respect the many > great accomplishments of individual engineers loosely affiliated with > "Core", Bitcoin Unlimited has our own process for documentation and > dis

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

On Wednesday, March 02, 2016 2:56:14 PM Luke Dashjr via bitcoin-dev wrote: > so it may even be possible to have such a proposal ready in time to be > deployed alongside SegWit to take effect in time for the upcoming subsidy > halving. Lapse of thinking/clarity here. This probabl

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. > > I

[bitcoin-dev] Hardfork to fix difficulty drop algorithm

We are coming up on the subsidy halving this July, and there have been some concerns raised that a non-trivial number of miners could potentially drop off the network. This would result in a significantly longer block interval, which also means a higher per-block transaction volume, which could

[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

Re: [bitcoin-dev] SIGHASH_NOINPUT in Segregated Witness

On Friday, February 26, 2016 1:07:46 AM Joseph Poon via bitcoin-dev wrote: > This would be achieved using a SIGHASH flag, termed SIGHASH_NOINPUT. It > does not include as part of the signature, the outpoint being spent > (txid and index), nor the amount. It however, would include the spent > outpoi

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 > > > > where > > > > >

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 fil

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 reasonably

Re: [bitcoin-dev] BIP Final status

On Monday, February 08, 2016 10:41:00 PM Peter Todd wrote: > On Mon, Feb 08, 2016 at 10:17:55PM +0000, Luke Dashjr via bitcoin-dev wrote: > > Additionally, https://github.com/bitcoin/bips/pull/315 proposes to > > upgrade five additional from Draft to Final status, and preferably

[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 messa

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

[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. - Expandi

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

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 you list say anything about the fact that "being > > lost" (kicked out of the network) is a problem for those node's u

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

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 ... > > >

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] BIP draft: Hard fork opt-in mechanism for SPV nodes

Soft-hardforks have the same behaviour for both SPV and full nodes. I don't see the point in making this SPV-only "middle layer"... On Friday, February 05, 2016 6:40:57 PM jl2012 via bitcoin-dev wrote: > BIP draft: Hard fork opt-in mechanism for SPV nodes: > https://github.com/bitcoin/bips/pull/32

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 self-curated

Re: [bitcoin-dev] Hardfork bit BIP

On Thursday, February 04, 2016 5:14:49 PM jl2012 via bitcoin-dev wrote: > ABSTRACT > > This document specifies a proposed change to the semantics of the sign > bit of the "version" field in Bitcoin block headers, as a mechanism to > indicate a hardfork is deployed. Disagree with treating the "ver

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 l

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 > released

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

On Tuesday, February 02, 2016 5:38:59 PM Jorge Timón wrote: > In the section > https://github.com/luke-jr/bips/blob/bip-biprevised/bip-biprevised.mediawi > ki#formally-defining-consensus > > Can we please find another term for the "consensus" here (which is > often confused with "consensus rules",

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 th

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 communication

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

On Tuesday, February 02, 2016 5:50:29 AM Dave Scotese wrote: > The section that starts "Should two software projects need to release" > addresses issues that are difficult to ascertain from what is written > there. I'll take a stab at what it means: > > Would bitcoin be better off if multiple app

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 cases both encourages the lazy case,

Re: [bitcoin-dev] SegWit GBT updates

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 cases both encourages the lazy case, and enables > > pools to require miners use it. It also complicates the server-side > > implementation somewhat, and could i

[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 to

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 c

[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

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 t

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

On Tuesday, January 26, 2016 3:07:40 AM Toby Padilla wrote: > > I don't see any benefit to changing that. It is better that coins are > > burned. > > I think this is our fundamental disagreement. People will burn coins to > encode data, why allow this when there's a better alternative? My point i

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 OP_RETU

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 firs

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 b

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 intentionall

Re: [bitcoin-dev] Increasing the blocksize as a (generalized) softfork.

On Sunday, December 20, 2015 10:56:33 AM joe2015--- via bitcoin-dev wrote: > "generalized" softfork. FWIW, this is something I've been planning to proposed (in a nicer form) for a while, tentatively called a "soft hardfork" (or less-seriously a "softserve hardfork"). The big piece missing that I

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

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 any implementation that wants to > propose

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 > implementati

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] [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 >

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

On Saturday, November 14, 2015 9:15:07 PM Angel Leon wrote: > "the economy does not necessarily include miners" > so the money supply isn't part of the economy? Not in the context of economic majority deciding hardforks. After all, the outcome of the hardfork *determines* the money supply. So the

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

On Saturday, November 14, 2015 10:52:12 AM Jorge Timón via bitcoin-dev wrote: > Currently bip99 recommends 95% miner upgrade confirmation with version bits > (bip9) for uncontroversial hardforks just like it does for uncontroversial > softforks. It is true that in the case of hardforks miners don't

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 > sig

Re: [bitcoin-dev] BIP proposal - Max block size

On Friday, November 13, 2015 1:07:33 PM Erik via bitcoin-dev wrote: > Hi devs. I was discussing the BIP proposals concerning max block size > yesterday in the #bitcoin channel. I believe that BIP101 fully utilized > will outperform consumer hardware soon or later and thereby centralize > Bitcoin. I

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 gi

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

On Friday, November 13, 2015 2:56:55 AM Chun Wang via bitcoin-dev wrote: > * 2 MB, 21 <= height < 42; It's impossible to have the entire network upgraded in the past. Furthermore, 1 MB is already too large a block size today. While blocks don't need to be as big as the limit, it's better

Re: [bitcoin-dev] Upcoming Transaction Priority Changes

On Thursday, November 12, 2015 9:21:57 PM Alex Morcos wrote: > To be clear Luke, its not THAT complicated to maintain the mining policy, > but preserving the ability of people to place priority based transactions > in a limited mempool world is quite complicated. See recently closed > #6992. > I t

Re: [bitcoin-dev] Upcoming Transaction Priority Changes

On Thursday, November 12, 2015 8:43:17 PM Jorge Timón wrote: > On Thu, Nov 12, 2015 at 9:12 PM, Luke Dashjr via bitcoin-dev > wrote: > > On Thursday, November 12, 2015 7:47:50 PM Matt Corallo via bitcoin-dev > > wrote: > >> * Mining code will use starting priority

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] 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 star

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 > > wrote: > > On Tuesday, November 03, 2015 9:44:02 PM Christian Decker wrote: > >> So this is indeed a form of desired malleability we will likely

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. > Non-upgrad

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

On Tuesday, November 03, 2015 8:37:44 PM Christian Decker wrote: > I am still very much intrigued by Luke's idea of having empty scriptsigs > and ship the signatures in external scripts, however the proposal uses the > on-the-fly normalization because we have no good way of relaying the > external

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 alrea

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 > isn't,

[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 logic

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. UTX

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 > > modify/customise

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 procedure

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 net

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] [BIP] Normalized transaction IDs

On Thursday, October 22, 2015 8:26:58 AM Christian Decker wrote: > I think the scenario of the single signer re-ordering the outputs and > inputs and then re-signing the transaction is in the same category of > simple double-spends. The signer could just as well sign a completely > different transa

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 entail

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

On Wednesday, October 21, 2015 6:22:25 PM Danny Thorpe wrote: > Let's keep canonical ordering separate from the normalized transaction ID > proposal. Baby steps. Normalized transaction IDs provide an immediate > benefit against the hazard of third party manipulation of transactions in > the mempool

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

On Wednesday, October 21, 2015 8:44:53 AM Christian Decker wrote: > Hm, that is true as long as the signer is the only signer of the > transaction, otherwise he'd be invalidating the signatures of the other > signers. Or he can just have the other signers re-sign with the modified version. Even if

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

On Wednesday, October 21, 2015 8:31:42 AM Christian Decker wrote: > On Wed, Oct 21, 2015 at 9:52 AM Luke Dashjr wrote: > > 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

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 > > malleability later on wo

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

On Monday, October 19, 2015 2:01:04 PM Christian Decker via bitcoin-dev wrote: > The proposal is implemented (see below), by computing the normalized > transaction ID when adding them to the UTXO and storing them along with the > coin state. OP_CHECKSIGEX mostly duplicates OP_CHECKSIG and > OP_CHEC

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] 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 06,

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 cop

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 e

<    1   2   3   4   >