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

[Justus Ranvier via bitcoin-dev]

On 19/09/15 15:11, Rune K. Svendsen wrote:
> An honest miner is a miner that supports the network by building on top of 
> the best valid chain. A malicious miner is one who wants to disrupt the 
> Bitcoin network, not support it, for example by executing a 51% attack which 
> mines empty blocks on top of the best chain.

This isn't a particularly good definition.

"An honest miner is a miner that supports the network by building on top
of the best valid chain."

What is the "best valid chain"? The one with the most proof of work? The
one that meets some other definition of "best"?

"A malicious miner is one who wants to disrupt the Bitcoin network, not
support it"

This is a tautology, the equivalent of saying "a malicious miner is a
miner that is malicious" A true, but entirely useless, statement.

"for example by executing a 51% attack which mines empty blocks on top
of the best chain."

Again, you're begging the question with the word "attack", because
that's what you're supposed to demonstrate.

Apparently the difference between honest mining and malicious mining is
empty blocks? You've said in both cases the miners are extending the
"best valid chain". Is extending the best valid chain with an empty
block always a malicious act?

What's the significance of 51% in this definition? Is the same empty
block which extended the best valid chain honest if the miner who
produced it has 49% of the network hashing power and malicious if they
add a few more ASIC units?

-- 
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] Proposed new policy for transactions that depend on other unconfirmed transactions

[Alex Morcos via bitcoin-dev]

Thanks for everyone's review.  These policy changes have been merged in to
master in 6654 , which just
implements these limits and no mempool limiting yet.  The default ancestor
package size limit is 900kb not 1MB.

Yes I think these limits are generous, but they were designed to be as
generous as was computationally feasible so they were unobjectionable
(since the existing policy was no limits).  This does not preclude future
changes to policy that would reduce these limits.





On Fri, Aug 21, 2015 at 3:52 PM, Danny Thorpe 
wrote:

> The limits Alex proposed are generous (bordering on obscene!), but
> dropping that down to allowing only two levels of chained unconfirmed
> transactions is too tight.
>
> Use case: Brokered asset transfers may require sets of transactions with a
> dependency tree depth of 3 to be published together. ( N seller txs, 1
> broker bridge tx, M buyer txs )
>
> If the originally proposed depth limit of 100 does not provide a
> sufficient cap on memory consumption or loop/recursion depth, a depth limit
> of 10 would provide plenty of headroom for this 3 level use case and
> similar patterns.
>
> -Danny
>
> On Fri, Aug 21, 2015 at 12:22 PM, Matt Corallo via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> I dont see any problem with such limits. Though, hell, if you limited
>> entire tx dependency trees (ie transactions and all required unconfirmed
>> transactions for them) to something like 10 txn, maximum two levels
>> deep, I also wouldnt have a problem.
>>
>> Matt
>>
>> On 08/14/15 19:33, Alex Morcos via bitcoin-dev wrote:
>> > Hi everyone,
>> >
>> >
>> > I'd like to propose a new set of requirements as a policy on when to
>> > accept new transactions into the mempool and relay them.  This policy
>> > would affect transactions which have as inputs other transactions which
>> > are not yet confirmed in the blockchain.
>> >
>> > The motivation for this policy is 6470
>> >  which aims to limit the
>> > size of a mempool.  As discussed in that pull
>> > ,
>> > once the mempool is full a new transaction must be able to pay not only
>> > for the transaction it would evict, but any dependent transactions that
>> > would be removed from the mempool as well.  In order to make sure this
>> > is always feasible, I'm proposing 4 new policy limits.
>> >
>> > All limits are command line configurable.
>> >
>> > The first two limits are required to make sure no chain of transactions
>> > will be too large for the eviction code to handle:
>> >
>> > Max number of descendant txs : No transaction shall be accepted if it
>> > would cause another transaction in the mempool to have too many
>> > descendant transactions (all of which would have to be evicted if the
>> > ancestor transaction was evicted).  Default: 1000
>> >
>> > Max descendant size : No transaction shall be accepted if it would cause
>> > another transaction in the mempool to have the total size of all its
>> > descendant transactions be too great.  Default : maxmempool / 200  =
>> 2.5MB
>> >
>> > The third limit is required to make sure calculating the state required
>> > for sorting and limiting the mempool and enforcing the first 2 limits is
>> > computationally feasible:
>> >
>> > Max number of ancestor txs:  No transaction shall be accepted if it has
>> > too many ancestor transactions which are not yet confirmed (ie, in the
>> > mempool). Default: 100
>> >
>> > The fourth limit is required to maintain the pre existing policy goal
>> > that all transactions in the mempool should be mineable in the next
>> block.
>> >
>> > Max ancestor size: No transaction shall be accepted if the total size of
>> > all its unconfirmed ancestor transactions is too large.  Default: 1MB
>> >
>> > (All limits include the transaction itself.)
>> >
>> > For reference, these limits would have affected less than 2% of
>> > transactions entering the mempool in April or May of this year.  During
>> > the period of 7/6 through 7/14, while the network was under stress test,
>> > as many as 25% of the transactions would have been affected.
>> >
>> > The code to implement the descendant package tracking and new policy
>> > limits can be found in 6557
>> >  which is built off of
>> 6470.
>> >
>> > Thanks,
>> > Alex
>> >
>> >
>> >
>> > ___
>> > 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.lin

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

