odinn [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2014-10-20 to 2015-10-15
💬 Posted a total of 88 messages
📚 Participated in the following categories: Bitcoin-development, bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub1xv3g4rkhj7eyape0cqjhc9g4ljdu5axqkgcdewma854a8r7e0mtsl5j2ga

Profile Code

nprofile1qqsrxg523mte0vjwsuhuqftuz52lex72wnqtyvxuhd7n627n3lvha4cprpmhxue69uhhyetvv9ujumn0wdmksetjv5hxxmmdqyt8wumn8ghj7un9d3shjtnwdaehgu3wvfskueqywkvwf

Publishing to

relay.noswhere.com

relay.nostr.band

Author Public Key

npub1xv3g4rkhj7eyape0cqjhc9g4ljdu5axqkgcdewma854a8r7e0mtsl5j2ga

Show more details

Last Notes

2023-06-07 17:43:36

- reply

📅 Original date posted:2015-10-15
📝 Original message:-----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 at 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+0CQRXHUwJpK07IzFm5CwzSGIwri/VWT+1t/27Lk1Kt9iV4+zxOZhO
RFyo4gmJ6GApZ7N6wlIWD9R2hFdg9Q+taZHgRXiMDMqi8MOJjf5tMAXnYjbMQrSr
ntLY3ESFF0yF3ZGIIptNI4atv6UdhL2po7p+F5GMa7VZp7/e3zw96Uxmd2wkZN0R
3G5VHR2gscn3PooykpH/nhpH4mk0eFsWomuwWXAxfo2JjMhuyIXU0KnUs7ibpfPT
qtOmBW/7DI//IeRJpstAnbc22g6YOqCKrMDgNe0HgVjnmugNpY1/wRh29m+WCpA=
=felI
-----END PGP SIGNATURE-----

2023-06-07 17:43:35

- reply

📅 Original date posted:2015-10-14
📝 Original message:-----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 at 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-----

2023-06-07 17:43:33

- reply

📅 Original date posted:2015-10-15
📝 Original message:-----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
> <odinn.cyberguerrilla at riseup.net> 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
>>>> <bitcoin-dev at lists.linuxfoundation.org> 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 here.
>>>>>>>
>>>>>>> - egs
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Oct 14, 2015 at 2:20 PM, Bob McElrath
>>>>>>> <bob at mcelrath.org> 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 at 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!
>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> bitcoin-dev mailing list
>>>>>>>>> bitcoin-dev at lists.linuxfoundation.org
>>>>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>
>>>>>>>>>
!DSPAM:561e98cd301391127216946!
>>>>>>>>
>>>>>>>> -- Cheers, Bob McElrath
>>>>>>>>
>>>>>>>> "For every complex problem, there is a solution that
>>>>>>>> is simple, neat, and wrong." -- H. L. Mencken
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> bitcoin-dev mailing list
>>>>>>> bitcoin-dev at lists.linuxfoundation.org
>>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>>>>
>>>>
>>>>>>>
>>>>>
>>>>>>>
_______________________________________________ bitcoin-dev
>>>>> mailing list bitcoin-dev at 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-----
iQEcBAEBCgAGBQJWH/PfAAoJEGxwq/inSG8COLkH/3k/ZlUT2yWNYYmlN8SeU9HW
OqGW2akcHI1ObkUxW6Ljy9JCX2z34Py5c7BnpvBkiDRtAGC7bFpH1nHL5prCCxKS
Q2tjZIuu5stWkyz55fOKZ64SVASitOK7+eGhfmN+L04L+bc9BJU/ifQlU+eTH+35
cftjEFHuDClhy+P7zLPklBr62SZezPnr2kHxyV4pyGY132nKsYuB4gHAU6eI+ZeY
dFBliXXbHrQMGWH414pXz3WzpA20CNUYWpV4iJydJmU9EEM4UOaQ7YjIXBubbu6z
hDa0PYXiwvuM4VAnL7z29Q2FHbFMKmVPH01NffI6uhvpGMVZQ2cqwvhXhOS3aL8=
=4AiZ
-----END PGP SIGNATURE-----

2023-06-07 17:43:31

- reply

📅 Original date posted:2015-10-15
📝 Original message:-----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
> <bitcoin-dev at lists.linuxfoundation.org> 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 here.
>>>>
>>>> - egs
>>>>
>>>>
>>>>
>>>> On Wed, Oct 14, 2015 at 2:20 PM, Bob McElrath
>>>> <bob at mcelrath.org> 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 at 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!
>>>>>
>>>>>> _______________________________________________
>>>>>> bitcoin-dev mailing list
>>>>>> bitcoin-dev at lists.linuxfoundation.org
>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>>>
>>>>>>
>>>>>>
>>>>>>
!DSPAM:561e98cd301391127216946!
>>>>>
>>>>> -- Cheers, Bob McElrath
>>>>>
>>>>> "For every complex problem, there is a solution that is
>>>>> simple, neat, and wrong." -- H. L. Mencken
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________ bitcoin-dev
>>>> mailing list bitcoin-dev at lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>
>
>>>>
>> _______________________________________________ bitcoin-dev
>> mailing list bitcoin-dev at 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-----
iQEcBAEBCgAGBQJWH2hSAAoJEGxwq/inSG8CztwH/3kaBDCpci0WMjw9gEUybI+R
320i/cbPHHFO0eEJgWOK0mpYXYiEyoZULRjvHBjTNTS7wUVNmKsnmZDx1n9X9OCS
hQc9yoSZejoulA0f/Sys++N5ku9KPYN9EFnHpmgTtV7OW7aD8L66PCtiAOhNy7WD
T75eXjQvhWCCId1C3lvIzB6X1qTdK1gGMjNHzv49FP6RJDXa7RB7ceKrHwrXQ8J/
kbQvwOjfmGbfDZb0tSvlNKT05s4CWW6TzsUdkg5QfMs16r6b1TAz55LLj7bonTNG
muFhywfBo0oLG0NbTTQTW0pmq9TF8iy8HV/4Z48Yu8bwrZ7UA1+Q7ghV3AFPHyE=
=x4Ek
-----END PGP SIGNATURE-----

2023-06-07 17:43:30

- reply

📅 Original date posted:2015-10-14
📝 Original message:-----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 predened 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 <bob at mcelrath.org>
> 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 at 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!
>>
>>> _______________________________________________ bitcoin-dev
>>> mailing list bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>>
>>> !DSPAM:561e98cd301391127216946!
>>
>> -- Cheers, Bob McElrath
>>
>> "For every complex problem, there is a solution that is simple,
>> neat, and wrong." -- H. L. Mencken
>>
>>
>
>
>
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev at 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-----
iQEcBAEBCgAGBQJWHtVfAAoJEGxwq/inSG8C85kH/2T07oj/JM+bQcgy2kw9rtUa
XHkMNn86kVvtaniSKQ2j+SO9q8HkUI9Rv0Pz+qbX1CyAm6Z1FTCtDKornCnxx7FW
AJyZQSm5n40LUBIc3o2NBJvXKySTO2jpxluw0HAU8BQHSgFWwj1+vocqObDYxRCd
YDlhGd2ITmF55TlR+9seWqRyW+gABUoS+SaxM2yZaqWFlUGyOhYCJYpIo1nfWCZi
1F7/j0E92zu5kS5JJuRE91A4Si0LeTQPtPqXMeVm/UicdQB1a/aI0mzp6VRdm3Bo
gE79r1sKFFgpbQcz68OzPAL3RFTm1Q/C5jcqdy6cQjgp9em/v4uOCS3TKLWlVNQ=
=Einy
-----END PGP SIGNATURE-----

2023-06-07 17:43:18

- reply

📅 Original date posted:2015-10-14
📝 Original message:-----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-xt at 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" <tomz at freedommail.ch>
> 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.00003 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+unsubscribe at googlegroups.com. For more options, visit
>> https://groups.google.com/d/optout.
>>
>
>
>
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev at 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-----

2023-06-07 17:43:17

- reply

📅 Original date posted:2015-10-13
📝 Original message:-----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
> <odinn.cyberguerrilla at riseup.net> 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-----

2023-06-07 17:43:15

- reply

📅 Original date posted:2015-10-13
📝 Original message:-----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.
>
> XXXX at 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 [###] [XXXX] 20 0 1402M 317M 49836 S 1.0 8.2
> 0:41.71 ./bitcoind -daemon
>
> XXXX at prime:~/bin$ ./bitcoin-cli getmempoolinfo { "size" : 1072,
> "bytes" : 670000 }
>
> 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 [###] [XXXX] 20 0 4961M 3540M 11080 S 2.8 45.3
> 8h20:11 bin/bitcoind -daemon
>
> XXXX at feather:~$ bin/bitcoin-cli getmempoolinfo { "size" : 3045,
> "bytes" : 39656126 }
>
> 39 MB mempool, 3540 MB total memory usage. After restarting
> bitcoind, I see:
>
> [XXXX]@feather:~$ bin/bitcoin-cli stop Bitcoin server stopping
> [XXXX]@feather:~$ bin/bitcoind -daemon Bitcoin server starting
> [XXXX]@feather:~$ sleep 10; bin/bitcoin-cli getmempoolinfo { "size"
> : 39, "bytes" : 47037 }
>
>
> PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+
> Command [###] [XXXX] 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.00003 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 at 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-----

2023-06-07 17:42:35

- reply

📅 Original date posted:2015-10-05
📝 Original message:-----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-----

2023-06-07 17:42:33

- reply

📅 Original date posted:2015-10-04
📝 Original message:-----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"
>>> <bitcoin-dev at lists.linuxfoundation.org
>>> <mailto:bitcoin-dev at 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 at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
>
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev at 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-----

2023-06-07 17:42:32

- reply

📅 Original date posted:2015-10-04
📝 Original message:-----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"
>> <bitcoin-dev at lists.linuxfoundation.org
>> <mailto:bitcoin-dev at 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 at 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-----

2023-06-07 17:42:09

- reply

📅 Original date posted:2015-10-01
📝 Original message:-----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 at 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-----

2023-06-07 17:41:37

- reply

📅 Original date posted:2015-09-29
📝 Original message:-----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 at 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-----

2023-06-07 17:41:30

- reply

📅 Original date posted:2015-09-28
📝 Original message:-----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
> <bitcoin-dev at lists.linuxfoundation.org> 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 at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev at 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-----

2023-06-07 17:39:16

- reply

📅 Original date posted:2015-09-03
📝 Original message:-----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 <jgarzik at gmail.com>
> 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 at 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-----

2023-06-07 17:38:49

- reply

📅 Original date posted:2015-09-01
📝 Original message:-----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 at 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-----

2023-06-07 17:38:20

- reply

📅 Original date posted:2015-08-27
📝 Original message:-----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
> <gavinandresen at gmail.com <mailto:gavinandresen at 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 at 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-----

2023-06-07 17:38:16

- reply

📅 Original date posted:2015-08-27
📝 Original message:-----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 at 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-----

2023-06-07 17:37:31

- reply

📅 Original date posted:2015-08-30
📝 Original message:-----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 <jgarzik at gmail.com
> <mailto:jgarzik at 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
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at 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
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at 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 at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at 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-----

2023-06-07 17:37:29

- reply

📅 Original date posted:2015-08-22
📝 Original message:-----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
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at 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 at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at 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-----

2023-06-07 17:37:28

- reply

📅 Original date posted:2015-08-21
📝 Original message:-----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 at 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-----

2023-06-07 17:37:27

- reply

📅 Original date posted:2015-08-21
📝 Original message:-----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-----

2023-06-07 17:37:25

- reply

📅 Original date posted:2015-08-21
📝 Original message:-----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 <fork_id1> <fork_id2> OP_DROP OP_DROP OP_HASH160 <hash script
> 1> OP_EQUAL OP_ENDIF OP_IF <fork_id3> OP_DROP OP_HASH160 <hash
> 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 <hash script 1> and can be spent on fork 3 by the
> owner of <hash script 2>.
>
> 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 at 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-----

2023-06-07 17:37:24

- reply

📅 Original date posted:2015-08-21
📝 Original message:-----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 at 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-----

2023-06-07 17:37:03

- reply

📅 Original date posted:2015-08-19
📝 Original message:-----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-----

2023-06-07 17:36:54

- reply

📅 Original date posted:2015-08-22
📝 Original message:-----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
> <bitcoin-dev at lists.linuxfoundation.org> 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 at 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-----

2023-06-07 17:36:42

- reply

📅 Original date posted:2015-08-19
📝 Original message:-----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
> <bitcoin-dev at lists.linuxfoundation.org> 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 at 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-----

2023-06-07 17:36:42

- reply

📅 Original date posted:2015-08-19
📝 Original message:-----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
> <odinn.cyberguerrilla at riseup.net> 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-----

2023-06-07 17:36:29

- reply

📅 Original date posted:2015-08-19
📝 Original message:-----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
> <odinn.cyberguerrilla at riseup.net
> <mailto:odinn.cyberguerrilla at riseup.net>> 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 <adam at cypherspace.org
>> <mailto:adam at cypherspace.org> <mailto:adam at cypherspace.org
>> <mailto:adam at cypherspace.org>>> 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 at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
>
>
>
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev at 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
GaaXCvGFeL/VT2P9uwUWLLuOinEdvx+AGScIfdhNuN6JhN3KFY6dHXSCYTvNtNg/
XEZWNeyF3nu5lCtNQCryobDobhVdhSsv6FIWgmEdS7Ubh30jv1oWbR1wELWFEDc=
=iY5p
-----END PGP SIGNATURE-----

2023-06-07 17:36:10

- reply

📅 Original date posted:2015-08-19
📝 Original message:-----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
> <bitcoin-dev at lists.linuxfoundation.org> 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 preferences as to which of these changes would be
>> best to do first. This whole XT thing is essentially giving *one*
>> proposal special treatment above those that others have proposed.
>> Many of us have only held back from doing this out of our belief
>> that goodwill amongst network participants is more important than
>> trying to push some pet feature some of us want.
>>
>> Please stop this negativity - we ALL want the best for Bitcoin
>> and are doing our best, given what we understand and know, to do
>> what’s right.
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev at 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/yyAAoJEGxwq/inSG8CaicIALQU//jNkUVRb6uzYFtSNb/y
cWViS5oaberLC2S0pQu2C4CciHSht347luM8kxlp3xL045SgIvvwXBzooH5HE+JE
+NscfC58+2RyQWgPiWrwQ2JSFQgaRzi58fyE8rLSdsLKXjJkbkaol6w2atbpvHP8
Zbm6sAOybLurA+2N9ZtxWosEZEfjT54Sf14+YNQlr5ve3JbYBIbZ8PhWPXwc5P/5
FuwBb/JBszClasWGxmsexrpXfK6Kqy2rOVOWmmYNMjpHR8oYZWKC42HTOXw2lig1
lspqMEXBTv+ppSk1KU5ovwftongX3W0lM5DOj3FXE7frlgcBxeMMFBFBFGnT3ZU=
=vCZH
-----END PGP SIGNATURE-----

2023-06-07 17:35:59

- reply

📅 Original date posted:2015-08-19
📝 Original message:-----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"
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at 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 at 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-----

2023-06-07 17:35:57

- reply

📅 Original date posted:2015-08-21
📝 Original message:-----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 at 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-----

2023-06-07 17:35:51

- reply

📅 Original date posted:2015-08-19
📝 Original message:-----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 <pete at petertodd.org>
> 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 at 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-----

2023-06-07 17:35:45

- reply

📅 Original date posted:2015-08-18
📝 Original message:-----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 at 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+/fAAoJEGxwq/inSG8C4ZAIAKm1pEne0FlOW1O4zLe6mZOz
YTcnpSHFiVw4AfUPgbzR813ODphnJqcwnoT1q/sojjqgIDtwZY+AqdjA3VAbe15D
bAPlvQGmXMlaXq8OteDYPKxPzQMUlRtxEd9+sxO5IGFx0kvmKQLzdk6cmgawcRhN
PrDyXIqLlx6Yp0REQ03v3poLTGojUkPLeqdMrJAjwpuAyv9F8iVUn7SeHemEi8cm
fW4wOJogA8j9P//3a7+Cr8bjnOz6+QwpHsdlZlKM4VUTxt3Vgx4vu+SQjQxWgZEK
I+HGvgQW1buoDxleBbFq6SJc55lhF41IB17tewuDuPzT2nL4zOkbis1tUk3ASxY=
=Rm7w
-----END PGP SIGNATURE-----

2023-06-07 17:34:52

- reply

📅 Original date posted:2015-08-12
📝 Original message:-----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-----

2023-06-07 17:34:31

- reply

📅 Original date posted:2015-08-10
📝 Original message:-----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"
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> 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 at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev at 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-----

2023-06-07 17:34:14

- reply

📅 Original date posted:2015-08-30
📝 Original message:-----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 at 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.
>
>
>> e. Can users opt to obtain their balance information via Tor
>> (or equivalent means)?
>>
>
> If Tor is set up as a SOCKS proxy, you can configure Bitcoin-QT
> download the blockchain and broadcast txs through a single Tor
> circuit. This can be configured once before opening Bitcoin-Qt.
>
> 8. Does the applications route outgoing transactions
> independently
>> from the manner in which it obtains balance information? Can
>> users opt to have their transactions submitted to the Bitcoin
>> network via Tor (or an equivalent means) independently of how
>> they obtain their balance information?
>>
>
> No, you can only configure a single proxy.
>
>
>> 9. If your application supports multiple identities/wallets,
>> does each one connect to the network as if it were completely
>> independent from the other?
>>
>
> No built-in support for multiple identities. You can hotswap wallet
> files to crudely simulate this. You'd have to manually change the
> Tor connection outside of Bitcoin-Qt to create the effect of making
> the network connections independent.
>
>
>> a. Does the application ever request balance information
>> for addresses belonging to multiple identities in the same
>> network query?
>>
>
> Blocks are downloaded and tx broadcasts received/relayed rather
> than querying the utxo set for a particular address. When swapping
> between wallet files, some information may be leaked e.g. the
> client may be at the same block height in terms of what it has
> downloaded from the p2p network, which may leak to global passive
> adversaries/AS's or sybil attackers the fact that a single client
> was used for multiple wallets.
>
>
>> b. Are outgoing transactions from multiple identities
>> routed independently of each other to the Bitcoin network?
>>
>
> Transactions from multiple identities would not be routed at the
> same time. I'm not clear what happens if you have a single wallet
> (identity) open and then open a new wallet (identity) without
> closing Bitcoin-Qt -- some of the same routing paths may still be
> used such that an attacker might observe transactions broadast
> signed by private keys from multiple wallets (identities) and
> observe that they appear to come from the same wallet client. OBPP
> should assume the worst unless prevented contrary evidence.
>
>
>> c. When an identity/wallet is deleted, does the deletion
>> process eliminate all evidence from the user's device that the
>> wallet was previously installed?
>>
>
> Identity is primarily tied to a wallet.dat file. Deleting it will
> remove most of the evidence that the wallet was installed on that
> device, but there may be some extra information in ancillary files
> that should also be deleted. This is an OS-level function, as
> there is no operation built into the client to delete a wallet file
> (identity).
>
>
>> Network Privacy
>>
>> 10. When a user performs a backup operation for their wallet,
>> does this generate any automatic network activity, such as a web
>> query or email?
>>
>
> No. Backups are local, and no email or SMS is linked. No web
> queries related to backup.
>
>
>> 11. Does your application perform any lookup external to the
>> user’s device related to identifying transaction senders or
>> recipients?
>>
>
> No
>
>
>> 12. Does you application connect to known endpoints which
>> would be visible to an ISP, such as your domain?
>>
>
> Yes, some connections to known p2p full nodes to bootstrap the
> connection to the Bitcoin p2p network. This is configurable, but
> there are defaults. An ISP is likely to be able to identify a
> customer as running the Bitcoin-Qt client in particular on this
> basis.
>
>
>> 13. If your application connects directly to nodes in the
>> Bitcoin P2P network, does it either use an unremarkable user
>> agent string (Bitcoin Core. BitcoinJ, etc), or randomize its user
>> agent on each connection?
>>
>
> BIP12 specifies format for user agents:
> https://github.com/bitcoin/bips/blob/master/bip-0014.mediawiki
>
> It appears that the Bitcoin-QT leaks specific information about its
> client version through User Agent. This file defines the current
> client version:
> https://github.com/bitcoin/bitcoin/blob/55294a9fb673ab0a7c99b9c18279fe
12a5a07890/src/clientversion.h
>
> Various other files seem to use this to build up the UA string,
> which is transmitted to other peers.
>
>
>>
>> Physical Access
>>
>> 14. Does the application uninstall process for your
>> application eliminate all evidence from the user's device that
>> the application was previously installed? Does it also eliminate
>> wallet data?
>>
>
> Probably depends on the platform. Last time I checked, I think
> Bitcoin-Qt leaves behind a .bitcoin directory on most platforms
> even after you run an uninstall script.
>
>
>> 15. Does your application use techniques such as
>> steganography to store persistent wallet metadata in a form not
>> identifiable as belong to a Bitcoin wallet application?
>>
>
> No
>
>
>> 16. Please describe the degree to which users can use
>> passwords/PINs to protect their data: a. Can the user set a
>> password/PIN to protect their private keys?
>>
>
> You can encrypt the wallet file with a password. The wallet is
> "locked" until the password is entered, preventing decryption of
> the private keys.
>
>
>> b. Can the user set a password/PIN to protect their public
>> keys and balance information?
>>
>
> No -- any wallet.dat file can be opened and the public keys
> inspected without the password.
>
>
>> c. Can the user set a password/PIN to encrypt other wallet
>> metadata, such as address books and transaction notes?
>>
>
> No -- any wallet.dat file can be opened and the metadata inspected
> without the password.
>
>
>> d. Does the application use a single password/PIN to cover
>> all protected data, or does it allow the use of multiple
>> passwords/PINs?
>>
>
> A single password for the wallet file.
>
>
>>
>> Custodianship
>>
>> 17. Do you as a wallet provider ever have access to
>> unencrypted copies of the user’s private keys, public keys, or
>> any other wallet metadata which may be used to associate a user
>> with their transactions or balances?
>>
>
> No custodianship.
>
>
>> Telemetry Data
>>
>> 18. If your application reports telemetry data, such as
>> usage information or automatic crash reporting, does the user
>> have the opportunity to review and approve all information
>> transmitted before it is sent?
>>
>
> No obvious telemetry data being sent.
>
>
>> Source Code and Building
>>
>> 19. Can a user of your application compile the application
>> themselves in a manner that produces a binary version identical
>> to the version you distribute (deterministic build system)?
>>
>
> Yes, I think that's the point of the gitian stuff.
>
> -Kristov
>
>
>
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev at 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-----
iQEcBAEBCgAGBQJV45G0AAoJEGxwq/inSG8CbZkH/06DGCXKdHUQlOKaeXYvLb7S
AonXX8/ZMB4D/Z2J9lE9BJP+CDZOUYAOwwaLDD/ecZvtiIgG0O7NP/pj6qLW3nW6
muazJH95u6Bac1jGxTf+cuEo3ntJFwtsXuP907GMpWGqM1Bk2BwrMIfUQFYm+9Rs
hpMpux/40d+dqs5daaBVr975d9+jkwcHRnpXJY/fYOCOXo+sF8lmRjeKoeMHyyw1
H2yJOuTIwZklEfg01yyuxKBRUpl2fGwO34yJp6/Ap+gjdHPP+DNOCYHEPQiPOxf8
rKTq9kgoABUj6aukS2phgDcbGJ6+YCuSWbh04GKviWLhvmzSmXXUQig6Ixz1PhM=
=3fIz
-----END PGP SIGNATURE-----

2023-06-07 17:34:07

- reply

📅 Original date posted:2015-08-11
📝 Original message:-----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
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> On Monday 10. August 2015 23.03.39 <tel:2015%2023.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 not an issue.
>
>
> You can buy broadband in every relevant country that easily
> supports the bandwidth we need. (remember we won't jump to 8Mb in a
> day, it will likely take at least 6 months).
>
>
> Neither one of those assertions is clear. Keep in mind the goal is
> to have Bitcoin survive active censorship. Presumably that means
> being able to run a node even in the face of a hostile ISP or
> government. Furthermore, it means being location independent and
> being able to move around. In many places the higher the bandwidth
> requirements the fewer the number of ISPs that are available to
> service you, and the more visible you are.
>
> It may also be necessary to be able to run over Tor. And not just
> today's Tor which is developed, serviced, and supported by the US
> government, but a Tor or I2P that future governments have turned
> hostile towards and actively censor or repress. Or existing
> authoritative governments, for that matter. How much bandwidth
> would be available through those connections?
>
> It may hopefully never be necessary to operate under such
> constraints, except by freedom seeking individuals within existing
> totalitarian regimes. However the credible threat of doing so may
> be what keeps Bitcoin from being repressed in the first place. Lose
> the capability to go underground, and it will be pressured into
> regulation, eventually.
Bitcoin (as well as the internet, and the world wide web) is already
regulated around the world.
There used to be a map that documented this fairly well, called
bitlegal (bitlegal.net) but the site is now parked or offline. There
is an alternative visual picture of the subject at:
http://is.gd/vFgYrf
The upshot of that is that web wallets (which are popularized due to
convenience) cannot be considered to provide users with control over
their money - extended discussion on this here in the bitcoin.org
repository:
https://github.com/bitcoin-dot-org/bitcoin.org/issues/996
My question, therefore is this:
When you say "it will be pressured into regulation, eventually," what
do you mean? Are you implying that even the hardware wallets and
desktop wallets for bitcoin will be regulated to the point where they
cannot be used by individuals who actually care about being able to
circumvent financial censorship? If so, explain how that is the case.
I could see an argument where that might be the case to some degree
if you would mention it in the context of services like Chainalysis
and other companies that are in the process of setting up services for
corporation-states for "virtual currency compliance;" e.g.; if
activity can be scanned and if a state has a requirement you are
supposed to be registered with the state to use virtual currency at
some level, and if companies scan the blockchain and report this
information to states (as they now do), then as you say, the only
reasonable method of using virtual currencies would be one in which
location is masked and information about the nodes and history of
transactions can be hidden. However, this requires more privacy and
anonymity effort in bitcoin development, but I don't think it would
actually keep people from using hardware and desktop wallets (although
I do think eventually people will, as they are beginning to now, be
gradually censored more and more from utilizing web wallets for
activities that they desire).
It seems to me that the existence of various tools and conditions
(external to the whole issue of legal constraints) are also very
important. For example, various companies have recently made public
announcements that they will leave (or not operate in) New York due to
Bitlicense - Kraken, Shapeshift.io, poloniex, and others. It's
understandable given the extreme nature of NY's approach (I personally
oppose any regulation of virtual currencies). But technically, they
didn't have to cease operating, did they? This was a failure in their
business model. They made a big statement about how evil NY was and
fled the scene, perhaps never to return to serve NY. (Note, I don't
live in NY, so I'm not personally being left out in the cold when
Kraken etc. leave, for the record.) As said, this was a failure in
Kraken, poloniex's, shapeshift's, etc., business model. Why? Because
here we are talking about web-based services. A distributed,
decentralized, peer-to-peer model in which the user has a piece of
software on their computer (think openbazaar or bitsquare) is far and
away better than services which are web based. Why? Because systems
which are set up such as (openbazaar, bitsquare) don't have to worry
about the constraints of state boundaries or shifting legal things,
nor do the people who made the software end up holding keys on behalf
of the users. If Kraken, poloniex, etc., had bothered to develop
contingency software (similar to what is being worked on with
https://bitsquare.io/ for example) for users who might be affected in
jurisdictions where corporation-states Just Don't Get It (read... NY,
and possibly CA, as examples) then maybe they wouldn't have to worry
about it at all. It just would be a matter of users installing a
piece of software from their website, discontinuing the web-based
exchange for that state, and directing users for highly regulated
states to a download page for the decentralized exchange software.
Not that hard really - but something we haven't seen done yet by the
big exchanges.
I have another question for you below...
>
> To the second point, it has been previously pointed out that large
> miners stand to gain from larger blocks, for the same basic
> underlying reasons as selfish mining. The incentive is to increase
> blocks, and miners are able to do so at will and without cost. I
> would not be so certain that we wouldn't see large blocks sooner
> than that.
>
>
> We should get the inverted bloom filters stuff (or competing
> products) working at least on a one-to-one basis so we can solve
> the propagation time problem. There frankly is a huge amount of
> optimization that can be done in that area, we don't even use
> locality (pingtime) to optimize distribution.
>> From my experience you can expect a 2-magnitude speedup in that
> same 6 month period by focusing some research there.
>
>
> This is basically already deployed thanks to Matt's relay network.
> Further improvements are not going to have dramatic effects.
>
>
> Remember 8Gb/block still doesn't support VISA/Mastercard.
>
>
> No, it doesn't. And 8GB/block is ludicrously large -- it would
> absolutely, without any doubt destroy the very nature of Bitcoin,
> turning it into a fundamentally uninteresting reincarnation of the
> existing financial system.
Why do you say 8GB / block would destroy the very nature of Bitcoin?
I don't see that it would destroy bitcoin... but also, what would
cause 8GB to happen very soon? As I understood it, any process would
phase increases. Explain how that would destroy the very nature of
Bitcoin?
Blocksize is extremely likely to get bigger (I'm supposing here that
some version of Garzik's BIP 100 or something very close to it is what
will likely be adopted and that the blocksize would be voted on
something like this:
https://bitcoin.stackexchange.com/questions/37943/bip-100-what-votes-are
- -possible
Am I wrong? Please let me know if I'm dumb.
I am aware consensus isn't precisely there yet, but I'm just curious.
> And still be unable to compete with VISA/Mastercard.
>
> So why then the pressure to go down a route that WILL lead to
> failure by your own metrics?
>
> I humbly suggest that maybe we should play the strengths of
> Bitcoin instead -- it's trustlessness via policy neutrality.
>
> Either that, or go work on Stellar. Because that's where it's
> headed otherwise.
>
>
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev at 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
iQEcBAEBAgAGBQJVypDkAAoJEGxwq/inSG8CSAEH/00rWd1wzGU3vhXqzVCzPcHx
GnMpR3iiSYpjm1Wt1tHc1SsJnhcVL93iNuOpQMTU7jXhj9qEYu58uoVz+XnfeiFY
i4B4awt3fuR33+D5Y+IKAm3KLd1HYpcSq7N2LSSJli2r8zvum+rcm5CXppR8qxJM
nmjlS/Tp6FwKhBzqOeBGK6vWnigs1KJgllO4AzNKPSXwFPhQKZGMbH1cFx5qKxp9
5UmU4bxZNKmOtjvfFyptR1lY+JYqaoQeOkdnlOYWAaClSiH1y8DnzJtpVSImw3X5
ZYI5GUp1HgE4RrxK8cykPn5j90elHSWe+GaREjMcidnyJYvtlPapnEpEnda5iBk=
=pxSx
-----END PGP SIGNATURE-----

2023-06-07 17:34:05

- reply

📅 Original date posted:2015-08-11
📝 Original message:-----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
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> 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
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> On Monday 10. August 2015 23.03.39 <tel:2015%2023.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 not an issue.
>
>
> You can buy broadband in every relevant country that easily
> supports the bandwidth we need. (remember we won't jump to 8Mb in a
> day, it will likely take at least 6 months).
>
>
> Neither one of those assertions is clear. Keep in mind the goal is
> to have Bitcoin survive active censorship. Presumably that means
> being able to run a node even in the face of a hostile ISP or
> government. Furthermore, it means being location independent and
> being able to move around. In many places the higher the bandwidth
> requirements the fewer the number of ISPs that are available to
> service you, and the more visible you are.
>
> It may also be necessary to be able to run over Tor. And not just
> today's Tor which is developed, serviced, and supported by the US
> government, but a Tor or I2P that future governments have turned
> hostile towards and actively censor or repress. Or existing
> authoritative governments, for that matter. How much bandwidth
> would be available through those connections?
>
> It may hopefully never be necessary to operate under such
> constraints, except by freedom seeking individuals within existing
> totalitarian regimes. However the credible threat of doing so may
> be what keeps Bitcoin from being repressed in the first place. Lose
> the capability to go underground, and it will be pressured into
> regulation, eventually.
>
> To the second point, it has been previously pointed out that large
> miners stand to gain from larger blocks, for the same basic
> underlying reasons as selfish mining. The incentive is to increase
> blocks, and miners are able to do so at will and without cost. I
> would not be so certain that we wouldn't see large blocks sooner
> than that.
>
>
> We should get the inverted bloom filters stuff (or competing
> products) working at least on a one-to-one basis so we can solve
> the propagation time problem. There frankly is a huge amount of
> optimization that can be done in that area, we don't even use
> locality (pingtime) to optimize distribution.
>> From my experience you can expect a 2-magnitude speedup in that
> same 6 month period by focusing some research there.
>
>
> This is basically already deployed thanks to Matt's relay network.
> Further improvements are not going to have dramatic effects.
>
>
> Remember 8Gb/block still doesn't support VISA/Mastercard.
>
>
> No, it doesn't. And 8GB/block is ludicrously large -- it would
> absolutely, without any doubt destroy the very nature of Bitcoin,
> turning it into a fundamentally uninteresting reincarnation of the
> existing financial system. And still be unable to compete with
> VISA/Mastercard.
>
> So why then the pressure to go down a route that WILL lead to
> failure by your own metrics?
>
> I humbly suggest that maybe we should play the strengths of
> Bitcoin instead -- it's trustlessness via policy neutrality.
>
> Either that, or go work on Stellar. Because that's where it's
> headed otherwise.
>
>
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
>
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev at 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
iQEcBAEBAgAGBQJVypQUAAoJEGxwq/inSG8CZ3wH/1BsvmusOaCHnQMSrRAhUSTy
owzhWC/7AWUuav7MSr8upLK29oGnL+R4+PqmyuXmSBQDjwJmtlS11GXvEP3/BqzA
Qxz6EkEw/BRPe1YgvsS9LJNe90aIsiJRgeGls3XIirdzE0b6PSFn4GB0hn0XLU5Y
rNA6WlWHlZ5c/J26sxbEUdWzQZd7cTybJgmUVwqjqaviBpvg5iGIHhN/dHglqRvm
9/IscT3MNneXqD5QYwNvYUG2yjgRLgggnIufU37r8Rt+S6xJ0TK++R5hhKS5fF61
7xBQGDuczI+/mCGMc88JZxEIAV/H63SfIrD3bjqcfDnGXDl9SmrfdiIwyy3Yitc=
=zbGE
-----END PGP SIGNATURE-----

2023-06-07 17:33:04

- reply

📅 Original date posted:2015-08-10
📝 Original message:-----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"
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at 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-----

2023-06-07 17:33:03

- reply

📅 Original date posted:2015-08-10
📝 Original message:-----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
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> 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
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> 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 his local payment
> channel, increasing the amount payable to him when the channel is
> closed.
>
> There are two possible sources of funding for Bob's increased
> claim. They can appear alone, or in combination:
>
>
> Funding Source (1) A deposit from Bob's payment hub
>
> Bob can receive funds, if his payment hub has made a deposit to
> the channel. Another name for this is "credit".
>
> This credit has no default risk: Bob cannot just take payment
> hub's deposit. 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.
>
> This is a 3rd-party dependency totally absent with plain old
> bitcoin. It will come with a fee and, in an important way, it is
> worse than the current banking system. If a bank will not even
> open an account for Bob today, why would a payment hub lock up hard
> bitcoin to allow Bob to be paid through a Poon-Dryja channel?
>
>
> Funding Source (2) Bob's previous spends
>
> If Bob has previously spent from the channel, decreasing his claim
> on its funds (which he could have deposited himself), that claim
> can be re-increased.
>
> To avoid needing credit (1), Bob has an incentive to consolidate
> spending and income in the same payment channel, just as with
> today's banks. This is at odds with the idea that Bob will have
> accounts with many payment hubs. It is an incentive for
> centralization.
>
>
> With Lightning Network, Bob will need a powerful middleman to send
> and receive money effectively. *That* is uninteresting to me.
>
>
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
>
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev at 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
iQEcBAEBAgAGBQJVyNlfAAoJEGxwq/inSG8CTvgH/3b4wyoU+hQtQ7Ewk4n1UK/Q
gBezGVfv6v9D8uRU+8gR37gG6TpiG3VS37g47fkAbqTTUzY16qGRXMV8mi0FVz/3
8Hqz7rWZEllYfeYrV9MUoNftrFmjy1PucPgd95BYmWaHoZRxBwhr+YpkZS5lfEqK
p1byEdqXW04sc3UBdNlirYNOBJA0wOPgco45G2S3gFBh5XQZ9YCLB+x/IN8rW1mS
wQ3FrXRdEKfGMZ83xij1zOVpwi3bPJ5XrUzEV3sdGUdj6jWi0Pa05tRD+0qt7dpZ
oPq4p6aLj2z5/mwyiaW6T14CNY1Mp46tMgAv+BOJ/M3HA350isTGxG2X+73KeH0=
=xX4u
-----END PGP SIGNATURE-----

2023-06-07 17:32:14

- reply

📅 Original date posted:2015-08-03
📝 Original message:-----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 at 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*
> <https://plus.google.com/u/0/113107039501292625391/posts>
> <http://www.linkedin.com/in/ergophobe> /"Don't bunt. Aim out of the
> ball park. Aim for the company of immortals." -- David Ogilvy /
>
> /This message was created with 100% recycled electrons. Please
> think twice before printing./
>
>
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev at 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
iQEcBAEBAgAGBQJVvtxQAAoJEGxwq/inSG8CkVEIAJu9XsUzF4CKFD6xF3yofZ6R
l2KcYjX1UegUi5mYAv8BLJVd5ZbRrUfjoIR6dbjMu2q4bYADCt57ZXx7zV8bdHQT
Si9puYe3BboeeKJceS1jU5rkQbXrh/T4owqVMf8VAhDHQHVUVtSEvvx9gmxjFhze
zz/aeWtCKH44EJB8/PqO3nN6iOIhq7QoKmiqqO1HL6lMXNTck8wq07UmhXziGK2F
/5kX/uDM2BlAQs2E1IMeWe9GUJhHOQEqLfUPopfCTS7uTDt8FERWvobe5kPSV/vp
RNmQ5ojhQl7qWIq/I7zmtzDJNNi16PsKxFFl358bXAPzw4bq7ymzniVLqo4C5LE=
=eKYy
-----END PGP SIGNATURE-----

2023-06-07 17:32:09

- reply

📅 Original date posted:2015-08-02
📝 Original message:-----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
>> <bitcoin-dev at lists.linuxfoundation.org> 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 is verified, which would
> make sure an invalid fork won't grow beyond 2 blocks.
>
>
>
>>> Global bandwidth is expected to grow by 37%/year until 2021 so
>>> 27.67% should be safe at least for the coming 10 years.
>>> Source:
>>>
>> https://www.telegeography.com/research-services/global-bandwidth-fore
cast-service/
>>
>
>>
>>
>> I'd rather be conservative here. My primary purpose is trying to
>> create an uncontroversial proposal that introduces an expectation
>> of growth with technology.
>
> If we could have a longer initial ramp up period, we may adopt a
> slower long term parameter. I think we should at least restore the
> original 32MB limit in a reasonable time frame, say 6-8 years,
> instead of 20 years in your proposal. If you believe Bitcoin should
> become a global settlement network, 32MB would be the very minimum
> as that is only 75% of current SWIFT traffic.
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev at 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
iQEcBAEBAgAGBQJVvc7bAAoJEGxwq/inSG8CPIMH/RjIEWuig7oBQxA3sX0TNoDL
ohNcXyaa69lTJ8M5kfihWEgxKrEBJ8H/yp0rxIz/B5SfOCgTho9Yzyj4KrJ+qTvs
M4x2/9YthVvIBuJ5g8IbYVH73pNNR+xPnR1VikbffmGsWNIN3kYgDWUeO1qVWswd
y0eySo/8KdaPR7ojyF03l028Uejv4uSHCy8W0FHo6lyEBUAfIOeQULMYllyUbN2S
B3K5si6Swar93EQZ510PfB1u4DMK26ITXhK+Hxx67cjHu7F1lvyl+zzncUlpXrDM
b30f0kYImFV96vIGlEh+MVLzS1SAkaPW/S5K9fdZ97tYfwXC5az1ki0hUapnujU=
=6VEW
-----END PGP SIGNATURE-----

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

📅 Original date posted:2015-07-30
📝 Original message:-----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 at 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-----

2023-06-07 15:44:12

- reply

📅 Original date posted:2015-07-30
📝 Original message:-----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
>> <mailto:bitcoin-dev at lists.linuxfoundation.org> *Sent:* Wednesday,
>> July 29, 2015 7:09 AM *To:*
>> bitcoin-dev at lists.linuxfoundation.org
>> <mailto:bitcoin-dev at 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
>> <gubatron at gmail.com> 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
>> <bitcoin-dev at lists.linuxfoundation.org
>> <mailto:bitcoin-dev at lists.linuxfoundation.org>> 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 Bitcoin succombs to the free stuff army, I will sell all the
>> coins and leave. Nothing is for free.
>>
>> I apologize for any exagerations, but I just felt strongly
>> towards expressing my opinion here. I'm only a local Bitcoin
>> trader, computer engineer, with a reasonable understanding of
>> free markets. And I'm running only one full node.
>>
>> Kind regards, Valentin
>>
>>
>> _______________________________________________ bitcoin-dev
>> mailing list bitcoin-dev at lists.linuxfoundation.org
>> <mailto:bitcoin-dev at lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev at 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
iQEcBAEBAgAGBQJVufPFAAoJEGxwq/inSG8CBHUIAKZQaTvJToxGmEXSTckHZ2fX
NEVJNbw0oebdpQU6mvYR1hjK4LE/pY+cyfTh98RxQtsIHGJqVghU/kgzP6PSyS9J
NYB3HO3iz2l9rBRQCe197wfg1GlY1QhepNFofYj1k1MDIB2QCMUXhUwz7e7wncuc
TESDEHH/mUqPOnWBKeEbru7gr0aLn8ltmEHXwDQdlPP9iyXGpt9oGWoP1fBYTRwg
r29vW8wCYhKzbS44ovPRilGWnWhxyB/2N5Qb94JkdzWCdr98bBIZQ8eL+w64lEhv
9A8Umiu9B8c6Ch9C1d4c/ircA4MJKSroTfLh8SgkjYtdAnECAJmQ3ZcUGgyGerw=
=gCvd
-----END PGP SIGNATURE-----

2023-06-07 15:44:03

- reply

📅 Original date posted:2015-07-30
📝 Original message:-----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
> <bitcoin-dev at lists.linuxfoundation.org> 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 personally would pay several multiples of the
>> competitors' fees to continue using bitcoin.
>>
>> Sure, some marginal use cases will drop off with greater fees,
>> but that's normal and expected. These will be use cases where the
>> user doesn't care about bitcoin's advantages. We must be willing
>> to let these use cases go anyway, because we unfortunately don't
>> have room on chain for everything anyone might want to do.
>>
>> Therefore, bitcoin tx fees can go much higher than the
>> competition.
>>
>> Remember how Satoshi referenced the banking crisis in his early
>> work? The 2008 banking crisis was about a lot of things, but high
>> credit card and paypal fees wasnt one of them. There's more going
>> on here than just payments. Any speculative economic analysis
>> would do better to include this fact.
>
> Precisely. And as "just a payment system" Bitcoin is not an
> especially great one: The design requirements for
> decenteralization impose considerable costs. To the extent that
> the technology in Bitcoin is useful at all for building "just
> another payment system" this technology in in the process of being
> agressively copied by parties with deep fiat relationships
> (including in partnership with centeral banks). If the focus for
> Bitcoin's competative advantage becomes exclusively "better"
> payments then it will almost certinatly fail in the market-place
> against competing systems which avoid the Bitcoin currency adoption
> related obsticles (but also gain none of Bitcoin's important
> social/political promise).
>
> Also, critically, if Bitcoin's security properties are manintained
> and enhanced then Bitcoin can be used to build secure systems which
> _also_ accomidate those applications and we can have both. But if
> Bitcoin's security properties are not strong then then advanced
> tools cannot be built for it. E.g. atomic swaps make trustless
> trades with external systems possible; but they are especially
> sensitive to long reorginizations by miners... so they can only be
> securely used where those reorgs are infeasable. So while I agree
> that we must be willing to tolerate not catching every conceivable
> use case; most of the time all that means is addressing them via a
> less direct but more focused solution rather than ignoring them
> completely. _______________________________________________
> bitcoin-dev mailing list bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev at 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
iQEcBAEBAgAGBQJVufH2AAoJEGxwq/inSG8C1mgH/3poEpk8pDDgZ7YQlGmAZjiO
MDBempLkfm1BFFoNAzjMn9mwtmL9wDfpn/sd/YbuIriJjQR2WSl6zy/sLx/uIYxd
qRuSRwOzN6wN7NfAuG7Lt3NtawOjAgl87n5YhRVB/d/MAK5HAvx3L9ME1Px//qsF
Czg5r0XG4ZiQnT8J30caMtooSVU9toradAmMleVbMVOi9KViyuW2IvXz5mM1jYHh
h+CB+CVHlhuKubXWpnnxYtOLLRQM5QSyfQiMPimVG0QPSOC5UkXJNo5gK6YMtBkT
0FevJyoMF+0LVTTPVGms+jolxu2PX3RW59nhNKEAuxOWfeHdMFFGtPP04XbpqSo=
=R3aj
-----END PGP SIGNATURE-----

2023-06-07 15:43:54

- reply

📅 Original date posted:2015-07-30
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Mike, tone it down, please, when I read your stuff it's like you are
drinking too much Red bull or something.
On 07/29/2015 11:03 AM, Mike Hearn via bitcoin-dev wrote:
> It was _well_ .... understood that the users of Bitcoin would wish
> to protect its decenteralization by limiting the size of the chain
> to keep it verifyable on small devices.
>
>
> No it wasn't. That is something you invented yourself much later.
> "Small devices" isn't even defined anywhere, so there can't have
> been any such understanding.
>
> The actual understanding was the opposite. Satoshi's words:
>
> "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."
>
> That is from 2008:
>
>
> http://satoshi.nakamotoinstitute.org/emails/cryptography/2/#selection-
75.16-83.14
>
>
> Then he went on to talk about Moore's law and streaming HD videos
> and the like. At no point did he ever talk about limiting the
> system for "small devices".
>
> I have been both working on and using Bitcoin for longer than you
> have been around, Gregory. Please don't attempt to bullshit me
> about what the plan was. And stop obscuring what this is about.
> It's not some personality cult - the reason I keep beating you over
> the head with Satoshi's words is because it's that founding vision
> of the project that brought everyone together, and gave us all a
> shared goal.
>
> If Satoshi had said from the start,
>
> "Bitcoin cannot ever scale. So I intend it to be heavily limited
> and used only by a handful of people for rare transactions. I
> picked 1mb as an arbitrary limit to ensure it never gets popular."
>
> ... then I'd have not bothered getting involved. I'd have said,
> huh, I don't really feel like putting effort into a system that is
> intended to NOT be popular. And so would many other people.
>
>
> Don't think you can claim otherwise, because doing so is flat out
> wrong.
>
>
> I just did claim otherwise and no, I am not wrong at all.
>
> (Which, incidentially, is insanely toxic to any security argument
> for SPV; ---- and now we see the market failure that results from
> your and Gavin years long campaign to ignore problems in the mining
> ecosystem:
>
>
> Since when have we "campaigned" to "ignore problems" in the mining
> ecosystem? What does that even mean? Was it not I who wrote this
> blog post?
>
>
> http://blog.bitcoinfoundation.org/mining-decentralisation-the-low-hang
ing-fruit/
>
> Gregory, you are getting really crazy now. Stop it. The trend
> towards mining centralisation is not the fault of Gavin or myself,
> or anyone else. And SPV is exactly what was always intended to be
> used. It's not something I "fixated" on, it's right there in the
> white paper. Satoshi even encouraged me to keep working on bitcoinj
> before he left!
>
>
> Look, it's clear you have decided that the way Bitcoin was meant
> to evolve isn't to your personal liking. That's fine. Go make an
> alt coin where your founding documents state that it's intended to
> always run on a 2015 Raspberry Pi, or whatever it is you mean by
> "small device". Remove SPV capability from the protocol so everyone
> has to fully validate. Make sure that's the understanding that
> everyone has from day one about what your alt coin is for. Then
> when someone says, gee, it'd be nice if we had some more capacity,
> you or someone else can go point at the announcement emails and say
> "no, GregCoin is meant to always be verifiable on small devices,
> that's our social contract and it's written into the consensus
> rules for that reason".
>
> But your attempt to convert Bitcoin into that altcoin by exploiting
> a temporary hack is desperate, and deeply upsetting to many people.
> Not many quit their jobs and created companies to build products
> only for today's tiny user base.
>
>
> My list of "things a full node is useful for" wasn't ordered by
> importance, by the way.
>
>
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev at 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
iQEcBAEBAgAGBQJVuejTAAoJEGxwq/inSG8CKigH+gJpevuZ/mbCy9cjhLvX6VT/
NBQjU82EPDkMkASqoQOekIBOrgODBcN8HsR1xnPHYZYh9HmMaQ/kZDZI3EUP76CU
s1vvL0AQC11b0aai+z1K5XU6xK+HxRewujBj9lKtH/JuRUHoKUrRIn/5KxT6Nb5+
OXCpoXKnynfu7T57RrVBOKCPW0Oo7jay9owjDzy+J/ATfqqPDB++7nDbPPVzyrNs
6TlHaC/CxRcq832lwBe1KwaX4A7KFiqHwWoK5/R7Ccyj5X21nHXnDOuXLqwOfGtH
1aARAQ6dqHor5Kw9/Y7yAdoNnrK3XYR80Qdr6I77f3X2B40GdnBiBOSUpoQNAB0=
=nRef
-----END PGP SIGNATURE-----

2023-06-07 15:42:42

- reply

📅 Original date posted:2015-07-24
📝 Original message:-----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 <gavinandresen at gmail.com
> <mailto:gavinandresen at gmail.com>> 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.
>
> Software that assembles transactions into blocks and software that
> validates blocks must be updated to enforce the new consensus
> rules.
>
> ==Deployment==
>
> This change will be deployed with BIP 100 or BIP 101.
>
> ==Discussion==
>
> Linking these consensus rules to the maximum block size allows
> more transactions and/or transactions with more inputs or outputs
> to be included if the maximum block size increases.
>
> The constants are chosen to be maximally compatible with the
> existing consensus rule, and to virtually eliminate the possibility
> that bitcoins could be lost if somebody had locked some funds in a
> pre-signed, expensive-to-validate, locktime-in-the-future
> transaction.
>
> But they are chosen to put a reasonable upper bound on the CPU
> time required to validate a maximum-sized block.
>
> ===Alternatives to this BIP:===
>
> 1. A simple limit on transaction size (e.g. any transaction in a
> block must be 100,000 bytes or smaller).
>
> 2. Fix the CHECKSIG/CHECKMULTISIG opcodes so they don't re-hash
> variations of the transaction's data. This is the "most correct"
> solution, but would require updating every piece of
> transaction-creating and transaction-validating software to change
> how they compute the signature hash, and to avoid potential attacks
> would still require some limit on how many such operations were
> permitted.
>
> ==References==
>
> [[https://bitcointalk.org/?topic=140078|CVE-2013-2292]]: Sergio
> Demian Lerner's original report
>
>
>
>
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev at 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
iQEcBAEBAgAGBQJVsty2AAoJEGxwq/inSG8ChnsH/1zvxxYlKE4LPdwx9PPdk4Pi
W9Vj1RAX+J57f+kxE6tVZRLkIVo0vpTPqDaNMAcvsDWPdlK1wQKrjzws1qN8UpiO
yoMHAu8TC+HMoV+wJZVHafXf/e+PitWMS2P2HMZFVSlh7m/nsZNvjkykgyBNgaoh
wf4SQOSoorCUr4HDDsw32lmMq5Sohaq3Z+WSXKik8awel6OcerVPDwAWkb79tXTC
THI+t3YjLhQjwXNvs3Iwn7z1iYSSUbZUoUlOpCwaeVx6tdtDgW4vzzohCOEl2VqO
z8K6TM60+01pHAbrsWv9ItOBus8wJWHEyUFcdshf71BaNq2NHfijyCy9dCxtgWg=
=speV
-----END PGP SIGNATURE-----

2023-06-07 15:42:36

- reply

📅 Original date posted:2015-07-19
📝 Original message:-----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 at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev at 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-----

2023-06-07 15:42:23

- reply

📅 Original date posted:2015-07-16
📝 Original message:-----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 <pete at petertodd.org
> <mailto:pete at petertodd.org>> 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 at 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-----

2023-06-07 15:42:03

- reply

📅 Original date posted:2015-07-15
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
The numbering of the version, though. <shivers>
On 07/12/2015 08:49 AM, Wladimir J. van der Laan wrote:
> Bitcoin Core version 0.11.0 is now available from:
>
> <https://bitcoin.org/bin/bitcoin-core-0.11.0/>
>
> This is a new major version release, bringing both new features
> and bug fixes.
>
> Please report bugs using the issue tracker at github:
>
> <https://github.com/bitcoin/bitcoin/issues>
>
> 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.00001. 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.00005 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 of
> space used will exceed the pruning target in order to keep the
> required last 288 blocks on disk.
>
> Block pruning works during initial sync in the same way as during
> steady state, by deleting block files "as you go" whenever disk
> space is allocated. Thus, if the user specifies 550MB, once that
> level is reached the program will begin deleting the oldest block
> and undo files, while continuing to download the blockchain.
>
> For now, block pruning disables block relay. In the future, nodes
> with block pruning will at a minimum relay "new" blocks, meaning
> blocks that extend their active chain.
>
> Block pruning is currently incompatible with running a wallet due
> to the fact that block data is used for rescanning the wallet and
> importing keys or addresses (which require a rescan.) However,
> running the wallet with block pruning will be supported in the near
> future, subject to those limitations.
>
> Block pruning is also incompatible with -txindex and will
> automatically disable it.
>
> Once you have pruned blocks, going back to unpruned state requires
> re-downloading the entire blockchain. To do this, re-start the
> node with -reindex. Note also that any problem that would cause a
> user to reindex (e.g., disk corruption) will cause a pruned node to
> redownload the entire blockchain. Finally, note that when a pruned
> node reindexes, it will delete any blk???.dat and rev???.dat files
> in the data directory prior to restarting the download.
>
> To enable block pruning on the command line:
>
> - `-prune=N`: where N is the number of MB to allot for raw block &
> undo data.
>
> Modified RPC calls:
>
> - `getblockchaininfo` now includes whether we are in pruned mode or
> not. - `getblock` will check if the block's data has been pruned
> and if so, return an error. - `getrawtransaction` will no longer be
> able to locate a transaction that has a UTXO but where its block
> file has been pruned.
>
> Pruning is disabled by default.
>
> Big endian support --------------------
>
> Experimental support for big-endian CPU architectures was added in
> this release. All little-endian specific code was replaced with
> endian-neutral constructs. This has been tested on at least MIPS
> and PPC hosts. The build system will automatically detect the
> endianness of the target.
>
> Memory usage optimization --------------------------
>
> There have been many changes in this release to reduce the default
> memory usage of a node, among which:
>
> - Accurate UTXO cache size accounting (#6102); this makes the
> option `-dbcache` precise where this grossly underestimated memory
> usage before - Reduce size of per-peer data structure (#6064 and
> others); this increases the number of connections that can be
> supported with the same amount of memory - Reduce the number of
> threads (#5964, #5679); lowers the amount of (esp. virtual) memory
> needed
>
> Fee estimation changes ----------------------
>
> This release improves the algorithm used for fee estimation.
> Previously, -1 was returned when there was insufficient data to
> give an estimate. Now, -1 will also be returned when there is no
> fee or priority high enough for the desired confirmation target. In
> those cases, it can help to ask for an estimate for a higher target
> number of blocks. It is not uncommon for there to be no fee or
> priority high enough to be reliably (85%) included in the next
> block and for this reason, the default for `-txconfirmtarget=n` has
> changed from 1 to 2.
>
> Privacy: Disable wallet transaction broadcast
> ----------------------------------------------
>
> This release adds an option `-walletbroadcast=0` to prevent
> automatic transaction broadcast and rebroadcast (#5951). This
> option allows separating transaction submission from the node
> functionality.
>
> Making use of this, third-party scripts can be written to take care
> of transaction (re)broadcast:
>
> - Send the transaction as normal, either through RPC or the GUI -
> Retrieve the transaction data through RPC using `gettransaction`
> (NOT `getrawtransaction`). The `hex` field of the result will
> contain the raw hexadecimal representation of the transaction - The
> transaction can then be broadcasted through arbitrary mechanisms
> supported by the script
>
> One such application is selective Tor usage, where the node runs on
> the normal internet but transactions are broadcasted over Tor.
>
> For an example script see
> [bitcoin-submittx](https://github.com/laanwj/bitcoin-submittx).
>
> Privacy: Stream isolation for Tor
> ----------------------------------
>
> This release adds functionality to create a new circuit for every
> peer connection, when the software is used with Tor. The new
> option, `-proxyrandomize`, is on by default.
>
> When enabled, every outgoing connection will (potentially) go
> through a different exit node. That significantly reduces the
> chance to get unlucky and pick a single exit node that is either
> malicious, or widely banned from the P2P network. This improves
> connection reliability as well as privacy, especially for the
> initial connections.
>
> **Important note:** If a non-Tor SOCKS5 proxy is configured that
> supports authentication, but doesn't require it, this change may
> cause that proxy to reject connections. A user and password is sent
> where they weren't before. This setup is exceedingly rare, but in
> this case `-proxyrandomize=0` can be passed to disable the
> behavior.
>
> 0.11.0 Change log =================
>
> Detailed release notes follow. This overview includes changes that
> affect behavior, not code moves, refactors and string updates. For
> convenience in locating the code changes and accompanying
> discussion, both the pull request and git merge commit are
> mentioned.
>
> ### RPC and REST - #5461 `5f7279a` signrawtransaction: validate
> private key - #5444 `103f66b` Add
> /rest/headers/<count>/<hash>.<ext> - #4964 `95ecc0a` Add
> scriptPubKey field to validateaddress RPC call - #5476 `c986972`
> Add time offset into getpeerinfo output - #5540 `84eba47` Add
> unconfirmed and immature balances to getwalletinfo - #5599
> `40e96a3` Get rid of the internal miner's hashmeter - #5711
> `87ecfb0` Push down RPC locks - #5754 `1c4e3f9` fix
> getblocktemplate lock issue - #5756 `5d901d8` Fix
> getblocktemplate_proposals test by mining one block - #5548
> `d48ce48` Add /rest/chaininfos - #5992 `4c4f1b4` Push down RPC
> reqWallet flag - #6036 `585b5db` Show zero value txouts in
> listunspent - #5199 `6364408` Add RPC call `gettxoutproof` to
> generate and verify merkle blocks - #5418 `16341cc` Report missing
> inputs in sendrawtransaction - #5937 `40f5e8d` show script
> verification errors in signrawtransaction result - #5420 `1fd2d39`
> getutxos REST command (based on Bip64) - #6193 `42746b0` [REST]
> remove json input for getutxos, limit to query max. 15 outpoints -
> #6226 `5901596` json: fail read_string if string contains trailing
> garbage
>
> ### Configuration and command-line options - #5636 `a353ad4` Add
> option `-allowselfsignedrootcertificate` to allow self signed root
> certs (for testing payment requests) - #5900 `3e8a1f2` Add a
> consistency check `-checkblockindex` for the block chain data
> structures - #5951 `7efc9cf` Make it possible to disable wallet
> transaction broadcast (using `-walletbroadcast=0`) - #5911
> `b6ea3bc` privacy: Stream isolation for Tor (on by default, use
> `-proxyrandomize=0` to disable) - #5863 `c271304` Add autoprune
> functionality (`-prune=<size>`) - #6153 `0bcf04f` Parameter
> interaction: disable upnp if -proxy set - #6274 `4d9c7fe` Add
> option `-alerts` to opt out of alert system
>
> ### Block and transaction handling - #5367 `dcc1304` Do all block
> index writes in a batch - #5253 `203632d` Check against MANDATORY
> flags prior to accepting to mempool - #5459 `4406c3e` Reject
> headers that build on an invalid parent - #5481 `055f3ae` Apply
> AreSane() checks to the fees from the network - #5580 `40d65eb`
> Preemptively catch a few potential bugs - #5349 `f55c5e9` Implement
> test for merkle tree malleability in CPartialMerkleTree - #5564
> `a89b837` clarify obscure uses of EvalScript() - #5521 `8e4578a`
> Reject non-final txs even in testnet/regtest - #5707 `6af674e`
> Change hardcoded character constants to descriptive named constants
> for db keys - #5286 `fcf646c` Change the default maximum OP_RETURN
> size to 80 bytes - #5710 `175d86e` Add more information to errors
> in ReadBlockFromDisk - #5948 `b36f1ce` Use GetAncestor to compute
> new target - #5959 `a0bfc69` Add additional block index consistency
> checks - #6058 `7e0e7f8` autoprune minor post-merge improvements -
> #5159 `2cc1372` New fee estimation code - #6102 `6fb90d8` Implement
> accurate UTXO cache size accounting - #6129 `2a82298` Bug fix for
> clearing fCheckForPruning - #5947 `e9af4e6` Alert if it is very
> likely we are getting a bad chain - #6203 `c00ae64` Remove P2SH
> coinbase flag, no longer interesting - #5985 `37b4e42` Fix removing
> of orphan transactions - #6221 `6cb70ca` Prune: Support
> noncontiguous block files - #6256 `fce474c` Use best header chain
> timestamps to detect partitioning - #6233 `a587606` Advance
> pindexLastCommonBlock for blocks in chainActive
>
> ### P2P protocol and network code - #5507 `844ace9` Prevent DOS
> attacks on in-flight data structures - #5770 `32a8b6a` Sanitize
> command strings before logging them - #5859 `dd4ffce` Add correct
> bool combiner for net signals - #5876 `8e4fd0c` Add a NODE_GETUTXO
> service bit and document NODE_NETWORK - #6028 `b9311fb` Move
> nLastTry from CAddress to CAddrInfo - #5662 `5048465` Change
> download logic to allow calling getdata on inbound peers - #5971
> `18d2832` replace absolute sleep with conditional wait - #5918
> `7bf5d5e` Use equivalent PoW for non-main-chain requests - #6059
> `f026ab6` chainparams: use SeedSpec6's rather than CAddress's for
> fixed seeds - #6080 `31c0bf1` Add jonasschnellis dns seeder - #5976
> `9f7809f` Reduce download timeouts as blocks arrive - #6172
> `b4bbad1` Ignore getheaders requests when not synced - #5875
> `304892f` Be stricter in processing unrequested blocks - #6333
> `41bbc85` Hardcoded seeds update June 2015
>
> ### Validation - #5143 `48e1765` Implement BIP62 rule 6 - #5713
> `41e6e4c` Implement BIP66
>
> ### Build system - #5501 `c76c9d2` Add mips, mipsel and aarch64 to
> depends platforms - #5334 `cf87536` libbitcoinconsensus: Add
> pkg-config support - #5514 `ed11d53` Fix 'make distcheck' - #5505
> `a99ef7d` Build winshutdownmonitor.cpp on Windows only - #5582
> `e8a6639` Osx toolchain update - #5684 `ab64022` osx: bump build
> sdk to 10.9 - #5695 `23ef5b7` depends: latest config.guess and
> config.sub - #5509 `31dedb4` Fixes when compiling in c++11 mode -
> #5819 `f8e68f7` release: use static libstdc++ and disable reduced
> exports by default - #5510 `7c3fbc3` Big endian support - #5149
> `c7abfa5` Add script to verify all merge commits are signed - #6082
> `7abbb7e` qt: disable qt tests when one of the checks for the gui
> fails - #6244 `0401aa2` configure: Detect (and reject) LibreSSL -
> #6269 `95aca44` gitian: Use the new bitcoin-detached-sigs git repo
> for OSX signatures - #6285 `ef1d506` Fix scheduler build with some
> boost versions. - #6280 `25c2216` depends: fix Boost 1.55 build on
> GCC 5 - #6303 `b711599` gitian: add a gitian-win-signer descriptor
> - #6246 `8ea6d37` Fix build on FreeBSD - #6282 `daf956b` fix crash
> on shutdown when e.g. changing -txindex and abort action - #6354
> `bdf0d94` Gitian windows signing normalization
>
> ### Wallet - #2340 `811c71d` Discourage fee sniping with nLockTime
> - #5485 `d01bcc4` Enforce minRelayTxFee on wallet created tx and
> add a maxtxfee option - #5508 `9a5cabf` Add RandAddSeedPerfmon to
> MakeNewKey - #4805 `8204e19` Do not flush the wallet in
> AddToWalletIfInvolvingMe(..) - #5319 `93b7544` Clean up wallet
> encryption code - #5831 `df5c246` Subtract fee from amount - #6076
> `6c97fd1` wallet: fix boost::get usage with boost 1.58 - #5511
> `23c998d` Sort pending wallet transactions before reaccepting -
> #6126 `26e08a1` Change default nTxConfirmTarget to 2 - #6183
> `75a4d51` Fix off-by-one error w/ nLockTime in the wallet - #6276
> `c9fd907` Fix getbalance * 0
>
> ### GUI - #5219 `f3af0c8` New icons - #5228 `bb3c75b` HiDPI
> (retina) support for splash screen - #5258 `73cbf0a` The RPC
> Console should be a QWidget to make window more independent - #5488
> `851dfc7` Light blue icon color for regtest - #5547 `a39aa74` New
> icon for the debug window - #5493 `e515309` Adopt style colour for
> button icons - #5557 `70477a0` On close of splashscreen interrupt
> verifyDB - #5559 `83be8fd` Make the command-line-args dialog
> better - #5144 `c5380a9` Elaborate on signverify message dialog
> warning - #5489 `d1aa3c6` Optimize PNG files - #5649 `e0cd2f5` Use
> text-color icons for system tray Send/Receive menu entries - #5651
> `848f55d` Coin Control: Use U+2248 "ALMOST EQUAL TO" rather than a
> simple tilde - #5626 `ab0d798` Fix icon sizes and column width -
> #5683 `c7b22aa` add new osx dmg background picture - #5620
> `7823598` Payment request expiration bug fix - #5729 `9c4a5a5`
> Allow unit changes for read-only BitcoinAmountField - #5753
> `0f44672` Add bitcoin logo to about screen - #5629 `a956586`
> Prevent amount overflow problem with payment requests - #5830
> `215475a` Don't save geometry for options and about/help window -
> #5793 `d26f0b2` Honor current network when creating autostart link
> - #5847 `f238add` Startup script for centos, with documentation -
> #5915 `5bd3a92` Fix a static qt5 crash when using certain versions
> of libxcb - #5898 `bb56781` Fix rpc console font size to flexible
> metrics - #5467 `bc8535b` Payment request / server work - part 2 -
> #6161 `180c164` Remove movable option for toolbar - #6160 `0d862c2`
> Overviewpage: make sure warning icons gets colored
>
> ### Tests - #5453 `2f2d337` Add ability to run single test manually
> to RPC tests - #5421 `886eb57` Test unexecuted OP_CODESEPARATOR -
> #5530 `565b300` Additional rpc tests - #5611 `37b185c` Fix spurious
> windows test failures after 012598880c - #5613 `2eda47b` Fix
> smartfees test for change to relay policy - #5612 `e3f5727` Fix
> zapwallettxes test - #5642 `30a5b5f` Prepare paymentservertests for
> new unit tests - #5784 `e3a3cd7` Fix usage of NegateSignatureS in
> script_tests - #5813 `ee9f2bf` Add unit tests for next difficulty
> calculations - #5855 `d7989c0` Travis: run unit tests in different
> orders - #5852 `cdae53e` Reinitialize state in between individual
> unit tests. - #5883 `164d7b6` tests: add a BasicTestingSetup and
> apply to all tests - #5940 `446bb70` Regression test for
> ResendWalletTransactions - #6052 `cf7adad` fix and enable bip32
> unit test - #6039 `734f80a` tests: Error when setgenerate is used
> on regtest - #6074 `948beaf` Correct the PUSHDATA4 minimal encoding
> test in script_invalid.json - #6032 `e08886d` Stop nodes after RPC
> tests, even with --nocleanup - #6075 `df1609f` Add additional
> script edge condition tests - #5981 `da38dc6` Python P2P testing -
> #5958 `9ef00c3` Add multisig rpc tests - #6112 `fec5c0e` Add more
> script edge condition tests
>
> ### Miscellaneous - #5457, #5506, #5952, #6047 Update libsecp256k1
> - #5437 `84857e8` Add missing CAutoFile::IsNull() check in main -
> #5490 `ec20fd7` Replace uint256/uint160 with opaque blobs where
> possible - #5654, #5764 Adding jonasschnelli's GPG key - #5477
> `5f04d1d` OS X 10.10: LSSharedFileListItemResolve() is deprecated -
> #5679 `beff11a` Get rid of DetectShutdownThread - #5787 `9bd8c9b`
> Add fanquake PGP key - #5366 `47a79bb` No longer check osx
> compatibility in RenameThread - #5689 `07f4386` openssl: abstract
> out OPENSSL_cleanse - #5708 `8b298ca` Add list of implemented BIPs
> - #5809 `46bfbe7` Add bitcoin-cli man page - #5839 `86eb461` keys:
> remove libsecp256k1 verification until it's actually supported -
> #5749 `d734d87` Help messages correctly formatted (79 chars) -
> #5884 `7077fe6` BUGFIX: Stack around the variable 'rv' was
> corrupted - #5849 `41259ca` contrib/init/bitcoind.openrc:
> Compatibility with previous OpenRC init script variables - #5950
> `41113e3` Fix locale fallback and guard tests against invalid
> locale settings - #5965 `7c6bfb1` Add git-subtree-check.sh script -
> #6033 `1623f6e` FreeBSD, OpenBSD thread renaming - #6064 `b46e7c2`
> Several changes to mruset - #6104 `3e2559c` Show an init message
> while activating best chain - #6125 `351f73e` Clean up parsing of
> bool command line args - #5964 `b4c219b` Lightweight task
> scheduler - #6116 `30dc3c1` [OSX] rename Bitcoin-Qt.app to
> Bitcoin-Core.app - #6168 `b3024f0` contrib/linearize: Support
> linearization of testnet blocks - #6098 `7708fcd` Update Windows
> resource files (and add one for bitcoin-tx) - #6159 `e1412d3` Catch
> errors on datadir lock and pidfile delete - #6186 `182686c` Fix two
> problems in CSubnet parsing - #6174 `df992b9` doc: add translation
> strings policy - #6210 `dfdb6dd` build: disable optional use of gmp
> in internal secp256k1 build - #6264 `94cd705` Remove translation
> for -help-debug options - #6286 `3902c15` Remove berkeley-db4
> workaround in MacOSX build docs - #6319 `3f8fcc9` doc: update
> mailing list address
>
> Credits =======
>
> Thanks to everyone who directly contributed to this release:
>
> - 21E14 - Adam Weiss - Alex Morcos - ayeowch - azeteki - Ben
> Holden-Crowther - bikinibabe - BitcoinPRReadingGroup - Blake
> Jakopovic - BtcDrak - charlescharles - Chris Arnesen - Ciemon -
> CohibAA - Corinne Dashjr - Cory Fields - Cozz Lovan - Daira
> Hopwood - Daniel Kraft - Dave Collins - David A. Harding - dexX7 -
> Earlz - Eric Lombrozo - Eric R. Schulz - Everett Forth - Flavien
> Charlon - fsb4000 - Gavin Andresen - Gregory Maxwell - Heath - Ivan
> Pustogarov - Jacob Welsh - Jameson Lopp - Jason Lewicki - Jeff
> Garzik - Jonas Schnelli - Jonathan Brown - Jorge Timón - joshr -
> jtimon - Julian Yap - Luca Venturini - Luke Dashjr - Manuel Araoz -
> MarcoFalke - Matt Bogosian - Matt Corallo - Micha - Michael Ford -
> Mike Hearn - mrbandrews - Nicolas Benoit - paveljanik - Pavel
> Janík - Pavel Vasin - Peter Todd - Philip Kaufmann - Pieter Wuille
> - pstratem - randy-waterhouse - rion - Rob Van Mieghem - Ross
> Nicoll - Ruben de Vries - sandakersmann - Shaul Kfir - Shawn
> Wilkinson - sinetek - Suhas Daftuar - svost - Thomas Zander - Tom
> Harding - UdjinM6 - Vitalii Demianets - Wladimir J. van der Laan
>
> And all those who contributed additional code review and/or
> security research:
>
> - Sergio Demian Lerner
>
> As well as everyone that helped translating on
> [Transifex](https://www.transifex.com/projects/p/bitcoin/).
>
>
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev at 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
iQEcBAEBAgAGBQJVpkHzAAoJEGxwq/inSG8CYXQH/j+RkquHT6F+gjbST9eMNshI
9ydEnqL68o5FtZfRCdfrv3+GbXtsf7OFK9O/67denujiMR5OCQHCLZsV9bPpVrib
AsxVHzu+YWavjcyrlnKR4NAI9BUNNJzmsoBK2uD2c2niqT4CsbHMLssUuYXO3xM9
nKIlkn8ZZhbnJEJhM3UESh99KLPXqnKsmu++ZjGZdRnBPD1RGNbRuUCwqzUeij4L
Fyzj5X3UWFloF+oI9IGy7/wRYRrJ0k9q9NSJPU5Xv9RRZ63T4lv1phNMzYFzFve5
48HF+6+BSa+JUh4SihjEAuVNeHtPDMhZMCxkx/YTNDDjUL8UEFDKNc/xmx+ObFM=
=rpNr
-----END PGP SIGNATURE-----

2023-06-07 15:41:38

- reply

📅 Original date posted:2015-07-04
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Raystonn,
How would an average SPV wallet user know anything about this at all?
They might not know it is even happening, or if they have some idea
that something is wrong, then they wouldn't know what to do.
Say you use Electrum, some older version like 1.9. Electrum's current
version is 2.3.3. Or say you use a slightly older version like 2.2.
In any event, how is an end user possibly going to know which of
Electrum's (or any other SPV wallet's) versions are "the minimum
required for safety?" (so as to know they would need to upgrade
because problems)? Is this just something where it's really down to
community announcements on websites and reddits and the like?
On 07/03/2015 10:17 PM, Raystonn wrote:
> SPV clients are at risk in scenarios like this. We should encourage
> them to check node versions against the minimum required for
> safety. This check should be upgraded when new BIPs go into effect.
> It won't help against malicious nodes. But it will help in cases
> such as today's.
>
> On 3 Jul 2015 8:17 pm, Gregory Maxwell <gmaxwell at gmail.com> wrote:
>
> On Sat, Jul 4, 2015 at 3:11 AM, Raystonn <raystonn at hotmail.com>
> wrote:
>> We need some analysis on why this has happened. It appears the
> larger hashrate is violating BIP66. Thus it appears the network
> is rejecting this BIP, though potentially accidentally. If this is
> an accident, how is such a large portion of hashrate forking, and
> what can we do to avoid this in the future?
>
> A near majority of the hashrate on the network appears to be SPV
> mining.
>
> Btcnuggets was a non-upgraded miner that produced an invalid block
> after the lock in and f2pool and antpool have been extending it.
> Fortunately their extension contains no transactions (an artifact
> of SPV mining). Obviously a complete understanding is going to
> take some time; though I would note that this general failure mode
> was one we were aware of and is part of the reason the treshold is
> so high.
>
>
>
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev at 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
iQEcBAEBAgAGBQJVl3HCAAoJEGxwq/inSG8CXXIH/0s8o09UwRld+upM2pdAovMu
1SBCg/JeK3jXvqJDjyAbYe22WbnW8ykrZdujo1MFGuoZWbgrrSXo581lpyCy3O6c
SZYfAJee4eILzBl4MOwiAImcJBE3zOBCKT/DDaD1Qc8XvX6ReWJFYZgHsp/5F/BL
VlwVV9505V3X2G+y+3XOPwLggCu6m0MkRgeUjNTwdn+j6Yg6/NjJbS+YDDgjZ9dM
y3+uGA9Ek0bCLwjceUh8xAEwb+QUJrJgrNIo1vjuy+NRl18s1rUSx1YGTRkAD8eV
spdGTmXClx/phNnsR072hsqYRSj0CzhV8cQnEAh3ZmB4/RMhcxeNDmGw4rFNwD4=
=71aR
-----END PGP SIGNATURE-----

2023-06-07 15:41:37

- reply

📅 Original date posted:2015-07-04
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
"The Wall Street of Bitcoin"
On 07/03/2015 08:30 PM, Peter Todd wrote:
> On Sat, Jul 04, 2015 at 03:17:17AM +0000, Gregory Maxwell wrote:
>> On Sat, Jul 4, 2015 at 3:11 AM, Raystonn <raystonn at hotmail.com>
>> wrote:
>>> We need some analysis on why this has happened. It appears the
>>> larger hashrate is violating BIP66. Thus it appears the
>>> network is rejecting this BIP, though potentially accidentally.
>>> If this is an accident, how is such a large portion of hashrate
>>> forking, and what can we do to avoid this in the future?
>>
>> A near majority of the hashrate on the network appears to be SPV
>> mining.
>
> As for what "SPV mining" is:
>
> While blocks are propagating throughout the network, frequently
> it's possible for miners to get the header of the block before they
> get and fully validate the block itself. This is just a few seconds
> to tens of seconds, but that's a big deal for profitability. So
> miners have been running custom patches that mine on top of the
> longest chain they know about, even if they haven't actually
> verified the blocks in it due to propagation delays.
>
> Unfortunately the Bitcoin protocol lets you do that, and the extra
> % of revenue makes a big difference when you take into account the
> low profit margins of mining these days. BIP66 happened to trigger
> this issue this time, but actually *any* miner creating an invalid
> block for *any* reason would have done so with the software miners
> are running right now.
>
>
>
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev at 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
iQEcBAEBAgAGBQJVl1PeAAoJEGxwq/inSG8C2LAIAK9FbCODbTu2t2yktusv37Sd
zf5/ApqciZ01X4oiQHHKXIgzhYgNenv2dnRsBsrGtn53L1AopXOiSIcz8ECCYsjp
lwiKitebU7VukDlCu07ZQpff62Hm34lsqo2oXZHSC/lKYXD5llixgCmNrs2CTYrF
bWxCr2pngr+azDFX9hUSr6c48MO8Id8hdiWIcYwofNOcUACloqgJ/SaZZqT5OSXj
gk3Iq0ltTQdc71z7g8G1cqHfL/Nu47X0XnwVt8UAOn0b8bo3Hbz3QegPXoj1tik2
j8lJUqm3lwKdIky2i50OWxL/agaXou3jJy19jhziW5sRh3tkZfC4BbI+wazfRyk=
=dW9O
-----END PGP SIGNATURE-----

2023-06-07 15:41:26

- reply

📅 Original date posted:2015-07-01
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
(My replies below)
On 06/26/2015 06:47 AM, Tier Nolan wrote:
> On Thu, Jun 25, 2015 at 3:07 PM, Adam Back <adam at cypherspace.org
> <mailto:adam at cypherspace.org>> 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 at 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
iQEcBAEBAgAGBQJVlG5oAAoJEGxwq/inSG8C0r4H/0eklB9GxgHdl4LK7UoLeYYb
hlCiIJZ1+sRhTRIHrBtZO+nb2Uy3jLdqO9eOL4z9OXk3TCRBFwSdWrwsZXbzy3tC
5TmYlHvLSpfjiUxpP9JcO5E2VwFvB80pKkjPuUhwFVngh0HHsTA1IinUt52ZW1QP
wTdgKFHw3QL9zcfEXljVa3Ih9ssqrl5Eoab8vE2yr3p3QHR7caRLY1gFyKKIRxVH
YQangx6D33JcxyAcDNhYqavyt02lHxscqyZo6I4XUvE/aZVmSVTlm2zg7xdR7aCZ
0PlDwzpMD6Zk2QO/5qPPPos/5VETT0ompFK62go/hY2uB4cm+yZw3FFxR+Kknog=
=rtTH
-----END PGP SIGNATURE-----

2023-06-07 15:41:26

- reply

📅 Original date posted:2015-07-01
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Possibly relevant to this discussion (though old)
https://gist.github.com/gavinandresen/2355445 (last changed in 2012 I
think?)
and
https://bitcoin.stackexchange.com/questions/30817/what-is-a-soft-fork
(which cites gavin's gist shown above)
On 06/25/2015 05:42 PM, Milly Bitcoin wrote:
> That description makes sense. It also makes sense to separate out
> the hard fork from the soft fork process. Right now some people
> want to use the soft fork procedure for a hard fork simply because
> there is no other way to do it.
>
> I am under the impression that most users expect
> changes/improvements that would require a hard fork so I think some
> kind of process needs to be developed. Taking the responsibility
> off the shoulder of the core maintainer also makes sense. The hard
> fork issue is too much of a distraction for people trying to
> maintain the nuts and bolts of the underlying system.
>
> I saw a suggestion that regularly scheduled hard forks should be
> planned. That seems to make sense so you would have some sort of
> schedule where you would have cut off dates for hard-fork BIP
> submissions. That way you avoid the debates over whether there
> should be hard forks to what should be contained within the hard
> fork (if needed). It makes sense to follow the BIP process as
> close as possible. Possibly adding another step after "Dev
> acceptance" to include input from others such as
> merchants/exchanges/miners/users. It will only be an approximation
> of "decentralization" and the process won't be perfect but if you
> want to move forward then you need some way to do it.
>
> Russ
>
>
> On 6/25/2015 4:05 PM, Tier Nolan wrote:
>> On Thu, Jun 25, 2015 at 2:50 AM, Mark Friedenbach
>> <mark at friedenbach.org <mailto:mark at friedenbach.org>> wrote:
>>
>> I'm sorry but this is absolutely not the case, Milly. The reason
>> that people get defensive is that we have a carefully
>> constructed process that does work (thank you very much!) and is
>> well documented.
>>
>>
>> There is no process for handling hard forks, which aren't bug
>> fixes.
>>
>> Soft forks have a defined process of something like
>>
>> - BIP proposal + discussion - Proposed code - Dev acceptance -
>> Release - Miner vote/acceptance
>>
>> The devs have a weak veto. If they refuse to move forward with
>> changes, miners could perform a soft fork on their own. They
>> don't want to do that, as it would be controversial and the devs
>> know the software better.
>>
>> The miner veto is stronger (for soft forks) but not absolute.
>> The devs could checkpoint/blacklist a chain if miners implemented
>> a fork that wasn't acceptable (assuming the community backed
>> them).
>>
>> When ASICs arrived, it was pointed out by some that the devs
>> could hit back if ASICs weren't made publicly available. If they
>> slightly tweaked the hashing algorithm, then current generation
>> of ASICs would be useless. The potential threat may have acted
>> as a disincentive for ASIC manufacturers to use the ASICs
>> themselves.
>>
>> Moving forward with agreement between all involved is the
>> recommended and desirable approach.
>>
>> Consensus between all parties is the goal but isn't absolutely
>> required. This escape valve is partly what makes consensus work.
>> If you dig your heels in, then the other side can bypass you, but
>> they have an incentive to try to convince you to compromise
>> first. The outcome is better if a middle ground can be found.
>>
>> Hard forks are different. The "checks and balances" of weak
>> vetoes are not present. This means that things can devolve from
>> consensus to mutual veto. Consensus ceases to be a goal and
>> becomes a requirement.
>>
>> This is partly a reflection of the nature of hard forks.
>> Everyone needs to upgrade. On the other hand, if most of the
>> various groups upgrade, then users of the legacy software would
>> have to upgrade or get left behind. If 5% of the users decided
>> not to upgrade, should they be allowed to demand that nobody else
>> does?
>>
>> There is clearly some kind of threshold that is reasonable.
>>
>> The fundamental problem is that there isn't agreement on what
>> the block size is. Is it equal in status to the 21 million BTC
>> limit?
>>
>> If Satoshi had said that 1MB was part of the definition of
>> Bitcoin, then I think people would accept it to the same extent
>> as they accept the 21 million coin limit. It might cause people
>> to leave the coin though.
>>
>> It was intended to be temporary, but people have realized that
>> it might be a good idea to keep it. In effect both sides could
>> argue that they should be considered the status quo.
>>
>> I wonder if a coin toss would be acceptable :). "Come to an
>> agreement or we decide by coin toss"
>>
>>
>> _______________________________________________ bitcoin-dev
>> mailing list bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev at 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
iQEcBAEBAgAGBQJVlGrZAAoJEGxwq/inSG8C2wYH/3VZgzpbJrgprqNMDwWsMoxx
DFbgjQfOrHbVvAQebSlcH1FXPnzVZZSbxMlQAbDXr4lpREvMPQiomixCmkTTepob
zKhJu/bGYgLVqcXSDYuJTwCKgHfzTj02Q8D8ViFZdsPOHLIuhcAAq+KgioUHH+Ps
v2kWA48ePTHVxqNd79S2CKjk5Gyo99YIMAjbQOuC6DbW/y1hNmQP7iQPn6UUe4pY
qyLLDa6ccKvJslq3chXGK/alhGHZ5lyEYZY43qiL9cBEgqEn6kHC5gveqQxvXMvj
rOoZbAKCAc9GdlhUplRt5MhF35FTFvbaBTAq07/95Xo4C8DIhmXesHgmPtc1OqI=
=n7Pa
-----END PGP SIGNATURE-----

2023-06-07 15:39:48

- reply

📅 Original date posted:2015-06-23
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
1) Hard fork not (necessarily) needed
2) See Garzik's BIP 100, better (this is not meant to say "superior to
your stuff," but rather simply to say, "Better you should work with
Garzik to implement BIP-100, that would be good")
3) See points 1 and 2 above
4) If still reading... changes should be (as you seem to have been
trying to lean towards)... lean towards gradual change; hence, changes
that would flow from this BIP would be better off oriented in a
process that dies not require the "way you have done it."
You did address that, to be fair - in your TODO, this link:
http://gavinandresen.ninja/time-to-roll-out-bigger-blocks
contained the following link:
http://gavinandresen.ninja/bigger-blocks-another-way
However, in reading that, I didn't see any meaningful statements that
would refute the approach in Garzik's BIP-100.
Maybe a better way to say this is,
Work with Jeff Garzik (which I am sure you are already having such
discussions in private) as well as the list discussions,
Move forward on BIP-100 with Garzik and other developers (not such a
bad plan really) and don't get caught up in XT. (If you feel you can
develop XT further, that is your thing but it would perhaps make you
lose focus, work together with other developers.)
Relax into the process. Things will be ok.
Respectfully,
- -O
On 06/22/2015 11:18 AM, Gavin Andresen wrote:
> I promised to write a BIP after I'd implemented
> increase-the-maximum-block-size code, so here it is. It also lives
> at:
> https://github.com/gavinandresen/bips/blob/blocksize/bip-8MB.mediawiki
>
> I don't expect any proposal to please everybody; there are
> unavoidable tradeoffs to increasing the maximum block size. I
> prioritize implementation simplicity -- it is hard to write
> consensus-critical code, so simpler is better.
>
>
>
>
> BIP: ?? Title: Increase Maximum Block Size Author: Gavin Andresen
> <gavinandresen at gmail.com <mailto:gavinandresen at gmail.com>> Status:
> Draft Type: Standards Track Created: 2015-06-22
>
> ==Abstract==
>
> This BIP proposes replacing the fixed one megabyte maximum block
> size with a maximum size that grows over time at a predictable
> rate.
>
> ==Motivation==
>
> Transaction volume on the Bitcoin network has been growing, and
> will soon reach the one-megabyte-every-ten-minutes limit imposed by
> the one megabyte maximum block size. Increasing the maximum size
> reduces the impact of that limit on Bitcoin adoption and growth.
>
> ==Specification==
>
> After deployment on the network (see the Deployment section for
> details), the maximum allowed size of a block on the main network
> shall be calculated based on the timestamp in the block header.
>
> The maximum size shall be 8,000,000 bytes at a timestamp of
> 2016-01-11 00:00:00 UTC (timestamp 1452470400), and shall double
> every 63,072,000 seconds (two years, ignoring leap years), until
> 2036-01-06 00:00:00 UTC (timestamp 2083190400). The maximum size of
> blocks in between doublings will increase linearly based on the
> block's timestamp. The maximum size of blocks after 2036-01-06
> 00:00:00 UTC shall be 8,192,000,000 bytes.
>
> Expressed in pseudo-code, using integer math:
>
> function max_block_size(block_timestamp):
>
> time_start = 1452470400 time_double = 60*60*24*365*2 size_start =
> 8000000 if block_timestamp >= time_start+time_double*10 return
> size_start * 2^10
>
> // Piecewise-linear-between-doublings growth: time_delta =
> block_timestamp - t_start doublings = time_delta / time_double
> remainder = time_delta % time_double interpolate = (size_start *
> 2^doublings * remainder) / time_double max_size = size_start *
> 2^doublings + interpolate
>
> return max_size
>
> ==Deployment==
>
> Deployment shall be controlled by hash-power supermajority vote
> (similar to the technique used in BIP34), but the earliest possible
> activation time is 2016-01-11 00:00:00 UTC.
>
> Activation is achieved when 750 of 1,000 consecutive blocks in the
> best chain have a version number with bits 3 and 14 set (0x20000004
> in hex). The activation time will be the timestamp of the 750'th
> block plus a two week (1,209,600 second) grace period to give any
> remaining miners or services time to upgrade to support larger
> blocks. If a supermajority is achieved more than two weeks before
> 2016-01-11 00:00:00 UTC, the activation time will be 2016-01-11
> 00:00:00 UTC.
>
> Block version numbers are used only for activation; once activation
> is achieved, the maximum block size shall be as described in the
> specification section, regardless of the version number of the
> block.
>
>
> ==Rationale==
>
> The initial size of 8,000,000 bytes was chosen after testing the
> current reference implementation code with larger block sizes and
> receiving feedback from miners stuck behind bandwidth-constrained
> networks (in particular, Chinese miners behind the Great Firewall
> of China).
>
> The doubling interval was chosen based on long-term growth trends
> for CPU power, storage, and Internet bandwidth. The 20-year limit
> was chosen because exponential growth cannot continue forever.
>
> Calculations are based on timestamps and not blockchain height
> because a timestamp is part of every block's header. This allows
> implementations to know a block's maximum size after they have
> downloaded it's header, but before downloading any transactions.
>
> The deployment plan is taken from Jeff Garzik's proposed BIP100
> block size increase, and is designed to give miners, merchants,
> and full-node-running-end-users sufficient time to upgrade to
> software that supports bigger blocks. A 75% supermajority was
> chosen so that one large mining pool does not have effective veto
> power over a blocksize increase. The version number scheme is
> designed to be compatible with Pieter's Wuille's proposed "Version
> bits" BIP.
>
> TODO: summarize objections/arguments from
> http://gavinandresen.ninja/time-to-roll-out-bigger-blocks.
>
> TODO: describe other proposals and their advantages/disadvantages
> over this proposal.
>
>
> ==Compatibility==
>
> This is a hard-forking change to the Bitcoin protocol; anybody
> running code that fully validates blocks must upgrade before the
> activation time or they will risk rejecting a chain containing
> larger-than-one-megabyte blocks.
>
> Simplified Payment Verification software is not affected, unless
> it makes assumptions about the maximum depth of a transaction's
> merkle branch based on the minimum size of a transaction and the
> maximum block size.
>
> ==Implementation==
>
> https://github.com/gavinandresen/bitcoinxt/tree/blocksize_fork
>
>
>
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev at 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
iQEcBAEBAgAGBQJVigtJAAoJEGxwq/inSG8CqZwIAIG3ZQzekfccPxBOMqtim175
Crov6hrO9FaIzbLljECpUi60RKuDM/fs09ZJsKKIaJPkB5dlJjs4huc206veAIO+
K2h3DmAcA6W/Thk0C2cV3ewv+OiELDOhpeoddBBLPadAfaBGr4l9ltqWLdBtMCmw
OtmiWstEuXTao9ApgoFOmybdmCjbfrfhejOOHs/pMiSn5xVE60RK4x2HFTFsHfAN
fZAeLCuwuN2qWMrVrr+cbpCXjEuE1xZG3WEj7ppYoGR+AgF/Y5/U1j7S4PVpk85s
CgMkpcWvLnBMmSCrllnRZy1Gfrwk36Pg0rXD/l/NNd0/KTpmPSvkX/bCyzFwbzo=
=ft62
-----END PGP SIGNATURE-----

2023-06-07 15:39:38

- reply

📅 Original date posted:2015-06-23
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
ohai
On 06/22/2015 09:23 AM, Nathan Wilcox wrote:
> hello world.
>
> -- Nathan Wilcox Least Authoritarian
>
> email: nathan at leastauthority.com
> <mailto:nathan at leastauthority.com> twitter: @least_nathan PGP:
> 11169993 / AAAC 5675 E3F7 514C 67ED E9C9 3BFE 5263 1116 9993
>
>
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev at 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
iQEcBAEBAgAGBQJVigc+AAoJEGxwq/inSG8CJ80H/RCWzbiS1OBi1pPhC/0uRHFS
RAfXqmyvnjHomI4vfEKq0bocEEGW5BPDjD+bVuPlTbi3sBheaHkMJyjSBPcXBoH1
3V8sGVEl5lxt9/pbNMXEAyuCpXllI/EQmwXLkbDXwGclLWe+VUawLXLMj6p3r0w1
Z0JC1oidTZR2khnrLKsnTtymMznr5dOj1WDa7ej5m/xikhcADwJk22R9XmY1mf4L
LqYLnVtrXIhw7A0Xuc/E6v0BjBvlxGhHhkbxRC3DRj6U2eBeOpE610vuX86JGp6D
v6dfNyWnuQ3MPy0A5i7ZpGUIwPHEtV+w4+SHwN2QMrsHtQZnfqJirrhCKPOX3HY=
=zDQL
-----END PGP SIGNATURE-----

2023-06-07 15:39:17

- reply

📅 Original date posted:2015-06-20
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Peter,
Recently there was a brouhaha over Coinbase censoring the ability of
firearms businesses to accept bitcoins via Coinbase
https://www.reddit.com/r/Bitcoin/comments/3agbs7/coinbase_shuts_down_bit
coin_biz_for_firearms/
The question and relevance here to this is that for people who are
going for the alternate route (e.g., bailing on Coinbase / Bitpay /
similar web wallets, in favor of setting up with something like
Electrum and using Gear https://gear.mycelium.com/ as payment
processor or Straight
https://github.com/snitko/straight-server,
what would be the answer to "What does this mean for me?" for this topic
?
On 06/19/2015 03:39 AM, Peter Todd wrote:
> Yesterday F2Pool, currently the largest pool with 21% of the
> hashing power, enabled full replace-by-fee (RBF) support after
> discussions with me. This means that transactions that F2Pool has
> will be replaced if a conflicting transaction pays a higher fee.
> There are no requirements for the replacement transaction to pay
> addresses that were paid by the previous transaction.
>
>
> I'm a user. What does this mean for me?
> ---------------------------------------
>
> In the short term, very little. Wallet software aimed at average
> users has no ability to reliably detect conditions where an
> unconfirmed transaction may be double-spent by the sender. For
> example, Schildbach's Bitcoin Wallet for Android doesn't even
> detect double-spends of unconfirmed transactions when connected to
> a RBF or Bitcoin XT nodes that propagate them. The least
> sophisticated double-spend attack possibly - simply broadcasting
> two conflicting transactions at the same time - has about 50%
> probability of success against these wallets.
>
> Additionally, SPV wallets based on bitcoinj can't even detect
> invalid transactions reliably, instead trusting the full node(s) it
> is connected too over the unauthenticated, unencrypted, P2P
> protocol to do validation for them. For instance due to a unfixed
> bug¹ Bitcoin XT nodes will relay double-spends that spend the
> output of the conflicting transaction. I've personally tested this
> with Schildbach's Bitcoin Wallet for Android, which shows such
> invalid transactions as standard, unconfirmed, transactions.
>
> Users should continue to assume that unconfirmed transactions could
> be trivially reversed by the sender until the first confirmation.
> In general, only the sender can reverse a transaction, so if you do
> trust the sender feel free to assume an unconfirmed transaction
> will eventually confirm. However, if you do not trust the sender
> and/or have no other recourse if they double-spend you, wait until
> at least the first confirmation before assuming the transaction
> will go through.
>
> In the long term, miner support of full RBF has a number of
> advantages to users, allowing you to more efficiently make
> transactions, paying lower fees. However you'll need a wallet
> supporting these features; none exist yet.
>
>
> I'm a business. What does this mean for me?
> -------------------------------------------
>
> If you use your own node to verify transactions, you probably are
> in a similar situation as average users, so again, this means very
> little to you.
>
> If you use a payment processor/transaction API such as BitPay,
> Coinbase, BlockCypher, etc. you may or may not be accepting
> unconfirmed transactions, and they may or may not be "guaranteed"
> by your payment processor even if double-spent. If like most
> merchants you're using the API such that confirmations are required
> prior to accepting orders (e.g. taking a meaningful loss such as
> shipping a product if the tx is reversed) nothing changes for you.
> If not I recommend you contact your payment processor.
>
>
> I'm a miner. Why should I support replace-by-fee?
> -------------------------------------------------
>
> Whether full or first-seen-safe⁵ RBF support (along with
> child-pays-for-parent) is an important step towards a fully
> functioning transaction fee market that doesn't lead to users'
> transactions getting mysteriously "stuck", particularly during
> network flooding events/attacks. A better functioning fee market
> will help reduce pressure to increase the blocksize, particularly
> from the users creating the most valuable transactions.
>
> Full RBF also helps make use of the limited blockchain space more
> efficiently, with up to 90%+ transaction size savings possible in
> some transaction patterns. (e.g. long payment chains⁶) More users
> in less blockchain space will lead to higher overall fees per
> block.
>
> Finally as we'll discuss below full RBF prevents a number of
> serious threats to the existing level playing field that miners
> operate in.
>
>
> Why can't we make accepting unconfirmed txs from untrusted people
> safe?
> ----------------------------------------------------------------------
- -
>
> For a decentralized wallet, the situation is pretty bleak. These
> wallets only have a handful of connections to the network, with no
> way of knowing if those connections give an accurate view of what
> transactions miners actually know about.
>
> The only serious attempt to fix this problem for decentralized
> wallets that has been actually deployed is Andresen/Harding's
> double-spend relaying, implemented in Bitcoin XT. It relays up to
> one double-spend transaction per double-spent txout, with the
> intended effect to warn recipients. In practice however this
> functionality makes it easier to double-spend rather than harder,
> by giving an efficient and easy way to get double-spends to miners
> after the fact. Notably my RBF implementation even connects to
> Bitcoin XT nodes, reserving a % of all incoming and outgoing
> connection slots for them.
>
> Additionally Bitcoin XT's double-spend relaying is subject to
> attacks include bandwidth exhaustion, sybil attacks, and Gervais's
> non-sybil interactive attacks⁷ among many others.
>
>
> What about centralised wallets? -------------------------------
>
> Here the solutions being deployed, planned, and proposed are
> harmful, and even represent serious threats to Bitcoin's
> decentralization.
>
>
> Confidence factors ------------------
>
> Many services such as BlockCypher² have attempted to predict the
> probability that unconfirmed transactions will be mined, often
> guaranteeing merchants payment³ even in the event of a
> double-spend. The key component of these predictions is to sybil
> attack the P2P network as a whole, connecting to as many nodes as
> possible to measure transaction propagation. Additionally these
> services connect to pools directly via the getblocktemplate
> protocol, repeatedly downloading via GBT the lists of transactions
> in the to-be-mined blocks to determine what transactions miners are
> attempting to mine.
>
> None of these measures scale, wasting significant network and
> miner resources; in one instance a sybil attack by Chainalysis even
> completely blocked the users of the SPV wallet Breadwallet⁴ from
> accessing the network. These measures also don't work very well,
> giving double-spend attackers incentives to sybil attack miners
> themselves.
>
>
> Transaction processing contracts with miners
> --------------------------------------------
>
> The next step after measuring propagation fails is to contract
> with miners directly, signing contracts with as much of the hashing
> power as possible to get the transactions they want mined and
> double-spends rejected. The miners/pools would then provide an
> authenticated API endpoint for exclusive use of this service that
> would allow the service to add and remove specific transactions to
> the mempool on demand.
>
> There's a number of serious problems with this:
>
> 1) Mining contracts can be used to double-spend
>
> ...even when they're being used "honestly".
>
> Suppose Alice is a merchant using CoinPayCypher, who has contracts
> with 75% of the hashing power. Bob, another merchant, meanwhile
> uses a decentralized Bitcoin Core backend for payments to his
> website.
>
> Mallory wants to double-spend Bob's to buy his expensive products.
> He can do this by creating a transaction, tx1, that pays Alice,
> followed by a second transaction, tx2, that pays Bob. In any
> circumstance when Mallory can convince Bob to accept tx2, but
> prevent Bob from seeing tx1, the chance of Malory's double-spend
> succeeding becomes ~75% because CoinPayCypher's contracts with
> mining ensure the transaction paying Alice will get mined.
>
> Of course, dishonest use and/or compromise makes double-spending
> trivial: Malory can use the API credentials to ask miners to
> reject Bob's payment at any time.
>
>
> 2) They still don't work, without 51% attacking other miners
>
> Even if CoinPayCypher has 75% of the hashing power on contract,
> that's still a potentially 75% chance of being double-spent. The
> 25% of miners who haven't signed contracts have no _decentralized_
> way of ensuring they don't create blocks with double-spends, let
> alone at low cost. If those miners won't or can't sign contracts
> with CoinPayCypher the only next step available is to reject their
> blocks entirely.
>
>
> 3) Legal contracts give the advantage to non-anonymous miners in
> Western jurisdictions
>
> Suppose CoinPayCypher is a US company, and you're a miner with 1%
> hashing power located in northern China. The barriers to you
> succesfully negotiating a contract with CoinPayCypher are
> significant. You don't speak the same langauge, you're in a
> completely different jurisdiction so enforcing the legal contract
> is difficult, and being just 1%, CoinPayCypher sees you as
> insignificant.
>
> Who's going to get the profitable hashing power contracts first, if
> at all? Your English speaking competitors in the west. This is
> inherently a pressure towards centralization of mining.
>
>
> Why isn't this being announced on the bitcoin-security list first?
> ------------------------------------------------------------------
>
> I've had repeated discussions with services vulnerable to
> double-spends; they have been made well aware of the risk they're
> taking. If they've followed my own and others' advice they'll at
> minimum have constant monitoring of the rate of double-spends both
> on their own services and on the P2P network in general.
>
> If you choose to take a risk you should accept the consequences.
>
>
> How do I actually use full RBF? -------------------------------
>
> First get the full-RBF patch to v0.10.2:
>
> https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.10.2
>
> The above implementation of RBF includes additional code to find
> and preferentially connect to other RBF nodes, as well as Bitcoin
> XT nodes. Secondly, try out my replace-by-fee-tools at:
>
> https://github.com/petertodd/replace-by-fee-tools
>
> You can watch double-spends on the network here:
>
> http://respends.thinlink.com/
>
>
> References ----------
>
> 1) "Replace-by-fee v0.10.2 - Serious DoS attack fixed! - Also
> novel variants of existing attacks w/ Bitcoin XT and Android
> Bitcoin Wallet", Peter Todd, May 23rd 2015, Bitcoin-development
> mailing list,
> http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/
msg07795.html
>
> 2) "From Zero to Hero: Bitcoin Transactions in 8 Seconds", June
> 2nd, 2014, Erik Voorhees,
> https://medium.com/blockcypher-blog/from-zero-to-hero-bitcoin-transact
ions-in-8-seconds-7c9edcb3b734
>
> 3) Coinbase Merchant API, Accessed Jun 19th 2015,
> https://developers.coinbase.com/docs/merchants/callbacks#confirmations
>
> 4) "Chainalysis CEO Denies 'Sybil Attack' on Bitcoin's Network",
> March 14th 2015, Grace Caffyn, Coindesk,
> http://www.coindesk.com/chainalysis-ceo-denies-launching-sybil-attack-
on-bitcoin-network/
>
> 5) "First-Seen-Safe Replace-by-Fee", May 25th 2015, Peter Todd,
> Bitcoin-development mailing list,
> http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.ne
t/msg07829.html
>
> 6) "Cost savings by using replace-by-fee, 30-90%", May 25th 2015,
> Peter Todd, Bitcoin-development mailing list,
> http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/
msg07813.html
>
> 7) "Tampering with the Delivery of Blocks and Transactions in
> Bitcoin", Arthur Gervais and Hubert Ritzdorf and Ghassan O. Karame
> and Srdjan Capkun, Cryptology ePrint Archive: Report 2015/578, Jun
> 10th 2015, http://eprint.iacr.org/2015/578
>
>
>
> ----------------------------------------------------------------------
- --------
>
>
>
>
> _______________________________________________ Bitcoin-development
> mailing list Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
- --
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
iQEcBAEBAgAGBQJVhcdfAAoJEGxwq/inSG8CVxUH/1E7P/fuAaDaVMGexaW8MVRT
wEPx/sI1IU7S7UC5wXdcm9EufSK4smPLyPuW97LAPRIGnSvTF8BEYW+EW1hLtt0V
p9Vbj7+Ii5CJtarLebjeYKjiNSXF8h2p8oH+eeCjUygnzHt5Hsbc8R0aMRyPDJkT
lNQmzWGxN1rBTjTQZ+FDA2E2AA1Dkv7UXL15MwudxLOCUONTMh3uwUKC5dz9HE+5
dz3iZWx879VLuaQscDz65FBf5axSKFjL+RGkIuPLF8B1ybsSl0ZYEctmPIv5Ld4V
w0bw+oABCFvCKbINdUY+VOdXogDXJDVmCaY/Bbu6sPoZcr0FmHrvHd9KfngjkR4=
=7W68
-----END PGP SIGNATURE-----

