Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

2015-06-18 Thread Gregory Maxwell
On Thu, Jun 18, 2015 at 1:36 PM, Mike Hearn m...@plan99.net wrote: And allegations that the project is run like wikipedia or an edit war are verifyably untrue. Check the commit history. This was a reference to a post by Gregory on Reddit where he said if Gavin were to do a pull request for

Re: [Bitcoin-development] [BIP draft] Consensus-enforced transaction replacement signalled via sequence numbers

2015-06-16 Thread Gregory Maxwell
On Wed, Jun 17, 2015 at 1:00 AM, Mark Friedenbach m...@friedenbach.org wrote: Given that we have had more than two weeks of public discussion, code is available and reviewed, and several community identified issues resolved, I would like to formally request a BIP number be assigned for this

Re: [Bitcoin-development] [RFC] Canonical input and output ordering in transactions

2015-06-14 Thread Gregory Maxwell
On Sat, Jun 6, 2015 at 4:42 AM, Rusty Russell ru...@rustcorp.com.au wrote: Title: Canonical Input and Output Ordering Author: Rusty Russell ru...@rustcorp.com.au Discussions-To: Bitcoin Dev bitcoin-development@lists.sourceforge.net Status: Draft Type: Standards Track Created: 2015-06-06

Re: [Bitcoin-development] [RFC] Canonical input and output ordering in transactions

2015-06-14 Thread Gregory Maxwell
On Mon, Jun 8, 2015 at 9:25 PM, Danny Thorpe danny.tho...@gmail.com wrote: Recommending sorting of the inputs and outputs as a best practice is fine (and better than random, IMO), but not as part of IsStandard() or consensus rules. There are cases where the order of the inputs and outputs is

Re: [Bitcoin-development] Proposal: Move Bitcoin Dev List to a Neutral Competent Entity

2015-06-14 Thread Gregory Maxwell
On Sun, Jun 14, 2015 at 10:12 AM, Warren Togami Jr. wtog...@gmail.com wrote: From the perspective of our community, for bitcoin-dev it seems like a great fit. Why? While they are interested in supporting general open source development, the LF has literally zero stake in this. In addition to

Re: [Bitcoin-development] Consensus-enforced transaction replacement via sequence numbers

2015-05-27 Thread Gregory Maxwell
On Wed, May 27, 2015 at 7:47 AM, Peter Todd p...@petertodd.org wrote: Equally this proposal is no more consensus enforcement than simply increasing the fee (and possibly decreasing the absolute nLockTime) for You've misunderstood it, I think-- Functionally nlocktime but relative to each txin's

Re: [Bitcoin-development] Long-term mining incentives

2015-05-27 Thread Gregory Maxwell
On Wed, May 27, 2015 at 9:59 PM, Mike Hearn m...@plan99.net wrote: I wrote an article that explains the hashing assurance contract concept: https://medium.com/@octskyward/hashing-7d04a887acc8 (it doesn't contain an in depth protocol description) The prior (and seemingly this) assurance

Re: [Bitcoin-development] First-Seen-Safe Replace-by-Fee

2015-05-26 Thread Gregory Maxwell
On Tue, May 26, 2015 at 5:54 PM, Tom Harding t...@thinlink.com wrote: It's not difficult to imagine real-world consequences to not having contributed to the transaction. I'm having a hard time. Can you help me understand a specific case where this makes a difference. It appears to be a

Re: [Bitcoin-development] First-Seen-Safe Replace-by-Fee

2015-05-26 Thread Gregory Maxwell
On Tue, May 26, 2015 at 11:00 PM, Tom Harding t...@thinlink.com wrote: The bitcoin transaction is part of a real-world deal with unknown connections to the other parts I'm having a hard time parsing this. You might as well say that its part of a weeblix for how informative it is, since you've

Re: [Bitcoin-development] Proposed additional options for pruned nodes

2015-05-12 Thread Gregory Maxwell
It's a little frustrating to see this just repeated without even paying attention to the desirable characteristics from the prior discussions. Summarizing from memory: (0) Block coverage should have locality; historical blocks are (almost) always needed in contiguous ranges. Having random

Re: [Bitcoin-development] Proposed additional options for pruned nodes

2015-05-12 Thread Gregory Maxwell
On Tue, May 12, 2015 at 8:10 PM, Jeff Garzik jgar...@bitpay.com wrote: True. Part of the issue rests on the block sync horizon/cliff. There is a value X which is the average number of blocks the 90th percentile of nodes need in order to sync. It is sufficient for the [semi-]pruned nodes to

Re: [Bitcoin-development] Proposed alternatives to the 20MB step function

2015-05-10 Thread Gregory Maxwell
On Sun, May 10, 2015 at 9:21 PM, Gavin Andresen gavinandre...@gmail.com wrote: a while I think any algorithm that ties difficulty to block size is just a complicated way of dictating minimum fees. Thats not the long term effect or the motivation-- what you're seeing is that the subsidy gets in

Re: [Bitcoin-development] A way to create a fee market even without a block size limit (2013)

