On Fri, Jul 27, 2012 at 1:59 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, b
> shopping.
Good thing I can still spend, even with an incomplete blockchain :)
> but why do you also need to encrypt 2+ GB of public record?
1) I'm not seeing an option to split the wallet, debug log and other
privates pathwise from the blockchain.
2) Because encrypt everything is reasonable st
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 ch
> 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, but it was less than two days as
> that was the span be
On Fri, Jul 27, 2012 at 12:20 AM, grarpamp wrote:
> Update: this class of machine just became useless for bitcoin.
> When blk0002.dat was created to store more blocks, all forward
> progress processing blocks turned into losing ground by 20 or so
> a day. Guessing both datfiles were being accessed
Update: this class of machine just became useless for bitcoin.
When blk0002.dat was created to store more blocks, all forward
progress processing blocks turned into losing ground by 20 or so
a day. Guessing both datfiles were being accessed at once resulting
in disk based overload. I've not seen an
Meh, probably harmless, but...
As best I can tell, OP_RESERVED does absolutely nothing (a NOP).
CScript::IsPushOnly(...) counts this as a push operation.
--
Live Security Virtual Conference
Exclusive live event will cov
On Thu, Jul 26, 2012 at 7:27 AM, Mike Hearn wrote:
>> OP_CODESEPARATOR 14
>> OP_DEPTH 182
>
> I'm interested to see what scripts were using OP_DEPTH and
> OP_CODESEPARATOR, as the latter appears to be useless to my eyes.
>
> Could you give some tx ids which use unusual opcodes?
The OP_DEPTH are a
> OP_CODESEPARATOR 14
> OP_DEPTH 182
I'm interested to see what scripts were using OP_DEPTH and
OP_CODESEPARATOR, as the latter appears to be useless to my eyes.
Could you give some tx ids which use unusual opcodes?
--
L
9 matches
Mail list logo
