Re: [bitcoin-dev] Bitcoin-NG whitepaper.

[odinn via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello, and thanks for the reply.  I don't think you are missing
anything, I'll continue to observe this thread for further details and
developments on NG generally, security, & privacy.

Ittay:
> Hi Odinn,
> 
> I guess to answer we should separate pure-NG from the hypothetical
> overlay-NG that runs on top of Bitcoin. For pure NG one still has
> to set a transaction bandwidth limit due to bandwidth and storage
> limitations of the individual clients. This rate can be arbitrarily
> high with NG without compromising protocol security.
> 
> With overlay NG you cannot run above Bitcoin's bandwidth because
> all clients must agree on the ledger, so different clients cannot
> run at different rates. You could do two things: 1. Significantly
> reduce observed latency (time to first confirmation). Users get
> better confidence as more miners adopt NG. 2. Increase the
> bandwidth once everyone is on board.
> 
> As for privacy - I don't see why NG would change things. Such
> privacy schemes are only concerned with the transaction DAG. NG
> does not touch this structure. Am I missing something?
> 
> Thanks, Ittay
> 
> 
> On Thu, Oct 15, 2015 at 4:48 AM, odinn
>  wrote:
> 
> So, there could not be, for example, a user decision to activate
> it? (versus not activate it)?  I'm wondering if something about
> this can be boiled down to allowing the user to make a choice on
> the matter (turn it on and off).  In Bitcoin-NG, the protocol as
> follows (as described in a general overview of it): every 10
> minutes, NG elects a 'leader,' who then vets future transactions as
> soon as they happen. NG approach supposedly can run as fast as the
> network will allow.
> 
> If this is the case, and if NG functions without major hiccup, 
> shouldn't a user (of Core, for example) be able to be given the
> option to choose between:
> 
> (a) being limited by the blocksize and block interval, or (b)
> running out as fast as the network will allow (NG)?
> 
> The other questions I had pertained to privacy.  How would this
> scheme affect users who would be trying to do things like stealth
> or confidential transactions?
> 
> Matt Corallo:
>>>> Huh? No... This is not a Bitcoin Core issue, it is a Bitcoin 
>>>> protocol one and should be discussed here, not on github. I
>>>> really appreciate Ittay and Emin's efforts in this space and
>>>> their willingness to work with the Bitcoin community on it!
>>>> It seems it still needs some tuning, but seems like if the
>>>> pool-mining issues were resolved it could make block relay
>>>> times irrelevant, at least.
>>>> 
>>>> Matt
>>>> 
>>>> On October 14, 2015 3:21:19 PM PDT, odinn via bitcoin-dev 
>>>>  wrote: This
>>>> (Bitcoin-NG in concept) could be done as a (issue and pull
>>>> request process) to Bitcoin Core itself, amirite?  It seems
>>>> like it would provide an interesting issue to open and have
>>>> healthy discussion on both mailing list and github, adding
>>>> the caveat that it would be at the user's option.  Thus if
>>>> something like Bitcoin-NG did come to be it would be
>>>> something more like a feature that the user could activate /
>>>> deactivate from within Core.  I assume it would be default
>>>> off, but with the option to utilize.  Code would thus be 
>>>> available to others as well.  I am not saying yea or nay on
>>>> it, just that it seems like this could be done.
>>>> 
>>>> Some notes:
>>>> 
>>>> Once a node generates a key block it becomes the leader.  As
>>>> a leader, the node is allowed to generate  microblocks  at  a
>>>> set rate smaller  than  a  prede >ned  maximum.  A
>>>> microblock in Bitcoin-NG contains  ledger  entries  and  a
>>>> header.   The  header contains the  reference  to the
>>>> previous  block,  the  current GMT  time,  a cryptographic
>>>> hash  of  its  ledger  entries,  and a cryptographic
>>>> signature  of  the  header.   The  signature  uses the
>>>> private  key that  matches  the public key in the latest key 
>>>> block in the chain. For a microblock to be valid, all its
>>>> entries must be valid according to the specification of the
>>>> state machine, and the signature has to be valid.  However,
>>>> the microblocks, it is said, don't affect the weight of the
>>>> chain, because they do not contain proof of work.  

Re: [bitcoin-dev] Bitcoin-NG whitepaper.

[odinn via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

So, there could not be, for example, a user decision to activate it?
(versus not activate it)?  I'm wondering if something about this can
be boiled down to allowing the user to make a choice on the matter
(turn it on and off).  In Bitcoin-NG, the protocol as follows (as
described in a general overview of it): every 10 minutes, NG elects a
'leader,' who then vets future transactions as soon as they happen. NG
approach supposedly can run as fast as the network will allow.

If this is the case, and if NG functions without major hiccup,
shouldn't a user (of Core, for example) be able to be given the option
to choose between:

(a) being limited by the blocksize and block interval, or
(b) running out as fast as the network will allow (NG)?

The other questions I had pertained to privacy.  How would this scheme
affect users who would be trying to do things like stealth or
confidential transactions?

Matt Corallo:
> Huh? No... This is not a Bitcoin Core issue, it is a Bitcoin
> protocol one and should be discussed here, not on github. I really
> appreciate Ittay and Emin's efforts in this space and their
> willingness to work with the Bitcoin community on it! It seems it
> still needs some tuning, but seems like if the pool-mining issues
> were resolved it could make block relay times irrelevant, at
> least.
> 
> Matt
> 
> On October 14, 2015 3:21:19 PM PDT, odinn via bitcoin-dev
>  wrote: This (Bitcoin-NG in
> concept) could be done as a (issue and pull request process) to
> Bitcoin Core itself, amirite?  It seems like it would provide an
> interesting issue to open and have healthy discussion on both
> mailing list and github, adding the caveat that it would be at the
> user's option.  Thus if something like Bitcoin-NG did come to be it
> would be something more like a feature that the user could
> activate / deactivate from within Core.  I assume it would be
> default off, but with the option to utilize.  Code would thus be
> available to others as well.  I am not saying yea or nay on it,
> just that it seems like this could be done.
> 
> Some notes:
> 
> Once a node generates a key block it becomes the leader.  As a
> leader, the node is allowed to generate  microblocks  at  a  set
> rate smaller  than  a  prede>ned  maximum.  A  microblock in
> Bitcoin-NG contains  ledger  entries  and  a  header.   The  header
> contains the  reference  to the  previous  block,  the  current
> GMT  time,  a cryptographic  hash  of  its  ledger  entries,  and
> a cryptographic signature  of  the  header.   The  signature  uses
> the  private  key that  matches  the public key in the latest key
> block in the chain. For a microblock to be valid, all its entries
> must be valid according to the specification of the state machine,
> and the signature has to be valid.  However, the microblocks, it is
> said, don't affect the weight of the chain, because they do not
> contain proof of work.  It is assumed by the authors of this model
> that this situation is critical for maintaining incentives here.
> 
> The questions that then begin to emerge to me are how is this 
> information managed and protected?  The headers, thus containing 
> reference(s) to previous block(s), current GMT time(s),
> cryptographic hash(es) of ledger entries, and cryptographic
> signature(s) of the headers, so forth, and other information.  Can
> the Bitcoin-NG scheme be designed or implemented in a manner which
> supports Stealth sends, Confidential Transactions, or similar
> privacy measures?  Or is this something which cannot be answered at
> this time?
> 
> Emin Gün Sirer via bitcoin-dev:
>>>>> So it seems to me that all I need to do is figure out who
>>>>> the current
>>>> leader is,
>>>>> and DDoS him off the network to shut Bitcoin-NG down.
>>>> 
>>>> Good point. If NG is layered on top of Bitcoin, we'd retain
>>>> all of Bitcoin as is. This would confer all the benefits of
>>>> Bitcoin's retrospective blocks, as well as add the ability to
>>>> mint microblocks with low latency in between. And despite the
>>>> phrase "the leader," the actual leader in NG is a key, not a
>>>> specific node. That makes it possible to deter DDoS attacks
>>>> by dynamically migrating where in the network the leader is
>>>> operating in response to an attack. Finally, DDoS attacks
>>>> against miners are already possible, but they seem rare, and
>>>> I suspect it's at least partly because of the success of Matt
>>>> Corallo's high speed bitcoin relay network. Similar defenses
>>>> can apply her

Re: [bitcoin-dev] Proposed list moderation policy and conduct

[odinn via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Another point building on Justus's remarks that I'll make (below)

Justus Ranvier via bitcoin-dev:
> On 14/10/15 19:02, Jeff Garzik via bitcoin-dev wrote:
>> *Disclose potential conflicts*
>> 
>> 1. List discussions often involve interested parties. We expect 
>> participants to be aware when they are conflicted due to
>> employment or other projects they are involved in, and disclose
>> those interests to other project members. 2. When in doubt,
>> over-disclose. Perceived conflicts of interest are important to
>> address, so that the lists’ decisions are credible even when 
>> unpopular, difficult or favorable to the interests of one group
>> over another.
> 
> Even if we assume everybody will try to approach that topic in
> good faith, I don't think it's that simple.
> 
> A term that's become popular recently is "Bitcoin maximalist", and
> it's frequently used as a slur or insult.
> 
> I honestly find that to be incomprehensible. If somebody at a Ford
> board meeting started talking about how Ford needed to make sure
> Toyota was able to sell enough cars, they wouldn't get very far by
> labelling their critics as "Ford maximalists".
> 
> Anyone who works at Ford and who isn't a Ford maximalist is in the
> wrong job.
> 
> And yet in Bitcoin, a much development is funded by companies who
> offer products which compete with Bitcoin, or at least would be in
> competition if Bitcoin were to achieve unlimited success.


One example that came to mind as I was reading this was, when I
presented an idea that I thought would be good for integration into
Bitcoin Core, explaining in various ways why I felt it would be
worthwhile to explore, I eventually had someone tell me I should go
and develop the idea first as either some sort of independent wallet,
or to demonstrate it would work via an alt.  (This has now occurred,
as a successful implementation of my micro-donations idea has been
demonstrated in an alt.)  I have to wonder, however, when I eventually
bring the micro-donation ideas back in such a form that they could
again be considered in bitcoin-dev, whether or not they would
seriously be considered, in part due to this effect which Justus
Ranvier has described in part ~ that is to say, the effect of people
engaging in the use of "maximalist" or some other label (or labels) as
limiting the extent of discourse which people can engage in.  (I
realize that wasn't exactly where you were going with this Justus, but
I'm just expanding upon the notion of how some labels and categories
can be used to suppress real discussion.)  Or, for example, if people
see me as "conflicted," and someone else doesn't, and I'm confused
about why someone would see me as "conflicted," where does that leave
one?  Quite possibly, stuck in a morass of unproductive commentary (or
maybe just being ignored by moderators who might see quite a few
people as "conflicted").

> 
> I expect this is a minority view on this list, but my position is
> that anyone who is not a Bitcoin maximalists has a potential
> conflict of interest if they're also involved in Bitcoin
> development.
> 
> I also suspect this issue is a cause of much user dissatisfaction
> with Bitcoin development. If Bitcoin users and investors don't
> trust that the developers are working toward the unlimited success
> case, they can and will revolt.
> 

Another thing to consider, although the person(s) proposing the list
moderation policy and conduct document will certainly not want to hear
it, is that the list might be better off without a policy document
that is enforced by moderators.  (An "about" section for what the list
is about, its purpose, and how people are supposed to treat each
other, is probably good... but the enforcement angle that I'm seeing
is probably a bad idea.)  What we stand for here is more than making
people comfortable while technical issues are discussed on a list.
The idea of keeping a protocol free of financial censorship, in
concept, extends to language as well, and thus people should be able
to be free in how they write and speak, even when their peers on the
list don't like what they see in others' expressions.

I recommend removal of the enforcement and moderator sections.
(Technically, there are mods for it already... I suppose... the
question is how you disclose in a "Purpose" or "About" section that
refers to this list who the mods are, or rather, what the roles are of
each person involved in a way that is minimally invasive and lets the
list flow.)

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

- -- 
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJWH2YLAAoJEGxwq/inSG8C0aAH/AqYWgZEyRM5d1rAwjt6jNrf
Vqkd+kBCu0+

Re: [bitcoin-dev] Proposed list moderation policy and conduct

[odinn via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512


I am concerned that someone will always call "off topic" regardless of
how on-topic something actually is.  There is no objective measure of
on-topicness here (or hasn't been) unless we say it has to do with
bitcoin development.

If you say, "Conversations should remain focused and on-topic," as you
have suggested, then presumably you mean, as has also been suggested
in the proposed list moderation policy and conduct document, that we

"aim to facilitate constructive discussion
of issues related to technical development of the bitcoin protocol and
the Bitcoin Core reference implementation"

and thus, that "on-topic" conversations would necessarily be "related
to technical development of the bitcoin protocol and the Bitcoin Core
reference implementation."

Unfortunately, while that is fairly specific to what this list is
about, I think it still will result in a lot of people shouting "Off
Topic!" whenever someone mentions something that might even be
remotely and slightly off the the range.  Thus, I don't think the
current language in the proposed list moderation policy and conduct
document is really that good, and needs much more discussion and
refinement before, well, anything.  It would be a shame if every time
someone brings up something innovative, new or wonderful, or explores
something on the boundaries, they are shouted down with cries of "Off
Topic!" Which, by the way, I see happening A Lot on this list.

Specifically relating to the subject of Disclosure,
It is suggested that people here
"*Disclose potential conflicts*"

"1. List discussions often involve interested parties. We expect
participants to be aware when they are conflicted due to employment or
other projects they are involved in, and disclose those interests to
other project members.
2. When in doubt, over-disclose. Perceived conflicts of interest are
important to address, so that the lists’ decisions are credible even
when unpopular, difficult or favorable to the interests of one group
over another."

I don't doubt that this is a fine plan, but those who work for three
letter agencies or have simply signed NDAs (as an example) aren't
going to disclose anything, nada ~ but will be here anyway, pushing
their personal interests.  Reality.

Looking forward to discussion.

Cheers,

O

Luke Dashjr via bitcoin-dev:
> On Thursday, October 15, 2015 12:02:21 AM Jeff Garzik via
> bitcoin-dev wrote:
>> 2. If someone asks for help it is because they need it. Politely
>> suggest specific documentation or more appropriate venues where
>> appropriate. Avoid aggressive or vague responses.
> 
> This could get noisy. Clarification that only *development* help is
>  appropriate for the list would improve it.
> 
>> 2. Conversations should remain focused and on-topic. If you must
>> change the topic, start a new thread by changing the topic line
>> of your emails.
> 
> Probably should note that entirely new threads should be new
> messages, *not* merely a reply with a changed topic (as changing
> the topic does not in fact start a new thread).
> 
>> 4. Off-topic threads will be directed to other venues.
> 
> Threads like this one are off-topic, yet we have no obvious other
> venue for it.. :(
> 
>> *Disclose potential conflicts*
> 
> IMO this seems like not only a waste of time, but also futile for
> anyone not exclusively associated with a single
> company/organization.
> 
>> If you have concerns about someone’s conduct: * *On-list*:
>> discussing conduct on-list, either as part of another message or
>> as a standalone thread, is always acceptable.
> 
> Please no. This is off-topic noise.
> 
> Luke ___ bitcoin-dev
> mailing list bitcoin-dev@lists.linuxfoundation.org 
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 

- -- 
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJWHvYPAAoJEGxwq/inSG8C/AgIAKxEOZpQ5O7cdAGcBceE840d
1Jv29kfErv/+vuasCumbF6yCRljJGqeU/t7YmoWcQzSD5jijBbZ7uB7yXBsoJwyg
xELeEAzV2t7v7zLxi569xVKvdaMrIYvwPB2uOQsfmqZ2+PrSlBsRIhcgB9zeuVyK
5Mtb0cHJx7aDmBhhC4r1IQGNfa8zzfdsNU4BqHR2/l6NmH29p9tb7DPC+83O6xY+
ODn6gDRAFsjC+Cy3gsLNf1J4hEvGOkkSVMJIHEmkdJx2gN306rbc7X7DK7CSQX3E
vmhAmDj419dpTvciOEjuiROGDhawPnBsO37UZJIVC/6yWe4sDk5JvQULU2HiyDo=
=T4vL
-END PGP SIGNATURE-
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin-NG whitepaper.

[odinn via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

This (Bitcoin-NG in concept) could be done as a (issue and pull
request process) to Bitcoin Core itself, amirite?  It seems like it
would provide an interesting issue to open and have healthy discussion
on both mailing list and github, adding the caveat that it would be at
the user's option.  Thus if something like Bitcoin-NG did come to be
it would be something more like a feature that the user could activate
/ deactivate from within Core.  I assume it would be default off, but
with the option to utilize.  Code would thus be available to others as
well.  I am not saying yea or nay on it, just that it seems like this
could be done.

Some notes:

Once a node generates a key block it becomes the leader.  As a leader,
the node is allowed to generate  microblocks  at  a  set  rate
smaller  than  a  predened  maximum.  A  microblock in Bitcoin-NG
contains  ledger  entries  and  a  header.   The  header  contains
the  reference  to the  previous  block,  the  current  GMT  time,  a
 cryptographic  hash  of  its  ledger  entries,  and  a cryptographic
 signature  of  the  header.   The  signature  uses  the  private  key
 that  matches  the public key in the latest key block in the chain.
For a microblock to be valid, all its entries must be valid according
to the specification of the state machine, and the signature has to be
valid.  However, the microblocks, it is said, don't affect the weight
of the chain, because they do not contain proof of work.  It is
assumed by the authors of this model that this situation is critical
for maintaining incentives here.

The questions that then begin to emerge to me are how is this
information managed and protected?  The headers, thus containing
reference(s) to previous block(s), current GMT time(s), cryptographic
hash(es) of ledger entries, and cryptographic signature(s) of the
headers, so forth, and other information.  Can the Bitcoin-NG scheme
be designed or implemented in a manner which supports Stealth sends,
Confidential Transactions, or similar privacy measures?  Or is this
something which cannot be answered at this time?

Emin Gün Sirer via bitcoin-dev:
>> So it seems to me that all I need to do is figure out who the
>> current
> leader is,
>> and DDoS him off the network to shut Bitcoin-NG down.
> 
> Good point. If NG is layered on top of Bitcoin, we'd retain all of
> Bitcoin as is. This would confer all the benefits of Bitcoin's
> retrospective blocks, as well as add the ability to mint
> microblocks with low latency in between. And despite the phrase
> "the leader," the actual leader in NG is a key, not a specific
> node. That makes it possible to deter DDoS attacks by dynamically
> migrating where in the network the leader is operating in response
> to an attack. Finally, DDoS attacks against miners are already 
> possible, but they seem rare, and I suspect it's at least partly
> because of the success of Matt Corallo's high speed bitcoin relay
> network. Similar defenses can apply here.
> 
> - egs
> 
> 
> 
> On Wed, Oct 14, 2015 at 2:20 PM, Bob McElrath 
> wrote:
> 
>> So it seems to me that all I need to do is figure out who the
>> current leader is, and DDoS him off the network to shut
>> Bitcoin-NG down.
>> 
>> This is a significant advantage to bitcoin's ex-post-facto
>> blocks: no one knows where the next one will come from.  The only
>> way to shut the network down is to shut all nodes down.
>> 
>> Emin Gün Sirer via bitcoin-dev
>> [bitcoin-dev@lists.linuxfoundation.org] wrote:
>>> Hi everyone,
>>> 
>>> We just released the whitepaper describing Bitcoin-NG, a new
>>> technique
>> for
>>> addressing some of the scalability challenges faced by
>>> Bitcoin.
>> Surprisingly,
>>> Bitcoin-NG can simultaneously increase throughput while
>>> reducing
>> latency, and
>>> do so without impacting Bitcoin's open architecture or changing
>>> its trust model. This post illustrates the core technique: 
>>> http://hackingdistributed.com/2015/10/14/bitcoin-ng/ while the
>>> whitepaper has all the nitty gritty details: 
>>> http://arxiv.org/abs/1510.02037
>>> 
>>> Fitting NG on top of the current Bitcoin blockchain is future
>>> work that
>> we
>>> think is quite possible. NG is compatible with both Bitcoin as
>>> is, as
>> well as
>>> Blockstream-like sidechains, and we currently are not planning
>>> to compete commercially with either technology -- we see NG as
>>> being complementary
>> to both
>>> efforts. This is pure science, published and shared with the
>>> community to advance the state of blockchains and to help them
>>> reach throughputs and latencies required of cutting edge
>>> fintech applications. Perhaps it can
>> be
>>> adopted, or perhaps it can provide the spark of inspiration for
>>> someone
>> else to
>>> come up with even better solutions.
>>> 
>>> We would be delighted to hear your feedback. - Ittay Eyal and
>>> E. Gün Sirer.
>>> 
>>> !DSPAM:561e98cd301391127216946!
>> 
>>> 

Re: [bitcoin-dev] Memory leaks?

[odinn via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

For the record, Mr. Hearn, you do not own this list.  I submit to you
that you have very little to say on this matter at this stage and your
idle threats to "ban people" based on their preferences, suggestions,
or characterizations of your chosen software project are at best very
silly.

I am not and never was on bitcoin...@googlegroups.com and thus have
clipped that from the reply-to.

Mike Hearn via bitcoin-dev:
> Leaks are not the only explanation possible. Caches and
> fragmentation can also give this sort of effect. Unfortunately the
> tools to debug this aren't great. You could try a build with
> tcmalloc and use it to investigate heap stats.
> 
> Odinn, trolling like a 3 year old will get you swiftly banned. Last
> warning. On 14 Oct 2015 9:58 am, "Tom Zander" 
> wrote:
> 
>> On Tuesday 13 Oct 2015 14:56:08 Jonathan Toomim  via bitcoin-dev
>> wrote:
>>> Does anybody have any guesses where we might be leaking memory,
>>> or what
>> is
>>> using the additional 2.4 GB? I've been using
>>> minrelaytxfee=0.3 or similar on my nodes. Maybe there's a
>>> leak in the minrelaytxfee code path? Has anyone else seen
>>> something similar?
>> 
>> I suggest running it in valgrind with --leak-check=full for 10
>> minutes.
>> 
>> valgrind --leak-check=full src/bitcoind 2>&1 | tee out
>> 
>> This at least will show you any memory leaks at exit. Naturally,
>> the leaks you observe may just be design issues where cache can 
>> grow to much and when the cache is cleaned on shutdown you won't
>> see it in the valgrind output.
>> 
>> -- You received this message because you are subscribed to the
>> Google Groups "bitcoin-xt" group. To unsubscribe from this group
>> and stop receiving emails from it, send an email to
>> bitcoin-xt+unsubscr...@googlegroups.com. For more options, visit
>> https://groups.google.com/d/optout.
>> 
> 
> 
> 
> ___ bitcoin-dev mailing
> list bitcoin-dev@lists.linuxfoundation.org 
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 

- -- 
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJWHnKFAAoJEGxwq/inSG8CoN8H/i4m748xSMkXLgsOO2nqghXr
K3EI98BucU5XF4M/0qW0EjN1PHdkl+EjtUt0POT3mG3hl66PaoA04nMgDrND7V+w
sEXICchAVNx5+AleT65U60iibASZZIlZaXmOtdtCgz7GulmMfsfnNV2IRRvsSO1A
Nl0PuEqPW1/rsJDA58tDb8y2ltMEo5Zi2AYDMvD/AfSuNBqdHM/2IrWSPUwDB7NN
TLq5WXyW5mv7qywIu3/8jk0za6RN4gc1DmpIJHjm4bO+4FoF0oytcaOg5X8uOC1B
pOxhvEM2fTjziXaBJVha/6lrGxfi8/mdLBE68hjB3Q6/KDF9VrugdG0JK0iuDW8=
=YqPh
-END PGP SIGNATURE-
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Memory leaks?

[odinn via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

You wanted advice... you got it

Jonathan Toomim (Toomim Bros):
> 
> On Oct 13, 2015, at 3:49 PM, odinn
>  wrote:
> 
>> Signed PGP part It would also help to know what operating
>> system(s) you are using for both the oldie and the freshie.
> 
> Linux feather 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1+deb8u3
> (2015-08-04) x86_64 GNU/Linux Linux server 3.2.0-4-amd64 #1 SMP
> Debian 3.2.60-1+deb7u3 x86_64 GNU/Linux Linux prime 3.2.0-4-amd64
> #1 SMP Debian 3.2.63-2+deb7u2 x86_64 GNU/Linux
> 
> This excessive memory consumption was seen on 3 machines, all of
> which run Debian. All three machines run p2pool as well as
> bitcoind. Two run XT, one runs Core.
> 
>> 
>> You should compare this to having set up a node on a completely
>> clean computer.
> 
> 
> I can't afford to do that. All of the servers I have are being used
> for something. Also, I'm not sure what it is you're trying to test
> for with that suggestion. The numbers I'm reporting are for
> bitcoind's resident set, not for the whole server's memory usage. I
> don't see how other processes running on the same machine are
> relevant unless you are suggesting that RPC calls (e.g.
> getblocktemplate) might be somehow responsible.
> 
>> 
>> Also, dump your XT, is poo.
> 
> 
> Not relevant. I addressed this message to both the Core and XT
> lists because the issue appears to affect both forks. Let's keep
> blocksize and governance debates to their own threads, please.
> 
> Repeating request: Has anyone else seen something similar? Can you
> report your mempool size and total bitcoind resident set size for
> your running full nodes?
> 

- -- 
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJWHZrZAAoJEGxwq/inSG8CZzQIAKsqKs//Wydv60nXgy5AWAPU
qZ9HuyyWXDKljxzv/Ky5jS7o7B8Ivhnt6zWvkpMTF/R9MLpGrS9jBxXZjHF//ET0
L+eoVrmxwt+rgSjIPSGU/ftF8Jnh1sELecR8FMuCaFR87xraR/7FsJF/233RLWFg
+scNiFEgttyizFNgSq2r1/N3G5e603qXfh0+reaabDX3E+8+PKyUqVaG5E+TUEW0
NIkqi7MuEYd+/Q0SGAYyY/j2BQnebsTB2TbupE/soJkAYqYbCQR8TtrctmwLXTL0
GN+WyWwLYpMio3+7a6oQJ67TBcFxCVmF81zxKM1VIoT0u39VVWeYD1YfxEYFN9Y=
=a6kH
-END PGP SIGNATURE-
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Memory leaks?

[odinn via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

You should compare this to having set up a node on a completely clean
computer.  It would also help to know what operating system(s) you are
using for both the oldie and the freshie.

Also, dump your XT, is poo.  Then try again, look at Core nodes on
your oldie and freshie.  Watch them for a bit.

Cheers,

O

Jonathan Toomim (Toomim Bros) via bitcoin-dev:
> I just noticed that several of my running bitcoind processes were
> using around 3+ GB of RAM, even though the mempool itself seemed to
> be under control.
> 
> @prime:~/bin$ ./bitcoin-cli getmempoolinfo { "size" : 1896, 
> "bytes" : 37341328 }
> 
> [total memory usage not shown -- I restarted bitcoind as soon as I
> noticed, and didn't copy it down from top]
> 
> 37 MB mempool, >3 GB RAM usage. Normally, when there aren't a lot
> of unconfirmed txns floating around the network, memory usage is
> around 600 MB, so this is quite unusual.
> 
> After restarting the process and letting it run for a few minutes,
> I get:
> 
> PID USER  PRI  NI  VIRT   RES   SHR S CPU% MEM%   TIME+
> Command [###] [] 20   0 1402M  317M 49836 S  1.0  8.2
> 0:41.71 ./bitcoind -daemon
> 
> @prime:~/bin$ ./bitcoin-cli getmempoolinfo { "size" : 1072, 
> "bytes" : 67 }
> 
> 0.67 MB mempool, 317 MB RAM usage. Much more reasonable.
> 
> 
> Here's another node I'm running that has been online longer, before
> restarting:
> 
> PID USER  PRI  NI  VIRT   RES   SHR S CPU% MEM%   TIME+
> Command [###] [] 20   0 4961M 3540M 11080 S  2.8 45.3
> 8h20:11 bin/bitcoind -daemon
> 
> @feather:~$ bin/bitcoin-cli getmempoolinfo { "size" : 3045, 
> "bytes" : 39656126 }
> 
> 39 MB mempool, 3540 MB total memory usage. After restarting
> bitcoind, I see:
> 
> []@feather:~$ bin/bitcoin-cli stop Bitcoin server stopping 
> []@feather:~$ bin/bitcoind -daemon Bitcoin server starting 
> []@feather:~$ sleep 10; bin/bitcoin-cli getmempoolinfo { "size"
> : 39, "bytes" : 47037 }
> 
> 
> PID USER  PRI  NI  VIRT   RES   SHR S CPU% MEM%   TIME+
> Command [###] [] 20   0 1640M  247M 67960 S  0.0  3.2
> 0:05.17 bin/bitcoind -daemon
> 
> 
> 
> 
> Does anybody have any guesses where we might be leaking memory, or
> what is using the additional 2.4 GB? I've been using
> minrelaytxfee=0.3 or similar on my nodes. Maybe there's a leak
> in the minrelaytxfee code path? Has anyone else seen something
> similar?
> 
> This issue appears to happen both with Bitcoin Core 0.10.1 and with
> Bitcoin XT 0.11B.
> 
> 
> 
> ___ bitcoin-dev mailing
> list bitcoin-dev@lists.linuxfoundation.org 
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 

- -- 
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJWHYqAAAoJEGxwq/inSG8Cp8YIAJa9xWA+rNY9ZOTWjOEZGc7Q
IpXqpIyZprhEog6By/rQ7Te+xdUuaIZrMPESEoQIdMlDjRu7V2CWKGr1LbbDf2v9
A6nMhE19tazDSMAcqHlcuWRfpex3C5QD93Oo7h0QvioNLc8cseNsYzqvOW40vIFL
SPJOfor6IFLEi6/0t7OBhVyaXZdhI7XD1IDxeD67IOafCDwHgixFZWS4aCpz4axj
i4B8DNsVgDdeYI2STBiqnL9Sopdnc1q2CwC1ENszR+sCXwIB9vdPOtIjhtWGk1gi
f+/I8IUP/jn2xIjAGixjEePCIFLFV3kI+B6akH8+TsXB4G9C3zHEHTsfCrmLblg=
=VMV3
-END PGP SIGNATURE-
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Incentives to run full nodes, revisited

[odinn via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512


Due to the previous post on this subject
( http://is.gd/x6g5q5 ) having fractured links
please see the following, with working implementation
(in BCN) shown at: http://abis.io

This is intended to be implemented in different currencies, and so far
has been implemented in one (BCN - GUI wallet).  The concept is
feasible in BTC as well.

Comments welcome.

Developer's blog:

https://bytecoin.org/news/bytecoin-wallet-1.0.8-release-introduces-micro
- -donations/

(Above link can be found also at http://abis.io)

See also:

https://odinn.cyberguerrilla.org/index.php/2015/10/03/greater-giving-pot
ential/

- -- 
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJWEiKAAAoJEGxwq/inSG8Cr18IAKEIBaHp7qkA2xJVTLyXmYkh
RWJg92cjD2Oy82ZkbdGjOJr9XjLFfwiYyZIZucKs1drafjOQvDllNpqII1/grWio
igwEW0eWl/of2tACK6u5i9bCXcfYi4MnMV1rF1DM0etSjRZUu//bX8qrwiwXvAzZ
RmuRlSFvBYE3BuIbd7ekQGfzkXjIVlHerXSDQcELwVhbnQKTYDk/i/4SzmPFHg9Y
S2Zp/SWVQANqvnfuZPjNvbmNXJEdgIzmiUfx2F3ap+5qxtLOJ28zNGnFB+UPRTzr
enlpnxmaUGBkJOEDrQzu0AKoNIeZRyJ6dpzjmMmvsnwo2VW27dKg+NEAOC4zD/U=
=Axnt
-END PGP SIGNATURE-
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Incentives to run full nodes

[odinn via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

(Note:  Due to being very tired I have issued a correction to my post
below so as to make sure I have not been misunderstood.)

odinn via bitcoin-dev:
> Hello,
> 
> Some background on this
> 
> 
> A very long while ago I posted to the bitcoin-development mailing
> list some ABIS concepts having to do with microdonations:
> 
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-December/
00
>
> 
3791.html
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-January/0
04
>
> 
049.html
> 
> And an interesting post (which led me to explore BCN) via nullc: 
> https://news.ycombinator.com/item?id=7765455 (posted 1 & 1/3 year
> ago).

(I realize the way I wrote the above paragraph made it sound like I
posted the above post at https://news.ycombinator.com/item?id=7765455
but I just want to point out here that I did not; I meant to say that
I read an interesting post which led me to explore BCN that was
published by nullc.)

> 
> 
> Anyway, some long while ago this discussion came up about
> "Incentives to run full nodes," and the last post in the thread was
> here:
> 
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-June/0060
83
>
> 
.html
> 
> Since that time, some new developments have come to light which
> the participants in that thread may find interesting;
> 
> Please see in part,
> 
> https://bytecoin.org/news/bytecoin-wallet-1.0.8-release-introduces-mic
ro
>
> 
- -donations/
> 
> This presents a working implementation in BCN; the concept as 
> implemented there is arguably viable in BTC as well.
> 
> Please explore, play with, discuss, etc.
> 
> Cheers,
> 
> - O
> 
> odinn:
>> Potentially relevant...
> 
>> "Incentivizing the running of full nodes"
> 
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-June/006
0
>
>> 
28
> 
> 
> .html
> 
>> (However, the issue to which I referred here is now closed)
> 
>> View whole thread:
> 
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-June/thr
e
>
>> 
ad
> 
> 
> .html#6028
> 
>> On 08/17/2015 02:44 PM, Chris Pacia via bitcoin-dev wrote:
> 
>>> On Aug 17, 2015 5:29 PM, "Peter Todd via bitcoin-dev" 
>>> >> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote: From the
>>>  point of view of a
>>>> wallet, it's not very secure to use Hearn-style SPV mode, and
>>>>  volunteers running full nodes doesn't help things. Sybil 
>>>> attacking the IP address space is pretty easy in comparison
>>>> to aquiring hashing power sufficient to create false 
>>>> confirmations, so any attacker able to do the former will 
>>>> likely be running the full node you're connecting too
>>>> anyway. Ultimately, Hearn-style SPV is a close approximation
>>>> to just trusting anyone with a non-trivial amount of hashing
>>>> power. (and getting that is surprisingly easy, e.g. w/ SPV
>>>> mining)
> 
>>> Can you explain how the spv node fails against an attacker with
>>> a non-trivial amount of hash power where a full node doesn't?
>>> To attack an spv wallet that is waiting for 6 or 10
>>> confirmations, you would not only need to Sybil them but also
>>> summon a massive amount of hashing power to create a chain of
>>> headers (while forgoing the opportunity to mine valid blocks
>>> with that hash power).
> 
>>> But could someone with that much hash power not Sybil a full 
>>> node and give them a chain for valid blocks (but on an orphan 
>>> fork)? The failure model doesn't seem specific to spv to me.
> 
> 
> 
>>> ___ 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
> 

- -- 
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJWEM5PAAoJEGxwq/inSG8C48UH/A9mfVaP2h1nOD2po2yaDCLA
xJuMIhrgo81q+WAbwFk4ac3bu3R/RzLLM7yA2IWDiPJrt6gCvEgIjzsHcG7+q5Bd
s7dPEFnibPzpqXjnVh6FcfpuW/MCT3AXiSvnsKiLh99v+oz9g50fIpOMYuOTk/Sy
816xqKbDfKEHzkWzeOv5gV61AzNS7PDWjfRqRV/Om5+J/MZt/kgXJ8UqEVmYbLXM
wIOWA1Vl4BZtQBiQpyDBjBUDhU0YboVXOMIbmx+ffDXKydcErLwFOCBp3XjVOMti
y0B56kmPko5xKH4/n53WFLH32ILd7dZNtK4KzhmyPjeJ+yXdfFTmR3Ayo4wvP2s=
=UvrH
-END PGP SIGNATURE-
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Incentives to run full nodes

[odinn via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello,

Some background on this


A very long while ago I posted to the bitcoin-development mailing list
some ABIS concepts having to do with microdonations:

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-December/00
3791.html
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-January/004
049.html

And an interesting post (which led me to explore BCN) via nullc:
https://news.ycombinator.com/item?id=7765455
(posted 1 & 1/3 year ago).


Anyway, some long while ago this discussion came up about "Incentives
to run full nodes," and the last post in the thread was here:

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-June/006083
.html

Since that time, some new developments have come to light which the
participants in that thread may find interesting;

Please see in part,

https://bytecoin.org/news/bytecoin-wallet-1.0.8-release-introduces-micro
- -donations/

This presents a working implementation in BCN; the concept as
implemented there is arguably viable in BTC as well.

Please explore, play with, discuss, etc.

Cheers,

- - O

odinn:
> Potentially relevant...
> 
> "Incentivizing the running of full nodes"
> 
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-June/0060
28
>
> 
.html
> 
> (However, the issue to which I referred here is now closed)
> 
> View whole thread:
> 
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-June/thre
ad
>
> 
.html#6028
> 
> On 08/17/2015 02:44 PM, Chris Pacia via bitcoin-dev wrote:
> 
>> On Aug 17, 2015 5:29 PM, "Peter Todd via bitcoin-dev" 
>> > > wrote: From the 
>> point of view of a
>>> wallet, it's not very secure to use Hearn-style SPV mode, and 
>>> volunteers running full nodes doesn't help things. Sybil 
>>> attacking the IP address space is pretty easy in comparison to 
>>> aquiring hashing power sufficient to create false
>>> confirmations, so any attacker able to do the former will
>>> likely be running the full node you're connecting too anyway.
>>> Ultimately, Hearn-style SPV is a close approximation to just
>>> trusting anyone with a non-trivial amount of hashing power.
>>> (and getting that is surprisingly easy, e.g. w/ SPV mining)
> 
>> Can you explain how the spv node fails against an attacker with a
>>  non-trivial amount of hash power where a full node doesn't? To 
>> attack an spv wallet that is waiting for 6 or 10 confirmations,
>> you would not only need to Sybil them but also summon a massive
>> amount of hashing power to create a chain of headers (while
>> forgoing the opportunity to mine valid blocks with that hash
>> power).
> 
>> But could someone with that much hash power not Sybil a full
>> node and give them a chain for valid blocks (but on an orphan
>> fork)? The failure model doesn't seem specific to spv to me.
> 
> 
> 
>> ___ bitcoin-dev
>> mailing list bitcoin-dev@lists.linuxfoundation.org 
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 
> 
> 

- -- 
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJWEMsvAAoJEGxwq/inSG8CcU8IAMJ+ZYMFzjETUDEZNyUnVd3v
SJCNauufTOcqxLzQoGIj4Y66PDnk9doRy/KJUGhKNtg4vjxiEk+GGHRH02ktvnQB
6MGuDCJS+MLeGi2W2QMr1NdHl09kRo306F5ZgjtZnOqX0mhwhOrIUylpoevcBnSQ
maJ5hpmxqyhxozEyYyu50HwcMQrXeWKZ8G0VSkTqmY5wf0s98MGrFLWSujwsva0e
p4hvG6YgBH85ne7dnBSH/sySreJpRMA0aac/+1j9U3LVvMTsmuaPc71aGI791o/y
+KV+UZ8bgHldfi+NSK8wA4eRi4JQrt+ruE63XlfYl29gWINqsGeVtpW/W3jeDnI=
=KDER
-END PGP SIGNATURE-
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Design Competition

[odinn via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Grosses me out that you have enforced KYC as part of what you are
doing for anyone who would decide to get involved:

https://wiki.lykkex.com/?id=start#lykke_citizens

Good luck with that, I'm sure not going to be a part of it, and I
recommend that no-one else does either.

- - O

Richard Olsen via bitcoin-dev:
> All,
> 
> We are looking for participants in a Bitcoin related competition:
> the aim is to build a trading platform (initially for foreign
> exchange, other assets will follow) which lets participants settle
> their trades through the blockchain via coloured coins. To
> facilitate a quicker trade reconciliation, the use of a sidechain
> is a suggestion but by no means a requirement. There will be an
> online briefing event today where we will outline the requirements
> in more detail, though much of it we have posted on our website
> www.lykkex.com .
> 
> As we want this to be a community driven effort rather than
> something turning into a proprietary technology, all contributions
> will be made available under a MIT license on Github.
> 
> I look forward to answering your questions at the online briefing
> event or over email,
> 
> Thank you and kind regards, Richard Olsen
> 
> 
> 
> ___ bitcoin-dev mailing
> list bitcoin-dev@lists.linuxfoundation.org 
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 

- -- 
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJWDLjaAAoJEGxwq/inSG8CkQAH/i6603ivtZXjNw5ZlH1W2p7z
c88sb5CcTuTUi+zEx6Q0MRUFfdYcrcBrGsua3CKU9226rpL4acD2Bby5kUPZ1h2/
Rl5EiZa11oeqZaZaO5ZmXZ33BOaO2gxqqYEF1zBOzDgky6cqRrj8t4VAj5CKsxsP
ktM98UqVXdcuOfBP7y/xqX1Yw9e55PpwUCtaazLo8UkPLMrtdzrbKVZBtjqGxMnG
ZxmYku8g6xdmZAMz9xn9oVGtuMHrEjhIVycz3FMHBjoZNLE9yK4YeWyEvLI4YPFt
KBR7HvGDava3dzMM5ugw3hgFShfegjrIunWQ/vC9RCjBMLVGVX5RgEblgQe29eY=
=41DC
-END PGP SIGNATURE-
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

[odinn via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello, (see my remarks below)

jl2012 via bitcoin-dev:
> Jonathan Toomim (Toomim Bros) via bitcoin-dev 於 2015-09-29 09:30 寫
> 到:
>> SPV clients will appear to behave normally, and will continue to
>> show new transactions and get confirmations in a timely fashion.
>> However, they will be systematically susceptible to attack from
>> double-spends that attempt to spend funds in a way that the
>> upgraded nodes will reject. These transactions will appear to
>> get 1 confirmation, then regress to zero conf, every single time.
>> These attacks can be performed for as long as someone mines with
>> the old version.
> 
> 1. Who told you to accept 1-confirmation tx? Satoshi recommended 6 
> confirmations in the whitepaper. Take your own risk if you do not
> follow his advice.
> 
> 2. This is true only if your SPV client naively follows the
> longest chain without even looking at the block version. This might
> be good enough for the 1st generation SPV client, but future
> generations should at least have basic fraud detecting mechanism.
> 
> 

Regarding "basic fraud detecting mechanism" of which you speak, being
as I personally enjoy SPV for the time being (Electrum), and I know
that people will continue to keep using SPV wallets because they are
light and handy, I think that you make a good point that "basic fraud
detecting mechanism" is needed, but how to verify that such a
mechanism in an SPV wallet is good, and/or that the software and
version information provided by the server admins via the banner is
valid (being as it's not validated)?  I have made a thread on this
conundrum.  Which is posted here if you are interested.

https://bitcointalk.org/index.php?topic=1157545.0

So as to avoid repeating stuff please read whole thead before
answering in it or posting back to list.  It seems that there are
definitely unanswered questions...

I may open this up as an issue on https://github.com/spesmilo/electrum
about this stuff, but I wanted to post comment here also, for the record
.


> 
>> If an attacker thinks he could get more than 25 BTC of 
>> double-spends per block, he might even choose to mine with the 
>> obsolete version in order to get predictable orphans and to trick
>> SPV clients and fully verifying wallets on the old version.
> 
> This point is totally irrelevant. No matter there is a softfork or
> not, SPV users are always vulnerable to such double-spending attack
> if they blindly follow the longest chain AND accept 1-confirmation.
> The fiat currency system might be safer for them. 
> ___ bitcoin-dev mailing
> list bitcoin-dev@lists.linuxfoundation.org 
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

- -- 
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJWCuyBAAoJEGxwq/inSG8CtpAH/R6N1QYzMFWPo75RsP46VYbi
k33QbsbhlEznEEWX/ayKEzmnbt7DkXFXQtesuabongFr9UpwxED0OGQJztyRz5NC
iS8ty+Kfi9/Aq/e79A6IPSYfRCPB1w+oP/cEsV/LB4BPkut2mdpMbdwDZ3TQuLRq
LnFLmz8tY+CUqSbyrPUx/FKJ7ZbQsAlammMTKoUYaAYRytDBPzW4PdYtTyrK2QTK
jjt11n5U8ShmXdsCo/E0pWVbggQlhFgrCoIYjGNfmDyK/eYaskD5O6czIdqd5WPs
P+2zMC1Cukkr5l8BQXiSedVXGpMyaYhMgWB7MD6sNDIAE9IFbfEpkse/Ek4aJII=
=Ud4C
-END PGP SIGNATURE-
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

[odinn via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

And still no movement on BIP 63...

https://bitcointalk.org/index.php?topic=1083961.20

Apart from that,

All my prior objections to XT still hold as expressed on this list.
XT is not acceptable.

On the topic of consensus:

Reaching consensus, I hope, is something that developers can
accomplish by refining and adjusting the BIPS and coming to agreement
upon them.  This should be something that can be done in a few months
time, before the end of the year.

Cheers,

- - O

Adam Back via bitcoin-dev:
> I wonder what Gavin's views are, he's usually constructive, and see
> if he'll include it in XT - I think he may have said he was
> supportive.
> 
> The rationale for soft vs hard-forks is well known, so I wont go
> over them.
> 
> Adam
> 
> 
> On 28 September 2015 at 06:48, Mike Hearn via bitcoin-dev 
>  wrote:
>> There is no consensus on using a soft fork to deploy this
>> feature. It will result in the same problems as all the other
>> soft forks - SPV wallets will become less reliable during the
>> rollout period. I am against that, as it's entirely avoidable.
>> 
>> Make it a hard fork and my objection will be dropped.
>> 
>> Until then, as there is no consensus, you need to do one of two
>> things:
>> 
>> 1) Drop the "everyone must agree to make changes" idea that
>> people here like to peddle, and do it loudly, so everyone in the
>> community is correctly informed
>> 
>> 2) Do nothing
>> 
>> 
>> 
>> ___ 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
> 

- -- 
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJWCa0jAAoJEGxwq/inSG8CuCUIALiRt6cE3b+9f+l9m6aMTjIR
vTEIM/7B4dIZW9eatXmkxyd44uz5YoN93SlZtV62c90HCqqpFRBCfyXRyXzQ11E7
0i70or5LnWDOqrD1bSsCEdrQxPIpAQnv101UHe3iyn/uHAVBiz/HfqvGMruNt0r1
4sMecp+LedWpy6/p9c6iMHV1rhtYRfmRfJHj+9KlSn+in5PQKx2kieWqpfqjmlNs
J/UNoLvRuF0YxDcqEdp2BAaI0s+NyXBo3YDi4R77U9YPRj/cYuWHh/yPKAvFW+2K
0d9NNuKSKEY/m4uW3ghPEJL7OxlGbOoNWFS3kcKYr+BanfsPTov7yHQhBuRBRPw=
=hd0W
-END PGP SIGNATURE-
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP 100 repo

[odinn via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Excellent - thank you.

Jeff Garzik via bitcoin-dev:
> Oops, link paste fail.
> 
> The repo: https://github.com/jgarzik/bip100
> 
> 
> On Wed, Sep 2, 2015 at 7:51 PM, Jeff Garzik 
> wrote:
> 
>> Opened a repo containing the full text of BIP 100 discussion
>> document, in markdown format.
>> 
>> The BIP 100 formal spec will be checked in here as well, before
>> submitting to upstream bips.git repo.
>> 
>> 
>> 
> 
> 
> 
> ___ bitcoin-dev mailing
> list bitcoin-dev@lists.linuxfoundation.org 
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 

- -- 
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-BEGIN PGP SIGNATURE-

iQEbBAEBCgAGBQJV5+uQAAoJEGxwq/inSG8CVBUH9A5GtIj3pLxZRlX0oDxSbIWJ
2830HURoeb40ShBlhbzO1nHiJtPhRPWqByZETQcuElBagMPreSKI5VZxJ1xaNOI3
o6yo9ujeLNlge1j53TOq8uQCXKnwrVsjS3yQkXlo+IX+Vihin5c/D4Xn9y97OqwQ
CixVswCJrrRrGHj6YaFsfAx+epaJ/aT4djoB0XjH9PKJI5b0cPGSBDipHbuVn3nd
FZidPAS/hHI0Sw3k0EHtYudjBXBbMi2hCad37asrg2cIF/sFbCA/BSkpuIi5agzY
50Wp8xm3gd4WWjEn/svhw2AIgH7R/1Yk2/qFImob5iXMm7sU1OUMHD325kN2dg==
=7a0Z
-END PGP SIGNATURE-
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] AT&T has effectively banned Bitcoin nodes by closing port 8333 via a hidden firewall in the cable box

[odinn via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Another note on this subject to add to the stuff people have already
mentioned...

If you have the AT&T landline but don't use AT&T's standard internet /
tv (what they call Uverse) offering - that is, if you prefer to use
some local internet provider - you are probably better off (in terms
of avoiding not only this sort of blockage/censorship but as well,
potentially getting a better privacy policy that isn't going to be
like AT&T's long-term data retention).  You can check directly with
the various local small ISPs to see what their policies are
specifically on ports and whatnot.

Ideally your ISP should let you:

port forward to SOMEPORTNUMBER for tcp and udp

(above may or may not be helpful for some if you are using
decentralized markets)

have port 8333 open

(above is for bitcoin of course)

Supposing you have FTTN because you are paying a local ISP for
internet service, and that local ISP has contracted with AT&T to be
able to provide service in an area where old-style DSL has been phased
out, thus your local ISP is essentially providing you AT&T FTTN.
(FTTN is Fiber to the Node, FTTN-BP is FTTN Bonded Pair).  Even if a
local ISP has its own privacy policy posted which is different from
AT&T, everything is subject to AT&T data retention because the FTTN.
So get yourself a VPN (or set up your own) for your connection. Tor
will run through the VPN.

General observations - TWC stores your IP and other stuffs for 6
months or longer.  Same for Comcast.  Verizon retains your stuffs for
18 month minimum, probably longer though. Qwest/Century, 1 year.
Cox, 6 months.  AT&T retains for longer than a year.  This is just
what they are telling you, the reality is it's probably longer due to
stuff like this:
https://www.lawfareblog.com/odni-and-doj-release-last-section-215-collec
tion-order









Zach G via bitcoin-dev:
> I have been struggling to get port 8333 open all year, I gave up
> and was using blockchain for months despite a strong desire to stay
> on Bitcoin Core, but now the issue has reached critical mass since
> I'm using the python Bitcoin server module. I have literally spent
> my entire day trying to open 8333, I thoroughly made sure it was
> open on the router and computer and it's still closed. Strangely
> enough I got it open for 30 seconds once today but something closed
> it immediately.
> 
> After hours of phone calls and messaging AT&T finally told me the
> truth of what was going on, and only because I noticed it myself
> and demanded an answer. The internet is being routed through a
> DVR/cable box, and they confirmed the DVR also has a firewall. To
> make this even more absurd they refused to turn the firewall off
> because it is their equipment. So effectively they can firewall any
> port they want even if the customer asks them not to, in the
> unlikely event the customer figures it out.
> 
> Perhaps this is the driving force behind the inexplicable and
> massive decline in Bitcoin nodes. Bitcoin is being censored by the
> ISPs themselves, and they won't even tell you that. I had to get in
> touch with headquarters and threaten to rip it out of the wall to
> get a proper answer.
> 
> 
> 
> ___ bitcoin-dev mailing
> list bitcoin-dev@lists.linuxfoundation.org 
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 

- -- 
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJV5VDeAAoJEGxwq/inSG8CvkIH/jy4Vo+My3xeBdvFQmxkJWyQ
U5mv2zWEvBYw71Xy1EDzQY1AhEBmatUU1eu2AbOqXdUR4511FxCNzFmTxy6roEiz
EehBkvXNbBCbEzLRisjxuQw34OKM+xfieCqE1mzJok2uSdLMMQLcbWL1/k3/OmS5
9O9z/wMXqU1Jc19MTK+vF1Lz5ilnRn3hEbTaCN3ivYnYFa0DpBH9r0Y07UcoJ6Wr
ui/x0sSSuupAGzOkZ75HQ8yeQXckeAu6TB3/jE8QEqNUmAJkmR8eK4ofXZWFrIjy
mOKeQL4c+jRQnTR8pt+y89g2QIpzFoHaV5T+WvQuC1t8xNOrxLgYFXWgl0dhoYE=
=UCLC
-END PGP SIGNATURE-
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Open Bitcoin Privacy Protect Privacy Questionnaire, Mid-Year 2015 report

[odinn via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Related:

https://github.com/bitcoin/bitcoin/issues/6568

Kristov Atlas via bitcoin-dev:
> Hi Wei,
> 
> As you know, I'm not a developer of Bitcoin-Qt, but we'll need to
> make our best guesses for these answers if the developers won't
> reply. I'm going to post my best guesses here so that people
> reading the list have a short window of opportunity to correct me
> if they wish.
> 
> 
> On Fri, Aug 7, 2015 at 2:46 PM, Wei via bitcoin-dev < 
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> 
>> Transaction Formatting
>> 
>> 1.  Does your application take any steps to create ambiguity
>> between transactions which unavoidably spend from multiple
>> addresses at the same time and intentional mixing transactions?
>> 
> 
> No, Bitcoin-Qt does not try to make non-mixing transactions look
> like mixing transactions.
> 
> 
>> 2.  What algorithms does your application use for ordering
>> inputs and outputs in a transaction? In particular, how do you
>> handle the change output and do you take into account common
>> practices of other wallet applications when determining
>> ordering?
>> 
> 
> Not yet BIP 69. These notes suggest that outputs are randomized: 
> https://bitcoin.org/en/release/v0.8.1
> 
> 
>> 3.  Does your application minimize the harmful effects of
>> address reuse by spending every spendable input (“sweeping”) from
>> an address when a transaction is created?
>> 
> 
> Unknown
> 
> 4.  Does your application fully implement BIP 62?
>> 
> 
> Here's a detailed answer on stack exchange: 
> http://bitcoin.stackexchange.com/questions/35904/how-much-of-bip-62-de
aling-with-malleability-has-been-implemented
>
>  By item, my extremely brief interpretation:
> 
> Non-DER encoded ECDSA signatures: BIP66 soft fork has happened, so
> this is presumed to be implemented Non-push operations in
> scriptSig: Implemented Push operations in scriptSig of non-standard
> size type: Implemented in 0.9.0 Zero-padded number pushes:
> Implemented in 0.10.0 (current available version is 0.11.0) 
> Inherent ECDSA signature malleability: ...implemented? Superfluous
> scriptSig operations: implemented 0.6.0 Inputs ignored by scripts:
> Only partly addressed by 0.10.0.  It appears that the rest would
> require changes to consensus rules, so Bitcoin-Qt is as compliant
> as it can be. Sighash flags based masking and New signatures by the
> sender: Can't be implemented without changes to consensus rules.
> 
> I would summarize this as a "yes."
> 
> 
>> 
>> Mixing
>> 
>> 5.  If your application supports mixing:
>> 
> 
> It doesn't. There's an issue for CoinJoin here: 
> https://github.com/bitcoin/bitcoin/issues/3226
> 
> 
>> a.  What is the average number of participants a user can
>> expect to interact with on a typical join transaction? b.
>> Does your application attempt to construct join transactions in
>> a way that avoids distinguishing them from non-join
>> transactions? c.  Does your application perform any kind of
>> reversibility analysis on join transactions prior to presenting
>> them to the user for confirmation? d.  Is the mixing
>> technique employed secure against correlation attacks by the
>> facilitator, such as a CoinJoin server or off-chain mixing 
>> service? e.  Is the mixing technique employed secure against
>> theft of funds by the facilitator or its participants?
>> 
>> Donations
>> 
>> 6.  If your application has a fee or donation to the
>> developers feature:
>> 
> 
> No donation feature last time I checked.
> 
> 
>> a.  What steps do you take to make the donations
>> indistinguishable from regular spend in terms of output sizes and
>> destination addresses?
>> 
>> Balance Queries and Tx Broadcasting
>> 
>> 7.  Please describe how your application obtains balance
>> information in terms of how queries from the user’s device can
>> reveal a connection between the addresses in their wallet. a.
>> Does the application keep a complete copy of the blockchain 
>> locally (full node)?
>> 
> 
> Yes
> 
> 
>> b.  Does the user’s device provide a filter which matches
>> some fraction of the blockchain while providing a false positive
>> rate (bloom or prefix filters)?
>> 
> 
> No, it just downloads the whole blockchain and performs local
> queries.
> 
> 
>> i.  If so, approximately what fraction of the blockchain does
>> the filter match in a default configuration (0% - 100%)?
>> 
> 
> 100%, unless a user bootstraps downloading the blockchain.
> Bootstrapping will potentially limit the user's anonymity set to
> other people who have downloaded that bootstrap.dat file.
> 
> 
>> c.  Does the user’s device query all of their addresses at
>> the same time?
>> 
> 
> N/A
> 
> 
>> d.  Does the user’s device query addresses individually in a
>> manner that does not allow the query responder to correlate
>> queries for different addresses?
>> 
> 
> No. Just download blocks and processes that information locally.
> 
> 
>

Re: [bitcoin-dev] RE : Visualizations of Votes

[odinn via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

This is looking very good also (you've already seen it, but just
adding it to thread):

https://data.bitcoinity.org/bitcoin/block_size_votes/7d?c=block_size_vot
es&r=hour&t=bar
(site by Kacper Cieśla (comboy))

On 08/25/2015 01:46 AM, Christian Decker wrote:
> Yes, the two dimensions are orthogonal: BIP 100 support and actual
> size voting. However there seem to be a few pools which simply vote
> to support BIP100, without specifying a desired block size [1],
> hence I started tracking both on the same chart, maybe I'll split
> them into different charts to clarify.
> 
> Regards, Chris
> 
> [1]
> https://blockchain.info/tx/ba1e5d21a340772d637ee5dc0bde8072ad1a7b499ba
241d5bfaae9618749531e
>
>  On Mon, Aug 24, 2015 at 4:46 PM Jeff Garzik  <mailto:jgar...@gmail.com>> wrote:
> 
> There is a duplicated column.
> 
> BIP 100 voting is /BV\d+/
> 
> 
> 
> On Fri, Aug 21, 2015 at 9:24 AM, Christian Decker via bitcoin-dev 
>  <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
> 
> I hacked together a simple tracking page for the 'block votes', it
> currently includes the 8MB vote and XT, as well as the /BV\d+/ vote
> for generic size: http://bitcoinstats.com/network/votes/
> 
> On Fri, Aug 21, 2015 at 7:25 AM odinn via bitcoin-dev 
>  <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
> 
> Hello Nicolas,
> 
> On 08/20/2015 08:49 PM, Nicolas Dorier via bitcoin-dev wrote:
>>> A visualization I would like to see would include:
> 
>>> pie graph(s) of what % are voting for (BIP 100, BIP 101,
> 8MB, BIP
>>> sipa
>> etc) based on what's published in blocks.
> 
>> If such a vote existed, I would gladly show the pie on
> BIPxDevs.
>> However there is no standard way for miners to vote
> informally BIP
>> they support.
> 
> What about formal votes? Is there a way to visually have them
> appear in a pie chart as the votes become apparent in blocks?
> 
> I appreciate good visualizations and am trying to get a (visual) 
> comparison of the votes on these competing proposals.
> 
> 
> 
> 
>> ___
> bitcoin-dev mailing
>> list bitcoin-dev@lists.linuxfoundation.org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 
> 
> ___ bitcoin-dev mailing
> list bitcoin-dev@lists.linuxfoundation.org 
> <mailto:bitcoin-dev@lists.linuxfoundation.org> 
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 
> 
> ___ bitcoin-dev mailing
> list bitcoin-dev@lists.linuxfoundation.org 
> <mailto:bitcoin-dev@lists.linuxfoundation.org> 
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 
> 

- -- 
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJV4rRSAAoJEGxwq/inSG8C7gIIALRgWbwf447+B202oUOmtGW6
1CVBJX415PyOmBLqbKBgIRLhQm3rOa0WRcjYejHM2PJLz2XIAyLouOoxiy+rcwX4
yIqEX33El+evgDpFZPjHUYq15mMtP0+jnzwZvyYrCP41m1MUoXwOWDYnf8X+q4yb
h2eiApU4fRJmzDYWWzVmoWTYFEzjmNW95vSOTSCFxuvx2A6227vyJI1irQ9EDi7+
UVdvNqTIXTmNDDJBmIsUeWkSe7fAkgyejxD2S08zEUuLR8w3S+9JYJ0rDTMkl4PR
EEnuL1M34WMuT7uQIjeQ/5L3voMefKAjCcwiX/lvk2G+YKXXhQhqNy1uyPfJgyI=
=YUJa
-END PGP SIGNATURE-
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIPS proposal for implementing AML-KYC in bitcoin

[odinn via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Well,

On 08/27/2015 06:39 AM, prabhat via bitcoin-dev wrote:
> Fine point.
> 
> So where is the solution? What to do?

You could study bitcoin some more and understand what it is instead of
proposing to "implement AML-KYC in bitcoin" which shows vast ignorance
about it.

That's probably what you should do.

> 
> Prabhat Kumar Singh
> 
> Prabhat Kumar Singh
> 
> 
> On Thu, Aug 27, 2015 at 6:58 PM, Gavin Andresen
> mailto:gavinandre...@gmail.com>> wrote:
> 
> Have you talked with anybody at the Bitcoin Foundation about this 
> proposal?
> 
> As Chief Scientist of the Foundation, I am strongly opposed to any 
> proposal that puts the Foundation in a position of centralized 
> authority, so this is unacceptable: "The Bitcoin Foundation will
> act as fair play party and enforcement body to control the misuse
> of vast financial powers which bitcoin has."
> 
> The idea that a central organization can be trusted to keep
> secrets secure is just fundamentally wrong. In the very recent past
> we have seen government organizations fail in that task (the NSA,
> the OPM) and we see commercial organizations that SHOULD be highly
> motivated to do a good job also fail (e.g. the Ashley Madison
> leak).
> 
> Even if it were technically possible, I would be opposed because 
> decentralization is a bedrock principle of Bitcoin.
> 
> -- -- Gavin Andresen
> 
> 
> 
> 
> ___ bitcoin-dev mailing
> list bitcoin-dev@lists.linuxfoundation.org 
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 

- -- 
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJV38K+AAoJEGxwq/inSG8CTK8IAI3WMVX4Ajk4PraPsCZqugrv
OjuQXc13K4/lf+FSxerzuNQy2ppLnl4jS7/5kJ0kYRHf0FGn7nMvk6NX1bze4P4S
iAyP6oUvPv/LdX9XMettKo4S6B/Nrl8f3q9sRmW1ZicpvhTLrzIGXQvmnX3M115o
h+mtGMRcfL2znjZIoiAE9jEtTt3ZW3yswk4eGOA5wAoD5VAuBmVWBE61ZGqAFwW+
7EskK96ZQnlroKnk47sfn2V3vemUijpXtZItcuVSENAAKwhC/rMG2hLSFOFgk608
owYTLQcSX6DITNPpzb0/TMHwiuAog4YJ260QwY95SFyPARhN167SzR8IWKQU+MQ=
=t9+J
-END PGP SIGNATURE-
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIPS proposal for implementing AML-KYC in bitcoin

[odinn via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

No.

On 08/27/2015 01:10 AM, prabhat via bitcoin-dev wrote:
> Hi,
> 
> I am proposing to create a AML-KYC module to control the network
> and also qualify use cases in OFAC compliant way. Here is the
> attached doc.
> 
> Please provide your feedback and suggestions.
> 
> Best, Prabhat Kumar Singh
> 
> 
> ___ bitcoin-dev mailing
> list bitcoin-dev@lists.linuxfoundation.org 
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 

- -- 
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJV38DGAAoJEGxwq/inSG8CkYkIAJwHOnjesbq+UHogUkGJsuph
2ipSIcBEzbeVH8fQ2sij5jKULE0n8J7K/DtfzzRJj+IiaYB1Ecjl0kLVQ0ug6T/8
p5iuGQ2fvt1tMOy9+ptZbOZhtjUTWWSMqmFgsPkh5s/uGHeKy/jBjYsZv4FZ57Hm
DUUvGYIdaGQ2eYm4y4dLnvI0T5WFQvf0Vs4wvWZdKvD5oliSwGy4KNVIxlcGya8w
FPYaDe8q0rN5Aqp4V2jjfuF4KBC8dwHa9dyHTfSPA43I1qbcIVraSdJg1lCJ/bXh
rFz+MXcGmsxxzHMbv6C4y+YSET2TPuNUs4w6MVw2ZO0lYe1suWYeYvfccQA1+Uk=
=17NP
-END PGP SIGNATURE-
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] RE : Visualizations of Votes

[odinn via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

This is great!! Thank you.

On 08/21/2015 06:24 AM, Christian Decker wrote:
> I hacked together a simple tracking page for the 'block votes', it 
> currently includes the 8MB vote and XT, as well as the /BV\d+/ vote
> for generic size: http://bitcoinstats.com/network/votes/
> 
> On Fri, Aug 21, 2015 at 7:25 AM odinn via bitcoin-dev 
>  <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
> 
> Hello Nicolas,
> 
> On 08/20/2015 08:49 PM, Nicolas Dorier via bitcoin-dev wrote:
>>> A visualization I would like to see would include:
> 
>>> pie graph(s) of what % are voting for (BIP 100, BIP 101, 8MB,
>>> BIP sipa
>> etc) based on what's published in blocks.
> 
>> If such a vote existed, I would gladly show the pie on BIPxDevs. 
>> However there is no standard way for miners to vote informally
>> BIP they support.
> 
> What about formal votes? Is there a way to visually have them
> appear in a pie chart as the votes become apparent in blocks?
> 
> I appreciate good visualizations and am trying to get a (visual) 
> comparison of the votes on these competing proposals.
> 
> 
> 
> 
>> ___ bitcoin-dev
>> mailing list bitcoin-dev@lists.linuxfoundation.org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 
> 
> ___ bitcoin-dev mailing
> list bitcoin-dev@lists.linuxfoundation.org 
> <mailto:bitcoin-dev@lists.linuxfoundation.org> 
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 

- -- 
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJV1+kXAAoJEGxwq/inSG8Ctg4H/0zOfXEO/b+yxgGjnrIiiAi5
04Un/C9ZuPCn/dMQ5rZ0e8jIOclNER3NGtKbPBmLweyeN84HlrUUQ0ctRQocY1md
XwGJIMpjpwQCSf52XrH3IC0J8X45DQj3295sDNnmgAkOxIyPABKdDR7RJ8LfQU/B
BmJu0JAIBJmpAkz1ZJ2wYe2T0sUFk8WmvH40BzoIKqu0A9vMcR8IqfKMBI9Qczbw
ZJyWFTsgovS/p/8tSxeI458DsY1WjivdQe7nJNXit6eA5Yle3Cs3nvsA2+6xy5L9
uedX38+8s3XNXrXY1CCR7ptowjzCI+U6yiFluK+xx1oPPhtdRJYwo4vyTmaCaK8=
=uh68
-END PGP SIGNATURE-
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Core Devs : can you share your thoughts about all BIPs on this website ?

[odinn via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Bitcoin will be neutered and die if the big Chinese mining pools
utilize XT.

Specifically the text of @JihanWu's tweet was,

"I support increasing the block size. @BITMAINtech 's AntPool will be
prepared to switch to XT, IF we see majority has switched."

Since there are many people who are supportive of increasing the block
size, but have spend much time calling attention to the many problems
of XT (which I need not repeat again here), it is odd that Jihan Wu
would see a need to suggest that AntPool will be prepared to switch to
XT at a time when there has not yet been time for fully assessing
other proposals; not all proposals have gone through a voting process,
nor have even people had a chance yet to attend upcoming workshops on
the subject which are partially or wholly intended for development of
consensus ( one example being the upcoming one in Montreal, but I
think this is not the only one https://scalingbitcoin.org/montreal2015/
).
See also Pindar Wong's post on this list regarding the Montreal workshop
:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/0101
35.html

This is also a good time to remember again some of the pressures being
placed by the state on Chinese internet-based businesses.  These
pressures have increased, as has been recently discussed on this list,
here:

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/0098
61.html

Take a good read of these issues (linked to above) relating to Chinese
mining and the influence of the Chinese state, and it becomes clear
how the state pressures might cause Chinese miners to adopt XT in
light of:

Hearn's disabling Tor in XT
https://lists.torproject.org/pipermail/tor-dev/2014-July/007167.html
http://cointelegraph.com/news/115153/bitcoin-xt-fork-can-blacklist-tor-e
xits-may-reveal-users-ip-addresses
Hearn's move to support blacklisting
https://www.reddit.com/r/Bitcoin/comments/1qmbtu/mike_hearn_chair_of_the
_bitcoin_foundations_law/

A recent post that sums it up pretty well:
http://qntra.net/2015/08/collected-notes-on-the-xt-client-and-xtcoin-for
k/

I encourage people still reading this list to:

- - Not use XT
- - Work to develop consensus on an alternative that increases block
size (e.g. BIP 100)
- - Attend a conference if you can such as the one which is coming up in
Montreal https://scalingbitcoin.org/montreal2015/ and if you go there
as a developer / engineer / miner, AGREE ON SOMETHING (other than XT)
- - Visualize different proposals and votes on them so people can see
what is happening
- - Please see also (how end users can deal with this situation) at:
https://bitcointalk.org/index.php?topic=1157545.msg12189776
and contribute to the discussion if you like

Thank you.



On 08/21/2015 04:28 AM, Btc Drak via bitcoin-dev wrote:
> On Fri, Aug 21, 2015 at 11:55 AM, Yifu Guo via bitcoin-dev 
>  wrote:
>> I like the intend of this attempt to bring more clarity to the
>> blocksize debate, however it would be more help to make this a
>> information site about the current outstanding BIPs and summarize
>> their differences rather than voting mechanism. (ofcourse the
>> author of the BIPs would "vote" for their own proposals.)
>> 
>> It would be good to include supporting and counter statements
>> regards to these BIPs on the site. in addition to highlight
>> certain things like pools in china have voiced their opinion that
>> increase should happen, and 8mb is something they are comfortable
>> with, which is not directly related to a single BIP, but never 
>> the less relevant in this discussion.
> 
> I was rather surprised by the tweet from AntPool[1] today saying
> that they support big blocks and would be prepared to upgrade to
> XT. Pools have stated that they are willing to increase to a
> maximum of 8MB, but upgrading to XT puts them on a schedule towards
> 8GB which is clearly not what they have agreed to.
> 
> Do you have any insights into what's going on there?
> 
> Also do you have any insight into what Chinese pools would accept
> as a compromise in terms of raising the blocksize limit?
> 
> Drak
> 
> [1] https://twitter.com/JihanWu/status/633288343338381314 
> ___ bitcoin-dev mailing
> list bitcoin-dev@lists.linuxfoundation.org 
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 

- -- 
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJV1+ZRAAoJEGxwq/inSG8CzIEH/jQQzFHz2IUxh8CIDIyBEMFA
FxVqgcTcs2gdL0R4Nprj+PoKUYSDbanDSr+5QVt6Qp8l4jbQEC/QlFWlmwRL9AlC
tUxd5VAubWCuAcg2xADD4lEFedJlxZcDZ8VHp/TMUgPuWWLP0lvnXtef/FlgmPik
xAZzsHfujD1u0trwwvVSF4pjpbV1mKQcI5lkA9nGZI5yg7+bQDDEMjmCSh2xhyCe
5Tc0b7xQqJiamPgjbauKmZFfLpCM6UdHFiT19syJ1YB9F1JmpXWz3Kpxy1w6uFNH
HSseqGIUHjQDCq3rRwoXOYPf8aVfACXPxc00HH1SbUA5dgQs4lo+i6z71dcMgs4=
=4d+B
-END PGP SIGNATURE-

Re: [bitcoin-dev] RE : Visualizations of Votes

[odinn via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello Nicolas,

On 08/20/2015 08:49 PM, Nicolas Dorier via bitcoin-dev wrote:
>> A visualization I would like to see would include:
> 
>> pie graph(s) of what % are voting for (BIP 100, BIP 101, 8MB, BIP
>> sipa
> etc) based on what's published in blocks.
> 
> If such a vote existed, I would gladly show the pie on BIPxDevs. 
> However there is no standard way for miners to vote informally BIP
> they support.

What about formal votes? Is there a way to visually have them appear
in a pie chart as the votes become apparent in blocks?

I appreciate good visualizations and am trying to get a (visual)
comparison of the votes on these competing proposals.

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

- -- 
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJV1rZSAAoJEGxwq/inSG8CuNgIAIOIpHavzz6EJ5AOGBg2T859
MV7rsPfk1HBV4K1Yf4HfrlD/1SY0L57SANpRodi1NME3pl27QQCDnuwNLAqOLKtA
P/sHXnk9LuSG8Czk0PHOslZ+f1fDbmNm9gtR3QWXGOx0jP2b+WQ8RhkPhqQ++S/i
oXmjyrk+8TTu1hxMbuCcG5bqeS0lBm0SyrSbRTPWH+4U1jGYbxQNKkHnuZGByX4B
HBWuKvIylQzHCfy0ToUW+Z29Y+78wQNQUOA10eq7qpZCZvfRZUov1KBVXLx8GAKy
Y5WGSJYIAt+Rwn9eMxhpD91ZR1vwtqtRZn7M+NtrStPBJt+n4ET9VmPpsMAc/Zc=
=AHv3
-END PGP SIGNATURE-
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Visualizations of Votes

[odinn via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


This is a simple post.

Who's got visualizations of votes?

One I've seen that I liked was

http://bipsxdevs.azurewebsites.net/

This just covered how developers feel about the various BIPs though.

A visualization I would like to see would include:

pie graph(s) of what % are voting for (BIP 100, BIP 101, 8MB, BIP sipa
etc) based on what's published in blocks.

Has anyone hacked up such a thing which would describe miner voting,
etc. visually in real time?

- -- 
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJV1prZAAoJEGxwq/inSG8CsN0IAJeHH7iNO7P77pJIDWbRXY1c
4TUcxeu8Z31OwoR8expv8qLPPGQnO+YbUnwCCSmya9YohA+sDQPoMsbnb7M/k8No
KCoXr5FRrb67c/8k7zVHoXbwlQ2TWRLABEqHS2wA+UuHEOHQewjkpds5HMLc5rRW
mGWaa0bkE54XIQjbDgPOrg4yM7DizO45n4ue1yuntKCgL8Few5LC39IFsTxaQHDj
M8ljBV/XhZ8oJiOje43o+2nxDbmPh9bACt8EqG6Y2jmfY6jDWqDcp+tpvCUmdD1N
TIBRjSDNFviXQFXLDhtjDCF8QwegA8Zu+YYJMwroRzsLXEdQs1SBK2cOiVE73nA=
=mSJl
-END PGP SIGNATURE-
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Economic majority vote by splitting coins

[odinn via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

That's interesting.  But in all honesty I don't see most users being
able to pull off what you are describing.  If people don't want XT it
isn't going to get used. If they are convinced that it is needed its
use will grow but they won't realize how bad they will be misled until
later, at which point it will be...

.. Too Late

On 08/20/2015 04:16 AM, Tier Nolan via bitcoin-dev wrote:
> The economic majority is defined as the will of those who actually
> use Bitcoin as a payment system.
> 
> No matter what the miners want, if users and merchants refuse to
> accept their fork, then the fork loses and cannot be considered the
> "true" bitcoin fork.
> 
> The problem is that it is easy to measure a miner vote.  The
> economic majority is not so easy.
> 
> The relative value of two forks could be compared by adding a
> system similar colored coins.
> 
> These contracts could be added with a soft fork like the P2SH one.
> 
> OP_IF   OP_DROP OP_DROP OP_HASH160  1> OP_EQUAL OP_ENDIF OP_IF  OP_DROP OP_HASH160  script 2> OP_EQUAL OP_ENDIF
> 
> This works like P2SH and is template matching.  You can have as
> many entries as you want.
> 
> In the example, the output can be spent on fork 1 and fork 2 by
> the owner of  and can be spent on fork 3 by the
> owner of .
> 
> Until the deadline, the value on each fork must be preserved when 
> spending the output.  If you provide the key(s), you are allowed
> to consolidate entries.  You can also consolidate multiple outputs
> to the same key even if you don't have the key.
> 
> This means that split outputs are a little more hassle to use and
> the transactions are larger.  This doesn't matter much, since
> measuring the relative value of the two sub-coins only requires
> some of them to be traded.
> 
> If someone wants to propose a hard fork, they create a new fork id
> and deadline and release software that implements the hard fork at
> the given deadline (no miner vote needed).
> 
> To prevent spam, there could be a cost to create a fork-id (BTC
> paid to OP_RETURN) and the deadline could have a max time in the
> future (say 2 years).
> 
> After the deadline, core will allow conversion of outputs that pay
> to the core fork-id (probably 1) to be converted into unencumbered
> outputs by the person with the core-id script.  Likewise, the fork
> software will allow outputs that pay to the fork id to be
> converted.  Legacy bitcoin that haven't been "split" will be
> spendable on both sides equally.
> 
> This means that users can convert x legacy bitcoin into x
> fork-bitcoins and x core-bitcoins in advance of the fork.
> 
> This means that Exchanges could support trading between the two.
> The side that trades with the most value is the one that is
> supported by the economic majority.
> 
> As it becomes clear which side is going to win, the price of coins
> on the losing side should drop.  It is unlikely that the two would
> stay at exactly the same value without one side winning.
> 
> Users who want to to use the losing rules are free to do so but
> the economic majority will have made its decision.
> 
> 
> ___ bitcoin-dev mailing
> list bitcoin-dev@lists.linuxfoundation.org 
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 

- -- 
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJV1pmGAAoJEGxwq/inSG8CH7sH/ik9CE8V97zcALmbRi0w/DFr
/LxJVUHpl3XhV/2BtQP0Z1qd9OkEhmuG3wOdweCi089ksMbj2BLZ16EgXOnmjXCe
kB+Wk+nG5DglvQwpV1Tnl7UGfqvtry0sOUH9g5wZxJGIdnin3YQEP+TofJTVkrHw
MvU/MifsJZlzBHYcjYjGmkyAzhGUcurUAD5q+wz+iq4JsE/Zvtr5mR3ctPoaKx2w
7wMjSsGRWLYejv+7qYKwEjSV/ELSZCVIPURBUGBzkwWSaXTKdMf17sb44xF5m42i
5CjsGQxA7pY7EMHbYTz/hfUqElZp5y7MXoxoYkPh9ehyG1HSPSyUnxAPrAhc/+Y=
=2F2R
-END PGP SIGNATURE-
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Will there be a freeze of the current protocol version?

[odinn via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

To answer your question, from my perspective, I am not opposed to
block size increase.. I am hoping it would be in the context of
something like BIP 100 as I've said before.

But I'm extremely opposed to XT.

Would I continue with bitcoin if things continue and "XT prevails" as
you put it?  That is addressed in part here in this thread:

https://bitcointalk.org/index.php?topic=1157545.msg12196537

Basically, in short, I would fight it as long as possible.
I won't use XT, and I suspect there are many like myself who will
never use it as well.

On 08/20/2015 03:16 AM, Oliver Egginger via bitcoin-dev wrote:
> Hello,
> 
> BitPay seems to support BIP 101:
> 
> https://medium.com/@spair/increasing-the-block-size-limit-85ff236fc516
>
>  We do not know where this is going. But I suspect that ultimately
> also the core client will increase the block size.
> 
> Bitcoin is also the subject of research. I think that research is
> much to slow (and uncertain) for many companies and users. This is
> the reason for XT. Nevertheless, I think further research on the
> base of the current protocol version is very important. Thus, I
> hope that the current block chain survives. Albeit at a lower level
> with fewer users. And expressly not to sabotage necessary changes
> in the main project.
> 
> Let's suppose XT prevails or core is changed within the terms of
> BIP 101:
> 
> Do you think that there are enough people to continue with the old 
> protocol version? Would developers fork a Bitcoin client for
> supporting the old nodes with security updates? Or will there be a
> compatibility mode in XT, so that XT behave like an old Bitcoin
> node? What about smaller but important projects like picocoin?
> 
> - oliver ___ 
> bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org 
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 

- -- 
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJV1paRAAoJEGxwq/inSG8CTkQH/3N1kEuiGOCwHOe0Upw+XLi5
lIt0eME9cWsknqJvHyASVF6OGRcNdl5GFd2KG25P7NoxE5ZyP6zRuwzcPkAuDPNz
h+3lnNYx/e2sg69FPNXSnhShV0mlGAV7r/poLRFMP4AsOyq4kVmjD3LFFndnRJ9I
SekAj847ocMqcujkTt29gKw4JNT7JiWAbGELpxms4GYHvyCdDkjS319GfN5BcerV
xSYXcfrlji+dNFoll1TAEfXjcfuYmMitdXdRmbbcslxB57hAY/owwTRyOkjnrwDV
vacPYRauG2xcYQVGQAvRPSXaKtaE0sBau5Yjk1eN534knggypdrx0CC+BmqEqhA=
=HpeA
-END PGP SIGNATURE-
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin XT Fork

[odinn via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Bitcoin XT isn't technically an implementation of BIP 101.

It's really just an attack on the bitcoin network, not a whole
different than any of a variety of attacks one could perform on the
network.

Facts are as follows.

The published implementation of BIP 101 is shown on the BIP 101 page:

https://github.com/bitcoin/bips/blob/master/bip-0101.mediawiki

at:

https://github.com/bitcoin/bips/blob/master/bip-0101.mediawiki#Implement
ation

The only text in the Implementation section is the following link:

https://github.com/bitcoin/bitcoin/pull/6341

Which is closed by Gavin.

I am wondering why this drama continues, sort of stunned (but not
surprised) by Hearn's XT-hyping, bitcoin-attacking behavior and
crazed, delusional attitude, and hoping that consensus will be reached
on something - by something, I mean one of the following as shown at
http://bipsxdevs.azurewebsites.net/ -
well before XT achieves its goals.

By the way, since http://bipsxdevs.azurewebsites.net/ doesn't yet
appear to have any developers' signatures on it (except for luke-jr),
I'd like to take a moment to ask the developers if you could please
visit that site and put your signatures to it.  (Thanks to luke-jr for
being the first one.)

- - O

On 08/20/2015 02:13 AM, Peter Todd via bitcoin-dev wrote:
> On Thu, Aug 20, 2015 at 11:00:14AM +0200, Mike Hearn via
> bitcoin-dev wrote:
>>> 
>>> It is just that no one else is reckless enough to bypass the
>>> review process
>> 
>> 
>> I keep seeing this notion crop up.
>> 
>> I want to kill this idea right now:
>> 
>> - There were months of public discussion leading to up the
>> authoring of BIP 101, both on this mailing list and elsewhere.
>> 
>> - BIP 101 was submitted for review via the normal process. Jeff
>> Garzik specifically called Gavin out on Twitter and thanked him
>> for following the process:
>> 
>> https://twitter.com/jgarzik/status/614412097359708160
>> 
>> https://github.com/bitcoin/bips/pull/163
>> 
>> As you can see, other than a few minor typo fixes and a comment
>> by sipa, there was no other review offered.
>> 
>> - The implementation for BIP 101 was submitted to Bitcoin Core as
>> a pull request, to invoke the code review process:
>> 
>> https://github.com/bitcoin/bitcoin/pull/6341
>> 
>> Some minor code layout suggestions were made by Cory and
>> incorporated. Peter popped up to say there was no chance it'd
>> ever be accepted . and no further review was done.
> 
> No, I said there was no chance it'd be accepted "due to a number
> of BIP-level issues in addition to debate about the patch itself.
> For instance, Gavin has never given any details about testing; at
> minimum we'd need a BIP16 style quality assurance document. We also
> frown on writing software with building expiration dates, let alone
> expiration dates that trigger non-deterministically. (Note how my
> recently merged CLTV considered the year 2038 problem to avoid
> needing a hard fork at that date)"
> 
> Of course no further review was done - issues were identified and
> they didn't get fixed. Why would we do further review on something
> that was broken whose author wasn't interested in fixing even
> non-controversial and obvious problems?
> 
> The process is to do review, fix issues identified, and repeat
> until all issues are fixed.
> 
> 
> 
> ___ bitcoin-dev mailing
> list bitcoin-dev@lists.linuxfoundation.org 
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 

- -- 
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJV1pSTAAoJEGxwq/inSG8Css4IAMDPeUGm0hmScg1a2vDh+Vob
oeMGzwNfJngzFYpjvc+Wg+BnSTJBTWuc/lAm1Y4Rrdra6/o8CmYx9HERKFzaMszm
gZ0JQGsB7F7FPBwcLpXW+GI2mZz+orQoDXYB38ICF5arBIL95EyjNxEIcWR7Yb3+
XHsEFSlcxSKtF2UzkZHH10VALD7exveXAfdCNFSh/C1lcS+MqrhNjQ7Cal2BdJt3
Rnz7snTOYYb7hlTphEzHMA/9ftLIaQoNJZcVKg//5xgouc+C1S29St0pnTW6dsOD
p+VAfTnXb+PCSVl3mK8twEx2YqINK8IbK3DsnjXk/+zNZPyEa5wqnntZTI/0eSg=
=nakV
-END PGP SIGNATURE-
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin XT Fork

[odinn via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

re. Gavin and commit access

On 08/19/2015 12:15 PM, Btc Drak via bitcoin-dev wrote:
> On Wed, Aug 19, 2015 at 7:20 PM, Peter Todd 
> wrote:
>> Normal GitHub users submitting pull-reqs to Bitcoin Core can't
>> delete other users' comments on their own pull-reqs...
>> 
>> IMO that's an abuse of the pull-req process, and in turn, Gavin 
>> Andresens's commit access rights for the Bitcoin Core repo.
> 
> For the avoidance of doubt here's the archive link of my comment 
> https://archive.is/omvSY#40% (call me paranoid) and here's where he
> tells me he's censored my posts https://archive.is/vym6N#40%
> 
>> I think this should weigh in favor of Gavin Andresen not having
>> commit privileges for the Bitcoin Core repository.
> 
> It's time.

I agree, fwiw.  If he's going to censor others then that's
inconsistent with the responsibility of having commit access.

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

- -- 
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJV1NnDAAoJEGxwq/inSG8C0H0H/0ygc10hDP59Z2ktB8+wxqek
qLdMS4WbzPQzXkAAeVCu4RWzqeJjJZZ66VZ2aPBdsHHPIqOikAYAy3EaYQ2M7VIy
D6FW+AZK3ZHXX/ENVvtEPegu58ykk7QoWQkKQbH1Jqfxa0wcv3PQ5HtH92GReCNP
cNUMjnJkdI1XIVVQ8XRZ3OfOwUrJlSV7o9kKb6KRlEyXiGPRMI/myHIBBkKg5RkW
4Zc6GqRUiT7MIpQcRGV1/h5LuVyszbo70SrhX1D/w2W4B87bGScpH98hwqqKu+td
HnbI6VqLD1xMKBnj18GdpCJzKePkXoR0FHjkipcABXTjRa4Oy52AZyxU4w7luqI=
=PD5w
-END PGP SIGNATURE-
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin is an experiment. Why don't we have an experimental hardfork?

[odinn via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 08/19/2015 04:06 AM, Jorge Timón wrote:
> On Wed, Aug 19, 2015 at 12:14 PM, odinn
>  wrote:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>> 
>> Firstly, XT is controversial, not uncontroversial;
> 
> XT it's just a software fork.


You must be really tired.

Please read the whole pull request discussing this loathsome subject her
e:

https://github.com/bitcoin-dot-org/bitcoin.org/pull/899

It was fairly detailed and conclusive. I'm not being a dumdum when I
say that it is controversial.

> BIP101 (as currently implemented in Bitcoin XT) is a Schism
> hardfork (or an altcoin), but BIP101 could be modified to be
> deployed like an uncontroversial hardfork (in current bip99's
> draft, a given height plus 95% mining upgrade confirmation after
> that).

Everybody here is well aware of what this sad proposal is.  See
detailed reply to the moaning and groaning of Hearn on this subject,
where he claimed that "the difference between hard and soft forks is
actually quite small, has got smaller with time and is thus hardly the
policy-founding chasm you seem to think it is."  He was wrong, of
course.  Thus, my reply to that, which I won't bother to quote in
detail but which you can read here:
https://github.com/bitcoin-dot-org/bitcoin.org/pull/899#issuecomment-117
815987

> 
>> Third, it poses major risks as a non-peer reviewed alt with a
>> number of problematic features (with the privacy problems
>> recently mentioned on this list being just one of them)
>> 
>> Fourth, it has not followed any semblance of process in terms of
>> the development funnel or BIPS process, with XT developers
>> instead choosing instead a dangerous path of hard forking bitcoin
>> while being well aware of miner voting on viable solutions which
>> have followed process.
> 
> I'm not defending the Schism hardfork being proposed. I am very 
> worried about it and I have publicly said so several times. If
> Bitcoin XT didn't contained the Schism bip101 hardfork I wouldn't 
> be so worried: users are free to use software that is less reviewed
> at their own risk.
> 
>> The following proposals http://bipsxdevs.azurewebsites.net/ 
>> regardless of what you think of any one of them, are deserving
>> of attention (BIP 100 / BIP 101) and are being voted on as you
>> read this by miners. (BIP sipa is not yet numbered, and BIP 102
>> is a backup /fallback option.)  BIP 100 is probably the best of
>> these (note, in part, it schedules a hardfork on testnet in
>> September).
> 
> It's users and not miners who decide the consensus rules.
> 
>> Contentious hard forks are bad for Bitcoin. 
>> https://bitcoin.org/en/posts/hard-fork-policy You may want to
>> read this again if you haven't recently.
> 
> You may want to read BIP99 to understand that I know this, but
> still think that Schism hardforks may be necessary in some
> situations (I don't think this one is reasonable though).


Given the state in which bitcoin is in now, one could say that things
are fairly horrible, but by no means necessitating, as you put it, a
schism hardfork.  It is clear and evidenced by my previous posts and
others that Hearn's efforts are an attack on the bitcoin network.

> 
>> There is no basis for further promoting XT by suggesting that it 
>> should even be tested.
> 
> All I'm saying is that Bitcoin XT the software fork is totally
> fine (like other alternative Bitcoin implementations).

It's not totally fine at all.  It shouldn't even exist.  People are
doing other unsuspecting users a disservice by even suggesting that it
should be downloaded.

 The big problem is
> BIP101 being deployed as a Schism hardfork.

This is certainly a problem.

> 

#GAVEL

- -- 
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJV1GevAAoJEGxwq/inSG8CJXwH/3XX7Osr48MmcJ9mrPyOJ4Zn
WxRmdJ99mbO5KhrjD8+eRtFjURQNsQYAJ6ftnQEGaksuprSYCPQQR6WsV9mqRKZ2
/zdSz/5RjdADsjB2FDN6gWpwpyg7tzUpB6D4rCjuL1fcRmieCxwNUxnnFTbedxpE
MdT2oj9uSB7tTvU4AYs2VzJq0QeRn/c0pTJkBDwU0c4PN1tv/IQnOzmS+LnQDQJJ
eaunhpbmphRzqC9Mh8N7pD40ZyVoM5ysxVv86OaqmsOQL4W01CahQKADB4T/pBla
AOPh3LLxp7aamC9aYnBfxIaWXj28BZCwVasDkJdQ/Qg/rV5/Kze7TjJs9G2sowc=
=OvDj
-END PGP SIGNATURE-
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin is an experiment. Why don't we have an experimental hardfork?

[odinn via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Firstly, XT is controversial, not uncontroversial;
Second, this issue has been beat to death quite a while ago
https://github.com/bitcoin-dot-org/bitcoin.org/pull/899#issuecomment-117
815987
Third, it poses major risks as a non-peer reviewed alt with a number
of problematic features (with the privacy problems recently mentioned
on this list being just one of them)
Fourth, it has not followed any semblance of process in terms of the
development funnel or BIPS process, with XT developers instead
choosing instead a dangerous path of hard forking bitcoin while being
well aware of miner voting on viable solutions which have followed
process.

The following proposals
http://bipsxdevs.azurewebsites.net/
regardless of what you think of any one of them, are deserving of
attention (BIP 100 / BIP 101) and are being voted on as you read this
by miners. (BIP sipa is not yet numbered, and BIP 102 is a backup
/fallback option.)  BIP 100 is probably the best of these (note, in
part, it schedules a hardfork on testnet in September).

Contentious hard forks are bad for Bitcoin.
https://bitcoin.org/en/posts/hard-fork-policy
You may want to read this again if you haven't recently.

There is no basis for further promoting XT by suggesting that it
should even be tested.

#GAVEL

On 08/19/2015 02:29 AM, Jorge Timón via bitcoin-dev wrote:
> On Tue, Aug 18, 2015 at 11:06 PM, Danny Thorpe via bitcoin-dev 
>  wrote:
>> 
>> Ya, so?  All that means is that the experiment might reach the
>> hard fork tipping point faster than mainnet would. Verifying that
>> the network can handle such transitions, and how larger blocks
>> affect the network, is the point of testing.
>> 
>> And when I refer to testnet, I mean the public global testnet
>> blockchain, not in-house isolated networks like
>> testnet-in-a-box.
> 
> I would expect any uncontroversial hardfork to be deployed in
> testnet3 before it is deployed in bitcoin's main chain.
> 
> In any case, you can already do these tests using 
> https://github.com/bitcoin/bitcoin/pull/6382 Note that even if the
> new testchains are regtest-like (ie cheap proof of work) you don't
> need to test them "in-a-box": you can run them from many different
> places. Rusty's test ( http://rusty.ozlabs.org/?p=509 ) could have
> been perfectly made using #6382, it just didn't existed at the
> time. ___ bitcoin-dev
> mailing list bitcoin-dev@lists.linuxfoundation.org 
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 

- -- 
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJV1FcVAAoJEGxwq/inSG8CAd8H/R9khvHJJaNKrq7tjzksyc6V
jNN8ApaYUOE/i+goKd7XaeW0LM0aUC5vdqOCud632zb9XGo6awlk0fML4FV+wsE0
e5EfVDKZJxQ7zbaNCXXKTUfC+XRpJlhJgfF9jDgTsKv2l8fALbz+U6tn65Ke8F4+
9A4jJCe8yjttjBkX+8wLsSeDkDsPxo7f29rPfI6YMtN4MYbdxGiLjrTuRWrVje8q
l+3IFxrqGwKQl3LygRQHmLosvcW8UZzGYIM7hCleE9NUpc9TdpyTXPB3+9O9h4ty
5vY9jZ6t2Ww9CeljzD8S+1Nycz7sHqeoBCie+WexY7aT/QV2WQxFp4qnpO7PMSs=
=UNYA
-END PGP SIGNATURE-
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Ensuring Users have Safe Software and Version

[odinn via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


Recently I was re-reading the following (which has been edited
periodically):

https://bitcoin.org/en/alerts

It currently reads, "There is no ongoing event on the Bitcoin network."

However, in reading the most recent alert on that page, we are (it
seems) still affected by the issues discussed relative to the 4th of
July event, namely:

https://bitcoin.org/en/alert/2015-07-04-spv-mining

This originally was formulated in alerts via discussion on bitcoin.org
repository, here:
https://github.com/bitcoin-dot-org/bitcoin.org/pull/933

So anyway.

Getting back to this, how do I ensure that I have a safe version?

Thus far I am still using the guidance here from the bitcoin.org alert
shown above.  For example, for Electrum, bitcoin.org not only directs
users to wait 30 confirmations more than usual, but also directs users
to the following resource:
https://en.bitcoin.it/w/index.php?title=July_2015_chain_forks&redirect=n
o

This brings me to the "safe software and version."  If we understand
this correctly, the safe software and version will be Bitcoin Core at
its most current version.  Thus it is vitally important to provide a
way to ensure that users do not inadvertently be misled into
connecting to a XT node.

However, the information (about the software and version, in banner)
is provided voluntarily by the server administrators and thus isn't
validated.  How to make sure that you are actually connecting to one
who is running Core with the proper version (and not Core with some
very old version, or XT)?

On the bitcoin wiki, it states in part,
"During a fork, it is possible to use the Get Block Header custom
plugin[3] to authoritatively determine which side of the fork an
Electrum server is on."  It refers to this:
https://bitcointalk.org/index.php?topic=1110912.msg11800126

Depending on what wallet people are using, that is, Core, any of the
other wallets... hardware, desktop, web, mobile... there would be
different ways to determine what software is being used to make sure
that you are using Core in the current version (and not inadvertently
using XT for example).  The question is, how would this be done most
easily?

Thanks in advance for your answer(s).
- -- 
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJV1CakAAoJEGxwq/inSG8CLPUH/RnCMjGSFrPQc9wvRv9NWPYP
Mr+pzIBpiOXvikYXBT6cm/2AmmKhNmOjAHcdb9VrXPbk5ov/+odlcjGKeyXBc8zr
6+FAhDrnmznL1TEn+DL1UUBQlonNf4MFK8YZBusslFA14lSCSywn9IdubPD3ONzc
4f0uHl6c4wk0yLfmlJPbHevaEY/UdIyxPde2Nw+7IImWpdGJjBUiKTGb7/ZC4hTR
dTWmKNKAiXpCd2om86jbo12WP0rgpv66P2DgeetPzv8/dwWoons3FUJL/+tveFlm
SuTmjZWlDtzPm/56eTXUU64y7bSWYLrdQXxUk8zqzlYL5CJuVJ+1fi8OjwYYZH0=
=4J93
-END PGP SIGNATURE-
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Incentives to run full nodes

[odinn via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Potentially relevant...

"Incentivizing the running of full nodes"

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-June/006028
.html

(However, the issue to which I referred here is now closed)

View whole thread:

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-June/thread
.html#6028

On 08/17/2015 02:44 PM, Chris Pacia via bitcoin-dev wrote:
> 
> On Aug 17, 2015 5:29 PM, "Peter Todd via bitcoin-dev" 
>  > wrote: From the
> point of view of a
>> wallet, it's not very secure to use Hearn-style SPV mode, and
>> volunteers running full nodes doesn't help things. Sybil
>> attacking the IP address space is pretty easy in comparison to
>> aquiring hashing power sufficient to create false confirmations,
>> so any attacker able to do the former will likely be running the
>> full node you're connecting too anyway. Ultimately, Hearn-style
>> SPV is a close approximation to just trusting anyone with a
>> non-trivial amount of hashing power. (and getting that is 
>> surprisingly easy, e.g. w/ SPV mining)
> 
> Can you explain how the spv node fails against an attacker with a 
> non-trivial amount of hash power where a full node doesn't? To
> attack an spv wallet that is waiting for 6 or 10 confirmations, you
> would not only need to Sybil them but also summon a massive amount
> of hashing power to create a chain of headers (while forgoing the
> opportunity to mine valid blocks with that hash power).
> 
> But could someone with that much hash power not Sybil a full node
> and give them a chain for valid blocks (but on an orphan fork)? The
> failure model doesn't seem specific to spv to me.
> 
> 
> 
> ___ bitcoin-dev mailing
> list bitcoin-dev@lists.linuxfoundation.org 
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 

- -- 
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJV1BJLAAoJEGxwq/inSG8CUAoH/3SwFKxhRBFA8SFAj7ia2Af8
ITEOkLyNM23lxW4yUdHhxtPiHbvXDXctZ9LESgp39kmE3MEYZW7IhcmJ7WRBNNVq
sTXANa5B/o+LwYbVDdS8Rt/p8dTs+xxPWreuycLJFwoOFbhbqp8wFqdJvZb/w45F
MSTBeXUOVr65sBW5zSrindGxCzmi33b9FoTWHdZ0wQtyDInk3goixWFRJ5n95/nI
msA8iIDvPQBv0naXR9/3CiEvJz274TSBvlvhOR5IBKTv9pxamX/fjWDUe/Z6uyg1
3469EtimDb+BVhlEvcPPJBOwAOKQnRLdi2N4xVg+2csFtknBkc45uuxjvaq/yis=
=75Cp
-END PGP SIGNATURE-
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Annoucing Not-BitcoinXT

[odinn via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Agreed.

On 08/17/2015 07:36 AM, Adam Back via bitcoin-dev wrote:
> Thank you Eric for saying what needs to be said.
> 
> Starting a fork war is just not constructive and there are
> multiple proposals being evaluated here.
> 
> I think that one thing that is not being so much focussed on is 
> Bitcoin-XT is both a hard-fork and a soft-fork.  It's a hard-fork
> on Bitcoin full-nodes, but it is also a soft-fork attack on Bitcoin
> core SPV nodes that did not opt-in.  It exposes those SPV nodes to
> loss in the likely event that Bitcoin-XT results in a
> network-split.
> 
> The recent proposal here to run noXT (patch to falsely claim to
> mine on XT while actually rejecting it's blocks) could add enough 
> uncertainty about the activation that Bitcoin-XT would probably
> have to be aborted.
> 
> Adam
> 
> On 17 August 2015 at 15:03, Eric Lombrozo via bitcoin-dev 
>  wrote:
>> NxtChg,
>> 
>> In the entire history of Bitcoin we’ve never attempted anything
>> even closely resembling a hard fork like what’s being proposed
>> here.
>> 
>> Many of us have wanted to push our own hard-forking changes to
>> the protocol…and have been frustrated because of the inability to
>> do so.
>> 
>> This inability is not due to any malice on anyone’s part…it is a
>> feature of Satoshi’s protocol. For better or worse, it is *very
>> hard* to change the rules…and this is exactly what imbues Bitcoin
>> with one of its most powerful attributes: very well-defined
>> settlement guarantees that cannot be suddenly altered nor
>> reversed by anyone.
>> 
>> We’ve managed to have a few soft forks in the past…and for the
>> most part these changes have been pretty uncontroversial…or at
>> least, they have not had nearly the level of political
>> divisiveness that this block size issue is having. And even then,
>> we’ve encountered a number of problems with these deployments
>> that have at times required goodwill cooperation between
>> developers and mining pool operators to fix.
>> 
>> Again, we have NEVER attempted anything even remotely like what’s
>> being proposed - we’ve never done any sort of hard fork before
>> like this. If even fairly uncontroversial soft forks have caused
>> problems, can you imagine the kinds of potential problems that a
>> hard fork over some highly polarizing issue might raise? Do you
>> really think people are going to want to cooperate?!?
>> 
>> I can understand that some people would like bigger blocks. Other
>> people might want feature X, others feature Y…and we can argue
>> the merits of this or that to death…but the fact remains that we
>> have NEVER attempted any hard forking change…not even with a
>> simple, totally uncontroversial no-brainer improvement that would
>> not risk any sort of ill-will that could hamper remedies were it
>> not to go as smoothly as we like. *THIS* is the fundamental
>> problem - the whole bigger block thing is a minor issue by
>> comparison…it could be any controversial change, really.
>> 
>> Would you want to send your test pilots on their first flight…the
>> first time an aircraft is ever flown…directly into combat without
>> having tested the plane? This is what attempting a hard fork
>> mechanism that’s NEVER been done before in such a politically
>> divisive environment basically amounts to…but it’s even worse.
>> We’re basically risking the entire air force (not just one plane)
>> over an argument regarding how many seats a plane should have
>> that we’ve never flown before.
>> 
>> We’re talking billlions of dollars’ worth of other people’s money
>> that is on the line here. Don’t we owe it to them to at least
>> test out the system on a far less controversial, far less
>> divisive change first to make sure we can even deploy it without
>> things breaking? I don’t even care about the merits regarding
>> bigger blocks vs. smaller blocks at this point, to be quite
>> honest - that’s such a petty thing compared to what I’m talking
>> about here. If we attempt a novel hard-forking mechanism that’s
>> NEVER been attempted before (and which as many have pointed out
>> is potentially fraught with serious problems) on such a
>> politically divisive, polarizing issue, the result is each side
>> will refuse to cooperate with the other out of spite…and can
>> easily lead to a war, tanking the value of everyone’s assets on
>> both chains. All so we can process 8 times the number of
>> transactions we currently do? Even if it were 100 times, we
>> wouldn’t even come close to touching big payment processors like
>> Visa. It’s hard to imagine a protocol improvement that’s worth
>> the risk.
>> 
>> I urge you to at least try to see the bigger picture here…and to
>> understand that nobody is trying to stop anyone from doing
>> anything out of some desire for maintaining control - NONE of us
>> are able to deploy hard forks right now without facing these
>> problems. And different people obviously have different
>> priorities and preferen

Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase

[odinn via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Tier ~

I don't think the XT author(s) are going to do what you are
describing.  Their recent release, at
https://github.com/bitcoinxt/bitcoinxt/blob/0.11A/README.md
doesn't show any sign of moving toward a version which would be
"increasing consensus." Instead, they ignore any meaningful process
and, as I have recently indicated, have created somthing which
"sidetrack(s) real discussion necessary to resolve the issues so as to
achieve some level of consensus in block size debates."

That doesn't rule out that the BIP authors can't work together and
create something meaningful and useful, though.  As I stated before,

"In my past message(s), I've suggested that Jeff's BIP 100
is a better alternative to Gavin's proposal(s), but that I didn't
think that this should be taken to mean that I am saying one thing is
"superior" to Gavin's work, rather, I emphasized that Gavin work with
Jeff and Adam."

I am also looking forward to seeing some visualizations or graphs of
the miner votes going on right now on BIP 100 and BIP 101, for example.

Regarding XT, my statement is simple:

"Do not download this loathsome XT thing. Cast it back into the fires
from whence it came."

- - Odinn



On 08/17/2015 06:15 AM, Tier Nolan via bitcoin-dev wrote:
> One of the comments made by the mining pools is that they won't run
> XT because it is "experimental".
> 
> Has there been any consideration to making available a version of
> XT with only the blocksize changes?
> 
> The least "experimental" version would be one that makes the
> absolute minimum changes to core.
> 
> The MAX_BLOCK_SIZE parameter could be overwritten whenever the
> longest tip changes.  This saves creating a new function.
> 
> Without the consensus measuring code, the patch would be even
> easier. Satoshi's proposal was just a block height comparison (a
> year in advance).
> 
> The state storing code is also another complication.  If the
> standard "counting" upgrade system was used, then no state would
> need to be stored in the database.
> 
> On Wed, Jul 1, 2015 at 11:49 PM, odinn
>  > wrote:
> 
> (My replies below)
> 
> On 06/26/2015 06:47 AM, Tier Nolan wrote:
>> On Thu, Jun 25, 2015 at 3:07 PM, Adam Back >  > >> wrote:
> 
>> The hard-cap serves the purpose of a safety limit in case our 
>> understanding about the economics, incentives or game-theory is 
>> wrong worst case.
> 
> 
>> True.
> 
> Yep.
> 
> 
>> BIP 100 and 101 could be combined.  Would that increase
>> consensus?
> 
> Possibly ~ In my past message(s), I've suggested that Jeff's BIP
> 100 is a better alternative to Gavin's proposal(s), but that I
> didn't think that this should be taken to mean that I am saying one
> thing is "superior" to Gavin's work, rather, I emphasized that
> Gavin work with Jeff and Adam.
> 
> At least, at this stage the things are in a BIP process.
> 
> If the BIP 100 and BIP 101 would be combined, what would that look 
> like on paper?
> 
> 
>> - Miner vote threshold reached - Wait notice period or until 
>> earliest start time - Block size default target set to 1 MB -
>> Soft limit set to 1MB - Hard limit set to 8MB + double every 2
>> years - Miner vote to decide soft limit (lowest size ignoring
>> bottom 20% but 1MB minimum)
> 
>> Block size updates could be aligned with the difficulty setting 
>> and based on the last 2016 blocks.
> 
>> Miners could leave the 1MB limit in place initially.  The vote
>> is to get the option to increase the block size.
> 
>> Legacy clients would remain in the network until >80% of miners 
>> vote to raise the limit and a miner produces a >1MB block.
> 
>> If the growth rate over-estimates hardware improvements, the
>> devs could add a limit into the core client.  If they give notice
>> and enough users update, then miners would have to accept it.
> 
>> The block size becomes min(miner's vote, core devs).  Even if 4 
>> years notice is given, blocks would only be 4X optimal.
> 
> 
>> ___ 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
> 

- -- 
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJV0/vrAAoJEGxwq/inSG8CUSQH/0rX9j1f/tSYYxUeD8ktLm6b
WkB26eNEIEwpTNGwjjYbfVou29ZGGkp58P2jv7S52RekTS3dQshjj5wgFdXE1IX4
HhgMVEnyX2Hgooeu9O32HHfjSLxgxkAozibu0NM4NnRfFQU/DTSz5+H1rABUKnl3
k2LWkhoyX517/x1GUPiGGweGpOTSwC/6BxuhCUjx1vuL9Bpp93gWRf9cRlf99Xn3
Gaa

Re: [bitcoin-dev] Bitcoin XT Fork

[odinn via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

The "XT Fork" (better said, a POS alt*) and those behind it make not
even a pretense to work through process involved with bitcoin developmen
t.

(*This is not intended as a slight toward any other alts, as here in
this post I am focusing solely on XT.)

Instead of abandoning their useless project, or at least conceding
that their alt is operating essentially outside of the development
funnel (by this I mean BIP process), the developers of XT, via their
latest presentation of XT give nothing more than an attack on bitcoin
(albeit one that, more than anything, is designed to sidetrack real
discussion necessary to resolve the issues so as to achieve some level
of consensus in block size debates).  Curiously, XT is not even truly
the implementation of BIP 101; the actual proposed implementation of
BIP 101 as proposed at
https://github.com/bitcoin/bips/blob/master/bip-0101.mediawiki#implement
ation
is found here: https://github.com/bitcoin/bitcoin/pull/6341
(It is currently a closed issue.)

It's probably valid to call into question why Mike Hearn in particular
persists with this project at all, as he has been its biggest
cheerleader. Some reasons may be:
1) His interest in attacking bitcoin in the past (seems to be a
recurring pattern)
https://bitcointalk.org/index.php?topic=333824.0

2) His employment (has come up before) - QinetiQ, Google, etc
https://plus.google.com/+MikeHearn/about - it's simply not
unreasonable to ask why he's pushing it so hard when nobody wants it.

3) Various reasons mentioned here:
https://www.reddit.com/r/Bitcoin/comments/39yaug/the_history_of_mike_hea
rn_and_why_you_should_not/


4) His disinterest in following what is actually happening with votes
on legitimate proposals (e.g. Garzik's BIP 100) in the blocks. (Caveat
~ one doesn't see the BIP 100 yet in bitcoin/bips because it won't
appear for another couple weeks, supposedly.  The miners' voting is
already happening however.) Even according to http://xtnodes.com/ we
see that XT runs minimal nodes in comparison to the rest of nodes
being run across the network.

BIP 100 itself is anticipated to be submitted w/ implementation in the
next 2 weeks and many miners are already voting on BIP 100 (as per
Jeff Garzik, from a post 08/12/2015 12:46 PM -0400 to this mailing list)
.

 It is an insult to see Hearn fling the XT turd into the community
repeatedly.

How then to end this XT madness?

"The ring was made in the fires of Mount Doom. Only there can it be
unmade. The ring must be taken deep into Mordor and cast back into the
fiery chasm from whence it came. One of you must do this."
- - Lord Elrond

Do not download this loathsome XT thing. Cast it back into the fires
from whence it came.

- -Odinn


On 08/15/2015 10:43 AM, Satoshi Nakamoto via bitcoin-dev wrote:
> I have been following the recent block size debates through the
> mailing list.  I had hoped the debate would resolve and that a fork
> proposal would achieve widespread consensus.  However with the
> formal release of Bitcoin XT 0.11A, this looks unlikely to happen,
> and so I am forced to share my concerns about this very dangerous
> fork.
> 
> The developers of this pretender-Bitcoin claim to be following my
> original vision, but nothing could be further from the truth.  When
> I designed Bitcoin, I designed it in such a way as to make future
> modifications to the consensus rules difficult without near
> unanimous agreement.  Bitcoin was designed to be protected from the
> influence of charismatic leaders, even if their name is Gavin
> Andresen, Barack Obama, or Satoshi Nakamoto.  Nearly everyone has
> to agree on a change, and they have to do it without being forced
> or pressured into it.  By doing a fork in this way, these
> developers are violating the "original vision" they claim to
> honour.
> 
> They use my old writings to make claims about what Bitcoin was
> supposed to be.  However I acknowledge that a lot has changed since
> that time, and new knowledge has been gained that contradicts some
> of my early opinions.  For example I didn't anticipate pooled
> mining and its effects on the security of the network.  Making
> Bitcoin a competitive monetary system while also preserving its
> security properties is not a trivial problem, and we should take
> more time to come up with a robust solution.  I suspect we need a
> better incentive for users to run nodes instead of relying solely
> on altruism.
> 
> If two developers can fork Bitcoin and succeed in redefining what
> "Bitcoin" is, in the face of widespread technical criticism and
> through the use of populist tactics, then I will have no choice but
> to declare Bitcoin a failed project.  Bitcoin was meant to be both
> technically and socially robust.  This present situation has been
> very disappointing to watch unfold.
> 
> Satoshi Nakamoto
> 
> ___ bitcoin-dev mailing
> list bitcoin-dev@lists.linuxfoundation.org 
> http

[bitcoin-dev] Voting (BIP-100) Question, Etc.

[odinn via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Assuming some form of BIP 100 is a path which people may want to take,
how and at what point do miners vote on this?
Note:
https://bitcoin.stackexchange.com/questions/37943/bip-100-what-votes-are
- -possible
describes this somewhat, but is unclear as to timeline of when miners
would do the things described.

Followup question thrown in for good measure:
When is BIP 100 anticipated to be published (moved to 'accepted' and
published) at
https://github.com/bitcoin/BIPS ?

- -- 
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJVy3gLAAoJEGxwq/inSG8C9kgH/2YHDIbf118I4k3uLYn0UzUQ
7iF+gV76pgtjsXmcUpRw1piZcUwWFQ1MszTn92PvmW9sjajuTPRBOOmHv1srsC4e
H9jrQ3AoBDZCeY6FnVZIkCUYvcexi+2DsUG3z+e82AssBVljuzh3SPTZimA7oe20
9RxcNxSMmvcRFxkaFfuAjr2BaxiwaWNV7mlG1KCdCV8JV8LoHZRiMe+MPN7I9QKo
yssEYP49TzaXBaAsRFXVl8N+pr5CRtXz+bv5Uh3WOAzhXMqpeliKnzTLdsgyz2SR
EfICr7GezOieBvNRCp3e+bVD4mkG20Da7y0jfrxahRNB7ZBWIiFuxu4inyoCH00=
=644w
-END PGP SIGNATURE-
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Fees and the block-finding process

[odinn via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hey Angel,

On 08/11/2015 02:14 AM, Angel Leon via bitcoin-dev wrote:
> -policy neutrality. - It can't be censored. - it can't be shut
> down - and the rules cannot change from underneath you.
> 
> except it can be shutdown the minute it actually gets used by its 
> inability to scale.
> 
> what's the point of having all this if nobody can use it? what's
> the point of going through all that energy and CO2 for a mere 
> 24,000 transactions an hour?
> 
> It's clear that it's just a matter of time before it collapses.
> 
> Here's a simple proposal (concept) that doesn't pretend to set a
> fixed block size limit as you can't ever know the demands the
> future will bring
> https://gist.github.com/gubatron/143e431ee01158f27db4

This seems to be a really good idea... May I add in here something
that's been dismissed before but I will mention it again anyway...

http://is.gd/DiFuRr "dynamic block size adjustment"
My sense has been that something like this could be coupled with
Garzik's BIP 100.  For some reason I keep getting attacked for saying
this.

/RantOff

> 
> We don't need to go as far as countries with hyper inflation trying
> to use the technology to make it collapse, anybody here who has
> distributed commercial/free end user software knows that any small
> company out there installs more copies in a couple weeks than all
> the bitcoin users we have at the moment, all we need is a single
> company/project with a decent amount of users who are now enabled
> to transact directly on the blockchain to screw it all up (perhaps
> OpenBazaar this winter could make this whole thing come down,
> hopefully they'll take this debate and the current limitations
> before their release, and boy are they coding nonstop on it now
> that they got funded), the last of your fears should be a malicious
> government trying to shut you down, for that to happen you must
> make an impact first, for now this is a silly game in the grand 
> scheme of things.
> 
> And you did sound pretty bad, all of his points were very valid and
> they share the concern of many people, many investors,
> entrepreneurs putting shitload of money, time and their lives on a
> much larger vision than that of a network that does a mere 3,500
> tx/hour, but some people seem to be able to live in impossible or
> useless ideals.
> 
> It's simply irresponsible to not want to give the network a chance
> to grow a bit more. Miners centralizing is inevitable given the POW
> based consensus, hobbists-mining is only there for countries with
> very cheap energy.
> 
> If things remain this way, this whole thing will be a massive
> failure and it will probably take another decade before we can open
> our mouths about cryptocurrencies, decentralization and what not,
> and this stubornness will be the one policy that censored everyone,
> that shutdown everyone, that made the immutable rules not matter.
> 
> Perhaps it will be Stellar what ends up delivering at this stubborn
> pace.
> 
> http://twitter.com/gubatron
> 
> On Tue, Aug 11, 2015 at 4:38 AM, Thomas Zander via bitcoin-dev 
>  > wrote:
> 
>> It follows then, that if we make a decision now which destroys
>> that property, which makes it possible to censor bitcoin, to deny
>> service, or to pressure miners into changing rules contrary to
>> user interests, then Bitcoin is no longer interesting.
> 
> You asked to be convinced of the need for bigger blocks. I gave
> that. What makes you think bitcoin will break when more people use
> it?
> 
> Sent on the go, excuse the brevity. *From: *Mark Friedenbach *Sent:
> *Tuesday, 11 August 2015 08:10 *To: *Thomas Zander *Cc: *Bitcoin
> Dev *Subject: *Re: [bitcoin-dev] Fees and the block-finding
> process
> 
> 
> On Mon, Aug 10, 2015 at 11:31 PM, Thomas Zander via bitcoin-dev 
>  > wrote:
> 
> On Monday 10. August 2015 23.03.39  Mark 
> Friedenbach wrote:
>> This is where things diverge. It's fine to pick a new limit or
>> growth trajectory. But defend it with data and reasoned
>> analysis.
> 
> We currently serve about 0,007% of the world population sending 
> maybe one transaction a month. This can only go up.
> 
> There are about 20 currencies in the world that are unstable and 
> showing early signs of hyperinflation. If even small percentage of
> these people cash-out and get Bitcoins for their savings you'd have
> the amount of people using Bitcoin as savings go from maybe half a
> million to 10 million in the space of a couple of months. Why so
> fast? Because all the world currencies are linked. Practically all
> currencies follow the USD, and while that one may stay robust and
> standing, the linkage has been shown in the past to cause 
> chain-effects.
> 
> It is impossible to predict how much uptake Bitcoin will take, but
> we have seen big rises in price as Cyprus had a bailin and then
> when Greece first showed bad signs 

Re: [bitcoin-dev] Fees and the block-finding process

[odinn via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello, I thought these were good points, but I have a couple questions..
.

On 08/11/2015 12:08 AM, Mark Friedenbach via bitcoin-dev wrote:
> On Mon, Aug 10, 2015 at 11:31 PM, Thomas Zander via bitcoin-dev 
>  > wrote:
> 
> On Monday 10. August 2015 23.03.39  Mark 
> Friedenbach wrote:
>> This is where things diverge. It's fine to pick a new limit or
>> growth trajectory. But defend it with data and reasoned
>> analysis.
> 
> We currently serve about 0,007% of the world population sending 
> maybe one transaction a month. This can only go up.
> 
> There are about 20 currencies in the world that are unstable and 
> showing early signs of hyperinflation. If even small percentage of
> these people cash-out and get Bitcoins for their savings you'd have
> the amount of people using Bitcoin as savings go from maybe half a
> million to 10 million in the space of a couple of months. Why so
> fast? Because all the world currencies are linked. Practically all
> currencies follow the USD, and while that one may stay robust and
> standing, the linkage has been shown in the past to cause 
> chain-effects.
> 
> It is impossible to predict how much uptake Bitcoin will take, but 
> we have seen big rises in price as Cyprus had a bailin and then
> when Greece first showed bad signs again. Lets do our due diligence
> and agree that in the current world economy there are sure signs
> that people are considering Bitcoin on a big scale.
> 
> Bigger amount of people holding Bitcoin savings won't make the 
> transaction rate go up very much, but if you have feet on the
> ground you already see that people go back to barter in countries
> like Poland, Ireland, Greece etc. And Bitcoin will be an
> alternative to good to ignore.  Then transaction rates will go up.
> Dramatically.
> 
> If you are asking for numbers, that is a bit tricky. Again; we are
> at 0,007%... Thats like a f-ing rounding error in the world
> economy. You can't reason from that. Its like using a float to do
> calculations that you should have done in a double and getting
> weird output.
> 
> Bottom line is that a maximum size of 8Mb blocks is not that odd. 
> Because a 20 times increase is very common in a "company" that is
> about 6 years old. For instance Android was about that age when it
> started to get shipped by non- Google companies. There the increase
> was substantially bigger and the company backing it was definitely
> able to change direction faster than the Bitcoin oiltanker can
> change direction.
> 
> ...
> 
> Another metric to remember; if you follow hackernews (well, the 
> incubator more than the linked articles) you'd be exposed to the
> thinking of these startups. Their only criteria is growth. and this
> is rather substantial growth. Like 150% per month.  Naturally, most
> of these build on top of html or other existing technologies.  But
> the point is that exponential growth is expected in any startup.
> They typically have a much much more agressive timeline, though.
> Every month instead of every year. Having exponential growth in the
> blockchain is really not odd and even if we have LN or sidechains
> or the next changetip, this space will be used. And we will still
> have scarcity.
> 
> 
> I'm sorry, I really don't want to sound like a jerk, but not a
> single word of that mattered. Yes we all want Bitcoin to scale such
> that every person in the world can use it without difficulty.
> However if that were all that we cared about then I would be remiss
> if I did not point out that there are plenty of better, faster, and
> cheaper solutions to finding global consensus over a payment ledger
> than Bitcoin. Architectures which are algorithmically superior in
> their scaling properties. Indeed they are already implemented and
> you can use them today:
> 
> https://www.stellar.org/ http://opentransactions.org/
> 
> So why do I work on Bitcoin, and why do I care about the outcome of
> this debate? Because Bitcoin offers one thing, and one thing only
> which alternative architectures fundamentally lack: policy
> neutrality. It can't be censored, it can't be shut down, and the
> rules cannot change from underneath you. *That* is what Bitcoin
> offers that can't be replicated at higher scale with a SQL database
> and an audit log.
> 
> It follows then, that if we make a decision now which destroys
> that property, which makes it possible to censor bitcoin, to deny
> service, or to pressure miners into changing rules contrary to user
> interests, then Bitcoin is no longer interesting. We might as well
> get rid of mining at that point and make Bitcoin look like Stellar
> or Open-Transactions because at least then we'd scale even better
> and not be pumping millions of tons of CO2 into the atmosphere from
> running all those ASICs.
> 
> On the other side, 3Tb harddrives are sold, which take 8Mb blocks 
> without problems.
> 
> 
> Straw man, storage is n

Re: [bitcoin-dev] What Lightning Is

[odinn via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Replying because.

On 08/10/2015 10:14 AM, Pieter Wuille wrote:
> 
> On Aug 10, 2015 7:03 PM, "odinn via bitcoin-dev" 
>  <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote: Note that
> I've
>> been in favor of going ahead with Cameron Garnham's dynamic
>> softfork proposal right now, which can be seen at
>> http://is.gd/DiFuRr
> 
> No offence, but I think that anyone who claims a block size limit
> change can be done as a soft fork has some basic reading to do
> first.

Technically, my proposal has been thus:

"Note that I've
been in favor of going ahead with Cameron Garnham's dynamic softfork
proposal right now, which can be seen at http://is.gd/DiFuRr - testing
it out, seeing how that works, and at the same time making
preparations for moving forward with Garzik's BIP 100 (which could be
tailored or refined based on additional data gathered, without being
turned into a controversial fork"

To have quoted it only in part was unfair.

> 
> Also, please keep this thread about Lightning.

Agreed.

> 
> -- Pieter
> 

- -- 
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJVyOMjAAoJEGxwq/inSG8CmAQIAI5XrAIa8VrkFYLtJ8s0CHqj
kZrMatH2oVGGaENVChVDU7u4SGnMQdiJF32QY5Olih3ia1rAx9n43tiyPyUp8y0S
iLudwFfyvmzSyRdoLnTRbDYkiNUnuy9lppZsL+AtQWCpMLxBIObs1NnzP7je4Qn2
a8lWklMf9mmlCyhyah7kJPdZzECwfpz2ARk68iUUAuqqLcFM2afmzcgLh2PuDRhU
6Hjw7crTXA5AhPSeNNz1az0cq5MTUv46SAr3mbAiMjFwz7tFWSWEGMTaTdQ/Igwe
JeMARTJuxY7QL1XHAmKgfHUEi6mmW2LiG0vm6xp8XnRfsUNfDVZ8IsmYky7kDLM=
=5Aay
-END PGP SIGNATURE-
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] What Lightning Is

[odinn via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello,

If I understand this correctly, Lightning only requires transaction
malleability to be fixed to be able to work ~ I believe that was going
to happen in a release of (bitcoind), but I'm not sure if that is
correct on timing ( note also, this wiki seems to be out of date on
infos about bitcoind https://en.bitcoin.it/wiki/Bitcoind )

I have also heard it said that bitcoin should support relative
locktime opcodes so that long-lived micropayment channels would be
able to be created, such that there would be Lightning functionality
beyond the basic microhop channels (which would be short-lived in
nature at the basic level).

This would be nice, but it seems like such discussions would take a
while to get done as basic development issues right now aren't even
wrapping up (e.g. blocksize debate related stuff.)  Note that I've
been in favor of going ahead with Cameron Garnham's dynamic softfork
proposal right now, which can be seen at http://is.gd/DiFuRr - testing
it out, seeing how that works, and at the same time making
preparations for moving forward with Garzik's BIP 100 (which could be
tailored or refined based on additional data gathered, without being
turned into a controversial fork (e.g. needs to make sure to avoid
inclusion of XT, for example).  Garnham's proposal and Garzik's
proposal are not mutually exclusive, imho, and I don't see why the
matter can't simply be resolved, it seems to be just an endless pile
of argumentation that will go on forever and ever.  This needs to,
like, stop.

Also, it strikes me that unless and until certain changes can be made
in bitcoin that would reduce fees and cost to transact, solutions such
as Lightning are going to fill the gap whether or not you want them
to; users have a choice in the market, and as the billions of unbanked
are gradually excluded from straight bitcoin, people will seek other
services which offer them lesser fees to transact, or they will seek
other coins which offer them lesser cost to transact.  It is, after
all, an open market.  I have made this point before elsewhere albeit
with more emphasis (and data to back up my point):
( On Github at Pull Request #6201: http://is.gd/8bW0zq )

In making and successfully defending such points on Github, the
following conclusions were drawn:
As the cost to transact goes higher and higher based on this
observable trend (due to all the factors mentioned in the thread on
github), then people who are affected by these rising costs to
transact will do one of three things with respect to bitcoin (and
virtual currencies generally):
1) Ignore bitcoin (an unlikely possibility, but it is one that would
occur),
2) adopt alts which are more inclined to allow people to perform
microtransactions,
3) and/or use bitcoin increasingly off-chain, which is likely to come
with its own set of problems for the network.

Regarding donation or microdonation use cases, To keep it all
on-chain, wallets can be designed to accumulate donation micro-amounts
according to donation settings of a user (in voluntary donation use
cases such as in ABIS -- http://abis.io ) as an internal accounting
feature, for example, and when enough donation value is accumulated,
it can be sent to the recipient by piggybacking on one of the user's
daily transactions.  This is one method doing so in a manner which is
on-chain; depending on the cryptocurrency under consideration, the
feasibility of doing this in a wallet will be greater or lesser.

- -O


On 08/09/2015 01:14 PM, Hector Chu via bitcoin-dev wrote:
> In the Lightning network it is assumed that the balances can always
> be settled on the blockchain if any of the parties along the
> channel has a problem. What if the fee on the settlement
> transactions is not high enough to enter the blockchain? You can't
> do replace-by-fee after the fact. Do the fees always have to assume
> worst case scenarios on the Bitcoin fee market?
> 
> On 9 August 2015 at 19:54, Mark Friedenbach via bitcoin-dev 
>  > wrote:
> 
> Tom, you appear to be misunderstanding how lightning network and 
> micropayment hub-and-spoke models in general work.
> 
>> But neither can Bob receive money, unless payment hub has
> advanced it to the channel (or (2) below applies).  Nothing
> requires the payment hub to do this.
> 
> On the contrary the funds were advanced by the hub on the creation 
> of the channel. There is no credit involved. if the funds aren't 
> already available for Bob to immediately claim his balance, the 
> payment doesn't go through in the first place.
> 
> On Sun, Aug 9, 2015 at 11:46 AM, Tom Harding via bitcoin-dev 
>  > wrote:
> 
> On 8/4/2015 4:27 AM, Pieter Wuille via bitcoin-dev wrote:
> 
>> Don't turn Bitcoin into something uninteresting, please.
> 
> Consider how Bob will receive money using the Lightning Network.
> 
> Bob receives a payment by applying a contract to

Re: [bitcoin-dev] Alternative chain support for payment protocol

[odinn via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I thought this would be a helpful visualization in the discussion:

http://mapofcoins.com/

Of note are the differences between alts which were derived from BTC
(Proof-of-work algorithm: SHA-256), vs. those which were developed in
a different fashion such as BCN (Proof-of-work algorithm: CryptoNight)
and its alts.

On 08/09/2015 11:42 AM, John L. Jegutanis via bitcoin-dev wrote:
> Another possibility to support side|alt-chains is the bip44 coin
> type registry.
> 
> A problem that hasn't been mentioned is that a coin can extend the 
> protocol in an incompatible way (different protocol buffer format)
> so just changing the network field in the PaymentDetails message
> will not work. A better approach is to add an optional coin type
> field to the PaymentRequest and serialize the incompatible
> PaymentDetails to the serialized_payment_details field.
> 
> To support a future testnet4 in PaymentDetails we only need to add
> a new network string like "test4".
> 
> On Aug 9, 2015 18:23, "Ross Nicoll via bitcoin-dev" 
>  > wrote:
> 
> I'm cautious of using human-meaningful identifiers, especially any 
> that might require a central repository, due to name collisions. 
> Examples that could be complicated include BitcoinDark, Litedoge, 
> and other names that base on existing coins. I think the ability
> to differentiate between test networks is also useful.
> 
> Could certainly just use the genesis hash as network ID, that
> would work. Bit long, but suspect 64 bytes isn't the end of the
> world! I'll see if any more responses come in then raise a BIP for
> using genesis hash as an alternative to short names.
> 
> Ross
> 
> 
> On 09/08/2015 15:29, Mike Hearn wrote:
>> 
>> I'd appreciate initial feedback on the idea, and if there's no 
>> major objections I'll raise this as a BIP.
>> 
>> 
>> The reason BIP 70 doesn't do this is the assumption that alt
>> coins are ... well  alt. They can vary in arbitrary ways
>> from Bitcoin, and so things in BIP70 that work for Bitcoin may or
>> may not work for other coins.
>> 
>> If your alt coin is close enough to BIP 70 that you can reuse it 
>> "as is" then IMO we should just define a new network string for 
>> your alt. network = "dogecoin-main" or whatever.
>> 
>> You could also use the genesis hash as the network name. That 
>> works too. But it's less clear and would involve lookups to
>> figure out what the request is for, if you find such a request in
>> the wild. I don't care much either way.
> 
> 
> ___ 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
> 

- -- 
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJVyMViAAoJEGxwq/inSG8ChpsIAKcNoOuzisnfhcOchoqCxQ9d
dRNr3LNnVYT64Gcw8O88vX8Drijq5vxU/qqNVx66wPU5+mn7iBltDfuckV5+9KNU
AyOM56CHC//xT8aXcw2jZgKXIPhW7fpjIrhn4Eg/Pra77DSBTTdqNuxQbII2WLB8
HFcahawnRElro6/OZFwjyyTrHE9oEes/u/EiUYB4P0hiZ0m3Yh0Xm1GrmVMLoxc0
HH30ZztHrl5/wzx4t4+qcOpXXvffjO+5n9hssyil8qUgI72HeBxz5C84P7VhYMXj
b2xm+LC2c0pFtjM/oqIMp6R7UgXa1MfQq8Kb5/uuIJ9JGFbwhebrN/61K7S5EiE=
=R32m
-END PGP SIGNATURE-
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] A reason we can all agree on to increase block size

[odinn via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jim, some good points... People are rightly concerned about any given
regional or nation-state's dominance in mining, but China has
certainly become more of a subject of concern as of late, and not
simply because it is a communist country and because its economy is
highly centralized and state-run, but rather, because of the advent of
newly proposed or adopted laws (not unlike those which we see being
proposed in the UK or those recently adopted in France, so that no-one
may say I am unfairly targeting China).  Further, the recent shots off
the bow between the USA and China in the latest crypto-wars saga
(whether bluster or ultimately not) mean that we should be seriously
concerned about too much mining happening in one specific region; thus
there shouldn't be too much incentive for that to happen, yet at the
time being (as you've rightly pointed out) the subsidization of
electricity there, combined with the availability of certain
environmental conditions for cooling and / or hydropower, means that
China dominates the mining realm.

Recently I took the time to ask someone associated with a new bitcoin
mining operation in China some questions about the new (apparently
developing) National Security Law of China.

According to an early draft of this National Security Law, "the State
maintains the basic economic system and order of the socialist
marketplace ... safeguarding security in important industries and
fields that influence the populace's economic livelihood ... as well
as other major economic interests."

The Chinese government is currently reviewing another national
security related law, which in its first draft would mandate ALL
Internet companies operating in China to provide backdoor access and
encryption keys to the government.  (One would imagine that would
include any exchanges and mining operations as well.)

The US FBI Director (Comey) has also, of course, made plenty of
arguments for backdoors in encryption.  But as security expert Bruce
Schneier points out, there "really is no way" to keep users' data safe
while providing backdoors. He said:

"I have two options. I can design a secure system that has no
backdoor access, meaning neither criminals nor foreign intelligence
agencies nor domestic police can get at the data. Or I can design a
system that has backdoor access, meaning they all can."
(Reference:
http://www.zdnet.com/article/because-there-is-no-such-thing-as-a-secure-
backdoor-gosh-darn-it/
)

Anyway, the response of the individual (eric@haobtc - of haobtc.com)
to my questions can be seen here:

https://bitcointalk.org/index.php?topic=1072474.msg11914077#msg11914077

His responses were provided to me before the recent "Crypto Wars"
announcements which I think will only think make things worse:

https://twitter.com/helios_unbound/status/627648646985719809

So, I try to be optimistic, but I'm leaning pessimistic right now
about the situation with the effect of the Crypto Wars combined with
the dominance of Chinese mining plus China's development of new laws
that seem to involve further attempts to backdoor hardware and / or
software.  Obviously this doesn't break bitcoin for mathematical
reasons that everyone on this list is already familiar with I'm sure,
but it is concerning to me, and now I will /endrant

On 08/02/2015 02:02 PM, Jim Phillips via bitcoin-dev wrote:
> China is a communist country. It is no secret that all
> "capitalist" enterprises are essentially State controlled, or at
> the very least are subject to nationalization should the State deem
> it necessary. Most ASIC chips are manufactured in China, so they
> are cheap and accessible to Chinese miners. Electricity is
> subsidized and essentially free. Cooling is not an issue since
> large parts of China are mountainous and naturally cool. In short
> the Chinese miners have HUGE advantages over all other mining
> operations. This is probably why, between just the top 4 Chinese 
> miners, the People's Republic of China effectively controls 57% of
> all the Bitcoin being mined.
> 
> The ONLY disadvantage the Chinese miners have in competing with the
> rest of the world is bandwidth. China has poor connectivity with
> the rest of the world, and Chinese miners have said that an
> increase in the block size would be detrimental to them. I say,
> GOOD! Most of the free world has enough bandwidth to be able to
> handle larger blocks. We need to take advantage of that fact to get
> mining out of the centralized control of the Chinese.
> 
> If you're truly worried about larger blocks causing
> centralization, think about how, by restricting blocksize, you're
> enabling the Communist Chinese government to maintain centralized
> control over 57% of the Bitcoin hashing power.
> 
> -- *James G. Phillips IV*
> 
>  /"Don't bunt. Aim out of the
> ball park. Aim for the company of immortals." 

Re: [bitcoin-dev] A compromise between BIP101 and Pieter's proposal

[odinn via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I am in favor of a more gradual (longer) period and a softforking
solution... that is, more than 30 days of grace period (some period
between 60 days and a year), ...

... and given the number of valid softforking proposals out there it
seems to me that it would be rather simple to see one or more (e.g.
Cameron Garnham's dynamic block size adjustment (needing soft fork
only)) in a BIP.

It is also worthwhile to add that some of the softforking proposals,
and I believe Garnham's to be one of them, are not incompatible with
proposals such as Jeff Garzik's BIP 100, that is to say, there is
nothing keeping you from doing the Garnham dynamic block size
adjustment (softfork) right now today, examining its progress and
effect, while also preparing for a Garzik (BIP 100) for example.

- - Odinn

On 08/02/2015 12:16 AM, jl2012 via bitcoin-dev wrote:
> Pieter Wuille 於 2015-08-01 16:45 寫到:
>> On Fri, Jul 31, 2015 at 10:39 AM, jl2012 via bitcoin-dev 
>>  wrote:
> 
>>> 2. Starting date: 30 days after 75% miner support, but not
>>> before 2016-01-12 00:00 UTC
>>> 
>>> Rationale: A 30-day grace period is given to make sure everyone
>>> has enough time to follow. This is a compromise between 14 day
>>> in BIP101 and 1 year in BIP103. I tend to agree with BIP101.
>>> Even 1 year is given, people will just do it on the 364th day
>>> if they opt to procrastinate.
>> 
>> Given the time recent softforks have taken to deploy, I think
>> that's too soon.
> 
> Since I'm using "30 days after 75% miner support", the actual
> deployment period will be longer than 30 days. Anyway, if all major
> exchanges and merchants agree to upgrade, people are forced to
> upgrade immediately or they will follow a worthless chain.
> 
> 
>> 
>>> 3. The block size at 2016-01-12 will be 1,414,213 bytes, and 
>>> multiplied by 1.414213 by every 2^23 seconds (97 days) until
>>> exactly 8MB is reached on 2017-05-11.
>>> 
>>> Rationale: Instead of jumping to 8MB, I suggest to increase it 
>>> gradually to 8MB in 16 months. 8MB should not be particularly 
>>> painful to run even with current equipment (you may see my
>>> earlier post on bitctointalk: 
>>> https://bitcointalk.org/index.php?topic=1054482.0 ). 8MB is
>>> also agreed by Chinese miners, who control >60% of the
>>> network.
>> 
>> I have considered suggesting a faster ramp-up in the beginning,
>> but I don't think there is indisputable evidence that we can
>> currently deal with significantly larger blocks. I don't think
>> "painful" is the right criterion either; I'm sure my equipment
>> can "handle" 20 MB blocks too, but with a huge impact on network
>> propagation speed, and even more people choosing the outsource
>> their full nodes.
>> 
>> Regarding "reasonable", I have a theory. What if we would have
>> had 8 MB blocks from the start? My guess is that some more people
>> would have decided to run their high-transaction-rate use cases
>> on chain, that we'd regularly see 4-6 MB blocks, there would be
>> more complaints about low full node counts, maybe 90% instead of
>> 60% of the hash rate would be have SPV mining agreements with
>> each other, we'd somehow have accepted that even worse reality,
>> but people would still be complaining about the measly 25
>> transactions per second that Bitcoin could handle on-chain, and
>> be demanding a faster rampup to a more "reasonable" 64 MB block
>> size as well.
> 
> Since the block reward is miners' major income source, no rational
> miner would create mega blocks unless the fee could cover the extra
> orphaning risk. Blocks were not constantly full until recent
> months, and many miners are still keeping the 750kB soft limit.
> This strongly suggests that we won't have 4MB blocks now even
> Satoshi set a 8MB limit.
> 
> I don't have the data now but I believe the Satoshi Dice model
> failed not primarily due to the 1MB cap, but the raise in BTC/USD
> rate. Since minting reward is a fixed value in BTC, the tx fee must
> also be valued in BTC as it is primarily for compensating the extra
> orphaning risk. As the BTC/USD rate increases, the tx fee measured
> in USD would also increase, making micro-payment (measured in USD)
> unsustainable.
> 
> We might have less full nodes, but it was Satoshi's original plan:
> "At first, most users would run network nodes, but as the network
> grows beyond a certain point, it would be left more and more to
> specialists with server farms of specialized hardware. A server
> farm would only need to have one node on the network and the rest
> of the LAN connects with that one node." Theoretically, we only
> require one honest full node to prove wrongdoing on the blockchain
> and tell every SPV nodes to blacklist the invalid chain.
> 
> I think SPV mining exists long before the 1MB block became full,
> and I don't think we could stop this trend by artificially
> suppressing the block size. Miners should just do it properly, e.g.
> stop mining until the grandparent block

Re: [bitcoin-dev] A summary of block size hardfork proposals (and a softforking one)

[odinn via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Great summary, thanks.  Helpful to get general grasp of the main
things out there.

On 07/30/2015 11:14 AM, jl2012 via bitcoin-dev wrote:
> Currently, there are 4 block size BIP by Bitcoin developers:
> 
> BIP100 by Jeff: 
> http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf 
> BIP101 by Gavin: 
> https://github.com/bitcoin/bips/blob/master/bip-0101.mediawiki 
> BIP102 by Jeff: https://github.com/bitcoin/bips/pull/173/files 
> BIP??? by Pieter (called "BIP103" below): 
> https://gist.github.com/sipa/c65665fc360ca7a176a6
> 
> To facilitate further discussion, I'd like to summarize these
> proposals by a series of questions. Please correct me if I'm wrong.
> Something like sigop limit are less controversial and are not
> shown.
> 
> Should we use a BIP34-like voting mechanism to initiate the
> hardfork? BIP100, 102, 103: No BIP101: Yes
> 
> When should we initiate the hardfork? BIP100: 2016-01-11 BIP101: 2
> weeks after 75% miner support, but not before 2016-01-11 BIP102:
> 2015-11-11 BIP103: 2017-01-01
> 
> What should be the block size at initiation? BIP100: 1MB BIP101:
> 8MB BIP102: 2MB BIP103: 1MB
> 
> Should we allow further increase / decrease? BIP100: By miner
> voting, 0.5x - 2x every 12000 blocks (~3 months) BIP101: Double
> every 2 years, with interpolations in between (41.4% p.a.) BIP102:
> No BIP103: +4.4% every 97 days (double every 4.3 years, or 17.7%
> p.a.)
> 
> The earliest date for a >=2MB block? BIP100: 2016-04-03 (assuming
> 10 minutes block) BIP101: 2016-01-11 BIP102: 2015-11-11 BIP103:
> 2020-12-27
> 
> What should be the final block size? BIP100: 32MB is the max, but
> it is possible to reduce by miner voting BIP101: 8192MB BIP102:
> 2MB BIP103: 2048MB
> 
> When should we have the final block size? BIP100: Decided by
> miners BIP101: 30 years after initiation BIP102: 2015-11-11 BIP103:
> 2063-07-09
> 
> 
> 
> ___ bitcoin-dev mailing
> list bitcoin-dev@lists.linuxfoundation.org 
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 

I'd like to add to this some remarks that are from an earlier discussion

Cameron Garnham added into a thread, at
http://bitcoin-development.narkive.com/iHmMh6bZ/bitcoin-development-prop
osed-alternatives-to-the-20mb-step-function#post65
"First off, I am glad that the idea of dynamic block size adjustment is
gaining some attention, in particular the model that I proposed.

I wanted to take some time and explain some of the philosophy of how,
and why, I proposed this this particular model.

When Bitcoin was first made, there was a 32MB block size limit; this
was quickly found to be open to spam (and potentially DOS, as the code
was not-at-all optimized to support large blocks), and was reduced to
1MB, this was a quick fix that was never intended to last; at some
point the network should come to an understanding, a consensus if you
will, of what (and how much) belongs in a block.
The core point of this is that miners have always, and will always;
hold the power, to decide what goes into blocks; this implicitly,
obviously, includes how large blocks are. Miners are able to come any
sort of agreement they wish, providing the bitcoin clients accept
their blocks as valid."
(...)
"the proposal introducing a consensus protocol for block sizes;
instead of just having a hard limit (enforced by everyone), instead,
we have a constant factor above the average block size over a fixed
intervals that is soft-forked by only the miners. (The next simplest
mathematical construct).
This proposal is entirely a soft-fork and may be implemented without
changing any client code what so ever. In-fact, it could be
implemented by only a simple 51% majority of miners, with-or-without
gaining the wider community consensus."


- -- 
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJVuonLAAoJEGxwq/inSG8CensH/29IwToehXVgEA44RZmUsIdn
5d2OCGZHOsinJKS9Uqtd5SfIDycXVVTV832KrxIUH1oC685iwVzBuA4hJQc2Z49A
hNKs97N97iS2s3W6X/llbYz/3i3H6TQaCJGfK+XurFi6pxdC+4LgoUovtGaIsc8x
z7iTD5F7FEhPmKU6uxw9GRRvKHJwyy0xWWNgBAJjdS7F5y7DR1VC9RhPehpU75Wt
MGHrrogM41r+cNVDpNpnT42q0rAKC0IXjvY43ZoA/EFUoWkpaXI6jwKXtjqDjCP7
P8StjQ7eoeIkZWu1PwbfKStbF4Ob3Q7Xi+hQxCwciKdtfsLRFkdamzvpl/qh9wg=
=Itr1
-END PGP SIGNATURE-
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Răspuns: Personal opinion on the fee market from a worried local trader

[odinn via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Some additional points

On 07/29/2015 03:54 PM, s7r via bitcoin-dev wrote:
> (...)
> 
> The more people use bitcoin, the more demand we have on the market
> for BTC, the higher BTC/FIAT rate will be, more people will become 
> interested in mining and so on. Bitcoin is not a
> rich-only-private-club, it's an open, global, decentralized payment
> network. The less people use it... I guess you figured it out.

Yes.

(...) Having some
> offchain solution for small transactions would be a good idea, but
> this doesn't mean we should make small transactions impossible due
> to absurd fees.

This is correct also.

> 
> On 7/29/2015 8:47 PM, Raystonn . via bitcoin-dev wrote:
>>> When a category of users would get priced out because of the
>>> fee
>> market, they would be free to use any altcoin they want.
>> 
>> I believe that pretty well sums up where we’re headed if
>> transaction rate is artificially limited, whether that be by
>> maximum block size limit or something else.  A fee market will
>> necessarily include more than just Bitcoin.  The reality is it’s
>> very easy to trade value across different blockchains, and thus a
>> fee market will bleed value from Bitcoin and give it to
>> alternative blockchains.  If Bitcoin’s blocks are at maximum
>> capacity, people will exchange for something that allows them to
>> transact with a lesser fee, then make the desired payment.  This
>> adds value to the alternative blockchain and removes it from
>> Bitcoin.
>> 
>> Anyone thinking the fee market can be restrained to Bitcoin alone
>> is mistaken.
>> 
>> 
>> *From:* Vali Zero via bitcoin-dev 
>>  *Sent:* Wednesday,
>> July 29, 2015 7:09 AM *To:*
>> bitcoin-dev@lists.linuxfoundation.org 
>>  *Subject:*
>> [bitcoin-dev] Răspuns: Personal opinion on the fee market from a
>> worried local trader
>> 
>> I am disappointed that you did not understand my point of view.
>> Let me rephrase it for you,
>> 
>> People tipping, buying 0.99$ products and gamblers that need
>> Bitcoin transactions *more* than the rest of the people will
>> afford the fees that establish the equilibrium between demand and
>> supply of Bitcoin transactions. The people are free to use they
>> money for whatever they like, but you should understand that
>> Bitcoin transactions are not free.
>> 
>> I was merely attempting to point out that spammers and gamblers
>> would be the first ones that would go away. They would be free to
>> spam or gamble, but they would have to pay for it.
>> 
>> When a category of users would get priced out because of the fee
>> market, they would be free to use any altcoin they want.
>> 
>> Please understand that not everyone will leave. The more
>> important players will remain, those that need it the most. The
>> other players are free to use whatever altcoin they wish.
>> 
>> 
>> În Miercuri, 29 Iulie 2015 16:47:57, Angel Leon
>>  a scris:
>> 
>> 
>> "the gamblers and perhaps people transacting very low amounts.
>> The people that actually need Bitcoin would remain."
>> 
>> so people tipping, buying $0.99 products, and gamblers actually
>> don't need Bitcoin. Who are you to say what people need to use
>> money for? This statement goes against the freedom of
>> decentralization and financial freedom Bitcoin should be able to
>> provide.
>> 
>> It's an open network and it will be used as most users see fit,
>> and that requires a blocksize increase wether you like it or not,
>> it's simple physics, other time wait times will become unbearable
>> for those not willing to pay the high fees, if people leave, then
>> it only mean bitcoins isn't useful, and if bitcoin isn't useful,
>> it's worthless.
>> 
>> 
>> 
>> http://twitter.com/gubatron
>> 
>> On Wed, Jul 29, 2015 at 9:27 AM, Vali Zero via bitcoin-dev 
>> > > wrote:
>> 
>> Hello,
>> 
>> I have been reading an argument saying that paying higher fees
>> would scare Bitcoin users and they would stop using it,
>> preferring bank transfers or other payment methods. This does not
>> make sense for me. If some users leave, then demand for bitcoin
>> transactions goes down and so do the fees. The others remain.
>> 
>> Fee market means that an equilibrium is found between the demand
>> for bitcoin transactions and the available supply (given by the
>> block size). The fee is the price that finds this equilibrium.
>> 
>> If a fee market starts to exist, the first ones to leave are the 
>> spammers, probably followed by the gamblers and perhaps people 
>> transacting very low amounts. The people that actually need
>> Bitcoin would remain.
>> 
>> Please allow this fee market to form...
>> 
>> In the absence of a functioning fee market, I will refuse to run 
>> Bitcoin code that increases the block size and will do my best
>> to tell everyone I know not to upgrade towards running such code.
>> If Bit

Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn'ttemporary

[odinn via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I will jump in just because I feel like it because the questions are
fun and so on.  (Of course I am not Gregory)

On 07/29/2015 02:28 PM, Raystonn . via bitcoin-dev wrote:
> Gregory, can you please speak to the following points.  I would
> like a better understanding of your positions.
> 

Note that I am not Gregory, so with that caveat...

> 1) Do you believe that Bitcoin's future is as a high-value
> settlement network?

No, it will have multiple and diverse purposes into which it can be
used for and can evolve, it would not be sufficient to state that it
has "a future" merely as a high-value settlement network.

> 
> 2) Do you believe we need an artificial limit to transaction rate, 
> perhaps implemented as a maximum block size limit?  If so, why?

If you have a proposal on this, please submit it in the formal way as
a BIP draft.   Enough time has been burnt on the subject, imho.

> 
> 3) Transaction fees will fluctuate with global economic conditions
> and technology.  Those free-market fluctuations should equally
> affect any blockchain.  However, if transaction fees on the Bitcoin
> network are pushed artificially high, such as with an artificial
> limit to transaction rate only applicable to Bitcoin, this will
> create a condition where some other blockchains will have lower
> fees.  How do you plan to address the bleeding of value from
> Bitcoin to alternative lower-fee blockchains created by the
> artificially-high bitcoin transaction fees when users begin looking
> for the cheapest way to send value?  Modern economic study has
> shown that liquidity moves to the location of least friction.

It is the market.  What will happen will happen.  If bitcoin
development pushes fees upward as an overall trend and the overall
cost to transact continues to increase, billions of people around the
world will as a result be forced out from most use cases of bitcoin
and the "bleeding out" will occur naturally to alts (to the extent
that persons already possessed bitcoin first and need to transact).
As stated above, liquidity moves to location of least friction.
Bitcoin bagholders can whine all they want, but value will distribute
into the alts gradually.

> 
> 4) If you believe it's not a problem to allow alternative
> blockchains to leech some of Bitcoin's value,

"allow" is not a relevant term here, as it is not up to anyone what
people are going to do with their crypto of any kind.  Unless, of
course, you are fool enough to be using Coinbase and Bitpay or
something like that.  They own "your" coin, and they will decide, or
allow, what you do with it or whether you can even access it.
As has been stated before here, I hope you are not using such services.
On the other hand, the following are very interesting:
https://gear.mycelium.com/ - a Payment processor
http://openbazaar.org a decentralized Market
https://bitsquare.io/ a decentralized Exchange
https://electrum.org/ a light wallet that you manage

 then:
> a) How much value is it acceptable to lose?

Irrelevant.  Better question is, How much should one give? The more
you can give, the better off you will be.

> b) How do you think this will affect Bitcoin miners, whose large 
> investments in hardware do not transfer to other blockchains?

Too much attention is paid to the miners.  Miners should not be
butthurt when people say that we should not put them up on a pedestal.
 Think ahead, to when there will no longer be bitcoin mining such as
there is today.

> c) How do you think this will affect the investors and holders of 
> bitcoin in general?

People will continue to buy and sell.  Some major changes are in
store, however.  If you would like, see my reflections on what the
months ahead will hold, here:
http://www.twitlonger.com/show/n_1sn3lqs

> 
> 
> -Original Message- From: Gregory Maxwell via bitcoin-dev 
> Sent: Wednesday, July 29, 2015 1:09 PM To: Owen Cc: Bitcoin Dev 
> Subject: Re: [bitcoin-dev] Why Satoshi's temporary anti-spam
> measure isn'ttemporary
> 
> On Wed, Jul 29, 2015 at 7:56 PM, Owen via bitcoin-dev 
>  wrote:
>> On July 29, 2015 7:15:49 AM EDT, Mike Hearn via bitcoin-dev:
>>> Consider this:  the highest Bitcoin tx fees can possibly go is
>>> perhaps a little higher than what our competition charges. Too
>>> much higher than that, and people will just say, you know what
>>>  I'll make a bank transfer. It's cheaper and not much
>>> slower, sometimes no slower at all.
>> 
>> I respectfully disagree with this analysis. The implication is
>> that bitcoin is merely one of a number of payment technologies.
>> It's much more than that. It's sound money, censorship
>> resistance, personal control over money, programmable money, and
>> more. Without these attributes it's merely a really inefficient
>> way to do payments.
>> 
>> Given these advantages, there is no reason to believe the
>> marginal cost of a transaction can't far surpass that of a PayPal
>> or bank transfer. I personal

Re: [bitcoin-dev] For discussion: limit transaction size to mitigate CVE-2013-2292

[odinn via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Interesting, so this basically would merge into an already existing
BIP (Jeff Garzik's).  However, it proposes some changes.

OK

CVE-2013-2292 is a severity thingy of "high" which is described as

"bitcoind and Bitcoin-Qt 0.8.0 and earlier allow remote attackers to
cause a denial of service (electricity consumption) by mining a block
to create a nonstandard Bitcoin transaction containing multiple
OP_CHECKSIG script opcodes."

(munches popcorn)

I do appreciate seeing the effort toward working something toward /
into Garzik's proposal.  The general idea that I suggested before - to
work some new ideas (not XT-related), into a BIP, and to work with
Jeff Garzik on getting something done, seems to be the direction that
you are taking... so I'm hopeful that continues.

- -O

On 07/24/2015 01:59 PM, Gavin Andresen via bitcoin-dev wrote:
> After thinking about it, implementing it, and doing some
> benchmarking, I'm convinced replacing the existing, messy, ad-hoc
> sigop-counting consensus rules is the right thing to do.
> 
> The last two commits in this branch are an implementation: 
> https://github.com/gavinandresen/bitcoin-git/commits/count_hash_size
>
>  From the commit message in the last commit:
> 
> Summary of old rules / new rules:
> 
> Old rules: 20,000 inaccurately-counted-sigops for a 1MB block New:
> 80,000 accurately-counted sigops for an 8MB block
> 
> A scan of the last 100,000 blocks for high-sigop blocks gets a
> maximum of 7,350 sigops in block 364,773 (in a single, huge, ~1MB
> transaction).
> 
> For reference, Pieter Wuille's libsecp256k1 validation code 
> validates about 10,000 signatures per second on a single 2.7GHZ CPU
> core.
> 
> Old rules: no limit for number of bytes hashed to generate 
> signature hashes
> 
> New rule: 1.3gigabytes hashed per 8MB block to generate signature
> hashes
> 
> Block 364,422 contains a single ~1MB transaction that requires 
> 1.2GB of data hashed to generate signature hashes.
> 
> TODO: benchmark Core's sighash-creation code ('openssl speed
> sha256' reports something like 1GB per second on my machine).
> 
> Note that in normal operation most validation work is done as 
> transactions are received from the network, and can be cached so
> it doesn't have to be repeated when a new block is found. The
> limits described in this BIP are intended, as the existing sigop
> limits are intended, to be an extra "belt and suspenders" measure
> to mitigate any possible attack that involves creating and
> broadcasting a very expensive-to-verify block.
> 
> 
> Draft BIP:
> 
> BIP: ?? Title: Consensus rules to limit CPU time required to
> validate blocks Author: Gavin Andresen  > Status: Draft Type: Standards
> Track Created: 2015-07-24
> 
> ==Abstract==
> 
> Mitigate potential CPU exhaustion denial-of-service attacks by
> limiting the maximum number of ECDSA signature verfications done
> per block, and limiting the number of bytes hashed to compute
> signature hashes.
> 
> ==Motivation==
> 
> Sergio Demian Lerner reported that a maliciously constructed block
> could take several minutes to validate, due to the way signature
> hashes are computed for OP_CHECKSIG/OP_CHECKMULTISIG 
> ([[https://bitcointalk.org/?topic=140078|CVE-2013-2292]]). Each
> signature validation can require hashing most of the transaction's 
> bytes, resulting in O(s*b) scaling (where s is the number of
> signature operations and b is the number of bytes in the
> transaction, excluding signatures). If there are no limits on s or
> b the result is O(n^2) scaling (where n is a multiple of the number
> of bytes in the block).
> 
> This potential attack was mitigated by changing the default relay
> and mining policies so transactions larger than 100,000 bytes were
> not relayed across the network or included in blocks. However, a
> miner not following the default policy could choose to include a 
> transaction that filled the entire one-megaybte block and took a
> long time to validate.
> 
> ==Specification==
> 
> After deployment, the existing consensus rule for maximum number
> of signature operations per block (20,000, counted in two
> different, idiosyncratic, ad-hoc ways) shall be replaced by the
> following two rules:
> 
> 1. The maximum number of ECDSA verify operations required to
> validate all of the transactions in a block must be less than or
> equal to the maximum block size in bytes divided by 100 (rounded
> down).
> 
> 2. The maximum number of bytes hashed to compute ECDSA signatures
> for all transactions in a block must be less than or equal to the 
> maximum block size in bytes times 160.
> 
> ==Compatibility==
> 
> This change is compatible with existing transaction-creation
> software, because transactions larger than 100,000 bytes have been
> considered "non-standard" (they are not relayed or mined by
> default) for years, and a block full of "standard" transactions
> will be well-under the limits.
> 
> S

Re: [bitcoin-dev] Do we really need a mempool? (for relay nodes)

[odinn via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Some brief thoughts, adding here a suggestion for a dynamic approach
to the issue. (e.g. each additional tx relayed has some thing
associated with it, that is, a "doubling" for each additional tx
relayed that spends a given UTXO, doesn't sound like it would be the
most dynamic approach to the issue; considering that full nodes use
the (UTXOs) to establish if transactions are valid – all inputs to a
transaction must be in the UTXO database for it to be valid, but
rather, would end up ratcheting upward the fee/kB for each additional
tx relayed, as proposed).

A more dynamic fee approach would be a better one, imho, but how is
this to occur?

Quoting from Gavin Andresen's http://gavinandresen.ninja/utxo-uhoh,
"The entire UTXO set doesn’t have to be in RAM; it can be stored on an
SSD or spinning hard disk. The access pattern to the UTXO is not
random; outputs that were spent recently are more likely to be
re-spent than outputs that have not been spent in a long time. Bitcoin
Core already has a multi-level UTXO cache, thanks to the hard work of
Pieter Wuille."

The relay nodes would, in this scenario that is proposed here in this
message, be confirming and discarding; the wallet nodes, if I
understand properly, in this scenario, as proposed, should be
retaining (keeping a record of the transactions they've relayed and
using a mempool).

There are some questions here:

- - How is the mempool to be limited?
- - What is the mechanism by which the UTXO set is stored (or proposed
to be stored)?
- - How would dynamic fee determinations be calculated?
- - Please describe more the general purpose messaging network?

Thank you



On 07/18/2015 12:46 PM, Patrick Strateman via bitcoin-dev wrote:
> Relay nodes do not need a mempool, but do need some mechanism to
> avoid DoS issues.
> 
> Wallet nodes can use the mempool for fee estimation (in addition
> to looking at past blocks).
> 
> On 07/18/2015 11:52 AM, Peter Todd via bitcoin-dev wrote:
>> As in, do relay nodes need to keep a record of the transactions
>> they've relayed? Strictly speaking, the answer is no: one a tx is
>> relayed modulo DoS concerns the entire thing can be discarded by
>> the node. (unconfirmed txs spending other unconfirmed txs can be
>> handled by creating packages of transactions, evaluated as a
>> whole)
>> 
>> To mitigate DoS concerns, we of course have to have some per-UTXO
>> limit on bandwidth relayed, but that task can be accomplished by
>> simply maintaining some kind of per-UTXO record of bandwidth
>> used. For instance if the weighted fee and fee/KB were recorded,
>> and forced to - say - double for each additional tx relayed that
>> spent a given UTXO you would have a clear and simple upper limit
>> of lifetime bandwidth. Equally it's easy to limit bandwidth
>> moment to moment by asking peers for highest fee/KB transactions
>> they advertise first, stopping when our bandwidth limit is
>> reached.
>> 
>> You probably could even remove IsStandard() pretty much entirely
>> with the right increasingly expensive "replacement" policy,
>> relying on it alone to provide anti-DoS. Obviously this would
>> simplify some of the debates around mining policy! This could
>> even be re-used for scalable a general-purpose messaging network
>> paid by coin ownership if the UTXO set is split up, and some kind
>> of expiration over time policy is implemented.
>> 
>> Miners of course would still want to have a mempool, but that
>> codebase may prove simpler if it doesn't have to work double-duty
>> for relaying as well.
>> 
>> 
>> 
>> ___ 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
> 

- -- 
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJVq2cFAAoJEGxwq/inSG8CIo4IAJAZ97NvW6Qdjd6HLN8q2074
sEUGdDeonARiQZXLfGyTJVg43Yb6LKPqkjWPQEgl9LLNni8t99iUqu3BJxedRDjd
8x+/F8n5VJrUrn1pXUcbC1aWss1y8JPTO2KpF/WL254IFc8iE8MJf4YF8PDSgy5j
9uW8NvWvdT4dz+rXu9vqfcplz8x7NGQ+CWN2N2JlChhKLMFprXPIx8a7NQwaKdrY
lTpgAJWGMyPGNCmYQprBjIjOfp8tdTLQFlsLUAsXDmEisJX9goRVGMsHOWLTREoA
l3kTgM0WMv6MIG7NOQQcWLD7cZdwWYR9e49hc27VcHt2R/FTepvnwPqo2GtE0tM=
=eRbR
-END PGP SIGNATURE-
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Significant losses by double-spending unconfirmed transactions

[odinn via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Personally, I hope more people develop on-chain microtransaction
systems (so long as open source, etc) ~ see
http://dev.blockcypher.com/#microtransaction-api ~ and I hope the
bitcoin community figures out ways to re-examine dust, rather than
viewing it as a "problem," but instead, to re-examine this and
interpret it as an "opportunity" for microgiving. (I won't claim there
aren't challenges there, but I'll just throw that out there again..)

- - Please see, my little project, http://abis.io

On 07/15/2015 05:08 PM, Matthieu Riou via bitcoin-dev wrote:
> On Wed, Jul 15, 2015 at 12:32 PM, Peter Todd  > wrote:
> 
> 
> "In a Sybil attack the attacker subverts the reputation system of
> a peer-to-peer network by creating a large number of pseudonymous 
> identities, using them to gain a disproportionately large
> influence."
> 
> 
> Our "identities" aren't pseudonymous.
> 
> In the case of Bitcoin, there's something like 6,000 nodes, so if
> that 20% is achived via outgoing connections you'd have 600 to 1200
> active outgoing connections using up network resources.  Meanwhile,
> the default is 8 outgoing connections - you're using about two
> orders of magnitude more resources.
> 
> 
> You're not talking about a Sybil attack anymore, just resource use.
> We do know how to change default configurations to offer more
> connections.
> 
> If you are achieving that via incoming connections, you're placing
> a big part of the relay network under central control. As we've
> seen in the case of Chainalysis's sybil attack, even unintentional
> confirguation screwups can cause serious and widespread issues due
> to the large number of nodes that can fail in one go. (note how
> Chainalysis's actions were described(1) as a sybil attack by
> multiple Bitcoin devs, including Gregory Maxwell, Wladimir van der
> Laan, and myself)
> 
> 
> We're not Chainanalysis and we do not run hundreds of distinct
> nodes. Just a few well-tuned ones.
> 
> 
> What you are doing is inherently incompatible with
> decentralization.
> 
> 
> That's a matter of opinion. One could argue your actions and
> control attempts hurt decentralization. Either way, no one should
> play the decentralization police or act as a gatekeeper.
> 
> Question: Do you have relationships with mining pools? For
> instance, are you looking at contracts to have transactions mined
> to guarantee confirmations?
> 
> 
> No, we do not. We do not know anyone else having such contracts. As
> you know, Coinbase also denied having such contracts in place [1].
> But you seem to have more relationships with mining pools than we
> do.
> 
> Thanks, Matthieu CTO and Founder, BlockCypher
> 
> [1]
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/00886
4.html
>
> 
> 
> ___ bitcoin-dev mailing
> list bitcoin-dev@lists.linuxfoundation.org 
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 

- -- 
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJVpz6hAAoJEGxwq/inSG8CdAMIAJfJcJaXyFjUVLi6iA03tpot
8e0SONC+kadLRTUn8GzAlpSgvKLcfqO5WvNKsjJenckrP+B6oSlT2e2u0QGehxl4
gGfTksOPzrBFCfWOZnVAaDr4uR7OAHM/AjXkpn1gQJsh+xBhyeUF1xapPeR/M+9e
yXFtV0itZve93sKrtlo+J/VShEi9mPBYrFrJBK9o17ir5chXW/xzqGm1Ny3fS72U
/g9zkdt+LBidaLXdPvfBjjmux18BM+IAifO41C9Q0eIN6x0zajvPd/Y3Mm5J/QUe
p8qvj2Px75AYSCV0qzgMhETZdwYFor04f2zJ8u3WUB+AbupM9hewqvfPGiUi1qU=
=S/aI
-END PGP SIGNATURE-
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core 0.11.0 released

[odinn via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

The numbering of the version, though. 

On 07/12/2015 08:49 AM, Wladimir J. van der Laan wrote:
> Bitcoin Core version 0.11.0 is now available from:
> 
> 
> 
> This is a new major version release, bringing both new features
> and bug fixes.
> 
> Please report bugs using the issue tracker at github:
> 
> 
> 
> The entire distribution is also available as torrent:
> 
> magnet:?xt=urn:btih:82f0d2fa100d6db8a8c1338768dcb9e4e524da13&dn=bitcoi
n-core-0.11.0&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80%2Fannounce&
tr=udp%3A%2F%2Ftracker.publicbt.com%3A80%2Fannounce&tr=udp%3A%2F%2Ftrack
er.ccc.de%3A80%2Fannounce&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969&
tr=udp%3A%2F%2Fopen.demonii.com%3A1337&ws=https%3A%2F%2Fbitcoin.org%2Fbi
n%2F
>
>  Upgrading and downgrading =
> 
> How to Upgrade --
> 
> If you are running an older version, shut it down. Wait until it
> has completely shut down (which might take a few minutes for older
> versions), then run the installer (on Windows) or just copy over
> /Applications/Bitcoin-Qt (on Mac) or bitcoind/bitcoin-qt (on
> Linux).
> 
> Downgrade warning --
> 
> Because release 0.10.0 and later makes use of headers-first
> synchronization and parallel block download (see further), the
> block files and databases are not backwards-compatible with
> pre-0.10 versions of Bitcoin Core or other software:
> 
> * Blocks will be stored on disk out of order (in the order they
> are received, really), which makes it incompatible with some tools
> or other programs. Reindexing using earlier versions will also not
> work anymore as a result of this.
> 
> * The block index database will now hold headers for which no block
> is stored on disk, which earlier versions won't support.
> 
> If you want to be able to downgrade smoothly, make a backup of your
> entire data directory. Without this your node will need start
> syncing (or importing from bootstrap.dat) anew afterwards. It is
> possible that the data from a completely synchronised 0.10 node may
> be usable in older versions as-is, but this is not supported and
> may break as soon as the older version attempts to reindex.
> 
> This does not affect wallet forward or backward compatibility.
> There are no known problems when downgrading from 0.11.x to
> 0.10.x.
> 
> Important information ==
> 
> Transaction flooding -
> 
> At the time of this release, the P2P network is being flooded with
> low-fee transactions. This causes a ballooning of the mempool
> size.
> 
> If this growth of the mempool causes problematic memory use on your
> node, it is possible to change a few configuration options to work
> around this. The growth of the mempool can be monitored with the
> RPC command `getmempoolinfo`.
> 
> One is to increase the minimum transaction relay fee
> `minrelaytxfee`, which defaults to 0.1. This will cause
> transactions with fewer BTC/kB fee to be rejected, and thus fewer
> transactions entering the mempool.
> 
> The other is to restrict the relaying of free transactions with 
> `limitfreerelay`. This option sets the number of kB/minute at
> which free transactions (with enough priority) will be accepted. It
> defaults to 15. Reducing this number reduces the speed at which the
> mempool can grow due to free transactions.
> 
> For example, add the following to `bitcoin.conf`:
> 
> minrelaytxfee=0.5 limitfreerelay=5
> 
> More robust solutions are being worked on for a follow-up release.
> 
> Notable changes ===
> 
> Block file pruning --
> 
> This release supports running a fully validating node without
> maintaining a copy of the raw block and undo data on disk. To
> recap, there are four types of data related to the blockchain in
> the bitcoin system: the raw blocks as received over the network
> (blk???.dat), the undo data (rev???.dat), the block index and the 
> UTXO set (both LevelDB databases). The databases are built from the
> raw data.
> 
> Block pruning allows Bitcoin Core to delete the raw block and undo
> data once it's been validated and used to build the databases. At
> that point, the raw data is used only to relay blocks to other
> nodes, to handle reorganizations, to look up old transactions (if
> -txindex is enabled or via the RPC/REST interfaces), or for
> rescanning the wallet. The block index continues to hold the
> metadata about all blocks in the blockchain.
> 
> The user specifies how much space to allot for block & undo files.
> The minimum allowed is 550MB. Note that this is in addition to
> whatever is required for the block index and UTXO databases. The
> minimum was chosen so that Bitcoin Core will be able to maintain at
> least 288 blocks on disk (two days worth of blocks at 10 minutes
> per block). In rare instances it is possible that the amount o