2015-05-10 Thread Gregory Maxwell
On Sun, May 10, 2015 at 8:45 PM, Sergio Lerner sergioler...@certimix.com wrote: Can the system by gamed? Users can pay fees or a portion of fees out of band to miner(s); this is undetectable to the network. It's also behavior that miners have engaged in since at least 2011 (in two forms;

Re: [Bitcoin-development] Proposed alternatives to the 20MB step function

2015-05-08 Thread Gregory Maxwell
On Fri, May 8, 2015 at 8:33 PM, Mark Friedenbach m...@friedenbach.org wrote: These rules create an incentive environment where raising the block size has a real cost associated with it: a more difficult hashcash target for the same subsidy reward. For rational miners that cost must be

Re: [Bitcoin-development] Bitcoin-development Digest, Vol 48, Issue 41

2015-05-08 Thread Gregory Maxwell
On Sat, May 9, 2015 at 12:00 AM, Damian Gomez dgomez1...@gmail.com wrote: ...of the following: the DH_GENERATION would in effect calculate the reponses for a total overage of the public component, by addding a ternary option in the actual DH key (which I have attached to sse if you can

Re: [Bitcoin-development] Block Size Increase

2015-05-06 Thread Gregory Maxwell
On Wed, May 6, 2015 at 10:12 PM, Matt Corallo bitcoin-l...@bluematt.me wrote: Recently there has been a flurry of posts by Gavin at http://gavinandresen.svbtle.com/ which advocate strongly for increasing the maximum block size. However, there hasnt been any discussion on this mailing list in

Re: [Bitcoin-development] Reusable payment codes

2015-04-24 Thread Gregory Maxwell
On Fri, Apr 24, 2015 at 8:00 PM, Justus Ranvier justus.ranv...@monetas.net wrote: https://github.com/justusranvier/rfc/blob/payment_code/bips/bip-pc01.mediawiki This link contains an RFC for a new type of Bitcoin address called a payment code Payment codes are SPV-friendly alternatives to

Re: [Bitcoin-development] 75%/95% threshold for transaction versions

2015-04-24 Thread Gregory Maxwell
On Fri, Apr 24, 2015 at 7:58 PM, William Swanson swanson...@gmail.com wrote: On Thu, Apr 16, 2015 at 9:12 AM, s7r s...@sky-ip.org wrote: Thanks for your reply. I agree. Allen has a good point in the previous email too, so the suggestion might not fix anything and complicate things. The BIP 62

Re: [Bitcoin-development] Build your own nHashType

2015-04-14 Thread Gregory Maxwell
On Wed, Apr 8, 2015 at 7:50 PM, Stephen Morse stephencalebmo...@gmail.com wrote: Seeking feedback on a proposal that will allow a transaction signer to explicitly specify what is to be serialized for the signature hash. The basic idea is to make the nHashType general enough that we won't need a

Re: [Bitcoin-development] PAPER: New algorithm for the discrete logarithm problem on elliptic curves

2015-04-07 Thread Gregory Maxwell
On Tue, Apr 7, 2015 at 9:32 PM, Jean-Paul Kogelman jeanpaulkogel...@me.com wrote: https://eprint.iacr.org/2015/310.pdf http://www.reddit.com/r/Bitcoin/comments/31rcuo/new_algorithm_for_the_discrete_logarithm_problem/cq4b52u

Re: [Bitcoin-development] Address Expiration to Prevent Reuse

2015-03-26 Thread Gregory Maxwell
On Fri, Mar 27, 2015 at 1:51 AM, Thy Shizzle thyshiz...@outlook.com wrote: Yes I agree, also there is talks about a government body I know of warming to bitcoin by issuing addresses for use by a business and then all transactions can be tracked for that business entity. This is one proposal I

Re: [Bitcoin-development] Address Expiration to Prevent Reuse

2015-03-26 Thread Gregory Maxwell
On Thu, Mar 26, 2015 at 8:38 PM, Tom Harding t...@thinlink.com wrote: I addressed that by limiting the duplicate check to an X-block segment. X is hard-coded in this simple scheme (X=144 = 1-day addresses). You could picture a selectable expiration duration too. If its to be heuristic in

Re: [Bitcoin-development] Address Expiration to Prevent Reuse

2015-03-26 Thread Gregory Maxwell
On Thu, Mar 26, 2015 at 9:26 PM, Tom Harding t...@thinlink.com wrote: I should have been clearer that the motivation for address expiration is to reduce the rate of increase of the massive pile of bitcoin addresses out there which have to be monitored forever for future payments. It could make

Re: [Bitcoin-development] Address Expiration to Prevent Reuse

2015-03-26 Thread Gregory Maxwell
On Thu, Mar 26, 2015 at 10:28 PM, s7r s...@sky-ip.org wrote: This should not be enforced by default. No one suggested _anything_ like that. Please save the concern for someplace its actually applicable. I know it's not recommended to use the same pubkey more than once, but the protocol was

Re: [Bitcoin-development] BIP32 Index Randomisation

2015-03-12 Thread Gregory Maxwell
This seems overly complicated to me, unless I'm missing something. Instead, I think you should just give the server the master pubkey P only without the chaincode. Then when you transact you generate the address in whatever manner you like and tell the server the scalar value iL which the user

Re: [Bitcoin-development] BIP for standard multi-signature P2SH addresses

2015-03-11 Thread Gregory Maxwell
On Wed, Mar 11, 2015 at 11:45 AM, Thomas Kerin m...@thomaskerin.io wrote: I used BIP0090 as a place-holder, but I would like to request a BIP number for this now. We have had repeated problems in the past with people working on and circulating prior draft proposals squatting on each others

Re: [Bitcoin-development] Electrum 2.0 has been tagged

2015-03-11 Thread Gregory Maxwell
On Wed, Mar 11, 2015 at 7:24 PM, Ricardo Filipe ricardojdfil...@gmail.com wrote: i guess you look at the glass half full :) even though what you say is true, we should aim for wallets not to require those instructions, by standardizing these things in BIPs. let's hope bitcoin doesn't fail in

