Re: [Bitcoin-development] Project status

2011-08-29 Thread Luke-Jr
On Monday, August 29, 2011 4:10:01 PM Gavin Andresen wrote: Other things on the 0.4 TODO list: Can we get some form of the signmessage method in? -- Special Offer -- Download ArcSight Logger for FREE! Finally, a

[Bitcoin-development] Last try: Fixes for 0.4

2011-09-03 Thread Luke-Jr
to merge: - base58_liberal_parsing Again, these can all be merged with: # git fetch git://gitorious.org/~Luke-Jr/bitcoin/luke-jr-bitcoin.git \ # branch name git merge FETCH_HEAD -- Special Offer -- Download ArcSight

Re: [Bitcoin-development] 0.4rc1 known bugs

2011-09-06 Thread Luke-Jr
Got a fix for the encrypted-wallet mining issue: - unique_coinbase It depends on (and merges) the getwork_dedupe fix already common on pools and other miners who pay attention to the latest mining fixes. To merge: git fetch git://gitorious.org/~Luke-Jr/bitcoin/luke-jr-bitcoin.git

Re: [Bitcoin-development] Alert System

2011-09-08 Thread Luke-Jr
On Thursday, September 08, 2011 1:33:15 PM John Smith wrote: Be careful though, if you relay everything, it suddenly *does* have DDoS potential... Maybe require a proof-of-work then? -- Doing More with Less: The Next

[Bitcoin-development] 0.3.23+patches bug: JSON-RPC leaves sockets around when not connected

2011-09-09 Thread Luke-Jr
On Eligius, I have two bitcoinds running on the same system: - a hub node, which is dedicated to relaying network activity between the hundreds of nodes Eligius peers with - a work node, which is dedicated to managing mining, and only ever connects to the hub node Lately, the hub node has

Re: [Bitcoin-development] Project status

2011-09-13 Thread Luke-Jr
On Tuesday, September 13, 2011 10:43:27 AM Gavin Andresen wrote: 3) I'd really like to come to consensus on one or more 'multi-signature' standard transactions to enable much better wallet backup and security. More important in this area, IMO, is support for deterministic keychains in

Re: [Bitcoin-development] Difficulty adjustment / time issues

