Re: [Bitcoin-development] Stealth Addresses

2014-01-15 Thread Gregory Maxwell
On Wed, Jan 15, 2014 at 4:05 PM, Jeremy Spilman jer...@taplink.co wrote: Might I propose reusable address. I like this too. -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are

[Bitcoin-development] Bait for reusable addresses

2014-01-15 Thread Gregory Maxwell
One challenge with reusable addresses is that while they result in a small constant overhead for full nodes in searching for their own transactions they create large overheads for SPV nodes. One way to address this is for the SPV nodes to hand their servers their blinding private key so that the

Re: [Bitcoin-development] unlinakble static address? spv-privacy (Re: Stealth Addresses)

2014-01-15 Thread Gregory Maxwell
On Wed, Jan 15, 2014 at 5:02 PM, Jeremy Spilman jer...@taplink.co wrote: Choosing how many bits to put in the prefix may be difficult, particularly if transaction load changes dramatically over time. 0 or 1 bits may be just fine for a single user running their own node, whereas a central

Re: [Bitcoin-development] Stealth Addresses

2014-01-13 Thread Gregory Maxwell
On Mon, Jan 13, 2014 at 11:59 AM, Alan Reiner etothe...@gmail.com wrote: Then when someone wants to pay you, you simply give them the multiplier and root key (they already have the root key, but should verify). [...] What advantages does stealth addresses have over this scheme? You could

Re: [Bitcoin-development] An idea for alternative payment scheme

2014-01-03 Thread Gregory Maxwell
On Fri, Jan 3, 2014 at 10:00 AM, Nadav Ivgi na...@shesek.info wrote: I had an idea for a payment scheme that uses key derivation, but instead of the payee deriving the addresses, the payer would do it. It would work like that: The payee publishes his master public key The payer generates a

Re: [Bitcoin-development] BIP: register with IANA for bitcoin/cryptocoin port numbers

2014-01-02 Thread Gregory Maxwell
On Thu, Jan 2, 2014 at 9:22 PM, Troy Benjegerdes ho...@hozed.org wrote: I believe this is self-explainatory: 1) Bitcoin usually runs on port 8333. Why? 2) Bitcoin does not show in up http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml .. why? 3)

Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?

2013-12-31 Thread Gregory Maxwell
On Tue, Dec 31, 2013 at 5:39 AM, Drak d...@zikula.org wrote: The NSA has the ability, right now to change every download of bitcoin-qt, on the fly and the only cure is encryption. Please cut it out with the snake oil pedaling. This is really over the top. You're invoking the NSA as the threat

Re: [Bitcoin-development] BIP proposal: Authenticated prefix trees

2013-12-20 Thread Gregory Maxwell
On Thu, Dec 19, 2013 at 5:47 PM, Mark Friedenbach m...@monetize.io wrote: Hello fellow bitcoin developers. Included below is the first draft of a BIP for a new Merkle-compressed data structure. The need for this data structure arose out of the misnamed Ultimate blockchain compression project,

Re: [Bitcoin-development] RFC: MERGE transaction/script/process for forked chains

2013-12-17 Thread Gregory Maxwell
On Tue, Dec 17, 2013 at 2:41 PM, Troy Benjegerdes ho...@hozed.org wrote: I want to get some feedback.. I've used distributed version control systems for a long time, and the most useful feature is to be able to merge two different forks. We already automatically merge forks that we become

Re: [Bitcoin-development] 0.8.6 release candidate 1

2013-12-09 Thread Gregory Maxwell
On Mon, Dec 9, 2013 at 7:19 AM, Drak d...@zikula.org wrote: Why would it be made available for download at sourceforge.net if it's not actually released? The files are available here: Because it takes time to put the files up, propagate to mirrors, check by multiple people that the downloads

Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?

2013-12-08 Thread Gregory Maxwell
On Sun, Dec 8, 2013 at 11:16 AM, Drak d...@zikula.org wrote: BGP redirection is a reality and can be exploited without much You're managing to argue against SSL. Because it actually provides basically protection against an attacker who can actively intercept traffic to the server. Against that

Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?

2013-12-08 Thread Gregory Maxwell
On Sun, Dec 8, 2013 at 12:40 PM, Drak d...@zikula.org wrote: Let me clarify. SSL renders BGP redirection useless because the browser holds the signatures of CA's it trusts: an attacker cannot spoof a certificate because it needs to be signed by a trusted CA: that's the point of SSL, it

Re: [Bitcoin-development] [PATCH, try2] bitcoind: whitelist nodes against banning

2013-11-22 Thread Gregory Maxwell
On Fri, Nov 22, 2013 at 12:49 PM, Jeff Garzik jgar...@bitpay.com wrote: Whitelist nodes against banning. Is there a reason not to have a parallel get rpc to get the current list? -- Shape the Mobile Experience: Free

Re: [Bitcoin-development] Revisiting the BIPS process, a proposal

2013-11-19 Thread Gregory Maxwell
On Tue, Nov 19, 2013 at 8:53 AM, Drak d...@zikula.org wrote: It's quite normal for standards bodies to allocate numbers when in draft status. If they don't pass, they don't pass - they are clearly labelled DRAFTs. +1 on having things in a github repository. Much better for collaboration, The

Re: [Bitcoin-development] Revisiting the BIPS process, a proposal

2013-11-19 Thread Gregory Maxwell
On Tue, Nov 19, 2013 at 9:45 AM, Wladimir laa...@gmail.com wrote: Talking about complete, BIP 40 and 41 don't even have an associated document: https://github.com/bitcoin/bips I agree that was over-eager number assigning. Maybe! The subject matter its assigned for is already _widely_

Re: [Bitcoin-development] we can all relax now

2013-11-08 Thread Gregory Maxwell
On Fri, Nov 8, 2013 at 11:49 AM, Andreas M. Antonopoulos andr...@rooteleven.com wrote: Nicholas Weaver is reporting that pools have already started delaying blocks, something that hints at Selfish Mining, since Nov. 3rd. https://medium.com/something-like-falling/d321a2ef9317 He dismisses

Re: [Bitcoin-development] Possible Solution To SM Attack

2013-11-05 Thread Gregory Maxwell
On Tue, Nov 5, 2013 at 2:15 PM, Drak d...@zikula.org wrote: If I understand the issue properly, this seems like a pretty elegant solution: if two blocks are broadcast within a certain period of eachother, chose the lower target. That's a provable fair way of randomly choosing the winning block

Re: [Bitcoin-development] Auto-generated miner backbone

2013-11-04 Thread Gregory Maxwell
On Mon, Nov 4, 2013 at 3:58 AM, Michael Gronager grona...@ceptacle.com wrote: The suggested change is actually very simple (minutes of coding) and elegant and addresses precisely the identified problem. It is actually a mental shortcut in the assumption of how probability works when mining a

Re: [Bitcoin-development] Auto-generated miner backbone

2013-11-04 Thread Gregory Maxwell
On Mon, Nov 4, 2013 at 8:39 PM, Peter Todd p...@petertodd.org wrote: I suggested the mechanism myself for slightly different reasons, and if you know me, you'd know I'm the first to jump on anyone pushing centralization. Likewise, I did too and am also not very tolerant with trusted or

Re: [Bitcoin-development] Feedback requested: reject p2p message

2013-10-30 Thread Gregory Maxwell
On Sun, Oct 27, 2013 at 7:32 AM, Mike Hearn m...@plan99.net wrote: I'm really looking forward to this. Currently bitcoinj gets a small but steady stream of bug reports of the form my transaction did not propagate. It's flaky because the library picks one peer to send the transaction to, and

Re: [Bitcoin-development] Feedback requested: reject p2p message

2013-10-28 Thread Gregory Maxwell
On Mon, Oct 28, 2013 at 2:26 AM, Andreas Schildbach andr...@schildbach.de wrote: HTTP also defines success codes (2xx). Are we also talking about ACK messages now, rather than just REJECT messages? I do not believe we should do that: It would be a non-trivial increase the protocol bandwidth

Re: [Bitcoin-development] BIP 38

2013-10-25 Thread Gregory Maxwell
On Fri, Oct 25, 2013 at 11:50 AM, Mike Caldwell mcaldw...@swipeclock.com wrote: I have noticed that there was a recent change to BIP 0038 (Password-Protected Private Key) on the Wiki, which is a proposal I wrote in late 2012. Gregory, it looks to me as though you have made this change, and

[Bitcoin-development] Payment protocol for onion URLs.

2013-10-25 Thread Gregory Maxwell
One limitation of the payment protocol as speced is that there is no way for a hidden service site to make use of its full authentication capability because they are unable to get SSL certificates issued to them. A tor hidden service (onion site) is controlled by an RSA key. It would be trivial

Re: [Bitcoin-development] Payment protocol for onion URLs.

2013-10-25 Thread Gregory Maxwell
On Fri, Oct 25, 2013 at 8:41 PM, Luke-Jr l...@dashjr.org wrote: Is there any point to additional encryption over tor (which afaik is already encrypted end-to-end)? Is there a safe way to make this work through tor entry nodes/gateways? The x.509 in the payment protocol itself is for

Re: [Bitcoin-development] Revisiting the BIPS process, a proposal

2013-10-22 Thread Gregory Maxwell
On Mon, Oct 21, 2013 at 11:59 PM, Jean-Paul Kogelman jeanpaulkogel...@me.com wrote: Have you seen: https://en.bitcoin.it/wiki/Protocol_specification ? Take care, the information in the wiki is woefully incomplete. --

Re: [Bitcoin-development] Revisiting the BIPS process, a proposal

2013-10-22 Thread Gregory Maxwell
On Tue, Oct 22, 2013 at 12:34 AM, Martin Sustrik sust...@250bpm.com wrote: There's also Security Considerations part in every RFC that is pretty relevant for Bitcoin. Which would say something interesting like If the bitcoin network implements inconsistent behavior in the consensus critical

Re: [Bitcoin-development] A critique of bitcoin open source community

