Carlo Spiller [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2021-03-07 to 2021-06-24
💬 Posted a total of 3 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-08 00:54:24

- reply

📅 Original date posted:2021-06-24
📝 Original message:The key difference here is that in PoS the seller of the coin might
still have a vested interest in the network, where in PoW the person you
aquire energy from to mine and mint has absolutely nothing to do with
the network. Anyone with power supply can sell it to you and has no
further interest in what you do with that power. If you don't find a
powersupply, you can build your own.
That is not generically true for PoS. If the seller is still staked with
more coins they hold, they are entrenched in the network and have
"permissioned" you to partake only for what they sold to you. Even
worse, if a super-majority decides to simply never sell, you cannot
aquire significant stake and participate in minting.
Am 24.06.21 um 10:12 schrieb bitcoin-dev-request at lists.linuxfoundation.org:
> Re: Opinion on proof of stake in future
Premise: There is a healthy exchange market for PoS Coin X with tens of
thousands of participants bidding to buy and sell the coin for other
currencies on the market.
If the premise above is true, then there is no significant permission
needed to enter the market for minting blocks for PoS Coin X. If you make a
bid on someone's coins and they don't like you and refuse, you can move on
to any one of the other tens of thousands of people in that marketplace.

2023-06-07 20:30:39

- reply

📅 Original date posted:2021-03-08
📝 Original message:Hi Ariel
Thanks for your reply with the link to the SMA proposal, which I had
missed previoulsy. It is indeed very similar.
I see that Speedy trial is currently gaining broad support, which is
good. I think my proposal with the threshold set to 51% instead of 80%
to change LOT=false to LOT=true is also pretty similar to ST, with the
key difference being that the next step after a fail of MASF is already
baked in.
Excited to see how it all plays out.
Best
Carlo
Carlo Spiller
+41 79 368 85 06
www.carlospiller.com
Am 07.03.21 um 22:13 schrieb Ariel Lorenzo-Luaces:
> Hi Carlo
>
> This your proposal is similar to the Simple Majority Activation
> proposal (SMA). The difference is that your proposal has the final
> activation threshold set to 80% and SMA has it set to 51%
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018587.html
> <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018587.html>
>
> The problem with what you're proposing is what do users do if
> signaling is somewhere between 51% to 79%? Users that want to promote
> a UASF know that their miner majority can activate Taproot and
> activate without the 21% to 49% of miners needing to signal (or
> purposefully stalling). A UASF knows they have majority mining power
> so there is little risk to them and a big reward (activating Taproot)
> so they are incentivized to do a UASF.
>
> A UASF with a miner majority can scare everyone else about them being
> at risk of big reorgs to gain traction and followers.
>
> With the same proposal but the final threshold set to 51% instead of
> 80% there can't be risk of a UASF because if 51% is not reached they
> know they don't have enough miner support to keep the chain together.
>
> If support is less than 50% a UASF movement needs to hard fork anyway
> to change the PoW (for protection) and change addresses to prevent
> double spends.
>
> I really like the SMA proposal with 51% because it removes the
> incentive to do a UASF.
>
> Cheers
> Ariel Lorenzo-Luaces
> On Mar 7, 2021, at 6:37 AM, Carlo Spiller via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> Hi everybody
>
> I'm new to this list, but not new to Bitcoin, having skin in the game
> since 2014. I was there for the scaling war and the drama around SegWit,
> as a simple user. This time, I run my own full node and follow
> development. I hope to bring something new to the table.
>
> Having witnessed the miner's unwillingness to activate SegWit truly
> makes me concerened for a simple LOT=false. After reading the discussion
> now for some time and thinking about it myself, I have come to the
> following proposal.
>
> Initially deploy with LOT=false and an activation threshold of 95% of
> miner signaling.
>
> *IFF* after 6 months Taproot is not activated by MASF, BUT at least 80%
> of hashpower signaled for the upgrade, LOT gets a lock-in date another 6
> months later and the threshold for MASF is lowered to 90%.
>
> If after the initial 6 months of signaling with LOT=false, 80% is not
> reached, the proposal expires.
>
> This way, a small percent of hashpower does not get to stall activation,
> rather, 80% of hashpower can activate LOT=true, and later, 90% can
> activate Taproot. If a flaw is found in Taproot in the first six months
> (unlikely anyway), miners simply don't signal and the proposal expires.
> If miners don't signal at all, only six months are lost, before a new
> activation logic can be deployed.
>
> Don't mind this if something similar was already proposed somewhere else.
>
> Best
>
> Carlo
>
> ------------------------------------------------------------------------
>
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210308/1f9edeb5/attachment-0001.html>

2023-06-07 20:30:38

- reply

📅 Original date posted:2021-03-07
📝 Original message:Hi everybody
I'm new to this list, but not new to Bitcoin, having skin in the game
since 2014. I was there for the scaling war and the drama around SegWit,
as a simple user. This time, I run my own full node and follow
development. I hope to bring something new to the table.
Having witnessed the miner's unwillingness to activate SegWit truly
makes me concerened for a simple LOT=false. After reading the discussion
now for some time and thinking about it myself, I have come to the
following proposal.
Initially deploy with LOT=false and an activation threshold of 95% of
miner signaling.
*IFF* after 6 months Taproot is not activated by MASF, BUT at least 80%
of hashpower signaled for the upgrade, LOT gets a lock-in date another 6
months later and the threshold for MASF is lowered to 90%.
If after the initial 6 months of signaling with LOT=false, 80% is not
reached, the proposal expires.
This way, a small percent of hashpower does not get to stall activation,
rather, 80% of hashpower can activate LOT=true, and later, 90% can
activate Taproot. If a flaw is found in Taproot in the first six months
(unlikely anyway), miners simply don't signal and the proposal expires.
If miners don't signal at all, only six months are lost, before a new
activation logic can be deployed.
Don't mind this if something similar was already proposed somewhere else.
Best
Carlo