2011-09-13 Thread Luke-Jr
On Tuesday, September 13, 2011 11:06:37 AM Gavin Andresen wrote: Fixing (2) is easier; incorporating a ntp library and/or simply removing the bitcoin mining code from the client but requiring pools and miners to have accurate-to-within-a-minute system clocks (or their blocks will be

Re: [Bitcoin-development] Project status

2011-09-13 Thread Luke-Jr
On Tuesday, September 13, 2011 12:48:58 PM Douglas Huff wrote: On Sep 13, 2011 11:40 AM, Luke-Jr l...@dashjr.org wrote: Once created, they must submit the transaction to a staff member with the proper authority to bring it to the offline transaction-signing wallet (on a USB key), where

[Bitcoin-development] 0.4.x stable branch

2011-09-18 Thread Luke-Jr
Gavin, Jeff, et al: A group of developers would be interested in maintaining 0.4 into the future as a stable branch (ie, bugfixes only). Would you be willing to plan on making the next mainline version after 0.4, being called 0.5, so we can release 0.4.1, 0.4.2, etc? If we prepare the git

Re: [Bitcoin-development] Newly introduced DoS

2011-09-27 Thread Luke-Jr
What about this one? @@ -1276,13 +1278,13 @@ bool CBlock::AcceptBlock() // Get prev block index mapuint256, CBlockIndex*::iterator mi = mapBlockIndex.find(hashPrevBlock); if (mi == mapBlockIndex.end()) -return error(AcceptBlock() : prev block not found); +return

Re: [Bitcoin-development] Help wanted: translations

2011-10-08 Thread Luke-Jr
Please at least get Coinbaser merged for 0.5. It has had a lot of testing on Eligius for months, a landslide of support for the new JSON-RPC method (as requested), and I have even gone to the effort to document it. As I will no longer be using bitcoind for Eligius soon, I have little incentive

Re: [Bitcoin-development] Help wanted: translations

2011-10-10 Thread Luke-Jr
On Monday, October 10, 2011 5:22:28 AM Mike Hearn wrote: On Sun, Oct 9, 2011 at 1:12 AM, Luke-Jr l...@dashjr.org wrote: As I will no longer be using bitcoind for Eligius soon What will you be using instead? Isn't bitcoind a requirement for running a pool? Writing some custom software

Re: [Bitcoin-development] Help wanted: translations

2011-10-10 Thread Luke-Jr
On Monday, October 10, 2011 9:18:07 AM Mike Hearn wrote: As I will no longer be using bitcoind for Eligius soon What will you be using instead? Isn't bitcoind a requirement for running a pool? Writing some custom software designed to more efficiently create work. To

Re: [Bitcoin-development] State of Bitcoin Development: October Brain Dump

2011-10-13 Thread Luke-Jr
On Thursday, October 13, 2011 9:32:48 AM Gavin Andresen wrote: • Tighten up block-time rules to fix the potential timejacking attack. Once again, this does not fix anything (they're already strict enough for the 2-week window), and just creates new problems. • Work on 'discouraging'

Re: [Bitcoin-development] Lock protocol version numbers

2011-11-02 Thread Luke-Jr
On Wednesday, November 02, 2011 6:33:12 PM Amir Taaki wrote: Satoshi 0.5 What is Satoshi 0.5 anyway? 0.5's server is bitcoind and GUI is Bitcoin-Qt; the wx GUI client is gone, which is more or less what Satoshi referred to in the past...

Re: [Bitcoin-development] Lock protocol version numbers

2011-11-05 Thread Luke-Jr
On Saturday, November 05, 2011 12:17:58 PM Christian Decker wrote: Sorry for shooting this approach down, but I'm against it. User-agent strings are an extremely bad idea as it would lead developers to start making communication choices depending on the client type. This can be necessary in

Re: [Bitcoin-development] Difficulty adjustment / time issues

2011-11-07 Thread Luke-Jr
On Monday, November 07, 2011 10:02:43 AM Pieter Wuille wrote: Maybe a short interval (1 minute? 10 minutes?) instead of a fixed value could be allowed for the multiple-of-2016 blocks. Reminder that there is *already* a short interval only allowed for blocks in general...

[Bitcoin-development] Icon licenses

2011-11-15 Thread Luke-Jr
As you noticed, we replaced most of the icons with license issues in Bitcoin-Qt... but I intentionally did NOT replace the ones you created, assuming you would be willing to relicense them under the MIT (or similar) license. Could you commit a license change for these icons, ideally before

Re: [Bitcoin-development] State of Bitcoin Development: November Brain Dump

2011-11-21 Thread Luke-Jr
On Monday, November 21, 2011 8:06:27 PM Gavin Andresen wrote: Finding the money to hire some professional QA people to help create test plans and then execute them (the test plans, not the QA people) is one possible answer. Not prioritizing some unannounced release schedule over getting bugs

Re: [Bitcoin-development] Closing issues on github

2011-12-04 Thread Luke-Jr
On Sunday, December 04, 2011 5:24:08 AM John Smith wrote: I've also closed some issues that deal purely with Wx UI issues like this one: https://github.com/bitcoin/bitcoin/issues/425 I think my statement is valid, that we no longer support the old UI? Or maybe some people want to take up

Re: [Bitcoin-development] Version bytes 2.0

2011-12-12 Thread Luke-Jr
On Monday, December 12, 2011 3:56:01 PM Pieter Wuille wrote: It seems base58 is actually quite terrible for producing nice human-recognizable addresses, even though base58 is specially intended for human usage. We'll just have to deal with it, or completely overhaul it and move to a saner

Re: [Bitcoin-development] [BIP 15] Aliases

2011-12-12 Thread Luke-Jr
FirstBits looks nice at glance, but is bound to create a gold-rush to grab every nice-looking FirstBits address. HTTPS is only as secure as the (centralized) CAs, thus not really any better than TXT records. I don't think an address of some form is avoidable.

Re: [Bitcoin-development] [BIP 15] Aliases

2011-12-12 Thread Luke-Jr
On Monday, December 12, 2011 6:37:56 PM Jorge Timón wrote: Would it be too strange to use namecoin? This has the same problem as FirstBits, except .bit domains are dirt cheap, whereas vanitygen at least slows down grabbing all the common words...

Re: [Bitcoin-development] Fwd: [BIP 15] Aliases

2011-12-13 Thread Luke-Jr
On Tuesday, December 13, 2011 8:06:15 AM Gavin Andresen wrote: I agree with Mike Hearn and Christian Decker-- paying to 'someb...@foo.com' should become, behind the scenes, a HTTPS query to https://foo.com/something. If you just want to (say) donate to eff.org, then paying to '@eff.org' aught

Re: [Bitcoin-development] Fwd: [BIP 15] Aliases

2011-12-14 Thread Luke-Jr
On Wednesday, December 14, 2011 6:02:25 PM Rick Wesson wrote: I also am largely in favor of using secured zones to publish TXT records to digital currencies. I've been thinking mainly about TXT using the following format for bitcoin. _btc.lhs.rhs Don't confuse BTC (Bitcoin unit) with BC

[Bitcoin-development] Pubkey addresses

2011-12-16 Thread Luke-Jr
IMO, we should standardize and support public key addresses. While not ideal for humans, because of their length, it's a better fit for large QR Codes IMO. -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is

Re: [Bitcoin-development] Pubkey addresses

2011-12-17 Thread Luke-Jr
I propose that full public key addresses be required to be compact (length 33), and use version 21 (begins with '4', and is redundant with ver 20 for 20- byte data). Any reason this wouldn't be workable? -- Learn Windows

Re: [Bitcoin-development] Pubkey addresses

2011-12-18 Thread Luke-Jr
On Sunday, December 18, 2011 9:28:36 AM Jorge Timón wrote: Back on topic, is actually putting the whole pub key in each output what you're proposing? Yes, just like is already done for generation, since it is more efficient *overall* for the block chain. sipa's key extraction is a MUCH better

Re: [Bitcoin-development] [BIP 15] Aliases

2011-12-18 Thread Luke-Jr
On Sunday, December 18, 2011 8:14:20 PM Pieter Wuille wrote: Furthermore, the embedded bitcoin address could be hidden from the user: retrieved when first connecting, and stored together with the URI in an address book. Like ssh, it could warn the user if the key changes (which wil be ignored

[Bitcoin-development] Lying about User Agent (was: BIP language on normative behavior)

2011-12-19 Thread Luke-Jr
On Monday, December 19, 2011 5:29:34 PM Gregory Maxwell wrote: I've been arguing with Luke-JR on IRC about the interpenetration of BIP_0014— Gavin's recent commit uses the same version string for the GUI interface and the daemon mode. Luke believes this is a _violation_ of BIP_0014

[Bitcoin-development] 0.5.2 - rush?

2012-01-16 Thread Luke-Jr
Mushoz makes a good point: https://bitcointalk.org/index.php?topic=58450.msg695052#msg695052 Do we have enough downloads on 0.5.2rc1 to get the final rushed out and onto the website? -- RSA(R) Conference 2012

Re: [Bitcoin-development] bitcoin.org SOPA/PIPA blackout

2012-01-16 Thread Luke-Jr
On Monday, January 16, 2012 7:46:39 PM Alan Reiner wrote: In response to Jeff and Luke-Jr, I don't see how this is /just any other poltical issue/. It strikes at the heart of everything Bitcoin is about. Sorry, Bitcoin is not about the same thing to everyone. For me, Bitcoin is about one

Re: [Bitcoin-development] bitcoin.org SOPA/PIPA blackout

2012-01-17 Thread Luke-Jr
On Tuesday, January 17, 2012 2:42:51 AM Jorge Timón wrote: It may be a political issue, but I don't think wikipedia becomes a political organization for being against censorship. This is not about left or right. Is about free speech, one of the basic principles not only of freedom but also of

Re: [Bitcoin-development] Quote on BIP 16

2012-01-28 Thread Luke-Jr
On Sunday, January 29, 2012 12:10:41 AM Amir Taaki wrote: 2 compressed pubkeys 2 compressed pubkeys are 33 bytes each. Add 1 bytes for the N (n-of-m), 1 byte for the address version, and finally the 4 byte checksum, you get a total of 72 bytes. But these are *bytes* - to get an address, you

Re: [Bitcoin-development] CAddrMan: Stochastic IP address manager

2012-01-29 Thread Luke-Jr
On Sunday, January 29, 2012 9:31:02 PM Pieter Wuille wrote: The implementation is available in pull request 787 (https://github.com/bitcoin/bitcoin/pull/787), but there is certainly need for testing, and room for improvements. Test reports, comments, constructive criticism, suggestions and

Re: [Bitcoin-development] BIP 21 (modification BIP 20)

2012-01-30 Thread Luke-Jr
On Monday, January 30, 2012 1:07:16 PM thoma...@gmx.de wrote: I too support BIP21 over BIP20. BIP 21 is not forwards-compatible, and is intentionally designed to be biased toward decimal. BIP 20 is neutrally biased, forward-compatible, and has been implemented for over a year now. If BIP 20 is

Re: [Bitcoin-development] Announcement: libcoin

2012-02-01 Thread Luke-Jr
On Wednesday, February 01, 2012 9:18:32 AM Michael Grønager wrote: libcoin is now in a state ready for its first release, which I would like to share with you! Looks interesting. However, it doesn't configure for me: http://paste.pocoo.org/show/544135/ I noticed it's forked from bitcoind

Re: [Bitcoin-development] Announcement: libcoin

2012-02-01 Thread Luke-Jr
On Wednesday, February 01, 2012 10:58:28 AM Michael Grønager wrote: Your CMake cannot find boost - use ccmake or cmake-gui to help it with the location. I didn't see anything useful in ccmake. Boost is in the standard locations (/usr/include/boost/ and /usr/lib/libboost* Btw what platform

Re: [Bitcoin-development] Announcement: libcoin

2012-02-01 Thread Luke-Jr
On Wednesday, February 01, 2012 11:20:22 AM Michael Grønager wrote: OK - from your path it looks like linux. What version of Boost do you use. I require 1.47 or 1.48. - I will change that, but it is quite handy for signal_sets - will make an alternative scheme though. Upgrading to 1.47 did not

Re: [Bitcoin-development] libcoin (HEAD) now supports boost 1.47 - please test

2012-02-02 Thread Luke-Jr
On Thursday, February 02, 2012 8:46:05 AM Michael Grønager wrote: Please test and feed back. I found the problem: you are trying to use static libraries. Best practices are to use shared libraries (except for specific scenarios like universal Linux binaries) and most distros do not have static

Re: [Bitcoin-development] libcoin (HEAD) now supports boost 1.47 - please test

2012-02-02 Thread Luke-Jr
On Thursday, February 02, 2012 5:43:07 PM Michael Grønager wrote: Enabling dynamic libs was on my TODO, but on the Redmond_OS_not_to_be_mentioned you need to : * prepend class definitions with __declspec(dllexport) when you compile the dll * prepend class definitions with __declspec(dllimport)

Re: [Bitcoin-development] Version 0.6 release candidate 1 plan

2012-02-07 Thread Luke-Jr
On Monday, February 06, 2012 10:54:25 AM Luke-Jr wrote: 769 : Make transactions with extra data in scriptSig non-standard If this affects relaying, it will significantly harm the ability to replace the current spammy green address scheme with a sensible extra signature system. On the miner

Re: [Bitcoin-development] Version 0.6 release candidate 1 plan

2012-02-07 Thread Luke-Jr
On Tuesday, February 07, 2012 10:04:36 AM Luke-Jr wrote: On Monday, February 06, 2012 10:54:25 AM Luke-Jr wrote: 769 : Make transactions with extra data in scriptSig non-standard If this affects relaying, it will significantly harm the ability to replace the current spammy green address

[Bitcoin-development] 2012-02-17 next[-test]

2012-02-17 Thread Luke-Jr
849 gavin/testnetmining 852 Fix #846. Allow negative options in bitcoin.conf 719 coinbaser ^^ next ^^ 834 sje/BackupWallet 570 force_send 806 sipa/threadid 816 sipa/lameversion ^^ 037497c ^^ 854 laanwj/2012_02_qtipc 841

Re: [Bitcoin-development] BIP-13

2012-02-22 Thread Luke-Jr
On Wednesday, February 22, 2012 11:29:59 AM Michael Grønager wrote: SCRIPT_ADDRESS_TEST = 196, (11000100) !!! 11xx - test network xx00 - bitcoin 010y - p2sh This fits... PUBKEY_ADDRESS_TEST = 111, (0110) !!! What Gavin said.

Re: [Bitcoin-development] JSON-RPC is BIP territory or not?

2012-03-02 Thread Luke-Jr
On Friday, March 02, 2012 1:51:41 PM Amir Taaki wrote: It is a implementation-specific non-bitcoin-protocol proposal. My understanding of BIPs is that they apply across bitcoin implementations and largely focus on the most generic use-cases (like the URIs) and the protocol. Things which affect

Re: [Bitcoin-development] getmemorypool BIP process

2012-03-03 Thread Luke-Jr
On Saturday, March 03, 2012 9:23:08 AM Stefan Thomas wrote: From what I understand the BIP uses a polling model, e.g. a miner would use getmemorypool to request new work from a pool in intervals. Would it make sense to specify a version of the API supporting long polling? You mean explicitly

Re: [Bitcoin-development] getmemorypool BIP process

2012-03-03 Thread Luke-Jr
On Saturday, March 03, 2012 10:05:58 AM Gavin Andresen wrote: HTTP and JSON-RPC are a client-server model; there is no way for the server to make calls to the client. It's not practical to expect clients to run their own JSON-RPC server - many cannot listen on WAN ports at all. You're

Re: [Bitcoin-development] getmemorypool BIP process

2012-03-03 Thread Luke-Jr
On Saturday, March 03, 2012 6:51:34 PM Geir Harald Hansen wrote: Long polling as currently implemented in pools has a race condition. Does the miner reconnect first or does another block change happen first? Double block changes are common with merged mining and I'm doing all sorts of tricks

Re: [Bitcoin-development] Adding a pong message

2012-03-13 Thread Luke-Jr
On Tuesday, March 13, 2012 2:06:38 PM Mike Hearn wrote: https://github.com/bitcoin/bitcoin/pull/932 adds a pong message that echoes back a 64 bit nonce contained in the ping, if the protocol version is new enough. The goal of this is to make it easier for clients, especially mobile clients,

Re: [Bitcoin-development] Adding callback hooks to the satoshi client

2012-03-22 Thread Luke-Jr
On Thursday, March 22, 2012 1:13:13 AM Eric Lombrozo wrote: I would like to propose adding these callback hooks to the main branch. I am willing to help locate these key points, reorganize the code to place these methods in separate source files, define a callback mechanism, and contribute

[Bitcoin-development] 0.7 merge recommendations/status

2012-03-30 Thread Luke-Jr
NOTE: I've been piecing this together for about a week now, and intended to update it when 0.6.0 final was released, but with the timing of it, I just won't get the time to update for a while, so here is my last draft... It seems to me, there is potentially enough ready to merge into 0.7 to

Re: [Bitcoin-development] Signature Blocks and URI Sign Requests

2012-04-02 Thread Luke-Jr
On Monday, April 02, 2012 4:55:03 PM Alan Reiner wrote: Any thoughts? (I have no doubts that there are :) ) IMO, the sign-request URI should be an extension on the existing bitcoin: URI scheme; this way, sigNeeded can be omitted to imply sign with a sending address.

Re: [Bitcoin-development] Signature Blocks and URI Sign Requests

2012-04-03 Thread Luke-Jr
On Tuesday, April 03, 2012 2:46:17 PM Gavin Andresen wrote: We should avoid reinventing the wheel, if we can. I think we should extend existing standards whenever possible. I wonder if it's possible to make sigs compatible with PGP/EC ?

Re: [Bitcoin-development] new bitcoin.org clients page

2012-05-02 Thread Luke-Jr
On Wednesday, May 02, 2012 9:22:42 AM Mike Hearn wrote: The original software written by Satoshi Nakamoto, the project's founder. This is just wrong. While Bitcoin-Qt is by far the best client, it is Wladimir's, not Satoshi's. If your computer is low powered or you aren't willing to tolerate

Re: [Bitcoin-development] new bitcoin.org clients page

2012-05-02 Thread Luke-Jr
On Wednesday, May 02, 2012 12:21:13 PM grarpamp wrote: Can someone also please set the reply-to header for these lists. It's really annoying to hit reply and not have the list address show up. Thanks :) Try Reply to All

Re: [Bitcoin-development] new bitcoin.org clients page

2012-05-02 Thread Luke-Jr
On Wednesday, May 02, 2012 3:34:35 PM Gary Rowe wrote: Bitcoin-Qt * Developed in C This is far less relevant than license... Armory * Requires the entire blockchain * Dependent client of Bitcoin-Qt Or bitcoind? Electrum * Dependent client of Bitcoin-Qt (on server) Dependent on

Re: [Bitcoin-development] P2P feature discovery (was Re: BIP 33 - Stratized Nodes)

2012-05-16 Thread Luke-Jr
On Wednesday, May 16, 2012 6:18:27 PM Jeff Garzik wrote: Instead of further overloading service bits in the version message, or altering the version message, let us instead make feature discovery an easy, flexible, extensible process. We can add new commands without impacting older nodes, so

Re: [Bitcoin-development] P2P feature discovery (was Re: BIP 33 - Stratized Nodes)

2012-05-16 Thread Luke-Jr
On Wednesday, May 16, 2012 6:38:28 PM Jeff Garzik wrote: On Wed, May 16, 2012 at 2:29 PM, Luke-Jr l...@dashjr.org wrote: That assumes you already have a connection to the peer in question. As I understand it, the service bits are propagated as part of the address, so you can see at a glance

Re: [Bitcoin-development] Punishing empty blocks?

2012-05-24 Thread Luke-Jr
On Thursday, May 24, 2012 4:33:12 PM Jeff Garzik wrote: There appears to be some non-trivial mining power devoted to mining empty blocks. Even with satoshi's key observation -- hash a fixed 80-byte header, not the entire block -- some miners still find it easier to mine empty blocks, rather

Re: [Bitcoin-development] Punishing empty blocks?

2012-05-24 Thread Luke-Jr
On Thursday, May 24, 2012 4:33:12 PM Jeff Garzik wrote: Comments? It wouldn't be a problem if these no-TX blocks were not already getting frequent (1 in 20). FWIW, based on statistics for Eligius's past 100 blocks, it seems 10% (1 in 10) of 1-txn blocks is not actually unreasonable. This also

Re: [Bitcoin-development] Punishing empty blocks?

2012-05-24 Thread Luke-Jr
On Friday, May 25, 2012 12:51:09 AM Jeff Garzik wrote: On Thu, May 24, 2012 at 8:45 PM, Luke-Jr l...@dashjr.org wrote: On Thursday, May 24, 2012 4:33:12 PM Jeff Garzik wrote: Comments? It wouldn't be a problem if these no-TX blocks were not already getting frequent (1 in 20). FWIW

Re: [Bitcoin-development] Punishing empty blocks?

2012-05-29 Thread Luke-Jr
On Tuesday, May 29, 2012 3:05:18 PM Peter Vessenes wrote: 1) Germane to the original conversation, anything hard to implement will not get implemented by miners. Without my got-tired-of-waiting-for-someone-to-merge-it coinbaser branch, anything modifying the coinbase is hard to implement. 2)

Re: [Bitcoin-development] Punishing empty blocks?

2012-05-29 Thread Luke-Jr
On Tuesday, May 29, 2012 3:28:56 PM Peter Vessenes wrote: I don't understand what the 20 byte keyhash is. Can you elucidate? 20 byte keyhashes are a fundamental building block of the Bitcoin protocol. ripemd160(sha256(ecdsaPubKey))

Re: [Bitcoin-development] Punishing empty blocks?

2012-05-29 Thread Luke-Jr
On Tuesday, May 29, 2012 3:36:34 PM Peter Vessenes wrote: I suppose I mean that I don't understand how to reverse that into a URL when one is presented only with a block, or perhaps a coinbase in a transaction. A new message can be added to the p2p relay network, similar to tx and alert

[Bitcoin-development] Defeating the block withholding attack

2012-06-02 Thread Luke-Jr
Analysis, comments, constructive criticism, etc welcome for the following: ==Background== At present, an attacker can harm a pool by intentionally NOT submitting shares that are also valid blocks. All pools are vulnerable to this attack, whether centralized or decentralized and regardless of

Re: [Bitcoin-development] Defeating the block withholding attack

2012-06-03 Thread Luke-Jr
On Monday, June 04, 2012 1:43:42 AM Peter Vessenes wrote: Does it have asymmetric payoff for an attacker, that is, over time does it pay them more to spend their hashes attacking than just mining? That depends on the pool's reward scheme. Some complicated forms are capable of getting bonus

[Bitcoin-development] BIP16 backport bug (0.4.x and 0.5.x stuck on block 177617)

2012-06-14 Thread Luke-Jr
Block 177618 was rejected by BIP16-enabled backports (0.4.x and 0.5.x) due to containing a P2SH redemption with over 200 bytes in. Since the BIP16 code uses IsPushOnly to check the scriptSig for compliance, and IsPushOnly in these versions also enforced the 200-byte is standard rule, they were

Re: [Bitcoin-development] After compressed pubkeys: hybrid pubkeys

2012-06-16 Thread Luke-Jr
On Saturday, June 16, 2012 11:39:00 PM Gregory Maxwell wrote: On Sat, Jun 16, 2012 at 5:41 PM, Gavin Andresen gavinandre...@gmail.com wrote: RE: 0x06/0x07 'hybrid' public keys: Any opinions? Forbidding it certainly makes alternative implementation slightly easier in the future, but I'm not

Re: [Bitcoin-development] 0.6.x - detachdb in wrong place

2012-06-17 Thread Luke-Jr
On Sunday, June 17, 2012 11:04:42 PM grarpamp wrote: https://github.com/bitcoin/bitcoin https://git.gitorious.org/bitcoin/bitcoind-stable The latter is Luke's backports of security and stability fixes to otherwise unmaintained old versions. Ah ok, coming from cvs/svn, it's a bit

Re: [Bitcoin-development] Random order for clients page

2012-07-09 Thread Luke-Jr
FWIW, all this argumenting is why my original suggestion for a Clients list focussed on objective information in alphabetical order. -- Live Security Virtual Conference Exclusive live event will cover all the ways

Re: [Bitcoin-development] bitcoin.org - remove hackathon

2012-07-16 Thread Luke-Jr
On Monday, July 16, 2012 11:47:02 PM Jeff Garzik wrote: Vladimir does raise a fair point, though. Hackathon seems appropriate for bitcoin.org as it is focused on dev-related activities. (full disclosure: speaking at bitcoin2012.com) The conference might or might not be. The conference does

Re: [Bitcoin-development] Scalability issues

2012-07-27 Thread Luke-Jr
On Friday, July 27, 2012 5:59:20 AM grarpamp wrote: I now have an 1.8 ghz p3 celeron (128k cache) which should be substantially slower than your machine, running vintage 2.6.20 linux. Unfortunately I forgot to turn on timestamp logging so I don't know how long it took to sync the chain,

Re: [Bitcoin-development] Signing release binaries

2012-07-29 Thread Luke-Jr
On Sunday, July 29, 2012 10:17:51 AM Mike Hearn wrote: I guess Gavin would be the final signer. Considering that Gavin is not interested in participating in any way in the stable versions, I would prefer to see someone else responsible for OS-vendor signing.

Re: [Bitcoin-development] BIP 22 - getmemorypool

2012-07-30 Thread Luke-Jr
On Monday, July 30, 2012 8:26:12 PM Amir Taaki wrote: https://en.bitcoin.it/wiki/BIP_0022 Note that the Pooled Mining parts have already been moved to: https://en.bitcoin.it/wiki/BIP_GMPPM It just needs a number assigned (as the last part).

Re: [Bitcoin-development] Version 0.7 release planning

2012-08-02 Thread Luke-Jr
to enabled) luke-jr https://github.com/bitcoin/bitcoin/pull/1431 11) MAYBE: getblocktemplate ('getmemorypool', post IRC debate) luke-jr https://github.com/bitcoin/bitcoin/pull/936 + + m) getmemorypool: longpolling support + luke-jr https://github.com/bitcoin/bitcoin/pull/1355 + + m) Refactor