Re: [Bitcoin-development] BIP for standard multi-signature P2SH addresses

2015-03-11 Thread Gregory Maxwell
On Wed, Mar 11, 2015 at 11:24 PM, Pindar Wong pindar.w...@gmail.com wrote: Perhaps at some point consider introducing something akin to a 'Bitcoin-Draft' (BD) status with some autoexpiry period? I understand that the Internet Engineering Task Force (IETF) has the concept of 'Internet Drafts

Re: [Bitcoin-development] Electrum 2.0 has been tagged

2015-03-11 Thread Gregory Maxwell
On Wed, Mar 11, 2015 at 11:50 PM, devrandom c1.sf-bitc...@niftybox.net wrote: That said, I do agree that mnemonic phrases should be portable, and find it unfortunate that the ecosystem is failing to standardize on phrase handling. The fact remains that there are several apparently unresolvable

Re: [Bitcoin-development] Electrum 2.0 has been tagged

2015-03-11 Thread Gregory Maxwell
On Thu, Mar 12, 2015 at 2:41 AM, devrandom c1.sf-bitc...@niftybox.net wrote: I think there are some important advantages to not being forced to use the old wallet to send coins when switching wallets. The three I can think of right now are: maintaining transaction history, Just loading a key

[Bitcoin-development] BCF 2012 Miner vote

