[bitcoin-dev] Increased blockspace enabled by SegWit limited to just witness data?

2018-02-18 Thread CANNON via bitcoin-dev
-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 A5

Re: [bitcoin-dev] NIST 8202 Blockchain Technology Overview

2018-02-18 Thread CANNON via bitcoin-dev
-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

Re: [bitcoin-dev] NIST 8202 Blockchain Technology Overview

2018-02-06 Thread CANNON via bitcoin-dev
-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. > > >

Re: [bitcoin-dev] NIST 8202 Blockchain Technology Overview

2018-01-29 Thread CANNON via bitcoin-dev
-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 + > From: Yaga, Dylan (Fed) > To: C

Re: [bitcoin-dev] NIST 8202 Blockchain Technology Overview

2018-01-29 Thread CANNON via bitcoin-dev
Forwarded Message Subject: RE: NIST 8202 Blockchain Technology Overview Date: Mon, 29 Jan 2018 12:25:05 + From: Yaga, Dylan (Fed) To: CANNON Thank you for your comments. You, along with many others, expressed concern on section 8.1.2. To help foster a full transparency ap

Re: [bitcoin-dev] NIST 8202 Blockchain Technology Overview

2018-01-28 Thread CANNON via bitcoin-dev
-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

[bitcoin-dev] NIST 8202 Blockchain Technology Overview

2018-01-28 Thread CANNON via bitcoin-dev
-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 th

[bitcoin-dev] Single signature for all transactions in a block?

2017-12-31 Thread CANNON via bitcoin-dev
-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 inp

Re: [bitcoin-dev] A DNS-like decentralized mapping for wallet addresses?

2017-12-02 Thread CANNON via bitcoin-dev
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

Re: [bitcoin-dev] A DNS-like decentralized mapping for wallet addresses?

2017-12-02 Thread CANNON via bitcoin-dev
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 dece

Re: [bitcoin-dev] Why SegWit Anyway?

2017-11-26 Thread CANNON via bitcoin-dev
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. Wh

Re: [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover?

2017-04-13 Thread CANNON via bitcoin-dev
-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 wit

Re: [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover?

2017-03-25 Thread CANNON via bitcoin-dev
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" stand

[bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover?

2017-03-24 Thread CANNON via bitcoin-dev
-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

[bitcoin-dev] General bitcoin users mailing list?

2016-08-13 Thread Cannon via bitcoin-dev
I understand this mailing list is for topics relating to development. Is there a general users mailing list for bitcoin related things such as questions that are not necessarily related to dev? -- Cannon PGP Fingerprint: 2BB5 15CD 66E7 4E28 45DC 6494 A5A2 2879 3F06 E832 Email: can...@cannon-ciot