[gb via bitcoin-dev]

Although the planning for this a bit far along now, one consideration I
might add from experience on working with other transglobal IT projects
is the effect of timezones on local mood/alertness/awareness etc. The
guys at 9am pinging on their first coffee in the antipodes will be in a
different mindset than those at 21:00 in Europe, and this is
unavoidable. What is possible is to schedule the meeting every other
week at a time that is better for the "other" half, whoever that might
be. This comes at the cost of not having an exactly same time set every
week.

On Mon, 2015-09-21 at 15:29 +0200, Wladimir J. van der Laan via
bitcoin-dev wrote:
> On Fri, Sep 18, 2015 at 03:07:10AM +0200, Wladimir J. van der Laan 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?
> 
> From Jonasschnelli's doodle ( http://doodle.com/poll/cihug53sa8u4h2in#table ) 
> it appears that Thursday 19:00 UTC - 20:00 UTC is the most popular time.
> 
> I think scheduling the meeting in UTC (=Iceland time) makes sense 
> internationally because different locales have different DST or no DST at 
> all, so all in all that makes it more complex. It's true that this can make a 
> convenient time less convenient half of the year, for some people, but I 
> don't think there's a time that works for everyone anyway...
> 
> 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] Weekly development meetings on IRC

[Wladimir J. van der Laan via bitcoin-dev]

On Fri, Sep 18, 2015 at 03:07:10AM +0200, Wladimir J. van der Laan 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?

>From Jonasschnelli's doodle ( http://doodle.com/poll/cihug53sa8u4h2in#table ) 
>it appears that Thursday 19:00 UTC - 20:00 UTC is the most popular time.

I think scheduling the meeting in UTC (=Iceland time) makes sense 
internationally because different locales have different DST or no DST at all, 
so all in all that makes it more complex. It's true that this can make a 
convenient time less convenient half of the year, for some people, but I don't 
think there's a time that works for everyone anyway...

Wladimir
___
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

[jl2012 via bitcoin-dev]

It is possible to softfork. Just use Iceland time. Iceland time = UTC 
without DST


Btc Drak via bitcoin-dev 於 2015-09-18 16:34 寫到:

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


___
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

[Milly Bitcoin via bitcoin-dev]

On 9/21/2015 1:04 AM, Corey Haddad via bitcoin-dev wrote:
> If it turns out that the blocksize divide is hinging on differing
> developer views on the nature of the threat posed by governments,
> perhaps it would be better to defer to people who specialize in that
> area.  ...
...
> The main idea here is that if this is a politics question, please
> consider you may be outside your area of expertise.