2013-10-19 Thread Gregory Maxwell
On Sat, Oct 19, 2013 at 3:29 PM, Luke-Jr l...@dashjr.org wrote: See BIP 1 for the process.. proposals go to this mailing list first. FWIW, he did post to the mailing list and he got an underwhelming response:

Re: [Bitcoin-development] Faster databases than LevelDB

2013-09-17 Thread Gregory Maxwell
On Tue, Sep 17, 2013 at 4:00 AM, Mike Hearn m...@plan99.net wrote: LevelDB is fast - very fast if you give it enough CPU time and disk seeks. But it's not the last word in performance. I'd looked at the hyperleveldb, but their performance graphs made it seem like it would be slower for the

Re: [Bitcoin-development] BIP0039 Mnemonic code for generating deterministic keys

2013-09-10 Thread Gregory Maxwell
On Tue, Sep 10, 2013 at 2:03 PM, Matthew Mitchell matthewmitch...@godofgod.co.uk wrote: Well let's hope something like murder black people, stupid asian person or whip african slave doesn't come up. :-) Maybe it would have been better without the aggressive words? Ouch. This sounds like

[Bitcoin-development] Some current turbulence on the Bitcoin network: DB corruption errors on start from Bitcoin-qt / Bitcoind

2013-09-09 Thread Gregory Maxwell
Please return your seats and fasten your seat-belts. All Bitcoin-qt / Bitcoind nodes will currently fail to come back up after a restart, reporting : *** coin database inconsistencies found and Do you want to rebuild the block database now? Reindexing _will not_ correct the problem. In

Re: [Bitcoin-development] Some current turbulence on the Bitcoin network: DB corruption errors on start from Bitcoin-qt / Bitcoind

2013-09-09 Thread Gregory Maxwell
On Mon, Sep 9, 2013 at 1:53 AM, Gregory Maxwell gmaxw...@gmail.com wrote: More information will be forthcoming once a patch is available. I now have a patch up for review. https://github.com/bitcoin/bitcoin/pull/2982 (You should wait until other developers have had a chance to review before

Re: [Bitcoin-development] Way to tell that transaction was issued by a specific person/company

2013-08-23 Thread Gregory Maxwell
On Thu, Aug 22, 2013 at 11:26 PM, Maciej Trebacz mac...@bitalo.com wrote: So if you have multiple addresses you can't sign them with a single private key and include that signature in the transaction so other party can verify it against your public key. This could become very handy though - a

Re: [Bitcoin-development] BIP 32.5

2013-08-20 Thread Gregory Maxwell
On Thu, Aug 15, 2013 at 7:26 PM, Gregory Maxwell gmaxw...@gmail.com wrote: I am wondering if we shouldn't have a BIP32 addendum which makes the following signing related recommendations: Looks like we're in the midst of another DSA duplicated K disaster. (Now, blockchain.info mywallet) I

[Bitcoin-development] CoinWitness: Really Really ultimate blockchain compression

2013-08-19 Thread Gregory Maxwell
I've posted a somewhat blue-skies idea on troll^wBitcointalk that some here might find interesting: https://bitcointalk.org/index.php?topic=277389.0 -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's

Re: [Bitcoin-development] Proposal: remove getwork RPC from bitcoind

2013-08-19 Thread Gregory Maxwell
On Mon, Aug 19, 2013 at 1:09 PM, Frank F frank...@gmail.com wrote: If there are technical problems with getwork, maybe they should be addressed and fixed instead of outright abandoned. They have been, resulting in a replacement called getblocktemplate which (presumably) almost everyone talking

Re: [Bitcoin-development] Gavin's post-0.9 TODO list...

2013-08-16 Thread Gregory Maxwell
On Fri, Aug 16, 2013 at 6:41 AM, Warren Togami Jr. wtog...@gmail.com wrote: If you disallow the same IP and/or subnet from establishing too many TCP connections with your node, [...] has almost zero drawbacks, There are whole countries who access the internet from single IP addresses. There

[Bitcoin-development] BIP 32.5

2013-08-15 Thread Gregory Maxwell
I am wondering if we shouldn't have a BIP32 addendum which makes the following signing related recommendations: (1) Recommend a specific deterministic DSA derandomization procedure (a deterministic way to generate the DSA nonce), presumably one based on HMAC-SHA512 (since BIP32 uses that

Re: [Bitcoin-development] Preparing for the Cryptopocalypse

