Alex Morcos [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2014-02-13 to 2022-01-13
💬 Posted a total of 47 messages
📚 Participated in the following categories: Bitcoin-development, softfork proposal, bitcoin-dev, BIP Proposal, Update
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 18:06:37

- reply

📅 Original date posted:2017-09-29
📝 Original message:I had the same concern, or a miner could fill the remainder of the block
with their own high fee paying transactions if blocks were required to be
full.
On Fri, Sep 29, 2017 at 7:55 AM Daniele Pinna via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Maybe I'm getting this wrong but wouldn't this scheme imply that a miner
> is incentivized to limit the amount of transactions in a block to capture
> the maximum fee of the ones included?
>
> As an example, mined blocks currently carry ~0.8 btc in fees right now. If
> I were to submit a transaction paying 1 btc in maximal money fees, then the
> miner would be incentivized to include my transaction alone to avoid that
> lower fee paying transactions reduce the amount of fees he can earn from my
> transaction alone. This would mean that I could literally clog the network
> by paying 1btc every ten minutes.
>
> Am I missing something?
>
> Daniele
> _______________________________________________
> 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/20170929/7873796c/attachment.html>

2023-06-07 17:37:12

- reply

📅 Original date posted:2015-08-19
📝 Original message:This is a message that I wrote and had hoped that all the core devs would
sign on to, but I failed to finish organizing it. So I'll just say it from
myself.
There has been a valuable discussion over the last several months regarding
a hard fork with respect to block size. However the sheer volume of email
and proportion of discussion that is more philosophical than technical has
rendered this list almost unusable for its primary purpose of technical
discussion related to Bitcoin development. Many of us share the blame for
letting the discourse run off topic to such a degree, and we hope that an
appeal for individual self restraint will allow this list to return to a
higher signal-to-noise ratio.
-Please consider the degree to which any email you send is related to
technical development before sending it.
-Please consider how many emails you are sending to this list regarding the
same topic.
This list is not appropriate for an endless back and forth debate on the
philosophical underpinnings of Bitcoin. Although such a debate may be
worthwhile it should be taken to another forum for discussion. Every email
you send is received by hundreds of developers who value their time as much
as you value yours. If your intended audience isn't really the majority of
them, perhaps private communication would be more appropriate.
Thanks,
Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150819/68f13345/attachment-0001.html>

2023-06-07 17:32:28

- reply

📅 Original date posted:2015-08-04
📝 Original message:On Tue, Aug 4, 2015 at 9:12 AM, Gavin Andresen via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Tue, Aug 4, 2015 at 7:27 AM, Pieter Wuille via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> I would say that things already demonstrately got terrible. The mining
>> landscape is very centralized, with apparently a majority depending on
>> agreements to trust each other's announced blocks without validation.
>>
> And that is a problem... why?
>
> As far as I can tell, nobody besides miners running old and/or buggy
> software lost money due to outsourced mining validation (please correct me
> if I'm wrong-- I'm looking forward to Greg's post-mortem). The operators of
> bitcoin.org seem to have freaked out and pushed the panic button (with
> dire warnings of not trusting transactions until 20 confirmations), but
> theymos was well known for using an old, patched version of Core for
> blockexplorer.com so maybe that's not surprising.
>
>
I'm also looking forward to Greg's post-mortem, because I had a completely
different takeaway from the BIP66 mini-forks. My view is that despite the
extremely cautious and conservative planning for the completely
uncontentious fork, the damage could and would have been very significant
if it had not been for several core devs manually monitoring, intervening
and problem solving for other network participants. I don't believe thats
the way the system should work. Participants in the Bitcoin community have
come to rely on the devs for just making sure everything works for them.
That's not sustainable. The system needs to be made fundamentally more
secure if its going to succeed, not depend on the good will of any
particular parties, otherwise it certainly will no longer be permissionless.
The BIP66 fork was urgently required to fix an undisclosed consensus bug,
unanimously agreed on and without technical objection, and it was still
fraught with problems. That's the most clear cut example of when we should
have a fork. A change to a consensus limit that a significant proportion
of the community disagrees with for economic or technical reasons or both
should be raising a sea of red flags.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150804/b2ddba5d/attachment.html>