* [Bitcoin-development] Change to multiple executables?
@ 2011-08-10 9:36 John Smith
2011-08-10 10:14 ` Matt Corallo
` (2 more replies)
0 siblings, 3 replies; 26+ messages in thread
From: John Smith @ 2011-08-10 9:36 UTC (permalink / raw)
To: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1025 bytes --]
All,
In the current mainline client everything is lugged into one executable
(with an optional daemon-only one). I think this is a bad idea for various
reasons, and would propose something like:
- bitcoind: bitcoin daemon
- bitcoin(-qt): bitcoin GUI executable
- bitcoincl: bitcoin RPC command line
By default, all three would be built. In non-GUI mode, only bitcoind and
bitcoincl are built (the names are obviously open for discussion).
Advantages:
- It is more clear to the user. One command, one function.
- It simplifies the main functions.
- The UI would no longer double-function as daemon. It is a waste of
memory to link the UI libs if you only want to run a background process.
- The UI and daemon would no longer double-function as RPC call. Why load
the code for UI and network if you just want to send a single command over
JSONRPC? This would also prevent accidentally launching the daemon/UI
locally if you just want to send a command and forget to give an argument.
JS
[-- Attachment #2: Type: text/html, Size: 1448 bytes --]
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [Bitcoin-development] Change to multiple executables? 2011-08-10 9:36 [Bitcoin-development] Change to multiple executables? John Smith @ 2011-08-10 10:14 ` Matt Corallo 2011-08-10 10:26 ` John Smith 2011-08-10 10:43 ` Pieter Wuille 2011-08-10 21:37 ` Jeff Garzik 2011-08-11 13:50 ` Pieter Wuille 2 siblings, 2 replies; 26+ messages in thread From: Matt Corallo @ 2011-08-10 10:14 UTC (permalink / raw) To: bitcoin-development On Wed, 2011-08-10 at 09:36 +0000, John Smith wrote: > All, > > In the current mainline client everything is lugged into one > executable (with an optional daemon-only one). I think this is a bad > idea for various reasons, and would propose something like: > * bitcoind: bitcoin daemon > * bitcoin(-qt): bitcoin GUI executable > * bitcoincl: bitcoin RPC command line > By default, all three would be built. In non-GUI mode, only bitcoind > and bitcoincl are built (the names are obviously open for > discussion). > > Advantages: > * It is more clear to the user. One command, one function. I would argue its less clear for the user. Instead of opening either bitcoind or bitcoin to get RPC or GUI, now you have to open bitcoin and bitcoind or bitcoincl and bitcoind. Now, obviously bitcoin and bitcoincl can open bitcoind for you, but I think adding more executables complicates things for little clear advantage. > * It simplifies the main functions. > * The UI would no longer double-function as daemon. It is a > waste of memory to link the UI libs if you only want to run a > background process. As you pointed out, we have bitcoind for just this reason. > * The UI and daemon would no longer double-function as RPC call. > Why load the code for UI and network if you just want to send > a single command over JSONRPC? This would also prevent > accidentally launching the daemon/UI locally if you just want > to send a command and forget to give an argument. Making RPC optional for GUI users would be an interesting addition. > JS All this said, I totally agree with the more clear split of the source into separate library-ish components (I'm working on part of that now). However, I don't like the idea of splitting into more executables. If you are suggesting this so that bitcoin-qt can be distributed being built off of bitcoind, I would say go ahead and pull-request bitcoin-qt. I'm of the opinion that it should be merged whether we have autotools or not (we already have 5 makefiles, whats a few more options in those?) and jgarzik seemed to indicate that he would agree (Gavin?, sipa? tcatm?). Matt ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Bitcoin-development] Change to multiple executables? 2011-08-10 10:14 ` Matt Corallo @ 2011-08-10 10:26 ` John Smith 2011-08-10 10:43 ` Pieter Wuille 1 sibling, 0 replies; 26+ messages in thread From: John Smith @ 2011-08-10 10:26 UTC (permalink / raw) To: Matt Corallo; +Cc: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 1067 bytes --] On Wed, Aug 10, 2011 at 10:14 AM, Matt Corallo <bitcoin-list@bluematt•me>wrote: > I would argue its less clear for the user. Instead of opening either > bitcoind or bitcoin to get RPC or GUI, now you have to open bitcoin and > bitcoind or bitcoincl and bitcoind. Now, obviously bitcoin and > bitcoincl can open bitcoind for you, but I think adding more executables > complicates things for little clear advantage. > UI would obviously still have RPC functionality with -server. I don't mean dropping that. The UI links both the UI and the network code (for now, until this is separated out and the preferred UI<->core communication method is through RPC). I just mean that the *headless* daemon is separate from the UI executable, which is the case for any other sane client/server-based program in existence, from bittorrent nodes to game servers. It would also make it possible to build the command line RPC client (bitcoin-cl) *without* building the server or UI. Useful if you want to remotely control a Bitcoin daemon but not want to build it locally. JS [-- Attachment #2: Type: text/html, Size: 1364 bytes --] ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Bitcoin-development] Change to multiple executables? 2011-08-10 10:14 ` Matt Corallo 2011-08-10 10:26 ` John Smith @ 2011-08-10 10:43 ` Pieter Wuille [not found] ` <CAJNQ0ssWeU2vgR8XmCyGiZ3UHPv=zjLZEKVM=gqP0ozSC7Wmiw@mail.gmail.com> 1 sibling, 1 reply; 26+ messages in thread From: Pieter Wuille @ 2011-08-10 10:43 UTC (permalink / raw) To: bitcoin-development On Wed, Aug 10, 2011 at 12:14:49PM +0200, Matt Corallo wrote: > On Wed, 2011-08-10 at 09:36 +0000, John Smith wrote: > > All, > > > > In the current mainline client everything is lugged into one > > executable (with an optional daemon-only one). I think this is a bad > > idea for various reasons, and would propose something like: > > * bitcoind: bitcoin daemon > > * bitcoin(-qt): bitcoin GUI executable > > * bitcoincl: bitcoin RPC command line > > By default, all three would be built. In non-GUI mode, only bitcoind > > and bitcoincl are built (the names are obviously open for > > discussion). > > All this said, I totally agree with the more clear split of the source > into separate library-ish components (I'm working on part of that now). > However, I don't like the idea of splitting into more executables. I do agree about splitting off bitcoincl - it's kinda confusing now how the client behaves as a rpc daemon or UI when no RPC command-line parameters are present, and as a command-line client otherwise. I am less sure UI and RPC should be split (though being able to select both independently from eachother at compile time would be nice). I often run the UI and switch to RPC calls to inspect some details. Not sure how common this usage pattern is, though. > If you are suggesting this so that bitcoin-qt can be distributed being > built off of bitcoind, I would say go ahead and pull-request bitcoin-qt. > I'm of the opinion that it should be merged whether we have autotools or > not (we already have 5 makefiles, whats a few more options in those?) > and jgarzik seemed to indicate that he would agree (Gavin?, sipa? > tcatm?). The problem is that bitcoin-qt is built using qmake, and the rest using makefiles... so it's more than just adding an additional makefile. That said, it seems bitcoin-qt is mature enough to replace wxbitcoin to me, and would definitely like to see it in mainline. How streamlined is the process of building bitcoin-qt on windows and osx? Maybe we can switch everything to qmake (for now, as long as no maintained autotools is present)? -- Pieter ^ permalink raw reply [flat|nested] 26+ messages in thread
[parent not found: <CAJNQ0ssWeU2vgR8XmCyGiZ3UHPv=zjLZEKVM=gqP0ozSC7Wmiw@mail.gmail.com>]
* [Bitcoin-development] Change to multiple executables? [not found] ` <CAJNQ0ssWeU2vgR8XmCyGiZ3UHPv=zjLZEKVM=gqP0ozSC7Wmiw@mail.gmail.com> @ 2011-08-10 13:18 ` John Smith 2011-08-10 16:49 ` Gavin Andresen 0 siblings, 1 reply; 26+ messages in thread From: John Smith @ 2011-08-10 13:18 UTC (permalink / raw) To: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 2520 bytes --] > I do agree about splitting off bitcoincl - it's kinda confusing now how > the client behaves as a rpc daemon or UI when no RPC command-line > parameters are present, and as a command-line client otherwise. > > I am less sure UI and RPC should be split (though being able to select > both independently from eachother at compile time would be nice). I > often run the UI and switch to RPC calls to inspect some details. > Not sure how common this usage pattern is, though. > No no no I never stated that the UI should no longer support RPC. If you want the UI, with RPC, you can still run the UI executable with -server. There are many usecases in which you want to access the UI bitcoin client using RPC... I only meant that it would also build the *headless* daemon by default, as separate "bitcoind" executable. So you cannot run the UI exectuable as headless server anymore. The -daemon option would go away. It would make the setup a lot easier: The UI can connect to X and display a splash screen immediately without first looking at the command line arguments, whereas the headless daemon can ignore all that stuff and get straight to work. > > If you are suggesting this so that bitcoin-qt can be distributed being > > built off of bitcoind, I would say go ahead and pull-request bitcoin-qt. > > I'm of the opinion that it should be merged whether we have autotools or > > not (we already have 5 makefiles, whats a few more options in those?) > > and jgarzik seemed to indicate that he would agree (Gavin?, sipa? > > tcatm?). > > That said, it seems bitcoin-qt is mature enough to replace wxbitcoin > to me, and would definitely like to see it in mainline. How streamlined > is the process of building bitcoin-qt on windows and osx? Maybe we can > switch everything to qmake (for now, as long as no maintained autotools > is present)? > It's easy on windows: just install Qt Creator (comes with the Qt SDK), install the extra dependencies (build instructions are in README.rst), and hit build. On MacOSX I'm not sure. I think it's similar, as a few people built it for MacOSX and contributed settings for the .pro file... It can build the GUI fine for every platform, however it can only build the GUI, not the headless daemon or the command line client. You'd still need old fashioned makefiles for those. Cmake or autotools would be better, especially as those are intelligent enough to auto-detect the name of libraries such as boost, and detect presence of optional dependencies (miniupnp). JS [-- Attachment #2: Type: text/html, Size: 3291 bytes --] ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Bitcoin-development] Change to multiple executables? 2011-08-10 13:18 ` John Smith @ 2011-08-10 16:49 ` Gavin Andresen 2011-08-10 17:45 ` John Smith 0 siblings, 1 reply; 26+ messages in thread From: Gavin Andresen @ 2011-08-10 16:49 UTC (permalink / raw) To: John Smith; +Cc: Bitcoin Dev RE: splitting off the "send commands to a running bitcoin" : I'm mildly against it. It would be less confusing for newbies, at the cost of forcing everybody who has already written backup scripts or other interact-with-running-bitcoin tools to tweak their code. The coding will be easy, but do you really want to spend the time to answer all the "I installed Bitcoin X.Y and now my backup script doesn't work" questions and modify the wiki pages and ... I'd rather that time be spent working on any remaining build issues so we can switch to bitcoin-qt. I don't care if it is autotools or qmake or QT creator, I just care that it works on Windows and Linux under gitian and has clear instructions so I can build it on my Mac. -- -- Gavin Andresen ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Bitcoin-development] Change to multiple executables? 2011-08-10 16:49 ` Gavin Andresen @ 2011-08-10 17:45 ` John Smith 2011-08-10 18:41 ` Gavin Andresen 2011-08-10 18:43 ` Luke-Jr 0 siblings, 2 replies; 26+ messages in thread From: John Smith @ 2011-08-10 17:45 UTC (permalink / raw) To: Gavin Andresen; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1880 bytes --] On Wed, Aug 10, 2011 at 4:49 PM, Gavin Andresen <gavinandresen@gmail•com>wrote: > RE: splitting off the "send commands to a running bitcoin" : > > I'm mildly against it. It would be less confusing for newbies, at the > cost of forcing everybody who has already written backup scripts or > other interact-with-running-bitcoin tools to tweak their code. The > coding will be easy, but do you really want to spend the time to > answer all the "I installed Bitcoin X.Y and now my backup script > doesn't work" questions and modify the wiki pages and ... > As the project is still in "experimental" phase I suppose people can expect changes like this? And the change is pretty much trivial, and it makes sense for a future direction (UI<->Wallet in separate processes for security concerns). To be honest I feel a bit like every change that I (and I've also heard this from others) propose is shot down, no matter how well formulated. This is actively discouraging developers from joining this project. Of course it makes sense to be a careful, but the project is not on life support is it? Satoshi did a great job making the program, but his work was not perfect, and it makes sense to look ahead a bit. I think it would be better to switch to two branches, like most other open source projects I've worked with: 0.3.x -> small, compatible changes, bugfixes, like now 0.4.x -> trunk, more impactful changes, refactorings, eventual major release Both will obviously be fully compatible on the P2P-level. > I'd rather that time be spent working on any remaining build issues so > we can switch to bitcoin-qt. I don't care if it is autotools or qmake > or QT creator, I just care that it works on Windows and Linux under > gitian and has clear instructions so I can build it on my Mac. > I could do the Gitian stuff but not the Mac instructions, as I don't have a Mac... JS [-- Attachment #2: Type: text/html, Size: 2445 bytes --] ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Bitcoin-development] Change to multiple executables? 2011-08-10 17:45 ` John Smith @ 2011-08-10 18:41 ` Gavin Andresen 2011-08-10 19:32 ` Andy Parkins 2011-08-11 12:19 ` John Smith 2011-08-10 18:43 ` Luke-Jr 1 sibling, 2 replies; 26+ messages in thread From: Gavin Andresen @ 2011-08-10 18:41 UTC (permalink / raw) To: John Smith; +Cc: Bitcoin Dev > To be honest I feel a bit like every change that I (and I've also heard this > from others) propose is shot down, no matter how well formulated. This is > actively discouraging developers from joining this project. Well, to be honest I don't think more developers adding new features are needed right now-- I think the project's critical needs are more people testing and helping to fix bugs and scalability issues. In this particular case, I said I was mildly against it-- if you want me to switch to supporting it, then reassure me you're willing to do ALL the work to make it happen. Send me a list of wiki pages you'll edit to document the change and tell me that you'll be around to help people rewrite their backup scripts. > I think it would be better to switch to two branches, like most other open > source projects I've worked with. I don't see how dividing efforts between a 'bug fix' and 'development' branch will help fix the project's critical needs. If we did, I think there would be less pressure to help with the boring bug-fixing and testing of the bug-fix branch, which I think would be bad. -- -- Gavin Andresen ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Bitcoin-development] Change to multiple executables? 2011-08-10 18:41 ` Gavin Andresen @ 2011-08-10 19:32 ` Andy Parkins 2011-08-10 19:57 ` Jeff Garzik 2011-08-11 12:19 ` John Smith 1 sibling, 1 reply; 26+ messages in thread From: Andy Parkins @ 2011-08-10 19:32 UTC (permalink / raw) To: bitcoin-development On Wednesday 10 August 2011 19:41:51 Gavin Andresen wrote: > > To be honest I feel a bit like every change that I (and I've also heard > > this from others) propose is shot down, no matter how well > > formulated. This is actively discouraging developers from joining > > this project. > > Well, to be honest I don't think more developers adding new features > are needed right now-- I think the project's critical needs are more > people testing and helping to fix bugs and scalability issues. (Rant follows; stop reading now) That paragraph reveals a gross misunderstanding of how open source works. People get itches and they want to scratch them. They aren't paid, so they don't necessarilly want to turn up and be told which part they _should_ be working on. The choice is not "bug fix that Gavin wants" or "new feature that New Developer wants", it is "New Feature" or nothing. Of course, nothing forces existing developers to accept these new features; but the incredibly negative attitude on display when any new feature is suggested is not the way to grow a community. The correct way is a mentoring attitude -- offering opinions on how a new developer can get their idea in rather than telling them why it will never happen. > I don't see how dividing efforts between a 'bug fix' and 'development' > branch will help fix the project's critical needs. If we did, I think Again: that's not your call. People will work on what interests them. I've suggested a couple of features both here and on the forum and been shot down in varying degrees every time. Fine, but don't expect that I'm thinking "well I'll become an unpaid bug fixing grunt instead". I don't expect to be appointed head developer because I suggest an idea. I don't even expect anyone else to implement my idea for me. But why should I spend time on my own idea when the feedback is "no", "no", "we've already thought of that", "not needed", "go away", "why not fix some bugs instead"? I'm amazed that John Smith is as polite and persistent as he is looking at the amount of effort he's put in putting a pretty face on the train crash that existed before hand and seems to get no benefit of the doubt for his work. > there would be less pressure to help with the boring bug-fixing and > testing of the bug-fix branch, which I think would be bad. That pressure might be relieved if the community were able to grow a bit, and people felt they had a personal investment. That means loosening the reigns a bit; and perhaps a development branch would be the way to do that while not compromising code quality. I suggest a look at the way git itself is developed; it has the following branches: - master: the latest release + newly accepted features - maint: the latest release + bug fixes only - next: new features planned for inclusion, actively being worked on. Often created by merging "topic" branches from individual developers working on their current itch - pu: crazy stuff; not planned for inclusion, but acting as a staging area for people to show what they're working on Andy -- Dr Andy Parkins andyparkins@gmail•com ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Bitcoin-development] Change to multiple executables? 2011-08-10 19:32 ` Andy Parkins @ 2011-08-10 19:57 ` Jeff Garzik 2011-08-10 21:13 ` Andy Parkins 0 siblings, 1 reply; 26+ messages in thread From: Jeff Garzik @ 2011-08-10 19:57 UTC (permalink / raw) To: Andy Parkins; +Cc: bitcoin-development On Wed, Aug 10, 2011 at 3:32 PM, Andy Parkins <andyparkins@gmail•com> wrote: > People get itches and they want to scratch them. They aren't paid, so they > don't necessarilly want to turn up and be told which part they _should_ be > working on. The choice is not "bug fix that Gavin wants" or "new feature > that New Developer wants", it is "New Feature" or nothing. This is true -- though there is value to having a list of "things we think people should focus on" for the motivated, and for new people interested in tackling a project, but not sure what project to tackle. >> there would be less pressure to help with the boring bug-fixing and >> testing of the bug-fix branch, which I think would be bad. > > That pressure might be relieved if the community were able to grow a bit, > and people felt they had a personal investment. That means loosening the > reigns a bit; and perhaps a development branch would be the way to do that > while not compromising code quality. A centrally managed development branch on bitcoin/bitcoin.git is not the way to do it, however. See the description of linux-next, in my previous email, for a more distributed method which can easily be layered on top of the existing bitcoin dev structure by any motivated volunteer(s). Think distributed. :) The community does not need Linus's help (linux-next) or Gavin's help (bitcoin-next) to do this. linux-next became so widely used and useful that Linus requires almost all changes to be first staged in linux-next. -- Jeff Garzik exMULTI, Inc. jgarzik@exmulti•com ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Bitcoin-development] Change to multiple executables? 2011-08-10 19:57 ` Jeff Garzik @ 2011-08-10 21:13 ` Andy Parkins 2011-08-10 21:35 ` Jeff Garzik 2011-08-11 12:11 ` Mike Hearn 0 siblings, 2 replies; 26+ messages in thread From: Andy Parkins @ 2011-08-10 21:13 UTC (permalink / raw) To: Jeff Garzik; +Cc: bitcoin-development On Wednesday 10 August 2011 20:57:29 Jeff Garzik wrote: > > People get itches and they want to scratch them. They aren't paid, so > > they don't necessarilly want to turn up and be told which part they > > _should_ be working on. The choice is not "bug fix that Gavin wants" > > or "new feature that New Developer wants", it is "New Feature" or > > nothing. > > This is true -- though there is value to having a list of "things we > think people should focus on" for the motivated, and for new people > interested in tackling a project, but not sure what project to tackle. My objection is not that such a list exists, it is that potential new developers are, essentially, shouted down unless they are working on that list. I cannot imagine that many new developers arrive under those circumstances. > A centrally managed development branch on bitcoin/bitcoin.git is not > the way to do it, however. See the description of linux-next, in my > previous email, for a more distributed method which can easily be > layered on top of the existing bitcoin dev structure by any motivated > volunteer(s). I don't think I said anything about it being centrally managed. git lets us store these branches anywhere of course. The fact is that such a branch exists somewhere. > Think distributed. :) The community does not need Linus's help > (linux-next) or Gavin's help (bitcoin-next) to do this. linux-next I didn't say that it required anybody's help; but it does require a bit of willingess on the part of the master-branch-owning developers to import from that branch. > became so widely used and useful that Linus requires almost all > changes to be first staged in linux-next. They key thing with linux-next is that work done on it _does_ make it into the kernel. Tell me -- how many feature branches for bitcoin are just sitting as a pull request on github, and are now months old and abandoned out of disgust by their original authors? Here's another question: why is it that so many projects have "specially compiled" versions of bitcoin? Rhetorical question... it's because the official client doesn't do what they need, and won't accept their patches to add it (even optionally). I've only been watching this list for a few weeks (since the forum turned into an echo chamber); but I'm completely depressed by the agressive rejections of every new idea anyone raises. Don't believe me? Here's a list of ideas I've had "no, no, no"d so far; not one of which would have any financial implication at all. Only some of which would break backward compatibility. - Extra bits in the service field of the version message to allow nodes to indicate if they are mining; if they are willing to be seed nodes; if they relay transactions; if they want relayed transactions. - getblocks in reverse chronological order so clients can start up quicker while downloading the blocks in the backround. Ironically I was told "patches welcome" by someone who didn't reject this one instantly. - Remove verack, as it's completely unnecessary. - Query miners for pending transactions - Application version separate from client version - A way of requesting block bodies without headers (saving a lot of traffic for a thin client upgrading) - Double SHA-256 for a packet checksum? Seriously? - Sequence number as part of TxIn instead of part of the whole transaction - Script parameters should be stored outside the script, and reference by the script. All that ridiculous filtering of the scripts in OP_CHECKSIG would then go away. - MSG_DOUBLESPEND... nope - getblocks to accept MSG_TX and do something sensible Every single one of those has been shot down by one or more of the main developers. I'm not a genius, and not arrogant enough to assume that everything I say is right, but _nothing_? Really? There is no problem that one of the above addresses? Given that, what do I do? Hang around and get battered some more, or go away to my own little corner and work on my own implementation? You can imagine then that when I read moans about there not being enough new developers fixing bugs, that I am unsurprised and unsympathetic. I like bitcoin enough to hover on this list; and offer a view of your world from a potential developer who was chased away. Andy -- Dr Andy Parkins andyparkins@gmail•com ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Bitcoin-development] Change to multiple executables? 2011-08-10 21:13 ` Andy Parkins @ 2011-08-10 21:35 ` Jeff Garzik 2011-08-10 22:38 ` Andy Parkins 2011-08-11 12:11 ` Mike Hearn 1 sibling, 1 reply; 26+ messages in thread From: Jeff Garzik @ 2011-08-10 21:35 UTC (permalink / raw) To: Andy Parkins; +Cc: bitcoin-development On Wed, Aug 10, 2011 at 5:13 PM, Andy Parkins <andyparkins@gmail•com> wrote: > Don't believe me? Here's a list of ideas I've had "no, no, no"d so far; not > one of which would have any financial implication at all. Only some of > which would break backward compatibility. Breaking backwards compatibility means breaking people's access to their own money. If you remove an "unnecessary" step that existing nodes expect, then the cost of disrupting monetary access seems higher than the value of that breaking change. > - Extra bits in the service field of the version message to allow nodes > to indicate if they are mining; if they are willing to be seed nodes; > if they relay transactions; if they want relayed transactions. My own 'supernode' proposal also includes using the nServices bits. There's nothing fundamentally incompatible or wrong about that. > - Remove verack, as it's completely unnecessary. Compatibility issues? > - Query miners for pending transactions I could see value in querying a bitcoind node over JSON-RPC for pending transactions... and by extension, supporting that as an RPC on various miners' pool servers. Having a local dump of pending TX's would be useful. As an optional bitcoin P2P protocol command, available to anyone, seems to negatively impact privacy. > - Application version separate from client version Consensus has already approved this one, AFAIK. > - A way of requesting block bodies without headers (saving a lot of traffic > for a thin client upgrading) Do you mean headers without bodies? Gavin wants to work on headers-only, from what I've read, but others are welcome to contribute patches. > - Double SHA-256 for a packet checksum? Seriously? Compatibility issues? > - Sequence number as part of TxIn instead of part of the whole transaction Compatibility issues? > - Script parameters should be stored outside the script, and reference by > the script. All that ridiculous filtering of the scripts in OP_CHECKSIG > would then go away. Compatibility issues? > - MSG_DOUBLESPEND... nope Does consensus want this? > - getblocks to accept MSG_TX and do something sensible Link to elaboration of use case and need? > You can imagine then that when I read moans about there not being enough new > developers fixing bugs, that I am unsurprised and unsympathetic. I like > bitcoin enough to hover on this list; and offer a view of your world from a > potential developer who was chased away. Well, one unfortunate current aspect of bitcoin is... there seem to be problems aplenty right now :) However demotivating it may be, keeping the current system running must take priority over new features. I also heartily encourage others to do something I always want to do, but for lack of time: work on the design for bitcoin v2 ("theme: any breaking change is acceptable, it is a new block chain") There you may improve the protocol, get rid of the patent-cloudy ECDSA, use google's protocol buffers for encoding, make the proof-of-work algorithm memory-intensive, and other excellent, thoughtful breaking-change suggestions that have been made. Securing the integrity of money means that a lot of implementation decisions have been cemented into stone, however much we may personally dislike them. Backwards compatibility is paramount. -- Jeff Garzik exMULTI, Inc. jgarzik@exmulti•com ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Bitcoin-development] Change to multiple executables? 2011-08-10 21:35 ` Jeff Garzik @ 2011-08-10 22:38 ` Andy Parkins 2011-08-11 3:20 ` Jeff Garzik 0 siblings, 1 reply; 26+ messages in thread From: Andy Parkins @ 2011-08-10 22:38 UTC (permalink / raw) To: Jeff Garzik; +Cc: bitcoin-development On Wednesday 10 August 2011 22:35:01 Jeff Garzik wrote: > On Wed, Aug 10, 2011 at 5:13 PM, Andy Parkins <andyparkins@gmail•com> wrote: > > Don't believe me? Here's a list of ideas I've had "no, no, no"d so > > far; not one of which would have any financial implication at all. > > Only some of which would break backward compatibility. > > Breaking backwards compatibility means breaking people's access to > their own money. I wasn't actually giving a full explanation of how these things could be done, I was providing a list of "negatively received ideas"; imagine my surprise that they have been negatively received by you. However... The version number field combined with the massive complexity of: if( blockNumber > 500000 ) new_process(); else old_process(); Would sort all of your "compatibility" objections out, and would give nodes time to upgrade. > If you remove an "unnecessary" step that existing nodes expect, then > the cost of disrupting monetary access seems higher than the value of > that breaking change. If only there were some way of sending different things to different nodes, based on some sort of version number field. > > - Remove verack, as it's completely unnecessary. > > Compatibility issues? if( Version < VERSION_INTRODUCED ) sendVerack(); My point is that you are a clever guy; you are perfectly capable of coming up with these answers, but you don't want to. Nor does any other bitcoin developer. The protocol is perfect and there is no way of changing it. > > - Query miners for pending transactions > > I could see value in querying a bitcoind node over JSON-RPC for > pending transactions... and by extension, supporting that as an RPC on > various miners' pool servers. Having a local dump of pending TX's > would be useful. > > As an optional bitcoin P2P protocol command, available to anyone, > seems to negatively impact privacy. Eh? The transaction list is available on bitcoincharts. If my node had been connected it would have received that list anyway when each one was broadcast. What possible privacy loss could there be by making it possible to request it be repeated? Again though: the detail isn't the point. It's another half-hearted objection. > > - A way of requesting block bodies without headers (saving a lot of > > traffic for a thin client upgrading) > > Do you mean headers without bodies? Gavin wants to work on > headers-only, from what I've read, but others are welcome to > contribute patches. No; I mean being able to ask for just the block without the header. The reason being that a thin client might request blocks on demand... it's already got the header and doesn't need it again. The response: "it's only 80 bytes, blah, blah". 80*150000*N is a non- trivial amount of traffic. > > - Double SHA-256 for a packet checksum? Seriously? > > Compatibility issues? Only for the version message. But it would be trivial to do both types of checksum on the version message, and if either is true to accept the version message. After which the version is known and a much simpler checksum could be used for subsequent messages. Eventually the network would be upgraded enough that the old way can be dropped. Besides... hasn't TCP already got checksumming? Let's just stop checking the checksum. Or better still, stop calculating it and sending it. Double SHA-256 on every single message on every single node to create four checksum bytes is an enormous waste of CPU. > > - Sequence number as part of TxIn instead of part of the whole > > transaction > > Compatibility issues? If only there were a version field in the transaction and block structures. Again; casual rejection. > > - Script parameters should be stored outside the script, and reference > > by the script. All that ridiculous filtering of the scripts in > > OP_CHECKSIG would then go away. > > Compatibility issues? See above. > > - MSG_DOUBLESPEND... nope > > Does consensus want this? No, "consensus" doesn't. I was simply listing all the ideas that got rejected out of hand. The reason "consensus" doesn't think this one is necessary is because "we can already detect double spends by being widely connected"; ignoring the fact that a light or intermittently connected client would not be widely connected. But that's okay because "eventually payment processors will appear". Yep, my idea for fixing bitcoin is stupid because eventually someone else will mitigate it. > > - getblocks to accept MSG_TX and do something sensible > > Link to elaboration of use case and need? It was a few weeks ago; and it was an email from me about getblocks enhancements. It was patronisingly laughed off as being something that all you newbie "alternative client" writers go through. The use case is an on-demand thin client that wants to find the block that contains a particular transaction ID without downloading and indexing every single block in the chain. Additionally, _I_ plan to separate the block chain and wallet executables, so much so that the wallet executable doesn't necessarily need a local blockchain node and relies on a partially trusted remote -- it still wants to be able to do spot checks on that remote, and confirm whatever it's told. I would like to be able to do that using only commands that are in the official protocol; but I'm rapidly coming to accept that nothing I ask for will ever go in because there is no "use case". > Well, one unfortunate current aspect of bitcoin is... there seem to > be problems aplenty right now :) As with every project. However, the protocol is being treated as if it is some kind of holy scroll, and must not be touched. Bitcoin's ideas are revolutionary, its implementation is not. If we started again today, it would be done differently. Shouldn't we be trying to move the current protocol toward _that_ "done differently" as much as possible while bitcoin is still relatively small? Rhetorical again... I know the answer, it's "no". What exactly do the developers mean when they keep talking about bitcoin as "experimental"? It seems to me they mean "incredibly conservative, with no changes for the rest of time". > However demotivating it may be, keeping the current system running > must take priority over new features. Nothing I've suggested was to "stop the current system". I'm not even asking for developers to prioritise my ideas. I would just like mine, or anyone's ideas to not be instantly rejected out of hand. I mean for goodness sake, even "splitting into multiple executables" has been stomped on in this very thread. If something as trivial as that is "impossible" what chance is there that I would ever get "Change the 64-bit timestamp field to be microseconds since the epoch instead of seconds" in? > I also heartily encourage others to do something I always want to do, > but for lack of time: work on the design for bitcoin v2 ("theme: any > breaking change is acceptable, it is a new block chain") There you > may improve the protocol, get rid of the patent-cloudy ECDSA, use > google's protocol buffers for encoding, make the proof-of-work > algorithm memory-intensive, and other excellent, thoughtful > breaking-change suggestions that have been made. There is a popular idea that some other cryptocurrency will come along and displace bitcoin. It's not going to happen. Networking effects mean that there is no reason for people to change. I can just see the queue around the block now for bitcoin.2; identical in function to bitcoin except it "doesn't use ECDSA and the it uses protocol buffers on the wire, and uses more memory". Wow; there's a set of unique selling points. I'll get signs made. Let's be practical: technical-only improvements _have_ to be to bitcoin.1. Bitcoin's financial features are already complete or in progress; and it is financial features that would make people migrate to a competitor. Nobody is going to move to bitcoin.v2 because the source code has better comments. > Securing the integrity of money means that a lot of implementation > decisions have been cemented into stone, however much we may > personally dislike them. Backwards compatibility is paramount. I disagree about how set in stone these things are; but yeah; I've accepted that I'm on a loser. My list was to demonstrate how negative the community is; and you have confirmed that for me admirably. Bear that in mind the next time you're discussing the lack of manpower for bug fixes. Andy -- Dr Andy Parkins andyparkins@gmail•com ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Bitcoin-development] Change to multiple executables? 2011-08-10 22:38 ` Andy Parkins @ 2011-08-11 3:20 ` Jeff Garzik 2011-08-11 5:47 ` Andy Parkins 0 siblings, 1 reply; 26+ messages in thread From: Jeff Garzik @ 2011-08-11 3:20 UTC (permalink / raw) To: Andy Parkins; +Cc: bitcoin-development On Wed, Aug 10, 2011 at 6:38 PM, Andy Parkins <andyparkins@gmail•com> wrote: > On Wednesday 10 August 2011 22:35:01 Jeff Garzik wrote: > >> On Wed, Aug 10, 2011 at 5:13 PM, Andy Parkins <andyparkins@gmail•com> > wrote: >> > Don't believe me? Here's a list of ideas I've had "no, no, no"d so >> > far; not one of which would have any financial implication at all. >> > Only some of which would break backward compatibility. >> >> Breaking backwards compatibility means breaking people's access to >> their own money. > > I wasn't actually giving a full explanation of how these things could be > done, I was providing a list of "negatively received ideas"; imagine my > surprise that they have been negatively received by you. > > However... The version number field combined with the massive complexity of: > > if( blockNumber > 500000 ) > new_process(); > else > old_process(); > > Would sort all of your "compatibility" objections out, and would give nodes > time to upgrade. The above has been discussed on the forums. The community seems to consider that option one of last resort, because the consequences of -not- upgrading immediately become "I cannot access my money." The community also seems rather hard-wired against breaking changes like that, because it implies that we lowly dev peons are daring to mess with the Blessed Satoshi Design that has received extensive study, and 100% communal agreement. If the community changes its mind, and there are strong calls to make a breaking change, we can certainly do that. Bitcoin is not only open source but very much democratic -- people vote by choosing which client software to use. > However, the protocol is being treated as if it is some kind of holy scroll, > and must not be touched. Bitcoin's ideas are revolutionary, its > implementation is not. If we started again today, it would be done > differently. Shouldn't we be trying to move the current protocol toward > _that_ "done differently" as much as possible while bitcoin is still > relatively small? Rhetorical again... I know the answer, it's "no". Historically speaking, the protocol has had minor tweaks, if you check the patch history. Adding new protocol commands is pretty easy, for example. Removing commands tends to be high cost for low benefit ("protocol removes a harmless redundancy"), if you're messing with the initial negotiation sequence. IMO verack is not redundant, anyway. But the answer is "what do the users want" not "no" At the end of the day we're here to adequately reflect the needs of our userbase at all. And so far, the userbase seems highly conservative when it comes to incompatible changes. Correct me if I'm wrong... > I disagree about how set in stone these things are; but yeah; I've accepted > that I'm on a loser. My list was to demonstrate how negative the community > is; and you have confirmed that for me admirably. Bear that in mind the > next time you're discussing the lack of manpower for bug fixes. It's negative to weight costs vs. benefits? That is what I expect any good engineer to do. In any case, our -users- are not clamoring for breaking changes of the type you describe above, as far as I can see. Just the opposite. So if you want to deploy a breaking change, the burden is on you to convince the bitcoin users and miners that it's a good idea. If the bitcoin dev team is not accurately reflecting the desire of its users, then that should be corrected, and we want to hear feedback. -- Jeff Garzik exMULTI, Inc. jgarzik@exmulti•com ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Bitcoin-development] Change to multiple executables? 2011-08-11 3:20 ` Jeff Garzik @ 2011-08-11 5:47 ` Andy Parkins 2011-08-11 11:45 ` Joel Joonatan Kaartinen 0 siblings, 1 reply; 26+ messages in thread From: Andy Parkins @ 2011-08-11 5:47 UTC (permalink / raw) To: Jeff Garzik; +Cc: bitcoin-development On Thursday 11 August 2011 04:20:25 Jeff Garzik wrote: > > However... The version number field combined with the massive > > complexity of: > > > > if( blockNumber > 500000 ) > > new_process(); > > else > > old_process(); > > > > Would sort all of your "compatibility" objections out, and would give > > nodes time to upgrade. > > The above has been discussed on the forums. The community seems to > consider that option one of last resort, because the consequences of > -not- upgrading immediately become "I cannot access my money." The Did you even read what I wrote? "if( blockNumber > 5000000 )" is about as far from immediate as you can get. I'm not an idiot; I understand we can't lock people out of their money simply because of a software upgrade. It's not unreasonable to expect people will have upgraded by block 500000 though (or whatever number the community decided upon). Again you're missing my point... you are still shooting ideas down. > community also seems rather hard-wired against breaking changes like > that, because it implies that we lowly dev peons are daring to mess > with the Blessed Satoshi Design that has received extensive study, and > 100% communal agreement. Well the community had better unhardwire itself or its going to end up with five developers and no more. > If the community changes its mind, and there are strong calls to make > a breaking change, we can certainly do that. Bitcoin is not only open > source but very much democratic -- people vote by choosing which > client software to use. Voting with ones feet should be a last resort. Wouldn't it be better not to end up with incompatible clients out there? > Historically speaking, the protocol has had minor tweaks, if you check > the patch history. Adding new protocol commands is pretty easy, for > example. Removing commands tends to be high cost for low benefit > ("protocol removes a harmless redundancy"), if you're messing with the > initial negotiation sequence. IMO verack is not redundant, anyway. Client: I speak version 10 Server: hmmm, I don't speak version 10, I only speak version 5 Client: I am willing to lower to version 5 so I shall continue or Client: I speak version 10 Server: hmmm, I don't speak version 10, I only speak version 5 Client: I am unwilling to lower to version 5 so I shall hang up or Client: I speak version 5 Server: hmmm, I speak version 10, but I am willing to speak version 5 or Client: I speak version 5 Server: hmmm, I speak version 10, and I am unwilling to speak version 5 so I shall hang up 'verack' is redundant. It sends no information and merely says that the other end is willing to continue. Willing to continue is easily determined when the remote continues. Handling 'verack' is an annoyance, and adds nothing. > But the answer is "what do the users want" not "no" At the end of the > day we're here to adequately reflect the needs of our userbase at all. > And so far, the userbase seems highly conservative when it comes to > incompatible changes. Correct me if I'm wrong... Please point me at a single incompatible change that has been rejected by the userbase. Further: I'm not suggesting incompatible changes alone; that would be insane. I'm suggesting upgrade paths that delay incompatible changes until the change has propagated. > It's negative to weight costs vs. benefits? That is what I expect any > good engineer to do. I don't think that's what's happening. Not once have I seen the "benefits" side of that equation. What I have seen is plenty of "I can't see a use case for that"; when the key word in that sentence is "I". > In any case, our -users- are not clamoring for breaking changes of the > type you describe above, as far as I can see. Just the opposite. So > if you want to deploy a breaking change, the burden is on you to > convince the bitcoin users and miners that it's a good idea. The users aren't typically going to be familiar enough with the internals of bitcoin to care about many of the changes I suggested. I have repeatedly said I don't want to break anything, I want to transition in an orderly fashion (and the majority of my suggestions were backward compatible). But of course, I don't actually want to do anything with bitcoind itself, it's been made repeatedly clear to me that anything I might ask for is not going to happen -- and of course what I was pointing out, _not_ asking for, was that you can't expect to get new developers on board if they aren't going to be allowed to scratch their itches. > If the bitcoin dev team is not accurately reflecting the desire of its > users, then that should be corrected, and we want to hear feedback. You've just had some. The response was "you're wrong". Andy -- Dr Andy Parkins andyparkins@gmail•com ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Bitcoin-development] Change to multiple executables? 2011-08-11 5:47 ` Andy Parkins @ 2011-08-11 11:45 ` Joel Joonatan Kaartinen 2011-08-11 12:01 ` Christian Decker 2011-08-11 14:04 ` Andy Parkins 0 siblings, 2 replies; 26+ messages in thread From: Joel Joonatan Kaartinen @ 2011-08-11 11:45 UTC (permalink / raw) To: Andy Parkins; +Cc: bitcoin-development On Thu, 2011-08-11 at 06:47 +0100, Andy Parkins wrote: > Again you're missing my point... you are still shooting ideas down. And you're only shooting his actions down without indicating clearly what you think ought to be done instead. What do you want him to say instead? > > community also seems rather hard-wired against breaking changes like > > that, because it implies that we lowly dev peons are daring to mess > > with the Blessed Satoshi Design that has received extensive study, and > > 100% communal agreement. > > Well the community had better unhardwire itself or its going to end up with > five developers and no more. No way that will happen. A fork is going to happen sooner rather than later if this continues. It'd be great if it could be done within this project and named bitcoin-dev or bitcoin-next or similar. If this is not done, I wouldn't be surprised with the network splitting into 2 camps with different protocols but still working on the same blockchain. > > If the community changes its mind, and there are strong calls to make > > a breaking change, we can certainly do that. Bitcoin is not only open > > source but very much democratic -- people vote by choosing which > > client software to use. > > Voting with ones feet should be a last resort. Wouldn't it be better not to > end up with incompatible clients out there? There's no way to get the majority to vote with their feet to move to an incompatible client. Not immediately anyway. It can happen gradually though. As in: 1) alternative client is published that is compatible but extended. 2) this client gets the majority share of users/miners 3) they see this and decide to break compatibility. 4) original bitcoin client is now incompatible/history. > > It's negative to weight costs vs. benefits? That is what I expect any > > good engineer to do. > > I don't think that's what's happening. Not once have I seen the "benefits" > side of that equation. What I have seen is plenty of "I can't see a use > case for that"; when the key word in that sentence is "I". What is happening here is that most suggestions you point at have been discussed about before and so the "early adopter" developers remember that a decision about that was made already. However, the problem here lies with the fact that it's difficult to find the previous conversations. If there was a section in the wiki for recording past suggestions, there would be no need to say 'no'. You could instead say "We have discussed this before, please read..." and give them a link to the page with the relevant discussion. Of course, this would require actively forwarding people to the wiki for discussions and having them there. I think this would be a good idea. That would leave this list for discussing and coordinating the implementation of the changes that have been agreed on. For things that have already been discussed, you could try to find the previous discussion and add it there. But I expect for some things, new discussion needs to be had to get it on the wiki. - Joel ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Bitcoin-development] Change to multiple executables? 2011-08-11 11:45 ` Joel Joonatan Kaartinen @ 2011-08-11 12:01 ` Christian Decker 2011-08-11 14:04 ` Andy Parkins 1 sibling, 0 replies; 26+ messages in thread From: Christian Decker @ 2011-08-11 12:01 UTC (permalink / raw) To: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 4478 bytes --] On Thu, Aug 11, 2011 at 1:45 PM, Joel Joonatan Kaartinen < joel.kaartinen@gmail•com> wrote: > On Thu, 2011-08-11 at 06:47 +0100, Andy Parkins wrote: > > Again you're missing my point... you are still shooting ideas down. > > And you're only shooting his actions down without indicating clearly > what you think ought to be done instead. What do you want him to say > instead? > > > > community also seems rather hard-wired against breaking changes like > > > that, because it implies that we lowly dev peons are daring to mess > > > with the Blessed Satoshi Design that has received extensive study, and > > > 100% communal agreement. > > > > Well the community had better unhardwire itself or its going to end up > with > > five developers and no more. > > No way that will happen. A fork is going to happen sooner rather than > later if this continues. It'd be great if it could be done within this > project and named bitcoin-dev or bitcoin-next or similar. > I personally would welcome alternative clients as a vulnerability in the main client right now has the potential to kill the entire network. > > If this is not done, I wouldn't be surprised with the network splitting > into 2 camps with different protocols but still working on the same > blockchain. > Changes to the protocol are hard, mainly because hashes of packets are used to identify transactions and blocks, and even the target hash is a hash of a packet. As for your proposal to eliminate some parts of the protocol, I have to agree (the magic bytes seem an ugly hack by satoshi as I discussed with Mike, and the double SHA256 hashes as checksums are incredibly wasteful, and seem to have been chosen simply because a double hashing was already implemented). > > > > If the community changes its mind, and there are strong calls to make > > > a breaking change, we can certainly do that. Bitcoin is not only open > > > source but very much democratic -- people vote by choosing which > > > client software to use. > > > > Voting with ones feet should be a last resort. Wouldn't it be better not > to > > end up with incompatible clients out there? > > There's no way to get the majority to vote with their feet to move to an > incompatible client. Not immediately anyway. It can happen gradually > though. > > As in: 1) alternative client is published that is compatible but > extended. 2) this client gets the majority share of users/miners 3) they > see this and decide to break compatibility. 4) original bitcoin client > is now incompatible/history. > Changes should be implemented with backward compatibility in mind, even if it restricts the freedom of what can be changed. > > > > It's negative to weight costs vs. benefits? That is what I expect any > > > good engineer to do. > > > > I don't think that's what's happening. Not once have I seen the > "benefits" > > side of that equation. What I have seen is plenty of "I can't see a use > > case for that"; when the key word in that sentence is "I". > > What is happening here is that most suggestions you point at have been > discussed about before and so the "early adopter" developers remember > that a decision about that was made already. However, the problem here > lies with the fact that it's difficult to find the previous > conversations. > > If there was a section in the wiki for recording past suggestions, there > would be no need to say 'no'. You could instead say "We have discussed > this before, please read..." and give them a link to the page with the > relevant discussion. Of course, this would require actively forwarding > people to the wiki for discussions and having them there. I think this > would be a good idea. > Having a Wiki or a single Wikipage to list proposed changes, with all pro and cons, maybe pointing back to the original discussion would be nice. But don't forget that situations change, and features that have been shot down way back might become reachable/desirable at a later time, so please don't just use it as a method to shoot down ideas, but as a way to bring people up to speed and, if necessary, continue the discussion where it left. > > That would leave this list for discussing and coordinating the > implementation of the changes that have been agreed on. > > For things that have already been discussed, you could try to find the > previous discussion and add it there. But I expect for some things, new > discussion needs to be had to get it on the wiki. > > - Joel > - cdecker [-- Attachment #2: Type: text/html, Size: 5878 bytes --] ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Bitcoin-development] Change to multiple executables? 2011-08-11 11:45 ` Joel Joonatan Kaartinen 2011-08-11 12:01 ` Christian Decker @ 2011-08-11 14:04 ` Andy Parkins 1 sibling, 0 replies; 26+ messages in thread From: Andy Parkins @ 2011-08-11 14:04 UTC (permalink / raw) To: Joel Joonatan Kaartinen; +Cc: bitcoin-development [-- Attachment #1: Type: Text/Plain, Size: 1353 bytes --] On 2011 August 11 Thursday, Joel Joonatan Kaartinen wrote: > On Thu, 2011-08-11 at 06:47 +0100, Andy Parkins wrote: > > Again you're missing my point... you are still shooting ideas down. > > And you're only shooting his actions down without indicating clearly Yeah, shooting down a shooting down, which you've just shot down. Where will it end? > what you think ought to be done instead. What do you want him to say > instead? How about: "This is a good idea, but we don't want to break backward compatibility a little piece at a time. Instead we'd like to collect all such changes into one single compatibility breaking release. Here's the wiki page you should update; and here's the git branch you should push changes like this to." > most suggestions you point at have been discussed about before I know the application/protocol version split has been discussed before, but please point me to the relevant discussion on: loading the block chain in reverse; transaction only requests; checksumming removal; verack removal; storing script parameters outside the script; and requesting blocks by transaction hash instead of block hash. If I've missed all of these discussions and their inevitable logically indisputable rejection, I apologise. Andy -- Dr Andy Parkins andyparkins@gmail•com [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Bitcoin-development] Change to multiple executables? 2011-08-10 21:13 ` Andy Parkins 2011-08-10 21:35 ` Jeff Garzik @ 2011-08-11 12:11 ` Mike Hearn 2011-08-11 13:51 ` Andy Parkins 1 sibling, 1 reply; 26+ messages in thread From: Mike Hearn @ 2011-08-11 12:11 UTC (permalink / raw) To: Andy Parkins; +Cc: bitcoin-development I don't think Gavin misunderstands how open source works at all. It's completely normal for project maintainers to say "no" more often than they say "yes". When I worked on open source for a living this was part of the natural flow of things. It's important to understand that ideas which receive "maybe" or "yes but later" or "no unless you convince me" or "perhaps in a different way" are not being shot down. These answers are requests for more work to be done. You *cannot* get emotional about open source contributions and any veteran will tell you this. Open source maintainers cannot and do not say yes to every patch or idea that is proposed. I would be very worried if Gavin did. Now let's review these ideas: > Don't believe me? Here's a list of ideas > > - Extra bits in the service field of the version message to allow nodes > to indicate if they are mining; if they are willing to be seed nodes; > if they relay transactions; if they want relayed transactions. I think the concept is reasonable but service flags might not be the best way to do it, for instance, asking for a filtered transaction feed is useful for lightweight clients so you'd want more precision that can be fit into service bits. > - getblocks in reverse chronological order so clients can start up quicker > while downloading the blocks in the backround. Ironically I was told > "patches welcome" by someone who didn't reject this one instantly. I already told you this won't help startup time because you have to connect blocks together in sequence. You can't build up the block chain backwards unless you don't care about validation at all. > - Query miners for pending transactions Or just have them send an inv containing them after connect. I don't remember this one being "shot down". > - Application version separate from client version You mean separate from protocol version, right? > - A way of requesting block bodies without headers (saving a lot of traffic > for a thin client upgrading) The cost/benefit ratio of this one isn't obvious at all. The resource requirements for running a full node are large enough that re-downloading 80 bytes per block is the least of your worries if you're upgrading. > - Double SHA-256 for a packet checksum? Seriously? Feel free to submit a patch to disable checksum validation and see if Gavin accepts it. It needs to still be calculated at send time for other implementations. > - Sequence number as part of TxIn instead of part of the whole transaction Sequence numbers are already part of the tx inputs. Or do you mean they should be part of the whole transaction? If the latter then this is indeed an idea that will be shot down, it's deliberate that seqnums are part of the txinputs and it needs to be that way for contracts. It can't be changed without forking the protocol anyway. > Every single one of those has been shot down by one or more of the main > developers. I'm not a genius, and not arrogant enough to assume that > everything I say is right, but _nothing_? Really? There is no problem that > one of the above addresses? Some of your proposals address problems that need to be solved, but it's not clear that way is the right way to solve them. Others reflect either lack of understanding of the system or the fact that you don't value backwards compatibility whereas other people do. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Bitcoin-development] Change to multiple executables? 2011-08-11 12:11 ` Mike Hearn @ 2011-08-11 13:51 ` Andy Parkins 0 siblings, 0 replies; 26+ messages in thread From: Andy Parkins @ 2011-08-11 13:51 UTC (permalink / raw) To: Mike Hearn; +Cc: bitcoin-development [-- Attachment #1: Type: Text/Plain, Size: 10780 bytes --] On 2011 August 11 Thursday, Mike Hearn wrote: > I don't think Gavin misunderstands how open source works at all. It's > completely normal for project maintainers to say "no" more often than > they say "yes". When I worked on open source for a living this was > part of the natural flow of things. That wasn't the part I said he didn't understand. It was assuming that you can just declare that people should work on bug fixes and not features was a misunderstanding. People work on open source (at least at first) to get a feature they want. They aren't just going to show up and cry "command me lord". > It's important to understand that ideas which receive "maybe" or "yes > but later" or "no unless you convince me" or "perhaps in a different > way" are not being shot down. These answers are requests for more work > to be done. You *cannot* get emotional about open source contributions > and any veteran will tell you this. Open source maintainers cannot and > do not say yes to every patch or idea that is proposed. I would be > very worried if Gavin did. I don't expect them to; as I said, I'm not after everything I say being accepted out of hand, certainly as I haven't even turned up with patches. And you are absolutely correct that that would be worrying if it were so. What I object to is no guidance is offered to get the suggester what they want, a "you could have this if you did it like this", or "perhaps if you explained a bit more". It's just "no, your idea is based on your weak understanding of bitcoin," perhaps I'm being overly arrogant, but I think I understand it a lot more than you presume I do. I do try not to get emotional about these things; and email is not the best medium for conveying level of distress -- I'm certainly not banging on my keyboard, close to a heart attack. My motivation is only that I would like to see bitcoin do well, and I do see that the treatment of potential new people, while not offensive (nobody says f*ck off), is not encouraging. > Now let's review these ideas: Honestly you needn't have bothered. They've been reviewed to death at this point; and I'm not that interested in fighting to get them into a project that doesn't want them. I'll just play with my bricks over in the corner if that's okay? I offered the list as a demonstration that ideas don't get constructive help as to how progress can be made on them (i.e. how to make them acceptable), they just get rejected. Anyway; as you've put the time in, I'll do the same and respond. > > Don't believe me? Here's a list of ideas > > > > - Extra bits in the service field of the version message to allow nodes > > to indicate if they are mining; if they are willing to be seed nodes; > > if they relay transactions; if they want relayed transactions. > > I think the concept is reasonable but service flags might not be the > best way to do it, for instance, asking for a filtered transaction > feed is useful for lightweight clients so you'd want more precision > that can be fit into service bits. The service bits just seemed like the "bitcoin way" as the field already existed. Personally I would prefer an additional "capabilities" request with a variable number of ASCII strings in it, each indicating a capability, and if that's good with all of you -- excellent. > > - getblocks in reverse chronological order so clients can start up > > quicker while downloading the blocks in the backround. Ironically I was > > told "patches welcome" by someone who didn't reject this one instantly. > > I already told you this won't help startup time because you have to > connect blocks together in sequence. You can't build up the block > chain backwards unless you don't care about validation at all. I know you "told me this", but I think you are wrong. This is an example of the problem I'm trying to get across -- I see things differently; but rather than try and either fix my misunderstanding or see what I'm trying to achieve, it's rejected. I've already got it well on its way to being implemented is how I know you are wrong. It's perfectly possible to validate backwards because you are constructing a coherent chain based on an unvalidated start point. You then request the parent block and either (a) you finally reach the genesis block, you have reached a hard-coded valid point and the entire chain is therefore instantly validated or (b) you have a new start block, floating but validated to be part of the chain, if not absolutely validated. Further, with some checkpoints hard coded you don't even need to reach the genesis block to get a validated chain. The body of a block obviously can't be faked because of the Merkle hash. And finally... who says I care about validation? Perhaps I plan a situation where I implicitly trust the peer I'm talking to (which is exactly what I do plan). "There are more things in heaven and earth, Horatio, than are dreamt of in your philosophy". > > - Query miners for pending transactions > > Or just have them send an inv containing them after connect. I don't > remember this one being "shot down". I was told it had severe privacy implications; and you told me that it would be better to wait for some sort of filtering system that was planned, which I'd not heard of. I admit it wasn't exactly clear to me how what you described helped with my suggestion. Your suggestion here is a good alternative; but wouldn't it waste bandwidth? After all a receving node has no idea whether I have been connected to another node for 24 hours before I connect to it, and hence wouldn't need the list. > > - Application version separate from client version > > You mean separate from protocol version, right? Yep. I can well imagine that when alternative clients start appearing, some will have bugs. It will be very handy to either work around those bugs or simply deny version 1.4.17 of "Andy's Sexy Bitcoin Client" from connecting. Even just for monitoring network state it's useful. There is already talk, I see, of establishing how much of the network runs each released bitcoin version. > > - A way of requesting block bodies without headers (saving a lot of > > traffic for a thin client upgrading) > > The cost/benefit ratio of this one isn't obvious at all. The resource > requirements for running a full node are large enough that > re-downloading 80 bytes per block is the least of your worries if > you're upgrading. The benefit I'm aiming at is to imagine a thin client that has done a fast startup and only downloaded the headers. Then, it has a finite number of addresses it's interested in and wants to grab only the relevant bodies from the full chain. Or, fast startup is to grab all the headers, and then slowly grab the transactions from the blocks. The cost is if( !bodyOnly ) sendHeader(); sendBody(); I can't say I'm that invested in it; but it was another one for the list of "well I don't see what use that is" responses. > > - Double SHA-256 for a packet checksum? Seriously? > > Feel free to submit a patch to disable checksum validation and see if > Gavin accepts it. It needs to still be calculated at send time for > other implementations. I do feel free to write any patch I like. It's such a trivial patch though, that I feel certain you are being faceitous, knowing full well that it wouldn't be accepted. I'm trying to look five years in the future. I'm not suggesting it be turned off now -- that's impossible and I'm not an idiot. I'm trying to think of what the protocol should be and have a way of moving to that. The patch that is needed then is the one that makes the change gracefully. > > - Sequence number as part of TxIn instead of part of the whole > > transaction > > Sequence numbers are already part of the tx inputs. Or do you mean > they should be part of the whole transaction? If the latter then this > is indeed an idea that will be shot down, it's deliberate that seqnums > are part of the txinputs and it needs to be that way for contracts. It > can't be changed without forking the protocol anyway. The sequence number (and perhaps I've misunderstood) allows me to replace a transaction I've already submitted. I can't replace just one of the inputs, I have to replace the whole transaction. It's therefore the transaction that should have the sequence number. A signed transaction received with a higher sequence number should displace a lower one. I'm happy to accept that I have missed the use of the current sequence numbers in contracts. (To be fair, the wiki says "Transaction version as defined by the sender. Intended for "replacement" of transactions when information is updated before inclusion into a block.") Perhaps putting it in TxIn was because no one thought of having OP_PUSH_SEQUENCENUMBER as a script operator. > > Every single one of those has been shot down by one or more of the main > > developers. I'm not a genius, and not arrogant enough to assume that > > everything I say is right, but _nothing_? Really? There is no problem > > that one of the above addresses? > > Some of your proposals address problems that need to be solved, but > it's not clear that way is the right way to solve them. Others reflect > either lack of understanding of the system or the fact that you don't > value backwards compatibility whereas other people do. Of the above, only one could be lack of understanding (txIn). As to not valuing backward compatibility -- I certainly do. That shouldn't be used as an excuse to freeze the protocol forever. There are version fields in there, sensibly so; they should be used to fix problems. As I said a few times, the incompatible changes don't have to activate straight away, they can be delayed using the block number. Make it a block number four years away if you want, but the sooner those changes go in (whatever they may be), the more likely it is you'll get the majority of the network to change over. And once the alternative clients start appearing, the opportunity is gone -- if it's hard to get one client to change, imagine how hard it will be to change five. As I said above though, I don't want these fights. I know full well that what I want is not what you all want as far as client ideas go. I only started this response because I thought Gavin's "we don't want new developers for new features, we want bug fixes" was a bit of a foolish thing to say. Andy -- Dr Andy Parkins andyparkins@gmail•com [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Bitcoin-development] Change to multiple executables? 2011-08-10 18:41 ` Gavin Andresen 2011-08-10 19:32 ` Andy Parkins @ 2011-08-11 12:19 ` John Smith 2011-08-11 13:08 ` Pieter Wuille 1 sibling, 1 reply; 26+ messages in thread From: John Smith @ 2011-08-11 12:19 UTC (permalink / raw) To: Gavin Andresen; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 3726 bytes --] On Wed, Aug 10, 2011 at 6:41 PM, Gavin Andresen <gavinandresen@gmail•com>wrote: > > Well, to be honest I don't think more developers adding new features > are needed right now-- I think the project's critical needs are more > people testing and helping to fix bugs and scalability issues. > I do think to be an successful open source project we need more developers and more features. Activity is very important, it is kind of the lifeblood. Yes, a project will generally become more stable and slow in time as it nears "perfection" (or at least, a local optimum) but the current source is *far* from that. Yes -- bugs and scalability issues need to be addressed, but this will be a lot easier if some underlying problems are solved. And if we ignore the end users, they may run away and it becomes a pointless exercise. Taking the "long view" this includes build system, handling of threads/concurrency, modularization, pluggable DB and storage back-ends, separating the system into multiple "locked-down" processes, and so on. This can all be done while remaining P2P-compatible for as long as possible (we have versioning, don't we?). My proposal with multiple branches was about looking at the long view as well as the immediate firefighting. Yes, some changes might be riskier than others, but we can't just cargo-cult Satoshi's work forever... so with multiple branches, people can choose whether they have the balls to try something newer or just want to run the older version with the issues they know and love. It's better to be open. Look at Open Office, it only started to un-stagnate when it was forked out of Oracle's stranglehold. People want to work on these things, so why not? Until this is addressed, developers will prefer creating their own fork or even alternative client. After this UI stuff is handled I'll probably join up with one of them. > In this particular case, I said I was mildly against it-- if you want > me to switch to supporting it, then reassure me you're willing to do > ALL the work to make it happen. Send me a list of wiki pages you'll > edit to document the change and tell me that you'll be around to help > people rewrite their backup scripts. IMO this should have been your first reply, instead of first discourgaging me from doing it. Just make a list of what needs to be done. But I won't bother anymore... Let's just keep lumping everything in one executable. It's the Satoshi way. On Wed, Aug 10, 2011 at 7:32 PM, Andy Parkins <andyparkins@gmail•com> wrote: > Of course, nothing forces existing developers to accept these new features; > but the incredibly negative attitude on display when any new feature is > suggested is not the way to grow a community. The correct way is a > mentoring attitude -- offering opinions on how a new developer can get their > idea in rather than telling them why it will never happen. Exactly. My gripe is more about the negative attitude then anything else. The focus is always on the negative sides of every proposal, a bit of a climate of fear. I've had an employer that worked in the same way. Eternally hammering on "stability" the codebase, hiring 100's of extra developers, all firefighting and fixing immediate issues with "priority", the code became a minefield. Even with 8 hours of testcases, the overall structure of the code caused so many issues that customers feared every new release more. A classic negative feedback loop. I understand where it is coming from, many people just come and dump their "ideas" and never implement a line of code. But if people are actually proposing to implement something, or implemented it, they should IMO be given the benefit of the doubt. Not all outside ideas are bad. JS [-- Attachment #2: Type: text/html, Size: 4394 bytes --] ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Bitcoin-development] Change to multiple executables? 2011-08-11 12:19 ` John Smith @ 2011-08-11 13:08 ` Pieter Wuille 0 siblings, 0 replies; 26+ messages in thread From: Pieter Wuille @ 2011-08-11 13:08 UTC (permalink / raw) To: John Smith; +Cc: Bitcoin Dev On Thu, Aug 11, 2011 at 12:19:45PM +0000, John Smith wrote: > > In this particular case, I said I was mildly against it-- if you want > > me to switch to supporting it, then reassure me you're willing to do > > ALL the work to make it happen. Send me a list of wiki pages you'll > > edit to document the change and tell me that you'll be around to help > > people rewrite their backup scripts. > > IMO this should have been your first reply, instead of first discourgaging > me from doing it. Just make a list of what needs to be done. > > But I won't bother anymore... Let's just keep lumping everything in one > executable. It's the Satoshi way. I think there are a lot of misunderstandings here. Given your clarification that you simply wanted to remove the RPC client from the gui/daemon executable, I'm all for it. If I reread the answers, there is only "mild against" and a "no" that was based on a partial misunderstanding. Somehow it seems that many discussions in which some negative remarks were made just die out, and the person originally suggesting it takes this as a "shot down". Maybe (and that includes myself) we should be more outspoken about ideas we do like. As for the rest of this thread: i think some dev branch (either something linux-next like, or a separate official branch, or something else) is indeed very needed. The main tree should definitely be dealt with in a conservative way, but it's hard to make progress if you know that every patch that does some internal changes will need many rebasings and maintainance before it's actually merged and finally tested by some larger user base. Considering the issue of backward incompatible changes to the protocol: there is no denying that there are some serious deficiencies now (double sha256 checksums, the handling of the data being signed) and redundant things (magic bytes, verack). Yes, it is true that we could change these in the future with a (nBlocks >= X) test, but that would still mean you carry around both the old and the new code until at least block height X. Additionally, if you get another (better) idea that supercedes it somewhere between now and block X, you're still forced to first switch to the intermediate one, as some clients may not have upgraded... This is not to say this isn't an option we should consider, but for now, it just doesn't seem worth the hassle to me. There may come a day where we absolutely need a change to the protocol, and when we do, maybe it is time to fix all these "known and agreed upon defficiencies". It's definitely useful to discuss these, and in the context of "for when we do an incompatible change", no "breaks backward compatibility!" argument is valid. I'm in favor of wiki page where these are listed, together with pro and cons. -- Pieter ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Bitcoin-development] Change to multiple executables? 2011-08-10 17:45 ` John Smith 2011-08-10 18:41 ` Gavin Andresen @ 2011-08-10 18:43 ` Luke-Jr 2011-08-10 19:48 ` Jeff Garzik 1 sibling, 1 reply; 26+ messages in thread From: Luke-Jr @ 2011-08-10 18:43 UTC (permalink / raw) To: bitcoin-development On Wednesday, August 10, 2011 1:45:42 PM John Smith wrote: > 0.3.x -> small, compatible changes, bugfixes, like now > 0.4.x -> trunk, more impactful changes, refactorings, eventual major > release It seems there's room for some kind of "experimental" branch as well, including features that might not make it into any stable release (due to lack of use/interest or whatever). ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Bitcoin-development] Change to multiple executables? 2011-08-10 18:43 ` Luke-Jr @ 2011-08-10 19:48 ` Jeff Garzik 0 siblings, 0 replies; 26+ messages in thread From: Jeff Garzik @ 2011-08-10 19:48 UTC (permalink / raw) To: Luke-Jr; +Cc: bitcoin-development On Wed, Aug 10, 2011 at 2:43 PM, Luke-Jr <luke@dashjr•org> wrote: > On Wednesday, August 10, 2011 1:45:42 PM John Smith wrote: >> 0.3.x -> small, compatible changes, bugfixes, like now >> 0.4.x -> trunk, more impactful changes, refactorings, eventual major >> release > > It seems there's room for some kind of "experimental" branch as well, > including features that might not make it into any stable release (due to lack > of use/interest or whatever). In kernel land there exists "linux-next" Stephen Rothwell maintains a tree that is linux -tip, plus a list of trees & branches to pull from various individual developers. For example, linux-next pulls my SATA tree from libata-dev.git branch NEXT. Each developer is expected to publish changes they feel are ready for upstream. Developers are expected to "play nicely" and coordinate amongst themselves when two trees include conflicting changes. Trivial merge conflicts are handled by Stephen Rothwell, who does merging, build testing and such of the final set-of-N-trees result. More difficult merge conflicts are coordinated by the developers themselves, who work together to create a temporary "merge tree" that is then pulled by the linux-next maintainer. linux-next is the always moving, regenerated daily target where developers stage [in their opinion] upstream-ready changes. Thus Linus's linux.git development process really looks like the following, when linux-next is included in the picture: 1. Version X-1 is released, on day 0. 2. Merge window for version X opens, on day 0. 3. Linus pulls all changes that have seen testing in linux-next, over the -rc window (step #6, below) 4. Merge window closes, on day 7. 5. Version X-rc1 is released, on day 7. 6. Only bug fixes are accepted now (hopefully seen at least 24 hours of testing in linux-next, unless urgency demands otherwise). All new development is done in developer trees and branches, and is automatically published nightly in linux-next. 7. Version X is released, on day 90. Thus "upstream" stays almost constantly stable, except for the short 1-week merge window period, and linux-next comprises the rolling "development version" where new changes are staged. Note the subtle but important distinction between this and maintaining a strict 'bugfix' and 'development' branch system like John Smith described. The underlying linux-next dependent trees may be rebased at any time, and so linux-next is constantly regenerated, rather than being a cumulative history of choatic development. Major changes can and will be staged, de-staged, and re-staged during development, and maintaining a strict "official development branch" methodology is less flexible. Here is an example linux-next report. Stephen sends one, daily, with each linux-next tree generated: http://marc.info/?l=linux-next&m=131295044704945&w=2 As it applies to bitcoin, this "bitcoin-next" approach may simply be layered on top of the current methodology. All it requires is a volunteer who maintains this tree-of-trees, and wha-la: bitcoin has a development branch. -- Jeff Garzik exMULTI, Inc. jgarzik@exmulti•com ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Bitcoin-development] Change to multiple executables? 2011-08-10 9:36 [Bitcoin-development] Change to multiple executables? John Smith 2011-08-10 10:14 ` Matt Corallo @ 2011-08-10 21:37 ` Jeff Garzik 2011-08-11 13:50 ` Pieter Wuille 2 siblings, 0 replies; 26+ messages in thread From: Jeff Garzik @ 2011-08-10 21:37 UTC (permalink / raw) To: John Smith; +Cc: Bitcoin Dev On Wed, Aug 10, 2011 at 5:36 AM, John Smith <witchspace81@gmail•com> wrote: > In the current mainline client everything is lugged into one executable > (with an optional daemon-only one). I think this is a bad idea for various > reasons, and would propose something like: > > bitcoind: bitcoin daemon > bitcoin(-qt): bitcoin GUI executable > bitcoincl: bitcoin RPC command line > > By default, all three would be built. In non-GUI mode, only bitcoind and > bitcoincl are built (the names are obviously open for discussion). Seems reasonable to me. -- Jeff Garzik exMULTI, Inc. jgarzik@exmulti•com ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Bitcoin-development] Change to multiple executables? 2011-08-10 9:36 [Bitcoin-development] Change to multiple executables? John Smith 2011-08-10 10:14 ` Matt Corallo 2011-08-10 21:37 ` Jeff Garzik @ 2011-08-11 13:50 ` Pieter Wuille 2 siblings, 0 replies; 26+ messages in thread From: Pieter Wuille @ 2011-08-11 13:50 UTC (permalink / raw) To: Bitcoin Dev On Wed, Aug 10, 2011 at 11:36, John Smith <witchspace81@gmail•com> wrote: > All, > > In the current mainline client everything is lugged into one executable > (with an optional daemon-only one). I think this is a bad idea for various > reasons, and would propose something like: > > bitcoind: bitcoin daemon > bitcoin(-qt): bitcoin GUI executable > bitcoincl: bitcoin RPC command line Back on topic: I initially misunderstood your proposal. Let me reformulate, and suggest some names: * bitcoin-gui (or bitcoin-qt): always starts GUI, optionally starts RPC server, no RPC client * bitcoin-server: always starts RPC server, no RPC client, no GUI * bitcoin-client: always runs RPC client, no RPC server, no GUI Additionally, we could offer a script or symlinked executable with names "bitcoin" and "bitcoind" that detect whether RPC commands are present on the command line, and based on this invoke either bitcoin-server/bitcoin-gui or bitcoin-client (for backward compatibility). -- Pieter ^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2011-08-11 14:04 UTC | newest]
Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-08-10 9:36 [Bitcoin-development] Change to multiple executables? John Smith
2011-08-10 10:14 ` Matt Corallo
2011-08-10 10:26 ` John Smith
2011-08-10 10:43 ` Pieter Wuille
[not found] ` <CAJNQ0ssWeU2vgR8XmCyGiZ3UHPv=zjLZEKVM=gqP0ozSC7Wmiw@mail.gmail.com>
2011-08-10 13:18 ` John Smith
2011-08-10 16:49 ` Gavin Andresen
2011-08-10 17:45 ` John Smith
2011-08-10 18:41 ` Gavin Andresen
2011-08-10 19:32 ` Andy Parkins
2011-08-10 19:57 ` Jeff Garzik
2011-08-10 21:13 ` Andy Parkins
2011-08-10 21:35 ` Jeff Garzik
2011-08-10 22:38 ` Andy Parkins
2011-08-11 3:20 ` Jeff Garzik
2011-08-11 5:47 ` Andy Parkins
2011-08-11 11:45 ` Joel Joonatan Kaartinen
2011-08-11 12:01 ` Christian Decker
2011-08-11 14:04 ` Andy Parkins
2011-08-11 12:11 ` Mike Hearn
2011-08-11 13:51 ` Andy Parkins
2011-08-11 12:19 ` John Smith
2011-08-11 13:08 ` Pieter Wuille
2011-08-10 18:43 ` Luke-Jr
2011-08-10 19:48 ` Jeff Garzik
2011-08-10 21:37 ` Jeff Garzik
2011-08-11 13:50 ` Pieter Wuille
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox