Re: [bitcoin-dev] Voting by locking coins

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 8 August 2015 02:27:35 GMT-04:00, Hector Chu via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: Has there ever been any discussion of locking coins till a certain date for casting votes on an issue? Yes, John Dillon proposed a very

Re: [bitcoin-dev] Bitcoin XT Fork

On Wed, Aug 19, 2015 at 10:22:32AM -0700, Simon Liu via bitcoin-dev wrote: Olivier Janssens claims that one of your colleagues is asking for Gavin to be removed from his position. Is this true?

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

On Tue, Aug 18, 2015 at 06:36:45PM -0700, Peter Todd via bitcoin-dev wrote: is false. However, in the common scenario of a firewalled node, where the operator has neglected to explicitly set -listen=0, the code does still download the Tor exit node list, revealing the true location of the node

Re: [bitcoin-dev] Bitcoin XT 0.11A

On Wed, Aug 19, 2015 at 03:45:48PM -0700, Adam Back via bitcoin-dev wrote: Wouldnt the experience for SPV nodes be chaotic? If the full nodes are 50:50 XT and bitcoin core, then SPV clients would connect at random and because XT and core will diverge immediately after activation. Actually

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

On Fri, Aug 21, 2015 at 06:15:16PM -0400, Chris Pacia wrote: On Aug 21, 2015 2:07 AM, Peter Todd via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: Also, as I mentioned, just look at the popularity of wallets such as Mycelium that are not adopting bloom filters, but going

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

On Fri, Aug 21, 2015 at 05:55:58PM +, Matt Corallo wrote: Revised copy follows. re: mentioning the HTTP seeding stuff, I'm not sure we want to encourage more people aside from bitcoinj to use that...I thought about adding a DNS seed section to this bip, but decided against it...still, I

Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 21 August 2015 20:21:22 GMT-07:00, Jorge Timón jti...@jtimon.cc wrote: Don't you mean profits instead of revenue? Actually no. I thought revenue would be a less subjective question to ask, with more focus on the underlying orphan rate

Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap

On Fri, Aug 21, 2015 at 04:16:39PM -0700, Tom Harding wrote: On 8/21/2015 3:21 PM, Peter Todd wrote: To use a car analogy, Pieter Wuille has shown that the brake cylinders have a fatigue problem, and if used in stop-and-go traffic regularly they'll fail during heavy braking, potentially

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

On Sat, Aug 22, 2015 at 01:08:13AM +, Matt Corallo wrote: Well actually, we can reference the DoS attacks that Bitcoin XT nodes are undergoing right now - part of the attack is repeated Bloom filter requests to soak up disk IO bandwidth. I've CC'd Gavin and Mike - as far as I know they

Re: [bitcoin-dev] Bitcoin XT Fork

On Thu, Aug 20, 2015 at 11:00:14AM +0200, Mike Hearn via bitcoin-dev wrote: It is just that no one else is reckless enough to bypass the review process I keep seeing this notion crop up. I want to kill this idea right now: - There were months of public discussion leading to up

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

On Fri, Aug 21, 2015 at 02:01:06AM -0400, Jeff Garzik wrote: I don't see any link to data backing up Bloom filter usage has declined significantly Is there actual data showing this feature's use is declining or non-existent? I run a number of high speed nodes and while I don't have

Re: [bitcoin-dev] Core Devs : can you share your thoughts about all BIPs on this website ?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 20 August 2015 21:45:23 GMT-07:00, Gregory Maxwell via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: I think this is a bit well, sad, at the moment-- a basic principle in sound decision making is that one should try to withhold

Re: [bitcoin-dev] Core Devs : can you share your thoughts about all BIPs on this website ?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 21 August 2015 02:31:51 GMT-07:00, Btc Drak btcd...@gmail.com wrote: On Fri, Aug 21, 2015 at 10:29 AM, Peter Todd via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: What might be valuable is to ask devs to explain what their threat

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

On Fri, Aug 21, 2015 at 01:48:23AM -0400, Jeff Garzik via bitcoin-dev wrote: If this is widely deployed + enabled, what is the impact to current wallets in use? See my comment on the recently-opened issue, reproduced below. In short, not all that much, especially if we adopt my suggestion of

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

On Fri, Aug 21, 2015 at 04:46:17AM +, Matt Corallo wrote: Peter: Since I stole most of this text from your old BIP, should I leave you as an author? That's fine by me. BIP: ? Title: NODE_BLOOM service bit Author: Matt Corallo b...@bluematt.me, Peter Todd p...@petertodd.org Type:

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

On Tue, Aug 18, 2015 at 09:08:01PM -0400, Christophe Biocca via bitcoin-dev wrote: So I checked, and the code described *does not* run when behind a proxy of any kind, including tor:

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

Deployment of the proposed CLTV, CSV, etc. soft-forks has been recently complicated by the existence of XT(1) and Not-Bitcoin-XT(2) miners. Both mine blocks with nVersion=0x2007, which would falsely trigger the previously suggested implementation using the IsSuperMajority() mechanism and

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 17 August 2015 07:49:21 GMT-07:00, BitMinter operator via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: I don't think mining pools will immediately make blocks as big as possible if the hard limit is raised. Note that XT includes a

Re: [bitcoin-dev] Annoucing Not-BitcoinXT

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 The fun thing about this, is you only need 25% of hashing power running Not-BitcoinXT to screw over the miners running XT, as XT blocks are valid Bitcoin blocks if they're on a valid Bitcoin chain. 75% upgrade thresholds have a lot of issues...

Re: [bitcoin-dev] Bitcoin XT 0.11A

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 16 August 2015 17:03:35 GMT-07:00, Cameron Garnham via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: There are a few ways: here is my favorite (for the moment). 1. Spam the 8mb blocks with 1 Satoshi outputs to the brainwallet

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 6 August 2015 10:21:54 GMT-04:00, Gavin Andresen via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: On Thu, Aug 6, 2015 at 10:06 AM, Pieter Wuille pieter.wui...@gmail.com wrote: But you seem to consider that a bad thing. Maybe

Re: [bitcoin-dev] A Transaction Fee Market Exists Without a Block Size Limit--new research paper suggests

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 4 August 2015 17:30:28 GMT-04:00, Gavin Andresen via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: On Tue, Aug 4, 2015 at 2:41 PM, Dave Hudson via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: Fundamentally a block

Re: [bitcoin-dev] Consensus fork activation thresholds: Block.nTime vs median time vs block.nHeight

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 4 August 2015 16:02:53 GMT-04:00, Jorge Timón via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: One thing I've noticed there seems to be disagreement on is whether miners' upgrade confirmation (aka voting) is necessary for

Re: [bitcoin-dev] A Transaction Fee Market Exists Without a Block Size Limit--new research paper suggests

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 4 August 2015 14:41:53 GMT-04:00, Dave Hudson via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: The paper is nicely done, but I'm concerned that there's a real problem with equation 4. The orphan rate is not just a function of time;

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

On Wed, Jul 22, 2015 at 12:52:20PM -0400, Pieter Wuille via bitcoin-dev wrote: Hello all, I'd like to talk a bit about my view on the relation between the Bitcoin Core project, and the consensus rules of Bitcoin. I believe it is the responsibility of the maintainers/developers of Bitcoin

Re: [bitcoin-dev] Bitcoin Roadmap 2015, or If We Do Nothing Analysis

On Fri, Jul 24, 2015 at 07:09:13AM -0700, Adam Back via bitcoin-dev wrote: (Claim of large bitcoin ecosystem companies without full nodes) this says to me rather we have a need for education: I run a full node myself (intermittently), just for my puny collection of bitcoins. If I ran a

Re: [bitcoin-dev] Bitcoin Roadmap 2015, or If We Do Nothing Analysis

On Fri, Jul 24, 2015 at 03:39:08PM +0200, Thomas Zander via bitcoin-dev wrote: On Friday 24. July 2015 05.37.30 Slurms MacKenzie via bitcoin-dev wrote: It's worth noting that even massive companies with $30M USD of funding don't run a single Bitcoin Core node, I assume you mean that they

Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB

, Jeff Garzik jgar...@gmail.com wrote: On Tue, Jul 21, 2015 at 6:58 AM, Peter Todd via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: I don't agree with you at all. This is a case where if Jeff doesn't understand that issue, he's proposing changes that he's not competent enough

Re: [bitcoin-dev] Bitcoin Node Speed Test

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 23 July 2015 10:19:59 GMT-04:00, slurms--- via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: This does not support the theory that the network has the available bandwidth for increased block sizes, as in its current state 37% of

Re: [bitcoin-dev] Significant losses by double-spending unconfirmed transactions

On Wed, Jul 15, 2015 at 05:08:05PM -0700, Matthieu Riou via bitcoin-dev wrote: On Wed, Jul 15, 2015 at 12:32 PM, Peter Todd p...@petertodd.org wrote: In a Sybil attack the attacker subverts the reputation system of a peer-to-peer network by creating a large number of pseudonymous

Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB

On Tue, Jul 21, 2015 at 11:26:35AM +0200, Jorge Timón via bitcoin-dev wrote: I still disagree. Using height instead of time may make the implementation more complex by requiring some additional preparations but using height is in fact a simpler design. Why relay on clocks that we know will

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

On Thu, Oct 22, 2015 at 03:58:58PM -0500, Justus Ranvier via bitcoin-dev wrote: > On 22/10/15 15:43, Luke Dashjr wrote: > > BIPs should in general not be > > designed around current software > > I strongly disagree with this statement. > > There is a version byte in the payment code

[bitcoin-dev] Opt-in Full Replace-By-Fee (Full-RBF)

Summary --- Opt-In Full-RBF allows senders to opt-into full-RBF semantics for their transactions in a way that allows receivers to detect if the sender has done so. Existing "first-seen" mempool semantics are left unchanged for transactions that do not opt-in. At last week's IRC meeting(1)

Re: [bitcoin-dev] request to use service bit 28 for testing

On Sat, Nov 14, 2015 at 03:27:49PM -0800, Peter Tschipper via bitcoin-dev wrote: > I'd like to use service bit 28 for testing the block compression > prototype unless anyone has any objections or is using it already. Go for it! AFAIK the only testing service bit in use right now is bit 26, used

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

On Tue, Nov 03, 2015 at 09:44:02PM +, Christian Decker via bitcoin-dev 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

Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change

On Sat, Oct 03, 2015 at 04:30:56PM +0200, Peter Todd via bitcoin-dev wrote: > BIP68 and BIP112 collectively define the CHECKSEQUENCEVERIFY semantics, Another issue that came to mind re: CSV review is that there isn't actually any one pull-req with all the code changes together, making it h

Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change

On Tue, Oct 06, 2015 at 12:28:49PM +1030, Rusty Russell wrote: > Peter Todd via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> > writes: > > However I don't think we've done a good job showing why we need to > > implement this feature via nSequence. > > It coul

Re: [bitcoin-dev] Public Debate Challenge

On Wed, Oct 07, 2015 at 05:19:29PM +0700, Venzen Khaosan via bitcoin-dev wrote: > Mike Hearn, > > I challenge you to a public debate with the following conditions: This is very off-topic for a development mailing list. Go away. -- 'peter'[:-1]@petertodd.org

Re: [bitcoin-dev] BIP: Using Median time-past as endpoint for locktime calculations

On Thu, Aug 27, 2015 at 11:08:32PM +0100, Btc Drak wrote: This BIP was assigned number 113. I have updated the text accordingly and added credits to Gregory Maxwell. Please see the changes in the pull request: https://github.com/bitcoin/bips/pull/182 On Thu, Aug 27, 2015 at 11:11:10PM

Re: [bitcoin-dev] Short review of previously-proposed exotic SIGHASH types