2015-02-25 Thread Gregory Maxwell
It would appear that the Bitcoin Foundation has decided that their next two seats would be decided by miners. (More information available at: https://bitcoinfoundation.org/forum/index.php?/topic/1255-blockchain-voting/#entry13453 ) Unfortunately, they seem to have not provided the software

Re: [Bitcoin-development] bloom filtering, privacy

2015-02-20 Thread Gregory Maxwell
On Fri, Feb 20, 2015 at 4:54 PM, Mike Hearn m...@plan99.net wrote: And then what? So you know the block matches. But with reasonable FP rates every block will match at least a few transactions (this is already the case This approach needs a filter set with a lower FP rate. It doesn't depend on

Re: [Bitcoin-development] bloom filtering, privacy

2015-02-20 Thread Gregory Maxwell
On Fri, Feb 20, 2015 at 5:59 PM, Adam Back a...@cypherspace.org wrote: So now they ask a full node for merkle paths + transactions for the addresses from the UTXO set from the block(s) that it was found in. Use of the words UTXO set here is probably confusing people as it's likely to make

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

2015-02-12 Thread Gregory Maxwell
On Thu, Feb 12, 2015 at 1:18 PM, Mike Hearn m...@plan99.net wrote: history. Lots of miners have dropped out due to hardware obsolescence, yet massive double spending hasn't happened. How many thousands of BTC must be stolen by miners before you'd agree that it has, in fact, happened?

Re: [Bitcoin-development] determining change addresses using the least significant digits

2015-02-06 Thread Gregory Maxwell
On Wed, Feb 4, 2015 at 2:23 PM, Isidor Zeuner cryptocurrenc...@quidecco.de wrote: Hi there, traditionally, the Bitcoin client strives to hide which output addresses are change addresses going back to the payer. However, especially with today's dynamically calculated miner fees, this may

Re: [Bitcoin-development] [softfork proposal] Strict DER signatures

2015-02-02 Thread Gregory Maxwell
On Tue, Feb 3, 2015 at 12:44 AM, Pieter Wuille pieter.wui...@gmail.com wrote: The much simpler alternative is just adding this to BIP66's DERSIG right now, which is a one-line change that's obviously softforking. Is anyone opposed to doing so at this stage? Thats my preference.

Re: [Bitcoin-development] Bitcoin Core 0.9.4 not on bitcoin.org?

2015-02-01 Thread Gregory Maxwell
On Sun, Feb 1, 2015 at 8:08 PM, xor x...@freenetproject.org wrote: Why is that? Because Binaries on Bitcoin.org have always been unaffected by the issue 0.9.4 was released to address. Also, is it correct that there wasn't a release candidate before the release? Sounds dangerous to me. The

Re: [Bitcoin-development] [softfork proposal] Strict DER signatures

2015-01-26 Thread Gregory Maxwell
On Mon, Jan 26, 2015 at 5:14 AM, Pieter Wuille pieter.wui...@gmail.com wrote: On Tue, Jan 20, 2015 at 8:35 PM, Pieter Wuille pieter.wui...@gmail.com wrote: I therefore propose a softfork to make non-DER signatures illegal (they've been non-standard since v0.8.0). A draft BIP text can be

Re: [Bitcoin-development] SIGHASH_WITHINPUTVALUE

2015-01-23 Thread Gregory Maxwell
On Fri, Jan 23, 2015 at 4:18 PM, slush sl...@centrum.cz wrote: Can you send me any reference about this? Of course if that solves the problem, hard fork would not be necessary anymore. I'm just not aware of any. Sure; will aggregate up the citations when I'm not travling later today. To sign

Re: [Bitcoin-development] SIGHASH_WITHINPUTVALUE

2015-01-23 Thread Gregory Maxwell
On Fri, Jan 23, 2015 at 5:40 PM, slush sl...@centrum.cz wrote: Yes, the step you're missing is and build the table. Dynamic memory allocation is something you want to avoid, as well as any artifical restrictions to number of inputs or outputs. Current solution is slow, but there's really no

Re: [Bitcoin-development] SIGHASH_WITHINPUTVALUE

2015-01-23 Thread Gregory Maxwell
On Fri, Jan 23, 2015 at 3:24 PM, Alan Reiner etothe...@gmail.com wrote: Unfortunately, it seems that there was no soft-fork way to achieve this benefit, at least not one that had favorable properties. Most of the soft-fork variations of it required the coins being spent to have been

[Bitcoin-development] OpenSSL 1.0.0p / 1.0.1k incompatible, causes blockchain rejection.

2015-01-09 Thread Gregory Maxwell
OpenSSL 1.0.0p / 1.0.1k was recently released and is being pushed out by various operating system maintainers. My review determined that this update is incompatible with the Bitcoin system and could lead to consensus forks. Bitcoin Core released binaries from Bitcoin.org are unaffected, as are

Re: [Bitcoin-development] Bi-directional micropayment channels with CHECKLOCKTIMEVERIFY

2015-01-09 Thread Gregory Maxwell
On Fri, Jan 9, 2015 at 1:20 PM, Mike Hearn m...@plan99.net wrote: A limitation on most existing micropayment channel ideas is that payments can only flow in one direction. It's worth noting that the original protocol as designed by Satoshi did not have this limitation. It has evolved this way

Re: [Bitcoin-development] Bi-directional micropayment channels with CHECKLOCKTIMEVERIFY

2015-01-09 Thread Gregory Maxwell
On Fri, Jan 9, 2015 at 1:42 PM, Mike Hearn m...@plan99.net wrote: Additionally, there is a school of thought that says Bitcoin must work even if lots of miners are malicious and willing to break arbitrary things in order to try and get more money. I don't think Bitcoin can really be a This

Re: [Bitcoin-development] Re-enabling simple tx replacement

2015-01-04 Thread Gregory Maxwell
On Sun, Jan 4, 2015 at 2:43 PM, Ross Nicoll j...@jrn.me.uk wrote: Dear all, I've been looking at atomic cross-chain trading ( https://en.bitcoin.it/wiki/Atomic_cross-chain_trading ) between the Bitcoin and Dogecoin blockchains, and have a mostly functional prototype. However as it stands if

Re: [Bitcoin-development] Re-enabling simple tx replacement

2015-01-04 Thread Gregory Maxwell
On Sun, Jan 4, 2015 at 5:22 PM, Ross Nicoll j...@jrn.me.uk wrote: Grabbing a simple test case: https://chain.so/tx/BTCTEST/f903a31f2474df737d324c60abf2407e1cf7e052844da4ccffbfab81cf6ac1f8 - that won't lock until 0028 UTC on the 5th. I've tried closing the wallet, moving the wallet.dat file

Re: [Bitcoin-development] Re-enabling simple tx replacement

2015-01-04 Thread Gregory Maxwell
On Sun, Jan 4, 2015 at 5:35 PM, Gregory Maxwell gmaxw...@gmail.com wrote: Can you send me the actual raw transaction (that site doesn't appear have a way to get it, only some cooked json output; which doesn't include the sequence number). Nevermind, I guess. I think I figured out your problem

Re: [Bitcoin-development] BIP: Voluntary deposit bonds

2014-12-30 Thread Gregory Maxwell
On Tue, Dec 30, 2014 at 4:25 PM, Sergio Lerner sergioler...@certimix.com wrote: Slight off-topic: That looks like an abuse of the VM. Even P2SH is an abuse of the VM. Gavin's OP_EVAL (hard-fork) should had been chosen. I'm taking about a simple change that goes along the lines of Satoshi's

Re: [Bitcoin-development] BIP: Voluntary deposit bonds

2014-12-29 Thread Gregory Maxwell
On Mon, Dec 29, 2014 at 7:21 PM, Sergio Lerner sergioler...@certimix.com wrote: I propose to allow miners to voluntarily lock funds by letting miners add additional inputs to the coinbase transaction. Currently the coinbase transaction does not allow any real input to be added (only a

Re: [Bitcoin-development] Reading List for Getting Up to Speed

2014-12-24 Thread Gregory Maxwell
On Wed, Dec 24, 2014 at 5:08 PM, Will Bickford wbi...@gmail.com wrote: A tally from August indicated that I may need to slog through 280,000 lines You're counting 170kloc of machine generated code with the translation strings there. The top level (/src) and libconsensus are only about 36kloc.

Re: [Bitcoin-development] Area of Focus

2014-12-20 Thread Gregory Maxwell
On Sat, Dec 20, 2014 at 11:14 AM, Jeremy Spilman jer...@taplink.co wrote: are dnsseeds being blocked ostensibly because they are acting as dyanamic DNS infrastructure for malware sites? Pretty much appears to be the case. In every instance it appears to be automated. This predates the msft

Re: [Bitcoin-development] Recent EvalScript() changes mean CHECKLOCKTIMEVERIFY can't be merged

2014-12-15 Thread Gregory Maxwell
On Mon, Dec 15, 2014 at 12:47 PM, Peter Todd p...@petertodd.org wrote: [snip] Pull-req #4890², specifically commit c7829ea7, changed the This change was authored more than three months ago and merged more than two months ago. [And also, AFAICT, prior to you authoring BIP65] I didn't participate

Re: [Bitcoin-development] BIP 65 and OP_CHECKLOCKTIMEVERIFY inquiry...

2014-11-28 Thread Gregory Maxwell
On Fri, Nov 28, 2014 at 11:45 AM, Flavien Charlon flavien.char...@coinprism.com wrote: This breaks existing invariants and would make the coins potentially less fungible because they wouldn't be reorg safe. I'm not sure coins are ever reorg safe. All it takes is a double spend in the history

Re: [Bitcoin-development] Deanonymisation of clients in Bitcoin P2P network paper

2014-11-27 Thread Gregory Maxwell
On Thu, Nov 27, 2014 at 5:44 PM, Mistr Bigs mister...@gmail.com wrote: I might be mistaken, but it seems to me this paper discusses unintended ways of obtaining the IP addresses of clients involved in transactions on the core Bitcoin network. You're mistaken. :) If a node is used exclusively

Re: [Bitcoin-development] BIP 65 and OP_CHECKLOCKTIMEVERIFY inquiry...

2014-11-27 Thread Gregory Maxwell
On Thu, Nov 27, 2014 at 10:56 PM, Richard Moore m...@ricmoo.com wrote: Heya, I was wondering about BIP 65 regarding the OP_CHECKLOCKTIMEVERIFY, and thought it might make more sense to instead have a OP_CHECKLOCKTIME which would simply push an OP_TRUE or OP_FALSE onto the stack? Updating the

Re: [Bitcoin-development] Deanonymisation of clients in Bitcoin P2P network paper

2014-11-27 Thread Gregory Maxwell
On Fri, Nov 28, 2014 at 12:45 AM, Mistr Bigs mister...@gmail.com wrote: That's what I was trying to say... The researchers are deanonymizing transactions from non-Tor connected hosts. So why are we talking about Tor limitations in response to this? Shouldn't we be discussing how to address the

Re: [Bitcoin-development] Deanonymisation of clients in Bitcoin P2P network paper

2014-11-26 Thread Gregory Maxwell
Since this attack vector has been discussed, I started making some measurements on how effective it is to connect to Bitcoin using Tor, and I found that the number of connections dropping to near-zero is a situation which occurs rather frequently, which suggests that there is still room to

Re: [Bitcoin-development] BIP draft - Auxiliary Header Format

2014-11-09 Thread Gregory Maxwell
Some initial comments... Tying in the protocol changes is really confusing and the fact that they seem to be required out the gates would seemingly make this much harder to deploy. Is there a need to do that? Why can't the p2p part be entirely separate from the comitted data? On Mon, Nov 10,

Re: [Bitcoin-development] The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug

2014-11-06 Thread Gregory Maxwell
On Thu, Nov 6, 2014 at 11:12 PM, Peter Todd p...@petertodd.org wrote: BIP62 does make life easier for wallet authors as they don't have to deal with malleability - maybe! - Yes, I agree for most contract purposes CTLV is what you want to be using, instead of refund transactions beyond being

Re: [Bitcoin-development] Increasing regularity of block times?

2014-10-30 Thread Gregory Maxwell
On Thu, Oct 30, 2014 at 11:18 PM, Rusty Russell ru...@rustcorp.com.au wrote: Hi all, I've been toying with an algorithm to place a ceiling on confirmation latency by allowing weaker blocks after a certain time. Hope this isn't noise, but thought someone must have considered this

[Bitcoin-development] Fwd: death by halving

2014-10-28 Thread Gregory Maxwell
On Tue, Oct 28, 2014 at 8:17 PM, Ferdinando M. Ametrano ferdinando.ametr...@gmail.com wrote: On Oct 25, 2014 9:19 PM, Gavin Andresen gavinandre...@gmail.com wrote: We had a halving, and it was a non-event. Is there some reason to believe next time will be different? In november 2008

Re: [Bitcoin-development] Fwd: death by halving

2014-10-28 Thread Gregory Maxwell
On Tue, Oct 28, 2014 at 9:19 PM, Jérémie Dubois-Lacoste jeremie...@gmail.com wrote: The fact that a topic was brought up many times since a long time, does not mean it is not relevant. I am not saying that it is not relevant, I'm saying the discussion is pointless: No new information has

Re: [Bitcoin-development] DS Deprecation Window

2014-10-27 Thread Gregory Maxwell
On Tue, Oct 28, 2014 at 2:26 AM, Tom Harding t...@thinlink.com wrote: Matt, You're right, thanks. Without double-spend relay, miner won't know that some txes conflict with anything. Even with that, the miner cannot tell, his only safe option is to include no transactions at all. Consider a

Re: [Bitcoin-development] BIP process

2014-10-15 Thread Gregory Maxwell
On Wed, Oct 15, 2014 at 8:29 AM, Wladimir laa...@gmail.com wrote: Hello, I'm trying to create a bit of process around the https://github.com/bitcoin/bips repository. A) Currently a lot of pulls are open for various BIPs and it is not clear who should comment on them, or who decides on

Re: [Bitcoin-development] Malleable booleans

2014-10-14 Thread Gregory Maxwell
On Tue, Oct 14, 2014 at 7:27 AM, Thomas Zander tho...@thomaszander.se wrote: What about rejecting a script where a bool is not explicitly zero or one? I believe this is what he actually meant. -- Comprehensive Server

Re: [Bitcoin-development] Malleable booleans

2014-10-13 Thread Gregory Maxwell
On Tue, Oct 14, 2014 at 2:34 AM, Pieter Wuille pieter.wui...@gmail.com wrote: Hi all, while working on a BIP62 implementation I discovered yet another type of malleability: the interpretation of booleans. Any byte array with non-zero bytes in it (ignoring the highest bit of the last byte,

Re: [Bitcoin-development] Request for review/testing: headers-first synchronization in Bitcoin Core

2014-10-12 Thread Gregory Maxwell
On Sat, Oct 11, 2014 at 11:34 PM, Pieter Wuille pieter.wui...@gmail.com wrote: * Parallel block downloading (much faster sync on typical network connections). Much faster is an understatement. Benchmarking here shows one hour five minutes syncing to 295000. Old code isn't even at 25

Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time

2014-10-09 Thread Gregory Maxwell
On Thu, Oct 9, 2014 at 6:14 AM, Adam Back a...@cypherspace.org wrote: I think you can do everything with the existing script level nlocktime in some kind of turing completeness sense (maybe); but there is a complexity cost that often you have to resort to extra dependent transaction(s) (and

Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time

2014-10-09 Thread Gregory Maxwell
On Thu, Oct 9, 2014 at 6:33 AM, Peter Todd p...@petertodd.org wrote: Speaking of, can anyone think of an example of a complex transaction use-case that is affected by malleability which can't be fixed by CHECKLOCKTIMEVERIFY? I'm sure they exist, but I'm scratching my head trying to think of a

Re: [Bitcoin-development] The Bitcoin Freeze on Transaction Attack (FRONT)

2014-10-07 Thread Gregory Maxwell
On Tue, Oct 7, 2014 at 7:04 PM, Sergio Lerner sergioler...@certimix.com wrote: Using the my previous terminology, automatic fee-sharing (ORBS) is a solution to the freeze problem (FRONT) but opens the windows to CHAKIDO double-spending. and CHAKIDO double-spending is a much worse problem than

Re: [Bitcoin-development] The Bitcoin Freeze on Transaction Attack (FRONT)

2014-10-05 Thread Gregory Maxwell
On Sun, Oct 5, 2014 at 4:00 PM, Sergio Lerner sergioler...@certimix.com wrote: I would like to share with you a vulnerability in the Bitcoin protocol I've been thinking of which might have impact on the future of Bitcoin. Please criticize it! The Freeze on Transaction Problem I should point

Re: [Bitcoin-development] The Bitcoin Freeze on Transaction Attack (FRONT)

2014-10-05 Thread Gregory Maxwell
On Sun, Oct 5, 2014 at 4:40 PM, Gregory Maxwell gmaxw...@gmail.com I should point you to some of the tools that have been discussed in the past which are potentially helpful here: Ah, I should also mention a somewhat more far out approach which helps here as a side effect: If transactions were

Re: [Bitcoin-development] The Bitcoin Freeze on Transaction Attack (FRONT)

2014-10-05 Thread Gregory Maxwell
On Sun, Oct 5, 2014 at 4:54 PM, Jorge Timón jti...@blockstream.io wrote: In any case, it is interesting to think about this things since mining subsidies will eventually disappear and then transaction fees will ALWAYS be higher than subsidies. You can imagine that instead of subsidy Bitcoin

Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time

2014-10-03 Thread Gregory Maxwell
On Fri, Oct 3, 2014 at 7:28 AM, Matt Whitlock b...@mattwhitlock.name wrote: Is there a reason why we can't have the new opcode simply replace the top stack item with the block height of the txout being redeemed? This would not be soft-forking compatible. It also would be unsafe in that it

Re: [Bitcoin-development] BIP43 Purpose code for voting pool HD wallets

2014-09-25 Thread Gregory Maxwell
On Tue, Aug 19, 2014 at 10:11 AM, Justus Ranvier jus...@monetas.net wrote: Two draft information BIPs are attached. I've pinged some people privately but also pinging the list… no commentary on this proposal? -- Meet

Re: [Bitcoin-development] Does anyone have anything at all signed by Satoshi's PGP key?

2014-09-15 Thread Gregory Maxwell
On Mon, Sep 15, 2014 at 3:51 PM, Matt Whitlock b...@mattwhitlock.name wrote: On Monday, 15 September 2014, at 5:10 pm, Thomas Zander wrote: So for instance I start including a bitcoin public key in my email signature. I don't sign the emails or anything like that, just to establish that

Re: [Bitcoin-development] Small update to BIP 62

2014-09-01 Thread Gregory Maxwell
On Fri, Jul 18, 2014 at 8:14 AM, Pieter Wuille pieter.wui...@gmail.com wrote: Hi all, I've sent a pull request to make a small change to BIP 62 (my anti-malleability proposal) which is still a draft; see: * https://github.com/bitcoin/bips/pull/90 (the request) *

Re: [Bitcoin-development] Reconsidering github

2014-08-23 Thread Gregory Maxwell
On Sat, Aug 23, 2014 at 1:36 PM, Paul Rabahy prab...@gmail.com wrote: I want go give a bit of an outsiders perspective. I thoroughly understand the concepts of bitcoin and am a professional programmer, but have never taken the time to compile my own copy of bitcoin core. I have looked at the

Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages

2014-08-19 Thread Gregory Maxwell
On Tue, Aug 19, 2014 at 9:07 AM, Justus Ranvier justusranv...@riseup.net wrote: If that's not acceptable, even using TLS with self-signed certificates would be an improvement. TLS is a huge complex attack surface, any use of it requires an additional dependency with a large amount of difficult

Re: [Bitcoin-development] Reconsidering github

2014-08-19 Thread Gregory Maxwell
On Tue, Aug 19, 2014 at 5:02 AM, Jeff Garzik jgar...@bitpay.com wrote: It would be nice if the issues and git repo for Bitcoin Core were not on such a centralized service as github, nice and convenient as it is. To that end, I note that Linux does its own git repo, and now requires 2FA:

Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages

2014-08-19 Thread Gregory Maxwell
On Tue, Aug 19, 2014 at 4:39 PM, Justus Ranvier justusranv...@riseup.net wrote: While the rest of the 'net is busy deprecating HTTP and all other unencrypted transport methods, why is it(*) even a debate? I think it's desirable (and you can go look in #bitcoin-dev logs for me talking about it

Re: [Bitcoin-development] Reconsidering github

2014-08-19 Thread Gregory Maxwell
On Tue, Aug 19, 2014 at 6:26 PM, Troy Benjegerdes ho...@hozed.org wrote: If a project cannot be organized enough to run its own hosting/web presense/ counterintelligence/security that starts with installing an OS and patching kernels, then it is really not wise for me to trust my financial

Re: [Bitcoin-development] Outbound connections rotation

2014-08-18 Thread Gregory Maxwell
On Mon, Aug 18, 2014 at 9:46 AM, Ivan Pustogarov ivan.pustoga...@uni.lu wrote: Hi there, I'd like to start a discussion on periodic rotation of outbound connections. E.g. every 2-10 minutes an outbound connections is dropped and replaced by a new one. Connection rotation would be fine for

[Bitcoin-development] Fwd: Outbound connections rotation

2014-08-18 Thread Gregory Maxwell
On Mon, Aug 18, 2014 at 10:30 AM, Pieter Wuille pieter.wui...@gmail.com wrote: Yes, I believe peer rotation is useful, but not for privacy - just for improving the network's internal knowledge. I haven't looked at the implementation yet, but how I imagined it would be every X minutes you

Re: [Bitcoin-development] Outbound connections rotation

2014-08-18 Thread Gregory Maxwell
On Mon, Aug 18, 2014 at 11:37 AM, Ivan Pustogarov ivan.pustoga...@uni.lu wrote: the same for a long time, an attacker which does not have any peers at all but just listens the Bitcoin network can link together differed BC addresses and learn the IP of the client. I don't understand what you're

Re: [Bitcoin-development] Outbound connections rotation

2014-08-18 Thread Gregory Maxwell
On Mon, Aug 18, 2014 at 1:33 PM, Ivan Pustogarov ivan.pustoga...@uni.lu wrote: The attack I'm trying to address is described here: https://www.cryptolux.org/index.php/Bitcoin It was discussed here: https://bitcointalk.org/index.php?topic=632124.0 It uses the following observation. Each NATed

Re: [Bitcoin-development] Outbound connections rotation

2014-08-18 Thread Gregory Maxwell
On Mon, Aug 18, 2014 at 2:02 PM, Ivan Pustogarov ivan.pustoga...@uni.lu wrote: For each neighbour, a Bitcoin peer keeps the history of addresses that it forwarded to the neighbour. If an address was already forwarded to a neighbour it is not retransmitted again. Okay, sorry, I thought you were

Re: [Bitcoin-development] Squashing redundant tx data in blocks on the wire

2014-07-31 Thread Gregory Maxwell
On Thu, Jul 31, 2014 at 1:47 PM, Kaz Wesley kezi...@gmail.com wrote: trip to request the missing tx; if we could somehow get the What's the Difference approach to effectively operate on full transactions instead I explain how to do this on the network block coding page. Given that you know

Re: [Bitcoin-development] Squashing redundant tx data in blocks on the wire

2014-07-31 Thread Gregory Maxwell
On Thu, Jul 31, 2014 at 2:41 PM, Kaz Wesley kezi...@gmail.com wrote: the need to have transmitted the transaction list [..] first 32 bits per transaction is at least double the communication overhead of the simple approach, and only offers a bound on the probability of needing a round trip.

Re: [Bitcoin-development] Squashing redundant tx data in blocks on the wire

2014-07-31 Thread Gregory Maxwell
On Thu, Jul 31, 2014 at 3:27 PM, Kaz Wesley kezi...@gmail.com wrote: the FEC still lets you fill in the missing transactions without knowing in advance all that will be missing. I don't see why we need to solve that problem, since the protocol already involves exchanging the information

Re: [Bitcoin-development] deterministic transaction expiration

2014-07-31 Thread Gregory Maxwell
On Thu, Jul 31, 2014 at 6:38 PM, Matt Whitlock b...@mattwhitlock.name wrote: It would make more sense to introduce a new script opcode that pushes the current block height onto the operand stack. Then you could implement arbitrary logic about which blocks the transaction can be valid in. This

Re: [Bitcoin-development] deterministic transaction expiration

2014-07-31 Thread Gregory Maxwell
On Thu, Jul 31, 2014 at 8:26 PM, Matt Whitlock b...@mattwhitlock.name wrote: I understand what you're saying, but I don't understand why it's a problem. Transactions shouldn't be considered final until a reasonable number of confirmations anyway, so the possibility that an accepted

Re: [Bitcoin-development] Abnormally Large Tor node accepting only Bitcoin traffic

2014-07-28 Thread Gregory Maxwell
On Mon, Jul 28, 2014 at 5:31 AM, Robert McKay rob...@mckay.com wrote: I don't think Sybil attack is the right term for this.. there is only one IP address.. one identity. The bitcoin protocol is more or less identityless. It's using up lots of network capacity, number of sockets is as pretty

Re: [Bitcoin-development] Abnormally Large Tor node accepting only Bitcoin traffic

2014-07-27 Thread Gregory Maxwell
On Sun, Jul 27, 2014 at 7:12 PM, Jeremy jlru...@mit.edu wrote: Hey, There is a potential network exploit going on. In the last three days, a node (unnamed) came online and is now processing the most traffic out of any tor node -- and it is mostly plaintext Bitcoin traffic.

Re: [Bitcoin-development] Abnormally Large Tor node accepting only Bitcoin traffic

2014-07-27 Thread Gregory Maxwell
On Sun, Jul 27, 2014 at 7:40 PM, Peter Todd p...@petertodd.org wrote: Anyway, just goes to show that we need to implement better incoming connection limiting. gmaxwell has a good scheme with interactive proof-of-memory - where's your latest writeup? Or its a complete snipe hunt, I'm unable to

Re: [Bitcoin-development] Abnormally Large Tor node accepting only Bitcoin traffic

2014-07-27 Thread Gregory Maxwell
On Sun, Jul 27, 2014 at 7:45 PM, Gregory Maxwell gmaxw...@gmail.com wrote: Or its a complete snipe hunt, I'm unable to find any nodes with it connected to them. Does anyone here have any? [unimportant update] Turns out that my IPv4 nodes already have iptables blocking of that subnet, presumably

Re: [Bitcoin-development] Abnormally Large Tor node accepting only Bitcoin traffic

2014-07-27 Thread Gregory Maxwell
On Sun, Jul 27, 2014 at 7:54 PM, m...@bitwatch.co m...@bitwatch.co wrote: These website list Tor nodes by bandwidth: http://torstatus.blutmagie.de/index.php https://torstatus.rueckgr.at/index.php?SR=BandwidthSO=Desc And the details reveal it's a port 8333 only exit node:

Re: [Bitcoin-development] Time

2014-07-24 Thread Gregory Maxwell
On Thu, Jul 24, 2014 at 7:35 PM, Aaron Voisine vois...@gmail.com wrote: The upcoming release of breadwallet uses the height of the blockchain to enforce timed pin code lockouts for preventing an attacker from quickly making multiple pin guesses. This prevents them changing the devices system

Re: [Bitcoin-development] Policy for DNS seeds

2014-07-21 Thread Gregory Maxwell
On Mon, Jul 21, 2014 at 12:24 PM, Peter Todd p...@petertodd.org wrote: Might be worthwhile to also write an Expectations for DNSSeed users outlining what security properties the seeds actually have, and what kind of attacks are possible. Agreed. I've seen some amount of use of dnsseeds which

Re: [Bitcoin-development] Squashing redundant tx data in blocks on the wire

2014-07-19 Thread Gregory Maxwell
On Fri, Jul 18, 2014 at 8:06 PM, Emin Gün Sirer el33th4...@gmail.com wrote: Most things I've seen working in this space are attempting to minimize the data transfered. At least for the miner-interested case the round complexity is much more important because a single RTT is enough to

  1   2   3   4   >