CANNON [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2017-03-24 to 2018-02-18
💬 Posted a total of 14 messages
📚 Participated in the following categories: bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 18:10:53

- reply

📅 Original date posted:2018-02-18
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
I have a question in reference to the increased blockspace enabled
by the segregated witness upgrade. Is this extra blockspace beyond
the legacy 1 MB limit limited to just witness data?
- --
Cannon
PGP Fingerprint: 2BB5 15CD 66E7 4E28 45DC 6494 A5A2 2879 3F06 E832
Email: cannon at cannon-ciota.info
NOTICE: ALL EMAIL CORRESPONDENCE NOT SIGNED/ENCRYPTED WITH PGP SHOULD
BE CONSIDERED POTENTIALLY FORGED, AND NOT PRIVATE.
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJaiajLAAoJEAYDai9lH2mwDbMQAKgJseZG9oOoP9WJlESFdAzm
jLM69KLF4RVWDQjMWCtyVayyolXMLavW6fL4GL7/ztLYSl9Pz+FDlH3Qgo1GLDx4
fRUkmb0ApLBSAjmdqM+kWjgq3s6/oZaIkNxGeyK5SYY4QhF80Z42PWLBPKjAc7vn
pe7Im13NwtyJiRuCmq4e1z6GmW86fFOKOsR4rlWcftHOFmH8Gz5d9KK9LbPqU6Ca
+rde8yb+A9uXEv3O9MqeLId7FYSJixgzFGJosidVkAVQI7YZ0TAfG4HSwKjtqDz7
SW2Bs3nDeiCr2QN7Su9TUaoSN/yKTBOw5jnql9cNOYuf4GAG0MXWinmYP8MWCiqh
bIrzvOnlZGapX/36Fpab67VDcFnXJJc8ofqYmn+oUoW/q7geQpu/V1oz+AR9nD/d
n8wFxvZdRlTbq2XDXySaontxNH0rd80fSG5SJtO5Js9hK/vNG+Xa7Zc+76gEtvlF
5G1F6MOcsoXUDCnMteuNxaZx6TPML6RuWVmbR1wXOaX4qZ01p7AsjQlTIcrlVDsB
LVGW70wjfETBCffn1JQvFmIK7NzggIUuYfLF0IrfM4BrTa/01RnmfBOpWGiIvyIG
qZqKLYDbW7BDkc/HMtAonR/0t6bTUv/388USSnbMakO9bvih0xxIw4NWTyoSoef/
I+W6ny7qXt+pegLF4cYL
=YqEM
-----END PGP SIGNATURE-----

2023-06-07 18:10:32

- reply

📅 Original date posted:2018-02-06
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 01/31/2018 11:16 AM, Damian Williamson wrote:
> I disagree with the correctness of the following statement:
>
>
>> Rather than implementing the SegWit changes, the developers of Bitcoin Cash decided to simply increase the blocksize.
>
>
> I would suggest "Rather than being satisfied with the implementation of SegWit changes alone, the developers of
> Bitcoin Cash decided to also increase the blocksize.
>
>
> Regards,
>
> Damian Williamson
You do realize that segwit includes many improvements of which are unrelated to scaling? These same improvements of which
simply increasing the blocksize alone would not fix or enable. Segwit is not just a blocksize increase.
Bitcoin Cash, while increasing the blocksize directly, from my understanding has yet to implement the
improvements and capabilities that segwit enables.
One example being, with transactions hashes being able to be calculated in advanced prior to signing
(due to the signature being in different section than that used
to calculate the transaction ID) it is possible to create transaction trees, enhanced smart contracts, trustless mixing protocols,
micropayment networks, etc...
Segwit also increases the security of signatures.
There are lots of other things segregated witness enables as well.
By saying "..segwit changes alone.... decided to also..." Bitcoin Cash has not implemented segwit. Bitcoin Cash only
increased the blocksize.
that wording above at least from the way I read it, seems to imply that Bitcoin Cash has segwit.
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJaeQ3IAAoJEAYDai9lH2mwKkQP/3dgYApq1qv2lGIyZIdeN9SE
D5AuXPqFQYAoMwhC0RPNQU/jUisKIyd6zm4XCIm6KPufCtXkjfH9FLhd0ThbCTcy
Gk+pYYRBzSuBZdPBKg0DHu7alRETtxbdtUI0zDfERt1FFZb+HmcDcGTfwdVci3fa
jBiFXq1R+myMW5xdB44dipSk5kBhcpx2zitr1bIA4rF11QbxKAmzU7iPdRpA+PXz
gB9NImc1Dbz+TEA50tdq3v9Ov3x7m7F+QtBnqyLAigJh6XKa6guCfwKIGoawRGwZ
v2ur7T+Qh3KGRXCBlHnxgtFte16wHagwvsVgE5EEmJR0yJUc/4XU2kCGANVNDZ/P
pphqk8pruQ5rjQ8S+s6i5XG8oHVSB2fDh56NvPY7msA72j+Gk+XneV2eJbEAdjhb
9Ci7u1uPJL3pb3c/ZOwQvpIRV3tRjlh0DertWkd3Li5RZLO3uFvBTxNxrni6+9bf
/cmAOwfHjoUp8BX/nvgMjpIDCoEu+Rv9IO/ok3s3mX300JbczAdGbXbsPTE5G+DI
RB1kSmszwst8wOlOAsdVqk/iKRJdN9daTGGN6aE/wjkpSg8rW9BOaoI2X9t4oXCU
+oe/WlgkxhxPcNyhKpLeeYVe6nFX2fjU+THyyiAq/LJ/qHU/brKpXc4NesCVHhQP
BBlxiN0E4gndMGs/Lx89
=+UCK
-----END PGP SIGNATURE-----

2023-06-07 18:10:32

- reply

📅 Original date posted:2018-02-18
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Pardon my unproffesional tone in my original comment.
But thank you for passing on these corrections. This looks much better.
I have a few comments that might lend to making this even more accurate or complete.
It is nice to see Bitcoin Cash use the proper ticket "BCH" and with
clarrification that segregated witness was a softfork (backwards compatible
and optional to unupgraded nodes) instead of a hardfork. While segwit might
seem to compact more transactions to unupgraded nodes still using the 1 MB
blocksize limit (because signature data is stored outside of this legacy 1MB
limit), segwit is not actually more compact, but rather is a conservative blocksize
increase as a result of the new block space made available through segwit upgrade.
(One question I do have, which I am going to ask on the bitcoin-dev mailing list, is
"Is the increased blockspace made available through SegWit limited to just witness data?")
Segwit is not just about increased blockspace or transaction capactity though, but
also has more advantages as a result of seperating the signature into a different
segment. More information can be found here https://bitcoincore.org/en/2016/01/26/segwit-benefits/
One advantage is with segwit seperating the signature data, advanced smart contracts and functions
on top of bitcoin can be used. This is due to transaction IDs being able to be calculated without
signatures, or before being signed.
Segwit also increases signature security, and if I am correct enables signatures algorithms to be
able to be upgraded via a softfork.
Segwit also enables Lightning Network. Lightning Network upgrade to Bitcoin enables instant and really
cheap transactions which can handle micropayments and massive scaling of throughput of transactions per second.
With micropayment networks such as Lightning Network, payments can be made off-chain, while still being enforced
by and settled on the Bitcoin blockchain. The Bitcoin blockchain would act as a settlement or dispute layer. As
a result this would also result in freed up space on the bitcoin blockchain as well.
The political reasons which differ from the "bitcoin cash" crowd, and the "bitcoin" crowd is the long term vision
of how to scale Bitcoin. The majority of the "bitcoin cash" crowd believes that scaling should be done by
simply raising the blocksize.
The majority of the "bitcoin" crowd, believes that increasing the blocksize to accomodate for all transactions like
what "bitcoin cash" is doing, would lead to dangerous centralization of whom would able to operate a Bitcoin node.
This is due to the factors of both storage, and bandwidth which are needed to sync and store the blockchain by nodes.
https://lightning.network/lightning-network-paper.pdf
Paper:
The Bitcoin Lightning Network:
Scalable Off-Chain Instant Payments
DRAFT Version 0.5.9.2
page 2-3 outlines a good description of why increasing the blocksize to accomodate every global transaction as a scaling
solution is not feasible.
In summary,
So while the majority of the bitcoin crowd see micropayment channels and micropayment networks on higher layers as the
next step in scaling for handling majority of transactions, the "bitcoin cash" supporters prefer to simply increase the
blocksize to handle all these transactions.
I plan on reading the rest of this paper to see if I have any other things to add.
Cannon
PGP Fingerprint: 2BB5 15CD 66E7 4E28 45DC 6494 A5A2 2879 3F06 E832
Email: cannon at cannon-ciota.info
NOTICE: ALL EMAIL CORRESPONDENCE NOT SIGNED/ENCRYPTED WITH PGP SHOULD BE CONSIDERED POTENTIALLY FORGED, AND NOT PRIVATE.
On 01/29/2018 12:25 PM, XXXXXName removed for privacyXXXXXX wrote:
> Thank you for your comments. You, along with many others, expressed
> concern on section 8.1.2. To help foster a full transparency approach
> on the editing of this section, I am sending the revised section to
> you for further comment.
>
> 8.1.2 Bitcoin Cash (BCH)
> In 2017, Bitcoin users adopted an improvement proposal for Segregated Witness
> (known as SegWit, where transactions are split into two segments:
> transactional data, and signature data) through a soft fork. SegWit
> made it possible to store transactional data in a more compact
> form while maintaining backwards compatibility. However, a group
> of users had different opinions on how Bitcoin should evolve and
> developed a hard fork of the Bitcoin blockchain titled Bitcoin
> Cash. Rather than implementing the SegWit changes, the developers
> of Bitcoin Cash decided to simply increase the blocksize. When the
> hard fork occurred, people had access to the same amount of coins
> on Bitcoin and Bitcoin Cash.
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJaiabpAAoJEAYDai9lH2mwOVMP/id1xlK7Z7Sx0YpRD0SOHPw2
Ly/C42TQKH/w5zW5NnzndFJhgrLw68FDHcNRXF7NkryJBH9uZC0PuK/F7p2fGfdc
OAGAnz6dGJKi3aIXS9wyuLXCOBRuBN/PEOTiYk8t7HZ8n60Lsdo5zMxZhuS7QNdu
g1w3UtosNNXU5+9l4LpcRfynXSCCnh1EnNHa9qTIjmCJIjphnpu/hGVAIYWrYwof
AgcEMnv+KseYl6zWs7l5+nevAiDjxrUGEuHDUD9N0+kSLYv3Jsp8t++6q5gdtAI4
xfbyZaIOrSidSe3iSNCnHYuf6TQ/+RstvgPd4VfPJsCK+jVxuJ5R3MC0b5+3cWGU
iUnYsPuX7lKE00B/tW8gVoyVtzYc4eiv8Tp50GeI4Gv6n4K+QuKM82S9DPfn1Ku8
1vJpyL4LrZLkhmYGdTt2ajmg88wXpcySfaPa+xEY0bFziqEqnKgQgwAv1p3a5PbM
WCU2x8Hrv8mMR/RCpo4I0QmkdZfM6ITHGRX/WZa3MVdHB8C1hqT574AKyWvzse4K
YxIdbDZU0cjE5o7oOqTRAF1uR7XD2v8XAbyqQJaHi9z9n8l+CbyEXwNIHAWTkPPb
OVGmnECTCxE0ZZAyaYWaAEnK3FnYEWlF92LKUmjQxD6+1YkCiEe0X2AwFibXw3at
FPcZUkjeX+c7YDArq20l
=Ryov
-----END PGP SIGNATURE-----

2023-06-07 18:10:23

- reply

📅 Original date posted:2018-01-28
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Slight correction to email I just posted titled "NIST 8202 Blockchain Technology Overview"
The date in top of email states Jan 20, corrected date is Jan 28th which can be validated
also by verifying my signature (gpg includes timestamp when signing).
I also sent email with corrected date to NIST comments email address.
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJabnPNAAoJEAYDai9lH2mwzywP/Rr5qlkfihE6SkUZrMRp2G1R
jANSEOMgH3yj7UmNKO2Xqzw93ZyNxNIVAL7z2ru2A6D0ziPgMOUKzyTXbDDpqtJR
mvnI0pe50UpDIbpBMx18X6pGw97LlnEYR81UKeEUPJWDzE1auJiuBr+teHMqVA5O
DjGqYVQM/3LEK2yeKfYcTtxBqnHE3jwGnqV7AviHT6KqxmKuLQe18Rs+wNR9wmWO
RYSsp3lD0sIYAC/snZx1c3NrwnB5kbwTbISzYLF5wK6WOcguoUPTFnZ7x1uEHImt
pbDdgDKnkuUusHTGQJEz+0xYjugcYImP12nx73qrUUJBq17g9BdfhdBGlRXabIzu
STRDw3gwnoqfXcJLeJ8/3ICauA8TCkugp8vXXbQ+Gk5G/DXMYokR/DvxmTzWmvky
58vhrKOEFvVz9FBd6OALVbghQFVC8vtqvXB+AoM5bzHASlN+yOpt7wC4EOROla6f
qSusq3xvp3aybui5tmlTOQtvMV4kxxoqA/HFmJ/Wdxm3/oQdGCHw5qrlMtjILuM5
B5l+7UDbIiw6Vvi/ouGP7OekzJkTZo1tYY/95yXfg3I9cjv6wgEaRzHrVjF3o/FP
FQL4GN/Fnjz7E8VQ/w0ttJ+sRyoIMvd16FcRRIC0LzpsczlWuhpBfdxuSry80Loi
gztvxP9+MJVhJ5kZ27BJ
=BxwT
-----END PGP SIGNATURE-----

2023-06-07 18:10:22

- reply

📅 Original date posted:2018-01-30
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 01/30/2018 01:43 AM, CANNON via bitcoin-dev wrote:
>
>
> -------- Forwarded Message --------
> Subject: RE: NIST 8202 Blockchain Technology Overview
> Date: Mon, 29 Jan 2018 12:25:05 +0000
> From: Yaga, Dylan (Fed) <dylan.yaga at nist.gov>
> To: CANNON <cannon at cannon-ciota.info>
>
> Thank you for your comments.
> You, along with many others, expressed concern on section 8.1.2.
> To help foster a full transparency approach on the editing of this section, I am sending the revised section to you for further comment.
>
> 8.1.2 Bitcoin Cash (BCH)
> In 2017, Bitcoin users adopted an improvement proposal for Segregated Witness (known as SegWit, where transactions are split into two segments: transactional data, and signature data) through a soft fork. SegWit made it possible to store transactional data in a more compact form while maintaining backwards compatibility. However, a group of users had different opinions on how Bitcoin should evolve and developed a hard fork of the Bitcoin blockchain titled Bitcoin Cash. Rather than implementing the SegWit changes, the developers of Bitcoin Cash decided to simply increase the blocksize. When the hard fork occurred, people had access to the same amount of coins on Bitcoin and Bitcoin Cash.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
This is much better than the original. My question, the part where it says segwit makes transactions more compact, I thought that transactions are not more compact but rather they just take advantage of extra blockspace beyond that of 1 MB? Yes they would appear to be more compact to un-upgraded nodes due to the witness being stripped, but the transactions are not actually more compact right?
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJab+afAAoJEAYDai9lH2mwCDAP/RRpExXmnPzlvxuhhJ+8gSlc
QRZHVa0nJ2SETTZnQSa+0t8dBO9ROYSnDHuMEqz/ba8o00Rce8icxQvCGOO29OSK
Cru7/UJzYTwnt5mK2ljpUB1Fsx96fAPxfg4QMeDCRe+O5LLkH1als1GGVOwlFnLu
BAV0MoCljWzBxokf0ax8+ZHHYEaKe+Fj9PKby7CZrqQKoL9PkI/n7EvqICUdTCu5
tAz9SNIBVtUxgGx/ZY96hvBx0zorV1IQEWchQ50oh/V+TgmnOW4njQOKc4TcSgfp
TKpRFs8Zd7TzeIS/85GX0APGypchxdjlBaV0EORTO9GYFo7nKlzHkIGOF9Er+E6q
II4qjbKLc5d/wwCIA8MHFW0Vxwv2+0ztApaWAFW42+LeHERaPCzi4NEy5quqvmsE
IiTaGebl2XbTd0I+aB6WWsScTUmfXrt+NL05kwE0KDylY/mSwYMgYjP95X1Mci7X
rcJRf6/pP607EiHlq3MmDlyt4TrYBp9FVVjdjvM+sD8wz72FhWeYJQdyF8t1ToOD
U/ItNsxl5Jx9JvCkBXoX+6MMZ91W7D2x04Ur3OMRmy/lOoztOYAdlKy0tMyRqfCi
L81apfjvmTaR2OTWhCawgZGLXGJcfOG5ECuXC90B6il5Jsts/XwyFMN2Fa1iZB50
cZwF3ySKxoVtpsf/vTW7
=feRa
-----END PGP SIGNATURE-----

2023-06-07 18:10:22

- reply

📅 Original date posted:2018-01-29
📝 Original message:-------- Forwarded Message --------
Subject: RE: NIST 8202 Blockchain Technology Overview
Date: Mon, 29 Jan 2018 12:25:05 +0000
From: Yaga, Dylan (Fed) <dylan.yaga at nist.gov>
To: CANNON <cannon at cannon-ciota.info>
Thank you for your comments.
You, along with many others, expressed concern on section 8.1.2.
To help foster a full transparency approach on the editing of this section, I am sending the revised section to you for further comment.
8.1.2 Bitcoin Cash (BCH)
In 2017, Bitcoin users adopted an improvement proposal for Segregated Witness (known as SegWit, where transactions are split into two segments: transactional data, and signature data) through a soft fork. SegWit made it possible to store transactional data in a more compact form while maintaining backwards compatibility. However, a group of users had different opinions on how Bitcoin should evolve – and developed a hard fork of the Bitcoin blockchain titled Bitcoin Cash. Rather than implementing the SegWit changes, the developers of Bitcoin Cash decided to simply increase the blocksize. When the hard fork occurred, people had access to the same amount of coins on Bitcoin and Bitcoin Cash.

2023-06-07 18:10:21

- reply

📅 Original date posted:2018-01-28
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
January 20 2018
(I am also forwarding this message to the bitcoin mailing list just in case there
are other technological errors that could use correction in this draft paper or
anything that should be added with my comments.)
To the authors of this paper,
I am commenting on Draft NISTIR 8202 Blockchain Technology Overview located at
https://csrc.nist.gov/CSRC/media/Publications/nistir/8202/draft/documents/nistir8202-draft.pdf
Just in case that document is modified or removed I have also downloaded
it to redistribute this error ridden draft at a later point if neccesary,
and I also had the Internet Archive save a copy here for sake of archival reasons
to give context to this message.
https://web.archive.org/web/20180124170359/https://csrc.nist.gov/CSRC/media/Publications/nistir/8202/draft/documents/nistir8202-draft.pdf
There are a couple things I would like to contribute on regarding some
corrections needed in this paper. I must say, the content in this paper is
making me doubt the credibility of the NIST. I am starting to wonder if the
NIST is also incompetent with lack of credibility just like with most other
government institutions. Falsified information published as truth such as this
only expose their ignorance and incompetence and also propagate such ignorance
to other institutions and people whom rely on NIST for information or research.
The information presented in this paper is technologically invalid and contains
false information. I understand that mistakes happen, but this specific section
regarding "8.1.2 Bitcoin Cash (BCC)" is obviously written without prior research.
Even if research was done no citation is included to back these claims.
I ask you to please conduct research and validate information before publishing it,
especially when the credibility of the NIST is at stake.
I will proceed to outline some corrections.
1. Bitcoin Cash uses the ticker BCH, BCC is the ticker for BitConnectCoin
2. "When SegWit was activated, it caused a hard fork"
This is incorrect information. Segwit was not a hardfork. Rather segwit was
a softfork meaning that it is backwards compatible with unupgraded nodes and
miners. With it being a softfork it actually prevents a fork in the blockchain
by still being valid to unupgraded nodes and miners. Because segregated witness
is not a hardfork its use is optional.
3. "and all the mining nodes and users who did not want to change started
calling the original Bitcoin blockchain Bitcoin Cash (BCC)"
The original bitcoin blockchain is still called Bitcoin. Segwit did not create
any fork in the blockchain. Bitcoin Cash however was a hard fork that resulted
in a forked blockchain and new altcoin.
Bitcoin is Bitcoin,
Bitcoin Cash is Bitcoin Cash.
4. "Technically, Bitcoin is a fork and Bitcoin Cash is the original
blockchain."
Technically, that statement is not truth.
Bitcoin Cash was forked from the original Bitcoin blockchain to create
the altcoin "Bitcoin Cash" (BCH) by people whom believe that the blocksize
should be large enough to accomodate all individual transactions on the main
chain. Without going into any of my personal opinions of which one is better
(bitcoin vs. "bitcoin cash") technically Bitcoin Cash was a hardfork and is
not the original chain but a forked one. It is a hardfork as the blocks
generated by BCH are incompatible with BTC nodes. Because of this lack of
backwards compatibility, and the resulting fork in blockchain is why BCH is
technically a hardfork.
This is just one section of this paper I have read thus far. It makes me
wonder how many other fallacies are throughout this paper. I also wonder how
many other NIST papers exist out of draft form that contain errors. Even
the smallest amount of research could have prevented this in the case of
this paper, unless you are intentionally pushing false information.
I hope these comments are of benefit to the improvement of this paper.
Cannon
PGP Fingerprint: 2BB5 15CD 66E7 4E28 45DC 6494 A5A2 2879 3F06 E832
Email: cannon at cannon-ciota.info
NOTICE: ALL EMAIL CORRESPONDENCE NOT SIGNED/ENCRYPTED WITH PGP SHOULD
BE CONSIDERED POTENTIALLY FORGED, AND NOT PRIVATE.
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJabmySAAoJEAYDai9lH2mwVPcP/ika01NHFMBbxVU9OKc4Ibrd
12MpWW2sgvB14dm8NIuh/xQeFpxGjKvkwWCzqj0pSOE+WClVdK573MJcZF1hqnR4
iPNIr3noR632Hyl9V3Cst5hg5BiUmwETpsyDXG7q7Oj/bX3QAR+psjahk2H2gA6v
i4m1BP4052eRymznJ8aRQc1ak23C4ylLvjC3RRfNmXozG77N4w+tQvFXq45yQam+
nh/8EIck5D9vNTOtVgzgjVqQwfDgUsxgClqHGLNiUOSSievCQLhz1WynDZZSlKmf
Y1Gd70fBpHdrhLBe/SOLglZXPU2BTlicUoN/t9P+5i4qzPfNxfMW9eRi/Urd4sJX
INUuEUMJ2m5EspFjv3rMT19ELts8WhGskBq/4OCT8Wlb9arzhvrDySzLdX5ij75V
DhIX1r3CMDVN4HNb1V4M+Je4Wgle7oh+LS2QDjBnw3IMfjF37j+3OXiRDrlAkE30
GNg0SooANGBvMIMdjnc8fwIV/TxeNh0vEj8M2a4VjbthiDT4L1a4CzxOqT3eWbvB
YHUdz+hwSnydkj5EhyC2e0XN3zqvgSNYoE8HTvKG78ik49bZpxkssEuMWC5N+KM8
j2pgzbVdJXu08mwxrgf2wylUpR630WAEXkcVg3rOw+irPl1U0VxzNL8eNFZehMe6
nuUyXL4VMlApOgesmrCI
=RQoE
-----END PGP SIGNATURE-----

2023-06-07 18:09:06

- reply

📅 Original date posted:2017-12-31
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
I had a question relating to scaling and privacy enhancements.
I believe that segwit combined with aggregated signatures
and coinjoin can potentially achieve such. The idea is to
use aggregated signatures in conjunction with coinjoin. So
that all inputs of a coinjoin transaction would have a single
signature vastly decreasing size while having privacy at the
same time. If majority of transactions in a block did this I
assume that significant more transactions could be fit into a
block? However the question I have, with the extra blockspace
made possible by segwit, is this extra blockspace limited to only
witness data or can it be used for transaction data such as the
scenario I have described here?
- --
Cannon
PGP Fingerprint: 2BB5 15CD 66E7 4E28 45DC 6494 A5A2 2879 3F06 E832
Email: cannon at cannon-ciota.info
NOTICE: ALL EMAIL CORRESPONDENCE NOT SIGNED/ENCRYPTED WITH PGP SHOULD
BE CONSIDERED POTENTIALLY FORGED, AND NOT PRIVATE.
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJaSXSNAAoJEAYDai9lH2mwRy4QAMqhl6UWNqRy7ziDuxukm+nZ
jWtjyc8G38b9r9Nya13/GslHWeEDdSmma6e7afFMVX1y9Qj+t0EZDJVlMMy8JRZr
zDmSdXDxStNv6T+L3NVbSOBhdP+1MpcsvAAs3yd0Nl5cxfBF87ArHlXMbTLJF86S
1gijI4pg3x83tDg/Di6gf9BHk2oXGDc4vraF6LsMDTfQmp7S8pivnswaaEyb6etH
39ei6L3wkV7LvTmA2onCAB8vZtTuARhNuLTYSPfH5LAC4hha2bOCXci3p4Mz4qh3
U4LqUnuYVR8nYOFFsrfhKggN3kptVWhrbDAoHR2fLoYDmfbMkqUdyjdmmc2Rvlgm
eMJvpG91dYb+Q6JqTrar6DH+XSvoOVSWnBLe8Uwf4AnzGxMUpkTDzkyaBxGq4K1u
Vv2Yg808KwA47MKKpvKSckB350YAq9Cr276Lq/giUrxmS1gOyDKDjm1e3yFLM+6d
NancAwgnp17q43FwSX44cT0ISxk9USnWVhaKDQjSGK8MnirkZ1vuu2SshEW1AVhm
44Bt5nQdLmJDw7rqwkjv66sxofXvmCAnPD+p4yiVyfLNZ7OKw6XNcKm3zKAch2Fy
fefWbZnw0yEA3IhNPiMZOSv/YnwTtfzpFUNuTCtLehs+3Xkp0bl72JDz0HRVYbHM
RbsrLp60rD5kuJBq5dl7
=3gku
-----END PGP SIGNATURE-----

2023-06-07 18:08:04

- reply

📅 Original date posted:2017-12-01
📝 Original message:On 11/30/2017 10:20 PM, mandar mulherkar via bitcoin-dev wrote:
> Hello,
>
> I am new, so apologies if this has been asked before.
>
> Here are a few questions to start with -
>
> I was wondering in terms of mass adoption, instead of long wallet
> addresses, maybe there should be a DNS-like decentralized mapping service
> to provide a user at crypto address?
Check out namecoin, there is also blockstack as someone mentioned, but I personally feel namecoin is technologically better.
If do not want a static bitcoin address mapped to a username, could use a stealth address (we need more
support for stealth addresses in bitcoin wallets).

2023-06-07 18:08:03

- reply

📅 Original date posted:2017-12-01
📝 Original message:On 12/01/2017 03:15 AM, Lucas Clemente Vella via bitcoin-dev wrote:
> Unfortunately it didn't catch, but it would
Interesting, I just mentioned namecoin literally seconds before this email arrived.
Saying "it did not catch" is not accurate I'd say. It still works great, and namecoin
has actually made great progress this year 2017. I'd say that namecoin has great potential
but just not widely adopted yet.
Would be real nice to have namecion support in major bitcoin wallets for name to data mapping.

2023-06-07 18:07:51

- reply

📅 Original date posted:2017-11-25
📝 Original message:On 11/21/2017 01:16 PM, Adán Sánchez de Pedro Crespo via bitcoin-dev wrote:
> 2. SegWit signatures can be cheaper to verify (linear instead of
> quadratic). Prior to this, DoS attacks were possible by using forged
> transactions including signatures which could take several minutes to
> verify.
Where can I find more resources on this described DoS attack?
And how does SegWit prevent this if using SegWit transactions are not enforced?
Thanks

2023-06-07 18:00:02

- reply

📅 Original date posted:2017-04-13
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 03/24/2017 04:27 PM, Emin Gün Sirer wrote:
> Because there's no consensus on the contents of the mempool, this approach
> is unsafe and will lead to forks. It also opens a new attack vector where
> people can time the flood of new transactions with the discovery of a block
> by a competitor, to orphan the block and to fork the chain.
>
I know this is a delayed reply.
Without intending to revive an older thread, my intentions are to clarify
what I have meant in my original post just in case anyone misinterprets
where I said
"For example would be something like this:
If block = (empty OR <%75 of mempool) THEN discard
This threshold just an example."
I should have clarified that with this idea blocks would not be rejected if
does not match what that nodes have in their mempool, because as you have said,
there is no consensus on the contents of mempool and the mempool will vary from
node to node.
Instead what I have meant is that with this idea, nodes would only reject blocks if
they are empty or less than a determined percentage when compared to what is in mempool.
While this specific defense proposal I posted may or may not be a good idea, was only
throwing this idea out there to create discussion on possible defenses against an empty
or near empty block attack.
- --
Cannon
PGP Fingerprint: 2BB5 15CD 66E7 4E28 45DC 6494 A5A2 2879 3F06 E832
Email: cannon at cannon-ciota.info
NOTICE: ALL EMAIL CORRESPONDENCE NOT SIGNED/ENCRYPTED WITH PGP SHOULD
BE CONSIDERED POTENTIALLY FORGED, AND NOT PRIVATE.
If this matters to you, use PGP.
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJY8DIZAAoJEAYDai9lH2mwZKYP/jNJjyTeE09+IlsGolPV3Vp+
suJmUK26y8IbEzGxa8eVoX3w7407VNzqeT0jF8vK7oy97EPgszoiutbzYanKYH27
Rpck+FdW/Q5o6jqw59swX+KEvVao52ETPX3kV8ae5uA2txOBnn6C0qZbM5OxPVLN
IHr7E0+bn9BQVuTzhep1wNWi4cDzyeIjYfRGArBTkuSBKxFtbPmTMLa67qsBGKVu
JcGYm6rdDO0iVAR9od/Is9b+3gTW49x/3jBEdg7iCHc8KuGOilZaHfyU6xjt3fPo
L2lxXxUuobFD68/f4ervFVMpAPpmPaS/MEkHMIhJex3szdlSe/WZsQm+2/j799Rg
Ba62pMOYvSR43WwlwX8eySUlVsPtJNtObKnRvDBOmOICgsZ3T9tHKjI+9IPVi9Ib
s7yBBA1LFw4+c8wirzu1aaeDroJ3icqfU+tRe+nadQN1PMepk6sBUMu13bm8B3E3
R8oo+jFZRRvJmx7HDDlJX9GHri8hktCNm/gtt0ksWwEgAQHixukmKoDVssAmsiZ4
BbiWIA3ULciSKM782zDH7/GvDBbOurtV8TeubnV7DDARIA86COwuGjjk30Ltf3ia
5gnFIicLkmdRMh4AU0jvvEpxrHWFFJmreoR+jnAXHMBGoA6ExVaqR2VQzcpb5SIb
sqe/5499BqvJqS4ZFn7f
=q+nx
-----END PGP SIGNATURE-----

2023-06-07 17:57:47

- reply

📅 Original date posted:2017-03-25
📝 Original message:On 03/24/2017 07:00 PM, Aymeric Vitte wrote:
> I don't know what "Time is running short I fear" stands for and when 50%
> is supposed to be reached
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 03/24/2017 07:00 PM, Aymeric Vitte wrote: > I don't know what
"Time is running short I fear" stands for and when 50% > is supposed
to be reached
According to current hashrate distribution tracking site coin.dance,
very likely within less than four weeks according to current hashrate
takeover rate.
While a fork is very likely, that I dont really fear because worst
case scenario is that bitcoin still survives and the invalid chain
becomes an alt. My fear is the centralized mining power being used
to attack the valid chain with intentions on killing it. [1]
Shouldn't this 50% attack they are threatening be a concern? If it
is a concern, what options are on the table. If it is not a concern
please enlightent me as to why.
[1] Source:
https://www.reddit.com/r/Bitcoin/comments/6172s3/peter_rizun_tells_miners_to_force_a_hard_fork_by/
Text:
The attack quoted from his article:
https://medium.com/@peter_r/on-the-emerging-consensus-regarding-bitcoins-block-size-limit-insights-from-my-visit-with-2348878a16d8
[Level 2] Anti-split protection Miners will orphan the
blocks of non-compliant miners prior to the first larger block
to serve as a reminder to upgrade. Simply due to the possibility
of having blocks orphaned, all miners would be motivated to
begin signalling for larger blocks once support definitively
passes 51%. If some miners hold out (e.g., they may not be
paying attention regarding the upgrade), then they will begin
to pay attention after losing approximately $15,000 of revenue
due to an orphaned block.
[Level 3] Anti-split protection In the scenario where Levels
1 and 2 protection fails to entice all non-compliant miners to
upgrade, a small-block minority chain may emerge. To address the
risk of coins being spent on this chain (replay risk), majority
miners will deploy hash power as needed to ensure the minority
chain includes only empty blocks after the forking point. This
can easily be accomplished if the majority miners maintain a
secret chain of empty blocks built off their last empty
block publishing only as much of this chain as necessary
to orphan any non-empty blocks produced on the minority chain.
- --
Cannon
PGP Fingerprint: 2BB5 15CD 66E7 4E28 45DC 6494 A5A2 2879 3F06 E832
Email: cannon at cannon-ciota.info
NOTICE: ALL EMAIL CORRESPONDENCE NOT SIGNED/ENCRYPTED WITH PGP SHOULD
BE CONSIDERED POTENTIALLY FORGED, AND NOT PRIVATE.
If this matters to you, use PGP.
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJY1pbaAAoJEAYDai9lH2mwOO0QANOWqGzPNlifWguc+Y5UQxQM
eAiztAayQBoAyLcFE7/qdtSNlUxbIAHG17fM+aNkehjYH2oN5ODJ+j7E2Yt6EoUH
h5t8MLhNRG/YGF1hJK8Io940EmdcjuNmohiZvrjIqEOYggmLU3hR6J4gsuGsQQhu
gY3sMS/TtT+gZNH8w53ePGrsVhuQR7yEMMr91/vM4+Q5abpwqLeYLnslaZDcd3XK
VB9vyyK08r34J1GQt/H4UvTvGs28MFKBkvueA/Sfyvnrih7+WSQLuSvhiFr+cW1B
TmSVYrB2DzyHN27jDCI2ty3ryNE4PMYcaeLfI2TTbsD/MuVU5lK0kM/1JajP4eRj
j+P03OipuQiy/dNU63w0Uka2PbdKhDC13hVtK/ttBbNppbjnGeB9PYSJCzOpInGw
NwAyz0rVS/llGsdctcII7Z6AUMGuJXzsosY8vjUroU+KFRDqIbDfC53sH7DaPh7u
YawwId5S5RnZsAGCUJ+qNcg0s728J1eDjofN291IS5sOKMzpI7KhaOhFxjnk1MpN
ZAlQeTlvG+sAdn61QMQK1NbFt0km+jcqyVh0+L01yB0K4VDi1YFJaSBOaYUELBXa
8a6WhZf5nrl5UIpH7rRcPzzqchcdYczy5VRZp2UsU+HYeqLXlcN0a03yPpVQik9S
/T93MuZgmvSCry5MlccA
=R71g
-----END PGP SIGNATURE-----

2023-06-07 17:57:44

- reply

📅 Original date posted:2017-03-24
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
When the original white paper was written the idea was that nodes
would be miners at same time. That the distribution of mining power
being mostly on par with the distribution of nodes if I understand
correctly. The problem we face now I fear, is the mining power
becoming centralized. Even if every bitcoin node invested a $1000
into mining power and mined at a loss, it still would not even
make a dent in hash distribution. Currently there are around 6000
known nodes. If each node invested $1000 for say 10 ths of hashing
power. At current hashrate of around 3,674,473,142 GH/s this would
only make up %16 of hash power. This is out of balance as while
nodes are distributed mining power is becoming very centralized
due to the creation of monopolization of ASICs. The problem we
are facing is a small group of a couple people whom control a
large amount and growing of hash power. At time of this writing
it has quickly risen to 39% and at current rate will soon become
50% of hashing power that is controlled by a small group of a few
people. Their intentions are too hijack the bitcoin network to a
cryptocurrency that suits their dangerous agenda. Dangerous because
their plan would centralize power of consensus as I understand it,
to themselves the miners. Dangerous also because the code base of
the attempting subverters is buggy, insecure, and reckless from a
technological standpoint. Even though they only have very minute
amount of nodes compared to legitimate bitcion nodes, the danger
is that they are very quickly taking over in mining power. While
it is true that nodes will not accept invalid blocks that would be
attempted to be pushed by the conspirators, they are threatening to
attack the valid (or in their words, "minority chain") by dedicating
some mining power soley to attacking the valid chain by mining empty
blocks and orphaning the valid chain. So even though the majority
of nodes would be enforcing what blocks are valid and as a result
block the non-compliant longer chain, the conspiring miner can simply
(as they are currently threatening to) make the valid chain unuseable
by mining empty blocks.
If a malicious miner with half or majority control passes invalid
blocks, the worst case scenario is a hardfork coin split in which
the non-compliant chain becomes an alt. However the problem is that
this malicious miner is very recently threatening to not just simply
fork, but to kill the valid chain to force economic activity to the
adversary controlled chain. If we can simply defend against attacks
to the valid chain, we can prevent the valid chain from dying.
While empty or near empty blocks would generally be protected by
the incentive of miners to make money. The threat is there if the
malicious miner with majority control is willing to lose out on
these transaction fees and block reward if their intention is to
suppress it to force the majority onto their chain.
Proposal for potential solution Update nodes to ignore empty blocks,
so this way mined empty blocks cannot be used to DOS attack the
blockchain. But what about defense from say, blocks that are
not empty but intentionally only have a couple transactions
in it? Possible to have nodes not only ignore empty blocks,
but also blocks that are abnormally small compared to number of
valid transactions in mempool?
For example would be something like this:
If block = (empty OR <%75 of mempool) THEN discard
This threshold just an example.
What would be any potentials risks
and attacks resulting from both having such new rulesets and not
doing anything?
Lets assume that the first problem of blocking empty or near empty
blocks has been mitigated with the above proposed solution. How
likely and possible would it be for a malicious miner with lots of
mining power to orphan the chain after so many blocks even with
non empty blocks? Is there a need to mitigate this?
If so is it possible?
Time is running short I fear. There needs to be discussion on various
attacks and how they can be guarded against along with various
other contingency plans.
- --
Cannon
PGP Fingerprint: 2BB5 15CD 66E7 4E28 45DC 6494 A5A2 2879 3F06 E832
Email: cannon at cannon-ciota.info
NOTICE: ALL EMAIL CORRESPONDENCE NOT SIGNED/ENCRYPTED WITH PGP SHOULD
BE CONSIDERED POTENTIALLY FORGED, AND NOT PRIVATE.
If this matters to you, use PGP.
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJY1UH/AAoJEAYDai9lH2mw2QYQALDLBxjdO5WTG7VXfuAE476p
D3o1MMGw23tb+DFUO5WV6aFqfy3VSxbVXz6UuWbj6kHgp3ys6qxg5TX0Dy8tKSZM
V28kovuS/pfen4gTxw1FCNff7YVW1R8QX+cSYxSD5EoEaTbpIPgi8zMusDxUVZk2
WG3ItoyvkLvoNIYGDcU3gR3UkjDS5lOPiHu5BKSj1dEiibOXhr8JEBCznfUSyxCG
TjVRJaUPlwCU06nad8jAZiDrsW3l866iNkBKaMzMavYuMLvCGIdRkbf54B2ZlIT/
S/owusxqeIdQpydi/3ydnrqyeWo3znMnn+oOvdvfYEHKLts6gar3Zv8cZ40yYSIE
z7C7GQFIo5TYDUNOk+2VE7NNtdX39Wj3gJql/305miaIt0qMsf1D30ODjePwyxUQ
LQ96ZeF1K/0RSTN5TFvLjV9ZmaaN/tFm3kx0PunptJaZT8d9EgMeHREjCF4di04A
6Dp3Qeug41X/zdIc2AM387QnPwmGB1TpfrY9qgvcrIe26T6An2V5LHwVmslCX3ui
DYAl0o5ODQqnnakF1FIrr1blMVqm7FqDPQc1I5TfzQuxX2+x+5zdrciPC2HUMCMQ
jMujge5IdGL3kjEwjt+M6kqLu0/T0fhdUetb2DWrRJUcEVoIaiUL7qLJC+4KMR3d
Gu3oWoE1ld+BC6At28AD
=SSuj
-----END PGP SIGNATURE-----