Re: [bitcoin-dev] Scaling Bitcoin conference micro-report

[Eric Voskuil via bitcoin-dev]

On 09/18/2015 11:06 PM, NxtChg via bitcoin-dev wrote:
>> While to many of us that sounds crazy, if you're threat model assumes
>> Bitcoin is a legal/regulated service provided by a highly trusted
>> mining community it's a reasonable design.
>
> There is a large, grey area all the way to "legal/regulated service
> provided by a highly trusted mining community". Painting the worst
> looking picture is either a defect in thinking or intentional FUD.

The state is the threat in the Bitcoin threat model. You comments below
acknowledge it. The assumption of hostile state actors is the only
rational starting point. That which is regulated (and regulatable) in
Bitcoin is the attack surface.

While of course there are various degrees of weakness, the reference to
"legal/regulated service provided by a highly trusted mining" as the
threat is by no means irrational or misdirecting. This threat represents
the difference between Bitcoin and Fedcoin.

I found Mike's threat model downright disturbing. All benefits of
Bitcoin arise from its resistance to this threat. Anyone investor in
this space should be paying attention... the apparent benefits of
Bitcoin will vaporize with regulation.

>> Mike Hearn recently posted his threat model, which specifically
>> argues we should assume governments are not a threat.
>
> There are two ways to fight governments:
>
> 1. either you become too big to close, so political repercussions
> become unacceptable

This is extremely naive. At a minimum, getting popular/successful (and
regulated) is the formula for regulatory capture.

> 2. or you become too tiny to hunt, in which case you are much better
> off with a specialized alt-coin, designed specifically for that
> purpose.

I assume you are referring some marginal and largely irrelevant effort.

False dichotomy.

[cross-posted to libbitcoin]



signature.asc
Description: OpenPGP digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Scaling Bitcoin conference micro-report

[NxtChg via bitcoin-dev]

>While to many of us that sounds crazy, if you're threat model assumes
>Bitcoin is a legal/regulated service provided by a highly trusted mining
>community it's a reasonable design.

There is a large, grey area all the way to "legal/regulated service provided by 
a highly trusted mining community".

Painting the worst looking picture is either a defect in thinking or 
intentional FUD.


> Mike Hearn recently posted his threat model, which specifically argues we
> should assume governments are not a threat.

There are two ways to fight governments:

1. either you become too big to close, so political repercussions become 
unacceptable

2. or you become too tiny to hunt, in which case you are much better off with a 
specialized alt-coin, designed specifically for that purpose.

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Fill-or-kill transaction

[Jorge Timón via bitcoin-dev]

How them being expensive to generate make them less likely to be reorged?
Would an op_return output used as a nonce to make the hash of the
transaction contain some proof of work make the non-coinbase expirable
transaction more secure against reorgs?
I'm afraid your point is irrelevant.
On Sep 19, 2015 4:01 AM, "Luke Dashjr"  wrote:

> On Thursday, September 17, 2015 7:14:38 PM Jorge Timón via bitcoin-dev
> wrote:
> > As Mark points out this can be made safe by requiring that all the
> outputs
> > of a transaction that can expire have op_maturity/csv/rcltv of 100. That
> > makes them as reorg-safe as coinbase transactions.
>
> Not quite as safe. Remember that mined bitcoins have not only a 100-block
> maturity requirement, but *also* are expensive to generate.
> Mere OP_CHECKMATURITYVERIFY (aka rcltv) has no cost to use...
>
> Luke
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Jorge Timón via bitcoin-dev]

I disagree with the importance of this concern and old soft/hardforks will
replace this activation mechanism with height, so that's an argument in
favor of using the height from the start. This is "being discussed" in a
thread branched from bip99's discussion.
Anyway, is this proposing to use the block time or the median block time?
For some hardforks/softforks the block time complicates the implementation
(ie in acceptToMemoryPool) as discussed in the mentioned thread.
On Sep 19, 2015 1:24 AM, "Rusty Russell"  wrote:

> Jorge Timón via bitcoin-dev 
> writes:
> > I agree on using height vs time. Rusty, what do you mean by being easier
> > for bip writers? How is writing "block x" any harder than writing "date
> y".
>
> Three years from drafting is reasonable.  How many blocks is that?  Hmm,
> better make it 6 years of blocks just in case we have a hash race.
>
> Deployment speed is measured in months, not blocks.  It's hard enough to
> guess without adding another variable.
>
> Cheers,
> Rusty.
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Hash of UTXO set as consensus-critical

[Justus Ranvier via bitcoin-dev]

On 18/09/15 15:17, Rune Kjær Svendsen via bitcoin-dev wrote:
> Bitcoin does not function if the majority of mining power is dishonest. There 
> is no way around that. It’s how proof-of-work functions.


None of those statements are true.

If a majority of Bitcoin miners are mining invalid blocks, then they
aren't Bitcoin miners any more and are no longer relevant to the Bitcoin
consensus.

There does exist a problem that light clients aren't always able to tell
the difference between chains that are valid and chains that are not
valid, but it's is possible to create simple proofs that would do so:

https://gist.github.com/justusranvier/451616fa4697b5f25f60


If those changes would be implemented, then any node that knew a chain
was invalid could produce a compact proof that anyone else in the
network could verify, regardless of how much proof of work was used to
create the invalid chain.

Committed UTXO sets would need safe to rely upon if a similar set of
proofs that a particular set was invalid existed.

-- 
Justus Ranvier
Open Bitcoin Privacy Project
http://www.openbitcoinprivacyproject.org/
jus...@openbitcoinprivacyproject.org
E7AD 8215 8497 3673 6D9E 61C4 2A5F DA70 EAD9 E623


0xEAD9E623.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Fill-or-kill transaction

[Luke Dashjr via bitcoin-dev]

On Thursday, September 17, 2015 7:14:38 PM Jorge Timón via bitcoin-dev wrote:
> As Mark points out this can be made safe by requiring that all the outputs
> of a transaction that can expire have op_maturity/csv/rcltv of 100. That
> makes them as reorg-safe as coinbase transactions.

Not quite as safe. Remember that mined bitcoins have not only a 100-block 
maturity requirement, but *also* are expensive to generate.
Mere OP_CHECKMATURITYVERIFY (aka rcltv) has no cost to use...

Luke
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Scaling Bitcoin conference micro-report

[Peter Todd via bitcoin-dev]

On Fri, Sep 18, 2015 at 08:06:23PM +, Matt Corallo via bitcoin-dev wrote:
> I did not intend to imply that there was agreement on a desire to
> schedule a second hardfork. My wording may have been a bit too loose.
> Instead, I believe there was much agreement that doing a short-term
> hardfork now, with many agreeing that a second would hopefully be
> entirely unnecessary/impossible, while others thought that a second
> would be necessary and would have to happen. While this may set up a
> similar controversy again in several years, I think everyone agreed that
> we cannot predict the future and I, personally, think none of us should
> be committing to a viewpoint for what should be done at that time.
> 
> Personally, I think it is also critical that there be no messaging that
> people should rely on or assume there will be a future increase after a
> short-term bump (which I also do not believe people should be relying on
> now).

Agreed!

We still seem to be in a possition where there is fundemental
disagreements about the threat model we should design for, and
ultimately, what we want Bitcoin to be. For instance, yesterday I was on
a blocksize panel, and Valery Vavilov - CEO of the ASIC manufacturer and
miner BitFury - stated that he thought we needed to setup a system of
large, high-bandwidth, high-powered, Bitcoin nodes at institutions such
as universities and large companies to allow the Bitcoin blocksize to be
raised multiple orders of magnitude. (e.g. hundreds of megabytes, or
even multiple gigabytes) In discussion with him he seemed to expect that
we'd have just a few hundred Bitcoin nodes at most, with SPV being the
standard way of using Bitcoin.

While to many of us that sounds crazy, if you're threat model assumes
Bitcoin is a legal/regulated service provided by a highly trusted mining
community it's a reasonable design. Mike Hearn recently posted his
threat model, which specifically argues we should assume governments are
not a threat. (and Hearn has previously argued that the design of
Bitcoin assumes a majority of miners are "honest" rather than merely
economically rational) Similarly Gavin Andresen was also on that panel,
and stated that he believes the idea that Bitcoin has O(n^2) scaling is
wrong, implying he doesn't think a large % of the Bitcoin user base will
continue to run fully validating nodes. (note that there are other
possibilities he could be referring to here, although again with
different security assumptions and/or unproven tech)

The main objection I raised during the committer/contributor discussions
to the idea of a "short term bump" was messaging. I think it's fair to
say that nearly all the support for a small blocksize increase stemmed
from the (perceived) need to give Bitcoin users and Bitcoin
infrastructure some more time to adapt to a world where the blocksize
does not grow sufficiently to meet demand, resulting in higher
transaction fees and the practical requirement to use the Bitcoin
blockchain more efficiently. (or of course the development of genuinely
scalable blockchain technology) With that in mind, it's important that
we properly communicate that fact, or as Hearn replied, we'll run into
the same problem all over again in a few years, but with even less
safety margin in the system.

My second objection was one of science. Any bump should be accompanied
by some kind of model describing scientifically what we were trying to
achieve and where the numbers chosen came from. For instance, Pieter
Wuille's BIP103 proposes 17% per year based on a bandwidth growth model,
the assumption that bandwidth is the bottleneck we're trying to keep
constant, and the design criteria to keep centralization roughly
constant. (all else being equal) Sure there's lots of potential flaws in
that proposal, but the _message_ that we're basing it on science rather
than political "horse-trading" is very important.

As for the disagreements, it's quite likely that we can't come to
genuine consensus in the fact of those fundemental disagreements about
what Bitcoin should be. I don't have any good way to resolve that, and
I'm open to suggestions!

-- 
'peter'[:-1]@petertodd.org
00da942d1651d405c157821a3fa55bd0c11cd9b39321e574


signature.asc
Description: Digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Dave Scotese via bitcoin-dev]

I am in a timezone that uses DST (currently PDT), but I would like us to
use a timezone that does NOT use DST.  It will be nice to have something
that reflects the seasonal patterns like my own body does.  I hate the time
change in both ways.

