Re: [bitcoin-dev] Weekly development meetings on IRC: schedule

There could not be a worse timing than this for those in China (3-4am), Japan/Korea (4-5am), and Australia (3-6am depends on which part of the country). Maybe we have no dev in this part of the planet? Is there any chance to review the timing in a weekly or monthly basis (also with a doodle

Re: [bitcoin-dev] Weekly development meetings on IRC: schedule

All, Current meeting time visualised globally. http://everytimezone.com/#2015-9-24,420,4ia jl, I think I found a good compromise: if the US want to accommodate Asia and willing to sacrifice preference, 23:00 to 00:00 UTC might work. http://everytimezone.com/#2015-9-24,660,4ia It isn't easy

[bitcoin-dev] Weak block thoughts...

I've been thinking about 'weak blocks' and SPV mining, and it seems to me weak blocks will make things better, not worse, if we improve the mining code a little bit. First: the idea of 'weak blocks' (hat tip to Rusty for the term) is for miners to pre-announce blocks that they're working on,

[bitcoin-dev] CI Build for Bitcoin - Some Basic Questions about Gitian and other stuff

Hi Folks. I'm trying my hand at creating a reproducible build of my own for bitcoin and bitcoin-XT, using TeamCity. I believe it is the best way to learn something: To try to build it yourself. Here is what I think I know so far, and I would love corrections, plus questions: 1. Bitcoin is

Re: [bitcoin-dev] CI Build for Bitcoin - Some Basic Questions about Gitian and other stuff

The builds made by Travis are for the purpose of making sure that the source code compiles and tests run successfully on all supported platforms. The binaries are not used anywhere else because Travis is not a trusted platform. The binaries on bitcoin.org are built using the gitian process and

Re: [bitcoin-dev] libconsensus and bitcoin development process

On Wed, Sep 23, 2015 at 1:49 AM, Dave Scotese wrote: > If I'm reading this situation correctly, Jeff is basically pointing out that > developers need more links (hooks, rungs, handholds, data points, whatever > you want to call them) so that they can see all the things

Re: [bitcoin-dev] CI Build for Bitcoin - Some Basic Questions about Gitian and other stuff

Thanks Mark. Is there a public server where the gitian builds can be viewed? Is there a public server that shows the quorum verifications or that shows how to join in on the verification if such as thing is helpful? On Wed, Sep 23, 2015 at 10:18 AM, Mark Friedenbach wrote:

Re: [bitcoin-dev] Weak block thoughts...

> On Sep 23, 2015, at 12:28 PM, Peter R wrote: > > Hi Gavin, > > One thing that's not clear to me is whether it is even necessary--from the > perspective of the block size limit--to consider block propagation. I didn't mention the block size limit; weak blocks are a good

Re: [bitcoin-dev] Weak block thoughts...

On Wed, Sep 23, 2015 at 4:43 PM, Gavin Andresen via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Imagine miners always pre-announce the blocks they're working on to their > peers, and peers validate those 'weak blocks' as quickly as they are able. > > Because weak blocks are

Re: [bitcoin-dev] [BIP Proposal] Version bits with timeout and delay.

On 9/13/2015 11:56 AM, Rusty Russell via bitcoin-dev wrote: '''Success: Activation Delay''' The consensus rules related to ''locked-in'' soft fork will be enforced in the second retarget period; ie. there is a one retarget period in which the remaining 5% can upgrade. At the that activation

Re: [bitcoin-dev] Weak block thoughts...

Thanks for the reply, Gavin. I agree on all points. Peter ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Weak block thoughts...

On Wed, Sep 23, 2015 at 4:07 PM, Bryan Bishop via bitcoin-dev wrote: > more recently: > http://gnusha.org/bitcoin-wizards/2015-09-20.log > http://diyhpl.us/wiki/transcripts/scalingbitcoin/roundgroup-roundup-1/ >

Re: [bitcoin-dev] CI Build for Bitcoin - Some Basic Questions about Gitian and other stuff

Well the gitian builds are made available on bitcoin.org. If you mean a build server where gitian builds are automatically done and made available, well that rather defeats the point of gitian. The quorum signatures are accumulated here: https://github.com/bitcoin/gitian.sigs (it's a manual

Re: [bitcoin-dev] Weak block thoughts...

On Wed, Sep 23, 2015 at 3:24 PM, Gregory Maxwell wrote: > On Wed, Sep 23, 2015 at 3:43 PM, Gavin Andresen via bitcoin-dev > wrote: > [...] > > A miner could try to avoid validation work by just taking a weak block > > announced by

Re: [bitcoin-dev] [BIP Proposal] Version bits with timeout and delay.

I say keep it simple. If the 75% threshold is hit, then support suddenly drops off below 50%, "meh" -- there will be a big ruckus, everybody will freak out, and miners will refuse to build big blocks because they'll worry that they'll get orphaned. Adding more complexity for a case that ain't

Re: [bitcoin-dev] CI Build for Bitcoin - Some Basic Questions about Gitian and other stuff

So who physically manually uploads the gitian build to bitcoin.org? On Wed, Sep 23, 2015 at 11:10 AM, Mark Friedenbach wrote: > Well the gitian builds are made available on bitcoin.org. If you mean a > build server where gitian builds are automatically done and made

[bitcoin-dev] Torrent-style new-block propagation on Merkle trees

As I understand it, the current block propagation algorithm is this: 1. A node mines a block. 2. It notifies its peers that it has a new block with an inv. Typical nodes have 8 peers. 3. The peers respond that they have not seen it, and request the block with getdata [hash]. 4. The node sends

Re: [bitcoin-dev] Weak block thoughts...

Gavin Andresen via bitcoin-dev writes: > I don't see any incentive problems, either. Worst case is more miners > decide to skip validation and just mine a variation of the > highest-fee-paying weak block they've seen, but that's not a disaster-- > invalid