On Sun, Aug 30, 2015 at 01:56:34PM -0500, Bryan Bishop via bitcoin-dev wrote: > Here is a short review of previously-proposed and exotic SIGHASH types. > > SIGHASH_MULTIPLE > Similarly, petertodd has asked for a SIGHASH_DONT_SIGN_TXID before to > make OP_CODESEPARATOR more useful. There's also

Re: [bitcoin-dev] ERRATA CORRIGE + Short Theorem

On Sun, Aug 30, 2015 at 10:01:00PM +0200, Daniele Pinna via bitcoin-dev wrote: > Since my longer post seems to be caught in moderator purgatory I will > rehash its results into this much smaller message. I apologize for the > spamming. > > I present a theorem whose thesis is obvious to many. > >

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

On Thu, Sep 03, 2015 at 11:18:08PM +, Gregory Maxwell via bitcoin-dev wrote: > 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

Re: [bitcoin-dev] BIP 100 specification

On Thu, Sep 03, 2015 at 06:32:09PM +0100, Btc Drak via bitcoin-dev wrote: > Just use a 4-byte unsigned integer where the integer is the size in > bytes. It's concise and less complex (and less complex to implement). > There's no need for human readable strings here. Solid NACK on making string

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

On Fri, Sep 04, 2015 at 01:13:18PM -0700, Andy Chase via bitcoin-dev wrote: > Thanks for your thoughts. > > My proposal isn't perfect for sure. There's likely much better ways to do > it. But to be clear what I'm trying to solve is basically this: > > Who makes high-level Bitcoin decisions?

Re: [bitcoin-dev] Proposal to add the bitcoin symbol to Unicode

On Sat, Sep 05, 2015 at 07:11:27AM -0700, Ken Shirriff via bitcoin-dev wrote: > Use of the bitcoin symbol in text is inconvenient, because the bitcoin > symbol isn't in the Unicode standard. To fix this, I've written a proposal > to have the common B-with-vertical-bars bitcoin symbol added to

[bitcoin-dev] python-bitcoinlib-v0.5.0rc1 - OpenSSL crashes on OSX and Arch Linux should be fixed

https://github.com/petertodd/python-bitcoinlib/tree/python-bitcoinlib-v0.5.0rc1 FWIW if you've been experienceing OpenSSL related crashes on OSX or Arch Linux this release should fix your issues. I don't have any way of testing this myself, so if I could get some confirmation that this new

Re: [bitcoin-dev] BIP 100 specification

On Thu, Sep 03, 2015 at 01:34:54PM -0700, Dave Scotese via bitcoin-dev wrote: > I have seen "1M" mean 1,000,000 bytes as well as 1,048,576bytes and > 1,024,000 bytes. I believe the best policy is to use "megabyte" to mean > 2^20 (1,048,576) bytes. Kb always means 1024 bytes, even when a lot

Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap [BIP 1xx - Draft]

On Tue, Aug 25, 2015 at 04:26:23PM -0400, Matt Whitlock wrote: On Tuesday, 25 August 2015, at 1:16 pm, Peter Todd via bitcoin-dev wrote: What would you think of an approach like John Dillon's proposal to explicitly give the economic majority of coin holders a vote for the max blocksize

Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap [BIP 1xx - Draft]

On Wed, Aug 26, 2015 at 05:44:46AM +0800, Chun Wang wrote: On Wed, Aug 26, 2015 at 5:18 AM, Simon Liu via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: I don't think this would work. If the rule is that one user can only have one vote, how do you prevent a user running

Re: [bitcoin-dev] libconsensus and bitcoin development process

On Tue, Sep 15, 2015 at 12:10:37AM -0400, Jeff Garzik via bitcoin-dev wrote: > Refactors however have a very real negative impact. > bitcoin/bitcoin.git is not only the source tree in the universe. > Software engineers at home, at startups, and at major companies are > maintaining branches of

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 17 September 2015 19:56:17 GMT-07:00, Alex Morcos via bitcoin-dev wrote: >+1 >sounds good to me! +2 My schedule is chaotic, but I'll try to attend. -BEGIN PGP SIGNATURE-