On Fri, Sep 18, 2015 at 2:50 PM, Luke Dashjr via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Friday, September 18, 2015 8:24:50 PM Btc Drak via bitcoin-dev wrote:
> > Google calendar is localised, so it doesn't matter. The problem with
> > quoting UTC anyway it the meeting times are going to change for those
> that
> > observe DST. It would be much better to quote an actual timezone of an
> > actual area so it will remain constant, like 1700 CEST, or 0900AM PDT for
> > example. Otherwise when the clocks change, what was a convenient meeting
> > time will become inconvenient for some.
>
> Not everyone does crazy clock-changing. Using such a time system for
> scheduling seems to inconvenience the wrong position. (although perhaps
> arguably better since most people probably use DST) :p
>
> (Aside, if Google Calendar can't support standard UTC, that sounds like an
> argument against using Google Calendar...)
>
> > Urgh... Can we hardfork time? It's clearly in need of an upgrade...
>
> Tonal time works nice any consistently. :D
>
> Luke
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>



-- 
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy  and Meme Racing
 (in alpha).
I'm the webmaster for The Voluntaryist  which
now accepts Bitcoin.
I also code for The Dollar Vigilante .
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

[Rusty Russell via bitcoin-dev]

Mark Friedenbach via bitcoin-dev 
writes:
> Eric, that would be, I think, my sequencenumbers2 branch in which nSequence
> is an explicit relative lock-time field (unless the most significant bit is
> set). That has absolutely clear semantics. You should comment on #6312
> where this is being discussed.

Indeed.  Simplicity wins.  We have half the number space left for the
future, too.  If people are paranoid, reserve the top *two* bits.

Thanks,
Rusty.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Rusty Russell via bitcoin-dev]

Tier Nolan via bitcoin-dev  writes:
> On Wed, Sep 16, 2015 at 9:19 PM, Rusty Russell 
> wrote:
>> You need a timeout: an ancient (non-mining, thus undetectable) node
>> should never fork itself off the network because someone reused a failed
>> BIP bit.
>>
>
> I meant if the 2nd bit was part of the BIP.  One of the 2 bits is "FOR" and
> the other is "AGAINST".  If against hits 25%, then it is deemed a failure.
>
> The 2nd bit wouldn't be used normally.  This means that proposals can be
> killed quickly if they are obviously going to fail.

This could be added if we approach one failed soft fork every 5 weeks,
I guess (or it could be just for specific soft forks).

Cheers,
Rusty.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Rusty Russell via bitcoin-dev]

Tier Nolan via bitcoin-dev 
writes:
> The advantage of enforcing the rule when 75% is reached (but only for
> blocks with the bit set) is that miners get early notification that they
> have implemented the rule incorrectly.They might produce blocks that
> they think are fine, but which aren't.

Indeed.  There are three believable failure possibilties:

1) You don't implement the rule at all, and don't set the bit.
2) You implement it and set bit, but think some valid block is invalid.
3) You implement it and set bit, but think some invalid block is valid.

#1 is by far the most common, and the proposal is designed so they
*always* get ~2 weeks warning before those drop to SPV security.

Assuming the mining majority isn't buggy (otherwise, it's arguably not a
bug but a feature!) #2 is the worst case: some miners fork off and don't
rejoin.

So there is a slight advantage in doing this early: those buggy miners
no longer contribute to the 95% threshold.  But that's outweighed IMHO
by:

1) We would need another delay at 75% so #1 nodes can upgrade.

2) The new feature won't be exercised much before impliciation, since
   it's useless before then, so it might not find bugs anyway.

In conclusion, I'm not convinced by the extra complexity.

Cheers,
Rusty.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Rusty Russell via bitcoin-dev]

Jorge Timón via bitcoin-dev  writes:
> I agree on using height vs time. Rusty, what do you mean by being easier
> for bip writers? How is writing "block x" any harder than writing "date y".

Three years from drafting is reasonable.  How many blocks is that?  Hmm,
better make it 6 years of blocks just in case we have a hash race.

Deployment speed is measured in months, not blocks.  It's hard enough to
guess without adding another variable.

Cheers,
Rusty.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Scaling Bitcoin conference micro-report

[Mike Hearn via bitcoin-dev]

Any change that results in this happening all over again in a few years
does not have consensus.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Hash of UTXO set as consensus-critical

[Vincent Truong via bitcoin-dev]

This way lets us protect from 51% overwrites for a whole year:

1. Hash utxo set as is today, H1, and store it in a block.
2. At the same time, store a copy of the utxo set for H1 on disk, D1
3. After 1 year, create D2, then wait for H2 (if a fork happens then
recreate D2 and see which wins)
4. The block with H2 must hash on top of H1
4. Blocks before H1 can be safely pruned by the network, only keeping D1
for reference/validation, plus blocks the node wants to keep (data/colored
coins)
5. After 1 year, repeat for H3.
7. D1 can also be dropped after a few days once D3 is up, since the H1
securing D1 would have been pruned with H3's usage of D2 by then.

This reduces the security model from 'always secure' to 'secure, as of last
year'. An attacker will need to have hidden hashing power to overwrite a
years worth of blocks. Which I think would be hard enough.

The attacker can also try to undo a freshly built Hn, but because we can
build Dn first and wait for Hn, the nodes should be expecting the same
hash. They also serve as automated checkpoints to prevent them from
overwriting all of it.
On Sep 19, 2015 6:38 AM, "Jorge Timón" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> s/move the genesis block forward/move your genesis checkpoint forward/
> On Sep 18, 2015 4:37 PM, "Jorge Timón"  wrote:
>
>> Well, with utxo commitments at some point maybe is enough to validate the
>> full headers history but only the last 5 years of ttansaction history
>> (assuming utxo commitments are buried 5 years worth of blocks in the past).
>> This scales much better than validating the full history and if we get a 5
>> year reorg something is going really wrong anyway...
>> Maybe after validating the last 5 years you also want to validate the
>> rest of the history backards to get the "fully-full node" security.
>> Of course 5 years it's just an arbitrary number: 2 or maybe even 1 would
>> probably be secure enough for most people. I've referred to this idea as
>> "hard checkpoints" or "moving the genesis block forward" in the past.
>> On Sep 18, 2015 4:18 PM, "Rune Kjær Svendsen" <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> There are a couple of points I’d like to address.
>>>
>>> Firstly, yes, >50% attacks are a problem for Bitcoin. Bitcoin does not
>>> function if the majority of mining power is dishonest. There is no way
>>> around that. It’s how proof-of-work functions. And if we lose
>>> proof-of-work, we lose Bitcoin.
>>>
>>> Secondly, I’m not suggesting that UTXO set hashes *replace* block
>>> hashes, or even that it should be in the block header (probably in the
>>> coinbase somewhere). I suggest it as an *addition* to the existing
>>> consensus rules. Full nodes can still verify the chain with the added step
>>> of hashing the UTXO set for every block. Of course, this can easily be
>>> deferred to after proof-of-work has been verified already, such that no
>>> work is wasted. Unless a 51% attack is in effect. But I argue that this is
>>> a moot point, since Bitcoin is useless anyway under such circumstances.
>>>
>>> Lastly, I’m not suggesting miners discard the blockchain history. A
>>> miner has an incentive to be absolutely sure that the chain he’s building
>>> on is the right one. If he’s wrong, he loses money/income. There’s simply
>>> no reason for a professional miner *not* to do the full initial sync, which
>>> only needs to be done once. Non-miners, who just want to check the balance
>>> of their wallet, however, really don’t need to retrieve information about
>>> Hal Finney sending bitcoins to Satoshi in 2010. In any case, this practice
>>> isn’t sustainable.
>>>
>>> In the end, it isn’t possible to control whether a miner verifies the
>>> entire blockchain anyway (anyone can send the UTXO set over the wire). Not
>>> letting the proof-of-work cover the UTXO hash doesn’t solve this problem,
>>> it only makes it impossible to know whether a given UTXO set is the one
>>> that the majority is mining on without retrieving the entire blockchain,
>>> and doing the verification yourself. People can choose to skip that
>>> regardless of what we do.
>>>
>>> Furthermore, all nodes have the option of deciding which level of
>>> security they want. We’re not lessening security of the protocol, we’re
>>> strengthening the security of something that’s already possible to do
>>> (build on top of an unverified blockchain), but we’d rather want that
>>> people not do.
>>>
>>> /Rune
>>>
>>>
>>> > On 18 Sep 2015, at 21:43, Patrick Strateman via bitcoin-dev <
>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>> >
>>> > Full nodes using UTXO set commitments is a change to the bitcoin
>>> > security model.
>>> >
>>> > Currently an attacker with >50% of the network hashrate can rewrite
>>> history.
>>> >
>>> > If full nodes rely on UTXO set commitments such an attacker could
>>> create
>>> > an infinite number of bitcoins (as in many times more than the current
>>> > 21 million bitcoin limit).
>>> >
>>> > Before we 

[bitcoin-dev] Improving Blocksize Communication Through Markets

[Paul Sztorc via bitcoin-dev]

Dear List,

1. Are you sick of hearing about THE BLOCKSIZE?
2. Do you feel that long-settled blocksize issues are coming up again
and again, resulting in duplicated work and communications burnout?
3. Do you feel that, while scalability is important and all, people
should just shut up about it already so that you can talk about X
Feature that you actually spent your time on?
4. Do you ever stop and think: How much *money* was spent for everyone
to travel to Montreal, stay at their hotels, and to rent the conference
venue and broadcasting accommodations? Shouldn't there be a way of just
*purchasing* the information we wanted more directly?
5. Do you feel that the inherent subjectivity of the conversation
encourages “political maneuvers” such as character assassination,
reduction of complex issues to minimal (two) unrepresentative “parties”,
and harassment / threats of violence (for the “greater good”)?

As I presented at the Montreal Conference, there is a way to
substantially improve the discussion. Would you believe that Hal Finney
himself advocated it just seven short years ago?

I happen to know it back-to-front, and the (simple) pieces are already
coded into my own more-complex project Truthcoin.

You could wait for me to hack the pieces together myself (which might
take a long time), or you, a competent/fast C++ developer familiar with
Bitcoin and/or Sidechain-Elements, could talk to me for 30 minutes, and
(depending on your skill level) bang it out in, probably, one weekend.

