On Monday, August 29, 2011 4:10:01 PM Gavin Andresen wrote:
Other things on the 0.4 TODO list:
Can we get some form of the signmessage method in?
--
Special Offer -- Download ArcSight Logger for FREE!
Finally, a
to merge:
- base58_liberal_parsing
Again, these can all be merged with:
# git fetch git://gitorious.org/~Luke-Jr/bitcoin/luke-jr-bitcoin.git \
# branch name git merge FETCH_HEAD
--
Special Offer -- Download ArcSight
Got a fix for the encrypted-wallet mining issue:
- unique_coinbase
It depends on (and merges) the getwork_dedupe fix already common on pools and
other miners who pay attention to the latest mining fixes.
To merge:
git fetch git://gitorious.org/~Luke-Jr/bitcoin/luke-jr-bitcoin.git
On Thursday, September 08, 2011 1:33:15 PM John Smith wrote:
Be careful though, if you relay everything, it suddenly *does* have DDoS
potential...
Maybe require a proof-of-work then?
--
Doing More with Less: The Next
On Eligius, I have two bitcoinds running on the same system:
- a hub node, which is dedicated to relaying network activity between the
hundreds of nodes Eligius peers with
- a work node, which is dedicated to managing mining, and only ever connects
to the hub node
Lately, the hub node has
On Tuesday, September 13, 2011 10:43:27 AM Gavin Andresen wrote:
3) I'd really like to come to consensus on one or more
'multi-signature' standard transactions to enable much better wallet
backup and security.
More important in this area, IMO, is support for deterministic keychains in
Gavin, Jeff, et al:
A group of developers would be interested in maintaining 0.4 into the future
as a stable branch (ie, bugfixes only). Would you be willing to plan on making
the next mainline version after 0.4, being called 0.5, so we can release
0.4.1, 0.4.2, etc? If we prepare the git
What about this one?
@@ -1276,13 +1278,13 @@ bool CBlock::AcceptBlock()
// Get prev block index
mapuint256, CBlockIndex*::iterator mi =
mapBlockIndex.find(hashPrevBlock);
if (mi == mapBlockIndex.end())
-return error(AcceptBlock() : prev block not found);
+return
Please at least get Coinbaser merged for 0.5. It has had a lot of testing on
Eligius for months, a landslide of support for the new JSON-RPC method (as
requested), and I have even gone to the effort to document it. As I will no
longer be using bitcoind for Eligius soon, I have little incentive
On Monday, October 10, 2011 5:22:28 AM Mike Hearn wrote:
On Sun, Oct 9, 2011 at 1:12 AM, Luke-Jr l...@dashjr.org wrote:
As I will no longer be using bitcoind for Eligius soon
What will you be using instead? Isn't bitcoind a requirement for running a
pool?
Writing some custom software
On Monday, October 10, 2011 9:18:07 AM Mike Hearn wrote:
As I will no longer be using bitcoind for Eligius soon
What will you be using instead? Isn't bitcoind a requirement for
running
a
pool?
Writing some custom software designed to more efficiently create work.
To
On Thursday, October 13, 2011 9:32:48 AM Gavin Andresen wrote:
• Tighten up block-time rules to fix the potential timejacking attack.
Once again, this does not fix anything (they're already strict enough for the
2-week window), and just creates new problems.
• Work on 'discouraging'
On Wednesday, November 02, 2011 6:33:12 PM Amir Taaki wrote:
Satoshi 0.5
What is Satoshi 0.5 anyway? 0.5's server is bitcoind and GUI is Bitcoin-Qt;
the wx GUI client is gone, which is more or less what Satoshi referred to in
the past...
On Saturday, November 05, 2011 12:17:58 PM Christian Decker wrote:
Sorry for shooting this approach down, but I'm against it. User-agent
strings are an extremely bad idea as it would lead developers to start
making communication choices depending on the client type.
This can be necessary in
On Monday, November 07, 2011 10:02:43 AM Pieter Wuille wrote:
Maybe a short interval (1 minute? 10 minutes?) instead of a fixed
value could be allowed for the multiple-of-2016 blocks.
Reminder that there is *already* a short interval only allowed for blocks in
general...
As you noticed, we replaced most of the icons with license issues in
Bitcoin-Qt... but I intentionally did NOT replace the ones you created,
assuming you would be willing to relicense them under the MIT (or similar)
license. Could you commit a license change for these icons, ideally before
On Monday, November 21, 2011 8:06:27 PM Gavin Andresen wrote:
Finding the money to hire some professional QA people to help create
test plans and then execute them (the test plans, not the QA people)
is one possible answer.
Not prioritizing some unannounced release schedule over getting bugs
On Sunday, December 04, 2011 5:24:08 AM John Smith wrote:
I've also closed some issues that deal purely with Wx UI issues like this
one:
https://github.com/bitcoin/bitcoin/issues/425
I think my statement is valid, that we no longer support the old UI? Or
maybe some people want to take up
On Monday, December 12, 2011 3:56:01 PM Pieter Wuille wrote:
It seems base58 is actually quite terrible for producing nice
human-recognizable addresses, even though base58 is specially intended for
human usage. We'll just have to deal with it, or completely overhaul it
and move to a saner
FirstBits looks nice at glance, but is bound to create a gold-rush to grab
every nice-looking FirstBits address.
HTTPS is only as secure as the (centralized) CAs, thus not really any better
than TXT records.
I don't think an address of some form is avoidable.
On Monday, December 12, 2011 6:37:56 PM Jorge Timón wrote:
Would it be too strange to use namecoin?
This has the same problem as FirstBits, except .bit domains are dirt cheap,
whereas vanitygen at least slows down grabbing all the common words...
On Tuesday, December 13, 2011 8:06:15 AM Gavin Andresen wrote:
I agree with Mike Hearn and Christian Decker-- paying to
'someb...@foo.com' should become, behind the scenes, a HTTPS query to
https://foo.com/something. If you just want to (say) donate to
eff.org, then paying to '@eff.org' aught
On Wednesday, December 14, 2011 6:02:25 PM Rick Wesson wrote:
I also am largely in favor of using secured zones to publish TXT
records to digital currencies. I've been thinking mainly about TXT
using the following format for bitcoin.
_btc.lhs.rhs
Don't confuse BTC (Bitcoin unit) with BC
IMO, we should standardize and support public key addresses. While not ideal
for humans, because of their length, it's a better fit for large QR Codes IMO.
--
Learn Windows Azure Live! Tuesday, Dec 13, 2011
Microsoft is
I propose that full public key addresses be required to be compact (length
33), and use version 21 (begins with '4', and is redundant with ver 20 for 20-
byte data). Any reason this wouldn't be workable?
--
Learn Windows
On Sunday, December 18, 2011 9:28:36 AM Jorge Timón wrote:
Back on topic, is actually putting the whole pub key in each output
what you're proposing?
Yes, just like is already done for generation, since it is more efficient
*overall* for the block chain. sipa's key extraction is a MUCH better
On Sunday, December 18, 2011 8:14:20 PM Pieter Wuille wrote:
Furthermore, the embedded bitcoin address could be hidden from the user:
retrieved when first connecting, and stored together with the URI in
an address book. Like ssh, it could warn the user if the key changes
(which wil be ignored
On Monday, December 19, 2011 5:29:34 PM Gregory Maxwell wrote:
I've been arguing with Luke-JR on IRC about the interpenetration of
BIP_0014— Gavin's recent commit uses the same version string for the
GUI interface and the daemon mode.
Luke believes this is a _violation_ of BIP_0014
Mushoz makes a good point:
https://bitcointalk.org/index.php?topic=58450.msg695052#msg695052
Do we have enough downloads on 0.5.2rc1 to get the final rushed out and onto
the website?
--
RSA(R) Conference 2012
On Monday, January 16, 2012 7:46:39 PM Alan Reiner wrote:
In response to Jeff and Luke-Jr, I don't see how this is /just any other
poltical issue/. It strikes at the heart of everything Bitcoin is about.
Sorry, Bitcoin is not about the same thing to everyone. For me, Bitcoin is
about one
On Tuesday, January 17, 2012 2:42:51 AM Jorge Timón wrote:
It may be a political issue, but I don't think wikipedia becomes a
political organization for being against censorship.
This is not about left or right. Is about free speech, one of the
basic principles not only of freedom but also of
On Sunday, January 29, 2012 12:10:41 AM Amir Taaki wrote:
2 compressed pubkeys
2 compressed pubkeys are 33 bytes each. Add 1 bytes for the N (n-of-m), 1 byte
for the address version, and finally the 4 byte checksum, you get a total of
72 bytes. But these are *bytes* - to get an address, you
On Sunday, January 29, 2012 9:31:02 PM Pieter Wuille wrote:
The implementation is available in pull request 787
(https://github.com/bitcoin/bitcoin/pull/787), but there is certainly
need for testing, and room for improvements. Test reports, comments,
constructive criticism, suggestions and
On Monday, January 30, 2012 1:07:16 PM thoma...@gmx.de wrote:
I too support BIP21 over BIP20.
BIP 21 is not forwards-compatible, and is intentionally designed to be biased
toward decimal. BIP 20 is neutrally biased, forward-compatible, and has been
implemented for over a year now. If BIP 20 is
On Wednesday, February 01, 2012 9:18:32 AM Michael Grønager wrote:
libcoin is now in a state ready for its first release, which I would like
to share with you!
Looks interesting. However, it doesn't configure for me:
http://paste.pocoo.org/show/544135/
I noticed it's forked from bitcoind
On Wednesday, February 01, 2012 10:58:28 AM Michael Grønager wrote:
Your CMake cannot find boost - use ccmake or cmake-gui to help it with the
location.
I didn't see anything useful in ccmake. Boost is in the standard locations
(/usr/include/boost/ and /usr/lib/libboost*
Btw what platform
On Wednesday, February 01, 2012 11:20:22 AM Michael Grønager wrote:
OK - from your path it looks like linux. What version of Boost do you use.
I require 1.47 or 1.48. - I will change that, but it is quite handy for
signal_sets - will make an alternative scheme though.
Upgrading to 1.47 did not
On Thursday, February 02, 2012 8:46:05 AM Michael Grønager wrote:
Please test and feed back.
I found the problem: you are trying to use static libraries. Best practices
are to use shared libraries (except for specific scenarios like universal
Linux binaries) and most distros do not have static
On Thursday, February 02, 2012 5:43:07 PM Michael Grønager wrote:
Enabling dynamic libs was on my TODO, but on the
Redmond_OS_not_to_be_mentioned you need to : * prepend class definitions
with __declspec(dllexport) when you compile the dll * prepend class
definitions with __declspec(dllimport)
On Monday, February 06, 2012 10:54:25 AM Luke-Jr wrote:
769 : Make transactions with extra data in scriptSig non-standard
If this affects relaying, it will significantly harm the ability to replace
the current spammy green address scheme with a sensible extra signature
system. On the miner
On Tuesday, February 07, 2012 10:04:36 AM Luke-Jr wrote:
On Monday, February 06, 2012 10:54:25 AM Luke-Jr wrote:
769 : Make transactions with extra data in scriptSig non-standard
If this affects relaying, it will significantly harm the ability to
replace the current spammy green address
849 gavin/testnetmining
852 Fix #846. Allow negative options in bitcoin.conf
719 coinbaser
^^ next ^^
834 sje/BackupWallet
570 force_send
806 sipa/threadid
816 sipa/lameversion
^^ 037497c ^^
854 laanwj/2012_02_qtipc
841
On Wednesday, February 22, 2012 11:29:59 AM Michael Grønager wrote:
SCRIPT_ADDRESS_TEST = 196, (11000100) !!!
11xx - test network
xx00 - bitcoin
010y - p2sh
This fits...
PUBKEY_ADDRESS_TEST = 111, (0110) !!!
What Gavin said.
On Friday, March 02, 2012 1:51:41 PM Amir Taaki wrote:
It is a implementation-specific non-bitcoin-protocol proposal. My
understanding of BIPs is that they apply across bitcoin implementations
and largely focus on the most generic use-cases (like the URIs) and the
protocol. Things which affect
On Saturday, March 03, 2012 9:23:08 AM Stefan Thomas wrote:
From what I understand the BIP uses a polling model, e.g. a miner would
use getmemorypool to request new work from a pool in intervals. Would it
make sense to specify a version of the API supporting long polling?
You mean explicitly
On Saturday, March 03, 2012 10:05:58 AM Gavin Andresen wrote:
HTTP and JSON-RPC are a client-server model; there is no way for the
server to make calls to the client. It's not practical to expect clients
to run their own JSON-RPC server - many cannot listen on WAN ports at
all.
You're
On Saturday, March 03, 2012 6:51:34 PM Geir Harald Hansen wrote:
Long polling as currently implemented in pools has a race condition.
Does the miner reconnect first or does another block change happen
first? Double block changes are common with merged mining and I'm
doing all sorts of tricks
On Tuesday, March 13, 2012 2:06:38 PM Mike Hearn wrote:
https://github.com/bitcoin/bitcoin/pull/932 adds a pong message that
echoes back a 64 bit nonce contained in the ping, if the protocol
version is new enough.
The goal of this is to make it easier for clients, especially mobile
clients,
On Thursday, March 22, 2012 1:13:13 AM Eric Lombrozo wrote:
I would like to propose adding these callback hooks to the main
branch. I am willing to help locate these key points, reorganize the
code to place these methods in separate source files, define a callback
mechanism, and contribute
NOTE: I've been piecing this together for about a week now, and intended to
update it when 0.6.0 final was released, but with the timing of it, I just
won't get the time to update for a while, so here is my last draft...
It seems to me, there is potentially enough ready to merge into 0.7 to
On Monday, April 02, 2012 4:55:03 PM Alan Reiner wrote:
Any thoughts? (I have no doubts that there are :) )
IMO, the sign-request URI should be an extension on the existing bitcoin: URI
scheme; this way, sigNeeded can be omitted to imply sign with a sending
address.
On Tuesday, April 03, 2012 2:46:17 PM Gavin Andresen wrote:
We should avoid reinventing the wheel, if we can. I think we should
extend existing standards whenever possible.
I wonder if it's possible to make sigs compatible with PGP/EC ?
On Wednesday, May 02, 2012 9:22:42 AM Mike Hearn wrote:
The original software written by Satoshi Nakamoto, the project's founder.
This is just wrong. While Bitcoin-Qt is by far the best client, it is
Wladimir's, not Satoshi's.
If your computer is low powered or you aren't willing to tolerate
On Wednesday, May 02, 2012 12:21:13 PM grarpamp wrote:
Can someone also please set the reply-to header
for these lists. It's really annoying to hit reply and
not have the list address show up. Thanks :)
Try Reply to All
On Wednesday, May 02, 2012 3:34:35 PM Gary Rowe wrote:
Bitcoin-Qt
* Developed in C
This is far less relevant than license...
Armory
* Requires the entire blockchain
* Dependent client of Bitcoin-Qt
Or bitcoind?
Electrum
* Dependent client of Bitcoin-Qt (on server)
Dependent on
On Wednesday, May 16, 2012 6:18:27 PM Jeff Garzik wrote:
Instead of further overloading service bits in the version message, or
altering the version message, let us instead make feature discovery an
easy, flexible, extensible process.
We can add new commands without impacting older nodes, so
On Wednesday, May 16, 2012 6:38:28 PM Jeff Garzik wrote:
On Wed, May 16, 2012 at 2:29 PM, Luke-Jr l...@dashjr.org wrote:
That assumes you already have a connection to the peer in question.
As I understand it, the service bits are propagated as part of the
address, so you can see at a glance
On Thursday, May 24, 2012 4:33:12 PM Jeff Garzik wrote:
There appears to be some non-trivial mining power devoted to mining
empty blocks. Even with satoshi's key observation -- hash a fixed
80-byte header, not the entire block -- some miners still find it
easier to mine empty blocks, rather
On Thursday, May 24, 2012 4:33:12 PM Jeff Garzik wrote:
Comments? It wouldn't be a problem if these no-TX blocks were not
already getting frequent (1 in 20).
FWIW, based on statistics for Eligius's past 100 blocks, it seems 10% (1 in
10) of 1-txn blocks is not actually unreasonable. This also
On Friday, May 25, 2012 12:51:09 AM Jeff Garzik wrote:
On Thu, May 24, 2012 at 8:45 PM, Luke-Jr l...@dashjr.org wrote:
On Thursday, May 24, 2012 4:33:12 PM Jeff Garzik wrote:
Comments? It wouldn't be a problem if these no-TX blocks were not
already getting frequent (1 in 20).
FWIW
On Tuesday, May 29, 2012 3:05:18 PM Peter Vessenes wrote:
1) Germane to the original conversation, anything hard to implement will
not get implemented by miners.
Without my got-tired-of-waiting-for-someone-to-merge-it coinbaser branch,
anything modifying the coinbase is hard to implement.
2)
On Tuesday, May 29, 2012 3:28:56 PM Peter Vessenes wrote:
I don't understand what the 20 byte keyhash is. Can you elucidate?
20 byte keyhashes are a fundamental building block of the Bitcoin protocol.
ripemd160(sha256(ecdsaPubKey))
On Tuesday, May 29, 2012 3:36:34 PM Peter Vessenes wrote:
I suppose I mean that I don't understand how to reverse that into a URL
when one is presented only with a block, or perhaps a coinbase in a
transaction.
A new message can be added to the p2p relay network, similar to tx and alert
Analysis, comments, constructive criticism, etc welcome for the following:
==Background==
At present, an attacker can harm a pool by intentionally NOT submitting shares
that are also valid blocks. All pools are vulnerable to this attack, whether
centralized or decentralized and regardless of
On Monday, June 04, 2012 1:43:42 AM Peter Vessenes wrote:
Does it have asymmetric payoff for an attacker, that is, over time does it
pay them more to spend their hashes attacking than just mining?
That depends on the pool's reward scheme. Some complicated forms are capable
of getting bonus
Block 177618 was rejected by BIP16-enabled backports (0.4.x and 0.5.x) due to
containing a P2SH redemption with over 200 bytes in. Since the BIP16 code uses
IsPushOnly to check the scriptSig for compliance, and IsPushOnly in these
versions also enforced the 200-byte is standard rule, they were
On Saturday, June 16, 2012 11:39:00 PM Gregory Maxwell wrote:
On Sat, Jun 16, 2012 at 5:41 PM, Gavin Andresen gavinandre...@gmail.com
wrote:
RE: 0x06/0x07 'hybrid' public keys:
Any opinions? Forbidding it certainly makes alternative implementation
slightly easier in the future, but I'm not
On Sunday, June 17, 2012 11:04:42 PM grarpamp wrote:
https://github.com/bitcoin/bitcoin
https://git.gitorious.org/bitcoin/bitcoind-stable
The latter is Luke's backports of security and stability fixes to
otherwise unmaintained old versions.
Ah ok, coming from cvs/svn, it's a bit
FWIW, all this argumenting is why my original suggestion for a Clients list
focussed on objective information in alphabetical order.
--
Live Security Virtual Conference
Exclusive live event will cover all the ways
On Monday, July 16, 2012 11:47:02 PM Jeff Garzik wrote:
Vladimir does raise a fair point, though. Hackathon seems appropriate
for bitcoin.org as it is focused on dev-related activities. (full
disclosure: speaking at bitcoin2012.com) The conference might or
might not be. The conference does
On Friday, July 27, 2012 5:59:20 AM grarpamp wrote:
I now have an 1.8 ghz p3 celeron (128k cache) which should be
substantially slower than your machine, running vintage 2.6.20 linux.
Unfortunately I forgot to turn on timestamp logging so I don't know
how long it took to sync the chain,
On Sunday, July 29, 2012 10:17:51 AM Mike Hearn wrote:
I guess Gavin would be the final signer.
Considering that Gavin is not interested in participating in any way in the
stable versions, I would prefer to see someone else responsible for OS-vendor
signing.
On Monday, July 30, 2012 8:26:12 PM Amir Taaki wrote:
https://en.bitcoin.it/wiki/BIP_0022
Note that the Pooled Mining parts have already been moved to:
https://en.bitcoin.it/wiki/BIP_GMPPM
It just needs a number assigned (as the last part).
to enabled)
luke-jr https://github.com/bitcoin/bitcoin/pull/1431
11) MAYBE: getblocktemplate ('getmemorypool', post IRC debate)
luke-jr https://github.com/bitcoin/bitcoin/pull/936
+
+ m) getmemorypool: longpolling support
+ luke-jr https://github.com/bitcoin/bitcoin/pull/1355
+
+ m) Refactor
On Monday, September 10, 2012 3:07:52 PM Matthew Mitchell wrote:
Here is a BIP draft for improving the block relaying and validation so that
it can be done in parallel and so that redundancy can be removed. This
becomes more beneficial the larger the block sizes are.
On Sunday, October 14, 2012 8:52:33 PM Kyle Henderson wrote:
Given that sourceforge has shown to restrict access to a number of
countries at the request of the USA
This needs some clarification. If the USA has requested it, then presumably
there's some legality involved, and our US developers
On Tuesday, November 06, 2012 6:47:34 PM Gavin Andresen wrote:
Thursdays at 18:00 UTC (6PM Europe/1PM east US/10AM west US) seem to
be a good time for the core dev team to meet on the #bitcoin-dev
freenode IRC channel to chat.
I'd like to talk about:
o Can we put together a TODO list to
On Tuesday, November 06, 2012 7:56:23 PM slush wrote:
On Tue, Nov 6, 2012 at 7:13 PM, Luke-Jr l...@dashjr.org wrote:
But more important to the success of BIP today, I think, is encouraging
wider community participation.
It's not about BIP process, it's possibly about content of particular
On Monday, November 26, 2012 11:32:46 PM Gregory Maxwell wrote:
Obviously the state of the world with browsers is not that good... but
in our own UAs we can do better and get closer to that.
This effectively centralizes Bitcoin (at least in the eyes of many) and even
if each competing client
On Friday, February 08, 2013 11:49:09 PM Gavin Andresen wrote:
Windows builds are varying with every compile, and I think I finally
figured out why: we are not passing the -frandom-seed flag down into
the leveldb build (I used objdump to dump two different binaries, and
they differed only in
On Saturday, February 09, 2013 2:33:25 PM Timo Hanke wrote:
Why don't you use namecoin or another alt-chain for this?
Because namcoin tries to solve a different problem, DNS, whereas I want
to establish an identity for a payment protocol.
What is the technical difference here? Namecoin ties
On Monday, March 11, 2013 7:27:51 PM Rune K. Svendsen wrote:
From: Rune K. Svendsen runesv...@gmail.com
On the Main tab in the Options dialog, it previously said a minimum
fee of 0.01 is recommended. This amounts to about $0.50 at today's
price. Change this to 0.001 to be more sensible. We
On Monday, March 11, 2013 9:17:25 PM Rune Kjær Svendsen wrote:
On Mon, Mar 11, 2013 at 9:46 PM, Luke-Jr l...@dashjr.org wrote:
On Monday, March 11, 2013 8:34:52 PM Rune Kjær Svendsen wrote:
Ok. I'll fork on Github. Looking at the source, and some Qt
documentation,
it should
On Tuesday, March 12, 2013 7:03:54 AM Alan Reiner wrote:
I'm sure it won't be long before Slashdot and a variety of sources start
reporting on this event. Bitcoin has been in the media a lot lately, so
this story is likely to get some attention. The blowback of this event
is mostly
controversial changes.
I figured 2 MB in 2-3 years was fairly uncontroversial.
If not, let's scrap that idea for now.
Luke-jr, any chance in getting you to revise your proposal to narrow
the scope to things that don't need serious debate?
It was a one-time start the conversation proposal.
I expect what
clients *is by definition* a
hard fork.
Proposal:
1) Patch the pre-0.8 branches to support an increased lock count, whatever
number is required to make sure that this problem never shows up again at
the current block size (I defer to Luke-Jr and gmaxwell's numbers on this).
This is a hard fork
On Wednesday, March 13, 2013 6:01:02 PM Michael Gronager wrote:
Please note that it was not 0.8 that had issues, but 0.7(and downwards).
While 0.7 and earlier do have issues, they also define the Bitcoin protocol.
0.8's failure to comply with the protocol is an issue.
On Wednesday, March 13, 2013 6:27:13 PM Mark Friedenbach wrote:
Luke-Jr is suggesting that we add-to/modify the bitcoin protocol rules
which all verifying implementations must adhere to. I'm suggesting that we
instead change the old codebase to do what we expected it to do all along
(what 0.8
On Friday, March 15, 2013 5:06:20 PM Benjamin Lindner wrote:
On Mar 13, 2013, at 8:18 PM, Cameron Garnham da2...@gmail.com wrote:
For me, everyone signed up to bitcoin thinking that there was a 1MB /
block limit. The lock limits were unexpected, and could be considered
extremely
On Saturday, March 23, 2013 10:42:26 AM Randy Willis wrote:
Introducing super-nodes with thousands of connected peers can greatly help
here.
UDP is connectionless.
I would hope any UDP bitcoin protocol doesn't try to emulate a connection. :/
Luke
On Saturday, March 23, 2013 5:28:55 PM Jeff Garzik wrote:
On Sat, Mar 23, 2013 at 1:09 PM, Luke-Jr l...@dashjr.org wrote:
I don't think anyone is mining using bitcoind 0.7 or later?
slush, BTC Guild, ozcoin too I think, several others.
Not for producing coinbases (where BIP 34
On Saturday, March 23, 2013 5:47:46 PM Jeff Garzik wrote:
On Sat, Mar 23, 2013 at 1:43 PM, Luke-Jr l...@dashjr.org wrote:
On Saturday, March 23, 2013 5:28:55 PM Jeff Garzik wrote:
On Sat, Mar 23, 2013 at 1:09 PM, Luke-Jr l...@dashjr.org wrote:
I don't think anyone is mining using bitcoind
On Saturday, March 23, 2013 6:21:32 PM Jeff Garzik wrote:
On Sat, Mar 23, 2013 at 1:51 PM, Luke-Jr l...@dashjr.org wrote:
bitcoind is nowhere in the implementation of the miner end of BIP 34.
Again, not strictly true.
bitcoind's 'getblocktemplate' RPC call used by some supplies the block
On Sunday, April 14, 2013 5:09:58 AM Peter Todd wrote:
Currently signmessage/verifymessage only supports messages signed by a
single key. We should extend that to messages signed by n-of-m keys, or
from the users point of view, P2SH multisig addresses.
I think it would be wise to figure out HD
On Wednesday, May 22, 2013 2:20:22 PM Jeff Garzik wrote:
On Wed, May 22, 2013 at 10:12 AM, Melvin Carvalho
melvincarva...@gmail.com wrote:
On 22 May 2013 16:07, Jeff Garzik jgar...@exmulti.com wrote:
On Wed, May 22, 2013 at 6:27 AM, Melvin Carvalho
melvincarva...@gmail.com wrote:
On Saturday, May 25, 2013 3:36:46 AM Robert Backhaus wrote:
Here is the link to the FreeBSD build system 'port' that I am planning to
get committed when 0.8.2 is released. Any comments appreciated.
The Makefile mostly just applies the users request for GIU/QR/UPNP. The
major change is using
On Saturday, May 25, 2013 8:25:35 AM Melvin Carvalho wrote:
It might be an idea to have 'rule change' fixes and 'bug fix' releases go
out separately
Bitcoin is a consensus system. You can't run clients with different rules on
the same blockchain/network - it just won't work! Maybe we're now
On Thursday, May 16, 2013 10:02:05 AM bitcoingr...@gmx.com wrote:
One of the main goals will be to separate the wallet from the node, as we
have already done with mining.
How is this different from what Electrum has already done?
Luke
On Thursday, May 16, 2013 10:55:44 AM Addy Yeow wrote:
Is the number representing the count for the client nodes?
I was curious of the count myself earlier this week and started to
traverse down the network using getaddr message starting from seed
nodes and found upward to 57k nodes running
On Thursday, May 30, 2013 2:54:00 AM grarpamp wrote:
Should there not be a 0.8.2 branch laid down at 09e437b (v0.8.2)
in which the like of release build stoppers or critfixes such as d315eb0
are included... for those tracking that level of defect without
wishing to track all the growing post
1 - 100 of 164 matches
Mail list logo