2013-08-05 Thread Gregory Maxwell
On Sun, Aug 4, 2013 at 8:30 PM, Peter Vessenes pe...@coinlab.com wrote: I studied with Jeffrey Hoffstein at Brown, one of the creators of NTRU. He told me recently NTRU, which is lattice based, is one of the few (only?) NIST-recommended QC-resistant algorithms. Lamport signatures (and merkle

Re: [Bitcoin-development] BitMail - p2p Email 0.1. beta

2013-07-30 Thread Gregory Maxwell
On Mon, Jul 29, 2013 at 10:01 PM, Randolph D. rdohm...@gmail.com wrote: Secure P2P Email from Friend to Friend without relying on a central server. Key- / Repleo-Exchange. Full decentral Email-Network using the Echo Protocol. Store Email for Offline-Friends in the P2P Network. Chat and

Re: [Bitcoin-development] Linux packaging letter

2013-07-23 Thread Gregory Maxwell
On Tue, Jul 23, 2013 at 1:01 PM, Mike Hearn m...@plan99.net wrote: Hi, Some of us have put together an open letter to the Linux packaging community, outlining why Bitcoin is different to other programs and asking them to not patch or modify the upstream sources. Please consider signing it

Re: [Bitcoin-development] Linux packaging letter

2013-07-23 Thread Gregory Maxwell
On Tue, Jul 23, 2013 at 4:23 PM, Greg Troxel g...@work.lexort.com wrote: Is the repeatable build infrastructure portable (to any reasonable mostly-POSIX-compliant system, with gcc or clang)? I have the vague It's portable to anything that can run the relevant VMs. Uh provided you don't mind

Re: [Bitcoin-development] Linux packaging letter

2013-07-23 Thread Gregory Maxwell
On Tue, Jul 23, 2013 at 7:35 PM, zooko zo...@zooko.com wrote: I think some package maintainers might perceive this version of the letter as high-handed -- telling someone else how to do their job -- and they might not notice the actual facts included in the letter explaining why Bitcoin

Re: [Bitcoin-development] Endianness (was: Linux packaging letter)

2013-07-23 Thread Gregory Maxwell
On Tue, Jul 23, 2013 at 8:54 PM, Wendell w...@grabhive.com wrote: Forking for curiosity's sake: Is there a substantial barrier to endian independence in the Bitcoin codebase? Not really. The software was originally written to write out memory order to and from the wire, which is part of why the

Re: [Bitcoin-development] Endianness (was: Linux packaging letter)

2013-07-23 Thread Gregory Maxwell
On Tue, Jul 23, 2013 at 9:07 PM, Gregory Maxwell gmaxw...@gmail.com wrote: order to and from the wire, which is part of why the protocol is LE everywhere, *before someone corrects me, it's not LE everywhere (I meant manywhere :P)— there is just enough BE to keep you on your toes. :P

Re: [Bitcoin-development] Review for slides for defeating trojans talk

2013-07-12 Thread Gregory Maxwell
On Fri, Jul 12, 2013 at 7:28 AM, Rob Meijer rmei...@xs4all.nl wrote: Completed the first draft of my slides+speaker-notes for my upcoming Defeating Trojans talk at the OHM2013. BitCoin is one of the main examples I use in this talk to emphasize the need for programs like BitCoin to have their

Re: [Bitcoin-development] Double-Spending Fast Payments in Bitcoin due to Client versions 0.8.1

2013-06-27 Thread Gregory Maxwell
On Thu, Jun 27, 2013 at 3:23 AM, Arthur Gervais arthur.gerv...@inf.ethz.ch wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear Bitcoin developers, We would like to report a vulnerability which might lead, under some assumptions, to a double-spending attack in a fast payment scenario.

Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org

2013-06-27 Thread Gregory Maxwell
On Thu, Jun 27, 2013 at 10:10 AM, Jim jim...@fastmail.co.uk wrote: Let me know if you think this is a good idea (or not!) and if you have any questions. Being able to promote a fast SPV desktop wallet would be great! I went through an cycle of testing on multibit after I saw some complaints

Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org

2013-06-27 Thread Gregory Maxwell
On Thu, Jun 27, 2013 at 11:04 AM, Luke-Jr l...@dashjr.org wrote: On Thursday, June 27, 2013 5:30:21 PM Jeff Garzik wrote: * Very real possibility of an overall net reduction of full nodes on P2P network Even a reduction of *nodes at all*, as I've never seen a listening bitcoinj or MultiBit

Re: [Bitcoin-development] Double Spend Notification

2013-05-20 Thread Gregory Maxwell
On Mon, May 20, 2013 at 6:56 PM, Pieter Wuille pieter.wui...@gmail.com wrote: On Tue, May 21, 2013 at 3:24 AM, Robert Backhaus rob...@robbak.com wrote: So the decision has been made to make 0-conf double spends trivial, so no one will ever trust 0-confs. If a later transaction appears with a

Re: [Bitcoin-development] blind symmetric commitment for stronger byzantine voting resilience (Re: bitcoin taint unilateral revocability)

2013-05-15 Thread Gregory Maxwell
On Wed, May 15, 2013 at 6:24 PM, Gavin gavinandre...@gmail.com wrote: Busy with pre-conference stuff, not following details of this conversation... ... but it sounds a lot like the guy fawkes protocol Zooko was thinking about a year or so ago. Sort of, but in a guy fawkes signature you use

Re: [Bitcoin-development] blind symmetric commitment for stronger byzantine voting resilience (Re: bitcoin taint unilateral revocability)

2013-05-15 Thread Gregory Maxwell
On Wed, May 15, 2013 at 7:22 PM, Mike Hearn m...@plan99.net wrote: Conceptually it sounds a lot like ZeroCoin (not in implementation)? Zerocoin conceals the connection from everyone forever, assuming the underlying trapdoor problem is computational infeasible, but at great cost. Adamcoin,

Re: [Bitcoin-development] Discovery/addr packets (was: Service bits for pruned nodes)

2013-05-06 Thread Gregory Maxwell
On Mon, May 6, 2013 at 10:19 AM, Peter Todd p...@petertodd.org wrote: running hash of all messages sent on a connection so far. Add a new protocol message that asks the node to sign the current accumulated hash. We already depend on OpenSSL, why not just use standard SSL? SSL doesn't actually

Re: [Bitcoin-development] Discovery/addr packets (was: Service bits for pruned nodes)

2013-05-06 Thread Gregory Maxwell
On Mon, May 6, 2013 at 10:53 AM, Peter Todd p...@petertodd.org wrote: We don't have non-repudiation now, why make that a requirement for the first version? Adding non-repudiation is something that has to happen at the Bitcoin protocol level,(1) so it's orthogonal to using SSL to make sure

Re: [Bitcoin-development] limits of network hacking/netsplits (was: Discovery/addr packets)

2013-05-06 Thread Gregory Maxwell
On Mon, May 6, 2013 at 3:51 PM, Adam Back a...@cypherspace.org wrote: Maybe I could hack a pool to co-opt it into my netsplit and do the work for me, or segment enough of the network to have some miners in it, and they do the work. Or you can just let it mine honestly and take the Bitcoins.

Re: [Bitcoin-development] Service bits for pruned nodes

2013-04-28 Thread Gregory Maxwell
On Sun, Apr 28, 2013 at 9:29 AM, Mike Hearn m...@plan99.net wrote: I'd imagined that nodes would be able to pick their own ranges to keep rather than have fixed chosen intervals. Everything or two weeks is rather X most recent is special for two reasons: It meshes well with actual demand, and

Re: [Bitcoin-development] Service bits for pruned nodes

2013-04-28 Thread Gregory Maxwell
On Sun, Apr 28, 2013 at 7:57 PM, John Dillon john.dillon...@googlemail.com wrote: Have we considered just leaving that problem to a different protocol such as BitTorrent? Offering up a few GB of storage capacity is a nice idea but it means we would soon have to add structure to the network to

Re: [Bitcoin-development] Who is creating non-DER signatures?

2013-04-13 Thread Gregory Maxwell
On Sat, Apr 13, 2013 at 2:43 PM, Pieter Wuille pieter.wui...@gmail.com wrote: Actual network rules will need to come later. However, even just not accepting them into memory pools will it make very hard (if not impossible) for the buggy clients that create transactions to get any confirmations.

Re: [Bitcoin-development] To prevent arbitrary data storage in txouts — The Ultimate Solution

2013-04-10 Thread Gregory Maxwell
On Tue, Apr 9, 2013 at 11:53 PM, Peter Todd p...@petertodd.org wrote: Of course, either way you have the odd side-effect that it's now difficult to pay further funds to a random txout seen on the blockchain... strange, although possibly not a bad thing. Oh wow, thats actually a quite good

Re: [Bitcoin-development] On-going data spam

2013-04-09 Thread Gregory Maxwell
On Tue, Apr 9, 2013 at 7:39 AM, Caleb James DeLisle calebdeli...@lavabit.com wrote: what anti-virus software might do when certain streams of bytes are sent across the tcp socket or persisted to disk. Perhaps worth contacting an AV company and asking what is the smallest data they have a

[Bitcoin-development] To prevent arbitrary data storage in txouts — The Ultimate Solution

2013-04-09 Thread Gregory Maxwell
(1) Define a new address type, P2SH^2 like P2SH but is instead H(H(ScriptPubKey)) instead of H(ScriptPubKey). A P2SH^2 address it is a hash of a P2SH address. (2) Make a relay rule so that to relay a P2SH^2 you must include along the inner P2SH address. All nodes can trivially verify it by

Re: [Bitcoin-development] To prevent arbitrary data storage in txouts — The Ultimate Solution

2013-04-09 Thread Gregory Maxwell
On Tue, Apr 9, 2013 at 8:52 PM, Robert Backhaus rob...@robbak.com wrote: That sounds workable. I take it that the P2SH address is not stored? I like it that this denies the possibility of storing data in the block chain, but does not block interesting uses like creating date stamps - You can

Re: [Bitcoin-development] A mining pool at 46%

2013-04-05 Thread Gregory Maxwell
On Fri, Apr 5, 2013 at 2:30 AM, Melvin Carvalho melvincarva...@gmail.com wrote: There was some chat on IRC about a mining pool reaching 46% http://blockchain.info/pools The estimates on there may be a bit lossy. What's the risk of a 51% attack. The whole fixation on 51 as a magic number is a

Re: [Bitcoin-development] A mining pool at 46%

2013-04-05 Thread Gregory Maxwell
On Fri, Apr 5, 2013 at 2:48 AM, Mike Hearn m...@plan99.net wrote: but I think p2pool still has a lot of problems dealing with FPGA/ASIC hardware and it hasn't been growing for a long time. As an aside and a clarification— P2pool works great with FPGAs, and one of the largest FPGA farms I've

Re: [Bitcoin-development] Integration testing for BitCoin

2013-04-05 Thread Gregory Maxwell
On Fri, Apr 5, 2013 at 10:24 AM, Adam Ritter arit...@gmail.com wrote: Hey guys, I just bought some BitCoins after being lazy to do it for the last few years, but also looked at the client code and the messages that are going on this mailing list. I saw that there are quite some unit tests,

Re: [Bitcoin-development] Key retirement and key compromise

2013-03-25 Thread Gregory Maxwell
On Mon, Mar 25, 2013 at 1:49 PM, Roy Badami r...@gnomon.org.uk wrote: I'm not envisaging something as drastic as changing the rules to make transactions to revoked addresses invalid - just an overlay protocol. Although to be useful such a protocol would have to be pretty much universally

Re: [Bitcoin-development] Upcoming network event: block v2 lock-in

2013-03-23 Thread Gregory Maxwell
On Sat, Mar 23, 2013 at 10:47 AM, Jeff Garzik jgar...@exmulti.com wrote: On Sat, Mar 23, 2013 at 1:43 PM, Luke-Jr l...@dashjr.org wrote: Not for producing coinbases (where BIP 34 is implemented). Sure, that is largely the pool server layer. But it is misleading to imply that bitcoind is

Re: [Bitcoin-development] A bitcoin UDP P2P protocol extension

2013-03-23 Thread Gregory Maxwell
On Sat, Mar 23, 2013 at 5:57 PM, Jay F j...@outlook.com wrote: My first concern was that I and about everyone else only has TCP/UDP port forwarding, You tunnel it! http://tools.ietf.org/html/draft-tuexen-tsvwg-sctp-dtls-encaps-00 You could do worse to have a data stream that looks like WEBRTC

Re: [Bitcoin-development] 0.8.1 ideas

2013-03-15 Thread Gregory Maxwell
On Fri, Mar 15, 2013 at 10:06 AM, Benjamin Lindner b...@benlabs.net wrote: This. Software behavior which is not described by the source code should not be considered an integral part of the rule set. Any influence of external libraries on the consensus mechanism is unacceptable. No one

Re: [Bitcoin-development] 0.8.1 ideas

2013-03-13 Thread Gregory Maxwell
On Wed, Mar 13, 2013 at 8:05 AM, Peter Todd p...@petertodd.org wrote: If we're going to consider doing this, at minimum we need to also I beg people to not derail discussion about fixing things with discussion of other controversial changes. Luke-jr, any chance in getting you to revise your

Re: [Bitcoin-development] 0.8.1 ideas

2013-03-13 Thread Gregory Maxwell
On Wed, Mar 13, 2013 at 1:10 PM, Matthew Mitchell matthewmitch...@thelibertyportal.com wrote: Why would it be a difficulty in getting people to update away from 0.7 and earlier? How long would that roughly take? If people are hesitant to update, imagine if a more serious vulnerability is

[Bitcoin-development] On fork awareness Was: 0.8.1 ideas

2013-03-13 Thread Gregory Maxwell
On Wed, Mar 13, 2013 at 2:06 PM, Andy Parkins andypark...@gmail.com wrote: On Wednesday 13 Mar 2013 12:56:29 Luke-Jr wrote: Here's a simple proposal to start discussion from... It seems to me that the biggest failure was not the development of two chains, but the assurance to users (by the

Re: [Bitcoin-development] 0.8.1 ideas

2013-03-13 Thread Gregory Maxwell
On Wed, Mar 13, 2013 at 2:22 PM, Roy Badami r...@gnomon.org.uk wrote: The idea of the client detecting/warning about not-trivial forking seems worthwhile too, though, assuming it doesn't already (AIUI it doesn't). It does warn— if its heard the fork and its on the lower difficulty side.