2023-06-07 15:38:45

- reply

📅 Original date posted:2015-06-18
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I maintain that you should apologize to those who traverse this list.
What you are saying is digging yourself a deeper hole and is not
merely embarrassing but is crossing a threshold in which you have used
words, albeit subtly, to attack a community.
If you refuse to apologize, I get it. You have not apologized thus
far, and pressing for an apology is unlikely to get an (authentic)
one. But then, you should voluntarily step back and let others do the
hard work of coming to the consensus that you seem to think is
impossible to accomplish based on how bitcoin is run.
I believe this matter will be resolved, but not with the "help" of
those who make threatening statements (and who are unable to apologize
for having made them).
- -O
On 06/18/2015 03:00 AM, Mike Hearn wrote:
> Dude, calm down. I don't have commit access to Bitcoin Core and
> Gavin already said long ago he wouldn't just commit something, even
> though he has the ability to do so.
>
> So why did I say it? Because it's consistent with what I've always
> said: you cannot run a codebase like Wikipedia. Maintainers have to
> take part in debates, and then make a decision, and anyone else who
> was delegated commit access for robustness or convenience must then
> respect that decision. It's the only way to keep a project making
> progress at a reasonable pace.
>
> This is not a radical position. That's how nearly all coding
> projects work. I have been involved with open source for 15 years
> and the 'single maintainer who makes decisions' model is normal,
> even if in some large codebases subsystems have delegated
> submaintainers.
>
> This is also how all my own projects are run. Bitcoinj has
> multiple people with commit access. Regardless, if there were to be
> some design dispute or whatever, I wouldn't tolerate the others
> with commit access starting some kind of Wiki-style edit war in the
> code if they disagreed. Nor would I ever expect to get my own way
> in other people's projects by threatening to revert the maintainers
> changes.
>
> Core is in the weird position where there's no decision making
> ability at all, because anyone who shows up and shouts enough can
> generate 'controversy', then Wladimir sees there is disagreement
> and won't touch the issue in question. So it just runs and runs and
> /anyone/ with commit access can then block any change.
>
> I realise some people think this anti-process leads to better
> decision making. I disagree. It leads to no decision making, which
> is not the same thing at all.
- --
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
iQEcBAEBAgAGBQJVg0HiAAoJEGxwq/inSG8CXOwIAKSGRJPtSx+untgMERwE7lW7
9p0gWz4jvKhyO+RrGPXlofckvp4Fp/7Yxa+TDLcXbzGi6OesX9yIyN7e06LJW4DP
h7V2PwzS49ZyB/krd03HjvWMFnhoGy7zB7M1okq5myIvx+h1htX9TirNbDl7PU9Z
SWyNNw+GXPsIV/xuPu81LP5GrR3gIxwwhhopOq2qcm08AUiuIJ8EA31mT2ZgwMWB
RxrnktFRzMbW2fD7Z7njTz1gjw1duPyGApJ+xpqtcjjS2idPNuw1nESZTCE3+TwG
Dk1AKmYt8TvZzFWyo/0ly7vYFFW27Yh7SC3oeDJBoWkvySuIFrevux7ekfKxPOc=
=wc2m
-----END PGP SIGNATURE-----

