Re: [bitcoin-dev] Block size hard fork

On Sat, Aug 1, 2015 at 12:05 AM, Hector Chu via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: There is nothing tying transactions to the blocks they appear in. Transactions can be recieved or accepted in different orders by different nodes. The purpose of the blockchain is to resolve

Re: [bitcoin-dev] Bitcoin XT Fork

On Mon, Aug 17, 2015 at 8:37 PM, Oliver Egginger via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: Would we discuss his posting if he would not claim to be Satoshi? There are a lot of smart people on this list, which publish occasionally quite useful ideas. I actually learned

Re: [bitcoin-dev] Bitcoin XT Fork

On Mon, Aug 17, 2015 at 11:51 AM, Oliver Egginger via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: To avoid such discussions. You seem to be assuming that there is specific reason to believe the message is unauthentic. This is not the case. Contrary to other poster's claims, if the

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

On Mon, Aug 24, 2015 at 12:25 AM, Tom Harding via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: ack no inversion. This can actually allow more direct preservation of existing semantics. http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009350.html I can't follow this

Re: [bitcoin-dev] Bitcoin XTs Tor IP blacklist downloading system has significant privacy leaks.

On Wed, Aug 19, 2015 at 1:36 AM, Peter Todd via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: tl;dr: Yes, Bitcoin XT has a privacy problem with the automatic Tor exit node list download. It's not a bug, it's a feature: These concerns and others were specifically called out when we

Re: [bitcoin-dev] Bitcoin XT Fork

On Mon, Aug 17, 2015 at 7:16 PM, Hector Chu via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: On 15 August 2015 at 18:43, Satoshi Nakamoto via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: I suspect we need a better incentive for users to run nodes instead of relying

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

On Wed, Jul 29, 2015 at 9:59 AM, Mike Hearn via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: I do love history lessons from people who weren't actually there. I doubt the rest of us really enjoy hearing these lessons from from you where you wildly distort history to reflect your

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

On Wed, Jul 29, 2015 at 7:56 PM, Owen via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: On July 29, 2015 7:15:49 AM EDT, Mike Hearn via bitcoin-dev: Consider this: the highest Bitcoin tx fees can possibly go is perhaps a little higher than what our competition charges. Too much higher

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

On Wed, Jul 29, 2015 at 6:03 PM, Mike Hearn he...@vinumeris.com wrote: It was _well_ understood that the users of Bitcoin would wish to protect its decenteralization by limiting the size of the chain to keep it verifyable on small devices. No it wasn't. That is something you invented

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

On Wed, Aug 5, 2015 at 7:53 PM, Arnoud Kouwenhoven - Pukaki Corp via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: Thanks for the reply. My understanding is that the bitcoin relay network is a backbone of connected high speed servers to increase the rate at which transactions and new

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

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 future? It already validates block version numbers. It only relays valid transactions. Although, the block relaying

Re: [bitcoin-dev] trust

On Sat, Aug 8, 2015 at 6:10 AM, Thomas Zander via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: The idea that Bitcoins very reason for existence is to avoid trusting anyone but yourself is something I've heard before, and I have to comment because it is a destructive thought. It is

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

On Thu, Oct 22, 2015 at 8:26 AM, Christian Decker via bitcoin-dev wrote: > Normalized transaction IDs do help in the case that the single signer wants > to immediately follow up its transaction with another transaction spending > the first one's change

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

On Thu, Oct 29, 2015 at 6:57 AM, telemaco via bitcoin-dev wrote: > Why not "outsource" totally that data management part to the already > existing with decades of experience database world. People would be able to > create incredibly easy bitcoin

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