Re: [bitcoin-dev] python-bitcoinlib-v0.5.0rc1 - OpenSSL crashes on OSX and Arch Linux should be fixed

On Sun, Sep 06, 2015 at 08:43:24PM -0400, Peter Todd via bitcoin-dev wrote: > https://github.com/petertodd/python-bitcoinlib/tree/python-bitcoinlib-v0.5.0rc1 No issues have been reported with the release candidate, so I've released v0.5.0 officially pretty much as-is: https://github.

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

On Mon, Sep 28, 2015 at 03:41:56PM +0200, Mike Hearn wrote: > > > > 1) Do you agree that CLTV should be added to the Bitcoin protocol? > > > > Ignoring the question how exactly it is added, hard-fork or soft-fork. > > > > The opcode definition seems OK. Good! > > 2) Will you add a

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

On Mon, Sep 28, 2015 at 09:43:42AM -0400, Gavin Andresen wrote: > On Mon, Sep 28, 2015 at 9:28 AM, Peter Todd wrote: > > > > 2) Mr. Todd (or somebody) needs to write up a risk/benefit security > > > tradeoff analysis doo-hickey document and publish it. I'm reasonably > > >

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

On Mon, Sep 28, 2015 at 04:33:23PM +0200, Mike Hearn wrote: > > > > SPV wallets can't detect hard-forks > > > They don't have to - they pick the highest work chain. Any miner who hasn't > upgraded makes blocks on the shorter chain that are then ignored (or > rather, stored for future reorgs).

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

On Sun, Sep 27, 2015 at 04:26:12PM -0400, jl2...@xbt.hk wrote: > +1 for deploying BIP65 immediately without further waiting. Agree > with all Peter's points. Thanks! > By the way, is there any chance to backport it to 0.9? In the > deployment of BIP66 some miners requested a backport to 0.9 and

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

Summary --- It's time to deploy BIP65 CHECKLOCKTIMEVERIFY. I've backported the CLTV op-code and a IsSuperMajority() soft-fork to the v0.10 and v0.11 branches, pull-reqs #6706 and #6707 respectively. A pull-req for git HEAD for the soft-fork deployment has been open since June 28th, #6351 -

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

On Mon, Sep 28, 2015 at 12:48:57PM +0200, Mike Hearn wrote: > There is *no* consensus on using a soft fork to deploy this feature. It > will result in the same problems as all the other soft forks - SPV wallets > will become less reliable during the rollout period. I am against that, as > it's

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

On Mon, Sep 28, 2015 at 09:01:02AM -0400, Gavin Andresen wrote: > I think three things need to happen: > > 1) Stop pretending that "everyone must agree to make consensus rule > changes." "Rough consensus" is what we've always gone with, and is good > enough. > > 2) Mr. Todd (or somebody) needs

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 24 September 2015 14:56:23 GMT-04:00, Suhas Daftuar wrote: >I considered that as well, but it seemed to me that other software on >the >network (say, different wallet implementations) might prefer the option >of >being

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 24 September 2015 14:37:40 GMT-04:00, Suhas Daftuar via bitcoin-dev wrote: >On Thu, Sep 24, 2015 at 2:17 PM, Tier Nolan via bitcoin-dev < >bitcoin-dev@lists.linuxfoundation.org> wrote: > >> >> Is there

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

On Fri, Sep 18, 2015 at 08:06:23PM +, Matt Corallo via bitcoin-dev wrote: > I did not intend to imply that there was agreement on a desire to > schedule a second hardfork. My wording may have been a bit too loose. > Instead, I believe there was much agreement that doing a short-term > hardfork

Re: [bitcoin-dev] Opt-in Full Replace-By-Fee (Full-RBF)

On Sun, Nov 29, 2015 at 10:32:34PM -0500, Chris via bitcoin-dev wrote: > On 11/16/2015 07:42 PM, Peter Todd via bitcoin-dev wrote: > > Sequence is used for opting in as it is the only "free-form" field > > available for that purpose. Opt-in per output was proposed as wel

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

On Thu, Dec 17, 2015 at 04:58:02PM +, Tier Nolan via bitcoin-dev wrote: > This is really the most important question. > > Bitcoin is kind of like a republic where there is separation of powers > between various groups. > > The power blocs in the process include > > - Core Devs > - Miners >

Re: [bitcoin-dev] Segregated witnesses and validationless mining

On Tue, Dec 22, 2015 at 05:31:19PM -0800, Peter Todd via bitcoin-dev wrote: > # Summary Updates from IRC discussion: 1) There was some debate about what exactly should be required from the current block to calculate the previous block posession proof. For instance, requiring the coinbase outp

Re: [bitcoin-dev] How to preserve the value of coins after a fork.

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 30 December 2015 12:22:43 GMT-08:00, "Emin Gün Sirer" wrote: >On Wed, Dec 30, 2015 at 3:16 PM, Peter Todd wrote: > >> Note how transaction malleability can quickly sabotage naive notions >of >> this

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

On Thu, Jan 07, 2016 at 08:54:00PM -0500, Gavin Andresen via bitcoin-dev wrote: > --- > > I'm really disappointed with the "Here's the spec, take it or leave it" > attitude. What's the point of having a BIP process if the discussion just > comes down to "We think more is better. We don't care

[bitcoin-dev] Segregated witnesses and validationless mining

# Summary 1) Segregated witnesses separates transaction information about what coins were transferred from the information proving those transfers were legitimate. 2) In its current form, segregated witnesses makes validationless mining easier and more profitable than the status quo,

Re: [bitcoin-dev] Segregated witnesses and validationless mining

On Tue, Dec 22, 2015 at 05:31:19PM -0800, Peter Todd via bitcoin-dev wrote: > # Easy solution: previous witness data proof > > To return segregated witnesses to the status quo, we need to at least > make having the previous block's witness data be a precondition to > c

Re: [bitcoin-dev] The increase of max block size should be determined by block height instead of block time

On Sat, Dec 19, 2015 at 03:17:03AM +0800, Chun Wang via bitcoin-dev wrote: > In many BIPs we have seen, include the latest BIP202, it is the block > time that determine the max block size. From from pool's point of > view, it cannot issue a job with a fixed ntime due to the existence of > ntime

Re: [bitcoin-dev] We need to fix the block withholding attack

On Sat, Dec 19, 2015 at 07:43:59PM -0800, Chris Priest via bitcoin-dev wrote: > Then shouldn't this be something the pool deals with, not the bitcoin > protocol? There is no known way for pools - especially ones that allow anonymous hashers - to effectively prevent block withholding attacks

Re: [bitcoin-dev] The increase of max block size should be determined by block height instead of block time

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 18 December 2015 11:52:19 GMT-08:00, "Jorge Timón via bitcoin-dev" wrote: >I agree that nHeight is the simplest option and is my preference. >Another option is to use the median time from the previous

Re: [bitcoin-dev] We need to fix the block withholding attack

On Sat, Dec 26, 2015 at 12:12:13AM -0800, Multipool Admin wrote: > Any attempt to 'fix' this problem, would most likely require changes to all > mining software, why not just make mining more decentralized in general? > > For example, allow anyone to submit proofs of work to Bitcoind that are >

[bitcoin-dev] We can trivially fix quadratic CHECKSIG with a simple soft-fork modifying just SignatureHash()

Occured to me that this hasn't been mentioned before... We can trivially fix the quadratic CHECK(MULTI)SIG execution time issue by soft-forking in a limitation on just SignatureHash() to only return true if the tx size is <100KB. (or whatever limit makes sense) This fix has the advantage over

Re: [bitcoin-dev] We need to fix the block withholding attack

On Sun, Dec 20, 2015 at 12:12:49AM -0500, Emin Gün Sirer via bitcoin-dev wrote: > There's quite a bit of confusion in this thread. > > Peter is referring to block withholding attacks. Ittay Eyal (as sole > author -- I was not involved in this paper [1]) was the first Ah, thanks for the

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 20 December 2015 08:30:45 GMT-08:00, Chris Pacia wrote: >On Dec 20, 2015 6:34 AM, "Jeff Garzik via bitcoin-dev" < >bitcoin-dev@lists.linuxfoundation.org> wrote: > >> 2) This reverses the useful minimization attribute of HD

