* [Bitcoin-development] Useful bitcoin patches...
@ 2011-07-01 3:23 Jeff Garzik
2011-07-01 16:03 ` Christian Decker
` (2 more replies)
0 siblings, 3 replies; 14+ messages in thread
From: Jeff Garzik @ 2011-07-01 3:23 UTC (permalink / raw)
To: Bitcoin Development
This was posted to IRC:
http://davids.webmaster.com/~davids/bitcoin-3diff.txt
Includes several useful features that all the big pools have been
screaming for... notably HTTP/1.1 keep-alive support.
--
Jeff Garzik
exMULTI, Inc.
jgarzik@exmulti•com
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [Bitcoin-development] Useful bitcoin patches... 2011-07-01 3:23 [Bitcoin-development] Useful bitcoin patches Jeff Garzik @ 2011-07-01 16:03 ` Christian Decker 2011-07-01 16:23 ` Gregory Maxwell 2011-07-01 16:25 ` Matt Corallo 2011-07-01 18:59 ` Luke-Jr 2011-07-10 18:42 ` Luke-Jr 2 siblings, 2 replies; 14+ messages in thread From: Christian Decker @ 2011-07-01 16:03 UTC (permalink / raw) To: Bitcoin Development [-- Attachment #1: Type: text/plain, Size: 1407 bytes --] Some appear to be beneficial to everybody. Multithreading the RPC will certainly speed up quite a few services and I see no downside in adding it. The same is true for Keep-Alive. I'm against including the long polling support because incredibly few people will benefit from it (pool providers) and yet it is included for everyone. The Hub mode is good, and I would go a step further and optimize the connection logic for all nodes by default. Just IMHO Regards, Chris On Fri, Jul 1, 2011 at 5:23 AM, Jeff Garzik <jgarzik@exmulti•com> wrote: > This was posted to IRC: > http://davids.webmaster.com/~davids/bitcoin-3diff.txt > > Includes several useful features that all the big pools have been > screaming for... notably HTTP/1.1 keep-alive support. > > -- > Jeff Garzik > exMULTI, Inc. > jgarzik@exmulti•com > > > ------------------------------------------------------------------------------ > All of the data generated in your IT infrastructure is seriously valuable. > Why? It contains a definitive record of application performance, security > threats, fraudulent activity, and more. Splunk takes this data and makes > sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-d2d-c2 > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > [-- Attachment #2: Type: text/html, Size: 2097 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Bitcoin-development] Useful bitcoin patches... 2011-07-01 16:03 ` Christian Decker @ 2011-07-01 16:23 ` Gregory Maxwell 2011-07-01 16:25 ` Matt Corallo 1 sibling, 0 replies; 14+ messages in thread From: Gregory Maxwell @ 2011-07-01 16:23 UTC (permalink / raw) To: Christian Decker; +Cc: Bitcoin Development On Fri, Jul 1, 2011 at 12:03 PM, Christian Decker <decker.christian@gmail•com> wrote: > Some appear to be beneficial to everybody. > Multithreading the RPC will certainly speed up quite a few services and I > see no downside in adding it. The same is true for Keep-Alive. The multithreaded RPC stuff will need very aggressive testing to make sure it doesn't expose race conditions elsewhere in the code. E.g. you don't want to lose change from a send because some txn called getnewaddress concurrently and there was a bug. So far the multithreaded RPC patches have pretty much only been run by miners... who have a different rpc profile than everyone else. (and the MT RPC that I've been using only multhreaded getwork…) > The Hub mode is good, and I would go a step further and optimize the > connection logic for all nodes by default. Gah. No. The 'hub mode' is not good. We're already low on sockets network wide, adding a built in DDOS mode flag to bitcoin that makes nodes aggressively connect to lots of neighbors is a bad idea. People will ignorantly enable it thinking they are adding resources to the network when they are really consuming much much more. I have a big fast node with a higher connection limit and the flood fixes and I'm currently seeing 596 inbound connections right now. This suggests the situation is already a lot worse than the rough numbers using lfnet connection counts suggested. Miners, concerned with fast block propagation, should manually addnode each other. We should fix the addnode logic so that it reserve connection slots for addnoded nodes and tries to keep connecting to them (or, alternatively, add a peernode flag for that behavior) currently addnode is oneshot. There is a lot of room for longer term improvements to the connection and forwarding logic, and I have a couple interesting ones I'm running on my nodes, but we don't really have any good way to test and validate changes, so I'm hesitant to publish them. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Bitcoin-development] Useful bitcoin patches... 2011-07-01 16:03 ` Christian Decker 2011-07-01 16:23 ` Gregory Maxwell @ 2011-07-01 16:25 ` Matt Corallo 1 sibling, 0 replies; 14+ messages in thread From: Matt Corallo @ 2011-07-01 16:25 UTC (permalink / raw) To: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 2066 bytes --] 1) Native Long Polling Support Not sure about this one, it would be useful, but preferably done once Bitcoin is cleaned up anyway. A probable good way would be a central notification interface which net, wallets, etc all connect to, including things like a pool server. Thus I'm not sure about merging something like this now. 2) A fix from Luke Dash Jr. His branch is at https://gitorious.org/~Luke-Jr/bitcoin/luke-jr-bitcoin/commits/getwork_dedupe and I would say it would be good to merge. gmaxwell indicated that hes been running this for a while and it is stable. 3) Hub Mode Why? We dont have enough nodes listening to begin with, this generates a ton of net usage on other listening nodes, which is not good. If you open up your ports, you will get just as many, if not more connections very easily. 4) RPC Turbocharge Yep, this is something that is needed, there is also the other asio pull request on github, not sure how/if these compare. 5) Resource Leak Fix Looks good to me. Matt On Fri, 2011-07-01 at 18:03 +0200, Christian Decker wrote: > Some appear to be beneficial to everybody. > Multithreading the RPC will certainly speed up quite a few services > and I see no downside in adding it. The same is true for Keep-Alive. > > I'm against including the long polling support because incredibly few > people will benefit from it (pool providers) and yet it is included > for everyone. > > The Hub mode is good, and I would go a step further and optimize the > connection logic for all nodes by default. > > Just IMHO > > Regards, > Chris > > > On Fri, Jul 1, 2011 at 5:23 AM, Jeff Garzik <jgarzik@exmulti•com> > wrote: > This was posted to IRC: > http://davids.webmaster.com/~davids/bitcoin-3diff.txt > > Includes several useful features that all the big pools have > been > screaming for... notably HTTP/1.1 keep-alive support. > > -- > Jeff Garzik > exMULTI, Inc. > jgarzik@exmulti•com [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Bitcoin-development] Useful bitcoin patches... 2011-07-01 3:23 [Bitcoin-development] Useful bitcoin patches Jeff Garzik 2011-07-01 16:03 ` Christian Decker @ 2011-07-01 18:59 ` Luke-Jr 2011-07-10 18:42 ` Luke-Jr 2 siblings, 0 replies; 14+ messages in thread From: Luke-Jr @ 2011-07-01 18:59 UTC (permalink / raw) To: bitcoin-development On Thursday, June 30, 2011 11:23:56 PM Jeff Garzik wrote: > This was posted to IRC: > http://davids.webmaster.com/~davids/bitcoin-3diff.txt > > Includes several useful features that all the big pools have been > screaming for... notably HTTP/1.1 keep-alive support. "Native Long Polling Support" should be renamed. Real native long polling would be for solo miners. "A fix from Luke Dash Jr." -- I have a branch with this; I didn't check that his version is up to date. "RPC Turbocharge" -- If this incorporates only my changes for multithreading, it breaks JSON-RPC over SSL. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Bitcoin-development] Useful bitcoin patches... 2011-07-01 3:23 [Bitcoin-development] Useful bitcoin patches Jeff Garzik 2011-07-01 16:03 ` Christian Decker 2011-07-01 18:59 ` Luke-Jr @ 2011-07-10 18:42 ` Luke-Jr 2011-07-10 19:12 ` Matt Corallo 2011-08-04 20:29 ` Luke-Jr 2 siblings, 2 replies; 14+ messages in thread From: Luke-Jr @ 2011-07-10 18:42 UTC (permalink / raw) To: bitcoin-development On Thursday, June 30, 2011 11:23:56 PM Jeff Garzik wrote: > This was posted to IRC: > http://davids.webmaster.com/~davids/bitcoin-3diff.txt > > Includes several useful features that all the big pools have been > screaming for... notably HTTP/1.1 keep-alive support. There seems to be a new version at: http://davids.webmaster.com/~davids/bitcoin-4diff.txt I haven't compared them yet. For the "3diff" version, I extracted and made proper git branches for each logical part: hub_mode threaded_rpc \-- rpc_keepalive (depends on threaded_rpc, or a single connection would keep the JSON-RPC interface locked up) signal_blk_notify (generic version of -pollpidfile, with a bugfix) bugfix_CreateThread_leak getwork_dedupe (original branch for my bugfix) In addition, I also consider these branches valid candidates for merging: coinbaser (popens a given command and reads coinbase outputs from stdout) gitignore (ignore some common misc files) minfee_modes (internal function changes to allow specifying different fees for relay, send, or accept-in-block) \-- eligius_relay (relay lower fees only Eligius will accept) \-- eligius_sendfee (send lower fees only Eligius will accept) txinfo (adds entries to getinfo for transactions accepted for relaying, transactions accepted for the current block-in-progress, and current block-in-progress size) bitcoinuri (compliant support for all bitcoin: URIs) All available from git://gitorious.org/~Luke-Jr/bitcoin/luke-jr-bitcoin.git ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Bitcoin-development] Useful bitcoin patches... 2011-07-10 18:42 ` Luke-Jr @ 2011-07-10 19:12 ` Matt Corallo 2011-07-10 20:30 ` Luke-Jr 2011-08-04 20:29 ` Luke-Jr 1 sibling, 1 reply; 14+ messages in thread From: Matt Corallo @ 2011-07-10 19:12 UTC (permalink / raw) To: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 4117 bytes --] On Sun, 2011-07-10 at 14:42 -0400, Luke-Jr wrote: > On Thursday, June 30, 2011 11:23:56 PM Jeff Garzik wrote: > > This was posted to IRC: > > http://davids.webmaster.com/~davids/bitcoin-3diff.txt > > > > Includes several useful features that all the big pools have been > > screaming for... notably HTTP/1.1 keep-alive support. > > There seems to be a new version at: > http://davids.webmaster.com/~davids/bitcoin-4diff.txt > I haven't compared them yet. > > For the "3diff" version, I extracted and made proper git branches for each > logical part: > hub_mode No, no, no, no, no. This has been discussed several times and provides little to no advantage for miners and has the potential to severely harm the network. > threaded_rpc > \-- rpc_keepalive (depends on threaded_rpc, or a single connection would > keep the JSON-RPC interface locked up) Some form of patch that implements these does need to be pulled soon, I would say 0.4.1 or maybe sooner. > signal_blk_notify (generic version of -pollpidfile, with a bugfix) Seems to be a feature for such a minority that until the codebase is cleaned a ton we shouldn't add features for small minorities. We have seen even one or two line patches cause regressions so I, personally, think we should really focus on cleaning the codebase (CWallet was a great start) and then add all these minority features once the backend stuff is really clean and efficient. > bugfix_CreateThread_leak Yes, should be in for 0.4 and I think there is a pull request for it. > getwork_dedupe (original branch for my bugfix) I think there is already a pull request, which should be merged for 0.4 IMO. > > In addition, I also consider these branches valid candidates for merging: > coinbaser (popens a given command and reads coinbase outputs from stdout) Seems like you are the only one who would benifit here, as noone else but eligius changes coinbase output to a random set. > gitignore (ignore some common misc files) > minfee_modes (internal function changes to allow specifying different fees > for relay, send, or accept-in-block) We don't need something that just generically changes the functions to allow whatever fee you want, we need something more generalized to allow more custom settings, not just blind accept if fee is x per kb or something. Sipa has suggested various things that should allow for more fee control by the users while still preventing users from sending transactions that lock their coins in limbo. > \-- eligius_relay (relay lower fees only Eligius will accept) > \-- eligius_sendfee (send lower fees only Eligius will accept) No, and no. Just because you are willing to accept lower fees doesn't mean the incentives are right to prevent DDoS. The fees aren't there to support the miners (not for a while, at least) they are there to prevent stupid users from DDoSing and just generally wasting everyone else's resources for no reason. > txinfo (adds entries to getinfo for transactions accepted for relaying, > transactions accepted for the current block-in-progress, and current > block-in-progress size) These are cool numbers to know, but I'm not sure if they have any real uses making them just useless feature creep. > bitcoinuri (compliant support for all bitcoin: URIs) URI support would be nice. > > All available from git://gitorious.org/~Luke-Jr/bitcoin/luke-jr-bitcoin.git > > ------------------------------------------------------------------------------ > All of the data generated in your IT infrastructure is seriously valuable. > Why? It contains a definitive record of application performance, security > threats, fraudulent activity, and more. Splunk takes this data and makes > sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-d2d-c2 > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Bitcoin-development] Useful bitcoin patches... 2011-07-10 19:12 ` Matt Corallo @ 2011-07-10 20:30 ` Luke-Jr [not found] ` <1310335963.2230.29.camel@Desktop666> 0 siblings, 1 reply; 14+ messages in thread From: Luke-Jr @ 2011-07-10 20:30 UTC (permalink / raw) To: bitcoin-development On Sunday, July 10, 2011 3:12:12 PM Matt Corallo wrote: > On Sun, 2011-07-10 at 14:42 -0400, Luke-Jr wrote: > > For the "3diff" version, I extracted and made proper git branches for > > each logical part: > > hub_mode > > No, no, no, no, no. This has been discussed several times and provides > little to no advantage for miners and has the potential to severely harm > the network. I just said it exists. I don't expect anyone to promote or merge it. > > In addition, I also consider these branches valid candidates for merging: > > coinbaser (popens a given command and reads coinbase outputs from > > stdout) > > Seems like you are the only one who would benifit here, as noone else > but eligius changes coinbase output to a random set. I suspect because they haven't figured out how. Take it or leave it. > > minfee_modes (internal function changes to allow specifying different > > fees for relay, send, or accept-in-block) > > We don't need something that just generically changes the functions to > allow whatever fee you want, we need something more generalized to allow > more custom settings, not just blind accept if fee is x per kb or > something. Sipa has suggested various things that should allow for more > fee control by the users while still preventing users from sending > transactions that lock their coins in limbo. This is a step in that direction, at least, by providing the mode as input. Since 0.4 is moving to Qt, perhaps moving GetMinFee to QtScript is appropriate. > > \-- eligius_relay (relay lower fees only Eligius will accept) > > \-- eligius_sendfee (send lower fees only Eligius will accept) > > No, and no. Just because you are willing to accept lower fees doesn't > mean the incentives are right to prevent DDoS. The fees aren't there to > support the miners (not for a while, at least) they are there to prevent > stupid users from DDoSing and just generally wasting everyone else's > resources for no reason. Again, take it or leave it, but in the meantime you're asking for trouble from users who feel they're being forced to pay more than they have to. Or perhaps rather than trouble, that decision will increase awareness of other clients that don't try to control the users. That could be good too. ^ permalink raw reply [flat|nested] 14+ messages in thread
[parent not found: <1310335963.2230.29.camel@Desktop666>]
[parent not found: <201107101846.09997.luke@dashjr.org>]
* Re: [Bitcoin-development] Useful bitcoin patches... [not found] ` <201107101846.09997.luke@dashjr.org> @ 2011-07-10 22:58 ` Matt Corallo 0 siblings, 0 replies; 14+ messages in thread From: Matt Corallo @ 2011-07-10 22:58 UTC (permalink / raw) To: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 1389 bytes --] On Sun, 2011-07-10 at 18:46 -0400, Luke-Jr wrote: > On Sunday, July 10, 2011 6:12:43 PM Matt Corallo wrote: > > On Sun, 2011-07-10 at 16:30 -0400, Luke-Jr wrote: > > > Again, take it or leave it, but in the meantime you're asking for trouble > > > from users who feel they're being forced to pay more than they have to. > > > Or perhaps rather than trouble, that decision will increase awareness of > > > other clients that don't try to control the users. That could be good > > > too. > > > > Its not a question of forcing users to pay anything, its a question of > > how best to solve the "Im just gonna throw random crap in the chain for > > the lulz" problem without causing too many side effects. As with many > > things Bitcoin, the temporary solution was something that was fairly > > quickly hacked together to solve the problem without causing too many > > problems. What needs to happen is an actual solution, Bitcoin, in > > theory, allows for all kinds of cool things, but the solution here needs > > carefully thought out and implemented, not just keep lowering the fees. > > The point is that we are already accepting lower fees. People (probably) want > to pay those lower fees. Yet there's developers writing their software to get > in the way between the user and pool willing to do business. Read what I wrote again, and don't reply off-list. [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Bitcoin-development] Useful bitcoin patches... 2011-07-10 18:42 ` Luke-Jr 2011-07-10 19:12 ` Matt Corallo @ 2011-08-04 20:29 ` Luke-Jr 2011-08-04 20:42 ` Luke-Jr ` (2 more replies) 1 sibling, 3 replies; 14+ messages in thread From: Luke-Jr @ 2011-08-04 20:29 UTC (permalink / raw) To: bitcoin-development Reminder these are still ready for merging... Jeff, you seem to have rewritten *part of* bugfix_CreateThread_leak and neglected to attribute the original author (as my branch did/does). > For the "3diff" version, I extracted and made proper git branches for each > logical part: > hub_mode > threaded_rpc > \-- rpc_keepalive (depends on threaded_rpc, or a single connection would > keep the JSON-RPC interface locked up) > signal_blk_notify (generic version of -pollpidfile, with a bugfix) > bugfix_CreateThread_leak > getwork_dedupe (original branch for my bugfix) > > In addition, I also consider these branches valid candidates for merging: > coinbaser (popens a given command and reads coinbase outputs from stdout) > gitignore (ignore some common misc files) > minfee_modes (internal function changes to allow specifying different > fees for relay, send, or accept-in-block) > \-- eligius_relay (relay lower fees only Eligius will accept) > \-- eligius_sendfee (send lower fees only Eligius will accept) > txinfo (adds entries to getinfo for transactions accepted for relaying, > transactions accepted for the current block-in-progress, and > current block-in-progress size) > bitcoinuri (compliant support for all bitcoin: URIs) > > All available from git://gitorious.org/~Luke-Jr/bitcoin/luke-jr-bitcoin.git ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Bitcoin-development] Useful bitcoin patches... 2011-08-04 20:29 ` Luke-Jr @ 2011-08-04 20:42 ` Luke-Jr 2011-08-04 23:43 ` Jeff Garzik 2011-09-03 15:27 ` [Bitcoin-development] Last try: Fixes for 0.4 Luke-Jr 2 siblings, 0 replies; 14+ messages in thread From: Luke-Jr @ 2011-08-04 20:42 UTC (permalink / raw) To: bitcoin-development On Thursday, August 04, 2011 4:29:01 PM Luke-Jr wrote: > Jeff, you seem to have rewritten *part of* bugfix_CreateThread_leak and > neglected to attribute the original author (as my branch did/does). My apologies. BlueMatt showed me how my comment here was wrong. Hopefully I'll remember how GitHub shows merges like this in the future. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Bitcoin-development] Useful bitcoin patches... 2011-08-04 20:29 ` Luke-Jr 2011-08-04 20:42 ` Luke-Jr @ 2011-08-04 23:43 ` Jeff Garzik 2011-08-05 3:01 ` Luke-Jr 2011-09-03 15:27 ` [Bitcoin-development] Last try: Fixes for 0.4 Luke-Jr 2 siblings, 1 reply; 14+ messages in thread From: Jeff Garzik @ 2011-08-04 23:43 UTC (permalink / raw) To: Luke-Jr; +Cc: bitcoin-development >> threaded_rpc >> \-- rpc_keepalive (depends on threaded_rpc, or a single connection would >> keep the JSON-RPC interface locked up) Definitely want _some_ path to HTTP/1.1 persistent connections, either this or async I/O, https://github.com/bitcoin/bitcoin/pull/214 Based on field usage, it sounds like the above, threaded rpc, is more stable. So my only question remaining, for which I've not yet reviewed the code, is: what is the behaviour under assault from lots of new incoming TCP connections? One very common problem with threaded TCP servers is blindly creating new threads without any filtering or checking of incoming connections, thereby quickly reaching thread limits, possibly causing other parts of the program to fail. Any amount of RPC request volume, miner or not, sent to the present implementation winds up using a lot of socket resources due to the constant disconnect/reconnect demanded of the current HTTP/1.0 code. This patch addresses that key issue, providing positive impact for all production bitcoin sites using RPC. Miners are hitting these problems now, and Gavin's right that mainnet miners are a small portion of the total population, but our RPC server implementation really is bloody awful at present. Reliable, production TCP servers use either threads or async I/O, or a combination of both (thread pool + async I/O == win). Deploying HTTP/1.1 persistent connections will make a positive impact at any site heavily using RPC. >> bugfix_CreateThread_leak Did I leave something out, when merging commit 67ed7d9d4929d8fe1c5f976c184c72dff02d83b7 Author: JoelKatz <DavidJoelSchwartz@GMail•com> Date: Mon Jul 25 15:06:45 2011 -0700 ? >> getwork_dedupe (original branch for my bugfix) I think we need this, but have not yet reviewed/thought about it. >> gitignore (ignore some common misc files) Sounds nice to have. Jeff P.S. I'm moving my home computer lab setup to a new house. Internet will be spotty until August 11, and you won't see much of me at all on #bitcoin-dev. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Bitcoin-development] Useful bitcoin patches... 2011-08-04 23:43 ` Jeff Garzik @ 2011-08-05 3:01 ` Luke-Jr 0 siblings, 0 replies; 14+ messages in thread From: Luke-Jr @ 2011-08-05 3:01 UTC (permalink / raw) To: Jeff Garzik; +Cc: bitcoin-development On Thursday, August 04, 2011 7:43:56 PM Jeff Garzik wrote: > >> bugfix_CreateThread_leak > > Did I leave something out, when merging > > commit 67ed7d9d4929d8fe1c5f976c184c72dff02d83b7 > Author: JoelKatz <DavidJoelSchwartz@GMail•com> > Date: Mon Jul 25 15:06:45 2011 -0700 > > ? Yes. I'm not sure it has any practical impact on the software, but there was what looks like a platform-specific compile fix (casting between potentially incompatible types) too. ^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bitcoin-development] Last try: Fixes for 0.4 2011-08-04 20:29 ` Luke-Jr 2011-08-04 20:42 ` Luke-Jr 2011-08-04 23:43 ` Jeff Garzik @ 2011-09-03 15:27 ` Luke-Jr 2 siblings, 0 replies; 14+ messages in thread From: Luke-Jr @ 2011-09-03 15:27 UTC (permalink / raw) To: bitcoin-development Once more before I just give up on trying... These branches fix bugs still remaining in 0.4rc1: - bugfix_getwork_newblk_race - getwork_dedupe - boost_fs3 - gitignore Additionally, this branch adds a tolerance to human error typing in base58 with ambiguous symbols, and should be very safe 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2011-09-03 15:27 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-07-01 3:23 [Bitcoin-development] Useful bitcoin patches Jeff Garzik
2011-07-01 16:03 ` Christian Decker
2011-07-01 16:23 ` Gregory Maxwell
2011-07-01 16:25 ` Matt Corallo
2011-07-01 18:59 ` Luke-Jr
2011-07-10 18:42 ` Luke-Jr
2011-07-10 19:12 ` Matt Corallo
2011-07-10 20:30 ` Luke-Jr
[not found] ` <1310335963.2230.29.camel@Desktop666>
[not found] ` <201107101846.09997.luke@dashjr.org>
2011-07-10 22:58 ` Matt Corallo
2011-08-04 20:29 ` Luke-Jr
2011-08-04 20:42 ` Luke-Jr
2011-08-04 23:43 ` Jeff Garzik
2011-08-05 3:01 ` Luke-Jr
2011-09-03 15:27 ` [Bitcoin-development] Last try: Fixes for 0.4 Luke-Jr
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox