Nostr notes by

📅 Original date posted:2015-10-15 📝 Original ...

2023-06-07T19:43:31+02:00

In reply to nevent1q…7r6d
_________________________

📅 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-----

📅 Original date posted:2015-10-14 📝 Original ...

2023-06-07T19:43:30+02:00

In reply to nevent1q…ysxj
_________________________

📅 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-----

📅 Original date posted:2015-10-13 📝 Original ...

2023-06-07T19:43:17+02:00

In reply to nevent1q…swds
_________________________

📅 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-----

📅 Original date posted:2015-10-13 📝 Original ...

2023-06-07T19:43:15+02:00

In reply to nevent1q…6z0a
_________________________

📅 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-----

📅 Original date posted:2015-10-05 📝 Original ...

2023-06-07T19:42:35+02:00

In reply to nevent1q…2yx8
_________________________

📅 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-----

📅 Original date posted:2015-09-28 📝 Original ...

2023-06-07T19:41:30+02:00

In reply to nevent1q…gad2
_________________________

📅 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-----

📅 Original date posted:2015-08-27 📝 Original ...

2023-06-07T19:38:20+02:00

In reply to nevent1q…wa4s
_________________________

📅 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-----

📅 Original date posted:2015-08-27 📝 Original ...

2023-06-07T19:38:16+02:00

In reply to nevent1q…e9w3
_________________________

📅 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-----

📅 Original date posted:2015-08-19 📝 Original ...

2023-06-07T19:36:10+02:00

In reply to nevent1q…kt3c
_________________________

📅 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-----

📅 Original date posted:2015-08-19 📝 Original ...

2023-06-07T19:35:51+02:00

In reply to nevent1q…7ym5
_________________________

📅 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-----

📅 Original date posted:2015-08-18 📝 Original ...

2023-06-07T19:35:45+02:00

In reply to nevent1q…r6wt
_________________________

📅 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-----

📅 Original date posted:2015-08-11 📝 Original ...

2023-06-07T19:34:07+02:00

In reply to nevent1q…atxu
_________________________

📅 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-----

📅 Original date posted:2015-08-11 📝 Original ...

2023-06-07T19:34:05+02:00

In reply to nevent1q…47r6
_________________________

📅 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-----

📅 Original date posted:2015-08-10 📝 Original ...

2023-06-07T19:33:04+02:00

In reply to nevent1q…wssr
_________________________

📅 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-----

📅 Original date posted:2015-08-10 📝 Original ...

2023-06-07T19:33:03+02:00

In reply to nevent1q…h4tl
_________________________

📅 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-----

📅 Original date posted:2015-08-22 📝 Original ...

2023-06-07T17:48:56+02:00

In reply to nevent1q…hwe6
_________________________

📅 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-----

📅 Original date posted:2015-08-22 📝 Original ...

2023-06-07T17:48:25+02:00

In reply to nevent1q…8rfr
_________________________

📅 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-----

📅 Original date posted:2015-08-18 📝 Original ...

2023-06-07T17:47:28+02:00

In reply to nevent1q…59gt
_________________________

📅 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-----

📅 Original date posted:2015-08-10 📝 Original ...

2023-06-07T17:45:15+02:00

In reply to nevent1q…qhe5
_________________________

📅 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-----

📅 Original date posted:2015-08-03 📝 Original ...

2023-06-07T17:44:36+02:00

In reply to nevent1q…3h74
_________________________

📅 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-----

📅 Original date posted:2015-07-15 📝 Original ...

2023-06-07T17:42:03+02:00

In reply to nevent1q…xcfu
_________________________

📅 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-----

📅 Original date posted:2015-06-23 📝 Original ...

2023-06-07T17:39:48+02:00

In reply to nevent1q…mvm5
_________________________

📅 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-----

📅 Original date posted:2015-06-18 📝 Original ...

2023-06-07T17:38:26+02:00

In reply to nevent1q…lu4c
_________________________

📅 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-----

📅 Original date posted:2015-06-15 📝 Original ...

2023-06-07T17:38:18+02:00

In reply to nevent1q…ep77
_________________________

📅 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-----

📅 Original date posted:2015-06-14 📝 Original ...

2023-06-07T17:37:34+02:00

In reply to nevent1q…c4hu
_________________________

📅 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-----

📅 Original date posted:2015-03-23 📝 Original ...

2023-06-07T17:31:58+02:00

In reply to nevent1q…m03w
_________________________

📅 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-----