2023-06-07 15:38:43

- reply

📅 Original date posted:2015-06-18
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Regarding this proposal from Mike Hearn to remove consensus process
from the BIP, which I think is unsound philosophy. I will address
this briefly below.
On 06/18/2015 09:05 AM, Mike Hearn wrote:
> So then: make a proposal for a better process, post it to this
> list.
>
>
> Alright. Here is a first cut of my proposal. It can be inserted
> into an amended BIP 1 after "What belongs in a successful BIP?".
> Let me know what you think.
>
>
>
> The following section applies to BIPs that affect the block chain
> consensus rules or the peer to peer protocol and thus require
> changes to Bitcoin Core.
>
> Once a draft BIP has been submitted to bitcoin-development for
> consideration, the Bitcoin Core maintainer will deliver a
> preliminary yes/no verdict within three weeks.
For many things, that will simply be too fast. It is better to allow
the primary maintainer to collaborate with other people who normally
work on the code and determine what the schedule will be based on
life, volume of work, and so on.
> This verdict may be informed by the debate that has taken part in
> the previous three weeks. If more time is required, the maintainer
> is required to request an extension from the BIP author, who may
> then elect to force an immediate decision (risking a no), or
> choosing to allow more time.
Again, this three week thing doesn't work. But assume for a moment
that there is a certain amount of time that is such and so and it is
set by the maintainer. The notion that the maintainer would be
"required" to request an extension from the BIP author is sheer
lunacy. There is no need to codify the actions of the project
maintainer such that he/she would be needing to be subject to the
whims of whatever BIP author. In like manner, a BIP author should not
have to be subject to forever delay of a BIP due to inaction of a
maintainer, but should have an answer regarding whether it can be
assigned a number, published as draft and so forth after a reasonable
time. To me, a "reasonable time" is something that should be
discussed amongst the maintainer, those who work regularly on code,
and the BIP author.
>
> The verdict will meet the following criteria:
>
> * It will address the latest version of the BIP at the time the
> verdict is rendered.
>
> * In case of a rejection, it will spell out and describe the
> technical rationale for this decision. Opinions held by other
> people are not considered technical rationales: if the maintainer
> agrees with a technical point made during discussion, he must own
> that opinion for himself. Therefore no BIP will be rejected on
> grounds of controversy, disagreement, lack of consensus or
> otherwise.
No, this is ridiculous, because the notion that "no BIP will be
rejected on grounds of controversy, disagreement, lack of consensus,
or otherwise," is clearly an attempt to do away with consensus models
of business, and it is also not a very logical statement because
controversy and disagreement are a natural part of... coming to what
eventually is an agreement.
>
> * In case of rejection, the maintainer will provide a clear,
> specific list of actionable steps the BIP author can take next. For
> example, a list of what changes would address the technical
> objections raised.
This above section I agree with.
In case the maintainer believes no change could ever make
> the BIP acceptable, the list must consist of instructions for how
> to create a patch set and, in the case of changes to the consensus
> rules, how to initiate a hard fork.
This above section I do not agree with because of the obvious bias in
favor of the hard fork. Everything here seems to be aligned to push
for hard fork, hard fork, hard fork. It's like the author can't tear
his mind off it.
>
> A BIP, even once rejected, may live on in the BIPS repository,
> though its entry in the index may be sorted below others. The BIP
> author may update the BIP with a summary of any resulting
> discussion. As such a summary may be inherently contentious in case
> of a dispute, the authors wording of that summary is final and may
> not be subject to meta-debate.
>
>
This doesn't seem right at all.
>
>
> ----------------------------------------------------------------------
- --------
>
>
>
>
> _______________________________________________ Bitcoin-development
> mailing list Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
- --
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
iQEcBAEBAgAGBQJVg0sHAAoJEGxwq/inSG8CuFcH/0tzRWWyy3wmDegNx463xoaq
EhG/dNqoIvavMlyJrKfKWPK6Mndgo9BtxkYbvOlO40Y51SW4SaisWGzHRg4HyIbJ
0Orp+C0jXhvnrJ7hRwKhrdZQUIRAI19NLVthSb9W6mHnXWJC8ilhlK9Ei9ILRjGl
tM5pZ28SkyJ/b+CnltnYW8t6AvE4zlggC4QsCuUwA2cFoFWjQeESpqjy4kJNv464
yKlsrqoIzs2vNnoLIx1B0aLX9mNTQUwB1yMXtu8IVcAQe/G1LEEnNO56LGf8O0yJ
KcBTSpDAtCxvfkwtr3DS6LtCzXcej974NW068n/92zZIKzsdcZk/o3O5ZxEO7Wg=
=YwvU
-----END PGP SIGNATURE-----

