Santino Napolitano [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2015-06-28 to 2015-12-19
💬 Posted a total of 7 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 17:46:53

- reply

📅 Original date posted:2015-12-19
📝 Original message:I disagree. I think all client-side adoption of SW reliably tells you is that those implementers saw value in it greater than the cost of implementation. It's possible what they valued was the malleability fix and didn't see the limited potential circumvention of MAX_BLOCK_SIZE material to their decision.
They could just as easily attach an OP_RETURN output to all of their transactions which pushes "big blocks please" which would more directly indicate their preference for larger blocks. You could also let hand-signed letters from the heads of businesses explicitly stating their desire speak for their intentions vs. any of this nonsense. Or the media interviews, forum comments, tweets, etc...
19.12.2015, 20:43, "Peter Todd via bitcoin-dev" <bitcoin-dev at lists.linuxfoundation.org>:
> On Sat, Dec 19, 2015 at 11:49:25AM -0500, jl2012 via bitcoin-dev wrote:
>> I have done some calculation for the effect of a SW softfork on the
>> actual total block size.
>
> Note how the fact that segwit needs client-side adoption to enable an
> actual blocksize increase can be a good thing: it's a clear sign that
> the ecosystem as a whole has opted-into a blocksize increase.
>
> Not as good as a direct proof-of-stake vote, and somewhat coercive as a
> vote as you pay lower fees, but it's an interesting side-effect.
>
> --
> 'peter'[:-1]@petertodd.org
> 00000000000000000188b6321da7feae60d74c7b0becbdab3b1a0bd57f10947d
> ,
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 17:42:46

- reply

📅 Original date posted:2015-10-05
📝 Original message:While this isn't really the place to discuss it, I respectfully disagree. Mike appears to be making a point concerning Bitcoin protocol authorship and on the perceived value of soft-forks. It doesn't look like simple trolling to me. Mike and Gregory are both extremely intelligent and well-versed in Bitcoin and both should be listened to earnestly and equally while receiving our full professional respect.
At this stage it's becoming readily apparent to at least me (and without putting words into his mouth it would seem Gavin has experienced a similar realisation; please correct if I'm mistaken) that Bitcoin protocol authorship and individual implementation development need to be separated asap. I have no suggestions for the structure of this separation but as soon as it happens the better, IMO. It's likely messages like this would then no longer be seen on this list and Bitcoin Core developers could focus on their implementation's development free from distraction while other implementers and Core developers could discuss protocol issues in a more relevant forum in a more civilized and constructive manner.
05.10.2015, 23:05, "Steven Pine via bitcoin-dev" <bitcoin-dev at lists.linuxfoundation.org>:
> It's pretty clear Mike has turned into concern troll and bully. He insults people, mischaracterizes others, quibbles over words and definitions and has stated numerous times in other forums he has no interest in building consensus changes he doesn't agree with himself.
>
> He's lost his integrity and trust and why the core developers waste their time with his antics is beyond me, let Mike fork Bitcoin, develop XT, and ignore his input on core unless some XT feature is deemed good enough to incorporate, that is how a thousand other open source projects deal with trolls like Mike.
>
> On Oct 5, 2015 3:41 PM, "Gregory Maxwell via bitcoin-dev" <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> On Mon, Oct 5, 2015 at 7:13 PM, Tom Zander via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>> It is an eloquent change, but not really the topic we were discussing. It also
>>> makes you attack Mike (calling him out as having a strawman) without basis.
>>> For the second time in this thread.
>>> I would suggest arguing on the topic, not on the man.
>>
>> Such a shame you appear to reserve that wisdom for those you disagree
>> with, biting your tongue when others emit all forms of ad hominem--
>> such as suggesting we've spent less volunteer time on Bitcoin and thus
>> our opinion has less merit (or that we haven't written certian kinds
>> of software (even when, ironically, we have!), and thus our opinion
>> doesn't have merit, and so on). I think everyone would benefit from
>> it, especially as that kind of correction is best received from
>> someone who agrees with you.
>>
>> In this case, I think, however your correction is also misplaced at
>> least on this message; though I would otherwise welcome it. I'm not
>> complaining about the man; but pointing out the behavior of stating an
>> opinion no one as held as theirs and attacking it is not a productive
>> way to hold a discussion. It's an argument or a behavior, not a
>> person, and beyond calling it bad I attempted to explaining (perhaps
>> poorly) why its bad.
>>
>> What Sergio is saying is not the same; Mike argued some established
>> criteria existed where it didn't-- and I was pointing that out; and
>> talking about how the situation here is not very similar to the one
>> that Mike was trying to draw a parallel to. I enumerated a number of
>> specific reasons why this is the case. If the differences between
>> Sergio's comments and mine are still unclear after this clarification,
>> I'd be glad to talk it through with you off-list-- in spite of your
>> (welcome) compliments, communication is just fundamentally difficult,
>> and no amount eloquence changes that. If there is continued
>> misunderstanding, I do not doubt its my fault; but it's probably not a
>> good use of hundreds/thousands of people's time for you to help me
>> interactively improve my explanation on list. :)
>> _______________________________________________
>> 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

2023-06-07 17:41:50

- reply

📅 Original date posted:2015-09-29
📝 Original message:I'm not intending to completely dismiss your concerns but as a data point: I read this list daily and it usually takes 15 minutes or less while I drink a cup of coffee.
My concern is that this is one of the (maybe *the*) last uncensored persisted forums related to technical bitcoin discussion with wide viewership. It is increasingly difficult for an average somewhat technical person to attempt to hold the bitcoin development community accountable for its actions or have their voice heard. It would really be a shame if messages like this were relegated to a black hole where things like the exchange rate and various scammy spam goes to fester.
>Debates over bitcoin philosophy, broader context, etc. will start seeing grumpy list admins squawk about "off-topic!"
Who will draw this line? It's unclear to me who the list admins are.

2023-06-07 17:41:46

- reply

📅 Original date posted:2015-09-29
📝 Original message:> So I'll repeat the question that I posed before - given that there are clear, explicit downsides,
> what is the purpose of doing things this way? Where is the gain for ordinary Bitcoin users?
+1 for a direct answer to this question.

2023-06-07 17:35:56

- reply

📅 Original date posted:2015-08-19
📝 Original message:Gavin has been very clear about the fact that he's on vacation. I'm not sure what you want Mike to say. It's obvious the Bitcoin Core developer pitchforks are out for him so there isn't really anything he can possibly say which will be constructively received on this highly adversarial and increasingly ridiculous charade of a mailing list. I feel as though they've made their case abundantly clear to anyone paying attention.
The community will weigh the independent merit of the two points of view and that community is not as naive and uninformed as everyone on this list likes to portray them to be. Your concern for companies' welfare is appreciated but I'm confident they can manage their own independent assessments of this matter as well as seek out enough varied expert opinions such that they can make an informed decision.
19.08.2015, 19:53, "Adam Back via bitcoin-dev" <bitcoin-dev at lists.linuxfoundation.org>:
> It seems to be a recurring meme that BIP 101 is somehow "a solution
> put forward" where BIP 100, 102, 103, flexcap, extension blocks etc
> etc are not.
>
> That is not at ALL the case, and is insulting (present company excluded).
>
> It is just that no one else is reckless enough to bypass the review
> process and risk a controversial hard fork deployment war. Myself and
> many other people warned Gavin a network fork "war" would start (ie
> someone would think of some way to sabotage or attack the deployment
> of Bitcoin-XT via protocol, code, policy, consensus soft-fork etc. He
> ignored the warnings. Many also warned that 75% was an optimally BAD
> trigger ratio (and that in a hard fork it is not a miner vote really
> as in soft-forks). Gavin & Mike ignored that warning to. I know they
> heard those warnings because I told them 1:1 in person or via email
> and had on going conversations. Others did too.
>
> People can not blame bitcoin core or me, that this then predictably
> happened exactly as we said it would - it was completely obvious and
> predictable.
>
> In fact noBitcoinXT is even more dangerous and therefore amplified in
> effect in creating mutual assured destruction kind of risk profile
> than the loose spectrum of technical counters imagined. I did not
> personally put much effort into thinking about counters because I
> though it counter productive and hoped that Gavin & Mike would have
> the maturity to not start down such a path.
>
> Again any of the other proposals can easily be implemented. They
> *could* also spin up a web page and put up binaries, however no one
> else was crazy enough to try to start a deployment in that way.
>
> It is also puzzling timing - with all these BIPs and ongoing
> discussion and workshops coming imminently to then release ahead of
> that process where as far as I know Gavin said he was equally happy
> with BIP 100 or other proposal which ever is best, and on basically
> the eve of workshops planned to progress this collaboratively.
> Bitcoin-XT is also under tested, people are finding privacy bugs and
> other issues. (Not even mentioning the above 75% optimally bad
> parameter, and the damage to community reputation and collaborative
> environment that this all causes.)
>
> Very disappointing Gavin and Mike.
>
> I find it quite notable that Gavin and Mike have been radio silent on
> the bitcoin-dev list and yet we see a stream of media articles, blog
> posts, pod casts, and from what I can tell ongoing backroom lobbying
> of companies to run bitcoin-XT without trying AT ALL to offer a
> neutral or balanced or multi proposal information package so that
> companies technical people can make a balanced informed decision.
> That is what the workshops are trying to provide.
>
> Gavin, Mike - anything to say here?
>
> Adam
>
> On 18 August 2015 at 19:59, Angel Leon via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> "How then to end this XT madness?"
>>
>> Instead of bashing on someone that has actually put a solution forward, make
>> your own fork and see if your ideas on how to solve the issue are any
>> better.
>>
>> As of now, 1Mb blocks are pure madness, and people are voting over an 8mb
>> block increase every day that passes, even with a "useless project" like you
>> call it.
>>
>> Go out there and see how bitcoin is actually used.
>>
>> http://twitter.com/gubatron
>>
>> On Tue, Aug 18, 2015 at 10:54 PM, odinn via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>> 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-----
>>>
>>> _______________________________________________
>>> 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
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 15:47:36

- reply

2023-06-07 15:41:09

- reply

📅 Original date posted:2015-06-28
📝 Original message:Is the security concern that a newly announced block may not actually reflect a valid block (but valid enough to trick the client; i.e. it appears to link to the best-work chain) in an attempt to defraud the light client?
Like I pointed out, I'm not sure the goal was _perfect_ decentralization. The author seemed primarily keen to avoid having a single organization with direct control over the ledger. I think your specific fear could be mitigated by the light client peering with a node the light client somewhat trusts -- or at least one which has no incentive to cooperate in some attack against it which requires non-trivial mining expenditure. The IP would be logged and the fraud could be taken to a court if the light client chooses a node in the proper jurisdiction. I think for many use cases that might be sufficient. If it's a more serious transaction other nodes could be consulted.
If my reasoning is in error please correct. I'm sure many of you are much better at game theory than I.
28.06.2015, 05:13, "Patrick Strateman" <patrick.strateman at gmail.com>:
>> Further, it appears clear that the original author intended
>
> organizations operating full network nodes would provide connectivity to
> light clients and these light clients would make up the majority of the
> user base.
>
> Satoshi also believed that fraud proofs would be widely available and
> practical.
>
> If fraud proofs were practical SPV client security would be much closer
> to full node security than it is today.
>
> Unfortunately no design for fraud proofs which is both efficient and
> secure has been proposed; much less implemented and deployed.
>
> In building a system as new and innovative as bitcoin certain things
> will be wrong.
>
> The perception that SPV clients could be made nearly as secure as full
> nodes is one example of something that was wrong.
>
> On 06/27/2015 05:14 PM, Santino Napolitano wrote:
>> There is much heated debate going on right now and I know it can be very stressful but I'd like to point out that it is really amazing how passionately so many feel about this once very small project. Let's not forget there is something really special going on here and we're all part of it.
>>
>> The current debate has little to do with block size or hard-forks, IMO. It's about the nature of Bitcoin and what it means to people and how it will grow. I would like to take a moment to share my interpretation of the original author's intent based on everything I could find and read from this person. This is not to say their original vision is paramount-- or even that I got it completely correct but I think it might do us some good to think about.
>>
>> It seems as though the incentive conceived of for running a full network node was that it would enable mining. The proceeds from mining (new coins and transaction fees) would be the reward and provide a reason to continue operating these nodes. If fees are ever to be a sufficient reward and still allow for a practical and useful system the size of the blocks must grow significantly as must the user base. I'm not sure that this is really contested but I haven't exhaustively reviewed everyone's opinion so please excuse me if I have marginalized you. If you do contest that I would be interested in hearing it.
>>
>> Further, it appears clear that the original author intended organizations operating full network nodes would provide connectivity to light clients and these light clients would make up the majority of the user base. This is completely consistent with current trends in Internet consumption, e.g. tablets and phones are becoming more preferred to even owning a traditional computer. Having the system be entirely decentralized and trustless for every client does not appear to me to be the original design goal. Yes, the whitepaper speaks of the design goal as not having a need for a trusted third party but it does not say that some amount of trust won't be preferred by a majority of users. In fact, in the SPV section it implies some amount of localized trust is perhaps a necessary trade-off and maybe businesses should still run their own full network node if they want the stronger completely trustless guarantee. The global decentralized consensus appears meant to make the netwo
rk
>
> r
>> esilient to a single government or other adversary's ability to shut the network down. If you really want to trust no one it is your option at a cost and should be possible by design. The author further gives evidence that they believe Moore's observation would keep the idea of running a full network node a practical one at global scale for perpetuity. It does not appear as if they intended for every individual to run one at home nor in their pocket.
>>
>> If my interpretation seems incorrect please do point it out. I hope this hasn't been too off-topic and distracting. The original author's engineering ingenuity is what gave me any interest in this project so re-visiting their design and scaling intentions might be helpful for us to move forward-- together.
>>
>> _______________________________________________
>> 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

2023-06-07 15:41:05

- reply

📅 Original date posted:2015-06-27
📝 Original message:There is much heated debate going on right now and I know it can be very stressful but I'd like to point out that it is really amazing how passionately so many feel about this once very small project. Let's not forget there is something really special going on here and we're all part of it.
The current debate has little to do with block size or hard-forks, IMO. It's about the nature of Bitcoin and what it means to people and how it will grow. I would like to take a moment to share my interpretation of the original author's intent based on everything I could find and read from this person. This is not to say their original vision is paramount-- or even that I got it completely correct but I think it might do us some good to think about.
It seems as though the incentive conceived of for running a full network node was that it would enable mining. The proceeds from mining (new coins and transaction fees) would be the reward and provide a reason to continue operating these nodes. If fees are ever to be a sufficient reward and still allow for a practical and useful system the size of the blocks must grow significantly as must the user base. I'm not sure that this is really contested but I haven't exhaustively reviewed everyone's opinion so please excuse me if I have marginalized you. If you do contest that I would be interested in hearing it.
Further, it appears clear that the original author intended organizations operating full network nodes would provide connectivity to light clients and these light clients would make up the majority of the user base. This is completely consistent with current trends in Internet consumption, e.g. tablets and phones are becoming more preferred to even owning a traditional computer. Having the system be entirely decentralized and trustless for every client does not appear to me to be the original design goal. Yes, the whitepaper speaks of the design goal as not having a need for a trusted third party but it does not say that some amount of trust won't be preferred by a majority of users. In fact, in the SPV section it implies some amount of localized trust is perhaps a necessary trade-off and maybe businesses should still run their own full network node if they want the stronger completely trustless guarantee. The global decentralized consensus appears meant to make the network resilient to a single government or other adversary's ability to shut the network down. If you really want to trust no one it is your option at a cost and should be possible by design. The author further gives evidence that they believe Moore's observation would keep the idea of running a full network node a practical one at global scale for perpetuity. It does not appear as if they intended for every individual to run one at home nor in their pocket.
If my interpretation seems incorrect please do point it out. I hope this hasn't been too off-topic and distracting. The original author's engineering ingenuity is what gave me any interest in this project so re-visiting their design and scaling intentions might be helpful for us to move forward-- together.