Bit by bit, it's become clear that it's a bit much to worry even a
little bit that overloading the word bit would be every bit as bad
as a two bit horse with the bit between it's teeth that bit the hand
that feeds it, or a drill bit broken to bits after just a bit of use.
Aaron
There's no trick
+1(bit) for your bit on bits.
On 4/05/2014, at 2:18 pm, Aaron Voisine vois...@gmail.com wrote:
Bit by bit, it's become clear that it's a bit much to worry even a
little bit that overloading the word bit would be every bit as bad
as a two bit horse with the bit between it's teeth that bit
On Sun, May 4, 2014 at 8:15 AM, Aaron Voisine vois...@gmail.com wrote:
Bit by bit, it's become clear that it's a bit much to worry even a
little bit that overloading the word bit would be every bit as bad
as a two bit horse with the bit between it's teeth that bit the hand
that feeds it, or a
Wladimir,
what is missing is a decision to pull for the reference client.
Or did I missed that bit?
signature.asc
Description: Message signed with OpenPGP using GPGMail
--
Accelerate Dev Cycles with Automated
On Sun, May 4, 2014 at 8:36 AM, Tamas Blummer ta...@bitsofproof.com wrote:
Wladimir,
what is missing is a decision to pull for the reference client.
Or did I missed that bit?
No opinion - we'll follow whatever the rest does.
Wladimir
Thanks, that makes sense, just wanted to make sure this what the problem
was.
On Sun, May 4, 2014 at 6:15 AM, Jeff Garzik jgar...@bitpay.com wrote:
On Sat, May 3, 2014 at 2:04 PM, Flavien Charlon
flavien.char...@coinprism.com wrote:
Outputs are above dust, inputs are not spent. OP_RETURN is
On Sat, May 3, 2014 at 3:15 PM, Mark Friedenbach m...@monetize.io wrote:
Is it more complex? The current implementation using template matching
seems more complex than `if script.vch[0] == OP_RETURN
script.vch.size() 42`
Not much more complex.
The template matches a two-chunk script with
I will drink to that!
Bitte ein Bit! (A Bit please - aka Bitburger Beer)
Mike
Sent from my iPhone
On May 4, 2014, at 12:17 AM, Aaron Voisine vois...@gmail.com wrote:
Bit by bit, it's become clear that it's a bit much to worry even a
little bit that overloading the word bit would be every
If changing the structure of the block header, wouldnt you also need to
increment the version number to 3?
No, in this case I don't think so. Incrementing the version number has
two purposes:
1. inform old clients that something new is going on
2. be able to phase out old version numbers and
Although I agree 32 bits for a version is overkill, I really don't like the
idea of you simply ignoring the protocol spec to try and reduce your own
costs. Especially because in future we should make unknown versions a
validation rule, so we can easily trigger hard forks.
If this change was
On Sun, Apr 27, 2014 at 02:38:06AM -0700, Mark Friedenbach wrote:
I'm not convinced of the necessity of this idea in general, but if it
were to be implemented I would recommend serializing the nVersion field
as a VarInt (Pieter Wuille's multi-byte serialization format) and using
the remaining
On Sun, May 04, 2014 at 05:26:06PM +0200, Mike Hearn wrote:
Although I agree 32 bits for a version is overkill, I really don't like the
idea of you simply ignoring the protocol spec to try and reduce your own
costs.
The purpose of the proposal is to change the protocol spec, not to
ignore it.
On Fri, Apr 11, 2014 at 5:54 PM, Gregory Maxwell gmaxw...@gmail.com wrote:
For the non-error-coded case I believe nodes
with random spans of blocks works out asymptotically to the same
failure rates as random.
If each block is really 512 blocks in sequence, then each slot is more
likely to
13 matches
Mail list logo