2023-06-07 15:38:35

- reply

📅 Original date posted:2015-06-18
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Regarding the bit on "getting out in front of the need, to prevent
significant negative impacts to users" I had suggested the following:
On 06/18/2015 03:52 PM, Jeff Garzik wrote:
> On Thu, Jun 18, 2015 at 3:33 PM, Mark Friedenbach
> <mark at friedenbach.org <mailto:mark at friedenbach.org>> wrote:
>
> On Thu, Jun 18, 2015 at 2:58 PM, Jeff Garzik <jgarzik at bitpay.com
> <mailto:jgarzik at bitpay.com>> wrote:
>
>
> The whole point is getting out in front of the need, to prevent
> significant negative impact to users when blocks are consistently
> full.
My thoughts on that:
Possible scope narrowing to one of the following concepts (but please,
someone tell me if this "scope narrowing" is unwise, not timely, or if
there is some other factors that would make it just stupid right now
because other things are in the works or whatever:
~ Jeff Garzik, with respect to his BIP 100 (note Evan Mo, CEO of
Huobi's mining project Digcoin, clarified that the big Chinese mining
pools consider further adjustments to the protocol beyond the
suggested 8 MB block size limit adjustment — such as the Bitcoin core
developer Jeff Garzik's BIP-100 draft — to be feasible)
~ Adam Back, with a simplified soft-fork one-way peg
~ Gavin Andresen, developing an 8 MB block size limit adjustment in
the context of Core (as an example) with one or more of the above
authors rather than focusing on XT. (This is a big assumption but,
roll with it)
All of this assumes that developer(s) are willing to abandon
intentionally contentious proposals such as the "hard fork to XT w/ 20
MB," remain within the context of Core and be reasonable.
Here I am being aware of the fact that "Pushing a hard fork in the
face of such controversy is a folly, a danger to the network, and that
deserves to be said." - Wladimir J. van der Laan
https://github.com/bitcoin/bitcoin.org/pull/894#issuecomment-112113917
>
> To do that, you need to (a) plan forward, in order to (b) set a
> hard fork date in the future.
>
>
> Or alternatively, fix the reasons why users would have negative
> experiences with full blocks, chiefly:
>
> * Get safe forms of replace-by-fee and child-pays-for-parent
> finished and in 0.12. * Develop cross-platform libraries for
> managing micropayment channels, and get wallet authors to adopt *
> Use fidelity bonds, solvency proofs, and other tricks to minimize
> the risk of already deployed off-chain solutions as an interim
> measure until: * Deploy soft-fork changes for truly scalable
> solutions like Lightning Network.
>
> Not raising the block size limit does not mean doing nothing to
> solve the problem.
>
>
> This is a long, unreasonable list of work. None of this exists and
> it equates to "upgrade all wallets and websites everywhere" It
> requires all exchanges, payment processors, merchants, etc. to -
> basically everybody but miners - to update.
>
> It is a far, far larger amount of work to write, test and deploy
> than simply increasing the block size limit.
>
> Think through roll-out of these ambitious suggestions, before
> suggesting as an alternative!
>
> Not a realistic alternative except in an alternate universe where
> (a) developer work at all companies is cost free, plus (b) we can
> pause the business universe while we wait for The Perfect
> Solution.
>
>
>
Something else I wanted to point out here in this thread is the
subject of the problem of "developers going off the deep end" which is
what started this thread:
Suppose you have a developer with full commit access who happens to
start threatening to revoking the other developers' commit access on
the repository, or that person doesn't even threaten, one day it just
happens.
What do you have then? Peter Todd has stated that all one "would
achieve by that sabotage is setting a key-value pair in a centralised
registry." But is that what we want?
The answer, obviously, is no.
This leads to other questions. What technical mechanisms exist to keep
developers from (in some dubious emotional or psycho state) to just
going off the deep and doing exactly what has been described above, if
they have full commit access? Is there a process whereby that can't
actually happen unless another developer provides a signature (e.g. a
multisignature type of process)? What keeps bitcoin safe from "The
Hearn Threat?"
If nothing does, then how would you change that?
And go ahead and tell me if these are dumb questions and I should just
be quiet, but if they are, please do explain why they are such dumb
questions.
>
>
>
>
>
>
>
> -- Jeff Garzik Bitcoin core developer and open source evangelist
> BitPay, Inc. https://bitpay.com/
>
>
> ----------------------------------------------------------------------
- --------
>
>
>
>
> _______________________________________________ Bitcoin-development
> mailing list Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
- --
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
iQEcBAEBAgAGBQJVg1OFAAoJEGxwq/inSG8COpAIAJrH9Uj9bcKr+UUR7ePV6/Yj
MmNTY2VKAtiQhwHM+Mqk2VvQANs7/uRBdZjzGnw1NRcca/m8Q0yZUHQiP8avCUOE
3MHqGviYjfeJdu1pcf+PO2pAImM5FCFdrfbbiWUt+ZoOKTxZjsLtF4RE+mc13AXJ
dktvy6SFdvQUgEx8pdXEDpmaUSYUr7syFP4sgHZmyMlhvCsXyE/8dC3sZTzEpVnC
xy1dyBmXHPW3W4FfBSblwwWgJWMcIcGJn8OLQKK5pni/iSVL6IMoRI/MLwOJdRr4
lr83g9FR/qxMqAT9UIZtATnePlkkWPU1szvak/tU/49fGioyYOF4b4KPg/bHYSc=
=hBcE
-----END PGP SIGNATURE-----

2023-06-07 15:38:26

- reply

📅 Original date posted:2015-06-18
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Recently I saw the following video:
https://www.youtube.com/watch?v=8JmvkyQyD8w&t=47m58s
Hadn't seen it until just today, although it was done on June 8, 2015.
So this is a bit dated, but to me it was a bit of a stunner to see the
extreme nature of (some) of the views presented in this video.
Let me be blunt, I have serious concerns regarding threats issued by a
developer in this video, and I think that it is entirely possible that
those of you who are core developers have already seen this and have
been discussing it. But I am interested in seeing this resolved here
on this list openly and having it resolved. It's sad and unfortunate
to me, but I feel that it's necessary to do this. Identify what's
happening, address it squarely, have the person who is threatening
others explain his/her behavior, deal with the problem and move on.
This seems to be very important. Please tell me if I am wrong about
this or totally flawed in my perspective here. Go right ahead.
In this video, a particular developer makes the following statement,
stating in part:
"My preferred solution is that Gavin revokes commit access from
everyone else in the project, and then... makes the change himself"
Regardless of how you look at this, and even if we believe that Gavin
will not respond to that developer's request for a so-called
"solution," such a statement (by any developer) is indeed both a
threat and an act of sabotage against the larger bitcoin community.
We should certainly be thankful therefore, for the recent policy
change at bitcoin.org which can be seen here:
https://cloud.githubusercontent.com/assets/61096/8173297/578483f8-1399-1
1e5-8f48-96f33d12b996.png
I firmly believe that any developer who made a statement suggesting
that commit access of others in the project be revoked so that they
can proceed with their personal plan, needs to answer for having made
such a suggestion with a formal apology to this list, followed by an
explanation for why they themselves should not have their commit
access removed.
Overall, however, this sort of bombastic, nuclear suggestion makes me
seriously concerned for the future of bitcoin (as well as any
cryptocurrency which has repositories on Github).
So, you know who you are: Apologize for your statement ("preferred
solution") and explain to the community why you should still have
commit access in light of the threat you have made to all the other
developers (and indeed to all participants of the bitcoin community).
These "nuclear options" are unacceptable to us all.
Respectfully,
- -O
- --
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
iQEcBAEBAgAGBQJVgoc3AAoJEGxwq/inSG8C6QYH/1Ag+4ESTSUPkP8PCTj1AJds
J4MmBz4cX7IYsSttTAjyiwd6oTHCU+wAcXtgZYpzr8rWF62bG5/+kAFUfjKwNsGM
WqcdNOR6h8fQulx8niuro8kZF/xOsG5eHtRK2FMCorxj0t6qn4pH5WAQL73J3hXQ
xI831Nt/L7VTa0jlKbr2/VGlqh6CtGrZ9mXp6aV1MBNwHbFryNBJW9ubvUv/IRxZ
GyJ+c3+Br2KKAQTMsyNn3VXMlXJL6kt0pwwk2od3j/+dKE4pAetHvZ5OgIO+qUWd
6R0/AaoW5jk343TaQ5BHaSpNW+OM9Yc1ycZyqE/YV8JwWeA6G/QdmRVYeoLMCZQ=
=zJeO
-----END PGP SIGNATURE-----

2023-06-07 15:38:25

- reply

📅 Original date posted:2015-06-18
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
The purpose of this post is to present an inquiry related to the
possible narrowing of scope of what sort of proposals are likely to
"bear fruit" at this stage. The inquiry or question is, "Are there
some proposals that are more likely to succeed, in addressing the
whole block size limit debate meaningfully?"
The flip side of this inquiry, is that if you think that an attempt to
do such "scope narrowing" _at this time_ is foolhardy, inappropriate,
wrong, or otherwise flawed, please say so and explain. I'm not
religious about this notion. I throw out proposals below which I
think would be likely to advance further ~ and thus I ask the question
again, and rephrase, "Are there some proposals (some shown below as
examples, not all-inclusive) that are more likely to succeed, in
addressing the whole block size limit debate meaningfully?"
~ Jeff Garzik, with respect to his BIP 100 (note Evan Mo, CEO of
Huobi's mining project Digcoin, clarified that the big Chinese mining
pools consider further adjustments to the protocol beyond the
suggested 8 MB block size limit adjustment — such as the Bitcoin core
developer Jeff Garzik's BIP-100 draft — to be feasible)
~ Adam Back, with a simplified soft-fork one-way peg
~ Gavin Andresen, developing an 8 MB block size limit adjustment in
the context of Core (as an example) with one or more of the above
authors rather than focusing on XT. (This is a big assumption but,
roll with it)
All of this assumes that developer(s) are willing to abandon
intentionally contentious proposals such as the "hard fork to XT w/ 20
MB," remain within the context of Core and be reasonable.
Here I am being aware of the fact that "Pushing a hard fork in the
face of such controversy is a folly, a danger to the network, and that
deserves to be said." - Wladimir J. van der Laan
https://github.com/bitcoin/bitcoin.org/pull/894#issuecomment-112113917
And if I'm lucky, this thread may get comments from DumbFruit, who
writes stuff like this:
https://bitcointalk.org/index.php?topic=1085436.msg11643203#msg11643203
So now... your thoughts?
- --
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
iQEcBAEBAgAGBQJVgnLuAAoJEGxwq/inSG8CchMH/0zm+A7Uqp8SpU+CsJr3lF2+
0re+5Ql4qVVmOI560918BtkdFjcq33jsKU9cYUDXqZ4wHfJTAGLGDqNgUZGpGkmJ
bqGgSvdF64P52Vb9PVnz1I9+aClas8Mjvl8XUYoD0yEA14XVBakYDRbVqZ5yPM8n
hBi6EpWLUnkFvvEj2dkgwddvPCvrnhVL/aRfmhet1pfOELfIrXtXI7hs2F1RyaqK
sbR/Qg3SFlyHzbxSzRVcZQ0G81exq/fxHqxc5kSLMiR7TODIJxCl6cJDCjf8LbeS
n6tL/I8vWN2zraYfb0cWu5uIjz5XnXpsitu951109zoS8IYle3uTfCF+6xdG3tY=
=HQ9R
-----END PGP SIGNATURE-----

2023-06-07 15:38:24

- reply

📅 Original date posted:2015-06-17
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Peter, my response below
On 06/16/2015 10:46 AM, Peter Todd wrote:
> On Tue, Jun 16, 2015 at 09:26:07AM -0700, odinn wrote:
>> This is very well done.
>>
>> Have you seen this discussion that I started regarding BIP 63?
>>
>> https://bitcointalk.org/index.php?topic=1083961.0
>>
>> I have no response from Peter Todd back on it other than "my time is
>> better spent focusing on more fundemental issues" and "I've also got
>> no-one interested in funding stealth address development right now,"
>> when several people (myself included) offered to send donations to se
e
>> the BIP (63) advance, no donation address was posted, so... waiting
>> for him to act on that.
>
> Sorry, but I'm looking at the huge amount of work that I'll likely hav
e
> responding to the blocksize issue, so I think I'm inclined to shelve
> work on BIP63 for now.
I seriously find this pretty sad... you said that paying rent was an
issue and your time was better spent on "more fundamental issues..." but
the very least you could do is post a donation address... Is there
someone who was working with you closely on the concept who could take
it up since you are not going to be working on it?
>
> Feel free to take it up; a (>=2)-part standard describing the resuable
> codes aspect, and separately how the ephemeral key is transmitted to t
he
> recipient makes sense to me.
>
I don't want to camp on Justus's thread on reusable payment codes ~ but
on the subject of BIP 63, it just did make sense to mention... so if
someone does have interest in working on it... please go to
https://bitcointalk.org/index.php?topic=1083961.0
and reply there.
- --
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
iQEcBAEBAgAGBQJVgQbMAAoJEGxwq/inSG8CD8gH/3jV+mLO9qv3t6JFxIvLMPtr
slGbymQtuqfAC09b6ybx3p6u9I1o1Nb3IgK1riu/Z3AzHxlnuYVUxN3N5ns0zGnx
F2WXs2suEa20YJkQ6dxZWLdNBjnUIEGGgXAit8X21LqVsqPfeZcocOWSeRDlePhk
/HRFLVtMehqfqjbuFAaAewVZUyT4Bn+3IU74krqR3e3YA00/ym1C5xCE3/kHvKIL
UF8EW9GgVYKuoyQdH3ICDwjiudwPOwIC4Ry0huaJgla43122RkwqYB+5kVr1583u
dx3VW8vW8HyQZJF+vb8d3F57R6FC6zYtFhCe0IzDIh+6xQxStk5zosMNIrtPKp4=
=h8Ib
-----END PGP SIGNATURE-----

2023-06-07 15:38:24

- reply

📅 Original date posted:2015-06-16
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
This is very well done.
Have you seen this discussion that I started regarding BIP 63?
https://bitcointalk.org/index.php?topic=1083961.0
I have no response from Peter Todd back on it other than "my time is
better spent focusing on more fundemental issues" and "I've also got
no-one interested in funding stealth address development right now,"
when several people (myself included) offered to send donations to see
the BIP (63) advance, no donation address was posted, so... waiting
for him to act on that.
I'm definitely supportive of seeing what you've written up here as
Reusable payment codes move to draft in https://github.com/bitcoin/bips
When you can, please write up something on bitcointalk as well.
On 04/24/2015 01:00 PM, Justus Ranvier wrote:
> Hash: SHA1
>
>
> https://github.com/justusranvier/rfc/blob/payment_code/bips/bip-pc01.m
ediawiki
>
>
>
> This link contains an RFC for a new type of Bitcoin address called
> a "payment code"
>
>
> Payment codes are SPV-friendly alternatives to DarkWallet-style
> stealth addresses which provide useful features such as positively
> identifying senders to recipients and automatically providing for
> transaction refunds.
>
>
> Payment codes can be publicly advertised and associated with a
> real-life identity without causing a loss of financial privacy.
>
>
> Compared to stealth addresses, payment codes require less
> blockchain data storage.
>
>
> Payment codes require 65 bytes of OP_RETURN data per
> sender-recipient pair, while stealth addresses require 40 bytes per
> transaction.
>
>
>
>
>
> ----------------------------------------------------------------------
- --------
>
>
One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable
> Insights Deep dive visibility with transaction tracing using APM
> Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>
>
>
> _______________________________________________ Bitcoin-development
> mailing list Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
- --
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
iQEcBAEBAgAGBQJVgE4fAAoJEGxwq/inSG8CjgkH/i0aX4aJaOjrbI2xzWbPeL1T
/APSvSqV0D610ljbw/MuRRFVagnK3lCs73fYolKw9uFG0cnwhIWJ53mCqPWhM5nL
kIejDTHr9jQ2tbXrU2L481Oat1Z6vtdQj7LolXFfD3Ktqz+sqp//gBaC9EEZ5nOq
4oz71Am58pf8+XGhtJk0+4XDXzFNd71bKKY+nMf9f3bwqNX93jHiF48hXwijFPC4
MOZmYRh3Sf5LAVP5p1JY3aJRQv4M/W0L2RDC+GW8Ol997etQSGGLhESihNNPw1m8
GEqJLBmUBkavzsRpZ009czfzL7EiCwsMbOrVw918o2Y9NnVpY9a9cBNB+UJgCmk=
=wAGz
-----END PGP SIGNATURE-----

2023-06-07 15:38:18

- reply

📅 Original date posted:2015-06-15
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Mike,
To sum it up, you are saying "bitcoin will break and many of our users
will leave therefore OMG WTF so we have to do what GAVIN AND ME want
to do to hardfork to XT which is the ONLY WAY, so GTFO!"
And so, no. We don't have to accept that attitude.
There are other proposals that actually would work here.
Cameron Garnham's dynamic block size adjustment (needing soft fork
only) mentioned here http://www.twitlonger.com/show/n_1smkanp
Jeff Garzik's proposals (rewritten and published as a BIP)
http://bitcoin-development.narkive.com/f5FMeA4D/comments-on-bip-100
and more.
I also disagree with the notion that everybody's just ok with what
Mike and Gavin are doing.... specifically, this statement by Mike
> The consensus you seek does exist. All wallet developers (except
> Lawrence), all the major exchanges, all the major payment
> processors and many of the major mining pools want to see the limit
> lifted
was kind of twisting things, because it made it sound like everybody
supports Gavin's proposal to hard fork to XT, which these folks don't.
Example:
1)
http://cointelegraph.com/news/114481/chinese-exchanges-reject-gavin-andr
esens-20-mb-block-size-increase
2) https://twitter.com/GreenAddress/status/605037073725313024
This isn't to say they don't want to see a limit adjusted but not in
the way that Gavin (and you, Mike) are proposing - not through this
hard fork to XT.
So go roll out your code for whatever it is you are going to put into
XT and make a BIP, but stop saying that everyone supports it when
obviously they don't and you don't even have something yet and there
are already superior alternatives that don't involve Gavin's hard fork
and your blessed XT.
On 06/15/2015 02:56 AM, Mike Hearn wrote:
> Hi Adam,
>
> Provisional answers below!
>
> - Are you releasing a BIP for that proposal for review?
>
>
> The work splits like this:
>
> * Gavin is writing the code and I think a BIP as well
>
> * I will review both and mostly delegate to Gavin's good taste
> around the details, unless there is some very strong disagreement.
> But that seems unlikely.
>
> * I have been handling gitian and the patch rebases, the code
> signing and so on, so far. I've also been doing some work to setup
> the basic infrastructure of the project (website etc).
>
>
> - If the reviewers all say NACK will you take on board their
> suggestions?
>
>
> Feedback will be read. There are no NACKS in Bitcoin XT. Patch
> requests aren't scored in any way. The final decision rests with
> the maintainer as in ~all open source projects.
>
>
>
> - On the idea of a non-consensus hard-fork at all, I think we can
> assume you will get a row of NACKs. Can you explain your
> rationale for going ahead anyway? The risks are well understood
> and enormous.
>
>
> Yes, I have been working on an article that explains how we got to
> this point from my perspective. It is quite long, but only because
> I want it to be readable for people who weren't following the
> debate.
>
> Anyway, I think I've laid out the gist of it over and over again,
> but to summarise:
>
> If Bitcoin runs out of capacity *it will break and many of our
> users will leave*. That is not an acceptable outcome for myself or
> the many other wallet, service and merchant developers who have
> worked for years to build an ecosystem around this protocol.
>
>
>
> - How do you propose to deal with the extra risks that come from
> non-consensus hard-forks? Hard-forks themselves are quite risky,
> but non-consensus ones are extremely dangerous for consensus.
>
>
> The approach is the same for other forks. Voting via block versions
> and then when there's been >X% for Y time units the 1mb limit is
> lifted/replaced.
>
>
>
>
> - If you're going it alone as it were, are you proposing that you
> will personally maintain bitcoin-XT? Or do you have a plan to
> later hand over maintenance to the bitcoin developers?
>
>
> Good question! I have various thoughts on this, but let's wait and
> see what happens first. Perhaps the new chain won't get the
> majority on it.
>
> In the event that the >1mb chain does eventually win, I would
> expect Core to apply the patch and rejoin the consensus rather than
> lose all its users. That would take XT back to being a fairly small
> patchset to improve the network protocol.
>
>
>
> - Do you have contingency plans for what to do if the
> non-consensus hard-fork goes wrong and $3B is lost as a result?
>
>
> Where did you get the $3B figure from? The fork either doesn't
> happen, or it happens after quite a long period of people knowing
> it's going to happen - for example because their full node is
> printing "You need to upgrade" messages due to seeing the larger
> block version, or because they read the news, or because they heard
> about it via some other mechanisms.
>
> Let me flip the question around. Do you have a contingency plan if
> Bitcoin runs out of capacity and significant user disruption occurs
> that results in exodus, followed by fall in BTC price? The only one
> I've seen is "we can perform an emergency hard fork in a few
> weeks"!
>
>
>
> As you can probably tell I think a unilateral fork without
> wide-scale consensus from the technical and business communities is
> a deeply inadvisable.
>
>
> Gavin and I have been polling many key players in the ecosystem.
> The consensus you seek does exist. All wallet developers (except
> Lawrence), all the major exchanges, all the major payment
> processors and many of the major mining pools want to see the limit
> lifted (I haven't been talking to pools, Gavin has).
>
> This notion that the change has no consensus is based on you
> polling the people directly around you and people who like to spend
> all day on this mailing list. It's not an accurate reflection of
> the wider Bitcoin community and that is one of the leading reasons
> there is going to be a fork. A small number of people have been
> flatly ignoring LOTS of highly technical and passionate developers
> who have written vast amounts of code, built up the Bitcoin user
> base, designed hardware and software, and yes built companies.
>
> How do you think that makes Bitcoin Core look to the rest of the
> Bitcoin world? How much confidence does that give people?
>
>
>
> Of the overall process, I think you can agree we should not be
> making technical decisions with this level of complexity and
> consensus risk with financial implications of this magnitude under
> duress of haste?
>
>
> This debate will never end until a fork makes it irrelevant. There
> is no process for ending it, despite me begging Wladimir to make
> one.
>
> And there is no haste. We have been debating the block size limit
> for _years_. We have known it must be lifted for _years_. I kicked
> off this current round of debates after realising that Wladimir's
> release timeline wouldn't allow a block size limit to be released
> before the end of the year. The reason we're talking about it now
> and not next year is exactly to ensure there is plenty of time.
>
>
>
>
> I can sincerely assure you everyone does want to scale bitcoin and
> shares your long term objective on that
>
>
> I really wish you were right, and I definitely feel you are one of
> the more reasonable ones Adam. But the overwhelming impression I
> get from a few others here is that no, they don't want to scale
> Bitcoin. They already decided it's a technological dead end. They
> want to kick end users out in order to "incentivise" (force) the
> creation of some other alternative, claiming that it's still
> Bitcoin whilst ignoring basic details ... like the fact that no
> existing wallets or services would work.
>
> Scaling Bitcoin can only be achieved by letting it grow, and
> letting people tackle each bottleneck as it arises at the right
> times. Not by convincing ourselves that success is failure.
>
>
>
> ----------------------------------------------------------------------
- --------
>
>
>
>
> _______________________________________________ Bitcoin-development
> mailing list Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
- --
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
iQEcBAEBAgAGBQJVf1e3AAoJEGxwq/inSG8C7NwIAIah+HzWKB+aydCgarJB1Tuv
4wK6ffaWP3pzT/D1jNPMoMwL6bp+hi/ixyrV2y9a841Oc/9vgf75ws1l8QH2YtEE
TM5cLnRtScXnbaHKAAQZyewURbmGKTUxhNLMIRlVMMq2uHwbUEqRrDaaBGhwC1HO
+v3u5zK13H1UMKBuUY7yANWvOamjs17FmwZ6MURYdX8qBFVqMoTorhPHTebDGusS
NxDm4uqphW7ylXISOm53v7i3/CPjW63YGB2fyk9J+BqxhOM7yAJSH0Ln/xtu/COa
uXudO+SbMco+x+cKrFLf/5ItxR65aOnWvWPKw0o55f96uSabngs/QozDhaU2BJk=
=gof9
-----END PGP SIGNATURE-----

2023-06-07 15:37:54

- reply

📅 Original date posted:2015-06-14
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I fully agree and support this idea.
Some recent discussion on social media which touches on this very
subject of bitcoin and sourceforge.... (I include nmap and gittorrent
as well because those seem relevant, imho)
https://twitter.com/jgarzik/status/607750046021357568
https://twitter.com/nmap/status/608418994236891137
https://twitter.com/ktorn/status/607818378531631106
https://twitter.com/ktorn/status/607822900331020288
On 06/14/2015 03:12 AM, Warren Togami Jr. wrote:
> Discomfort with Sourceforge
>
> For a while now people have been expressing concern about
> Sourceforge's continued hosting of the bitcoin-dev mailing list.
> Downloads were moved completely to bitcoin.org <http://bitcoin.org>
> after the Sept 2014 hacking incident of the SF project account.
> The company's behavior and perceived stability have been growing to
> be increasingly questionable.
>
>
> http://www.theregister.co.uk/2013/11/08/gimp_dumps_sourceforge_over_do
dgy_ads_and_installer
>
> November 2013: GIMP flees SourceForge over dodgy ads and
> installer
>
> https://lwn.net/Articles/646118/
>
> May 28th, 2015: SourceForge replacing GIMP Windows downloads
>
> http://seclists.org/nmap-dev/2015/q2/194
>
> June 3rd, 2015: Sourceforge hijacked nmap's old site and
> downloads.
>
>
> When this topic came up over the past two years, it seemed that
> most people agreed it would be a good idea to move. Someone always
> suggests Google Groups as the replacement host. Google is quickly
> shot down as too controversial in this community, and it becomes an
> even more difficult question as to who else should host it.
> Realizing this is not so simple, discussion then dies off until the
> next time somebody brings it up.
>
>
> http://sourceforge.net/p/bitcoin/mailman/bitcoin-development/thread/19
43127.DBnVxmfOIh%401337h4x0r/#msg34192607
>
> Somebody brought it up again this past week.
>
>
> It seems logical that an open discussion list is not a big deal to
> continue to be hosted on Sourceforge, as there isn’t much they
> could do to screw it up. I personally think moving it away now
> would be seen as a gesture that we do not consider their behavior
> to be acceptable. There are also some benefits in being hosted
> elsewhere, at an entity able to professionally maintain their
> infrastructure while also being neutral to the content.
>
>
> Proposal: Move Bitcoin Dev List to a Neutral Competent Entity
>
>
> Bitcoin is a global infrastructure development project where it
> would be politically awkward for any of the existing Bitcoin
> companies or orgs to host due to questions it would raise about
> perceived political control. For example, consider a bizarro
> parallel universe where MtGox was the inventor of Bitcoin, where
> they hosted its development infrastructure and dev list under their
> own name. Even if what they published was 100% technically and
> ideologically equivalent to the Bitcoin we know in our dimension,
> most people wouldn't have trusted it merely due to appearances and
> it would have easily gone nowhere.
>
>
> I had a similar thought process last week when sidechains code was
> approaching release. Sidechains, like Bitcoin itself, are intended
> to be a generic piece of infrastructure (like ethernet?) that
> anyone can build upon and use. We thought about Google Groups or
> existing orgs that already host various open source infrastructure
> discussion lists like the IETF or the Linux Foundation. Google is
> too controversial in this community, and the IETF is seen as
> possibly too politically fractured. The Linux Foundation hosts a
> bunch of infrastructure lists
> <https://lists.linuxfoundation.org/mailman/listinfo>and it seems
> that nobody in the Open Source industry considers them to be
> particularly objectionable. I talked with LF about the idea of
> hosting generic Bitcoin-related infrastructure development lists.
> They agreed as OSS infrastructure dev is already within their
> charter, so early this week sidechains-dev list began hosting
> there.
>
>
> From the perspective of our community, for bitcoin-dev it seems
> like a great fit. Why? While they are interested in supporting
> general open source development, the LF has literally zero stake in
> this. In addition to neutrality, they seem to be suitable as a
> competenthost. They have full-time sysadmins maintaining their
> infrastructure including the Mailman server. They are soon
> upgrading to Mailman 3 <http://wiki.list.org/Mailman3>, which means
> mailing lists would benefit from the improved archive browser. I
> am not personally familiar with HyperKitty, but the point here is
> they are a stable non-profit entity who will competently maintain
> and improve things like their Mailman deployment (a huge
> improvement over the stagnant Sourceforge). It seems that LF would
> be competent, neutral place to host dev lists for the long-term.
>
>
> To be clear, this proposal is only about hosting the discussion
> list. The LF would have no control over the Bitcoin Project, as no
> single entity should.
>
>
> Proposed Action Plan
>
>
> *
>
> Discuss this openly within this community. Above is one example
> of a great neutral and competent host. If the technical leaders
> here can agree to move to a particular neutral host then we do it.
>
> *
>
> Migration: The current list admins become the new list admins. We
> import the entire list archive into the new host's archives for
> user convenience.
>
> *
>
> http://sourceforge.net/p/bitcoin/mailman/ Kill bitcoin-list and
> bitcoin-test. Very few people actually use it. Actually, let's
> delete the entire Bitcoin Sourceforge project as its continued
> existence serves no purpose and it only confuses people who find
> it. By deletion, nobody has to monitor it for a repeat of the
> Sept 2014 hacking incident
> <https://www.phoronix.com/scan.php?page=news_item&px=MTc4Mzg>or
> GIMP-type hijacking <https://lwn.net/Articles/646118/>?
>
> *
>
> The toughest question would be the appropriateness of
> auto-importing the subscriber list to another list server, as mass
> imports have a tendency to upset people.
>
>
> Thoughts?
>
>
> Warren Togami
>
>
> ----------------------------------------------------------------------
- --------
>
>
>
>
> _______________________________________________ Bitcoin-development
> mailing list Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
- --
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
iQEcBAEBAgAGBQJVffgcAAoJEGxwq/inSG8COOsH/jC5TAjec1ridg9Ww/1+SW26
QvTaZ79PrK4+/5rvt3qXtCicOidGLTGpk/ixrgVN64nOiquaQm8JM/BrOrtZbYN0
/lXjhR6N8AEKYYvtjCQdD/JjNZ8Z0QvRZ4+XKUblBagm4BkRt4OtaVkctechscbM
WiMh+SfUPPlGiuucotiBFliF4TprFTCw0w/+WY521yKE5qgTPc6ZKBHI5TzYROoF
aAz7i6GlAZR0qlbV91IzakszZWF/Im6KHG30CYbU4eTb6Ic9tVHogC2EuW2zePd3
NxRXE4M0FunnVX61Eg3Bglm73h6SuzsL9x79Ckp0UXpZ8sJ7+mYCDKTZSUEWeJs=
=Xje2
-----END PGP SIGNATURE-----

2023-06-07 15:37:51

- reply

📅 Original date posted:2015-06-15
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
What about Gittorrent?
http://blog.printf.net/articles/2015/05/29/announcing-gittorrent-a-decen
tralized-github/
On 06/14/2015 08:19 PM, Warren Togami Jr. wrote:
> On Sun, Jun 14, 2015 at 5:15 AM, Jeff Garzik <jgarzik at bitpay.com
> <mailto:jgarzik at bitpay.com>> wrote:
>
> * ACK on moving away from SourceForge mailing lists - though only
> once a community-welcomed replacement is up and running
>
> * ACK on using LF as a mailing infrastructure provider
>
> * Research secure mailing list models, for bitcoin-security. The
> list is not ultra high security - we all use PGP for that - but it
> would perhaps be nice to find some spiffy cryptosystem where
> mailing list participants individually hold keys & therefore
> access.
>
>
> While I agree this is a good idea, this should not be a
> precondition for moving the public bitcoin-dev list. The security
> team needs to separately research/write tools needed for this.
>
> <jgarzik> warren, wanna just go ahead and create
> bitcoin-development @ LF?
>
>
> *More Feedback?* As for going ahead, perhaps we should wait to
> hear from more of the other technical leaders?
>
> *_More Questions_*
>
> *List Name?* Would people prefer "bitcoin-development" for he new
> list name instead of a shorter name like "bitcoin-dev"? I
> personally like the shorter name, but either is fine.
> https://lists.linuxfoundation.org/mailman/listinfo currently has
> "sidechains-dev", and "lightning-dev" is moving there sometime
> soon.
>
> *Proposed Cut-Off Date?* Then we also need to agree on a date to
> cut off the old list. Their sysadmin said we could have the new
> list auto-post from the old list for a short while. I wonder how
> well that works ... if that will result in double posting if people
> write to the new and CC the old list. Needs a little research how
> well it would behave to have both lists operating during a
> transition period. I think we should announce a cut-off date when
> posts to the old list is shut off, July 15th, one month from now.
> Thoughts?
>
> *Moderators?* Mailman on the new server allows having separate
> logins for admins and moderators. I think the admins of the old SF
> project are gavin, jgarzik and sipa... they are kind of busy.
> Perhaps we should identify known trusted community members who can
> help with moderation. Usually this is dealing with "held" messages
> that are flagged by the spam filter
>
> Warren Togami
>
>
> ----------------------------------------------------------------------
- --------
>
>
>
>
> _______________________________________________ Bitcoin-development
> mailing list Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
- --
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
iQEcBAEBAgAGBQJVfpcfAAoJEGxwq/inSG8CEdsH+weboFo8SCbwgoe68oZLl6Et
r4JtzZRu8jtw5x6AYcpVMBvUo3CHtbYCWREidBhvSU+TlOUjnxZRU5CjLpjHcc61
QV2hIGD1RUdrcj93PBsnNrvuXkLVHd09sKXCIvldY1d1GqTqy9sVY1skExd7zY2h
LmJhLdmNw7I+gLP/r8Ivl7aDqrpzHXr7pnbFXZZ0hxhthncxXTefi/IV+kAt3ptL
qfSRYGPyyUXWLfXF/XW+/DH+scZm+Iu/SSoSa6xnEo4MgY4HzZM2Uy+9Te9aO6wd
xvdpMetZV5A9Ljr8Ww72DPDkvUprk7u55OMgZZ4Fps53PnqwpNOjt3phIUH4iVE=
=6Fxw
-----END PGP SIGNATURE-----

2023-06-07 15:37:42

- reply

📅 Original date posted:2015-06-13
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I'm way late to this one, I guess, but adding some thoughts here... it
seems that anything which mitigates the problem of reuse should be to
the maximum extent possible, the user's option... if a person wants to
have an address that lasts forever they should be able to have it...
if they want to have an address that expires they should be able to
have it.
The reuse problem is, I think, better solved by the presentation of
stealth address proposals, and would be handled by a stealth BIP (BIP
63) which has been recently re-discussed here:
https://bitcointalk.org/index.php?topic=1083961.0
On 03/26/2015 02:44 PM, Gregory Maxwell wrote:
> On Thu, Mar 26, 2015 at 9:26 PM, Tom Harding <tomh at thinlink.com>
> wrote:
>> I should have been clearer that the motivation for address
>> expiration is to reduce the rate of increase of the massive pile
>> of bitcoin addresses out there which have to be monitored
>> forever for future payments. It could make a significant dent
>> if something like this worked, and were used by default someday.
>
> Great, that can be accomplished by simply encoding an expiration
> into the address people are using and specifying that clients
> enforce it.
>
> ----------------------------------------------------------------------
- --------
>
>
>
Dive into the World of Parallel Programming The Go Parallel Website,
sponsored
> by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly
> thought leadership blogs to news, videos, case studies, tutorials
> and more. Take a look and join the conversation now.
> http://goparallel.sourceforge.net/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
- --
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
iQEcBAEBAgAGBQJVe7cJAAoJEGxwq/inSG8C2uwH/2UfTX+6CEssv5ZhiwwqVNWk
bmlODZulsJK0FIIcz2oVtMvnMR7L8DX/XtFOdiVTk/wOn7vc7X/DZ9UVKSixKCLJ
IJLzBKEzFzMmNhxXv9fPsefuMsMlTkhifykl2BOp0T2gMEr5GweKSqn9XpQuo9mb
LhS5vqNCRw0X3eQ5sIalSfmK3ghP5yaU+orhFjvb3QJ/JN3mxgXyl3xLx9diPVdu
2I1QoxzCyE/tlEnxZGPrCtGe3d93mPhEFGGeiP+7eW8TkJa5AGCg3QWbzniC3Nsv
gjg6rCbLKtj300hH0glbPT96YO+r9l5itox+aArkCtNnR+/HlUb6zubgqebzPuc=
=KZQe
-----END PGP SIGNATURE-----

2023-06-07 15:37:40

- reply

📅 Original date posted:2015-06-14
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I agree that changes of anything more than trivial are difficult, but
I would disagree that they can't be made. It seems that the issue is
one of roadblocks and muddling through when a major issue (e.g. the
proposal of a hardfork / XT) is confronting the community and the
question of how to address this issue in a timely manner. That does
not mean that there isn't a process for the community to weigh in or
for the decisions of the participants in the network to be measured
because, of course, there is, but I submit that the larger issues are
having to do with concerns over the problems inherent in the totally
unnecessary XT proposal itself.
My own thoughts on that proposal are written up at
http://www.twitlonger.com/show/n_1smkanp
And have been supported somewhat by various others in the community,
such as GreenAddress (which is opposed at this time to increasing the
blocksize limit as per Gavin's proposal) and Adam Back:
https://twitter.com/adam3us/status/608920099609817088
I think Jeff Garzik had some good thoughts specifically regarding this
subject of user vote in blocksize through fees. Although I do agree
with you, Aaron, that the "changes more than trivial" are a tough nut
to crack, I won't say that they can't be made in such processes and I
am curious to see how this discussion progresses.
- -O
On 06/13/2015 10:46 PM, Aaron Voisine wrote:
> Yes, it does bother (some) people to see the consensus based
> system because of the difficulties that can be associated with
> implementing it. But that's the way it is. If you don't like
> consensus based systems (or decentralized, distributed systems)
> this is probably the wrong space for you.
>
>
> If consensus must be reached to make any changes, that just means
> that changes of anything more than trivial consequence simply can't
> be made. Extreme bias toward the status-quo will only work if
> external factors affecting the network also remain static.
>
> Aaron Voisine co-founder and CEO breadwallet.com
> <http://breadwallet.com/>
- --
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
iQEcBAEBAgAGBQJVffRMAAoJEGxwq/inSG8CGfIH/RkMNeJpcXdG+pC6Cg1XMELQ
wa/fkdKnnkhhxNm4keHeO0YQFw0BL4rQSQ2PfGEXU3keJrWlmxchEQteAGDzL55Y
1dSkQbfxsaEco2m6P0/1+WGuNOn2Sp653+/G/WoeaqMvp+b2ORbVZoqURv7Iz240
sI6GqWxWxuGpJyaW/PwVYfvGAImeQRKgKiB3w001Q3Lc36wDr/EGs4lVWJTSk+g+
60zj4+7jmqpr/Q/+sjQDE0KZSBU/EmrPYEuEdBkOmG4JnFgBqM7civtHis/zu7Uc
1sr/LcqeGm0VB/yt0CfvtsAC5KZyMFQABF0/Q2qX0GtuLbjyKWf7B/KEAPdC+m0=
=3cf3
-----END PGP SIGNATURE-----

2023-06-07 15:37:39

- reply

📅 Original date posted:2015-06-14
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
A decentralized, distributed application should offer its users
decentralized, distributed method of weighing in on the direction of
how it evolves as well as having an open development model. The
reference to Facebook and Myspace is completely inapplicable here
because the tyranny of such spaces isn't what we have with bitcoin
(fortunately), nor would we want to try to replicate it, ever, in any
way, shape, or form.
Yes, it does bother (some) people to see the consensus based system
because of the difficulties that can be associated with implementing
it. But that's the way it is. If you don't like consensus based
systems (or decentralized, distributed systems) this is probably the
wrong space for you.
On 06/13/2015 04:57 PM, Raystonn wrote:
> Adding back the list. Did not intend to remove it. Apologies.
>
> On 13 Jun 2015 4:52 pm, Raystonn <raystonn at hotmail.com> wrote:
>
> Based on my observations, what the majority of Bitcoin users want
> is a system that can carry more transactions per second than any
> existing payment system while retaining most of the security
> offered today. The technicalities on how this is achieved are not
> as important as the end result. If the only user input is to
> technicalities, they will use that to voice their opinions.
>
> On 13 Jun 2015 4:25 pm, Danny Thorpe <danny.thorpe at gmail.com>
> wrote:
>
> I don't recall Facebook or MySpace asking end users to alter the
> parameters of their respective back-end network infrastructure.
>
> How are Bitcoin end users qualified to make an informed decision
> regarding block size limits? And why should they care?
>
> Sure, I want Bitcoin to grow its user base. But to do that,
> Bitcoin has to be accessible to the nontechnical population.
> Asking nontechnical people to make technical decisions leads
> directly to stress and confusion, which most folks find
> off-putting.
>
> And please don't call me Shirley. ;>
>
> On Sat, Jun 13, 2015 at 3:42 PM, Raystonn <raystonn at hotmail.com
> <mailto:raystonn at hotmail.com>> wrote:
>
> Surely you would prefer to actually have users? Bitcoin does not
> exist in a vacuum. Network effect alone is not enough to ensure
> success in the face of competition from alternatives with a much
> better user experience. See Facebook vs MySpace, IE vs Netscape,
> etc.
>
> On 13 Jun 2015 3:20 pm, Danny Thorpe <danny.thorpe at gmail.com
> <mailto:danny.thorpe at gmail.com>> wrote:
>
> Please forgive my ignorance, but why should Bitcoin users have a
> say in block size limits? It's the miners and Bitcoin node
> operators that bear the burden of managing large blocks, no?
>
> Users voting on network parameters sounds like neighbors voting on
> how deep my swimming pool should be.
>
> Thanks, -Danny
>
> On Fri, Jun 12, 2015 at 11:11 AM, Peter Todd <pete at petertodd.org
> <mailto:pete at petertodd.org>> wrote:
>
> Jeff Garzik recently proposed that the upper blocksize limit be
> removed entirely, with a "soft" limit being enforced via miner
> vote, recorded by hashing power.
>
> This mechanism within the protocol for users to have any influence
> over the miner vote. We can add that back by providing a way for
> transactions themselves to set a flag determining whether or not
> they can be included in a block casting a specific vote.
>
> We can simplify Garzik's vote to say that one of the nVersion bits
> either votes for the blocksize to be increased, or decreased, by
> some fixed ratio (e.g 2x or 1/2x) the next interval. Then we can
> use a nVersion bit in transactions themselves, also voting for an
> increase or decrease. Transactions may only be included in blocks
> with an indentical vote, thus providing miners with a monetary
> incentive via fees to vote according to user wishes.
>
> Of course, to cast a "don't care" vote we can either define an
> additional bit, or sign the transaction with both versions.
> Equally we can even have different versions with different fees,
> broadcast via a mechanism such as replace-by-fee.
>
>
> See also John Dillon's proposal for proof-of-stake blocksize
> voting:
>
> https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net
/msg02323.html
>
>
>
- -- 'peter'[:-1]@petertodd.org <http://petertodd.org>
> 0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
>
> ----------------------------------------------------------------------
- --------
>
>
>
_______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> <mailto:Bitcoin-development at lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
>
>
> ----------------------------------------------------------------------
- --------
>
>
>
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
- --
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
iQEcBAEBAgAGBQJVfQL0AAoJEGxwq/inSG8CRqMH/0l9tHGA8figVGnIBoMgdpVi
uwMGTQTjLUf12/NFS27vT+OLMWqZRvVXvlxDF25N7la+QImhh67LqmQy8fkwGg5T
kJ6MkkFLgy05aqE/X3ywJUifOKmS3Y/RDDUJhrFjjHrsMGoF4ATtVwTpUBLik+kX
G3XRNlInmyB55UEcpyfBg9kfLz8xiy6sBPeaeGnFLCNWTs5TgJ6DTFqhBAAmE8Hw
k0tN6mW3wYS610FFkS2E3+W8O8KGs4oqAYLX/ZQOhX9oKjBvWWI4ppRpSDyBNcxd
A6VAKyU8HCuDHAEwba6gdlUa+yf4qxuZV1KCNENbvtN1CTsJ6oh0OxnEO6dtogo=
=KZmG
-----END PGP SIGNATURE-----

2023-06-07 15:37:34

- reply

📅 Original date posted:2015-06-14
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Notionally, I agree with what I see written here by Jeff, and I
appreciate the thoughtfulness that went into this short post to list.
On 06/14/2015 08:07 AM, Jeff Garzik wrote:
> Exactly -- both block size proponents and block size change
> conservatives seem to be glossing over this aspect - much to my
> dismay.
>
> Choosing the size limit is choosing the size of a scarce resource.
> By fiat.
>
> It is wrong to think that a "technical consensus" can choose what
> is best here.
>
> The block size limit defines the scope of a resource for which all
> fee market actors bid. That, in turn, defines who is in the fee
> market and how they behave, what market choices are made.
>
> It doesn't matter how or why the limit was originally enacted, what
> Satoshi meant to do. What matters, economically, is what is. What
> the software and our $3B economy & market knows and sees today. (I
> think some block size change proponents miss this!)
>
> The solution lies in transitioning this size limit to the free
> market. In the end, the users must choose their desired level of
> growth, decentralization, etc. We cannot rely on some dev's idea
> of the proper level of fee, proper level of growth, proper level
> of decentralization.
>
> And IMO, a "floating limit with training wheels" is better and
> stronger for bitcoin's health from a governance, user choice and
> free market perspective than simply "hard fork to 2MB, come back
> again in 6 months."
>
>
>
>
>
>
>
> On Sun, Jun 14, 2015 at 6:34 AM, Benjamin
> <benjamin.l.cordes at gmail.com <mailto:benjamin.l.cordes at gmail.com>>
> wrote:
>
> "The size limit is an economic policy lever that needs to be
> transitioned -away- from software and software developers, to the
> free market."
>
> Exactly right. Bitcoin does not have a free market for fee though,
> and literally all the discussion so far has neglected some
> fundamental aspect of this, as you described. It's not at all a
> "technical" or "engineering" decision. It's the question of how to
> potentially re-design a fundamental part of Bitcoin, and the
> proposals so far don't address this. What is the price of the
> scarce resource of the blockchain and the mechanism to decide on
> price, once the subsidy runs out?
>
> On Sun, Jun 14, 2015 at 12:06 PM, Mats Henricson <mats at henricson.se
> <mailto:mats at henricson.se>> wrote:
>> Jeff,
>>
>> with all due respect, but I've seen you saying this a few times
>> now, that this decision is oh so difficult and important.
>>
>> But this is not helpful. We all know that. Even I.
>>
>> Make a suggestion, or stay out of the debate!
>>
>> Mats
>>
>> On 06/14/2015 07:36 AM, Jeff Garzik wrote:
>>> The choice is very real and on-point. What should the block
>>> size
> limit
>>> be? Why?
>>>
>>> There is a large consensus that it needs increasing. To what?
>>>
> By what
>>> factor?
>>>
>>> The size limit literally defines the fee market, the whole
>>> damn
> thing. If
>>> software high priests choose a size limit of 300k, space is
> scarce, fees
>>> are bid high. If software high priests choose a size limit of
> 32mb, space
>>> is plentiful, fees are near zero. Market actors take their
>>> signals accordingly. Some business models boom, some business
>>> models
> fail, as a
>>> direct result of changing this unintentionally-added
>>> speedbump.
>>>
> Different
>>> users value adoption, decentralization etc. differently.
>>>
>>> The size limit is an economic policy lever that needs to be
> transitioned
>>> -away- from software and software developers, to the free
>>> market.
>>>
>>> A simple, e.g. hard fork to 2MB or 4MB does not fix higher
>>> level
> governance
>>> problems associated with actors lobbying developers, even if a
> cloistered
>>> and vetted Technical Advisory Board as has been proposed.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Sun, Jun 14, 2015 at 1:20 AM, Eric Lombrozo
> <elombrozo at gmail.com <mailto:elombrozo at gmail.com>> wrote:
>>>
>>>> I definitely think we need some voting system for
> metaconsensus…but if
>>>> we’re going to seriously consider this we should look at the
> problem much
>>>> more generally. Using false choices doesn’t really help,
>>>> though ;)
>>>>
>>>> - Eric Lombrozo
>>>>
>>>>
>>>> On Jun 13, 2015, at 10:13 PM, Jeff Garzik
>>>> <jgarzik at bitpay.com
> <mailto:jgarzik at bitpay.com>> wrote:
>>>>
>>>> On Sun, Jun 14, 2015 at 1:08 AM, Eric Lombrozo
> <elombrozo at gmail.com <mailto:elombrozo at gmail.com>>
>>>> wrote:
>>>>
>>>>> 2) BIP100 has direct economic consequences…and
>>>>> particularly for
> miners.
>>>>> It lends itself to much greater corruptibility.
>>>>>
>>>>>
>>>> What is the alternative? Have a Chief Scientist or
>>>> Technical
> Advisory
>>>> Board choose what is a proper fee, what is a proper level of
>>>> decentralization, a proper growth factor?
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
> ----------------------------------------------------------------------
- --------
>
>
>
>>
>>>
>>>
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development at lists.sourceforge.net
> <mailto:Bitcoin-development at lists.sourceforge.net>
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>>>
>>>
>>
>>
>>
> ----------------------------------------------------------------------
- --------
>
>
>
_______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
> <mailto:Bitcoin-development at lists.sourceforge.net>
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
> ----------------------------------------------------------------------
- --------
>
>
>
_______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> <mailto:Bitcoin-development at lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
>
> -- Jeff Garzik Bitcoin core developer and open source evangelist
> BitPay, Inc. https://bitpay.com/
>
>
> ----------------------------------------------------------------------
- --------
>
>
>
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
- --
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
iQEcBAEBAgAGBQJVfflFAAoJEGxwq/inSG8CrWoIAJOsZHTWqdILE0IYmmE50E/S
BcbPJJtjodw1liPVJEybyNUKSgq4Ucw9tuQpMVv3hF8bvug6/6HtxAQCptuIKRSw
WigZyvgm79u474YsPULG+2SltMrOFqmA05jTF9vWo0LBSY4xiMXjT4VwVt9xEcFc
qHW5OUa1QoFZkaOf/jtY+H3a9w8cHZFlroTkf4MaJkaMo81oSRfWz3Mj8wOz6f8z
MSEpvQERzETEcV0SqTBnzsoX8toO1s24a9HejMMfbeD7JAy8EvayFb3G1LNzBNVC
1x/yeLBGnE3Z0P80J0oUR5taLbGJl9+7Hb16rEzxivtZF5FWBdDmvwKBOKJ1Alo=
=ubcH
-----END PGP SIGNATURE-----

