On Monday, June 18, 2012 3:27:52 AM grarpamp wrote:
> So I get that github/master is the obvious top of things.
> But in looking at where the tags are between repositories,
> it's still not clear to me what the workflow is.
Workflow is all new development takes place in master during release windo
> be sure to have good backups that never touched the new code...
> We have at various times had bugs in master that would corrupt
> wallets
Sorry, that's to be expected, I shouldn't have asked.
> It would be very helpful if anyone offering bitcoin services would
> setup parallel toy versions of
Sorry for the duplication Amir, I meant to send this to everyone:
BitTorrent might be an example to look to here. It's a peer-to-peer network
that has undergone many significant protocol upgrades over the years while
maintaining compatibility. More recent clients have had the ability to
expose the
Right now we're seeing cases where block propagation is sometimes
taking minutes.
This doesn't cause much of a problem for general Bitcoin users but for
miners its problematic because it potentially increases the risk for
orphaning.
There are probably many contributing factors which can be improve
On Sun, Jun 17, 2012 at 7:04 PM, grarpamp wrote:
> Presumably the github/0.6.2 branch is safe for production?
0.6.2 is very widely used, more so than the other acceptably updated backports.
> What degree of caution about wallet eating should be
> made for those using github/master?
I can't spea
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
Hi Alberto,
Your thread was part of the inspiration for the idea that I proposed.
But as I read it more, I see that I originally misunderstood it
(mistaking it for a simpler unspent-TxOut tree idea). Even after
reading it, I'm not entirely clear how your proposal would work, but I
see that y
>> 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 different to find things.
There's something to be said for
Hi,
I did describe a very similar thing back in January (also illustrated,
and, if I'm not mistaken, more simple and efficient to recalculate),
and I wanted to do a prototype, but I have been very busy with other
projects since then.
https://en.bitcoin.it/wiki/User:DiThi/MTUT
I just saw Gavin le
On Sun, Jun 17, 2012 at 5:35 PM, grarpamp wrote:
>> It isn't inside the ifdef in bitcoin git master.
>
> Oh, hmm, well then, what is the difference or usage
> between these two repositories in regards to the project?
> Which one are the formal releases tagged (tbz's cut) in?
>
> Which one has the
> It isn't inside the ifdef in bitcoin git master.
Oh, hmm, well then, what is the difference or usage
between these two repositories in regards to the project?
Which one are the formal releases tagged (tbz's cut) in?
Which one has the branches with the commits that will
make it into the next fo
On Sun, Jun 17, 2012 at 02:39:28PM -0400, Alan Reiner wrote:
> All,
>
> With the flurry of discussion about blockchain compression, I
> thought it was time to put forward my final, most-advanced idea,
> into a single, well-thought-out, *illustrated*, forum post.
> Please check it out: https://bitc
All,
With the flurry of discussion about blockchain compression, I thought it
was time to put forward my final, most-advanced idea, into a single,
well-thought-out, *illustrated*, forum post. Please check it out:
https://bitcointalk.org/index.php?topic=88208.0
This is a huge undertaking,
As the only person to have created and maintaining a full reimplementation of
the Bitcoin protocol/standard, I do think Bitcoin is filled with arbitrary
endianness and magic numbers. However it is a tiny and simple protocol.
The big problem is not implementing the Bitcoin protocol, but the fact
On Sat, Jun 16, 2012 at 4:42 AM, Wladimir wrote:
> Which is a perfectly reasonable requirement. However, one could simply
> standardize what a 'thin client' and what a 'thick client' does and offers
> (at a certain version level), without having to explicitly enumerate
> everything over the protoc
On Sun, Jun 17, 2012 at 2:04 PM, Pieter Wuille wrote:
> On Sun, Jun 17, 2012 at 01:01:12PM +0200, Mike Hearn wrote:
> > > * 0x04 [32-byte X coord] [32-byte Y coord]: uncompressed format
> > > * 0x06 [32-byte X coord] [32-byte Y coord]: hybrid format for even Y
> coords
> > > * 0x07 [32-byte X coor
On Sun, Jun 17, 2012 at 01:01:12PM +0200, Mike Hearn wrote:
> > * 0x04 [32-byte X coord] [32-byte Y coord]: uncompressed format
> > * 0x06 [32-byte X coord] [32-byte Y coord]: hybrid format for even Y coords
> > * 0x07 [32-byte X coord] [32-byte Y coord]: hybrid format for odd Y coords
>
> So what
> * 0x04 [32-byte X coord] [32-byte Y coord]: uncompressed format
> * 0x06 [32-byte X coord] [32-byte Y coord]: hybrid format for even Y coords
> * 0x07 [32-byte X coord] [32-byte Y coord]: hybrid format for odd Y coords
So what's the actual difference in format? Is there any at all, or
it's just
On Sun, Jun 17, 2012 at 5:22 AM, grarpamp wrote:
> Well, detachdb doesn't appear in the -\? help
> because it's stuffed under pnp, which is not set
> in my build. please fix for people, tx :)
It isn't inside the ifdef in bitcoin git master.
(For future reference this sort of request is probably
Well, detachdb doesn't appear in the -\? help
because it's stuffed under pnp, which is not set
in my build. please fix for people, tx :)
#ifdef USE_UPNP
#if USE_UPNP
" -upnp\t " + _("Use Universal Plug and
Play to map the listening port (default: 1)") + "\n" +
#else
20 matches
Mail list logo