Re: [Bitcoin-development] Segmented Block Relaying BIP draft.

2012-09-10 Thread Luke-Jr
On Monday, September 10, 2012 3:07:52 PM Matthew Mitchell wrote: Here is a BIP draft for improving the block relaying and validation so that it can be done in parallel and so that redundancy can be removed. This becomes more beneficial the larger the block sizes are.

Re: [Bitcoin-development] Hosting of compiled bitcoin client

2012-10-14 Thread Luke-Jr
On Sunday, October 14, 2012 8:52:33 PM Kyle Henderson wrote: Given that sourceforge has shown to restrict access to a number of countries at the request of the USA This needs some clarification. If the USA has requested it, then presumably there's some legality involved, and our US developers

Re: [Bitcoin-development] IRC meeting agenda, 18:00 UTC Thursday

2012-11-06 Thread Luke-Jr
On Tuesday, November 06, 2012 6:47:34 PM Gavin Andresen wrote: Thursdays at 18:00 UTC (6PM Europe/1PM east US/10AM west US) seem to be a good time for the core dev team to meet on the #bitcoin-dev freenode IRC channel to chat. I'd like to talk about: o Can we put together a TODO list to

Re: [Bitcoin-development] IRC meeting agenda, 18:00 UTC Thursday

2012-11-06 Thread Luke-Jr
On Tuesday, November 06, 2012 7:56:23 PM slush wrote: On Tue, Nov 6, 2012 at 7:13 PM, Luke-Jr l...@dashjr.org wrote: But more important to the success of BIP today, I think, is encouraging wider community participation. It's not about BIP process, it's possibly about content of particular

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