Re: [Bitcoin-development] Warning: many 0.7 nodes break on large number of tx/block; fork risk

2013-03-12 Thread Gregory Maxwell
On Tue, Mar 12, 2013 at 2:10 AM, Mike Hearn m...@plan99.net wrote: BDB ran out of locks. However, only on some 0.7 nodes. Others, perhaps nodes using different flags, managed it. We have processed 1mb sized blocks on the testnet. Therefore it isn't presently clear why that particular block

Re: [Bitcoin-development] Changing the fee on already sent transactions

2013-03-12 Thread Gregory Maxwell
On Tue, Mar 12, 2013 at 2:47 AM, Peter Todd p...@petertodd.org wrote: Followed by the actual replacement logic. We could change this logic to instead evaluate if the candidate replacement does not remove or decrease the value of any existing outputs. Adding outputs is ok. Changing the set of

Re: [Bitcoin-development] Some PR preparation

2013-03-12 Thread Gregory Maxwell
On Tue, Mar 12, 2013 at 9:55 AM, Alan Reiner etothe...@gmail.com wrote: I don't want to misrepresent what happened, but how much of that was really a risk? The block was rejected, but the transactions were not. Some but not much. If someone flooded a bunch of duplicate concurrently announcing

Re: [Bitcoin-development] Some PR preparation