Re: [bitcoin-dev] An implementation of BIP102 as a softfork.

On Wed, Dec 30, 2015 at 05:29:05AM -0800, Jonathan Toomim via bitcoin-dev wrote: > As a first impression, I think this proposal is intellectually interesting, > but crufty and hackish and should never actually be deployed. Writing code > for Bitcoin in a future in which we have deployed a few

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 10 January 2016 22:57:15 GMT-05:00, Rusty >Cheers, >Rusty. >[1] Weirdly, the bitcoin network is doing this much work every 57 >days, for about $92M. If that's all the attack costs, it's under >1M in 10 years. Don't get too caught up

[bitcoin-dev] Closed Seal Sets and Truth Lists for Better Privacy and Censorship Resistance

At the recent coredev.tech meetup in Zurich I spent much of my time discussing anti-censorship improvements with Adam Back, building on his idea of blind symmetric commitments[^bsc], and my own ideas of client-side verification. Our goal here is to combat censorship by ensuring that miners do not

Re: [bitcoin-dev] Building Blocks of the State Machine Approach to Consensus

On Mon, Jun 20, 2016 at 04:21:39PM +, zaki--- via bitcoin-dev wrote: > Hi Peter, > > I didn't entirely understand the process of transaction linearization. > > What I see is a potential process where when the miner assembles the block, > he strips all but one sigscript per tx. The selection

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

On Tue, Jun 21, 2016 at 10:50:36PM +, James MacWhyte wrote: > > Note that "client supplied identification" is being pushed for AML/KYC > > compliance, e.g. Netki's AML/KYC compliance product: > > > > > >

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

On Tue, Jun 21, 2016 at 08:44:37PM +, Luke Dashjr via bitcoin-dev wrote: > 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 > >

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

On Mon, Jun 20, 2016 at 05:33:32PM +, 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] Even more proposed BIP extensions to BIP 0070

On Tue, Jun 21, 2016 at 08:44:37PM +, Luke Dashjr via bitcoin-dev wrote: > X509 is entrenched, so it should remain supported. PGP might make sense for > people already using it (it provides no real security for un-WoT-networked > users), but unforunately, few people use it. Correct me if I'm

Re: [bitcoin-dev] Merkle trees and mountain ranges

On Fri, Jun 17, 2016 at 08:22:04PM -0700, Bram Cohen wrote: > On Wed, Jun 15, 2016 at 5:10 PM, Peter Todd wrote: > > Agreed - regardless of approach adding latency to commitment calculations > > of > > all kinds is something I think we all agree can work in principle, although

Re: [bitcoin-dev] Merkle trees and mountain ranges

On Fri, Jun 17, 2016 at 07:43:47PM -0700, Bram Cohen wrote: > On Thu, Jun 16, 2016 at 9:34 PM, Peter Todd wrote: > > > So above you said that in merbinner trees each node "hash[es] in a record > > of > > its depth" That's actually incorrect: each node commits to the prefix

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

On Tue, Jun 21, 2016 at 05:14:31PM -0700, Justin Newton wrote: > On Tue, Jun 21, 2016 at 3:13 PM, Peter Todd via bitcoin-dev < > Hi Peter, >Certainly AML/KYC compliance is one of the use cases that BIP 75 and our > certificates can support. As a quick summary, > >

Re: [bitcoin-dev] Building Blocks of the State Machine Approach to Consensus

