Satoshin [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2019-01-22 to 2019-04-01
💬 Posted a total of 2 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 18:17:17

- reply

📅 Original date posted:2019-04-01
📝 Original message:Hi Everyone,
First portion of your First BIP is excellent- with this field the protocol can actually attain HFT- by pinning of value at time of trade for later unblock scaling as a mark to market tool which is used in HFT.
The Second BIP of a minimum price would never allow Bitcoin to pass the SEC test of a viable asset. - I hope that portion was actually a Joke since it makes no sense economically.
If one has ever seen a stock drop 90% in one day then you would understand the volatile nature of future valuation.
Prices have to be able to go higher and lower based on market demand and not tethering to perceived norms. If the US dollar was crashed and it went down to Venezuelan currency levels [hypothetically then where would your 50k limit lead the currency} Never say never-
Best Regards
XX
> On Mar 31, 2019, at 9:11 PM, Peter Todd via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> On Mon, Apr 01, 2019 at 12:30:34AM +0000, Luke Dashjr via bitcoin-dev wrote:
>> Certain parts of the community have been selling bitcoins for unreasonably
>> low prices. This has halted Bitcoin's valuation at $20k and even driven the
>> price down below $15k! However, clearly Bitcoin is worth much more than
>> that, and there is widespread support for higher prices.
>>
>> In light of this, I have written and implemented two BIPs: one to add a
>> signed price field to Bitcoin transactions, and the other to softfork a
>> minimum price of $50k USD/BTC a year from today.
>
> I believe I've found a serious vulnerability in your proposal: there's no limit
> on the maximum supply of USD.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 18:17:17

- reply

2023-06-07 18:15:59

- reply

📅 Original date posted:2019-01-22
📝 Original message:This could could be a viable option. I think this is the right approach.
Any downside to this and how much does this add to the blockweight if anything at all.
Anonymouse
> On Jan 22, 2019, at 4:19 AM, ZmnSCPxj via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Good Morning Matt,
>
>> ### ZmnSCPxj,
>>
>> I'm intrigued by this mechanism of using fixed R values to prevent multiple signatures, but how do we derive the R values in a way where they are
> unique for each blockheight but still can be used to create signatures or verify?
>
> One possibility is to derive `R` using standard hierarchical derivation.
> Then require that the staking pubkey be revealed to the sidechain network as actually being `staking_pubkey = P + hash(P || parent_R) * G` (possibly with some trivial protection against Taproot).
> To sign for a blockheight `h`, you must use your public key `P` and the specific `R` we get from hierarchical derivation from `parent_R` and the blockheight as index.
>
>
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 18:15:59

- reply