More details are on the project page ( http://bitcoinblocksize.com/ ),
some technical details are in the Github README.

I have also created a Slack:
https://blocksize-markets.slack.com/messages/general/

Sincerely,
Paul
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Luke Dashjr via bitcoin-dev]

On Friday, September 18, 2015 8:24:50 PM Btc Drak via bitcoin-dev wrote:
> Google calendar is localised, so it doesn't matter. The problem with
> quoting UTC anyway it the meeting times are going to change for those that
> observe DST. It would be much better to quote an actual timezone of an
> actual area so it will remain constant, like 1700 CEST, or 0900AM PDT for
> example. Otherwise when the clocks change, what was a convenient meeting
> time will become inconvenient for some.

Not everyone does crazy clock-changing. Using such a time system for 
scheduling seems to inconvenience the wrong position. (although perhaps 
arguably better since most people probably use DST) :p

(Aside, if Google Calendar can't support standard UTC, that sounds like an 
argument against using Google Calendar...)

> Urgh... Can we hardfork time? It's clearly in need of an upgrade...

Tonal time works nice any consistently. :D

Luke
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Luke Dashjr via bitcoin-dev]

On Friday, September 18, 2015 8:24:50 PM Btc Drak via bitcoin-dev wrote:
> Google calendar is localised, so it doesn't matter. The problem with
> quoting UTC anyway it the meeting times are going to change for those that
> observe DST. It would be much better to quote an actual timezone of an
> actual area so it will remain constant, like 1700 CEST, or 0900AM PDT for
> example. Otherwise when the clocks change, what was a convenient meeting
> time will become inconvenient for some.

Not everyone does crazy clock-changing. Using such a time system for 
scheduling seems to inconvenience the wrong position. (although perhaps 
arguably better since most people probably use DST) :p

(Aside, if Google Calendar can't support standard UTC, that sounds like an 
argument against using Google Calendar...)

> Urgh... Can we hardfork time? It's clearly in need of an upgrade...

Tonal time works nice and consistently. :D

Luke
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Matt Corallo via bitcoin-dev]

Yes, I'm aware, however they are closer to each other than UTC is to either :p.

On September 18, 2015 4:31:28 PM EDT, Gregory Maxwell  
wrote:
>On Fri, Sep 18, 2015 at 8:27 PM, Matt Corallo via bitcoin-dev
> wrote:
>> Google Calendar is localized, but has an option to change the
>timezone
>> of an event, it just doesnt have UTC in its options. So, yes, we
>should
>> use something that observes DST in roughly the same way as everyone
>else
>> - CEST/PDT/EST/etc.
>
>uh. There is fairly little global consistency in DST usage. Lots of
>places do dst on different dates.
>
>So if it's in some DST timezone it's likely to move twice each change
>for some subset of the people who do it.
>
>E.g. europe and US end DST one week apart.

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Matt Corallo via bitcoin-dev]

I believe that is out of date. I see neither UTC nor GMT on the website nor on 
Android.

Matt

On September 18, 2015 4:30:23 PM EDT, Jeffrey Paul  wrote:
>
>> On 18 Sep 2015, at 22:27, Matt Corallo via bitcoin-dev
> wrote:
>> 
>> Google Calendar is localized, but has an option to change the
>timezone
>> of an event, it just doesnt have UTC in its options. So, yes, we
>should
>> use something that observes DST in roughly the same way as everyone
>else
>> - CEST/PDT/EST/etc.
>
>According to this post, it is possible to configure Google Calendar to
>show an additional time zone to your localized one, and GMT/UTC is
>indeed in the list.
>
>https://productforums.google.com/forum/#!topic/calendar/y6uaiAdZrIg
>
>-jp
>
>--
>Jeffrey Paul  EEQJ
>j...@eeqj.com   https://eeqj.com
>+1-800-403-1126 (America)  +1-312-361-0355 (Worldwide)
>5539 AD00 DE4C 42F3 AFE1  1575 0524 43F4 DF2A 55C2

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Hash of UTXO set as consensus-critical

[Jorge Timón via bitcoin-dev]

s/move the genesis block forward/move your genesis checkpoint forward/
On Sep 18, 2015 4:37 PM, "Jorge Timón"  wrote:

> Well, with utxo commitments at some point maybe is enough to validate the
> full headers history but only the last 5 years of ttansaction history
> (assuming utxo commitments are buried 5 years worth of blocks in the past).
> This scales much better than validating the full history and if we get a 5
> year reorg something is going really wrong anyway...
> Maybe after validating the last 5 years you also want to validate the rest
> of the history backards to get the "fully-full node" security.
> Of course 5 years it's just an arbitrary number: 2 or maybe even 1 would
> probably be secure enough for most people. I've referred to this idea as
> "hard checkpoints" or "moving the genesis block forward" in the past.
> On Sep 18, 2015 4:18 PM, "Rune Kjær Svendsen" <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> There are a couple of points I’d like to address.
>>
>> Firstly, yes, >50% attacks are a problem for Bitcoin. Bitcoin does not
>> function if the majority of mining power is dishonest. There is no way
>> around that. It’s how proof-of-work functions. And if we lose
>> proof-of-work, we lose Bitcoin.
>>
>> Secondly, I’m not suggesting that UTXO set hashes *replace* block hashes,
>> or even that it should be in the block header (probably in the coinbase
>> somewhere). I suggest it as an *addition* to the existing consensus rules.
>> Full nodes can still verify the chain with the added step of hashing the
>> UTXO set for every block. Of course, this can easily be deferred to after
>> proof-of-work has been verified already, such that no work is wasted.
>> Unless a 51% attack is in effect. But I argue that this is a moot point,
>> since Bitcoin is useless anyway under such circumstances.
>>
>> Lastly, I’m not suggesting miners discard the blockchain history. A miner
>> has an incentive to be absolutely sure that the chain he’s building on is
>> the right one. If he’s wrong, he loses money/income. There’s simply no
>> reason for a professional miner *not* to do the full initial sync, which
>> only needs to be done once. Non-miners, who just want to check the balance
>> of their wallet, however, really don’t need to retrieve information about
>> Hal Finney sending bitcoins to Satoshi in 2010. In any case, this practice
>> isn’t sustainable.
>>
>> In the end, it isn’t possible to control whether a miner verifies the
>> entire blockchain anyway (anyone can send the UTXO set over the wire). Not
>> letting the proof-of-work cover the UTXO hash doesn’t solve this problem,
>> it only makes it impossible to know whether a given UTXO set is the one
>> that the majority is mining on without retrieving the entire blockchain,
>> and doing the verification yourself. People can choose to skip that
>> regardless of what we do.
>>
>> Furthermore, all nodes have the option of deciding which level of
>> security they want. We’re not lessening security of the protocol, we’re
>> strengthening the security of something that’s already possible to do
>> (build on top of an unverified blockchain), but we’d rather want that
>> people not do.
>>
>> /Rune
>>
>>
>> > On 18 Sep 2015, at 21:43, Patrick Strateman via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>> >
>> > Full nodes using UTXO set commitments is a change to the bitcoin
>> > security model.
>> >
>> > Currently an attacker with >50% of the network hashrate can rewrite
>> history.
>> >
>> > If full nodes rely on UTXO set commitments such an attacker could create
>> > an infinite number of bitcoins (as in many times more than the current
>> > 21 million bitcoin limit).
>> >
>> > Before we consider mechanisms for UTXO set commitments, we should
>> > seriously discuss whether the security model reduction is reasonable.
>> >
>> > On 09/18/2015 12:05 PM, Rune Kjær Svendsen via bitcoin-dev wrote:
>> >> Currently, when a new node wants to join the network, it needs to
>> retrieve the entire blockchain history, starting from January 2009 and up
>> until now, in order to derive a UTXO set that it can verify new
>> blocks/transactions against. With a blockchain size of 40GB and a UTXO size
>> of around 1GB, the extra bandwidth required is significant, and will keep
>> increasing indefinitely. If a newly mined block were to include the UTXO
>> set hash of the chain up until the previous block — the hash of the UTXO
>> set on top of which this block builds — then new nodes, who want to know
>> whether a transaction is valid, would be able to acquire the UTXO set in a
>> trustless manner, by only verifying proof-of-work headers, and knowing that
>> a block with an invalid UTXO set hash would be rejected.
>> >>
>> >> I’m not talking about calculating a complicated tree structure from
>> the UTXO set, which would put further burden on already burdened Bitcoin
>> Core nodes. We simply include the hash of the current UTXO set in a newly
>> created bloc

Re: [bitcoin-dev] Hash of UTXO set as consensus-critical

[Jorge Timón via bitcoin-dev]

Well, with utxo commitments at some point maybe is enough to validate the
full headers history but only the last 5 years of ttansaction history
(assuming utxo commitments are buried 5 years worth of blocks in the past).
This scales much better than validating the full history and if we get a 5
year reorg something is going really wrong anyway...
Maybe after validating the last 5 years you also want to validate the rest
of the history backards to get the "fully-full node" security.
Of course 5 years it's just an arbitrary number: 2 or maybe even 1 would
probably be secure enough for most people. I've referred to this idea as
"hard checkpoints" or "moving the genesis block forward" in the past.
On Sep 18, 2015 4:18 PM, "Rune Kjær Svendsen" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> There are a couple of points I’d like to address.
>
> Firstly, yes, >50% attacks are a problem for Bitcoin. Bitcoin does not
> function if the majority of mining power is dishonest. There is no way
> around that. It’s how proof-of-work functions. And if we lose
> proof-of-work, we lose Bitcoin.
>
> Secondly, I’m not suggesting that UTXO set hashes *replace* block hashes,
> or even that it should be in the block header (probably in the coinbase
> somewhere). I suggest it as an *addition* to the existing consensus rules.
> Full nodes can still verify the chain with the added step of hashing the
> UTXO set for every block. Of course, this can easily be deferred to after
> proof-of-work has been verified already, such that no work is wasted.
> Unless a 51% attack is in effect. But I argue that this is a moot point,
> since Bitcoin is useless anyway under such circumstances.
>
> Lastly, I’m not suggesting miners discard the blockchain history. A miner
> has an incentive to be absolutely sure that the chain he’s building on is
> the right one. If he’s wrong, he loses money/income. There’s simply no
> reason for a professional miner *not* to do the full initial sync, which
> only needs to be done once. Non-miners, who just want to check the balance
> of their wallet, however, really don’t need to retrieve information about
> Hal Finney sending bitcoins to Satoshi in 2010. In any case, this practice
> isn’t sustainable.
>
> In the end, it isn’t possible to control whether a miner verifies the
> entire blockchain anyway (anyone can send the UTXO set over the wire). Not
> letting the proof-of-work cover the UTXO hash doesn’t solve this problem,
> it only makes it impossible to know whether a given UTXO set is the one
> that the majority is mining on without retrieving the entire blockchain,
> and doing the verification yourself. People can choose to skip that
> regardless of what we do.
>
> Furthermore, all nodes have the option of deciding which level of security
> they want. We’re not lessening security of the protocol, we’re
> strengthening the security of something that’s already possible to do
> (build on top of an unverified blockchain), but we’d rather want that
> people not do.
>
> /Rune
>
>
> > On 18 Sep 2015, at 21:43, Patrick Strateman via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> > Full nodes using UTXO set commitments is a change to the bitcoin
> > security model.
> >
> > Currently an attacker with >50% of the network hashrate can rewrite
> history.
> >
> > If full nodes rely on UTXO set commitments such an attacker could create
> > an infinite number of bitcoins (as in many times more than the current
> > 21 million bitcoin limit).
> >
> > Before we consider mechanisms for UTXO set commitments, we should
> > seriously discuss whether the security model reduction is reasonable.
> >
> > On 09/18/2015 12:05 PM, Rune Kjær Svendsen via bitcoin-dev wrote:
> >> Currently, when a new node wants to join the network, it needs to
> retrieve the entire blockchain history, starting from January 2009 and up
> until now, in order to derive a UTXO set that it can verify new
> blocks/transactions against. With a blockchain size of 40GB and a UTXO size
> of around 1GB, the extra bandwidth required is significant, and will keep
> increasing indefinitely. If a newly mined block were to include the UTXO
> set hash of the chain up until the previous block — the hash of the UTXO
> set on top of which this block builds — then new nodes, who want to know
> whether a transaction is valid, would be able to acquire the UTXO set in a
> trustless manner, by only verifying proof-of-work headers, and knowing that
> a block with an invalid UTXO set hash would be rejected.
> >>
> >> I’m not talking about calculating a complicated tree structure from the
> UTXO set, which would put further burden on already burdened Bitcoin Core
> nodes. We simply include the hash of the current UTXO set in a newly
> created block, such that the transactions in the new block build *on top*
> of the UTXO set whose hash is specified. This actually alleviates Bitcoin
> Core nodes, as it will now become possible for nodes without the entire
> block

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

[Btc Drak via bitcoin-dev]

Urgh... Can we hardfork time? It's clearly in need of an upgrade...

On Fri, Sep 18, 2015 at 9:31 PM, Gregory Maxwell  wrote:

> On Fri, Sep 18, 2015 at 8:27 PM, Matt Corallo via bitcoin-dev
>  wrote:
> > Google Calendar is localized, but has an option to change the timezone
> > of an event, it just doesnt have UTC in its options. So, yes, we should
> > use something that observes DST in roughly the same way as everyone else
> > - CEST/PDT/EST/etc.
>
> uh. There is fairly little global consistency in DST usage. Lots of
> places do dst on different dates.
>
> So if it's in some DST timezone it's likely to move twice each change
> for some subset of the people who do it.
>
> E.g. europe and US end DST one week apart.
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Gregory Maxwell via bitcoin-dev]

On Fri, Sep 18, 2015 at 8:27 PM, Matt Corallo via bitcoin-dev
 wrote:
> Google Calendar is localized, but has an option to change the timezone
> of an event, it just doesnt have UTC in its options. So, yes, we should
> use something that observes DST in roughly the same way as everyone else
> - CEST/PDT/EST/etc.

uh. There is fairly little global consistency in DST usage. Lots of
places do dst on different dates.

So if it's in some DST timezone it's likely to move twice each change
for some subset of the people who do it.

E.g. europe and US end DST one week apart.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Jeffrey Paul via bitcoin-dev]

> On 18 Sep 2015, at 22:27, Matt Corallo via bitcoin-dev 
>  wrote:
> 
> Google Calendar is localized, but has an option to change the timezone
> of an event, it just doesnt have UTC in its options. So, yes, we should
> use something that observes DST in roughly the same way as everyone else
> - CEST/PDT/EST/etc.

According to this post, it is possible to configure Google Calendar to show an 
additional time zone to your localized one, and GMT/UTC is indeed in the list.

https://productforums.google.com/forum/#!topic/calendar/y6uaiAdZrIg

-jp

--
Jeffrey Paul  EEQJ
j...@eeqj.com   https://eeqj.com
+1-800-403-1126 (America)  +1-312-361-0355 (Worldwide)
5539 AD00 DE4C 42F3 AFE1  1575 0524 43F4 DF2A 55C2

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Matt Corallo via bitcoin-dev]

Google Calendar is localized, but has an option to change the timezone
of an event, it just doesnt have UTC in its options. So, yes, we should
use something that observes DST in roughly the same way as everyone else
- CEST/PDT/EST/etc.

On 09/18/15 20:24, Btc Drak wrote:
> Google calendar is localised, so it doesn't matter. The problem with
> quoting UTC anyway it the meeting times are going to change for those
> that observe DST. It would be much better to quote an actual timezone of
> an actual area so it will remain constant, like 1700 CEST, or 0900AM PDT
> for example. Otherwise when the clocks change, what was a convenient
> meeting time will become inconvenient for some.
> 
> On Fri, Sep 18, 2015 at 9:14 PM, Matt Corallo via bitcoin-dev
>  > wrote:
> 
> Generally in favor, but for practical purposes can we select a timezone
> that is available in Google Calendar? It appears it does not directly
> support UTC...
> 
> On 09/18/15 01:07, Wladimir J. van der Laan via bitcoin-dev wrote:
> > Hello,
> >
> > At Monday's code sprint we had a good idea to schedule a regular
> developer meeting in #bitcoin-dev.
> >
> > Attendance is of course voluntary, but it may be good to have a
> time that many people are expected to be present and current issues
> can be discussed.
> >
> > Any preference for days/times?
> >
> > What about e.g. every week 15:00-16:00 UTC on Thursday?
> >
> > Wladimir
> > ___
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> 
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> 
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 
> 
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Btc Drak via bitcoin-dev]

Google calendar is localised, so it doesn't matter. The problem with
quoting UTC anyway it the meeting times are going to change for those that
observe DST. It would be much better to quote an actual timezone of an
actual area so it will remain constant, like 1700 CEST, or 0900AM PDT for
example. Otherwise when the clocks change, what was a convenient meeting
time will become inconvenient for some.

On Fri, Sep 18, 2015 at 9:14 PM, Matt Corallo via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Generally in favor, but for practical purposes can we select a timezone
> that is available in Google Calendar? It appears it does not directly
> support UTC...
>
> On 09/18/15 01:07, Wladimir J. van der Laan via bitcoin-dev wrote:
> > Hello,
> >
> > At Monday's code sprint we had a good idea to schedule a regular
> developer meeting in #bitcoin-dev.
> >
> > Attendance is of course voluntary, but it may be good to have a time
> that many people are expected to be present and current issues can be
> discussed.
> >
> > Any preference for days/times?
> >
> > What about e.g. every week 15:00-16:00 UTC on Thursday?
> >
> > Wladimir
> > ___
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Hash of UTXO set as consensus-critical

[Rune Kjær Svendsen via bitcoin-dev]

There are a couple of points I’d like to address.

Firstly, yes, >50% attacks are a problem for Bitcoin. Bitcoin does not function 
if the majority of mining power is dishonest. There is no way around that. It’s 
how proof-of-work functions. And if we lose proof-of-work, we lose Bitcoin.

Secondly, I’m not suggesting that UTXO set hashes *replace* block hashes, or 
even that it should be in the block header (probably in the coinbase 
somewhere). I suggest it as an *addition* to the existing consensus rules. Full 
nodes can still verify the chain with the added step of hashing the UTXO set 
for every block. Of course, this can easily be deferred to after proof-of-work 
has been verified already, such that no work is wasted. Unless a 51% attack is 
in effect. But I argue that this is a moot point, since Bitcoin is useless 
anyway under such circumstances.

Lastly, I’m not suggesting miners discard the blockchain history. A miner has 
an incentive to be absolutely sure that the chain he’s building on is the right 
one. If he’s wrong, he loses money/income. There’s simply no reason for a 
professional miner *not* to do the full initial sync, which only needs to be 
done once. Non-miners, who just want to check the balance of their wallet, 
however, really don’t need to retrieve information about Hal Finney sending 
bitcoins to Satoshi in 2010. In any case, this practice isn’t sustainable.

In the end, it isn’t possible to control whether a miner verifies the entire 
blockchain anyway (anyone can send the UTXO set over the wire). Not letting the 
proof-of-work cover the UTXO hash doesn’t solve this problem, it only makes it 
impossible to know whether a given UTXO set is the one that the majority is 
mining on without retrieving the entire blockchain, and doing the verification 
yourself. People can choose to skip that regardless of what we do.

Furthermore, all nodes have the option of deciding which level of security they 
want. We’re not lessening security of the protocol, we’re strengthening the 
security of something that’s already possible to do (build on top of an 
unverified blockchain), but we’d rather want that people not do.

/Rune