On Mon, Jun 20, 2016 at 01:26:22PM +, Police Terror via bitcoin-dev wrote: > Bitcoin could embed a lisp interpreter such as Scheme, reverse engineer > the current protocol into lisp (inside C++), run this alternative engine > alongside the current one as an option for some years (only for fine

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

On Thu, Jun 23, 2016 at 01:30:45PM +0200, Pieter Wuille wrote: > On Jun 23, 2016 12:56, "Peter Todd via bitcoin-dev" < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > > In any case, I'd strongly argue that we remove BIP75 from the bips > repository, >

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

On Thu, Jun 23, 2016 at 02:01:10PM +0200, Pieter Wuille wrote: > On Thu, Jun 23, 2016 at 1:39 PM, Peter Todd wrote: > > On Thu, Jun 23, 2016 at 01:30:45PM +0200, Pieter Wuille wrote: > > For the record, I think the idea of the bips repo being a pure publication > > platform

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

On Thu, Jun 23, 2016 at 02:16:48PM +0200, Pieter Wuille wrote: > On Jun 23, 2016 14:10, "Peter Todd" wrote: > > > Right, so you accept that we'll exert some degree of editorial control; > the > > question now is what editorial policies should we exert? > > No, I do not. I am

Re: [bitcoin-dev] Merkle trees and mountain ranges

On Tue, Jun 14, 2016 at 05:14:23PM -0700, Bram Cohen via bitcoin-dev wrote: > This is in response to Peter Todd's proposal for Merkle Mountain Range > commitments in blocks: > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-May/012715.html > > I'm in strong agreement that there's

Re: [bitcoin-dev] Merkle trees and mountain ranges

On Thu, Jun 16, 2016 at 02:07:26AM -0700, Bram Cohen wrote: > On Wed, Jun 15, 2016 at 8:26 PM, Peter Todd wrote: > Okay, clearly my assumptions about the parts of that post I didn't read > carefully were way off. I'll have to look through it carefully to be able > to make

Re: [bitcoin-dev] Building Blocks of the State Machine Approach to Consensus

On Thu, Jun 23, 2016 at 03:58:29PM +0300, Alex Mizrahi wrote: > > > > The point I'm making is simply that to be useful, when you close a seal you > > have to be able to close it over some data, in particular, another seal. > > That's > > the key thing that makes the idea a useful construct for

Re: [bitcoin-dev] Merkle trees and mountain ranges

On Wed, Jun 15, 2016 at 06:16:26PM -0700, Bram Cohen wrote: > On Wed, Jun 15, 2016 at 5:10 PM, Peter Todd wrote: > > > On Tue, Jun 14, 2016 at 05:14:23PM -0700, Bram Cohen via bitcoin-dev wrote: > > > > > > Peter proposes that there should be both UTXO and STXO commitments,

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

On Sat, Feb 06, 2016 at 12:45:14PM -0500, Gavin Andresen via bitcoin-dev wrote: > On Sat, Feb 6, 2016 at 12:01 PM, Adam Back wrote: > > > > > It would probably be a good idea to have a security considerations > > section > > > Containing what? I'm not aware of any

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

On Sun, Feb 07, 2016 at 10:06:06AM -0500, Alex Morcos via bitcoin-dev wrote: > And the back and forth discussion over your BIP has been in large part a > charade. People asking why you aren't picking 95% know very well why you > aren't, but lets have an honest discussion of what the risks and in

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

On Mon, Feb 08, 2016 at 02:36:47PM -0800, Simon Liu via bitcoin-dev wrote: > > 1) The segregated witness discount is changed from 75% to 50%. The block > > size limit (ie transactions + witness/2) is set to 1.5MB. This gives a > > maximum block size of 3MB and a "network-upgraded" block size of

Re: [bitcoin-dev] Hardfork bit BIP

On Thu, Feb 04, 2016 at 12:36:06PM -0500, Gavin Andresen via bitcoin-dev wrote: > This BIP is unnecessary, in my opinion. > > I'm going to take issue with items (2) and (3) that are the motivation for > this BIP: > > " 2. Full nodes and SPV nodes following original consensus rules may not be >

[bitcoin-dev] Segwit Upgrade Procedures & Block Extension Data

A few notes on upgrade procedures associated with segregated witnesses: Initial Deployment == While segregated witnesses is a soft-fork, because it adds new data blocks that old nodes don't relay segwit nodes can't sync from non-segwit nodes and still be fully validating; once

  1   2   3   4   >