2012-11-26 Thread Luke-Jr
On Monday, November 26, 2012 11:32:46 PM Gregory Maxwell wrote: Obviously the state of the world with browsers is not that good... but in our own UAs we can do better and get closer to that. This effectively centralizes Bitcoin (at least in the eyes of many) and even if each competing client

Re: [Bitcoin-development] 0.8.0rc1 status

2013-02-08 Thread Luke-Jr
On Friday, February 08, 2013 11:49:09 PM Gavin Andresen wrote: Windows builds are varying with every compile, and I think I finally figured out why: we are not passing the -frandom-seed flag down into the leveldb build (I used objdump to dump two different binaries, and they differed only in

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

2013-02-09 Thread Luke-Jr
On Saturday, February 09, 2013 2:33:25 PM Timo Hanke wrote: Why don't you use namecoin or another alt-chain for this? Because namcoin tries to solve a different problem, DNS, whereas I want to establish an identity for a payment protocol. What is the technical difference here? Namecoin ties

Re: [Bitcoin-development] [PATCH] Change recommended fee to 0.001 BTC

2013-03-11 Thread Luke-Jr
On Monday, March 11, 2013 7:27:51 PM Rune K. Svendsen wrote: From: Rune K. Svendsen runesv...@gmail.com On the Main tab in the Options dialog, it previously said a minimum fee of 0.01 is recommended. This amounts to about $0.50 at today's price. Change this to 0.001 to be more sensible. We

Re: [Bitcoin-development] [PATCH] Change recommended fee to 0.001 BTC

2013-03-11 Thread Luke-Jr
On Monday, March 11, 2013 9:17:25 PM Rune Kjær Svendsen wrote: On Mon, Mar 11, 2013 at 9:46 PM, Luke-Jr l...@dashjr.org wrote: On Monday, March 11, 2013 8:34:52 PM Rune Kjær Svendsen wrote: Ok. I'll fork on Github. Looking at the source, and some Qt documentation, it should

Re: [Bitcoin-development] Some PR preparation

2013-03-12 Thread Luke-Jr
On Tuesday, March 12, 2013 7:03:54 AM Alan Reiner wrote: I'm sure it won't be long before Slashdot and a variety of sources start reporting on this event. Bitcoin has been in the media a lot lately, so this story is likely to get some attention. The blowback of this event is mostly

Re: [Bitcoin-development] 0.8.1 ideas

2013-03-13 Thread Luke-Jr
controversial changes. I figured 2 MB in 2-3 years was fairly uncontroversial. If not, let's scrap that idea for now. Luke-jr, any chance in getting you to revise your proposal to narrow the scope to things that don't need serious debate? It was a one-time start the conversation proposal. I expect what

Re: [Bitcoin-development] 0.8.1 ideas

2013-03-13 Thread Luke-Jr
clients *is by definition* a hard fork. Proposal: 1) Patch the pre-0.8 branches to support an increased lock count, whatever number is required to make sure that this problem never shows up again at the current block size (I defer to Luke-Jr and gmaxwell's numbers on this). This is a hard fork

Re: [Bitcoin-development] Blocksize and off-chain transactions

2013-03-13 Thread Luke-Jr
On Wednesday, March 13, 2013 6:01:02 PM Michael Gronager wrote: Please note that it was not 0.8 that had issues, but 0.7(and downwards). While 0.7 and earlier do have issues, they also define the Bitcoin protocol. 0.8's failure to comply with the protocol is an issue.

Re: [Bitcoin-development] 0.8.1 ideas

2013-03-13 Thread Luke-Jr
On Wednesday, March 13, 2013 6:27:13 PM Mark Friedenbach wrote: Luke-Jr is suggesting that we add-to/modify the bitcoin protocol rules which all verifying implementations must adhere to. I'm suggesting that we instead change the old codebase to do what we expected it to do all along (what 0.8

Re: [Bitcoin-development] 0.8.1 ideas

2013-03-13 Thread Luke-Jr
On Wednesday, March 13, 2013 9:06:44 PM Andy Parkins 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 client

Re: [Bitcoin-development] 0.8.1 ideas

2013-03-15 Thread Luke-Jr
On Friday, March 15, 2013 5:06:20 PM Benjamin Lindner wrote: On Mar 13, 2013, at 8:18 PM, Cameron Garnham da2...@gmail.com wrote: For me, everyone signed up to bitcoin thinking that there was a 1MB / block limit. The lock limits were unexpected, and could be considered extremely

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

2013-03-23 Thread Luke-Jr
On Saturday, March 23, 2013 10:42:26 AM Randy Willis wrote: Introducing super-nodes with thousands of connected peers can greatly help here. UDP is connectionless. I would hope any UDP bitcoin protocol doesn't try to emulate a connection. :/ Luke

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

2013-03-23 Thread Luke-Jr
On Saturday, March 23, 2013 5:28:55 PM Jeff Garzik wrote: On Sat, Mar 23, 2013 at 1:09 PM, Luke-Jr l...@dashjr.org wrote: I don't think anyone is mining using bitcoind 0.7 or later? slush, BTC Guild, ozcoin too I think, several others. Not for producing coinbases (where BIP 34

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

2013-03-23 Thread Luke-Jr
On Saturday, March 23, 2013 5:47:46 PM Jeff Garzik wrote: On Sat, Mar 23, 2013 at 1:43 PM, Luke-Jr l...@dashjr.org wrote: On Saturday, March 23, 2013 5:28:55 PM Jeff Garzik wrote: On Sat, Mar 23, 2013 at 1:09 PM, Luke-Jr l...@dashjr.org wrote: I don't think anyone is mining using bitcoind

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

2013-03-23 Thread Luke-Jr
On Saturday, March 23, 2013 6:21:32 PM Jeff Garzik wrote: On Sat, Mar 23, 2013 at 1:51 PM, Luke-Jr l...@dashjr.org wrote: bitcoind is nowhere in the implementation of the miner end of BIP 34. Again, not strictly true. bitcoind's 'getblocktemplate' RPC call used by some supplies the block

Re: [Bitcoin-development] RFC: extend signmessage/verifymessage to P2SH multisig

2013-04-13 Thread Luke-Jr
On Sunday, April 14, 2013 5:09:58 AM Peter Todd wrote: Currently signmessage/verifymessage only supports messages signed by a single key. We should extend that to messages signed by n-of-m keys, or from the users point of view, P2SH multisig addresses. I think it would be wise to figure out HD

Re: [Bitcoin-development] UUID to identify chains (payment protocol and elsewhere)

2013-05-22 Thread Luke-Jr
On Wednesday, May 22, 2013 2:20:22 PM Jeff Garzik wrote: On Wed, May 22, 2013 at 10:12 AM, Melvin Carvalho melvincarva...@gmail.com wrote: On 22 May 2013 16:07, Jeff Garzik jgar...@exmulti.com wrote: On Wed, May 22, 2013 at 6:27 AM, Melvin Carvalho melvincarva...@gmail.com wrote:

Re: [Bitcoin-development] Tentitive port for FreeBSD

2013-05-24 Thread Luke-Jr
On Saturday, May 25, 2013 3:36:46 AM Robert Backhaus wrote: Here is the link to the FreeBSD build system 'port' that I am planning to get committed when 0.8.2 is released. Any comments appreciated. The Makefile mostly just applies the users request for GIU/QR/UPNP. The major change is using

Re: [Bitcoin-development] (no subject)

2013-05-25 Thread Luke-Jr
On Saturday, May 25, 2013 8:25:35 AM Melvin Carvalho wrote: It might be an idea to have 'rule change' fixes and 'bug fix' releases go out separately Bitcoin is a consensus system. You can't run clients with different rules on the same blockchain/network - it just won't work! Maybe we're now

  1   2   >