2013-03-12 Thread Gregory Maxwell
On Tue, Mar 12, 2013 at 11:09 AM, Gregory Maxwell gmaxw...@gmail.com wrote: On Tue, Mar 12, 2013 at 10:35 AM, Peter Vessenes pe...@coinlab.com wrote: Can some enterprising soul determine if there were any double-spend attempts? I'm assuming no, and if that's the case, we should talk about

Re: [Bitcoin-development] Blocking uneconomical UTXO creation

2013-03-11 Thread Gregory Maxwell
On Mon, Mar 11, 2013 at 1:36 PM, Michael Gronager grona...@ceptacle.com wrote: The point with UTXO is in the long run to be able to switch from a p2p network where everyone stores, validates and verifies everything to a DHT where the load of storing, validating and verifying can be shared. I

Re: [Bitcoin-development] Secure download

2013-03-03 Thread Gregory Maxwell
On Sun, Mar 3, 2013 at 10:54 AM, Roy Badami r...@gnomon.org.uk wrote: Would be nice to have a secure page at bitcoin.org, though, rathar than having to go to github - certs from somewhere like Namecheap should cost you next to nothing. For those of us too lazy (not paranoid enough) to bother

Re: [Bitcoin-development] Incorporating block validation rule modifications into the block chain

2013-02-13 Thread Gregory Maxwell
On Wed, Feb 13, 2013 at 6:58 AM, Raph Frank raph...@gmail.com wrote: Bitcoin is not a democracy— it quite intentionally uses the consensus mechanism _only_ the one thing that nodes can not autonomously and interdependently validate (the ordering of transactions). So, how is max block size to

Re: [Bitcoin-development] Incorporating block validation rule modifications into the block chain

2013-02-13 Thread Gregory Maxwell
On Wed, Feb 13, 2013 at 3:10 PM, Stephen Pair step...@bitpay.com wrote: If you've already validated the majority of transactions in a block, isn't validating the block not all that compute intensive? Thus, it's really not blocks that should be used to impose any sort of scarcity, but rather

Re: [Bitcoin-development] Incorporating block validation rule modifications into the block chain

2013-02-13 Thread Gregory Maxwell
On Wed, Feb 13, 2013 at 7:42 AM, Gregory Maxwell gmaxw...@gmail.com wrote: I hope that should it become necessary to do so that correct path will be obvious to everyone, otherwise there is a grave risk of undermining the justification for the confidence in the immutability of any of the rules

Re: [Bitcoin-development] Incorporating block validation rule modifications into the block chain

2013-02-13 Thread Gregory Maxwell
On Wed, Feb 13, 2013 at 6:44 PM, Stephen Pair step...@bitpay.com wrote: One of the beauties of bitcoin is that the miners have a very strong incentive to distribute as widely and as quickly as possible the blocks they find...they also have a very strong incentive to hear about the blocks that

Re: [Bitcoin-development] Incorporating block validation rule modifications into the block chain

2013-02-12 Thread Gregory Maxwell
On Tue, Feb 12, 2013 at 5:49 AM, Raph Frank raph...@gmail.com wrote: Has this been considered? If made sufficiently general, older clients could support any extension of the rules. Various hard parameters within the protocol are defined in main.h of the official client. In BIP-34, there

Re: [Bitcoin-development] Blockchain as root CA for payment protocol

2013-02-11 Thread Gregory Maxwell
On Mon, Feb 11, 2013 at 11:12 AM, Timo Hanke timo.ha...@web.de wrote: It's not about technical differences, but about the different use or purpose, which can result in different security demands. I argue that DNS has a lower demand in this respect than payment ids have. So DNS data can be in a

Re: [Bitcoin-development] Draft BIP for Bloom filtering

2013-02-06 Thread Gregory Maxwell
On Wed, Feb 6, 2013 at 8:33 AM, Mike Hearn m...@plan99.net wrote: Can somebody please unlock the BIP wiki page? I don't know why it was locked but it's stale. I asked for permissions to unlock it but haven't heard back— will prod.

Re: [Bitcoin-development] Roadmap to getting users onto SPV clients

2012-12-04 Thread Gregory Maxwell
On Tue, Dec 4, 2012 at 12:46 PM, Mike Hearn m...@plan99.net wrote: The alternative, I guess, is to make Bitcoin-Qt have an SPV mode. I'm not convinced this is the best use of time, but if somebody steps up to do it, that could also work. I strongly believe that if community leads with client

Re: [Bitcoin-development] Roadmap to getting users onto SPV clients

2012-12-04 Thread Gregory Maxwell
On Tue, Dec 4, 2012 at 1:57 PM, Mark Friedenbach m...@monetize.io wrote: Alan's :( UTxO meta-chain proposal becomes vastly easier to do now that ultraprune is merged. No, not really. Somewhat easier due to some structural changes, but it still needs to invent and get consensus on a

Re: [Bitcoin-development] Roadmap to getting users onto SPV clients

2012-12-04 Thread Gregory Maxwell
On Tue, Dec 4, 2012 at 3:58 PM, Mike Hearn m...@plan99.net wrote: It sounds to me that you're insisting that you're asking people who oppose degrading our recommendations to commit to a costly rushed development timeline. I think this is a false choice. Hardly. I don't have any particular

Re: [Bitcoin-development] Roadmap to getting users onto SPV clients

2012-12-04 Thread Gregory Maxwell
On Tue, Dec 4, 2012 at 5:44 PM, Alan Reiner etothe...@gmail.com wrote: Greg's point looks like it's veering towards we don't want to grow the network unless we're going to get more full nodes out of it. No… There is no fundamental completion between taking what actions we can to maximize the

Re: [Bitcoin-development] Roadmap to getting users onto SPV clients

2012-12-04 Thread Gregory Maxwell
On Tue, Dec 4, 2012 at 9:08 PM, Alan Reiner etothe...@gmail.com wrote: Our divergence is on two points (personal opinions): (1) I don't think there is any real risk to the centralization of the network by promoting a SPV (purely-consuming) node to brand-new users. In my opinion (but I'm not

Re: [Bitcoin-development] String-based Hierarchical Deterministic Keys - Alternative to BIP 32

2012-12-04 Thread Gregory Maxwell
On Tue, Dec 4, 2012 at 10:06 PM, Mike Koss m...@coinlab.com wrote: I've implemented an alternative to the BIP 32 proposal. I wanted a system based on a hierarchical string representation (rather than hierarchy of integers as BIP 32 proposes). For example I name keys like this:

[Bitcoin-development] String-based Hierarchical Deterministic Keys - Alternative to BIP 32

2012-12-04 Thread Gregory Maxwell
On Tue, Dec 4, 2012 at 10:36 PM, Watson Ladd w...@uchicago.edu wrote: being able to spend a coin sent to an address generated by this scheme implies being able to spend any coin generated by this scheme. If you have the the full extended secret there then you can spend along the chain— but

Re: [Bitcoin-development] Chain dust mitigation: Demurrage based Chain Vacuuming

2012-12-03 Thread Gregory Maxwell
On Mon, Dec 3, 2012 at 7:24 AM, Michael Gronager grona...@ceptacle.com wrote: Bitcoin aka the blockchain is defined by the majority of the miners. This is what people have signed up to imo. A scheme that a) is of benefit for us all and b) is also of economical benefit for the miners, will

Re: [Bitcoin-development] Chain dust mitigation: Demurrage based Chain Vacuuming

2012-12-03 Thread Gregory Maxwell
On Mon, Dec 3, 2012 at 10:00 AM, Mike Hearn m...@plan99.net wrote: The main source for these 1 Satoshi payouts is Sahtoshi Dice. Because people are making 1 satoshi bets, or is this part of their messaging system? It's part of their messaging system. Every losing play results in a new 1e-8

Re: [Bitcoin-development] Chain dust mitigation: Demurrage based Chain Vacuuming

2012-12-03 Thread Gregory Maxwell
On Mon, Dec 3, 2012 at 2:50 PM, Andreas Petersson andr...@petersson.at wrote: These discussed features are all useful but quite contradicting. I imagine that a user will be able to switch between different coin selection policies minimize fees,max privacy,defragmentation,i don't care and even

Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-12-03 Thread Gregory Maxwell
On Thu, Nov 29, 2012 at 12:31 PM, Mike Hearn m...@plan99.net wrote: 4) A longer term reason - in time, people may choose to not broadcast transactions at all in some cases. I think how network speed will be funded post-inflation is still an open question. Assuming the simplest arrangement

Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-11-26 Thread Gregory Maxwell
On Mon, Nov 26, 2012 at 6:19 PM, Luke-Jr l...@dashjr.org wrote: On Monday, November 26, 2012 11:16:03 PM Mike Hearn wrote: They could be included as well of course, but from a seller perspective the most important thing is consistency. You have to be able to predict what CAs the user has,

Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-11-26 Thread Gregory Maxwell
On Mon, Nov 26, 2012 at 9:16 PM, Walter Stanish wal...@stani.sh wrote: X-ISO4217-A3 I see that draft-stanish-x-iso4217-a3 is not standards track, is there a reason for this? It also doesn't appear to address ~any of the the targeted items here. Is there another draft I should be looking for

Re: [Bitcoin-development] Electrum security model concerns

2012-11-15 Thread Gregory Maxwell
On Sat, Oct 6, 2012 at 12:37 PM, Gregory Maxwell gmaxw...@gmail.com wrote: I'm concerned about how the particular security model of electrum is being described; or rather— not being described. Just to close the loop on this: I finally got in touch with Thomas on IRC and walked over the security

Re: [Bitcoin-development] Draft BIP for Bloom filtering

2012-10-26 Thread Gregory Maxwell
On Fri, Oct 26, 2012 at 10:01 AM, Mike Hearn m...@plan99.net wrote: If you just want to waste bandwidth of nodes you can connect to nodes and repeatedly download blocks, or fill the network with fake nodes that spam random generated transactions to whoever connects. I don't see how to avoid

<    1   2   3   4   >