On Sun, Nov 15, 2015 at 1:45 AM, Peter R wrote: > My previous email described how Type 1 consensus failures can be safely dealt > with. These include many kinds of database exceptions (e.g., the LevelDB > fork at block #225,430), or consensus mismatches regarding the max size

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

On Fri, Oct 30, 2015 at 3:04 AM, Simon Liu via bitcoin-dev wrote: > Given that UTXO storage is considered critical, it seems reasonable to This sounds like a misunderstanding of what consensus criticial means. It does not mean that it must be right (though

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

On Fri, Oct 30, 2015 at 4:04 AM, Peter R wrote: > Can you give a specific example of how nodes that used different database > technologies might determine different answers to whether a given transaction > is valid or invalid? I’m not a database expert, but to me it would seem

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

On Wed, Oct 21, 2015 at 6:18 AM, Luke Dashjr via bitcoin-dev wrote: > 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

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

On Wed, Oct 21, 2015 at 7:48 AM, Gregory Maxwell wrote: > I'm still sad that uniform segregated witeness is so hard to deploy, > adding another id to every utxo set won't be a nice cost. :( But I > have been trying for a long time to come up with anything better and > not

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

On Mon, Oct 5, 2015 at 7:13 PM, Tom Zander via bitcoin-dev wrote: > It is an eloquent change, but not really the topic we were discussing. It also > makes you attack Mike (calling him out as having a strawman) without basis. > For the second time in this

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

On Mon, Oct 5, 2015 at 8:35 PM, Tom Zander via bitcoin-dev wrote: > Fortunately I can say that while we certainly value your opinion, when peoples > opinions are hard to read, as you indicated they can be, we should look at > their actions. The group has

Re: [bitcoin-dev] merged multisig inputs

On Thu, Oct 8, 2015 at 7:55 PM, Boris Neklabaro via bitcoin-dev wrote: > Hi, > > Is it possible to merge 2 utxos spending from multiple P2SH inputs? Or > combined inputs P2SH and P2PKH in a single transaction? Yes, the signatures for separate inputs are

Re: [bitcoin-dev] Your Gmaxwell exchange

On Sun, Aug 30, 2015 at 4:13 AM, Peter R pete...@gmx.com wrote: I agree that miners may change their level of centralization. This neither affects the model nor the results presented in the paper. It has tremdous significance to the real-world impact of your results. If not for the other

Re: [bitcoin-dev] Your Gmaxwell exchange

On Sun, Aug 30, 2015 at 1:43 AM, Peter R pete...@gmx.com wrote: Dear Greg, I am moving our conversation into public as I've recently learned that you've been forwarding our private email conversation verbatim without my permission [I received permission from dpinna to share the email below

Re: [bitcoin-dev] Let's kill Bitcoin Core and allow the green shoots of a garden of new implementations to grow from its fertile ashes

On Tue, Sep 1, 2015 at 2:16 AM, Peter R via bitcoin-dev wrote: > - Bitcoin-B (Blockstream) Blockstream currently has no interest in maintaining a separate implementation of Bitcoin. At this time I believe doing so would have significantly negative value;

Re: [bitcoin-dev] block size - pay with difficulty

On Thu, Sep 3, 2015 at 2:40 PM, Jeff Garzik wrote: > Expanding on pay-with-diff and volatility (closing comment), > > Users and miners will have significant difficulty creating and/or predicting > a stable block size (and fee environment) with pay-with-diff across the > months.

Re: [bitcoin-dev] block size - pay with difficulty

On Thu, Sep 3, 2015 at 6:23 PM, Jorge Timón wrote: > Greg, I believe Jeff is focusing on BtcDrak's proposal ( > https://gist.github.com/btcdrak/1c3a323100a912b605b5 ) where the > increased nBits are used to vote for the block size to raise > permanently ( or until it gets voted

Re: [bitcoin-dev] block size - pay with difficulty

On Thu, Sep 3, 2015 at 4:05 AM, Jeff Garzik via bitcoin-dev wrote: > (b) requiring miners to have idle > hashpower on hand to change block size are both unrealistic and potentially I really cannot figure out how you could characterize pay with difficty has

[bitcoin-dev] Proposed minor change to BIP 01 to use a PR for request assignment

The process in BIP01 was written when we used a different solution for storing and presenting BIPs. I'm thinking of suggesting that the number request process be changed to opening a pull req with BIP text with no number (e.g. just using the authors name and an index as the number) as the

Re: [bitcoin-dev] Versionbits BIP (009) minor revision proposal.

On Wed, Sep 30, 2015 at 2:30 AM, Rusty Russell wrote: > Hi all, > > Pieter and Eric pointed out that the current BIP has miners > turning off the bit as soon as it's locked in (75% testnet / 95% > mainnet). It's better for them to keep setting the bit until

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

On Wed, Sep 30, 2015 at 5:11 PM, Mike Hearn wrote: > Hi Gregory, > >> >> I'm surprised to see this response > > > Why? I have objected to the idea of soft forks many times. I wrote an entire > article about it in August. Yes, your article contained numerous factual and

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

On Wed, Sep 30, 2015 at 10:17 PM, Jeff Garzik wrote: > It is correct that security is slightly reduced for full nodes that have not > upgraded. It is not correct that the choice is binary, full node or SPV. > > Any user running a not-upgraded full node still retains protection

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

On Wed, Sep 30, 2015 at 9:01 PM, Mike Hearn wrote: > I coined the term SPV so I know exactly what it means, and bitcoinj The term comes from the Bitcoin whitepaper. > On the other hand, full nodes all claim they run scripts. Users expect that > and may be relying on it. The

[bitcoin-dev] Pedantic note on the use of "eventual consistency" to describe Bitcoin [Was: Let's deploy BIP65 CHECKLOCKTIMEVERIFY!]

On Wed, Sep 30, 2015 at 10:14 PM, Jorge Timón wrote: > reason you don't think guaranteed eventual consistency has any value Obligatory pedantic correction: In Bitcoin we don't actually achieve "eventual consistency" of the kind which is usually described in

Re: [bitcoin-dev] Crossing the line? [Was: Re: Let's deploy BIP65 CHECKLOCKTIMEVERIFY!]

On Fri, Oct 2, 2015 at 12:23 PM, Mike Hearn via bitcoin-dev wrote: > At that time nobody used the term "SPV wallet" to refer to what apps like > BreadWallet or libraries like bitcoinj do. Satoshi used the term "client > only mode", Jeff was calling them

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

On Fri, Oct 2, 2015 at 8:30 AM, Daniele Pinna via bitcoin-dev wrote: > The recently published paper I referenced cite's the Cuckoo cycle algorithm, > discusses its limitations and explains how their proposed algorithm greatly > improves on it. They discuss

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

On Wed, Sep 23, 2015 at 9:37 PM, Gavin Andresen wrote: >> Avoiding this is why I've always previously described this idea as >> merged mined block DAG (with blocks of arbitrary strength) which are >> always efficiently deferentially coded against prior state. A new >>

[bitcoin-dev] Are 'soft forks' misnamed? [was: Let's deploy BIP65 CHECKLOCKTIMEVERIFY!]

On Mon, Sep 28, 2015 at 10:16 PM, Dave Scotese via bitcoin-dev wrote: > Why are they called soft forks when they are really hidden forks? Isn't the > point of a soft fork to prevent old clients from rejecting what they don't > have the code to validate?

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

On Mon, Oct 5, 2015 at 9:27 PM, Peter R via bitcoin-dev wrote: > Once again, let’s use the current gridlock Allow me to state unequivocally-- since we've had problems with people stating non-factuals as fact without getting adequately clear correction--,

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

On Mon, Oct 5, 2015 at 9:08 PM, Tom Zander via bitcoin-dev wrote: > On Monday 5. October 2015 20.56.34 Gregory Maxwell wrote: >> (In this case, I don't even believe we have any regulator >> contributors that disagree). > > Regular contributor? > > Please

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

On Fri, Sep 18, 2015 at 8:27 PM, Matt Corallo via bitcoin-dev wrote: > Google Calendar is localized, but has an option to change the timezone > of an event, it just doesnt have UTC in its options. So, yes, we should > use something that observes DST in

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

On Wed, Sep 23, 2015 at 4:07 PM, Bryan Bishop via bitcoin-dev wrote: > more recently: > http://gnusha.org/bitcoin-wizards/2015-09-20.log > http://diyhpl.us/wiki/transcripts/scalingbitcoin/roundgroup-roundup-1/ >

[bitcoin-dev] Blockchain verification flag (BIP draft)

For discussion, A significant fraction of hashrate currently mines blocks without verifying them for a span of time after a new block shows up on the network for economically rational reasons. This otherwise harmful behavior can be made a beneficial to the whole network; but only if it is

Re: [bitcoin-dev] Blockchain verification flag (BIP draft)

On Fri, Dec 4, 2015 at 10:43 PM, Rusty Russell wrote: >> I agree with Jannes Faber, behavior with respect to SPV clients should be >> to only tell them about fully validated headers. > > A delicate balance. If we penalize these blocks too much, it's > disincentive to set

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

On Wed, Dec 9, 2015 at 7:54 AM, Jorge Timón wrote: > From this question one could think that when you said "we can do the > cleanup hardfork later" earlier you didn't really meant it. And that > you will oppose to that hardfork later just like you are opposing to > it now. > As

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

On Tue, Dec 8, 2015 at 11:48 PM, Jonathan Toomim wrote: > I understood that SegWit would allow about 1.75 MB of data in the average > case while also allowing up to 4 MB of data in the worst case. This means > that the mining and block distribution network would need a larger safety

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

On Tue, Dec 8, 2015 at 3:12 PM, Gavin Andresen via bitcoin-dev wrote: > 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 of

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

On Wed, Dec 9, 2015 at 1:09 AM, Gavin Andresen wrote: > Create a 1-megabyte transaction, with all of it's inputs spending > segwitness-spending SIGHASH_ALL inputs. > > Because the segwitness inputs are smaller in the block, you can fit more of > them into 1 megabyte. Each

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

On Wed, Dec 9, 2015 at 4:44 AM, Ryan Butler wrote: >>I agree, but nothing I have advocated creates significant technical >>debt. It is also a bad engineering practice to combine functional >>changes (especially ones with poorly understood system wide >>consequences and low

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

The Scaling Bitcoin Workshop in HK is just wrapping up. Many fascinating proposals were presented. I think this would be a good time to share my view of the near term arc for capacity increases in the Bitcoin system. I believe we’re in a fantastic place right now and that the community is ready to

Re: [bitcoin-dev] Segregated Witness features wish list

On Thu, Dec 10, 2015 at 6:47 AM, jl2012--- via bitcoin-dev wrote: > 4. Sum of fee, sigopcount, size etc as part of the witness hash tree: for I should have also commented on this: the block can indicate how many sum criteria there are; and then additional

Re: [bitcoin-dev] Segregated Witness features wish list

On Thu, Dec 10, 2015 at 6:47 AM, jl2012--- via bitcoin-dev wrote: > It seems the current consensus is to implement Segregated Witness. SW opens > many new possibilities but we need a balance between new features and > deployment time frame. I'm listing by my

Re: [bitcoin-dev] Forget dormant UTXOs without confiscating bitcoin

On Sun, Dec 13, 2015 at 1:00 AM, Vincent Truong via bitcoin-dev wrote: > have run a node/kept their utxo before they were aware of this change and > then realise miners have discarded their utxo. Oops? I believe you have misunderstood jl2012's post. His

Re: [bitcoin-dev] BIP 151 MITM

On Wed, Jun 8, 2016 at 11:47 PM, Alfie John via bitcoin-dev wrote: > Hi folks, > > Overall I think BIP 151 is a good idea. However unless I'm mistaken, what's to > prevent someone between peers to suppress the initial 'encinit' message during > negotiation,

[bitcoin-dev] The first successful Zero-Knowledge Contingent Payment

I am happy to announce the first successful Zero-Knowledge Contingent Payment (ZKCP) on the Bitcoin network. ZKCP is a transaction protocol that allows a buyer to purchase information from a seller using Bitcoin in a manner which is private, scalable, secure, and which doesn’t require trusting

Re: [bitcoin-dev] Open Bitcoin Privacy Protect Privacy Questionnaire, Mid-Year 2015 report

Better late than never, I should correct things here. In the future it would probably be more productive to open an issue. Otherwise there is no mechanism for someone to take ownership of a response. On Sun, Aug 30, 2015 at 7:45 PM, Kristov Atlas via bitcoin-dev

[bitcoin-dev] Fwd: The first successful Zero-Knowledge Contingent Payment

On Fri, Feb 26, 2016 at 11:06 PM, Sergio Demian Lerner wrote: > Congratulations! > > It a property of the SKCP system that the person who performed the trusted > setup cannot extract any information from a proof? > > In other words, is it proven hard to obtain

Re: [bitcoin-dev] The first successful Zero-Knowledge Contingent Payment

On Fri, Feb 26, 2016 at 11:33 PM, Tier Nolan via bitcoin-dev wrote: > That is very interesting. > > There has been some recent discussion about atomic cross chain transfers > between Bitcoin and legacy altcoins. For this purpose a legacy altcoin is > one

Re: [bitcoin-dev] SIGHASH_NOINPUT in Segregated Witness

On Fri, Feb 26, 2016 at 1:07 AM, Joseph Poon via bitcoin-dev wrote: > I'm interested in input and in the level of receptiveness to this. If > there is interest, I'll write up a draft BIP in the next couple days. The design of segwit was carefully

[bitcoin-dev] Fwd: Services bit for xthin blocks

On Tue, Mar 8, 2016 at 5:14 AM, Dave Scotese wrote: > I think a BIP is a good idea, but rather than making such a specific > proposal as "Let's use bit 4 to indicate communication of thin blocks," how > about a more general one like "Let's use bit(s?) 4(-5?) as user-agent

Re: [bitcoin-dev] Services bit for xthin blocks

On Mon, Mar 7, 2016 at 8:06 PM, G. Andrew Stone via bitcoin-dev wrote: > The Bitcoin Unlimited client needs a services bit to indicate that the node > is capable of communicating thin blocks. We propose to use bit 4 as AFAIK > bit 3 is already earmarked for

Re: [bitcoin-dev] Making AsicBoost irrelevant

On Wed, May 11, 2016 at 10:42 PM, Timo Hanke via bitcoin-dev wrote: > This is what I meant. If existing hardware gets forked-out it will > inevitably lead to the creation of an altcoin. Simply because the hardware > exists and can't be used for anything else

Re: [bitcoin-dev] Making AsicBoost irrelevant

On Wed, May 11, 2016 at 11:01 PM, Peter Todd via bitcoin-dev wrote: > Secondly, we can probably make the consensus PoW allow blocks to be mined > using > both the existing PoW algorithm, and a very slightly tweaked version where > implementing AsicBoost

Re: [bitcoin-dev] Proposal to update BIP-32

On Sun, May 8, 2016 at 10:07 AM, Pavol Rusnak via bitcoin-dev wrote: > On 21/04/16 14:08, Marek Palatinus via bitcoin-dev wrote: >> Sipa, you are probably the most competent to answer this. >> Could you please tell us your opinion? For me, this is >>

[bitcoin-dev] Fwd: Compact Block Relay BIP

On Mon, May 9, 2016 at 11:32 AM, Tom wrote: > On Monday 09 May 2016 10:43:02 Gregory Maxwell wrote: >> On Mon, May 9, 2016 at 9:35 AM, Tom Zander via bitcoin-dev >> wrote: >> > You misunderstand the networking effects. >> > The fact

Re: [bitcoin-dev] Compact Block Relay BIP

On Mon, May 9, 2016 at 11:37 PM, Peter R wrote: > It is a standard result that there are > m! / [n! (m-n)!] > ways of picking n numbers from a set of m numbers, so there are > > (2^32)! / [2! (2^32 - 2)!] ~ 2^63 > possible pairs in a set of 2^32 transactions. So wouldn’t

Re: [bitcoin-dev] BIP proposal: derived mnemonics

On Wed, Jul 27, 2016 at 10:39 AM, Jochen Hoenicke via bitcoin-dev wrote: > Jonas Schnelli via bitcoin-dev > schrieb am Di., 26. Juli 2016 um 22:10 Uhr: >> >> Side-note: Bip39 does still use PBKDF2 with 2048 iterations

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

On Tue, Aug 9, 2016 at 11:06 PM, Daniel Hoffman via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > I have updated the GitHub a lot (changed tones to be less chirpy, fixed > some smalls) and made a couple of samples (see attachment for MP3 and FLAC > of both tone tables, first 16

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

On Thu, Aug 11, 2016 at 8:37 PM, Erik Aronesty via bitcoin-dev wrote: > Still not sure how you can take a BIP32 public seed and figure out if an > address was derived from it though. I mean, wouldn't I have to compute all > 2^31 possible public child

Re: [bitcoin-dev] BIP 151

> I understand the use, when coupled with a yet-to-be-devised identity system, > with Bloom filter features. Yet these features This is a bit of a strawman, you've selected a single narrow usecase which isn't proposed by the BIP and then argue it is worthless. I agree that example doesn't have

Re: [bitcoin-dev] BIP 151

On Tue, Jun 28, 2016 at 9:22 PM, Eric Voskuil via bitcoin-dev wrote: > An "out of band key check" is not part of BIP151. It has a session ID for this purpose. > It requires a secure channel and is authentication. So BIP151 doesn't provide > the tools to

Re: [bitcoin-dev] BIP 151

On Tue, Jun 28, 2016 at 11:33 PM, Eric Voskuil wrote: > I don't follow this comment. The BIP aims quite clearly at "SPV" wallets as > its justifying scenario. It cites SPV as an example, doesn't mention bloom filters.. and sure-- sounds like the bip text should make the >>

Re: [bitcoin-dev] Authentication BIP

On Mon, Aug 8, 2016 at 5:09 PM, Andy Schroder via bitcoin-dev wrote: > I have mixed feelings about strictly tying the identity-public-keys with a [...] > guaranteed static IP address. The second reason is because the DNS PTR I don't see any reason that it

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

On Tue, Aug 16, 2016 at 10:52 PM, Russell O'Connor via bitcoin-dev wrote: > I see. > > But is it really necessary to soft fork over this issue? Why not just make > it a relay rule? Miners are already incentivized to modify transactions to > drop excess

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 Tue, Aug 23, 2016 at 8:54 PM, Kenneth Heutmaker via bitcoin-dev wrote: > SPV is kinda broken if the wallet doesn’t do this detection. If your wallet > connects only to nodes that don’t support bloom filtering, the wallet never > gets updates. We have

Re: [bitcoin-dev] Completing the retirement of the alert system

On Sat, Sep 10, 2016 at 1:23 PM, Andrew C via bitcoin-dev wrote: > On 9/10/2016 5:41 AM, Johnson Lau via bitcoin-dev wrote: >> 3. After a few months or so, publish the private key. > Why wait a few months? Why not just publish the key a few days after the >

Re: [bitcoin-dev] Completing the retirement of the alert system

On Sat, Sep 10, 2016 at 12:58 AM, Peter Todd wrote: > Good to do this sooner rather than later, as alert propagation on the P2P > network is going to continue to get less reliable as nodes upgrade to software Yes, this was one of my motivations for doing this soon. It would

[bitcoin-dev] Completing the retirement of the alert system

The alert system was a centralized facility to allow trusted parties to send messages to be displayed in wallet software (and, very early on, actually remotely trigger the software to stop transacting). It has been removed completely in Bitcoin Core after being disabled for a while. While the

[bitcoin-dev] Proposed BIP-1 change removing OPL licensing option.

I've proposed a revision to BIP-1 that removes the option to license the work under the OPL: https://github.com/bitcoin/bips/pull/446 The OPL contains troublesome terms where the licensor can elect to prohibit print publication of the work as well as the creation of modified versions without

Re: [bitcoin-dev] BIP draft: OP_CHECKBLOCKATHEIGHT

On Fri, Sep 23, 2016 at 10:20 PM, Luke Dashjr via bitcoin-dev wrote: > In the innocent use case of this opcode, a double-spend has already occurred, > and this should be a strict improvement. In the non-innocent abuse of this > opcode, I don't see that it's

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

On Tue, Sep 20, 2016 at 5:15 PM, Tom via bitcoin-dev wrote: > BIP number for my FT spec. This document does not appear to be concretely specified enough to review or implement from it. For example, it does not specify the serialization of "integer" (is it

Re: [bitcoin-dev] Capital Efficient Honeypots w/ "Scorched Earth" Doublespending Protection

On Thu, Aug 25, 2016 at 2:27 PM, Christian Decker via bitcoin-dev wrote: > If however > he is planning to use it as a foothold to further compromise your > company, send spam or similar, he will likely try to avoid these > tripwires. [...] Depends on the

Re: [bitcoin-dev] About ASICBoost

On Sun, Oct 2, 2016 at 10:51 PM, Matt Corallo via bitcoin-dev wrote: > If you had acted in a way which indicated even the slightest regard for > centralization pressure and the harm it can do to Bitcoin in the > long-term, then I dont think many would be

Re: [bitcoin-dev] BIP proposal: Inhibiting a covert attack on the Bitcoin POW function

On Wed, Apr 5, 2017 at 9:37 PM, Gregory Maxwell wrote: > each block MUST either contain a BIP-141 segwit commitment or a > correct WTXID commitment with ID 0xaa21a9ef. It was just pointed out to me that the proposed ID (which I just selected to be above the segwit one) collides

Re: [bitcoin-dev] BIP proposal: Inhibiting a covert attack on the Bitcoin POW function

On Thu, Apr 6, 2017 at 12:39 AM, Joseph Poon wrote: > #bitcoin@freenode: > 00:04gmaxwell| lol poon pretending that he isn't complicit in all this > stuff. > > Are you *fucking* serious? Is this how you resolve all problems? I'm > taking you seriously and having

Re: [bitcoin-dev] Using a storage engine without UTXO-index

On Sat, Apr 8, 2017 at 8:21 PM, Johnson Lau wrote: > pre-synced means already in mempool and verified? Then it sounds like we just > need some mempool optimisation? The tx order in a block is not important, > unless they are dependent In Bitcoin Core the software _explicitly_

Re: [bitcoin-dev] I do not support the BIP 148 UASF

On Sat, Apr 15, 2017 at 6:28 AM, Cameron Garnham wrote: > As many may remember, there was quite some controversy about the BIP16 vs BIP > 17 split; the main argument for BIP16 was the urgency of P2SH, and how this > was the already “tested and proven to work” solution. And as

Re: [bitcoin-dev] I do not support the BIP 148 UASF

On Sat, Apr 15, 2017 at 2:01 AM, Steven Pine via bitcoin-dev wrote: > Regarding this last point I was under the impression that if Segwit did not > activate by November then core was going to move on, is that no longer the Wow. Where did you get that idea?

Re: [bitcoin-dev] I do not support the BIP 148 UASF

On Sat, Apr 15, 2017 at 4:10 AM, Steven Pine wrote: > but segwit does > have a 'time out' as defined in BIP 9 with the date of November 15th? There is a technical requirement that BIP 9 bit allocations must have a timeout so that a bit is not forever burned if a proposal

[bitcoin-dev] I do not support the BIP 148 UASF

I do not support the BIP148 UASF for some of the same reasons that I do support segwit: Bitcoin is valuable in part because it has high security and stability, segwit was carefully designed to support and amplify that engineering integrity that people can count on now and into the future. I do

Re: [bitcoin-dev] Small Nodes: A Better Alternative to Pruned Nodes

On Mon, Apr 17, 2017 at 6:54 AM, David Vorick via bitcoin-dev wrote: > Rationale: > > A node that stores the full blockchain (I will use the term archival node) > requires over 100GB of disk space, which I believe is one of the most > significant barriers to

Re: [bitcoin-dev] Using a storage engine without UTXO-index

On Fri, Apr 7, 2017 at 6:52 PM, Tom Harding via bitcoin-dev wrote: > A network in which many nodes maintain a transaction index also enables a > class of light node applications that ask peers to prove existence and > spentness of TXO's. Only with the

Re: [bitcoin-dev] Using a storage engine without UTXO-index

On Fri, Apr 7, 2017 at 9:14 PM, Tomas wrote: > The long term *minimal disk storage* requirement, can obviously not be less > then all the unspent outputs. Then I think you may want to retract the claim that "As this solution, reversing the costs of outputs and inputs, [...]

Re: [bitcoin-dev] Using a storage engine without UTXO-index

On Fri, Apr 7, 2017 at 12:48 AM, Tomas wrote: > Bitcrust separates script validation (base load, when transaction come > in) from order validation (peak load, when blocks come in). How do you deal with validity rules changing based on block height? > For script validation it

Re: [bitcoin-dev] Using a storage engine without UTXO-index

On Thu, Apr 6, 2017 at 10:12 PM, Tomas via bitcoin-dev wrote: >As this > solution, reversing the costs of outputs and inputs, seems to have > excellent performance characteristics (as shown in the test results), > updates to the protocol addressing the UTXO

Re: [bitcoin-dev] I do not support the BIP 148 UASF

On Fri, Apr 14, 2017 at 8:34 PM, Tom Zander via bitcoin-dev wrote: > I expected you to know this, but ok, I'll explain. Please stop abusing participants on this list. Your activity is actively driving people off this list. James Hilliard should be

Re: [bitcoin-dev] I do not support the BIP 148 UASF

On Fri, Apr 14, 2017 at 9:10 PM, James Hilliard via bitcoin-dev wrote: > would have to intentionally modify the code to mine an invalid block > which is not something that would be likely to happen accidentally. IIRC-- If you do it accidentally you'll fail

Re: [bitcoin-dev] BIP proposal, Pay to Contract BIP43 Application

This construction appears to me to be completely insecure. Say my pubkey (the result of the derivation path) is P. We agree to contract C1. A payment is made to P + G*H(C1). But in secret, I constructed contract C2 and pubkey Q and set P = Q + G*H(C2). Now I can take that payment (paid to Q

Re: [bitcoin-dev] Updating the Scaling Roadmap

On Wed, Jul 12, 2017 at 1:40 AM, Paul Sztorc wrote: > Separately, and very important to me, is that you feel that there are > unresolved objections to drivechain's security model, which you decline > to share with me and/or the list. So I would hope that you instead > choose

Re: [bitcoin-dev] A Segwit2x BIP

On Fri, Jul 7, 2017 at 10:25 PM, Sergio Demian Lerner via bitcoin-dev wrote: > Hello, > > Here is a BIP that matches the reference code that the Segwit2x group has > built and published a week ago. I'm happy to see that someone has begun writing a

  1   2   3   >