On Wednesday, December 21, 2011 12:17:57 PM Jeff Garzik wrote:
> On Wed, Dec 21, 2011 at 12:14 PM, Luke-Jr wrote:
> > On Wednesday, December 21, 2011 12:12:43 PM Jeff Garzik wrote:
> >> On Wed, Dec 21, 2011 at 11:45 AM, Luke-Jr wrote:
> >> > Accepted for 0.6:
> >> > * 81807c3 (pull 719) Coinbaser
On Wed, Dec 21, 2011 at 12:14 PM, Luke-Jr wrote:
> On Wednesday, December 21, 2011 12:12:43 PM Jeff Garzik wrote:
>> On Wed, Dec 21, 2011 at 11:45 AM, Luke-Jr wrote:
>> > Accepted for 0.6:
>> > * 81807c3 (pull 719) Coinbaser
>>
>> This is not "accepted" as discussed yesterday on IRC. You need to
I think it would be a lot more than that. According to the Scalability
page (https://en.bitcoin.it/wiki/Scalability) if Bitcoin took over all
credit card transactions, that would be about 1.14GB per block. I
believe that is 58.5PB per year. (6*24*365*1.14/1024) This would also
mean the distribu
On Wednesday, December 21, 2011 12:12:43 PM Jeff Garzik wrote:
> On Wed, Dec 21, 2011 at 11:45 AM, Luke-Jr wrote:
> > Accepted for 0.6:
> > * 81807c3 (pull 719) Coinbaser
>
> This is not "accepted" as discussed yesterday on IRC. You need to
> find buy-in from some other miners to make sure this
On Wed, Dec 21, 2011 at 11:45 AM, Luke-Jr wrote:
> Accepted for 0.6:
> * 81807c3 (pull 719) Coinbaser
This is not "accepted" as discussed yesterday on IRC. You need to
find buy-in from some other miners to make sure this is what "they"
want, rather than just what "you" want.
--
Jeff Garzik
exM
On Tuesday, December 20, 2011 8:46:41 PM Luke-Jr wrote:
> On Tuesday, December 20, 2011 3:49:16 PM Gavin Andresen wrote:
> > I've been busy pulling patches into git HEAD for a Bitcoin version
> > 0.6, with the goal of having a Release Candidate 1 out in a couple of
> > weeks.
>
> I've rebuilt my '
On Wednesday, December 21, 2011 6:50:47 AM Eric Lombrozo wrote:
> I've made a couple recent posts that were intended for the Protocol
> extensions thread but have been put in new threads. What part of the
> email message is used to identify the thread to which it belongs? I
> would have thought the
On Wednesday, December 21, 2011 5:12:07 AM Mike Hearn wrote:
> Git does not produce very helpful summaries when every commit is a merge.
> Is there a way to fix that? You have to guess what a change does based on
> the name of the topic branch currently.
Not sure what you mean. Maybe `git log --no
I find it likely that we will at some point have supernodes. If we have browser
based wallets then the server for these automatically becomes supernodes.
Further, if we move along that direction, it becomes much simpler to use both
the scheme I proposed or to use a a lot of other schemes for sha
I've made a couple recent posts that were intended for the Protocol
extensions thread but have been put in new threads. What part of the
email message is used to identify the thread to which it belongs? I
would have thought the subject, but apparently it isn't.
Is it just me or does it seem inevitable that at some point supernodes
will emerge that other nodes trust to validate transactions for them?
Supernodes needn't even store the entire block chain and transaction
pool...it would be sufficient that they keep lists of IP addresses of
other trustworthy n
Woohoo, 0.6.0 merging time!
I'll merge some GUI pull requests for 0.6.x this/next week.
Wladimir
On Tue, Dec 20, 2011 at 9:49 PM, Gavin Andresen wrote:
> FYI for anybody who doesn't hang out in IRC:
>
> I've been busy pulling patches into git HEAD for a Bitcoin version
> 0.6, with the goal of h
Thanks for this summary Luke.
Git does not produce very helpful summaries when every commit is a merge.
Is there a way to fix that? You have to guess what a change does based on
the name of the topic branch currently.
--
W
On 2011 December 21 Wednesday, Amir Taaki wrote:
> In the original intention for BIP_0014, that would map to:
>
> /Gecko:20110613/Firefox:6.0a2/Mozilla:5.0/
>
> With something like WebKit, it becomes easy to see why that would be
> useful. You can suddenly do a network wide scan of all browsers
DHTs and Bitcoin:
First, lets define the problem we want to solve: scalability - when bitcoin
takes over all credit card transactions (!), and even before that, we will meet
a scalability problem. The blockchain will grow rapidly, (1MB/10min or 50GB/yr)
and we will constantly have transactions
15 matches
Mail list logo