> On 18 Sep 2015, at 21:43, Patrick Strateman via bitcoin-dev 
>  wrote:
> 
> Full nodes using UTXO set commitments is a change to the bitcoin
> security model.
> 
> Currently an attacker with >50% of the network hashrate can rewrite history.
> 
> If full nodes rely on UTXO set commitments such an attacker could create
> an infinite number of bitcoins (as in many times more than the current
> 21 million bitcoin limit).
> 
> Before we consider mechanisms for UTXO set commitments, we should
> seriously discuss whether the security model reduction is reasonable.
> 
> On 09/18/2015 12:05 PM, Rune Kjær Svendsen via bitcoin-dev wrote:
>> Currently, when a new node wants to join the network, it needs to retrieve 
>> the entire blockchain history, starting from January 2009 and up until now, 
>> in order to derive a UTXO set that it can verify new blocks/transactions 
>> against. With a blockchain size of 40GB and a UTXO size of around 1GB, the 
>> extra bandwidth required is significant, and will keep increasing 
>> indefinitely. If a newly mined block were to include the UTXO set hash of 
>> the chain up until the previous block — the hash of the UTXO set on top of 
>> which this block builds — then new nodes, who want to know whether a 
>> transaction is valid, would be able to acquire the UTXO set in a trustless 
>> manner, by only verifying proof-of-work headers, and knowing that a block 
>> with an invalid UTXO set hash would be rejected.
>> 
>> I’m not talking about calculating a complicated tree structure from the UTXO 
>> set, which would put further burden on already burdened Bitcoin Core nodes. 
>> We simply include the hash of the current UTXO set in a newly created block, 
>> such that the transactions in the new block build *on top* of the UTXO set 
>> whose hash is specified. This actually alleviates Bitcoin Core nodes, as it 
>> will now become possible for nodes without the entire blockchain to answer 
>> SPV queries (by retrieving the UTXO set trustlessly and using this to answer 
>> queries). It also saves bandwidth for Bitcore Core nodes, who only need to 
>> send roughly 1GB of data, in order to synchronise a node, rather than 40GB+. 
>> I will continue to run a full Bitcoin Core node, saving the entire 
>> blockchain history, but it shouldn’t be a requirement to hold the entire 
>> transaction history in order to start verifying new transactions.
>> 
>> As far as I can see, this also forces miners to actually maintain an UTXO 
>> set, rather than just build on top of the chain with the most proof-of-work. 
>> Producing a UTXO set and verifying a block against a chain is the same 
>> thing, so by including the hash of the UTXO set we force miners to verify 
>> the block that they want to build on top of.
>> 
>> Am I missing something obvious, because as far 

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

[Matt Corallo via bitcoin-dev]

Generally in favor, but for practical purposes can we select a timezone
that is available in Google Calendar? It appears it does not directly
support UTC...

On 09/18/15 01:07, Wladimir J. van der Laan via bitcoin-dev wrote:
> Hello,
> 
> At Monday's code sprint we had a good idea to schedule a regular developer 
> meeting in #bitcoin-dev.
> 
> Attendance is of course voluntary, but it may be good to have a time that 
> many people are expected to be present and current issues can be discussed.
> 
> Any preference for days/times?
> 
> What about e.g. every week 15:00-16:00 UTC on Thursday?
> 
> Wladimir
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Hash of UTXO set as consensus-critical

[Matt Corallo via bitcoin-dev]

I believe the discussion here is on improving initial-sync time by
simply skipping initial-sync and getting a committed-to utxo set. This
is obviously a new security model in between SPV and full-node (I would
call it SPV with future validation). Still, I'm not convinced it buys us
anything, we really should just tweak Bitcoin Core to do spv mode at
startup and validate backwards in the background. I think this would
alleviate most of the concerns raised, given the chain growth is not
entirely unreasonable going forward.

On 09/18/15 20:07, Alex Morcos via bitcoin-dev wrote:
> I guess I always assumed that UTXO set commitments were an alternative
> security model (between SPV and full-node), not that they would cause
> the existing security model to be deprecated.
> 
> 
> On Fri, Sep 18, 2015 at 3:43 PM, Patrick Strateman via bitcoin-dev
>  > wrote:
> 
> Full nodes using UTXO set commitments is a change to the bitcoin
> security model.
> 
> Currently an attacker with >50% of the network hashrate can rewrite
> history.
> 
> If full nodes rely on UTXO set commitments such an attacker could create
> an infinite number of bitcoins (as in many times more than the current
> 21 million bitcoin limit).
> 
> Before we consider mechanisms for UTXO set commitments, we should
> seriously discuss whether the security model reduction is reasonable.
> 
> On 09/18/2015 12:05 PM, Rune Kjær Svendsen via bitcoin-dev wrote:
> > Currently, when a new node wants to join the network, it needs to
> retrieve the entire blockchain history, starting from January 2009
> and up until now, in order to derive a UTXO set that it can verify
> new blocks/transactions against. With a blockchain size of 40GB and
> a UTXO size of around 1GB, the extra bandwidth required is
> significant, and will keep increasing indefinitely. If a newly mined
> block were to include the UTXO set hash of the chain up until the
> previous block — the hash of the UTXO set on top of which this block
> builds — then new nodes, who want to know whether a transaction is
> valid, would be able to acquire the UTXO set in a trustless manner,
> by only verifying proof-of-work headers, and knowing that a block
> with an invalid UTXO set hash would be rejected.
> >
> > I’m not talking about calculating a complicated tree structure
> from the UTXO set, which would put further burden on already
> burdened Bitcoin Core nodes. We simply include the hash of the
> current UTXO set in a newly created block, such that the
> transactions in the new block build *on top* of the UTXO set whose
> hash is specified. This actually alleviates Bitcoin Core nodes, as
> it will now become possible for nodes without the entire blockchain
> to answer SPV queries (by retrieving the UTXO set trustlessly and
> using this to answer queries). It also saves bandwidth for Bitcore
> Core nodes, who only need to send roughly 1GB of data, in order to
> synchronise a node, rather than 40GB+. I will continue to run a full
> Bitcoin Core node, saving the entire blockchain history, but it
> shouldn’t be a requirement to hold the entire transaction history in
> order to start verifying new transactions.
> >
> > As far as I can see, this also forces miners to actually maintain
> an UTXO set, rather than just build on top of the chain with the
> most proof-of-work. Producing a UTXO set and verifying a block
> against a chain is the same thing, so by including the hash of the
> UTXO set we force miners to verify the block that they want to build
> on top of.
> >
> > Am I missing something obvious, because as far as I can see, this
> solves the problem of quadratic time complexity for initial sync:
> http://www.youtube.com/watch?v=TgjrS-BPWDQ&t=2h02m12s
> >
> > The only added step to verifying a block is to hash the UTXO set.
> So it does require additional computation, but most modern CPUs have
> a SHA256 throughput of around 500 MB/s, which means it takes only
> two seconds to hash the UTXO set. And this can be improved further
> (GPUs can do 2-3 GB/s). A small sacrifice for the added ease of
> initial syncing, in my opinion.
> >
> > /Rune
> > ___
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> 
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 
> 
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> 
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 
> 
> 
> 
> ___
> bitcoin-dev mailing list
> bitco

Re: [bitcoin-dev] Hash of UTXO set as consensus-critical

[Alex Morcos via bitcoin-dev]

I guess I always assumed that UTXO set commitments were an alternative
security model (between SPV and full-node), not that they would cause the
existing security model to be deprecated.


On Fri, Sep 18, 2015 at 3:43 PM, Patrick Strateman via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Full nodes using UTXO set commitments is a change to the bitcoin
> security model.
>
> Currently an attacker with >50% of the network hashrate can rewrite
> history.
>
> If full nodes rely on UTXO set commitments such an attacker could create
> an infinite number of bitcoins (as in many times more than the current
> 21 million bitcoin limit).
>
> Before we consider mechanisms for UTXO set commitments, we should
> seriously discuss whether the security model reduction is reasonable.
>
> On 09/18/2015 12:05 PM, Rune Kjær Svendsen via bitcoin-dev wrote:
> > Currently, when a new node wants to join the network, it needs to
> retrieve the entire blockchain history, starting from January 2009 and up
> until now, in order to derive a UTXO set that it can verify new
> blocks/transactions against. With a blockchain size of 40GB and a UTXO size
> of around 1GB, the extra bandwidth required is significant, and will keep
> increasing indefinitely. If a newly mined block were to include the UTXO
> set hash of the chain up until the previous block — the hash of the UTXO
> set on top of which this block builds — then new nodes, who want to know
> whether a transaction is valid, would be able to acquire the UTXO set in a
> trustless manner, by only verifying proof-of-work headers, and knowing that
> a block with an invalid UTXO set hash would be rejected.
> >
> > I’m not talking about calculating a complicated tree structure from the
> UTXO set, which would put further burden on already burdened Bitcoin Core
> nodes. We simply include the hash of the current UTXO set in a newly
> created block, such that the transactions in the new block build *on top*
> of the UTXO set whose hash is specified. This actually alleviates Bitcoin
> Core nodes, as it will now become possible for nodes without the entire
> blockchain to answer SPV queries (by retrieving the UTXO set trustlessly
> and using this to answer queries). It also saves bandwidth for Bitcore Core
> nodes, who only need to send roughly 1GB of data, in order to synchronise a
> node, rather than 40GB+. I will continue to run a full Bitcoin Core node,
> saving the entire blockchain history, but it shouldn’t be a requirement to
> hold the entire transaction history in order to start verifying new
> transactions.
> >
> > As far as I can see, this also forces miners to actually maintain an
> UTXO set, rather than just build on top of the chain with the most
> proof-of-work. Producing a UTXO set and verifying a block against a chain
> is the same thing, so by including the hash of the UTXO set we force miners
> to verify the block that they want to build on top of.
> >
> > Am I missing something obvious, because as far as I can see, this solves
> the problem of quadratic time complexity for initial sync:
> http://www.youtube.com/watch?v=TgjrS-BPWDQ&t=2h02m12s
> >
> > The only added step to verifying a block is to hash the UTXO set. So it
> does require additional computation, but most modern CPUs have a SHA256
> throughput of around 500 MB/s, which means it takes only two seconds to
> hash the UTXO set. And this can be improved further (GPUs can do 2-3 GB/s).
> A small sacrifice for the added ease of initial syncing, in my opinion.
> >
> > /Rune
> > ___
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Scaling Bitcoin conference micro-report

[Matt Corallo via bitcoin-dev]

I did not intend to imply that there was agreement on a desire to
schedule a second hardfork. My wording may have been a bit too loose.
Instead, I believe there was much agreement that doing a short-term
hardfork now, with many agreeing that a second would hopefully be
entirely unnecessary/impossible, while others thought that a second
would be necessary and would have to happen. While this may set up a
similar controversy again in several years, I think everyone agreed that
we cannot predict the future and I, personally, think none of us should
be committing to a viewpoint for what should be done at that time.

Personally, I think it is also critical that there be no messaging that
people should rely on or assume there will be a future increase after a
short-term bump (which I also do not believe people should be relying on
now).

Matt

On 09/18/15 05:55, Mark Friedenbach wrote:
> Correction of a correction, in-line:
> 
> On Wed, Sep 16, 2015 at 5:51 PM, Matt Corallo via bitcoin-dev
>  > wrote:
> 
> > - Many interested or at least willing to accept a "short term bump", a
> > hard fork to modify block size limit regime to be cost-based via
> > "net-utxo" rather than a simple static hard limit.  2-4-8 and 17%/year
> > were debated and seemed "in range" with what might work as a short term
> > bump - net after applying the new cost metric.
> 
> I would be careful to point out that hard numbers were deliberately NOT
> discussed. Though some general things were thrown out, they were not
> extensively discussed nor agreed to. I personally think 2-4 is "in
> range", though 8 maybe not so much. Of course it depends on exactly how
> the non-blocksize limit accounting/adjusting is done.
> 
> Still, the "greatest common denominator" agreement did not seem to be
> agreeing to an increase which continues over time, but which instead
> limits itself to a set, smooth increase for X time and then requires a
> second hardfork if there is agreement on a need for more blocksize at
> that point.
> 
> 
> Perhaps it is accurate to say that there wasn't consensus at all except
> that (1) we think we can work together on resolving this impasse (yay!),
> and (2) it is conceivable that changing from block size to some other
> metric might provide the basis for a compromise on near-term numbers.
> 
> As an example, I do not think the net-UTXO metric provides any benefit
> with respect to scalability, and in some ways makes the situation worse
> (even though it helpfully solves an unrelated problem of spammy dust
> outputs). But there are other possible metrics and I maintain hope that
> data will show the benefit of another metric or other metrics combined
> with net-UTXO in a way that will allow us to reach consensus.
> 
> As a further example, I also am quite concerned about 2-4-8MB with
> either block size or net-UTXO as the base metric. As you say, it depends
> on how the non-blocksize limit accounting/adjusting is done... But if a
> metric were chosen that addressed my concerns (worst case propagation
> and validation time), then I could be in favor of an initial bump that
> allowed a larger number of typical transactions in a block.
> 
> But where I really need to disagree is on the requirement for a 2nd hard
> fork. I will go on record as being definitively against this. While
> being conservative with respect to exponentials, I would very much like
> to make sure that there is a long-term growth curve as part of any
> proposal. I am willing to accept a hard-fork if the adopted plan is too
> conservative, but I do not want to be kicking the can down the road to a
> scheduled 2nd hard fork that absolutely must occur. That, I feel, could
> be a more dangerous outcome than an exponential that outlasts
> conservative historical trends.
> 
> I commend Jeff for writing a Chatham-rules summary of the outcome of
> some hallway conversations that occurred. On the whole I think his
> summary does represent the majority view of the opinions expressed by
> core developers at the workshop. I will caution though that on nearly
> every issue there were those expressed disagreement but did not fight
> the issue, and those who said nothing and left unpolled opinions.
> Nevertheless this summary is informative as it feeds forwards into the
> design of proposals that will be made prior to the Hong Kong workshop in
> December, in order that they have a higher likelihood of success.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Hash of UTXO set as consensus-critical

[Patrick Strateman via bitcoin-dev]

Full nodes using UTXO set commitments is a change to the bitcoin
security model.

Currently an attacker with >50% of the network hashrate can rewrite history.

If full nodes rely on UTXO set commitments such an attacker could create
an infinite number of bitcoins (as in many times more than the current
21 million bitcoin limit).

Before we consider mechanisms for UTXO set commitments, we should
seriously discuss whether the security model reduction is reasonable.

On 09/18/2015 12:05 PM, Rune Kjær Svendsen via bitcoin-dev wrote:
> Currently, when a new node wants to join the network, it needs to retrieve 
> the entire blockchain history, starting from January 2009 and up until now, 
> in order to derive a UTXO set that it can verify new blocks/transactions 
> against. With a blockchain size of 40GB and a UTXO size of around 1GB, the 
> extra bandwidth required is significant, and will keep increasing 
> indefinitely. If a newly mined block were to include the UTXO set hash of the 
> chain up until the previous block — the hash of the UTXO set on top of which 
> this block builds — then new nodes, who want to know whether a transaction is 
> valid, would be able to acquire the UTXO set in a trustless manner, by only 
> verifying proof-of-work headers, and knowing that a block with an invalid 
> UTXO set hash would be rejected.
>
> I’m not talking about calculating a complicated tree structure from the UTXO 
> set, which would put further burden on already burdened Bitcoin Core nodes. 
> We simply include the hash of the current UTXO set in a newly created block, 
> such that the transactions in the new block build *on top* of the UTXO set 
> whose hash is specified. This actually alleviates Bitcoin Core nodes, as it 
> will now become possible for nodes without the entire blockchain to answer 
> SPV queries (by retrieving the UTXO set trustlessly and using this to answer 
> queries). It also saves bandwidth for Bitcore Core nodes, who only need to 
> send roughly 1GB of data, in order to synchronise a node, rather than 40GB+. 
> I will continue to run a full Bitcoin Core node, saving the entire blockchain 
> history, but it shouldn’t be a requirement to hold the entire transaction 
> history in order to start verifying new transactions.
>
> As far as I can see, this also forces miners to actually maintain an UTXO 
> set, rather than just build on top of the chain with the most proof-of-work. 
> Producing a UTXO set and verifying a block against a chain is the same thing, 
> so by including the hash of the UTXO set we force miners to verify the block 
> that they want to build on top of.
>
> Am I missing something obvious, because as far as I can see, this solves the 
> problem of quadratic time complexity for initial sync: 
> http://www.youtube.com/watch?v=TgjrS-BPWDQ&t=2h02m12s
>
> The only added step to verifying a block is to hash the UTXO set. So it does 
> require additional computation, but most modern CPUs have a SHA256 throughput 
> of around 500 MB/s, which means it takes only two seconds to hash the UTXO 
> set. And this can be improved further (GPUs can do 2-3 GB/s). A small 
> sacrifice for the added ease of initial syncing, in my opinion.
>
> /Rune
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Hash of UTXO set as consensus-critical

[Rune Kjær Svendsen via bitcoin-dev]

Currently, when a new node wants to join the network, it needs to retrieve the 
entire blockchain history, starting from January 2009 and up until now, in 
order to derive a UTXO set that it can verify new blocks/transactions against. 
With a blockchain size of 40GB and a UTXO size of around 1GB, the extra 
bandwidth required is significant, and will keep increasing indefinitely. If a 
newly mined block were to include the UTXO set hash of the chain up until the 
previous block — the hash of the UTXO set on top of which this block builds — 
then new nodes, who want to know whether a transaction is valid, would be able 
to acquire the UTXO set in a trustless manner, by only verifying proof-of-work 
headers, and knowing that a block with an invalid UTXO set hash would be 
rejected.

I’m not talking about calculating a complicated tree structure from the UTXO 
set, which would put further burden on already burdened Bitcoin Core nodes. We 
simply include the hash of the current UTXO set in a newly created block, such 
that the transactions in the new block build *on top* of the UTXO set whose 
hash is specified. This actually alleviates Bitcoin Core nodes, as it will now 
become possible for nodes without the entire blockchain to answer SPV queries 
(by retrieving the UTXO set trustlessly and using this to answer queries). It 
also saves bandwidth for Bitcore Core nodes, who only need to send roughly 1GB 
of data, in order to synchronise a node, rather than 40GB+. I will continue to 
run a full Bitcoin Core node, saving the entire blockchain history, but it 
shouldn’t be a requirement to hold the entire transaction history in order to 
start verifying new transactions.

As far as I can see, this also forces miners to actually maintain an UTXO set, 
rather than just build on top of the chain with the most proof-of-work. 
Producing a UTXO set and verifying a block against a chain is the same thing, 
so by including the hash of the UTXO set we force miners to verify the block 
that they want to build on top of.

Am I missing something obvious, because as far as I can see, this solves the 
problem of quadratic time complexity for initial sync: 
http://www.youtube.com/watch?v=TgjrS-BPWDQ&t=2h02m12s

The only added step to verifying a block is to hash the UTXO set. So it does 
require additional computation, but most modern CPUs have a SHA256 throughput 
of around 500 MB/s, which means it takes only two seconds to hash the UTXO set. 
And this can be improved further (GPUs can do 2-3 GB/s). A small sacrifice for 
the added ease of initial syncing, in my opinion.

/Rune
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Scaling Bitcoin conference micro-report

[Eric Lombrozo via bitcoin-dev]

To be quite frank, I'm a little disappointed we've fallen back on arguing over 
numbers pulled out of a hat rather than discussing far more fundamental issues 
such as the dev process generally, consensus building, and our basic 
understanding of what Bitcoin really is, its strengths and weaknesses, where it 
shows most promise, and communicating a more unified vision to the industry and 
the public.

On September 18, 2015 10:10:08 AM PDT, Dave Scotese via bitcoin-dev 
 wrote:
>"But if a metric were chosen that addressed my concerns (worst case
>propagation and validation time), then I could be in favor of an
>initial
>bump that allowed a larger number of typical transactions in a block."
>
>+1.  A ratio is much more valuable than a simple metric.  It seems
>clearly
>difficult to identify a reasonable limit to block size, but the ratio
>between any one of several possible metrics and bytes in a block would
>work
>well and may already have a very good reasonable expected range.
>
>I like BTCDaysDestroyed (BTCDD) best.  If it might be time consuming to
>compute, then it need only be computed for all blocks less than or
>equal in
>size to the average size of the largest 200 or so blocks in the
>previous
>difficulty period.  To exceed that limit, a miner would have to ensure
>that
>the block has enough BTCDD per byte.  "Enough" could be hardcoded in
>each
>release, or if it's simple enough, use the ratio as computed over all
>the
>blocks in the previous difficulty period as the lower limit.
>
>notplato
>
>On Thu, Sep 17, 2015 at 10:55 PM, Mark Friedenbach via bitcoin-dev <
>bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Correction of a correction, in-line:
>>
>> On Wed, Sep 16, 2015 at 5:51 PM, Matt Corallo via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> > - Many interested or at least willing to accept a "short term
>bump", a
>>> > hard fork to modify block size limit regime to be cost-based via
>>> > "net-utxo" rather than a simple static hard limit.  2-4-8 and
>17%/year
>>> > were debated and seemed "in range" with what might work as a short
>term
>>> > bump - net after applying the new cost metric.
>>>
>>> I would be careful to point out that hard numbers were deliberately
>NOT
>>> discussed. Though some general things were thrown out, they were not
>>> extensively discussed nor agreed to. I personally think 2-4 is "in
>>> range", though 8 maybe not so much. Of course it depends on exactly
>how
>>> the non-blocksize limit accounting/adjusting is done.
>>>
>>> Still, the "greatest common denominator" agreement did not seem to
>be
>>> agreeing to an increase which continues over time, but which instead
>>> limits itself to a set, smooth increase for X time and then requires
>a
>>> second hardfork if there is agreement on a need for more blocksize
>at
>>> that point.
>>>
>>
>> Perhaps it is accurate to say that there wasn't consensus at all
>except
>> that (1) we think we can work together on resolving this impasse
>(yay!),
>> and (2) it is conceivable that changing from block size to some other
>> metric might provide the basis for a compromise on near-term numbers.
>>
>> As an example, I do not think the net-UTXO metric provides any
>benefit
>> with respect to scalability, and in some ways makes the situation
>worse
>> (even though it helpfully solves an unrelated problem of spammy dust
>> outputs). But there are other possible metrics and I maintain hope
>that
>> data will show the benefit of another metric or other metrics
>combined with
>> net-UTXO in a way that will allow us to reach consensus.
>>
>> As a further example, I also am quite concerned about 2-4-8MB with
>either
>> block size or net-UTXO as the base metric. As you say, it depends on
>how
>> the non-blocksize limit accounting/adjusting is done... But if a
>metric
>> were chosen that addressed my concerns (worst case propagation and
>> validation time), then I could be in favor of an initial bump that
>allowed
>> a larger number of typical transactions in a block.
>>
>> But where I really need to disagree is on the requirement for a 2nd
>hard
>> fork. I will go on record as being definitively against this. While
>being
>> conservative with respect to exponentials, I would very much like to
>make
>> sure that there is a long-term growth curve as part of any proposal.
>I am
>> willing to accept a hard-fork if the adopted plan is too
>conservative, but
>> I do not want to be kicking the can down the road to a scheduled 2nd
>hard
>> fork that absolutely must occur. That, I feel, could be a more
>dangerous
>> outcome than an exponential that outlasts conservative historical
>trends.
>>
>> I commend Jeff for writing a Chatham-rules summary of the outcome of
>some
>> hallway conversations that occurred. On the whole I think his summary
>does
>> represent the majority view of the opinions expressed by core
>developers at
>> the workshop. I will caution though that on nearly every issue there
>were
>> those expressed disag

Re: [bitcoin-dev] Scaling Bitcoin conference micro-report

[Dave Scotese via bitcoin-dev]

"But if a metric were chosen that addressed my concerns (worst case
propagation and validation time), then I could be in favor of an initial
bump that allowed a larger number of typical transactions in a block."

+1.  A ratio is much more valuable than a simple metric.  It seems clearly
difficult to identify a reasonable limit to block size, but the ratio
between any one of several possible metrics and bytes in a block would work
well and may already have a very good reasonable expected range.

I like BTCDaysDestroyed (BTCDD) best.  If it might be time consuming to
compute, then it need only be computed for all blocks less than or equal in
size to the average size of the largest 200 or so blocks in the previous
difficulty period.  To exceed that limit, a miner would have to ensure that
the block has enough BTCDD per byte.  "Enough" could be hardcoded in each
release, or if it's simple enough, use the ratio as computed over all the
blocks in the previous difficulty period as the lower limit.

notplato

On Thu, Sep 17, 2015 at 10:55 PM, Mark Friedenbach via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Correction of a correction, in-line:
>
> On Wed, Sep 16, 2015 at 5:51 PM, Matt Corallo via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> > - Many interested or at least willing to accept a "short term bump", a
>> > hard fork to modify block size limit regime to be cost-based via
>> > "net-utxo" rather than a simple static hard limit.  2-4-8 and 17%/year
>> > were debated and seemed "in range" with what might work as a short term
>> > bump - net after applying the new cost metric.
>>
>> I would be careful to point out that hard numbers were deliberately NOT
>> discussed. Though some general things were thrown out, they were not
>> extensively discussed nor agreed to. I personally think 2-4 is "in
>> range", though 8 maybe not so much. Of course it depends on exactly how
>> the non-blocksize limit accounting/adjusting is done.
>>
>> Still, the "greatest common denominator" agreement did not seem to be
>> agreeing to an increase which continues over time, but which instead
>> limits itself to a set, smooth increase for X time and then requires a
>> second hardfork if there is agreement on a need for more blocksize at
>> that point.
>>
>
> Perhaps it is accurate to say that there wasn't consensus at all except
> that (1) we think we can work together on resolving this impasse (yay!),
> and (2) it is conceivable that changing from block size to some other
> metric might provide the basis for a compromise on near-term numbers.
>
> As an example, I do not think the net-UTXO metric provides any benefit
> with respect to scalability, and in some ways makes the situation worse
> (even though it helpfully solves an unrelated problem of spammy dust
> outputs). But there are other possible metrics and I maintain hope that
> data will show the benefit of another metric or other metrics combined with
> net-UTXO in a way that will allow us to reach consensus.
>
> As a further example, I also am quite concerned about 2-4-8MB with either
> block size or net-UTXO as the base metric. As you say, it depends on how
> the non-blocksize limit accounting/adjusting is done... But if a metric
> were chosen that addressed my concerns (worst case propagation and
> validation time), then I could be in favor of an initial bump that allowed
> a larger number of typical transactions in a block.
>
> But where I really need to disagree is on the requirement for a 2nd hard
> fork. I will go on record as being definitively against this. While being
> conservative with respect to exponentials, I would very much like to make
> sure that there is a long-term growth curve as part of any proposal. I am
> willing to accept a hard-fork if the adopted plan is too conservative, but
> I do not want to be kicking the can down the road to a scheduled 2nd hard
> fork that absolutely must occur. That, I feel, could be a more dangerous
> outcome than an exponential that outlasts conservative historical trends.
>
> I commend Jeff for writing a Chatham-rules summary of the outcome of some
> hallway conversations that occurred. On the whole I think his summary does
> represent the majority view of the opinions expressed by core developers at
> the workshop. I will caution though that on nearly every issue there were
> those expressed disagreement but did not fight the issue, and those who
> said nothing and left unpolled opinions. Nevertheless this summary is
> informative as it feeds forwards into the design of proposals that will be
> made prior to the Hong Kong workshop in December, in order that they have a
> higher likelihood of success.
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>


-- 
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocr

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

[Mike Hearn via bitcoin-dev]

>
> What one needs for that, I think, is a library that communicate with the
> node, and which offers functionality abstractly be similar to 'git pull':
> give me the tree path from my current known tip to the best tip, and supply
> the block hashes (and block data) along the way.
>

This is exactly what SPV libraries like bitcoinj do: they know how to build
a block locator, request the blocks forward from the common branch point,
and handle re-orgs onto whatever the current best chain are by downloading
data from a full node.

If your official position is people should all use bitcoinj to do things
like build extra indexes, then great. Send them our way. It already knows
how to calculate a UTXO set indexed by address.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Fill-or-kill transaction

[Jorge Timón via bitcoin-dev]

On Sep 17, 2015 6:48 PM, "Peter Todd"  wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
>
>
> On 17 September 2015 12:14:38 GMT-07:00, "Jorge Timón via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> >Fill or kill us normally used for trades and I think it can be
> >confusing.
> >Previous times this has been discussed it has been discussed under
> >nExpiryTime or op_height (which enables expiration), for example, in
> >the
> >freimarkets white paper.
> >
> >As Mark points out this can be made safe by requiring that all the
> >outputs
> >of a transaction that can expire have op_maturity/csv/rcltv of 100.
> >That
> >makes them as reorg-safe as coinbase transactions. Unfortunately this
> >doesn't play very well with p2sh...
>
> Why wouldn't that work with p2sh? It can be implemented by a "treat like
Coinbase" flag in the UTXO set, set when the output is created.

I said require all scrptPubkeys to have op_maturity/rcltv/csv 100+, but
yeah, that would work.

Regarding nKillTime, please call it nExpiryTime. And instead of fill or
kill transactions, ttansactions that expire. It is not only more accurate
(ie fill or kill is for market orders that complete in their full amount
now or are cancelled, not for transfers) and it is the term we have been
using for years.

Reinventing the wheel by changing its name it's something we do often (for
example, rcltv was op_maturity in February 2014 and was "reinvented" as
rcltv recently. This makes it harder for people to learn and follow up.
Please don't insist in fok, that's for market orders and works differently
than expiries. Expiry is the old name and it's also much more accurate.

>
> iQE9BAEBCgAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJV+0Ip
> AAoJEMCF8hzn9Lncz4MIAIQpz7tKbmjEuETX6BnPatJ50I+kS6CQ4eE+e1irXpbb
> OCMe0A2TGzw9G5t7DgMU1lCcbcbuqOxMOrHYXuGsGkpVtRrLFbkS/F9vCS2RJT0w
> kRkL2ecN8riAjh1lUUgY1CEgVyhkwh6Rw1ZALu3Ba2tISysMfXjAW1GiLHlgxP7g
> xD6zS0OTTokG/7+s1hGK2Nd4q/ZHnfOO1JgiBzrykGNq4enp7nRhiZKhnc/0ILJA
> 3WAsAMI14ZUxs95onjey7J3100tZBetYr14jzLRvf+w1klBNSvcen9dr+VhdyXYk
> MPMOwuUtq4OI1vt3HDoMjNFT6olg0gTxzWe8Grn96S4=
> =pP3Q
> -END PGP SIGNATURE-
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Fill-or-kill transaction

[jl2012 via bitcoin-dev]

Btc Drak 於 2015-09-18 02:42 寫到:

On Fri, Sep 18, 2015 at 4:27 AM, jl2012 via bitcoin-dev
 wrote:


Btc Drak 於 2015-09-17 15:12 寫到:


Forgive me if I have missed the exact use-case, but this seems
overly
complex. Surely fill-or-kill refers to getting a transaction
confirmed
within a few confirms or to drop the tx from the mempool so it
wont be
considered for inclusion anymore. As such, you could just
repurpose a
small range of nLocktime such that a TX will be accepted into
mempool
for a specific period before expiring.


What I'm describing is to implement fill-or-kill as consensus rule.
Certainly, we could implement it at the P2P network level:
everything is the same as I described, but the nLockTime2 and
nKillTime are for reference only and tx validity depends only on the
nLockTime. Benevolent miners should drop the tx after the suggested
kill time but there is no guarantee


Sure, you can make the scheme I describe consensus based by adding the
rule tx is not valid to mine after expiry: this still keeps the
simplicity I described.


If you simply redefine a range of unused nLockTime as nKillTime, users 
will be constrained to use either nLockTime or nKillTime, but not both 
in the same tx.


If we are willing to scarify a large range of tx nVersion, say 
10-15bits, the nKillTime data could be embedded there.


Another option is nSequence, which will allow per-input nKillTime and 
nLockTime.


The cleanest way, of course, is a hardfork to add a new nKillTime field 
to the tx so people could use nLockTime and nKillTime in parallel.



___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Eric Lombrozo via bitcoin-dev]

You're aware that my entire stack was built around this model and I've even 
built a fully fledged desktop GUI, multisig account manager, and servers 
supporting pull and event subscription atop it, right?

On September 17, 2015 5:07:20 PM PDT, "Wladimir J. van der Laan via 
bitcoin-dev"  wrote:
>On Wed, Sep 16, 2015 at 06:29:28PM -0400, Peter Todd via bitcoin-dev
>wrote:
>
>> I've run into a number of cases where companies were maintaining
>forks
>> of Bitcoin Core unnecessarily, where a different, loosely coupled,
>> architecture could do what they needed to do without including the
>new
>> logic in the codebase itself.
>
>This is the same point I have been making to Jeff privately.
>
>Refactors are a means to an end: a more modular, reusable and
>maintainable codebase. This goal is that new functionality can be
>plugged in more easily, and rebase work for e.g. functionality built on
>top can go down, not up, if it just hooks into well-defined interfaces
>here and there.
>
>Although there has been a lot of progress, bitcoind's design is still
>too monolithic. To add a more involved feature, like say a new index
>over the block chain data, code needs to be touched all over the place.
>This change interacts with all other functionality, potentially
>breaking the base node functionality - risk for users that do NOT use
>the functionality. This increases risk and review time.
>
>- *If possible* functionality should be built without changing
>bitcoind's code at all. An external process should be able to keep up
>to date with the chain, notice reorgs, and process block data
>accordingly. If bitcoind's interface does not allow that, or it is too
>difficult, that is what should be fixed. 
>- *if not possible* then a change should at least touch the code in as
>few places as possible, and integrate with e.g. signal notification.
>
>To name an example of it done right, IMO: Monero's 'simplewallet'. It
>is a command-line utility wallet that communicates with the node
>software, and remembers where it was in the chain, and processes
>changes to the chain state since its last invocation when it
>'refreshes'. 
>What is nice is that one can run an arbitary number of simplewallets
>against one node daemon, and unlike bitcoind's wallet it doesn't need
>to run as always-on daemon itself. It can be invoked when the user
>wants to do something with the wallet, or see if there are new
>transactions.
>
>An index could be implemented entirely externally in a similar way,
>while still fully handling reorgs.
>
>What one needs for that, I think, is a library that communicate with
>the node, and which offers functionality abstractly be similar to 'git
>pull': give me the tree path from my current known tip to the best tip,
>and supply the block hashes (and block data) along the way. 
>
>My long-term vision of bitcoind is a P2P node with validation and
>blockchain store, with a couple of data sources that can be subscribed
>to or pulled from.
>
>Wladimir
>___
>bitcoin-dev mailing list
>bitcoin-dev@lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Eric Lombrozo via bitcoin-dev]

I love the weekly meeting idea...but timezones might be an issue.

My general preference would be afternoons to late evenings pacific time, but 
that translates to late night/early morning for those in europe.

On September 18, 2015 12:04:58 AM PDT, Jonas Schnelli via bitcoin-dev 
 wrote:
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA256
>
>> On Friday, September 18, 2015 1:07:10 AM Wladimir J. van der Laan
>> via bitcoin-dev wrote:
>>> At Monday's code sprint we had a good idea to schedule a regular
>>> developer meeting in #bitcoin-dev.
>>> 
>>> Attendance is of course voluntary, but it may be good to have a
>>> time that many people are expected to be present and current
>>> issues can be discussed.
>> 
>> I think it's important to make a point that these meetings are for
>>  discussions, and explicitly never decisions, to avoid a repeat of
>> the P2SH events when people have to miss it.
>> 
>>> Any preference for days/times?
>>> 
>>> What about e.g. every week 15:00-16:00 UTC on Thursday?
>
>+1 for the weekly IRC meetings.
>
>For time and date maybe a Doodle could help:
>http://doodle.com/poll/cihug53sa8u4h2in#table
>
>
>- ---
>jonas
>-BEGIN PGP SIGNATURE-
>Version: GnuPG v2
>
>iQIcBAEBCAAGBQJV+7eaAAoJECnUvLZBb1PsESgQAIQnHDe7owv3OzMvxwupzGaD
>IkTsRtCTSntIb75Wb/KYc0y1L3ilSENRTfZ4nNc4QquqTstkhjU5t+u9T3Mak4D3
>2/5AOiJhV6OLYav1SC7uSJh0B4halnZlTwclU7NOvmnkg40DUpNxmEbf+RvUZup3
>J0EQFxIuhtjIz0HfZTvw6wmstrP3+UJZTbM5fg0FO3TpgmGybAUoQ3eWgRa7v/gR
>OUxnAV//Mus2O80/Z+c5KycZ1Dqc/iN7cQsQFt7kEIK0epkJhkTjoRrW9MyQW04d
>1jv7d0mjEJt+2EiC8UuwpaW2eFmeFnGR0pL4UCY1QsDzGENyHKNbrVg26v1AzIbB
>SNEYN1+fmsXQYosY5t0Z887Ij+u4/GLHciimh5z7fbI5VB1Ng6Wl84maVmP5Zb3L
>MHtkIqQ00RX7GIXUp5+u7eKOO0pH9S08tqo5Ag6ceynJ2lh4Wr8BCNghHzH+ybNJ
>NG3BaSkQmjxnWjW3XplaYyxz6E4qJ8id7qH4s0iaNKchAfXiCaBtbcMfljlyBSn/
>UbzHJk5jlWZEVpxmiMRctFxusk6GI4P+0eRTJrkffskLEjImUN93A8hOLs5Dy+gI
>mm/PZKT2S2qKKa6dlI2kpyPZuRbN7+WSi/FwI0YsUDGl+IoDSqTX7WqRY8cY40ji
>rUgzYTw3Won3BcjHTe9y
>=JsXj
>-END PGP SIGNATURE-
>___
>bitcoin-dev mailing list
>bitcoin-dev@lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Jonas Schnelli via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

> On Friday, September 18, 2015 1:07:10 AM Wladimir J. van der Laan
> via bitcoin-dev wrote:
>> At Monday's code sprint we had a good idea to schedule a regular
>> developer meeting in #bitcoin-dev.
>> 
>> Attendance is of course voluntary, but it may be good to have a
>> time that many people are expected to be present and current
>> issues can be discussed.
> 
> I think it's important to make a point that these meetings are for
>  discussions, and explicitly never decisions, to avoid a repeat of
> the P2SH events when people have to miss it.
> 
>> Any preference for days/times?
>> 
>> What about e.g. every week 15:00-16:00 UTC on Thursday?

+1 for the weekly IRC meetings.

For time and date maybe a Doodle could help:
http://doodle.com/poll/cihug53sa8u4h2in#table


- ---
jonas
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJV+7eaAAoJECnUvLZBb1PsESgQAIQnHDe7owv3OzMvxwupzGaD
IkTsRtCTSntIb75Wb/KYc0y1L3ilSENRTfZ4nNc4QquqTstkhjU5t+u9T3Mak4D3
2/5AOiJhV6OLYav1SC7uSJh0B4halnZlTwclU7NOvmnkg40DUpNxmEbf+RvUZup3
J0EQFxIuhtjIz0HfZTvw6wmstrP3+UJZTbM5fg0FO3TpgmGybAUoQ3eWgRa7v/gR
OUxnAV//Mus2O80/Z+c5KycZ1Dqc/iN7cQsQFt7kEIK0epkJhkTjoRrW9MyQW04d
1jv7d0mjEJt+2EiC8UuwpaW2eFmeFnGR0pL4UCY1QsDzGENyHKNbrVg26v1AzIbB
SNEYN1+fmsXQYosY5t0Z887Ij+u4/GLHciimh5z7fbI5VB1Ng6Wl84maVmP5Zb3L
MHtkIqQ00RX7GIXUp5+u7eKOO0pH9S08tqo5Ag6ceynJ2lh4Wr8BCNghHzH+ybNJ
NG3BaSkQmjxnWjW3XplaYyxz6E4qJ8id7qH4s0iaNKchAfXiCaBtbcMfljlyBSn/
UbzHJk5jlWZEVpxmiMRctFxusk6GI4P+0eRTJrkffskLEjImUN93A8hOLs5Dy+gI
mm/PZKT2S2qKKa6dlI2kpyPZuRbN7+WSi/FwI0YsUDGl+IoDSqTX7WqRY8cY40ji
rUgzYTw3Won3BcjHTe9y
=JsXj
-END PGP SIGNATURE-
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev