<unnamed>

Public Key

npub1vxzlqg5f7ykqr3hheqxdcqe35q02a8rr2mez30sjaldhlvu4hsvsqlz2gn

Profile Code

nprofile1qqsxrp0sy2ylztqpcmmusrxuqvc6q84wn334du3ghcfwlkmlkw2mcxgpzpmhxue69uhkummnw3ezuamfdejszrthwden5te0dehhxtnvdakqz9rhwden5te0wfjkccte9ejxzmt4wvhxjmcf73ezd

Publishing to

nostr.wine

nos.lol

relay.damus.io

Last Notes

2023-06-07 17:58:19 UTC

- reply

📅 Original date posted:2017-03-29
📝 Original message:I believe nearly everyone at Bitcoin Unlimited would be supportive of a UTXO check-pointing scheme. I’d love to see this happen, as it would greatly reduce the time needed to get a new node up-and-running, for node operators who are comfortable trusting these commitments.
I’m confident that we could work with the miners who we have good relationships with to start including the root hash of the (lagging) UTXO set in their coinbase transactions, in order to begin transforming this idea into reality. We could also issue regular transactions from “semi-trusted” addresses controlled by known people that include the same root hash in an OP_RETURN output, which would allow cross-checking against the miners’ UTXO commitments, as part of this initial “prototype” system.
This would "get the ball rolling" on UTXO commitments in a permissionless way (no one can stop us from doing this). If the results from this prototype commitment scheme were positive, then perhaps there would be support from the community and miners to enforce a new rule which requires the (lagging) root hashes be included in new blocks. At that point, the UTXO commitment scheme is no longer a prototype but a trusted feature of the Bitcoin network.
On that topic, are there any existing proposals detailing a canonical ordering of the UTXO set and a scheme to calculate the root hash?
Best regards,
Peter
> On Mar 29, 2017, at 12:33 PM, Daniele Pinna via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> What about periodically committing the entire UTXO set to a special checkpoint block which becomes the new de facto Genesis block?
>
> Daniele
>
> ------------------------------
>
> Message: 5
> Date: Wed, 29 Mar 2017 16:41:29 +0000
> From: Andrew Johnson <andrew.johnson83 at gmail.com <mailto:andrew.johnson83 at gmail.com>>
> To: David Vorick <david.vorick at gmail.com <mailto:david.vorick at gmail.com>>
> Cc: Bitcoin Dev <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>>
> Subject: Re: [bitcoin-dev] Hard fork proposal from last week's meeting
> Message-ID:
> <CAAy62_+JtoAuM-RsrAAp5eiGiO+OHLDjzqgbnF2De7TUU7TyYg at mail.gmail.com <mailto:CAAy62_%2BJtoAuM-RsrAAp5eiGiO%2BOHLDjzqgbnF2De7TUU7TyYg at mail.gmail.com>>
> Content-Type: text/plain; charset="utf-8"
>
> I believe that as we continue to add users to the system by scaling
> capacity that we will see more new nodes appear, but I'm at a bit of a loss
> as to how to empirically prove it.
>
> I do see your point on increasing load on archival nodes, but the majority
> of that load is going to come from new nodes coming online, they're the
> only ones going after very old blocks. I could see that as a potential
> attack vector, overwhelm the archival nodes by spinning up new nodes
> constantly, therefore making it difficult for a "real" new node to get up
> to speed in a reasonable amount of time.
>
> Perhaps the answer there would be a way to pay an archival node a small
> amount of bitcoin in order to retrieve blocks older than a certain cutoff?
> Include an IP address for the node asking for the data as metadata in the
> transaction... Archival nodes could set and publish their own policy, let
> the market decide what those older blocks are worth. Would also help to
> incentivize running archival node, which we do need. Of course, this isn't
> very user friendly.
>
> We can take this to bitcoin-discuss, if we're getting too far off topic.
>
>
> On Wed, Mar 29, 2017 at 11:25 AM David Vorick <david.vorick at gmail.com <mailto:david.vorick at gmail.com>>
> wrote:
>
> >
> > On Mar 29, 2017 12:20 PM, "Andrew Johnson" <andrew.johnson83 at gmail.com <mailto:andrew.johnson83 at gmail.com>>
> > wrote:
> >
> > What's stopping these users from running a pruned node? Not every node
> > needs to store a complete copy of the blockchain.
> >
> >
> > Pruned nodes are not the default configuration, if it was the default
> > configuration then I think you would see far more users running a pruned
> > node.
> >
> > But that would also substantially increase the burden on archive nodes.
> >
> >
> > Further discussion about disk space requirements should be taken to
> > another thread.
> >
> >
> > --
> Andrew Johnson
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170329/9b48ebe3/attachment.html <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170329/9b48ebe3/attachment.html>>
>
> ------------------------------
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170329/ca39b10a/attachment.html>

2023-06-07 17:50:23 UTC

- reply

📅 Original date posted:2016-05-09
📝 Original message:Greg Maxwell wrote:
> What are you talking about? You seem profoundly confused here...
>
> I obtain some txouts. I write a transaction spending them in malleable
> form (e.g. sighash single and an op_return output).. then grind the
> extra output to produce different hashes. After doing this 2^32 times
> I am likely to find two which share the same initial 8 bytes of txid.
[9 May 16 @ 4:30 PDT]
I’m trying to understand the collision attack that you're explaining to Tom Zander.
Mathematica is telling me that if I generated 2^32 random transactions, that the chances that the initial 64-bits on one of the pairs of transactions is about 40%. So I am following you up to this point. Indeed, there is a good chance that a pair of transactions from a set of 2^32 will have a collision in the first 64 bits.
But how do you actually find that pair from within your large set? The only way I can think of is to check if the first 64-bits is equal for every possible pair until I find it. How many possible pairs are there?
It is a standard result that there are
m! / [n! (m-n)!]
ways of picking n numbers from a set of m numbers, so there are
(2^32)! / [2! (2^32 - 2)!] ~ 2^63
possible pairs in a set of 2^32 transactions. So wouldn’t you have to perform approximately 2^63 comparisons in order to identify which pair of transactions are the two that collide?
Perhaps I made an error or there is a faster way to scan your set to find the collision. Happy to be corrected…
Best regards,
Peter

2023-06-07 17:50:23 UTC

- reply

📅 Original date posted:2016-05-09
📝 Original message:[9 May 16 @ 6:40 PDT]
For those interested in the hash collision attack discussion, it turns out there is a faster way to scan your set to find the collision: you’d keep a sorted list of the hashes for each TX you generate and then use binary search to check that list for a collision for each new TX you randomly generate. Performing these operations can probably be reduced to N lg N complexity, which is doable for N ~2^32. In other words, I now agree that the attack is feasible.
Cheers,
Peter
hat tip to egs
> On May 9, 2016, at 4:37 PM, Peter R via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Greg Maxwell wrote:
>
>> What are you talking about? You seem profoundly confused here...
>>
>> I obtain some txouts. I write a transaction spending them in malleable
>> form (e.g. sighash single and an op_return output).. then grind the
>> extra output to produce different hashes. After doing this 2^32 times
>> I am likely to find two which share the same initial 8 bytes of txid.
>
> [9 May 16 @ 4:30 PDT]
>
> I’m trying to understand the collision attack that you're explaining to Tom Zander.
>
> Mathematica is telling me that if I generated 2^32 random transactions, that the chances that the initial 64-bits on one of the pairs of transactions is about 40%. So I am following you up to this point. Indeed, there is a good chance that a pair of transactions from a set of 2^32 will have a collision in the first 64 bits.
>
> But how do you actually find that pair from within your large set? The only way I can think of is to check if the first 64-bits is equal for every possible pair until I find it. How many possible pairs are there?
>
> It is a standard result that there are
>
> m! / [n! (m-n)!]
>
> ways of picking n numbers from a set of m numbers, so there are
>
> (2^32)! / [2! (2^32 - 2)!] ~ 2^63
>
> possible pairs in a set of 2^32 transactions. So wouldn’t you have to perform approximately 2^63 comparisons in order to identify which pair of transactions are the two that collide?
>
> Perhaps I made an error or there is a faster way to scan your set to find the collision. Happy to be corrected…
>
> Best regards,
> Peter
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 17:50:21 UTC

- reply

📅 Original date posted:2016-05-09
📝 Original message:Hi Pieter,
> I tried to derive what length of short ids is actually necessary (some
> write-up is on
> https://gist.github.com/sipa/b2eb2e486156b5509ac711edd16153ed but it's
> incomplete).
>
> For any reasonable numbers I can come up with (in a very wide range),
> the number of bits needed is very well approximated by:
>
> log2(#receiver_mempool_txn * #block_txn_not_in_receiver_mempool /
> acceptable_per_block_failure_rate)
>
> For example, with 20000 mempool transactions, 2500 transactions in a
> block, 95% hitrate, and a chance of 1 in 10000 blocks to fail to
> reconstruct, needed_bits = log2(20000 * 2500 * (1 - 0.95) / 0.0001) =
> 34.54, or 5 byte txids would suffice.
>
> Note that 1 in 10000 failures may sound like a lot, but this is for each
> individual connection, and since every transmission uses separately
> salted identifiers, occasional failures should not affect global
> propagation. Given that transmission failures due to timeouts, network
> connectivity, ... already occur much more frequently than once every few
> gigabytes (what 10000 blocks corresponds to), that's probably already
> more than enough.
>
> In short: I believe 5 or 6 byte txids should be enough, but perhaps it
> makes sense to allow the sender to choose (so he can weigh trying
> multiple nonces against increasing the short txid length).
[9 May 16 @ 11am PDT]
We worked on this with respect to “Xthin" for Bitcoin Unlimited, and came to a similar conclusion.
But we (I think it was theZerg) also noticed another trick: if the node receiving the thin blocks has a small number of collisions with transactions in its mempool (e.g., 1 or 2), then it can test each possible block against the Merkle root in the block header to determine the correct one. Using this technique, it should be possible to further reduce the number of bytes used for the txids. That being said, even thin blocks built from 64-bit short IDs represent a tremendous savings compared to standard block propagation. So we (Bitcoin Unlimited) decided not to pursue this optimization any further at that time.
***
It’s also interesting to ask what the information-theoretic minimum amount of information necessary for a node to re-construct a block is. The way I’m thinking about this currently[1] is that the node needs all of the transactions in the block that were not initially part of its mempool, plus enough information to select and ordered subset from that mempool that represents the block. If m is the number of transactions in mempool and n is the number of transactions in the block, then the number of possible subsets (C') is given by the binomial coefficient:
C' = m! / [n! (m - n)!]
Since there are n! possible orderings for each subset, the total number of possible blocks (C) of size n from a mempool of size m is
C = n! C’ = m! / (m-n)!
Assuming that all possible blocks are equally likely, the Shannon entropy (the information that must be communicated) is the base-2 logarithm of the number of possible blocks. After making some approximations, this works out very close to
minimum information ~= n * log2(m),
which for your case of 20,000 transactions in mempool (m = 20,000) and a 2500-transaction block (n = 2500), yields
minimum information = 2500 * log2(20,000) ~ 2500 * 15 bits.
In other words, a lower bound on the information required is about 2 bytes per transactions for every transaction in the block that the node is already aware of, as well as all the missing transactions in full.
Of course, this assumes an unlimited number of round trips, and it is probably complicated by other factors that I haven’t considered (queue the “spherical cow” jokes :), but I thought it was interesting that a technique like Xthin or compact blocks is already pretty close to this limit.
Cheers,
Peter
[1] There are still some things that I can’t wrap my mind around that I’d love to discuss with another math geek :)

2023-06-07 17:43:55 UTC

- reply

📅 Original date posted:2015-10-30
📝 Original message:> On Oct 29, 2015, at 8:35 PM, Gregory Maxwell via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> On Fri, Oct 30, 2015 at 3:04 AM, Simon Liu via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> Given that UTXO storage is considered critical, it seems reasonable to
>
> This sounds like a misunderstanding of what consensus criticial means.
> It does not mean that it must be right (though obviously that is
> preferable) but that it must be _consistent_, between all nodes.
Can you give a specific example of how nodes that used different database technologies might determine different answers to whether a given transaction is valid or invalid? I’m not a database expert, but to me it would seem that if all the unspent outputs can be found in the database, and if the relevant information about each output can be retrieved without corruption, then that’s all that really matters as far as the database is concerned.
Let’s use an unspent pay-to-pubkey-hash output as an example: Alice spends this to Bob (she signs it properly), the TX propagates across the network and…then what? Do some nodes disagree on whether or not the TX is valid? What exactly would they disagree on? Are you suggesting that a database bug would cause some nodes to think the output was actually already spent, while others can correctly see that it’s unspent? Or maybe some nodes think the output doesn’t exist while others do? Or are you suggesting that the details about this output might be retrieved with errors from certain databases but correctly from others?
I’d like a concrete example to help me understand why more than one implementation of something like the UTXO database would be unreasonable.
Peter

2023-06-07 17:42:50 UTC

- reply

📅 Original date posted:2015-10-06
📝 Original message:> On Oct 5, 2015, at 6:37 PM, Tom Harding via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> On 10/5/2015 1:56 PM, Gregory Maxwell via bitcoin-dev wrote:
>> In this case, I don't even believe we have any regulator contributors
>> that disagree.
>
> Since Gavin Andresen chose you to be one of 4 people who decides whose
> contributions are accepted to the Core project, shouldn't you recuse
> yourself from referencing "regular contributor" as some kind of bar to
> an opinion being worthy?
>
> You don't want to be accused of squelching a person's opinions by
> nacking or sitting on commits, then turning around and branding those
> opinions as worthless because they are not from a "regular contributor."
> Do you?
Great point, Tom!
In fact, you’ve just explained the dynamics that create “centralizing pressure” in regards to development: If the weight of a person’s opinion is proportional to how many commits that person has made, and if the probability of getting a commit pulled is proportional to the weight of that person’s opinion, well…I’m pretty sure this results in a differential equation that has a solution that results in ever-increasing centralized control of the code base.
I believe we should work to deprecate the idea that Core is somehow the “core of Bitcoin," in favour of multiple competing implementations. XT and btcd are two working examples of this idea. Let’s make it easier for the community to determine the evolution of Bitcoin by making it easier for the community to express their vote based on the code we choose to run.
Best regards,
Peter

2023-06-07 17:42:49 UTC

- reply

📅 Original date posted:2015-10-05
📝 Original message:> On Oct 5, 2015, at 2:08 PM, Tom Zander via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Monday 5. October 2015 20.56.34 Gregory Maxwell wrote:
>> (In this case, I don't even believe we have any regulator
>> contributors that disagree).
>
> Regular contributor?
>
> Please explain how for a fork in the protocol should you only listen to
> regular Bitcoin Core contributors?
Furthermore, Bitcoin is significantly more than a "software project": it sits at a unique intersection of computer science, economics, physics, law and more. While I agree that minor bug-fixes and code-maintenance-type issues should be dealt with quietly by developers, decisions regarding Bitcoin’s governance and its evolution should be shaped by an interdisciplinary group of stakeholders from across the community. The hard- vs soft-fork debate is not just a code maintenance issue.
Once again, let’s use the current gridlock in Core to rally the growth of new forkwise-compatible implementations of the protocol. Gavin and Mike’s initiative with BIP101 and Bitcoin XT should be encouraged as one possible model for coming to consensus on hard-forking changes.
Best regards,
Peter

2023-06-07 17:42:49 UTC

- reply

📅 Original date posted:2015-10-05
📝 Original message:> On Oct 5, 2015, at 2:30 PM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
>
> On Mon, Oct 5, 2015 at 9:27 PM, Peter R via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> Once again, let’s use the current gridlock
>
> Allow me to state unequivocally-- since we've had problems with people
> stating non-factuals as fact without getting adequately clear
> correction--, there is no gridlock here and an effort to manufacturer
> one for political reasons will not be successful.
I disagree. There is gridlock in the Core Dev development process.
Peter

2023-06-07 17:42:38 UTC

- reply

📅 Original date posted:2015-10-05
📝 Original message:Dear Bitcoin Development Community:
I would like to share my opinion that Mike is correct regarding the soft fork versus hard fork debate. I agree that CLTV should be done with a hard fork for the reasons that Mike has discussed several times in the past (mainly that a hard forks requires active consensus while a soft fork requires only indifference). I believe this is a controversial change and—if Core Dev believes that controversial changes to the consensus rules must not happen—then my interpretation is that CLTV should not happen in its current form.
I also agree with Mike that Core's requirement for unanimous consensus results in development grid lock and should be revisited. In my opinion, the idea that unanimity is required should be replaced with the idea that the longest chain composed of valid transactions is the correct chain. It shouldn’t matter really how the chain becomes the longest—only that it does.
I believe that a good way to return power to the bitcoin community is to foster mutiple forkwise-compatible implementations of the protocol. Each implementation could have its own governance model and design objectives and use techniques like BIP101’s 750/1000 signalling mechanism to activate changes that may be desirable to the community. If a super majority does not support the change, then it won’t be activated. I created an animated GIF that visualizes one possibility for how multiple protocol implementations might emerge over time:
https://www.reddit.com/r/bitcoinxt/comments/3nhq9t/deprecating_bitcoin_core_visualizing_the/ <https://www.reddit.com/r/bitcoinxt/comments/3nhq9t/deprecating_bitcoin_core_visualizing_the/>
Decentralizing development and supporting multiple forkwise-compatible implementations of the protocol is a worthwhile goal that will simultaneously make Bitcoin more robust and more responsive to the will of the market.
Nodes would express their acceptance of a block by mining on top of it. Consensus would be determined by the code we choose to run.
Best regards,
Peter
> On Oct 5, 2015, at 10:01 AM, Paul Sztorc via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> On 10/5/2015 12:56 PM, Mike Hearn via bitcoin-dev wrote:
>>
>> As everyone in the Bitcoin community has been clearly told that
>> controversial changes to the consensus rules must not happen, it's
>> clear that CLTV cannot happen in its current form.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151005/c03eef97/attachment-0001.html>

2023-06-07 17:38:38 UTC

- reply

📅 Original date posted:2015-08-30
📝 Original message:Hi Greg,
>> I agree that miners may change their level of centralization. This neither
>> affects the model nor the results presented in the paper.
>
> It has tremdous significance to the real-world impact of your results.
The paper makes no claims about "miners changing their level of centralization." Whether it is or is not significant, it is outside the scope of the paper and irrelevant to the result that a fee market exists without a block size limit (given the assumption that some information about the transactions included in a block is communicated between miners during block solution propagation).
> If not for the other errors in your work,
Again, what you are calling "errors" are assumptions--in fact very reasonable assumptions that we know are valid for the network as a whole right now. You are proposing that maybe they won't be valid in the future if the miners move to some hypothetical configuration that you worry may be possible. I say prove it: show rigorously what the network would look like in a case where information about the transactions contained in a block is never communicated with the block solution. How do you get the miners to agree (assuming such a configuration is even physically possible)? Do you need all the miners to agree or only a portion of them? How reasonable is it that the systems moves into such a configuration? I know you spoke to this in your last response, but I mean really prove it...with a mathematical model, with diagrams and charts, with equations, with your assumptions clearly stated so that they can be put to the test--not by waving your hands on the bitcoin-dev mailing list.
This is an exciting field of research and we should encourage people to continue to explore these questions.
> this point would make the
> take away of your work not "a healthy transaction fee market exists
> without a block size limit" but rather "a decenteralized bitcoin
> cannot exist"-- as, accepting the other errors as fact your model
> shows that centralizing mining is always strictly more profitable at
> any level of fee demand; because your model equivilent shows that for
> any level of fee demand and gamma miners could increase their income
> by centeralizing further.
OK, I actually sort of agree with your very last sentence above. My paper indeed suggests that the most "profitable" configuration is one where there is only one "super pool." Is that likely to happen? I personally don't think so because of the game theory involved. But regardless of my opinion or your opinion on that matter, whether it is or isn't likely to happen is outside the scope of my paper. It is irrelevant to the result that a fee market exists without a block size limit given the assumption that there is more than a single miner.
> I absolutely agree that simplifications are useful and essential, but
> it is critically important to call them out before someone mistakes
> theoretical work as useful motivation for policy in the non-simplified
> system.
I do call them out. Furthermore, I've already agreed with you to further clarify these assumptions when I make the other corrections to the paper. Doing so will make the paper stronger.
I'm not going to address the remainder of your email because I believe that we are now talking past each other. I do appreciate the interest and attention that you've paid to my work on the Transaction Fee Market, and I also recognize the important contributions you've made such as coinjoin and HD wallets.
Best regards,
Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150830/a8607804/attachment.html>

2023-06-07 17:38:36 UTC

- reply

📅 Original date posted:2015-08-30
📝 Original message:Hi Greg,
> Unfortunately, your work extensive as it was made at least two
> non-disclosed or poorly-disclosed simplifying assumptions and a significant
> system understanding error which, I believe, undermined it completely.
>
> In short these were:
>
> * You assume miners do not have the ability to change their level
> centralization.
>
> -- In fact they do, not just in theory but in pratice have responded
> to orphaning this way in the past; and it is one of the major
> concerns in this space.
I agree that miners may change their level of centralization. This neither affects the model nor the results presented in the paper.
> * You assume the supply of bitcoin is infinite (that subsidy never
> declines)
>
> -- It declines geometrically, and must if the 21m limit is to be upheld.
> (Though I think this is not equally important as the other concerns)
No I don't. I assume the inflation rate is R/T, where R is a variable.
The last paragraph of the conclusion speaks to the paradox of what happens when R -> 0 as an area for future research.
> * You argue, incorrectly, that amount of information which must be
> transmitted at the moment a block is discovered is proportional to the
> block's size.
>
> -- Instead the same information can be transmitted _in advance_, as
> has been previously proposed, and various techniques can make doing
> so arbitrarily efficient.
I assume, very reasonably, that the block solutions contain information about the transactions included in the block. This is the case today, this is the case using the relay network, and this would be the case using any compression scheme I can personally imagine actually occurring in the future.
(I've always agreed that if block solutions can be communicated to all of the hash power in such a way that they don't include any information about the transactions they contain, then the conditions for a healthy fee market would not be met [this would be gamma --> infinity in my model]).
> [I would encourage anyone who is interested to read the posted off-list
> discussion]
As would I.
> I contacted you in private as a courtesy in the hope that it would be
> a more productive pathway to improving our collective understanding; as well
> as a courtesy to the readers of the list in consideration of traffic levels.
I appreciated the discussion we were having and I thought we had come to some kind of an understanding. I acknowledged that when I made the other corrections to my paper that I would further clarify the assumptions (I agreed that the presentation could be improved).
What was not courteous was that you forwarded the entire private email chain to other people without my permission.
> In one sense, this was a success: Our conversation concluded with you
> enumerating a series of corrective actions that you would take:
>
> --------
>> 1. I will make it more clear that the results of the paper hinge on
>> the assumption that block solutions are propagated across channels,
>> and that the quantity of pure information communicated per solution
>> is proportional to the amount of information contained within the block.
>>
>> 2. I will add a note [unless you ask me not to] something to the effect
>> of "Greg Maxwell challenges the claim that the coding gain cannot
>> be infinite…" followed by a summary of the scenario you described.
>> I will reference "personal communication." I will also run the note
>> by you before I make the next revision public.
>>
>> 3. I will point out that if the coding gain can be made spectacularly
>> high, that the propagation impedance in my model will become very small,
>> and that although a fee market may strictly exist in the asymptotic
>> sense, such a fee market may not be relevant (the phenomena in the paper
>> would be negligible compared to the dynamics from some other effect).
>>
>> 4. [UNRELATED] I also plan to address Dave Hudson's objections in my
>> next revision (the "you don't orphan your own block" point).
>>
>> Lastly, thank you for the note about what might happen when fees >
>> rewards. I've have indeed been thinking about this. I believe it is
>> outside the scope of the present paper, although I am doing some work
>> on the topic. (Perhaps I'll add a bit more discussion on this topic
>> to the present paper to get the reader thinking in this direction).
I stand by all of these four points. My paper wasn't perfectly presented. Making these clarifications will strengthen the manuscript by showing how strong the claim "a healthy transaction fee market exists without a block size limit" is.
> To the best of my knowledge, you've taken none of these corrective
> actions in the nearly month that has passed. I certainly understand being
> backlogged, but you've also continued to make public comments about your
> work seemingly (to me) in contradiction with the above corrective actions.
My public comments have been factual. I've even gone out of my way in several public threads to point out your objection that the coding gain could be zero (even though I think it is flawed "black-and-white thinking" about an academic scenario that will never unfold and might actually be physically impossible without Bitcoin already being centralized).
I'll end by saying that I am the one describing things as the presently are. You are talking about a hypothetical future that may or may not exist (and may not even be possible). The results of my paper logically follow from the assumptions made. You think the assumption that "block solutions contain information about the transactions included in the block" will not hold in the future. Can you show:
(a) Under what assumptions/requirements your communication scheme is physically possible.
(b) That such a configuration is not equivalent to a single entity[1] controlling >50% of the hash power.
(c) That the network moving into such a configuration is plausible.
Best regards,
Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150829/f8e88040/attachment.html>