2023-06-07 15:36:14

- reply

📅 Original date posted:2015-06-13
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 06/02/2015 04:03 AM, Mike Hearn wrote:
(...)
>
> If you really believe that decentralisation is, itself, the end,
> then why not go use an "ASIC resistant" alt coin with no SPV or web
> wallets which resembles Bitcoin at the end of 2009? That'd be a
> whole lot more decentralised than what you have now.
>
> The *percentage* of the community that mines is totally
> irrelevant, it's the absolute number of (independent) people that
> matters.
>
>
> So usage does matter, then? You'd rather have a coin that has
> power concentrated in a far smaller elite, proportionally, but has
> overall more usage? If there are say, 5000 full nodes today, and in
> ten years there are 6000, and they all run in vast datacenters and
> are owned by large companies, you'll feel like Bitcoin is more
> decentralised than ever? (n.b. I do not think this situation will
> ever happen, it's just an example).
>
Something you said about "power concentrated," made me think I should
post this here:
https://twitter.com/adam3us/status/608920099609817088
- --
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
iQEcBAEBAgAGBQJVe8gvAAoJEGxwq/inSG8CcykH/0d+WuPnzFWooCRJR+FwaI4w
Ad0z5GSLfYKGnmMMbbqkLsIA2GsfRAvivrsfZYd4slF5C7HEDGa3J/NC72U46dk6
qVm07UNBO3V+loLJtStIQQkg3tVGWjXeiySf4E4b8wlaZiBMS9WW0sAOWUJiGMDQ
jKNRpjXobkQGd8C+VJXDpgtmiY60bS4l6j7bbYv+mU6LxhLwCVCqjRJSEN08BH4E
AOwJg1qlORHPnrepfeJrB6TVxeHuLjCjWodXQ0jHbNchVQw7zc81gKrD40BJTzyO
TTtGPu3JUkcHtx7MVLbIdYNVElqxMS5Li+j9j3h+m9eGSaNgOOl3+8VGJexKPKI=
=j5Fh
-----END PGP SIGNATURE-----

2023-06-07 15:31:59

- reply

📅 Original date posted:2015-03-23
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Shizzle's opinion, it would seem, is highly important. I'm done here.
Thy Shizzle:
> Oh so you're talking about the criminality of one single entity? So
> having a quick look, it seems that the issue is they are collecting
> IPs and that kind of thing as well? So similar to what
> http://getaddr.bitnodes.io is doing but without the funding from
> the bitcoin foundation? If you are worried about your IP getting
> out you're behind a VPN. They can only collect the information made
> available to them. Botnets etc are completely different because you
> are forcing control over something you have no right to do. If
> companies want to sit there and collect publicly available
> information that you are voluntarily making available to them, why
> do you care? I can't see how it could be at all criminal.
> Remembering that most privacy laws relate to information that YOU
> PROVIDE to an entity during an agreement for service, payment, etc.
> You are providing this information publicly and they are collecting
> it from the public domain, not you giving it to them in an
> agreement, therefore the usual provisions of privacy etc don't
> apply. If you connect to their scraper node, of course they can log
> that. How could it possibly be criminal?
> ________________________________ From:
> odinn<mailto:odinn.cyberguerrilla at riseup.net> Sent: ‎23/‎03/‎2015
> 4:50 PM To: Thy Shizzle<mailto:thyshizzle at outlook.com> Cc:
> bitcoin-development at lists.sourceforge.net<mailto:bitcoin-development at lists.sourceforge.net>
>
>
Subject: Re: [Bitcoin-development] Criminal complaints against "network
disruption as a service" startups
>
> Back to what is Chainalysis and country of their origin, so
> criminal complaints against them would likely relate to violation
> of Swiss laws, as is described here:
> https://bitcointalk.org/index.php?topic=978088.msg10774882#msg10774882
>
> It is fairly obvious that Chainalysis is not merely doing what
> blockchain.info etc. is. Let's not delude ourselves here.
>
> As stated, it would be advisable for such a firm to cease
> operations, and it would seem that plenty of polite shots over the
> bow have been given to Chainalysis, which should now fold up its
> operation, pack its bags, and go back to its hole before trying to
> serve its masters again in another way. Etc.
>
> Corporations similar to Chainalysis which are domiciled in other
> countries which conduct collection of information in ways that
> violate countries' laws (there are many countries and each have
> their own ways of interpreting user privacy and what constitutes
> permissible breach and in what circumstances) can indeed be held to
> legal standards that may result in minimal or severe legal
> penalties. It is true that analyzing information that is publicly
> available, such as that which is in a library, is not illegal. But
> the act of surveillance is. (Then there is the question of what
> sort of surveillance, targeted or general, and whether it is
> limited to the bitcoin network or if it moves beyond that to
> attempts to correlate with usernames, IDs, IPs, and other
> information available on fora and apparent from services, but I
> won't get into that here.) Even if you argue that the manner in
> which you are performing your actions is not actually
> "surveillance," or you argue that it is "legally permissible,"
> someone else will certainly come along and make a reasonable
> argument that you are indeed engaging in illegal surveillance.
> They may even suggest to a judge that you are in the process of
> constructing a botnet and demand that your domains be seized, and
> may successfully obtain an ex parte temporary restraining order
> (TRO) against Chainalysis and similar corporations to have
> domain(s) seized. Any and all arguments may be added in here,
> there are 196 countries in the world today - each with their own
> unique laws - (maybe less by the time you read this) and a shit-ton
> of possible legal arguments that can be made by creative minds that
> might want to sue you if you have been surveilling people, each
> different depending on where your surveillance corporation is
> domiciled. There are plenty of legal processes available for
> people to do exactly that. You are indeed subject to having that
> happen to you if you continue to surveill the network even if you
> are doing so on behalf of the state for the purpose of gathering
> information for a state's compliance initiative.
>
> So, don't delude yourself, and be happy if all that happens is
> your little surveillance initiative has to close its doors (or gets
> sued if it stays open). Because that is the legal side of things.
> The extralegal stuff is far worse. The community is helping you by
> asking you gently to close up shop and go away. It is a helpful
> suggestion and I believe also a fair warning, again, a shot off the
> bow.
>
> On the development side, developers are certainly responsible for
> doing what they can to resist this kind of surveillance activity.
> But I have a feeling that will be a different thread which is more
> technical and so won't comment on it here, except to say it will
> likely involve working toward giving the user an anonymity option
> which can be exercised as part of any transaction.
>
> Thy Shizzle:
>> I don't believe that at all. Analyzing information publicly
>> available is not illegal. Chainalysis or whatever you call it
>> would be likened to observing who comes and feeds birds at the
>> park everyday. You can sit in the park and observe who feeds the
>> birds, just as you can connect to the Bitcoin P2P network and
>> observe the blocks being formed into the chain and transactions
>> etc. Unless there is some agreement taking place where it is
>> specified that upon connecting to the Bitcoin P2P swarm you agree
>> to a set of terms, however as every node is providing their own
>> "entry" into the P2P swarm it becomes really up to the node
>> providing the connection to uphold and enforce the terms of the
>> agreement. If you allow people to connect to you without terms of
>> agreement, you cannot cry foul when they record the data that
>> passes through. To say Chainalysis needs to cease is silly, the
>> whole point of the public blockchain is for Chainalysis, whether
>> it be for the verification of transactions, research or
>> otherwise.
>
>> -----Original Message----- From: "odinn"
>> <odinn.cyberguerrilla at riseup.net> Sent: ‎23/‎03/‎2015 1:48 PM
>> To: "bitcoin-development at lists.sourceforge.net"
>> <bitcoin-development at lists.sourceforge.net> Subject: Re:
>> [Bitcoin-development] Criminal complaints against "network
>> disruption as a service" startups
>
>> If you (e.g. Chainalysis) or anyone else are doing surveillance
>> on the network and gathering information for later use, and
>> whether or not the ultimate purpose is to divulge it to other
>> parties for compliance purposes, you can bet that ultimately the
>> tables will be turned on you, and you will be the one having your
>> ass handed to you so to speak, before or after you are served, in
>> legal parlance. Whether or not the outcome of that is meaningful
>> and beneficial to any concerned parties and what is the upshot of
>> it in the end depends on on what you do and just how far you
>> decide to take your ill-advised enterprise.
>
>> Chainalysis and similar operations would be, IMHO, well advised
>> to cease operations. This doesn't mean they will, but guess
>> what:
>
>> Shot over the bow, folks.
>
>> Jan Møller:
>>> What we were trying to achieve was determining the flow of
>>> funds between countries by figuring out which country a
>>> transaction originates from. To do that with a certain accuracy
>>> you need many nodes. We chose a class C IP range as we knew
>>> that bitcoin core and others only connect to one node in any
>>> class C IP range. We were not aware that breadwallet didn't
>>> follow this practice. Breadwallet risked getting tar-pitted,
>>> but that was not our intention and we are sorry about that.
>
>>> Our nodes DID respond with valid blocks and merkle-blocks and
>>> allowed everyone connecting to track the blockchain. We did
>>> however not relay transactions. The 'service' bit in the
>>> version message is not meant for telling whether or how the
>>> node relays transactions, it tells whether you can ask for
>>> block headers only or full blocks.
>
>>> Many implementations enforce non standard rules for handling
>>> transactions; some nodes ignore transactions with address
>>> reuse, some nodes happily forward double spends, and some nodes
>>> forward neither blocks not transactions. We did blocks but not
>>> transactions.
>
>>> In hindsight we should have done two things: 1. relay
>>> transactions 2. advertise address from 'foreign' nodes
>
>>> Both would have fixed the problems that breadwallet
>>> experienced. My understanding is that breadwallet now has the
>>> same 'class C' rule as bitcoind, which would also fix it.
>
>>> Getting back on the topic of this thread and whether it is
>>> illegal, your guess is as good as mine. I don't think it is
>>> illegal to log incoming connections and make statistical
>>> analysis on it. That would more or less incriminate anyone who
>>> runs a web-server and looks into the access log. At lease one
>>> Bitcoin service has been collecting IP addresses for years and
>>> given them to anyone visiting their web-site (you know who) and
>>> I believe that this practise is very wrong. We have no
>>> intention of giving IP addresses away to anyone, but we believe
>>> that you are free to make statistics on connection logs when
>>> nodes connect to you.
>
>>> On a side note: When you make many connections to the network
>>> you see lots of strange nodes and suspicious patterns. You can
>>> be certain that we were not the only ones connected to many
>>> nodes.
>
>>> My takeaway from this: If nodes that do not relay transactions
>>> is a problem then there is stuff to fix.
>
>>> /Jan
>
>>> On Fri, Mar 13, 2015 at 10:48 PM, Mike Hearn <mike at plan99.net>
>>> wrote:
>
>>>> That would be rather new and tricky legal territory.
>>>>
>>>> But even putting the legal issues to one side, there are
>>>> definitional issues.
>>>>
>>>> For instance if the Chainalysis nodes started following the
>>>> protocol specs better and became just regular nodes that
>>>> happen to keep logs, would that still be a violation? If so,
>>>> what about blockchain.info? It'd be shooting ourselves in
>>>> the foot to try and forbid block explorers given how useful
>>>> they are.
>>>>
>>>> If someone non-maliciously runs some nodes with debug
>>>> logging turned on, and makes full system backups every night,
>>>> and keeps those backups for years, are they in violation of
>>>> whatever pseudo-law is involved?
>>>>
>>>> I think it's a bit early to think about these things right
>>>> now. Michael Grønager and Jan Møller have been Bitcoin
>>>> hackers for a long time. I'd be interested to know their
>>>> thoughts on all of this.
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>>
>>>>
>
>>>>
>>>>
> Dive into the World of Parallel Programming The Go Parallel
> Website,
>>>> sponsored by Intel and developed in partnership with
>>>> Slashdot Media, is your hub for all things parallel software
>>>> development, from weekly thought leadership blogs to news,
>>>> videos, case studies, tutorials and more. Take a look and
>>>> join the conversation now.
>>>> http://goparallel.sourceforge.net/
>>>> _______________________________________________
>>>> Bitcoin-development mailing list
>>>> Bitcoin-development at lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>>
>>>>
>
>>>>
>>>>
>
>
>>> ------------------------------------------------------------------------------
>
>>>
>>>
>
>> Dive into the World of Parallel Programming The Go Parallel
>> Website, sponsored
>>> by Intel and developed in partnership with Slashdot Media, is
>>> your hub for all things parallel software development, from
>>> weekly thought leadership blogs to news, videos, case studies,
>>> tutorials and more. Take a look and join the conversation now.
>>> http://goparallel.sourceforge.net/
>
>
>
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>>>
>
>
>> ------------------------------------------------------------------------------
>
>>
>
> Dive into the World of Parallel Programming The Go Parallel
> Website, sponsored
>> by Intel and developed in partnership with Slashdot Media, is
>> your hub for all things parallel software development, from
>> weekly thought leadership blogs to news, videos, case studies,
>> tutorials and more. Take a look and join the conversation now.
>> http://goparallel.sourceforge.net/
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
- --
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-----
iQEcBAEBCgAGBQJVD7aKAAoJEGxwq/inSG8C4KsIAIu5atra8Y9R9oejNryjMQkz
UOVORw3y0eD8yaAiJJQzJjmNE6UXC92R3gM3KtQoQchSQ6RhyhZUZkzCY7k2Ug08
8UZnxjgAHCwScGUSgpDu2hcGDtC+Csa1EKOExjCxYCBlVRI+cCJqxIm9d7vGDi4V
R1y57xtKtussJxhZKVjIxothkHtSy5HuaKdKLfI7ikoBAerOVY7bGCxE+drUr4OO
Sgxe94M8z/ecFk3h37ZhuL2P+mNAlCKQkW592628XC0bXN8iT2vW7MnB3BLEBzvb
TeWFYUFjs5v09B6Cw6LQWFGKdFwLGganybeEqoKNfzrihEAa19PFsRWHPStMUCM=
=JnJQ
-----END PGP SIGNATURE-----

2023-06-07 15:31:58

- reply

📅 Original date posted:2015-03-23
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Back to what is Chainalysis and country of their origin, so criminal
complaints against them would likely relate to violation of Swiss
laws, as is described here:
https://bitcointalk.org/index.php?topic=978088.msg10774882#msg10774882
It is fairly obvious that Chainalysis is not merely doing what
blockchain.info etc. is. Let's not delude ourselves here.
As stated, it would be advisable for such a firm to cease operations,
and it would seem that plenty of polite shots over the bow have been
given to Chainalysis, which should now fold up its operation, pack its
bags, and go back to its hole before trying to serve its masters again
in another way. Etc.
Corporations similar to Chainalysis which are domiciled in other
countries which conduct collection of information in ways that violate
countries' laws (there are many countries and each have their own ways
of interpreting user privacy and what constitutes permissible breach
and in what circumstances) can indeed be held to legal standards that
may result in minimal or severe legal penalties. It is true that
analyzing information that is publicly available, such as that which
is in a library, is not illegal. But the act of surveillance is.
(Then there is the question of what sort of surveillance, targeted or
general, and whether it is limited to the bitcoin network or if it
moves beyond that to attempts to correlate with usernames, IDs, IPs,
and other information available on fora and apparent from services,
but I won't get into that here.) Even if you argue that the manner in
which you are performing your actions is not actually "surveillance,"
or you argue that it is "legally permissible," someone else will
certainly come along and make a reasonable argument that you are
indeed engaging in illegal surveillance. They may even suggest to a
judge that you are in the process of constructing a botnet and demand
that your domains be seized, and may successfully obtain an ex parte
temporary restraining order (TRO) against Chainalysis and similar
corporations to have domain(s) seized. Any and all arguments may be
added in here, there are 196 countries in the world today - each with
their own unique laws - (maybe less by the time you read this) and a
shit-ton of possible legal arguments that can be made by creative
minds that might want to sue you if you have been surveilling people,
each different depending on where your surveillance corporation is
domiciled. There are plenty of legal processes available for people
to do exactly that. You are indeed subject to having that happen to
you if you continue to surveill the network even if you are doing so
on behalf of the state for the purpose of gathering information for a
state's compliance initiative.
So, don't delude yourself, and be happy if all that happens is your
little surveillance initiative has to close its doors (or gets sued if
it stays open). Because that is the legal side of things. The
extralegal stuff is far worse. The community is helping you by asking
you gently to close up shop and go away. It is a helpful suggestion
and I believe also a fair warning, again, a shot off the bow.
On the development side, developers are certainly responsible for
doing what they can to resist this kind of surveillance activity. But
I have a feeling that will be a different thread which is more
technical and so won't comment on it here, except to say it will
likely involve working toward giving the user an anonymity option
which can be exercised as part of any transaction.
Thy Shizzle:
> I don't believe that at all. Analyzing information publicly
> available is not illegal. Chainalysis or whatever you call it would
> be likened to observing who comes and feeds birds at the park
> everyday. You can sit in the park and observe who feeds the birds,
> just as you can connect to the Bitcoin P2P network and observe the
> blocks being formed into the chain and transactions etc. Unless
> there is some agreement taking place where it is specified that
> upon connecting to the Bitcoin P2P swarm you agree to a set of
> terms, however as every node is providing their own "entry" into
> the P2P swarm it becomes really up to the node providing the
> connection to uphold and enforce the terms of the agreement. If you
> allow people to connect to you without terms of agreement, you
> cannot cry foul when they record the data that passes through. To
> say Chainalysis needs to cease is silly, the whole point of the
> public blockchain is for Chainalysis, whether it be for the
> verification of transactions, research or otherwise.
>
> -----Original Message----- From: "odinn"
> <odinn.cyberguerrilla at riseup.net> Sent: ‎23/‎03/‎2015 1:48 PM To:
> "bitcoin-development at lists.sourceforge.net"
> <bitcoin-development at lists.sourceforge.net> Subject: Re:
> [Bitcoin-development] Criminal complaints against "network
> disruption as a service" startups
>
> If you (e.g. Chainalysis) or anyone else are doing surveillance on
> the network and gathering information for later use, and whether or
> not the ultimate purpose is to divulge it to other parties for
> compliance purposes, you can bet that ultimately the tables will be
> turned on you, and you will be the one having your ass handed to
> you so to speak, before or after you are served, in legal parlance.
> Whether or not the outcome of that is meaningful and beneficial to
> any concerned parties and what is the upshot of it in the end
> depends on on what you do and just how far you decide to take your
> ill-advised enterprise.
>
> Chainalysis and similar operations would be, IMHO, well advised to
> cease operations. This doesn't mean they will, but guess what:
>
> Shot over the bow, folks.
>
> Jan Møller:
>> What we were trying to achieve was determining the flow of funds
>> between countries by figuring out which country a transaction
>> originates from. To do that with a certain accuracy you need
>> many nodes. We chose a class C IP range as we knew that bitcoin
>> core and others only connect to one node in any class C IP range.
>> We were not aware that breadwallet didn't follow this practice.
>> Breadwallet risked getting tar-pitted, but that was not our
>> intention and we are sorry about that.
>
>> Our nodes DID respond with valid blocks and merkle-blocks and
>> allowed everyone connecting to track the blockchain. We did
>> however not relay transactions. The 'service' bit in the version
>> message is not meant for telling whether or how the node relays
>> transactions, it tells whether you can ask for block headers only
>> or full blocks.
>
>> Many implementations enforce non standard rules for handling
>> transactions; some nodes ignore transactions with address reuse,
>> some nodes happily forward double spends, and some nodes forward
>> neither blocks not transactions. We did blocks but not
>> transactions.
>
>> In hindsight we should have done two things: 1. relay
>> transactions 2. advertise address from 'foreign' nodes
>
>> Both would have fixed the problems that breadwallet experienced.
>> My understanding is that breadwallet now has the same 'class C'
>> rule as bitcoind, which would also fix it.
>
>> Getting back on the topic of this thread and whether it is
>> illegal, your guess is as good as mine. I don't think it is
>> illegal to log incoming connections and make statistical analysis
>> on it. That would more or less incriminate anyone who runs a
>> web-server and looks into the access log. At lease one Bitcoin
>> service has been collecting IP addresses for years and given them
>> to anyone visiting their web-site (you know who) and I believe
>> that this practise is very wrong. We have no intention of giving
>> IP addresses away to anyone, but we believe that you are free to
>> make statistics on connection logs when nodes connect to you.
>
>> On a side note: When you make many connections to the network
>> you see lots of strange nodes and suspicious patterns. You can
>> be certain that we were not the only ones connected to many
>> nodes.
>
>> My takeaway from this: If nodes that do not relay transactions is
>> a problem then there is stuff to fix.
>
>> /Jan
>
>> On Fri, Mar 13, 2015 at 10:48 PM, Mike Hearn <mike at plan99.net>
>> wrote:
>
>>> That would be rather new and tricky legal territory.
>>>
>>> But even putting the legal issues to one side, there are
>>> definitional issues.
>>>
>>> For instance if the Chainalysis nodes started following the
>>> protocol specs better and became just regular nodes that
>>> happen to keep logs, would that still be a violation? If so,
>>> what about blockchain.info? It'd be shooting ourselves in the
>>> foot to try and forbid block explorers given how useful they
>>> are.
>>>
>>> If someone non-maliciously runs some nodes with debug logging
>>> turned on, and makes full system backups every night, and
>>> keeps those backups for years, are they in violation of
>>> whatever pseudo-law is involved?
>>>
>>> I think it's a bit early to think about these things right
>>> now. Michael Grønager and Jan Møller have been Bitcoin hackers
>>> for a long time. I'd be interested to know their thoughts on
>>> all of this.
>>>
>>>
>>> ------------------------------------------------------------------------------
>>>
>>>
>
>>>
Dive into the World of Parallel Programming The Go Parallel Website,
>>> sponsored by Intel and developed in partnership with Slashdot
>>> Media, is your hub for all things parallel software
>>> development, from weekly thought leadership blogs to news,
>>> videos, case studies, tutorials and more. Take a look and join
>>> the conversation now. http://goparallel.sourceforge.net/
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>>
>
>>>
>
>
>> ------------------------------------------------------------------------------
>
>>
>
> Dive into the World of Parallel Programming The Go Parallel
> Website, sponsored
>> by Intel and developed in partnership with Slashdot Media, is
>> your hub for all things parallel software development, from
>> weekly thought leadership blogs to news, videos, case studies,
>> tutorials and more. Take a look and join the conversation now.
>> http://goparallel.sourceforge.net/
>
>
>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
> ------------------------------------------------------------------------------
>
>
Dive into the World of Parallel Programming The Go Parallel Website,
sponsored
> by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly
> thought leadership blogs to news, videos, case studies, tutorials
> and more. Take a look and join the conversation now.
> http://goparallel.sourceforge.net/
> _______________________________________________ Bitcoin-development
> mailing list Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
- --
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-----
iQEcBAEBCgAGBQJVD6mmAAoJEGxwq/inSG8CkLUH/iWvn7kp6KW2fe5RFca1eAmH
L+5P+kNDzMARIRt8A3CvopoQQMZx44aZ8pMdErUk+78A7oeP/x+scYEkSiXE17Iv
saBWv43mO+qFxgVrU7y+9njwLJoywHitBymhLGisi3hv+H7lfIMdPK2dLVThwxel
bVO0Ga8Y9qDYAwtK23yEOCT7klj5mT0tG50U4HxDpIXaJj8kCnVUC2O1MdYhr1pP
93cDuhBmXOg7sOLAPpdWVhgfnz0Vm8M0ZWUIK+4FGzpQugWHcmdp3YUDCeczOYzD
u5zVdAqvdL6qQcWkUcGfkKaAqfJH3u5F2zeQvDUEJeeEz1lWnrsXuT7cCvcp/TU=
=6io6
-----END PGP SIGNATURE-----