That is a great suggestion.  Jerry Brito is the number one guy to go to 
for this information.  You will find that many early Bitcoiners are 
completely clueless as to the motivations of regulators.  However, you 
still have the problem that some influential developers know Bitcoin but 
otherwise are completely ignorant.  They will go around claiming 
everyone who discusses regulation is a "statist" and so forth.  Some 
people on this list actually claimed I am "statist" simply by pointing 
out that governments do both good and bad things and that most people 
trust and depend on governments to a certain extent.  That is simply a 
fact, it does not support any agenda.


Another example are the developers who are going around claiming a 
stress test is a criminal action against those running nodes.  Such a 
claim brings all kinds of complicated legal questions about the 
liability of people running nodes.  Instead of contacting someone who 
researched the issue (such as Peter Šurda who ended up posting several 
sensible replies) the developer posted some hyperbolic article on Reddit 
which did nothing but promote misinformation.  On top of that it makes 
Bitcoiners look totally ridiculous.  One day they claim Bitcoin will 
collapse all these government institutions and the next day they want 
those same government institutions to arrest people for overflowing 
their memory pool.


One final issue about the conference ... the developers should not be 
accepting advertisers engaged in nefarious activities.  In particular 
BicoinTalk was accepted as an advertiser.  It is well known that site 
has promoted fake banks where many users lost money 
(CoinLeders/Inputs.io), illegal investments schemes where,any people 
lost funds (BLBSE) and whole host of questionable, illegal, immoral, and 
unethical activities.  Just because the guy who runs the site wrote a 
block explorer that does not mean the developers should blindly promote 
a highly questionable web site that damages Bitcoin's reputation.  The 
people running these events need to start acting responsibly.


Russ










___
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  writes:
> On Sep 20, 2015 10:58 PM, "Rusty Russell"  wrote:
>>
>> Jorge Timón  writes:
>> > 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.
>>
>> Thanks, I'll have to dig through bitcoin-dev and find it.
>
> The initial thread is linked to from the BIP document (which is in the
> bitcoin/bips PR).

Thanks, read and digested.

The good news is that timeout via GetMedianTimePast() doesn't have any
effect on "should I accept this to mempool", and seems pretty
uncontroversial.   Activation is by block number once vote hits 95%, so
that too is fairly simple to implement.

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]

>
> Does this conversation have to happen on-list? It seems to have wandered
> incredibly far off-topic.
>

I understand, it does seem off topic. But . what was the topic again?
All Jeff's mail and the followups seem to say is there was a meeting where
some people (unnamed) agreed to do something (unspecified) if the metric
used is modified (which doesn't change the fundamental issues).

So there isn't really much on-topic to discuss. If/when Wladimir starts a
thread, with a BIP, and says "this is how it's gonna be in Bitcoin Core",
then there will be things to discuss.
___
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]

>Larger user base won't necessarily protect against governments if 
>we still have chokepoints they can go after.

This is the critical confusion about Bitcoin decentralization, which leads to 
this whole recent mess of shouting at each other.

Decentralization is _not_ a way to withstand an attack, if the government "goes 
after you".

Many people got this idea drilled into their heads in the previous years, that 
Bitcoin is a "movement" to fight governments, and decentralization is its main 
weapon.

They confuse Bitcoin and Anonymous.


>What we really need to grow is the number of nodes on the network 
>that participate in its basic infrastructure - namely: miners, validators, 
>etc...

Absolutely. Nobody argues that we shouldn't care about decentralization.

But who's gonna pay for all this? What are the incentives?

We need Bitcoin to get much more popular for this to happen.

___
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]

On Sep 20, 2015 10:58 PM, "Rusty Russell"  wrote:
>
> Jorge Timón  writes:
> > 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.
>
> Thanks, I'll have to dig through bitcoin-dev and find it.

The initial thread is linked to from the BIP document (which is in the
bitcoin/bips PR).
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev