Aymeric Vitte [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2016-12-15 to 2023-05-12
💬 Posted a total of 129 messages
📚 Participated in the following categories: bitcoin-dev, Lightning-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub15fc36esk6dy2x4ptk2ner209rl9u0d736gr99edtu9knu9uny80s4g5grz

Profile Code

nprofile1qqs2yugavctdxj9r2s4m9fu348j3lj78klgaypjjuk47zmf7z7fjrhcfmfepr

Author Public Key

npub15fc36esk6dy2x4ptk2ner209rl9u0d736gr99edtu9knu9uny80s4g5grz

Show more details

Last Notes

2023-06-19 17:42:09

- reply

📅 Original date posted:2023-05-12
🗒️ Summary of this message: A warning to the Lightning community to avoid off-topic discussions, as it destroyed the Tor-talk mailing list, leading to a loss of discussion.
📝 Original message:
Lightning list, I really think that you should stop this mess and
reconcentrate on technical topics
The very same did destroy the Tor-talk mailing list
Based on false assumptions as we saw later
Reading bulls all the day, everybody escaped
Result: the Tor community can't discuss any longer
Don't do the same
Le 11/05/2023 à 19:48, alicexbt via Lightning-dev a écrit :
> Hi Antoine,
>
>> I can say missing an open-source engineering meeting or being
>> revoked a few Github permissions matters far less than the clear
>> affirmation and respect of the freedom of expression, the presumption
>> of innocence and due process in the Bitcoin common space, all
>> proportions conserved.
>
> This is not acceptable. I will fight with you. Never feel alone.
>
> /devfd0
> floppy disk guy
>
> Sent with Proton Mail <https://proton.me/> secure email.
>
> ------- Original Message -------
> On Wednesday, May 10th, 2023 at 10:27 PM, Antoine Riard
> <antoine.riard at gmail.com> wrote:
>
>> Hi Tony,
>>
>> > Is there a better place to havepubliccommunication? Unfortunately
>> since one off topic email was sent here, it's been a ghost town. It
>> appears that there's many emails being held and only one moderator
>> that checks them once a week.
>>
>> As I think you're referring to my post of March 21th and as the
>> author of this post, I'll politely refuse the qualification of
>> "off-topic". I had and I still have the concerns of "frivolous legal
>> claims" being used between bitcoin developers/organizations provoking
>> a distortion of the neutrality of the development and a chilling
>> effect of the technical discussions (i.e code we compile and spec we
>> implement). For those reasons, it was my legal right and moral duty
>> to inform the community of what is happening between Chaincode and
>> myself. And here I'm following the recommendation of one of the
>> moderators of the Lightning mailing list himself "If this worries you
>> too, let's make sure we keep each other honest, OK?" [0].
>>
>> When you think a group of people with open-source responsibilities
>> are in a situation of conflict of interests or "moral hazards", or
>> even the appearance of them, you have the right to expose the
>> wrongdoing, including the _proportional_ revelation of private
>> elements. People have done the "free choice" to conduct a career in
>> open-source, for some even declaring in some context to maintain
>> integrity and accept their actions to be submitted to external
>> accountability [1]. While the exposure of private elements of public
>> personalities might break common courtesy, it's a morally valid
>> practice if you're familiar with the public institutions of US and
>> Europe, and I think this practice has found validity in the history
>> of open-source commons or IETF's protocol development [1].
>>
>> Beyond, the Bitcoin and Lightning development communication channels
>> constitute a public forum, where by nature the participants are
>> exchanging ideas and defending competing interests. In consequence,
>> the participants' rights and capabilities to contribute and speak
>> their minds in those communication channels should be protected.
>> Those communication channels are not your usual corporate workplace,
>> and in case of conflicting principles, the maintainers of those
>> communication channels should ensure a balance of rights and a
>> proportionality in any restraining measure.
>>
>> And this new post is not to exonerate myself of any legal
>> responsibility for personal matters that could be recognized as the
>> outcome of a judicial process, respective of both rights of the
>> accusation and rights of the defense. Rather to enlighten the Bitcoin
>> community that the formal separation between private matters and
>> open-source responsibilities, and the adequate check-and-balances to
>> guarantee this separation is somehow what are the underlying stakes
>> for this feud between Chaincode and myself, from my perspective. I
>> can say missing an open-source engineering meeting or being revoked a
>> few Github permissions matters far less than the clear affirmation
>> and respect of the freedom of expression, the presumption of
>> innocence and due process in the Bitcoin common space, all
>> proportions conserved.
>>
>> I don't blame any party involved in this issue, nor assign "bad
>> intentions''. One position is really a function of your life
>> experiences, knowledge of the legal and cultural framework and access
>> to the factual elements. As all human conflicts it is not binary
>> rather "grey". People can be top executives at a billion-dollar
>> company, having successful ventures with hundreds of folks under
>> management, or have a lot of responsibilities for their relative
>> young age, and still disagree on the set of legal and moral
>> principles to apply in the present case.
>>
>> Finally, thanks to the Bitcoin friends who have reached out to call
>> for level-headedness and cool-mindness in the public discussion of
>> this complex topic. Like I said to them, in the lack of more
>> suspected wrongdoing from the other side, I won't communicate further
>> on this subject on the Bitcoin and Lightning technical channels.
>> However I still firmly believe the discussion on the principles,
>> abstract in the maximum from its private elements, should still be
>> pursued on other channels. Independently, there is a legal channel
>> opened between Chaincode and myself and good progress is made to find
>> a serene and long-standing resolution to this issue.
>>
>> Best,
>> Antoine
>>
>> [0]
>> https://rusty-lightning.medium.com/the-corrosion-of-ethics-in-cryptocurrencies-f7ba77e9dfc3
>> [1]
>> https://github.com/btrustteam/board-book/blob/main/vision/genesis_principles.md
>> [2]
>> https://www.ietf.org/about/administration/policies-procedures/conflict-interest/
>>
>> Le lun. 8 mai 2023 à 21:26, Tony Giorgio via Lightning-dev
>> <lightning-dev at lists.linuxfoundation.org
>> <mailto:lightning-dev at lists.linuxfoundation.org>> a écrit :
>>
>> Is there a better place to have public communication?
>> Unfortunately since one off topic email was sent here, it's been
>> a ghost town. It appears that there's many emails being held and
>> only one moderator that checks them once a week.
>>
>> Would hate to see this list die but wondering if there's a better
>> place for discussions?
>>
>> Tony
>>
>>
>>
>>
>>
>>
>> -------- Original Message --------
>> On Apr 29, 2023, 9:57 PM, niftynei < niftynei at gmail.com
>> <mailto:niftynei at gmail.com>> wrote:
>>
>>
>> Hi all,
>>
>> When I joined the lightning community a few years ago, I was
>> relatively new to open source software and specification
>> work. Rusty really impressed on me on the importance of
>> holding conversations, as much as possible in public.
>>
>> Practically speaking, this encompasses IRC, this mailing
>> list, and github issues/PRs.
>>
>> The reason for this is twofold. It helps document the range
>> of options considered for technical decisions and it provides
>> an interface point for new participants to contribute to the
>> discussion.
>>
>> Given some recent mails that were posted to this list, now
>> seems like a good time to reiterate the importance and
>> preference of public communication whenever possible,
>> especially for specification or technical discussions.
>>
>>
>> ~ nifty
>>
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> <mailto:Lightning-dev at lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>
>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
--
Sophia-Antipolis, France
CV: https://www.peersm.com/CVAV.pdf
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
GitHub : https://www.github.com/Ayms
A Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7
A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
Bitcoin, Ethereum, smart contracts, lightning, sidechains, Defi, DApps, NFTs, DEX, DAO explained - Centralization vs Decentralization https://gist.github.com/Ayms/04b3084a14ee202e707b3faec57ed26e
Discover and Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com
Peersm : http://www.peersm.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230512/446a64e4/attachment-0001.html>

2023-06-09 13:13:11

- reply

📅 Original date posted:2023-05-12
🗒️ Summary of this message: A warning to the Lightning community to avoid off-topic discussions, as it destroyed the Tor-talk mailing list, leading to a lack of discussion.
📝 Original message:
Lightning list, I really think that you should stop this mess and
reconcentrate on technical topics
The very same did destroy the Tor-talk mailing list
Based on false assumptions as we saw later
Reading bulls all the day, everybody escaped
Result: the Tor community can't discuss any longer
Don't do the same
Le 11/05/2023 à 19:48, alicexbt via Lightning-dev a écrit :
> Hi Antoine,
>
>> I can say missing an open-source engineering meeting or being
>> revoked a few Github permissions matters far less than the clear
>> affirmation and respect of the freedom of expression, the presumption
>> of innocence and due process in the Bitcoin common space, all
>> proportions conserved.
>
> This is not acceptable. I will fight with you. Never feel alone.
>
> /devfd0
> floppy disk guy
>
> Sent with Proton Mail <https://proton.me/> secure email.
>
> ------- Original Message -------
> On Wednesday, May 10th, 2023 at 10:27 PM, Antoine Riard
> <antoine.riard at gmail.com> wrote:
>
>> Hi Tony,
>>
>> > Is there a better place to havepubliccommunication? Unfortunately
>> since one off topic email was sent here, it's been a ghost town. It
>> appears that there's many emails being held and only one moderator
>> that checks them once a week.
>>
>> As I think you're referring to my post of March 21th and as the
>> author of this post, I'll politely refuse the qualification of
>> "off-topic". I had and I still have the concerns of "frivolous legal
>> claims" being used between bitcoin developers/organizations provoking
>> a distortion of the neutrality of the development and a chilling
>> effect of the technical discussions (i.e code we compile and spec we
>> implement). For those reasons, it was my legal right and moral duty
>> to inform the community of what is happening between Chaincode and
>> myself. And here I'm following the recommendation of one of the
>> moderators of the Lightning mailing list himself "If this worries you
>> too, let's make sure we keep each other honest, OK?" [0].
>>
>> When you think a group of people with open-source responsibilities
>> are in a situation of conflict of interests or "moral hazards", or
>> even the appearance of them, you have the right to expose the
>> wrongdoing, including the _proportional_ revelation of private
>> elements. People have done the "free choice" to conduct a career in
>> open-source, for some even declaring in some context to maintain
>> integrity and accept their actions to be submitted to external
>> accountability [1]. While the exposure of private elements of public
>> personalities might break common courtesy, it's a morally valid
>> practice if you're familiar with the public institutions of US and
>> Europe, and I think this practice has found validity in the history
>> of open-source commons or IETF's protocol development [1].
>>
>> Beyond, the Bitcoin and Lightning development communication channels
>> constitute a public forum, where by nature the participants are
>> exchanging ideas and defending competing interests. In consequence,
>> the participants' rights and capabilities to contribute and speak
>> their minds in those communication channels should be protected.
>> Those communication channels are not your usual corporate workplace,
>> and in case of conflicting principles, the maintainers of those
>> communication channels should ensure a balance of rights and a
>> proportionality in any restraining measure.
>>
>> And this new post is not to exonerate myself of any legal
>> responsibility for personal matters that could be recognized as the
>> outcome of a judicial process, respective of both rights of the
>> accusation and rights of the defense. Rather to enlighten the Bitcoin
>> community that the formal separation between private matters and
>> open-source responsibilities, and the adequate check-and-balances to
>> guarantee this separation is somehow what are the underlying stakes
>> for this feud between Chaincode and myself, from my perspective. I
>> can say missing an open-source engineering meeting or being revoked a
>> few Github permissions matters far less than the clear affirmation
>> and respect of the freedom of expression, the presumption of
>> innocence and due process in the Bitcoin common space, all
>> proportions conserved.
>>
>> I don't blame any party involved in this issue, nor assign "bad
>> intentions''. One position is really a function of your life
>> experiences, knowledge of the legal and cultural framework and access
>> to the factual elements. As all human conflicts it is not binary
>> rather "grey". People can be top executives at a billion-dollar
>> company, having successful ventures with hundreds of folks under
>> management, or have a lot of responsibilities for their relative
>> young age, and still disagree on the set of legal and moral
>> principles to apply in the present case.
>>
>> Finally, thanks to the Bitcoin friends who have reached out to call
>> for level-headedness and cool-mindness in the public discussion of
>> this complex topic. Like I said to them, in the lack of more
>> suspected wrongdoing from the other side, I won't communicate further
>> on this subject on the Bitcoin and Lightning technical channels.
>> However I still firmly believe the discussion on the principles,
>> abstract in the maximum from its private elements, should still be
>> pursued on other channels. Independently, there is a legal channel
>> opened between Chaincode and myself and good progress is made to find
>> a serene and long-standing resolution to this issue.
>>
>> Best,
>> Antoine
>>
>> [0]
>> https://rusty-lightning.medium.com/the-corrosion-of-ethics-in-cryptocurrencies-f7ba77e9dfc3
>> [1]
>> https://github.com/btrustteam/board-book/blob/main/vision/genesis_principles.md
>> [2]
>> https://www.ietf.org/about/administration/policies-procedures/conflict-interest/
>>
>> Le lun. 8 mai 2023 à 21:26, Tony Giorgio via Lightning-dev
>> <lightning-dev at lists.linuxfoundation.org
>> <mailto:lightning-dev at lists.linuxfoundation.org>> a écrit :
>>
>> Is there a better place to have public communication?
>> Unfortunately since one off topic email was sent here, it's been
>> a ghost town. It appears that there's many emails being held and
>> only one moderator that checks them once a week.
>>
>> Would hate to see this list die but wondering if there's a better
>> place for discussions?
>>
>> Tony
>>
>>
>>
>>
>>
>>
>> -------- Original Message --------
>> On Apr 29, 2023, 9:57 PM, niftynei < niftynei at gmail.com
>> <mailto:niftynei at gmail.com>> wrote:
>>
>>
>> Hi all,
>>
>> When I joined the lightning community a few years ago, I was
>> relatively new to open source software and specification
>> work. Rusty really impressed on me on the importance of
>> holding conversations, as much as possible in public.
>>
>> Practically speaking, this encompasses IRC, this mailing
>> list, and github issues/PRs.
>>
>> The reason for this is twofold. It helps document the range
>> of options considered for technical decisions and it provides
>> an interface point for new participants to contribute to the
>> discussion.
>>
>> Given some recent mails that were posted to this list, now
>> seems like a good time to reiterate the importance and
>> preference of public communication whenever possible,
>> especially for specification or technical discussions.
>>
>>
>> ~ nifty
>>
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> <mailto:Lightning-dev at lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>
>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
--
Sophia-Antipolis, France
CV: https://www.peersm.com/CVAV.pdf
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
GitHub : https://www.github.com/Ayms
A Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7
A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
Bitcoin, Ethereum, smart contracts, lightning, sidechains, Defi, DApps, NFTs, DEX, DAO explained - Centralization vs Decentralization https://gist.github.com/Ayms/04b3084a14ee202e707b3faec57ed26e
Discover and Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com
Peersm : http://www.peersm.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230512/446a64e4/attachment-0001.html>

2023-06-09 13:12:47

- reply

📅 Original date posted:2023-03-06
🗒️ Summary of this message: A Lightning developer suggests using gossip messages to announce liquidity balances and differentiated services of channel liquidity levels instead of relying on sender-side probing.
📝 Original message:
The question is not really related to onion messages but why is
Lightning not using a DHT system for gossip?
Le 01/03/2023 à 19:02, Antoine Riard a écrit :
> Hi Val,
>
> Thanks for the proposal here. About using OM for payment probing, I
> think there could be an alternative of the routing hops themselves
> announcing their liquidity balances with an extension or new set of
> gossip messages.
>
> Gossips messages could commit to a liquidity balance and duration
> (e.g +1000 blocks from tip), rather relying on sender-side probing,
> which might be less and less accurate with higher rate of network
> liquidity congestion. Additionally, a routing hop could commit to
> "private" gossip sent back to HTLC senders during HTLC successful
> settlement. Those "private" gossip might announce "differentiated
> services" of channel liquidity levels. I believe this can be
> guaranteed transparently from the rest of the network thanks to
> parallel channels.
>
> Any deviation from the gossip message could be penalized by sender's
> scoring algorithms as the liquidity SLA parameters have been announced
> explicitly by the routing hops. This is just an intuition on how
> public channel liquidity discovery could be worked out, and I don't
> know which of the alternatives would be more efficient in terms of
> bandwidth/convergence delays.
>
> Best,
> Antoine
>
> Le lun. 27 févr. 2023 à 21:32, vwallace via Lightning-dev
> <lightning-dev at lists.linuxfoundation.org
> <mailto:lightning-dev at lists.linuxfoundation.org>> a écrit :
>
> Hi list!
>
> I wanted to bring up the idea of using onion messages for payment
> probing, which was briefly touched
> on at the 2022 LN summit. Tadge Dryja has also brought up a
> similar idea.
>
> I recommend reading the gist instead since it has the relevant
> diagrams in-line:
> https://gist.github.com/valentinewallace/ebe1741f0438c2360eda0f80f0e075c9
> but the scheme is also
> posted below for convenience.
>
> ## Introduction
>
> For context, in today’s lightning, payment reliability tends to
> heavily depend on having sufficient
> payment volume to determine current liquidity balances of
> channels, which is how most big nodes can
> tell whether a given channel has enough liquidity to forward a
> given amount. If a node is using HTLC
> probing to achieve this payment volume, they use a regular
> `update_add_htlc` message with a bogus
> payment hash, where the error returned informs the sender of
> whether the payment reached the final
> recipient. Note that there is a tradeoff between always routing
> through nodes that are known to
> rebalance their channels vs leaning on probing smaller nodes and
> “risking” payments through them
> based on what’s learned.
>
> Today’s HTLC payment probing can work well, but risks channel
> liquidity being locked up if a peer
> along the route goes offline. On the upside, for just-in-time
> probes, it works to loosely “reserve”
> the channel liquidity along the route for the actual payment.
>
> Onion messages (OMs) present a convenient way to probe without
> risking locked liquidity along the
> route.
>
> ## Design Rationale
>
> A naive approach could be to send onion message probes directly to
> individual nodes along the
> desired route, including those to which you don’t have a direct
> channel. However, this scheme is
> problematic because it would enable monitoring the payment flows
> of arbitrary nodes across the
> network without having to have a channel path to them. This would
> be a significant degradation of
> privacy because, for comparison, in HTLC probing it is quite
> difficult to probe the balances of
> far-off nodes. And if you can’t probe a node using HTLCs, you
> can’t send over it anyway, so there’s
> not a lot of benefit (and significant privacy downside).
>
> Therefore, it is probably best to design a scheme that probes
> along channel paths, like HTLC
> probing. This adds more complexity to the case where an
> intermediate node cannot forward the desired
> amount due to the stateless nature of OMs, discussed further down.
>
> ## Scheme
>
> Let’s go through the happy path, where Alice is probing Alice >
> Bob > Carol > Dave for a 100k msat
> payment.
>
> She’ll construct an onion message for Bob, the first hop, as such:
> https://imgur.com/BZg8yt8
>
> Bob receives this OM, sees that he’s able to forward 110k msats to
> his next-hop Carol, and forwards
> Carol’s onion packet to her. Carol sees she can forward 105k msats
> to Dave, and forwards his onion
> packet. Finally, Dave receives his onion packet, sees he can
> receive 100k msats from Carol, and uses
> the provided reply path to send a simple probe success onion
> message back to Alice:
>
> ```
> onion_message_probe_result {
> data_tlv {
> type: 4242,
> probe_id: [u8; 32],
> can_forward_desired_amt: true,
> }
> .. regular OM TLVs
> }
> ```
>
> Note that Dave will use this same onion message if he can’t
> receive; he’ll just set
> `can_forward_desired_amt` to false.
>
> As an example of the sad path for an intermediate node, if Carol
> can’t forward 105k msats to Dave,
> she’ll fail the probe back to Bob by sending this onion message:
> https://imgur.com/a/hqlzw4I
>
> This step justifies why we need to encode a failure onion for each
> intermediate hop of a probe. If
> we hadn’t done that, and Carol responded to Bob with an empty
> “failed” message, Bob would have no
> idea which peer to fail the probe back to, because OMs are
> stateless. Instead, Bob unwraps his error
> onion and sees that he needs to fail back to Alice with her
> provided error onion. Alice receives the
> failure onion and can see that Carol was not able to forward the
> desired amount corresponding to the
> probe id, thus completing the probe.
>
> ## Outro
>
> While there is nothing stopping nodes from lying about their
> ability to forward, they may be
> negatively scored if they do so. Further, adopting a protocol like
> this could help routing nodes
> attract more forwarding traffic, which is a nice incentive.
>
> I view this feature as a low priority enhancement, given there are
> a lot more pressing issues in LN,
> but open to feedback. Mostly, I thought it could be useful to
> spark ideas and highlight the
> flexibility of OMs.
>
> Cheers,
> Val
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> <mailto:Lightning-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
--
Sophia-Antipolis, France
CV: https://www.peersm.com/CVAV.pdf
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
GitHub : https://www.github.com/Ayms
A Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7
A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com
Peersm : http://www.peersm.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230306/a0b1de03/attachment-0001.html>

2023-06-09 13:12:33

- reply

📅 Original date posted:2023-01-31
🗒️ Summary of this message: The author proposes a simple NFT system and a universal coin swap system based on Bitcoin, which are easy to understand, secure, and decentralized. They argue that Bitcoin can do what Ethereum does in a simpler manner. The author is not against ordinals but does not see them as suitable for the "web3" future.
📝 Original message:
I am not sure to understand the current discussion about ordinals
relayed by the press, it's from my standpoint a no for storing things in
witness, and a no to use ordinals as a NFT system
Please remember that NFTs are not only electronic things, it can be real
things, or whatever you like, just referenced in the blockchain by a
"double hash" for my proposal
Bitcoin is currently completely out of the future: the so-called "web3",
and lightning will not solve everything
Then please see my two proposals and comment, it's simple and easy to
read, and just complies with all comments related to/against the
ordinals proposal (storing things for my proposals in a good old
OP_RETURN the hashes and signatures only, not flooding bitcoin with
proofs of nothing, docs, images, etc), or just point out other better
systems based on bitcoin
It just shows again that bitcoin is better in all aspects compared to
other systems
I am not against ordinals but don't see it for "web3"
Le 26/01/2023 à 21:15, Aymeric Vitte a écrit :
> Please see:
>
> "A Bitcoin NFT system"
> https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7 "The
> purpose of this proposal is to propose a simple NFT system based on the
> Bitcoin blockchain, assuming that the main purpose of a NFT is to be
> sold/bought, but not only, it can be something that you keep for
> yourself proving your ownership on the blockchain, or something that you
> offer to someone else, the advantages compared to using Ethereum or any
> blockchain/sidechain on both networks (or others) will be explained below"
>
> And the continuation:
>
> "A Universal Coin Swap system based on bitcoin"
> https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7 "The
> purpose here is to propose a simple Coin Swap decentralized system based
> on Bitcoin but that works for all blockchains/tokens"
>
> The idea is to propose something simple, that people can understand,
> secured, decentralized, easy to implement/use, not expensive for the
> users, unlike Ethereum solutions, showing also that bitcoin can easily
> do in a much more simple manner what ethereum is doing
>
> It's a bit similar to Lightning but not as sophisticated, basically the
> proof of deals are stored in OP_RETURN (looks trivial, yes, but unlike
> other solutions the proposals store a real proof and does not flood the
> bitcoin network with funny stuff, it could be turned into bitcoin
> contracts which most likely will not be recognized as standard), we
> cannot enforce everything like Lightning but the trust here is more
> based on a reputation model, and same as Lightning the cheater just lose
> its bitcoin or get tagged as a cheater, will be tracked and might assume
> the consequences later
>
> As written, I am a fan of Lightning but see it more as a middle/long
> term relationship between people since coins must be locked into a
> multisig transaction while here we are more talking about a one time
> deal, where you don't know if you will buy something else to the seller,
> with which coin and where (metaverse for example)
>
> For your review and comments, here or in private, no real inventions
> here but some non usual ideas like the double hash, the third party and
> others, solving also one of my personal problematic since years: "how to
> sell a secret NFT?"
>
> In any case it remains decentralized (but of course some tools/wallets
> must ease the process for the users), like Lightning, and unlike
> everything that is existing today in those areas to my knowledge, except
> Lightning again
>
> Regards
>
> Aymeric
>
>
--
Sophia-Antipolis, France
CV: https://www.peersm.com/CVAV.pdf
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
GitHub : https://www.github.com/Ayms
A Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7
A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com
Peersm : http://www.peersm.com

2023-06-09 13:12:33

- reply

📅 Original date posted:2023-01-26
🗒️ Summary of this message: The proposal suggests a simple NFT system and a universal coin swap system based on the Bitcoin blockchain, highlighting advantages over Ethereum solutions and offering a decentralized, secure, and easy-to-use alternative. The NFT system can be used for buying/selling or proving ownership, while the coin swap system works for all blockchains/tokens and uses a reputation model for trust. The proof of deals is stored in OP_RETURN, and the proposal solves the problem of selling a secret NFT. The systems are decentralized and do not flood the Bitcoin network with unnecessary data.
📝 Original message:
Please see:
"A Bitcoin NFT system"
https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7 "The
purpose of this proposal is to propose a simple NFT system based on the
Bitcoin blockchain, assuming that the main purpose of a NFT is to be
sold/bought, but not only, it can be something that you keep for
yourself proving your ownership on the blockchain, or something that you
offer to someone else, the advantages compared to using Ethereum or any
blockchain/sidechain on both networks (or others) will be explained below"
And the continuation:
"A Universal Coin Swap system based on bitcoin"
https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7 "The
purpose here is to propose a simple Coin Swap decentralized system based
on Bitcoin but that works for all blockchains/tokens"
The idea is to propose something simple, that people can understand,
secured, decentralized, easy to implement/use, not expensive for the
users, unlike Ethereum solutions, showing also that bitcoin can easily
do in a much more simple manner what ethereum is doing
It's a bit similar to Lightning but not as sophisticated, basically the
proof of deals are stored in OP_RETURN (looks trivial, yes, but unlike
other solutions the proposals store a real proof and does not flood the
bitcoin network with funny stuff, it could be turned into bitcoin
contracts which most likely will not be recognized as standard), we
cannot enforce everything like Lightning but the trust here is more
based on a reputation model, and same as Lightning the cheater just lose
its bitcoin or get tagged as a cheater, will be tracked and might assume
the consequences later
As written, I am a fan of Lightning but see it more as a middle/long
term relationship between people since coins must be locked into a
multisig transaction while here we are more talking about a one time
deal, where you don't know if you will buy something else to the seller,
with which coin and where (metaverse for example)
For your review and comments, here or in private, no real inventions
here but some non usual ideas like the double hash, the third party and
others, solving also one of my personal problematic since years: "how to
sell a secret NFT?"
In any case it remains decentralized (but of course some tools/wallets
must ease the process for the users), like Lightning, and unlike
everything that is existing today in those areas to my knowledge, except
Lightning again
Regards
Aymeric
--
Sophia-Antipolis, France
CV: https://www.peersm.com/CVAV.pdf
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
GitHub : https://www.github.com/Ayms
A Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7
A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com
Peersm : http://www.peersm.com

2023-06-09 13:08:41

- reply

📅 Original date posted:2023-05-12
📝 Original message:
Lightning list, I really think that you should stop this mess and
reconcentrate on technical topics
The very same did destroy the Tor-talk mailing list
Based on false assumptions as we saw later
Reading bulls all the day, everybody escaped
Result: the Tor community can't discuss any longer
Don't do the same
Le 11/05/2023 à 19:48, alicexbt via Lightning-dev a écrit :
> Hi Antoine,
>
>> I can say missing an open-source engineering meeting or being
>> revoked a few Github permissions matters far less than the clear
>> affirmation and respect of the freedom of expression, the presumption
>> of innocence and due process in the Bitcoin common space, all
>> proportions conserved.
>
> This is not acceptable. I will fight with you. Never feel alone.
>
> /devfd0
> floppy disk guy
>
> Sent with Proton Mail <https://proton.me/> secure email.
>
> ------- Original Message -------
> On Wednesday, May 10th, 2023 at 10:27 PM, Antoine Riard
> <antoine.riard at gmail.com> wrote:
>
>> Hi Tony,
>>
>> > Is there a better place to havepubliccommunication? Unfortunately
>> since one off topic email was sent here, it's been a ghost town. It
>> appears that there's many emails being held and only one moderator
>> that checks them once a week.
>>
>> As I think you're referring to my post of March 21th and as the
>> author of this post, I'll politely refuse the qualification of
>> "off-topic". I had and I still have the concerns of "frivolous legal
>> claims" being used between bitcoin developers/organizations provoking
>> a distortion of the neutrality of the development and a chilling
>> effect of the technical discussions (i.e code we compile and spec we
>> implement). For those reasons, it was my legal right and moral duty
>> to inform the community of what is happening between Chaincode and
>> myself. And here I'm following the recommendation of one of the
>> moderators of the Lightning mailing list himself "If this worries you
>> too, let's make sure we keep each other honest, OK?" [0].
>>
>> When you think a group of people with open-source responsibilities
>> are in a situation of conflict of interests or "moral hazards", or
>> even the appearance of them, you have the right to expose the
>> wrongdoing, including the _proportional_ revelation of private
>> elements. People have done the "free choice" to conduct a career in
>> open-source, for some even declaring in some context to maintain
>> integrity and accept their actions to be submitted to external
>> accountability [1]. While the exposure of private elements of public
>> personalities might break common courtesy, it's a morally valid
>> practice if you're familiar with the public institutions of US and
>> Europe, and I think this practice has found validity in the history
>> of open-source commons or IETF's protocol development [1].
>>
>> Beyond, the Bitcoin and Lightning development communication channels
>> constitute a public forum, where by nature the participants are
>> exchanging ideas and defending competing interests. In consequence,
>> the participants' rights and capabilities to contribute and speak
>> their minds in those communication channels should be protected.
>> Those communication channels are not your usual corporate workplace,
>> and in case of conflicting principles, the maintainers of those
>> communication channels should ensure a balance of rights and a
>> proportionality in any restraining measure.
>>
>> And this new post is not to exonerate myself of any legal
>> responsibility for personal matters that could be recognized as the
>> outcome of a judicial process, respective of both rights of the
>> accusation and rights of the defense. Rather to enlighten the Bitcoin
>> community that the formal separation between private matters and
>> open-source responsibilities, and the adequate check-and-balances to
>> guarantee this separation is somehow what are the underlying stakes
>> for this feud between Chaincode and myself, from my perspective. I
>> can say missing an open-source engineering meeting or being revoked a
>> few Github permissions matters far less than the clear affirmation
>> and respect of the freedom of expression, the presumption of
>> innocence and due process in the Bitcoin common space, all
>> proportions conserved.
>>
>> I don't blame any party involved in this issue, nor assign "bad
>> intentions''. One position is really a function of your life
>> experiences, knowledge of the legal and cultural framework and access
>> to the factual elements. As all human conflicts it is not binary
>> rather "grey". People can be top executives at a billion-dollar
>> company, having successful ventures with hundreds of folks under
>> management, or have a lot of responsibilities for their relative
>> young age, and still disagree on the set of legal and moral
>> principles to apply in the present case.
>>
>> Finally, thanks to the Bitcoin friends who have reached out to call
>> for level-headedness and cool-mindness in the public discussion of
>> this complex topic. Like I said to them, in the lack of more
>> suspected wrongdoing from the other side, I won't communicate further
>> on this subject on the Bitcoin and Lightning technical channels.
>> However I still firmly believe the discussion on the principles,
>> abstract in the maximum from its private elements, should still be
>> pursued on other channels. Independently, there is a legal channel
>> opened between Chaincode and myself and good progress is made to find
>> a serene and long-standing resolution to this issue.
>>
>> Best,
>> Antoine
>>
>> [0]
>> https://rusty-lightning.medium.com/the-corrosion-of-ethics-in-cryptocurrencies-f7ba77e9dfc3
>> [1]
>> https://github.com/btrustteam/board-book/blob/main/vision/genesis_principles.md
>> [2]
>> https://www.ietf.org/about/administration/policies-procedures/conflict-interest/
>>
>> Le lun. 8 mai 2023 à 21:26, Tony Giorgio via Lightning-dev
>> <lightning-dev at lists.linuxfoundation.org
>> <mailto:lightning-dev at lists.linuxfoundation.org>> a écrit :
>>
>> Is there a better place to have public communication?
>> Unfortunately since one off topic email was sent here, it's been
>> a ghost town. It appears that there's many emails being held and
>> only one moderator that checks them once a week.
>>
>> Would hate to see this list die but wondering if there's a better
>> place for discussions?
>>
>> Tony
>>
>>
>>
>>
>>
>>
>> -------- Original Message --------
>> On Apr 29, 2023, 9:57 PM, niftynei < niftynei at gmail.com
>> <mailto:niftynei at gmail.com>> wrote:
>>
>>
>> Hi all,
>>
>> When I joined the lightning community a few years ago, I was
>> relatively new to open source software and specification
>> work. Rusty really impressed on me on the importance of
>> holding conversations, as much as possible in public.
>>
>> Practically speaking, this encompasses IRC, this mailing
>> list, and github issues/PRs.
>>
>> The reason for this is twofold. It helps document the range
>> of options considered for technical decisions and it provides
>> an interface point for new participants to contribute to the
>> discussion.
>>
>> Given some recent mails that were posted to this list, now
>> seems like a good time to reiterate the importance and
>> preference of public communication whenever possible,
>> especially for specification or technical discussions.
>>
>>
>> ~ nifty
>>
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> <mailto:Lightning-dev at lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>
>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
--
Sophia-Antipolis, France
CV: https://www.peersm.com/CVAV.pdf
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
GitHub : https://www.github.com/Ayms
A Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7
A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
Bitcoin, Ethereum, smart contracts, lightning, sidechains, Defi, DApps, NFTs, DEX, DAO explained - Centralization vs Decentralization https://gist.github.com/Ayms/04b3084a14ee202e707b3faec57ed26e
Discover and Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com
Peersm : http://www.peersm.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230512/446a64e4/attachment-0001.html>

2023-06-09 13:08:14

- reply

📅 Original date posted:2023-03-06
📝 Original message:
The question is not really related to onion messages but why is
Lightning not using a DHT system for gossip?
Le 01/03/2023 à 19:02, Antoine Riard a écrit :
> Hi Val,
>
> Thanks for the proposal here. About using OM for payment probing, I
> think there could be an alternative of the routing hops themselves
> announcing their liquidity balances with an extension or new set of
> gossip messages.
>
> Gossips messages could commit to a liquidity balance and duration
> (e.g +1000 blocks from tip), rather relying on sender-side probing,
> which might be less and less accurate with higher rate of network
> liquidity congestion. Additionally, a routing hop could commit to
> "private" gossip sent back to HTLC senders during HTLC successful
> settlement. Those "private" gossip might announce "differentiated
> services" of channel liquidity levels. I believe this can be
> guaranteed transparently from the rest of the network thanks to
> parallel channels.
>
> Any deviation from the gossip message could be penalized by sender's
> scoring algorithms as the liquidity SLA parameters have been announced
> explicitly by the routing hops. This is just an intuition on how
> public channel liquidity discovery could be worked out, and I don't
> know which of the alternatives would be more efficient in terms of
> bandwidth/convergence delays.
>
> Best,
> Antoine
>
> Le lun. 27 févr. 2023 à 21:32, vwallace via Lightning-dev
> <lightning-dev at lists.linuxfoundation.org
> <mailto:lightning-dev at lists.linuxfoundation.org>> a écrit :
>
> Hi list!
>
> I wanted to bring up the idea of using onion messages for payment
> probing, which was briefly touched
> on at the 2022 LN summit. Tadge Dryja has also brought up a
> similar idea.
>
> I recommend reading the gist instead since it has the relevant
> diagrams in-line:
> https://gist.github.com/valentinewallace/ebe1741f0438c2360eda0f80f0e075c9
> but the scheme is also
> posted below for convenience.
>
> ## Introduction
>
> For context, in today’s lightning, payment reliability tends to
> heavily depend on having sufficient
> payment volume to determine current liquidity balances of
> channels, which is how most big nodes can
> tell whether a given channel has enough liquidity to forward a
> given amount. If a node is using HTLC
> probing to achieve this payment volume, they use a regular
> `update_add_htlc` message with a bogus
> payment hash, where the error returned informs the sender of
> whether the payment reached the final
> recipient. Note that there is a tradeoff between always routing
> through nodes that are known to
> rebalance their channels vs leaning on probing smaller nodes and
> “risking” payments through them
> based on what’s learned.
>
> Today’s HTLC payment probing can work well, but risks channel
> liquidity being locked up if a peer
> along the route goes offline. On the upside, for just-in-time
> probes, it works to loosely “reserve”
> the channel liquidity along the route for the actual payment.
>
> Onion messages (OMs) present a convenient way to probe without
> risking locked liquidity along the
> route.
>
> ## Design Rationale
>
> A naive approach could be to send onion message probes directly to
> individual nodes along the
> desired route, including those to which you don’t have a direct
> channel. However, this scheme is
> problematic because it would enable monitoring the payment flows
> of arbitrary nodes across the
> network without having to have a channel path to them. This would
> be a significant degradation of
> privacy because, for comparison, in HTLC probing it is quite
> difficult to probe the balances of
> far-off nodes. And if you can’t probe a node using HTLCs, you
> can’t send over it anyway, so there’s
> not a lot of benefit (and significant privacy downside).
>
> Therefore, it is probably best to design a scheme that probes
> along channel paths, like HTLC
> probing. This adds more complexity to the case where an
> intermediate node cannot forward the desired
> amount due to the stateless nature of OMs, discussed further down.
>
> ## Scheme
>
> Let’s go through the happy path, where Alice is probing Alice >
> Bob > Carol > Dave for a 100k msat
> payment.
>
> She’ll construct an onion message for Bob, the first hop, as such:
> https://imgur.com/BZg8yt8
>
> Bob receives this OM, sees that he’s able to forward 110k msats to
> his next-hop Carol, and forwards
> Carol’s onion packet to her. Carol sees she can forward 105k msats
> to Dave, and forwards his onion
> packet. Finally, Dave receives his onion packet, sees he can
> receive 100k msats from Carol, and uses
> the provided reply path to send a simple probe success onion
> message back to Alice:
>
> ```
> onion_message_probe_result {
> data_tlv {
> type: 4242,
> probe_id: [u8; 32],
> can_forward_desired_amt: true,
> }
> .. regular OM TLVs
> }
> ```
>
> Note that Dave will use this same onion message if he can’t
> receive; he’ll just set
> `can_forward_desired_amt` to false.
>
> As an example of the sad path for an intermediate node, if Carol
> can’t forward 105k msats to Dave,
> she’ll fail the probe back to Bob by sending this onion message:
> https://imgur.com/a/hqlzw4I
>
> This step justifies why we need to encode a failure onion for each
> intermediate hop of a probe. If
> we hadn’t done that, and Carol responded to Bob with an empty
> “failed” message, Bob would have no
> idea which peer to fail the probe back to, because OMs are
> stateless. Instead, Bob unwraps his error
> onion and sees that he needs to fail back to Alice with her
> provided error onion. Alice receives the
> failure onion and can see that Carol was not able to forward the
> desired amount corresponding to the
> probe id, thus completing the probe.
>
> ## Outro
>
> While there is nothing stopping nodes from lying about their
> ability to forward, they may be
> negatively scored if they do so. Further, adopting a protocol like
> this could help routing nodes
> attract more forwarding traffic, which is a nice incentive.
>
> I view this feature as a low priority enhancement, given there are
> a lot more pressing issues in LN,
> but open to feedback. Mostly, I thought it could be useful to
> spark ideas and highlight the
> flexibility of OMs.
>
> Cheers,
> Val
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> <mailto:Lightning-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
--
Sophia-Antipolis, France
CV: https://www.peersm.com/CVAV.pdf
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
GitHub : https://www.github.com/Ayms
A Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7
A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com
Peersm : http://www.peersm.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230306/a0b1de03/attachment-0001.html>

2023-06-09 13:07:57

- reply

📅 Original date posted:2023-01-26
📝 Original message:
Please see:
"A Bitcoin NFT system"
https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7 "The
purpose of this proposal is to propose a simple NFT system based on the
Bitcoin blockchain, assuming that the main purpose of a NFT is to be
sold/bought, but not only, it can be something that you keep for
yourself proving your ownership on the blockchain, or something that you
offer to someone else, the advantages compared to using Ethereum or any
blockchain/sidechain on both networks (or others) will be explained below"
And the continuation:
"A Universal Coin Swap system based on bitcoin"
https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7 "The
purpose here is to propose a simple Coin Swap decentralized system based
on Bitcoin but that works for all blockchains/tokens"
The idea is to propose something simple, that people can understand,
secured, decentralized, easy to implement/use, not expensive for the
users, unlike Ethereum solutions, showing also that bitcoin can easily
do in a much more simple manner what ethereum is doing
It's a bit similar to Lightning but not as sophisticated, basically the
proof of deals are stored in OP_RETURN (looks trivial, yes, but unlike
other solutions the proposals store a real proof and does not flood the
bitcoin network with funny stuff, it could be turned into bitcoin
contracts which most likely will not be recognized as standard), we
cannot enforce everything like Lightning but the trust here is more
based on a reputation model, and same as Lightning the cheater just lose
its bitcoin or get tagged as a cheater, will be tracked and might assume
the consequences later
As written, I am a fan of Lightning but see it more as a middle/long
term relationship between people since coins must be locked into a
multisig transaction while here we are more talking about a one time
deal, where you don't know if you will buy something else to the seller,
with which coin and where (metaverse for example)
For your review and comments, here or in private, no real inventions
here but some non usual ideas like the double hash, the third party and
others, solving also one of my personal problematic since years: "how to
sell a secret NFT?"
In any case it remains decentralized (but of course some tools/wallets
must ease the process for the users), like Lightning, and unlike
everything that is existing today in those areas to my knowledge, except
Lightning again
Regards
Aymeric
--
Sophia-Antipolis, France
CV: https://www.peersm.com/CVAV.pdf
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
GitHub : https://www.github.com/Ayms
A Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7
A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com
Peersm : http://www.peersm.com

2023-06-09 13:07:57

- reply

📅 Original date posted:2023-01-31
📝 Original message:
I am not sure to understand the current discussion about ordinals
relayed by the press, it's from my standpoint a no for storing things in
witness, and a no to use ordinals as a NFT system
Please remember that NFTs are not only electronic things, it can be real
things, or whatever you like, just referenced in the blockchain by a
"double hash" for my proposal
Bitcoin is currently completely out of the future: the so-called "web3",
and lightning will not solve everything
Then please see my two proposals and comment, it's simple and easy to
read, and just complies with all comments related to/against the
ordinals proposal (storing things for my proposals in a good old
OP_RETURN the hashes and signatures only, not flooding bitcoin with
proofs of nothing, docs, images, etc), or just point out other better
systems based on bitcoin
It just shows again that bitcoin is better in all aspects compared to
other systems
I am not against ordinals but don't see it for "web3"
Le 26/01/2023 à 21:15, Aymeric Vitte a écrit :
> Please see:
>
> "A Bitcoin NFT system"
> https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7 "The
> purpose of this proposal is to propose a simple NFT system based on the
> Bitcoin blockchain, assuming that the main purpose of a NFT is to be
> sold/bought, but not only, it can be something that you keep for
> yourself proving your ownership on the blockchain, or something that you
> offer to someone else, the advantages compared to using Ethereum or any
> blockchain/sidechain on both networks (or others) will be explained below"
>
> And the continuation:
>
> "A Universal Coin Swap system based on bitcoin"
> https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7 "The
> purpose here is to propose a simple Coin Swap decentralized system based
> on Bitcoin but that works for all blockchains/tokens"
>
> The idea is to propose something simple, that people can understand,
> secured, decentralized, easy to implement/use, not expensive for the
> users, unlike Ethereum solutions, showing also that bitcoin can easily
> do in a much more simple manner what ethereum is doing
>
> It's a bit similar to Lightning but not as sophisticated, basically the
> proof of deals are stored in OP_RETURN (looks trivial, yes, but unlike
> other solutions the proposals store a real proof and does not flood the
> bitcoin network with funny stuff, it could be turned into bitcoin
> contracts which most likely will not be recognized as standard), we
> cannot enforce everything like Lightning but the trust here is more
> based on a reputation model, and same as Lightning the cheater just lose
> its bitcoin or get tagged as a cheater, will be tracked and might assume
> the consequences later
>
> As written, I am a fan of Lightning but see it more as a middle/long
> term relationship between people since coins must be locked into a
> multisig transaction while here we are more talking about a one time
> deal, where you don't know if you will buy something else to the seller,
> with which coin and where (metaverse for example)
>
> For your review and comments, here or in private, no real inventions
> here but some non usual ideas like the double hash, the third party and
> others, solving also one of my personal problematic since years: "how to
> sell a secret NFT?"
>
> In any case it remains decentralized (but of course some tools/wallets
> must ease the process for the users), like Lightning, and unlike
> everything that is existing today in those areas to my knowledge, except
> Lightning again
>
> Regards
>
> Aymeric
>
>
--
Sophia-Antipolis, France
CV: https://www.peersm.com/CVAV.pdf
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
GitHub : https://www.github.com/Ayms
A Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7
A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com
Peersm : http://www.peersm.com

2023-06-07 23:21:41

- reply

📅 Original date posted:2023-05-09
🗒️ Summary of this message: The discussion on raising the limit on OP_RETURN continues, but there are concerns about controlling the value of stored information and avoiding freeriders. Decentralization may be a solution.
📝 Original message:Le 08/05/2023 à 23:43, Christopher Allen via bitcoin-dev a écrit :
> There was a recent thread discussing raising the limit on
> OP_RETURN https://github.com/bitcoin/bitcoin/issues/27043
Indeed we already discussed all of this, and the conclusion was: there
are no reasons to impose limits, because people will find some deviant
(or not) workarounds (like Stamps), and fees will regulate this
And how to control the value of what is stored? If I store e=mc2, the
way I like since as many said it's super easy to find plenty of ways to
store in bitcoin, this one is short and supposed to have more value than
bitcoin, no?
Personnally I think of course that you should store a reference to
something and not the something, so a few hashes and/or signatures which
you cannot do with OP_RETURN today (80B Moth, not 80kB)
I don't see very well what can be done against the freeriders, except
avoiding that they impact the whole network (a bit à la bittorrent),
maybe the issue is more about decentralization rather than trying to
impose limitations, so the decentralized miners can't have the whole
image of the whole txs and hold low fees txs, which is not the case at
all today, but it seems a bit utopic right now
Or maybe when the ordinal meme stuff/BRC20 will be proven to have
finally zero value the market will self regulate
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230509/a1edd728/attachment.html>

2023-06-07 23:20:45

- reply

📅 Original date posted:2023-04-20
🗒️ Summary of this message: The writer criticizes the slow and inefficient decision-making process of organizations like W3C and suggests that Bitcoin companies involve more efficient people in their development process. They also express concern about the cost of Bitcoin maintenance and the resignations of developers.
📝 Original message:Right, that's why I do not participate any longer, they specify things
for the participants (ie big companies), they disregard whatever
suggestion can be made, they are so slow that when they have specified
something someone else has specified something better, then they throw
away their spec and take what the others have specified
And they are wrong in many design decisions
What I meant is that bitcoin big companies should involve people, who
are not just discussing stupid things all the day like W3C folks but do
the work efficiently
Le 20/04/2023 à 15:59, Erik Aronesty a écrit :
> i think the w3c is a very good example of a slow train wreck, and we
> should do everything possible to avoid the decisions they made
>
> On Thu, Apr 20, 2023 at 7:09 AM Aymeric Vitte via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> Personnally I will never criticize the maintainers, but my comment was
> about the global process, I thought that for something important like
> bitcoin there were many devs/maintainers, and as you point out, a PR
> must be done by certified people
>
> I don't get very well why every company involved in bitcoin do not put
> at least one person in this process (a bit like W3C specs), with
> different time zone so every time you wake up you don't have to look
> at/handle hundreds of requests/comments
>
> And we can read in the press that bitcoin maintenance is supposed to
> cost 200M per year, probably false then, but this is worrying to see
> that devs/maintainers are stepping down one after the other
>
>
> Le 19/04/2023 à 23:33, Andrew Chow via bitcoin-dev a écrit :
> > Responses in-line.
> > Note that the opinions expressed in this email are my own and
> are not
> > representative of what other maintainers think or believe.
> >
> > On 04/18/2023 08:40 AM, Michael Folkson via bitcoin-dev wrote:
> > >
> > > Communication has been a challenge on Bitcoin Core for what I can
> > tell the entire history of the project. Maintainers merge a pull
> request
> > and provide no commentary on why they’ve merged it.
> >
> > What commentary does there need to be?
> > It's self evident that the maintainer believes the code is ready
> to be
> > merged, and has observed enough ACKs from contributors that they are
> > comfortable to do so.
> > You're welcome to ask for clarification, but frankly, I don't think
> > having any commentary on merges is going to be helpful or more
> elaborate
> > in any way.
> > Requiring maintainers to have to write explanations for every single
> > merge is simply going to increase the burden on them and
> increase the
> > rate of burnout and resignations.
> > We've had too many maintainers step down already.
> > It'll end up being a bunch of boilerplate comments that don't say
> > anything meaningful.
> >
> > There are certainly situations where PRs are merged very quickly
> or with
> > otherwise little apparent review.
> > But, as I said, if you ask a maintainer why it was merged, the
> answer
> > will be "I thought it was ready and had enough review".
> > There may be other reasons that made the maintainer think it was
> ready
> > sooner, such as the PR fixes a critical bug or security
> vulnerability,
> > but these reasons aren't going to be stated publicly.
> >
> > > Maintainers leave a pull request with many ACKs and few (if any)
> > NACKs for months and provide no commentary on why they haven't
> merged it.
> >
> > There are currently 320 open PRs and 366 open issues.
> > I wake up every morning to 150+ email notifications containing
> > everything that went on overnight, and throughout the day, I
> typically
> > get hundreds more.
> > It's impossible to keep up with everything that goes on
> throughout the repo.
> > ACKs come in sporadically, PRs are updated, reviews are posted, etc.
> > Often times PRs are not merged simply because the maintainers
> were not
> > aware that a PR was ready to be merged.
> > Things can simply fall through the cracks.
> >
> > Of course there are other reasons why something might not be
> merged, and
> > these generally fall into the camp of "I don't think it has had
> enough
> > review".
> > It's the maintainer's judgement call to make as to whether
> something has
> > been sufficiently reviewed, and part of the judgement call is to
> > consider the quality and competence of the reviewers.
> > If a PR had 100 ACKs but all from random people who have never
> > contributed to the project in any capacity, then it's not going
> to be
> > merged because those reviewers would be considered low quality.
> > It's not just about the numbers, but also about whether the
> reviewers
> > are people the maintainers think are familiar enough with an
> area and
> > have had a history of thoroughly reviewing PRs.
> > For example, if a reviewer who primarily works on the mempool
> reviewed a
> > PR in the wallet, I would consider their review and ACK with
> less weight
> > because they are unlikely to be familiar with the intricacies of
> the wallet.
> > Obviously that changes over time as they make more reviews.
> > For another example, if I see an ACK from a reviewer who posts
> reviews
> > that primarily contain nits on code style and other trivialities, I
> > would consider that ACK with less weight.
> >
> > Furthermore, the maintainers are not necessarily the ones who
> block a merge.
> > Part of evaluating if something is ready to be merged is to read the
> > comments on a PR.
> > Other frequent contributors may have commented or asked
> questions that
> > haven't been resolved yet.
> > PRs will often not be merged (even if they have ACKs) until a
> maintainer
> > deems that those comments and questions have been sufficiently
> resolved,
> > typically with the commenter stating in some way that their concerns
> > were addressed.
> > In these situations, no commentary from maintainers is given nor
> > necessary as it should be self evident (by reading the comments)
> that
> > something is controversial.
> > These kinds of comments are not explicit NACKs (so someone who
> is only
> > counting (N)ACKs won't see them), but are blocking nonetheless.
> >
> > Lastly, personally I like to review every PR before I merge it.
> > This often means that a PR that might otherwise be ready to be
> merged
> > wouldn't be merged by myself as I may not be familiar with that
> part of
> > the codebase.
> > It may also mean that I would require more or specific
> additional people
> > to review a PR before I merge it as I would weight my own review
> less
> > heavily.
> > With several long time maintainers stepping away, this may be a
> factor
> > in PRs taking longer to get merged as the remaining maintainers
> may be
> > less familiar with the parts of the codebase that were previously
> > maintained by someone else.
> >
> > > but a casual observer would have only seen Concept ACKs and
> ACKs with
> > 3 stray NACKs. Many of these casual observers inflated the
> numbers on
> > the utxos.org <http://utxos.org> site [4] signalling support for
> a soft fork activation
> > attempt.
> >
> > Anyone who thinks that maintainers only look at the numbers of
> (N)ACKs
> > is delusional.
> > As I explained above, there is a whole lot more nuance to
> determining
> > even just the status of the opinions on a PR, nevermind the code
> itself.
> >
> > In this specific example of a soft fork, there is also
> consideration of
> > the opinions outside of the repo itself, such as on this mailing
> list
> > and elsewhere that people discuss soft forks.
> >
> > On 04/19/2023 11:17 AM, Aymeric Vitte via bitcoin-dev wrote:
> > > While some simple changes can allow bitcoin to surpass
> ethereum, as
> > usual, like "Allow several OP_RETURN in one tx and no limited size"
> > https://github.com/bitcoin/bitcoin/issues/27043
> > >
> > > How long it will take remains mysterious
> >
> > No one (maintainers or contributors) is obligated to implement
> anything.
> > A feature request not being implemented is because the people who do
> > open PRs are either not interested in implementing the feature,
> or are
> > working on other things that they believe to be higher priority.
> > If there is a feature that you want, then you will often need to
> either
> > to it yourself, or pay someone to do it for you.
> >
> > Additionally, a feature may seem like a good idea to you, but
> there are
> > often interactions with other things that may end up resulting in it
> > being rejected or need significant revision, especially for
> something
> > which affects transaction relay.
> >
> >
> >
> > Andrew Chow
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> --
> Sophia-Antipolis, France
> CV: https://www.peersm.com/CVAV.pdf
> LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
> GitHub : https://www.github.com/Ayms
> A Universal Coin Swap system based on Bitcoin:
> https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7
> A bitcoin NFT system:
> https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
> Move your coins by yourself (browser version):
> https://peersm.com/wallet
> Bitcoin transactions made simple:
> https://github.com/Ayms/bitcoin-transactions
>
> torrent-live: https://github.com/Ayms/torrent-live
> node-Tor : https://www.github.com/Ayms/node-Tor
> Anti-spies and private torrents, dynamic blocklist:
> http://torrent-live.peersm.com
> Peersm : http://www.peersm.com
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
Sophia-Antipolis, France
CV: https://www.peersm.com/CVAV.pdf
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
GitHub : https://www.github.com/Ayms
A Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7
A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com
Peersm : http://www.peersm.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230420/8ea98348/attachment-0001.html>

2023-06-07 23:20:42

- reply

📅 Original date posted:2023-04-20
🗒️ Summary of this message: Bitcoin Core maintainers face communication challenges and a high workload, leading to burnout and resignations. PRs may not be merged due to oversight.
📝 Original message:Personnally I will never criticize the maintainers, but my comment was
about the global process, I thought that for something important like
bitcoin there were many devs/maintainers, and as you point out, a PR
must be done by certified people
I don't get very well why every company involved in bitcoin do not put
at least one person in this process (a bit like W3C specs), with
different time zone so every time you wake up you don't have to look
at/handle hundreds of requests/comments
And we can read in the press that bitcoin maintenance is supposed to
cost 200M per year, probably false then, but this is worrying to see
that devs/maintainers are stepping down one after the other
Le 19/04/2023 à 23:33, Andrew Chow via bitcoin-dev a écrit :
> Responses in-line.
> Note that the opinions expressed in this email are my own and are not
> representative of what other maintainers think or believe.
>
> On 04/18/2023 08:40 AM, Michael Folkson via bitcoin-dev wrote:
> >
> > Communication has been a challenge on Bitcoin Core for what I can
> tell the entire history of the project. Maintainers merge a pull request
> and provide no commentary on why they’ve merged it.
>
> What commentary does there need to be?
> It's self evident that the maintainer believes the code is ready to be
> merged, and has observed enough ACKs from contributors that they are
> comfortable to do so.
> You're welcome to ask for clarification, but frankly, I don't think
> having any commentary on merges is going to be helpful or more elaborate
> in any way.
> Requiring maintainers to have to write explanations for every single
> merge is simply going to increase the burden on them and increase the
> rate of burnout and resignations.
> We've had too many maintainers step down already.
> It'll end up being a bunch of boilerplate comments that don't say
> anything meaningful.
>
> There are certainly situations where PRs are merged very quickly or with
> otherwise little apparent review.
> But, as I said, if you ask a maintainer why it was merged, the answer
> will be "I thought it was ready and had enough review".
> There may be other reasons that made the maintainer think it was ready
> sooner, such as the PR fixes a critical bug or security vulnerability,
> but these reasons aren't going to be stated publicly.
>
> > Maintainers leave a pull request with many ACKs and few (if any)
> NACKs for months and provide no commentary on why they haven't merged it.
>
> There are currently 320 open PRs and 366 open issues.
> I wake up every morning to 150+ email notifications containing
> everything that went on overnight, and throughout the day, I typically
> get hundreds more.
> It's impossible to keep up with everything that goes on throughout the repo.
> ACKs come in sporadically, PRs are updated, reviews are posted, etc.
> Often times PRs are not merged simply because the maintainers were not
> aware that a PR was ready to be merged.
> Things can simply fall through the cracks.
>
> Of course there are other reasons why something might not be merged, and
> these generally fall into the camp of "I don't think it has had enough
> review".
> It's the maintainer's judgement call to make as to whether something has
> been sufficiently reviewed, and part of the judgement call is to
> consider the quality and competence of the reviewers.
> If a PR had 100 ACKs but all from random people who have never
> contributed to the project in any capacity, then it's not going to be
> merged because those reviewers would be considered low quality.
> It's not just about the numbers, but also about whether the reviewers
> are people the maintainers think are familiar enough with an area and
> have had a history of thoroughly reviewing PRs.
> For example, if a reviewer who primarily works on the mempool reviewed a
> PR in the wallet, I would consider their review and ACK with less weight
> because they are unlikely to be familiar with the intricacies of the wallet.
> Obviously that changes over time as they make more reviews.
> For another example, if I see an ACK from a reviewer who posts reviews
> that primarily contain nits on code style and other trivialities, I
> would consider that ACK with less weight.
>
> Furthermore, the maintainers are not necessarily the ones who block a merge.
> Part of evaluating if something is ready to be merged is to read the
> comments on a PR.
> Other frequent contributors may have commented or asked questions that
> haven't been resolved yet.
> PRs will often not be merged (even if they have ACKs) until a maintainer
> deems that those comments and questions have been sufficiently resolved,
> typically with the commenter stating in some way that their concerns
> were addressed.
> In these situations, no commentary from maintainers is given nor
> necessary as it should be self evident (by reading the comments) that
> something is controversial.
> These kinds of comments are not explicit NACKs (so someone who is only
> counting (N)ACKs won't see them), but are blocking nonetheless.
>
> Lastly, personally I like to review every PR before I merge it.
> This often means that a PR that might otherwise be ready to be merged
> wouldn't be merged by myself as I may not be familiar with that part of
> the codebase.
> It may also mean that I would require more or specific additional people
> to review a PR before I merge it as I would weight my own review less
> heavily.
> With several long time maintainers stepping away, this may be a factor
> in PRs taking longer to get merged as the remaining maintainers may be
> less familiar with the parts of the codebase that were previously
> maintained by someone else.
>
> > but a casual observer would have only seen Concept ACKs and ACKs with
> 3 stray NACKs. Many of these casual observers inflated the numbers on
> the utxos.org site [4] signalling support for a soft fork activation
> attempt.
>
> Anyone who thinks that maintainers only look at the numbers of (N)ACKs
> is delusional.
> As I explained above, there is a whole lot more nuance to determining
> even just the status of the opinions on a PR, nevermind the code itself.
>
> In this specific example of a soft fork, there is also consideration of
> the opinions outside of the repo itself, such as on this mailing list
> and elsewhere that people discuss soft forks.
>
> On 04/19/2023 11:17 AM, Aymeric Vitte via bitcoin-dev wrote:
> > While some simple changes can allow bitcoin to surpass ethereum, as
> usual, like "Allow several OP_RETURN in one tx and no limited size"
> https://github.com/bitcoin/bitcoin/issues/27043
> >
> > How long it will take remains mysterious
>
> No one (maintainers or contributors) is obligated to implement anything.
> A feature request not being implemented is because the people who do
> open PRs are either not interested in implementing the feature, or are
> working on other things that they believe to be higher priority.
> If there is a feature that you want, then you will often need to either
> to it yourself, or pay someone to do it for you.
>
> Additionally, a feature may seem like a good idea to you, but there are
> often interactions with other things that may end up resulting in it
> being rejected or need significant revision, especially for something
> which affects transaction relay.
>
>
>
> Andrew Chow
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Sophia-Antipolis, France
CV: https://www.peersm.com/CVAV.pdf
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
GitHub : https://www.github.com/Ayms
A Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7
A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com
Peersm : http://www.peersm.com

2023-06-07 23:20:39

- reply

📅 Original date posted:2023-04-19
🗒️ Summary of this message: Bitcoin Core's communication issues persist, with maintainers lacking transparency on merge decisions. Bitcoin's future relies on lightning and complex changes, but simple changes could surpass Ethereum.
📝 Original message:The different emails are overlong, it's difficult to follow
It is super surprising to see that Bitcoin has only 4 maintainers funded
by Brink and Blockstream, but I think the decisions are taken elsewhere
And I think the job of the maintainers is not only to be maintainers but
to do the PR sometimes, since the process is too complicate and they are
supposed to know well the code
And it seems like bitcoin is betting its future on lightning and/or
super clever (non understandble) changes to bitcoin scripting
While some simple changes can allow bitcoin to surpass ethereum, as
usual, like "Allow several OP_RETURN in one tx and no limited size"
https://github.com/bitcoin/bitcoin/issues/27043
How long it will take remains mysterious
Le 18/04/2023 à 14:40, Michael Folkson via bitcoin-dev a écrit :
>
> Communication has been a challenge on Bitcoin Core for what I can tell
> the entire history of the project. Maintainers merge a pull request
> and provide no commentary on why they’ve merged it. Maintainers leave
> a pull request with many ACKs and few (if any) NACKs for months and
> provide no commentary on why they haven't merged it. I can only
> speculate on why and it probably depends on the individual maintainer.
> Sometimes it will be poor communication skills, sometimes it will be a
> desire to avoid accountability, sometimes it will be fear of
> unreasonable and spiteful legal action if they mistakenly merge a pull
> request that ends up containing a bug. But search through the pull
> requests on Bitcoin Core and you will rarely see a rationale for a
> merge decision. The difference between say previous maintainers like
> Wladimir and some of the current maintainers is that previous
> maintainers were extremely responsive on IRC. If you disagreed with a
> merge decision or thought it had been merged prematurely they would be
> happy to discuss it on IRC. In present times at least a subset of the
> current maintainers are not responsive on IRC and will refuse to
> discuss a merge decision. One farcical recent example [0] was the pull
> request to add Vasil Dimov as a maintainer where despite many ACKs
> from other maintainers and other long term contributors two
> maintainers (fanquake and Gloria) refused to discuss it on the pull
> request or on IRC. It took almost 5 months for Gloria to comment on
> the pull request despite many requests from me on the PR and on IRC. I
> even requested that they attend the weekly Core Dev IRC meeting to
> discuss it which they didn’t attend.
>
>
> A pull request to add a maintainer isn’t a normal pull request.
> Generally pull requests contain a lot more lines of code than a single
> line adding a trusted key. Not merging a pull request for a long
> period of time can be extremely frustrating for a pull request author
> especially when maintainers and long term contributors don’t comment
> on the pull request and the pull request is stuck in “rebase hell”.
> Clearly it is the lesser evil when compared to merging a harmful or
> bug ridden pull request but poor non-existent communication is not the
> only way to prevent this. Indeed it creates as many problems as it solves.
>
>
> Another farcical recent(ish) example was the CTV pull request [1] that
> ultimately led to a contentious soft fork activation attempt that was
> called off at the last minute. If you look at the comments on the pull
> request there were 3 individuals (including myself) who NACKed the
> pull request and I think it is fair to say that none of us would be
> considered long term contributors to Bitcoin Core. I have criticised
> Jeremy Rubin multiple times for continuing to pursue a soft fork
> activation attempt when it was clear it was contentious [3] but if you
> look at the pull request comments it certainly isn’t clear it was.
> Maintainers and long term contributors (if they commented at all) were
> gently enthusiastic (Concept ACKing etc) without ACKing that it was
> ready to merge. A long term observer of the Core repo would have known
> that it wasn’t ready to merge or ready to attempt to activate
> (especially given it was a consensus change) but a casual observer
> would have only seen Concept ACKs and ACKs with 3 stray NACKs. Many of
> these casual observers inflated the numbers on the utxos.org site [4]
> signalling support for a soft fork activation attempt.
>
>
> I set out originally to write about the controls and processes around
> merges on the default signet (bitcoin-inquisition [5]) but it quickly
> became obvious to me that if communication around Core
> merges/non-merges is this weak you can hardly expect it to be any
> better on bitcoin-inquisition/default signet where there is no real
> monetary value at stake. I will probably write about
> bitcoin-inquisition/default signet in a future email as I do think the
> perception that it is “the one and only” staging ground for consensus
> changes is dangerous [6] if the maintainer(s) on that project have the
> same inclinations as a subset of the Core maintainers.
>
>
> As I stated at the beginning there is an element to this which is not
> individual(s) specific and an adverse reaction to outright malicious
> actors external to any of these projects. I do not think any of the
> current maintainers on Core or bitcoin-inquisition are outright
> malicious even if a subset of them consistently frustrate me with
> their lack of transparency and accountability. But this issue isn't
> going away and I'm sure we'll hear more on this from others in the
> coming months. To me it is a straight choice of taking transparency
> and accountability much more seriously or failing that investing more
> heavily (time and resources) in consensus compatible forks of Core and
> treating Core like it is a proprietary "open source" project where
> merge decisions are not explained or justified in the open.
>
>
> [0]: https://github.com/bitcoin/bitcoin/pull/25871
>
> [1]: https://github.com/bitcoin/bitcoin/pull/21702
>
> [2]:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020386.html
>
> [3]:
> https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718
>
> [4]: https://utxos.org/signals/
>
> [5]:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020921.html
>
> [6]:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020948.html
>
> -- Michael Folkson Email: michaelfolkson at protonmail.com
> <http://protonmail.com/>
> Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159
> 214C FEE3
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Sophia-Antipolis, France
CV: https://www.peersm.com/CVAV.pdf
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
GitHub : https://www.github.com/Ayms
A Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7
A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com
Peersm : http://www.peersm.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230419/4bf67dba/attachment-0001.html>

2023-06-07 23:19:22

- reply

📅 Original date posted:2023-02-07
🗒️ Summary of this message: The writer argues against storing large data in the blockchain, suggesting instead to store proofs and use third-party validation for accuracy.
📝 Original message:Le 06/02/2023 à 19:05, Erik Aronesty via bitcoin-dev a écrit :
> my favorite one is the javascript exploit for people that like to
> render untrusted blockchain data in their browser
Taking this example to show that from my standpoint it's not a good idea
to store "big things" in the blockchain, but it's a good idea to store
proofs of something ( then this is the rationale for this change request
https://github.com/bitcoin/bitcoin/issues/27043), we all know that there
are plenty of useless things already stored in the blockchain, now if
people want to pay to store big things, then let them do it
But how can you validate what is stored? Simple answer: you can't, I
take in my NFT proposal the example of js code loading, it's impossible
to be sure of the code loaded (and it is supposed to evolve, then which
version is correct in the blockchain can be mysterious) without using a
third party, that's what I am doing here: https://peersm.com/wallet, the
third party is my github repo, the code self validates that it is the
correct one and the user must check the hash, of course the code could
lie then you should better embed the check in a bookmarklet, the page
can't lie, and of course I could be a thief then others should check
the code and seed the hash somewhere, even if clearly explained that the
code must be used off line it's not difficult to invent different things
to steal the keys
Same principle applies with my NFT proposal (which can be real things,
so impossible to store in the blockchain): a third party allowing a
timestamp is used to prove that you are the seeder of the NFT (first
owner), minting can't be trusted and then becomes useless with the third
party, so you spare some bitcoin transactions
Using a third party does not mean that the blockchain is of no use,
again the blockchain will validate the life of the NFT and it remains
decentralized like lightning

2023-06-07 23:19:13

- reply

📅 Original date posted:2023-02-04
🗒️ Summary of this message: Proposal for NFT protection against theft and double minting. Third-party with timestamp and double hash not related to content, and secret NFT suggested.
📝 Original message:I still don't see in both proposals how you avoid that someone steals
your NFT, double mint it or sell it several time, because the thief can
do the very same that what your are describing, a hash of the content is
not enough, you can slightly modify an image or a document and it gives
another hash, as far as I know in all existing systems today there are
zero protection against this, I am quoting also Moxie's experience in my
proposals
That's why I am proposing the third party with a timestamp and a double
hash not related to the content itself, and the secret NFT, I don't see
the point to buy millions some electronic art that everyone can get for free
Anyway, I mostly consider that a NFT is a real good that you buy in the
metaverse, not only an electronic thing
Le 04/02/2023 à 11:38, Anthony Towns via bitcoin-dev a écrit :
> On Thu, Feb 02, 2023 at 10:39:21PM -0800, Casey Rodarmor via bitcoin-dev wrote:
>> Apologies for posting! I've tried to keep discussion of ordinals and
>> inscriptions off-list, because I consider it to be of little relevance to
>> general Bitcoin development.
> Anything that potentially uses up a large percentage of blockspace seems
> pretty relevant to general Bitcoin development to me...
>
>> AJ Towns writes:
>>> I think, however, that you can move inscriptions entirely off-chain. I
>>> wrote a little on this idea on twitter already [1], but after a bit more
>>> thought, I think pushing things even further off-chain would be plausible.
> I guess I should have explained why I think moving things off-chain is
> a worthwhile goal. Riffing off:
>
>> Another issue is salience and scarcity, as has been mentioned. Off-chain
>> content is unbounded, and thus less scarce. Usually, we design for
>> efficiency, volume, and scale. For NFT designs, which are intended to be
>> collectable, this is in some ways counterproductive.
> "scarce" has two meanings -- one is that there's not much of it, the
> other is that it's highly valued (or a third, where it's is consistently
> underpriced and unavailable even for people who'd pay more, but that
> hopefully doesn't apply).
>
> I think for bitcoin's blockspace, we ideally only want the first of
> these to be true. We want small blocks because that makes it cheap to
> verify bitcoin, which reduces the need to trust third parties and aids in
> decentralisation. But we don't want blockspace to be especially valuable,
> as that makes it expensive to use bitcoin, which then limits who can
> use it.
>
> Moving things off-chain helps with both these goals: it doesn't make it
> harder to validate bitcoin, and it also decreases demand for blockspace,
> making it cheaper for those cases where things can't be moved off-chain.
>
> As a result of this approach, bitcoin blockspace is currently quite
> cheap -- so inscribing at 100kB jpeg at 25kvB might cost perhaps $60 in
> a peak period, or $6 if you wait for 1sat/vb to confirm. Not exactly a
> luxury purchase.
>
> If you keep jpegs on-chain, as far as I can see, there's three outcomes:
>
> * blockspace stays relatively cheap, and there's no "scarcity" benefit to
> minting via on-chain inscriptions; it's cheap enough to just mint
> any random meme, and there's no prestige to doing so
>
> * blockspace becomes filled with jpegs, driving up costs for everyone,
> making jpeg collectors happy, but transactors sad
>
> * the amount of blockspace is increased, keeping prices low, and
> reducing "scarcity" in both senses, so also making it harder to
> validate bitcoin. no one really wins.
>
> I'd guess the first of these is the most likely, personally.
>
> As far as salience/notability goes, personally, I'd see ownership of
> inscriptions as a negative indicator; "hey, when I was young and foolish I
> wasted x-thousand bytes on the bitcoin blockchain, pointlessly creating a
> permanent cost for everyone trying to use bitcoin in future". That's not
> unforgivable; people do all sorts of foolish things, and bitcoin's meant
> to survive attacks, not just foolish pranks. But it doesn't seem like
> something to brag about or encourage, either, at least if you want bitcoin
> to be a monetary network that's usable in practice by many/most people.
>
> (Even if one day that goes the other way, and there is real (and
> transferable) social value in being able to say "I donated x sats to fees
> to help secure bitcoin", such a claim is more charitable/admirable/value
> with a smaller on-chain footprint, both in that it again keeps
> validation easier, but also in that it makes it easier for others to
> also simultaneously make the same charitable contribution)
>
>> NFT collectors have a strong revealed preference for on-chain content. The
>> content of high-value NFTs is often stored partially or completely on
>> chain,
> When you identify an NFT by a url that points at someone else's server,
> that's an obvious vulnerability, as Moxie demonstrated pretty well.
>
> But solving that by saying "okay, we'll just externalise the storage
> costs to the public, while privatising all the benefits" isn't a good
> approach either.
>
>> User protection when off-chain content is involved is fraught.
> I mean, that seems trivially solvable? Users already have to store the
> private key that controls ownership of these digital assets; storing the
> asset as well, which doesn't need to be private, isn't a big ask. And if
> a public site like ordinals.net is willing to store all the inscriptions
> that might be on the blockchain, they could just as easily store the
> same amount of off-chain digital assets.
>
>> When a user buys an NFT with
>> off-chain content, they now have the primary economic incentive to preserve
>> that content, so that their NFT retains value and can be enjoyed or sold.
> Yes -- the people who potentially benefit from the NFT should be the
> ones paying the costs of preserving that NFT.
>
>> Many existing NFT marketplaces that sell off-chain content do not explain
>> this to users, or give users tools that the average, non-technical person
>> can understand or use, which enables them to protect themselves. Even if
>> they did give users these tools, there are tricky considerations involved.
>> IPFS functions much like BitTorrent,
> Externalising the costs to some different network while privatising the
> benefits isn't any better than doing it to bitcoin; except in that maybe
> you're inconveniencing fewer people.
>
> Going back to this:
>
>> Another issue is salience and scarcity, as has been mentioned. Off-chain
>> content is unbounded, and thus less scarce. Usually, we design for
>> efficiency, volume, and scale. For NFT designs, which are intended to be
>> collectable, this is in some ways counterproductive.
> Obviously blockchains aren't the only "scarce" good out there. If scarcity
> is your goal, there's two very easy ways to make your own scarcity.
>
> One is requiring proof of work -- you could have a digital
> asset marketplace that only allows works that have a hash with
> at least 32 leading zero-bits [0] and use timestamping [1] (or a
> certificate-transparency approach) to ensure that as proof-of-work
> techonology improves, it can't be used to backdate mints.
>
> [0] https://github.com/nostr-protocol/nips/blob/master/13.md
> [1] https://github.com/nostr-protocol/nips/blob/master/03.md
>
> Or the other approach is you just require people to pay you some sats
> over lightning to host an NFT. That way you're the one collecting the
> fees, not miners; and you're (perhaps) the one incurring an obligation
> to preserve the NFT on behalf of its owners, rather than random bitcoin
> node operators.
>
>> The above issues also make the specification and implementation of NFTs
>> with off-chain content much more difficult.
> I'm not meaning to criticise you for doing what you think's interesting,
> so if it's coming off that way I apologise in advance. I think it's
> interesting, too. I just think that, when possible, off-chain is always
> better than on-chain, and it's worth exploring that idea further.
>
> In particular, I don't think it *is* actually much more difficult? Here's
> how I'd change what you've done to turn ordinals.net into an off-chain
> digital asset site:
>
> - setup a nostr relay, with submissions gated by proof of work, and
> no expiry. maybe https://github.com/Cameri/nostream ?
>
> - for any event that includes an "ordinal" tag, treat it as a digital
> asset, and add it to your digital asset database, just like you do now
> for inscriptions. either have your own nostr client that subscribes
> to your relay, or just query your relay's db directly.
>
> - have a regular proof of work adjustment targeting say 200MB worth of
> events per day (vs the 576MB per day of possible witness data).
>
> - update the ord tool to be able to encode digital artifacts into a nostr
> event, apply proof of work to it, and send it to (by default)
> your relay.
>
> That would let nostr clients immediately just add your relay and get a
> feed of minted digital artifacts, that's already spam-free due to the
> proof of work requirement. They could follow all of them, or just follow
> a particular artist by pubkey, too. An artist could publish a collection
> by publishing an event defining the collection, then linking each artwork
> to the collection as a "reply", making it pretty easy for nostr clients
> to follow a collection, while still having each artwork linked to its
> own ordinal, and I think without requiring any work on your behalf.
>
> You don't need to change the way ordinals are spent at all for any of
> this, I think; all you're doing is replacing the initial two transactions
> that link the digital artifact with the ordinal with an off-chain message
> achieving the same thing.
>
> Then to go beyond what you've got you could:
>
> - add some support for the current owner of an ordinal to link that
> back to their nostr profile -- eg, sign a message with the pubkey
> based on the current utxo holding the ordinal, referencing the digial
> asset; you could perhaps use NIP-2 "following" messages for this.
> if you've already using an open social network, might as well take
> advantage of it.
>
> - add some support for the "social legitimacy" aspect -- eg linking
> all the assets created by the same public key as an artist's portfolio;
> make it easy to go from their nft-related pubkey to their regular
> nostr profile or similar.
>
> - let creators that have already somehow demonstrated "social legitimacy"
> bypass the proof of work requirement, since "great art" is already
> naturally scarce. creators who've demonstrated their quality shouldn't
> need to waste time or money doing proof of work or paying blockchain
> fees
>
> Adding a lightning based patreon-type setup could be awesome there --
> content creators post content to a closed relay, patrons pay a fee
> over lightning to be able to receive events, and 90%+ of those fees
> are passed on to creators. If creators are happy with subscriptions,
> they just do that; if they want to auction off NFTs, they can do that;
> if they want both, that works too...
>
>> Additionally, I think the term "inscription" which has a connotation of
>> permanence, and of an indelible association with a particular satoshi, is
>> inappropriate for an off-chain NFT protocol.
> No objections about the "inscription" definition, but I'm not sure if the
> above means you're misunderstanding what I'm saying. In the off-chain
> scheme I'm talking about, the "digital asset" includes the ordinal
> that controls ownership, and is identified by the hash of its contents,
> including that ordinal's identity -- so there is an indelible association
> with a particular satoshi, despite it being an off-chain NFT protocol.
>
> For example if you take two identical digital assets, such as:
>
> https://ordinals.net/inscription/8ed2594cecbd43e5673168ff160ba00a6d8953fea7ab6b15a112f3bc94adc2f8i0
>
> https://ordinals.net/inscription/31e9577f9af1d1823bc00539291f061e4ac9ba727162a8e0d8d7b80512966561i0
>
> then in the off-chain world, they would look like two events:
>
> {
> pubkey: <Alice>
> kind: 0
> tags: [
> ord: "8ed2594cecbd43e5673168ff160ba00a6d8953fea7ab6b15a112f3bc94adc2f8:0:0"
> ]
> content: <av1.jpeg>
> id: <XXXX - hash of the above>
> sig: <sig by alice of XXXX>
> }
>
> and
>
> {
> pubkey: <Alice>
> kind: 0
> tags: [
> ord: "31e9577f9af1d1823bc00539291f061e4ac9ba727162a8e0d8d7b80512966561:0:0"
> ]
> content: <av1.jpeg>
> id: <YYYY = hash of the above>
> sig: <sig by alice of YYYY>
> }
>
> ie two unique digital assets, with two unique identifiers (XXXX and YYYY)
> that are each indelibly linked with particular satoshis.
>
> Obviously there's nothing stopping Alice minting the exact same content
> to two different ordinals -- presumably that's what happened with
> the two inscriptions above -- nor is there anything stopping Bob from
> right-click-save-as and doing the same; but as above, that's obviously
> true for inscriptions as well. The only truly unique thing is the specific
> hash and the specific content that generated the hash.
>
> The relationship does go the other way compared to inscriptions --
> here you keep the association so long as you remember the asset; with
> inscriptions you keep the association so long as you have bitcoin's
> historical blocks. As I've said above, the off-chain approach seems
> much better aligned with incentives to me, with the people who gain the
> benefit from that association paying the cost of preserving it.
>
> Cheers,
> aj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Sophia-Antipolis, France
CV: https://www.peersm.com/CVAV.pdf
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
GitHub : https://www.github.com/Ayms
A Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7
A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com
Peersm : http://www.peersm.com

2023-06-07 23:19:11

- reply

📅 Original date posted:2023-02-02
🗒️ Summary of this message: The author proposes a simpler approach to storing NFTs on Bitcoin, using third-party services like Wayback Machine or Github, and suggests increasing the OP_RETURN max size. They argue against off-chain storage due to lack of control and reliability.
📝 Original message:I am not an expert with RGB, but it looks limited (only bitcoin chains
from the github repo, apparently on hold), distributed over the
"lightning network" or LN nodes (what is it?), or Bifrost extension,
with a dubious token floating around, like ethereum mess as RGB docs
describe Ethereum (and myself also), layer2 or layer3, certainly not
decentralized (like still Bitcoin and Ethereum)
It's of course useless to trust IPFS or Bittorrent to store things
because you cannot control the seeders who have zero incentive to seed
such things
That's why in my much more simple proposals a well known third party is
there, wayback machine, github, twitter, etc, if they disappear then
probably internet has disappeared too, if they get censored you can
still get a snapshot of what you did
The intent is certainly not to store NFTs in Bitcoin, only hashes,
signatures and addresses, same for the third party proof, the NFT
content if not real is stored elsewhere (up to people to decide where)
Additionally you can store in the third party the proof that something
exists (the secret NFT), for example a small copy of the NFT electronic
art, the buyer will get the full version once the deal is done and once
he gets the decryption key, having the NFT for himself only
My proposals are not addressing wider D-stuff topics, supposedly
decentralized, but no
So I don't think that it's a waste of time to change the OP_RETURN max
size, currently it cannot even store <short message and/or hash> +
<signature>, probably it's logical to align it to the script size limit
(520B)
Or as I said previously deviant practices can happen, not expensive and
just burning satoshis, which is not a super idea
I don't get why on bitcoin all proposals must always be super
complicate, mine are simple, then take 5mn to read them
Le 02/02/2023 à 15:30, Peter Todd via bitcoin-dev a écrit :
> On Thu, Feb 02, 2023 at 07:15:33PM +1000, Anthony Towns via bitcoin-dev wrote:
>> Hi *,
>>
>> Casey Rodarmor's ordinals use the technique of tracking the identity of
>> individual satoshis throughout their lifetime:
> <snip>
>
>> I think, however, that you can move inscriptions entirely off-chain. I
>> wrote a little on this idea on twitter already [1], but after a bit more
>> thought, I think pushing things even further off-chain would be plausible.
> On the FAQ of the Ordinals website they discuss off-chain data storage and
> reject the idea:
>
> "Some Ethereum NFT content is on-chain, but much is off-chain, and is stored on
> platforms like IPFS or Arweave, or on traditional, fully centralized web
> servers. Content on IPFS is not guaranteed to continue to be available, and
> some NFT content stored on IPFS has already been lost. Platforms like Arweave
> rely on weak economic assumptions, and will likely fail catastrophically when
> these economic assumptions are no longer met. Centralized web servers may
> disappear at any time."
> https://web.archive.org/web/20230130012343/https://docs.ordinals.com/faq.html
>
> That same FAQ also mention RGB and Taro, which already implements an off-chain
> data model based on my Proofmarshal work. The Ordinals community is well aware
> of the trade-offs and have chosen to publish their data on chain. This is a
> collectables market based on artificial scarcity after all, so some conspicuous
> consumption isn't going to be a deterrent.
>
> Frankly, I think further discussion of this on the bitcoin-dev mailing list,
> with the aim of getting Ordinals and others to do something else, is a waste of
> everyones' time. The fact that publishing data on chain lets you take
> advantage of the very large network of archival Bitcoin nodes to publish and
> store your data indefinitely is a clear benefit that people will always be
> willing to pay for. The only realistic thing Bitcoin can do to discourage this
> is tweaks to the blocksize and segwit discount, which of course has well-known
> downsides.
>
> There's a clear social/economic benefit to the Ordinals community that the
> complete set of Ordinalds - and their inscriptions - is easy to extract and
> will be available as long as Bitcoin block data itself will be available.
> That's not going away and we should acknowledge that benefit honestly.
>
>> Implementing that is fairly straightforward: you just need a protocol
>> for creating an asset offchain and associating it with an ordinal --
>> nothing needs to happen on-chain at all. That is, you can do something
>> as simple as posting a single nostr message:
>>
>> {
>> "pubkey": <creator's pubkey>
>> "kind": 0,
>> "tags": [
>> ["ord", "txid:vout:sat"]
>> ],
>> "content": [jpeg goes here],
>> "id": <hash of the above>
>> "sig": <signature of id by creator's pubkey>
>> }
> nostr doesn't even have a clear data persistence model. As you know, nostr
> messages are passed around by relays that make no enforceable promise of
> actually keeping those messages or making them available. nostr doesn't have
> any kind of blockchain, making it diffcult for others to archive messages
> completely. Advocating for its use in a protocol designed to support valuable
> collectables expected to be owned for a significant amount of time is reckless.
>
> You know, we've been through all this before, years ago when colored coins were
> first being discussed. Bitcoin Core devs who knew better would try to
> discourage use of the Bitcoin chain for purposes they didn't approve of, by
> suggesting solutions that they knew full well didn't really work. Solutions
> like using OpenTimestamps inappropriately, alternative publication methods that
> failed to provide the same level of security as Bitcoin, etc. It was dishonest
> then, and it's disappointing to see a new generation of Bitcoin devs continue
> this pattern of dishonesty.
>
>> You can prove current ownership of the message by showing a custody
>> chain, that is the transaction specified by "txid" in the "ord" tag,
>> then every transaction that spent the given sat, until you get to one
>> that's still in the utxo set [3]. You don't need to provide witness
>> data or validate any of these tx's signatures, as that is already
>> implicit in that you end up at a tx in the utxo set. Just calculating
>> the txids and comparing against the output containing the sat you're
>> interested in is sufficient.
> The RGB protocol already does off-chain custody proofs, and implements NFTs.
> You can already use this for real with Iris Wallet - the ownership chain of a
> RGB asset is _not_ visible on the blockchain, as ownership does not follow
> satoshis. With more work, digital assets can even be transferred with
> O(log_2(n)) scaling allowing billions of transfers per second:
>
> https://petertodd.org/2017/scalable-single-use-seal-asset-transfer
>
> This of course is irrelevant to Ordinals, which will never have such a large
> market.
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Sophia-Antipolis, France
CV: https://www.peersm.com/CVAV.pdf
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
GitHub : https://www.github.com/Ayms
A Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7
A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com
Peersm : http://www.peersm.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230202/bab6d696/attachment.html>

2023-06-07 23:19:08

- reply

📅 Original date posted:2023-02-02
🗒️ Summary of this message: The proposed Bitcoin NFT system uses a double hash mechanism to prevent theft and counterfeiting, with a trusted third party for timestamping. A Universal Coin Swap system is also proposed.
📝 Original message:In your system what is the off-chain mechanism? And what prevent a thief
to steal your NFT?
I have submitted several time "A Bitcoin NFT system"
https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
It's more simple, the NFT (whether real or electronic) is referenced by
a initial hash (which is not the hash for example of your jpeg file
because easy to fake) and then get a final reference which is the hash
of the initial hash
The idea is that the real owner must prove that he has the knowledge of
the initial hash (for example luxury bag, you print the double hash on
it, and give the initial hash to the buyer, if the owner/seller can't
prove that he knows the inital hash, the bag is stolen or counterfeit
(with the double hash))
The NFT owner references the NFT signed by him in some trusted third
party allowing a timestanp (wayback machine for example), it proves that
he is the first one to have the knowledge of the double hash, so a thief
cannot intercept the "minting" transaction (if any because not really
necessary since the public key of the owner is known from the third
party) and steal the NFT for himself or do/replay a transaction with
this NFT, minting it or selling it several time
A third party is involved but it remains decentralized
Then the NFT owner and buyer exchange some information like for
lightning and do one transaction on Bitcoin storing the deal, see the
details in the proposals depending on what kind of deal occur between
the buyer and the seller, like lightning, if someone cheats, then he
loses his bitcoin
It's minimal, understandable, secured, decentralized and not expensive,
that's why I don't see very well why to complicate with ordinals
The proposal envisions the concept of "secret" NFTs also
The continuation of this proposal is "A Universal Coin Swap system based
on Bitcoin" https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7
It's simple also, you go from Decentraland to the Sandbox but don't have
SAND and want to pay with MANA, you agree on a MANA/SAND deal with the
seller which is stored in Bitcoin signed by both, then you pay with
MANA, other use cases are described in the proposal
Note: both proposals need to be modified since I thought OP_RETURN max
size was 512B and it is in fact 80B, which does not work for all cases
Le 02/02/2023 à 10:15, Anthony Towns via bitcoin-dev a écrit :
> Hi *,
>
> Casey Rodarmor's ordinals use the technique of tracking the identity of
> individual satoshis throughout their lifetime:
>
> On Tue, Feb 22, 2022 at 04:43:52PM -0800, Casey Rodarmor via bitcoin-dev wrote:
>> Briefly, newly mined satoshis are sequentially numbered in the order in
>> which they are mined. These numbers are called "ordinal numbers" or
>> "ordinals". When satoshis are spent in a transaction, the input satoshi
>> ordinal numbers are assigned to output satoshis using a simple
>> first-in-first-out algorithm.
> This is proposed as a BIP at https://github.com/bitcoin/bips/pull/1408
>
> When accompanied by a standard for associating some data or right with
> such an identity, this allows the creation of non-fungible tokens (or
> semi-fungible tokens) whose ownership can be transferred by a bitcoin
> transaction.
>
> The proposed BIP doesn't document any method for associating data or a
> right with an ordinal, but the "ord" tool defines "inscriptions" to fill
> this gap [0], providing a way of including mime-encoded data in a taproot
> witness. To make such an inscription, two transactions are required:
> one paying some sats to a special scriptPubKey that commits to the
> inscribed data, and a second that spends those sats to the owner of the
> newly inscribed ordinal, and in so doing revealing the full inscription.
>
> [0] https://docs.ordinals.com/inscriptions.html
>
> I think, however, that you can move inscriptions entirely off-chain. I
> wrote a little on this idea on twitter already [1], but after a bit more
> thought, I think pushing things even further off-chain would be plausible.
>
> [1] https://twitter.com/ajtowns/status/1619554871166013441
>
> In particular, rather than looking at it as being the owner of the sats
> that inscribes some content on those sats (analogously to signing a $100
> bill [2]), you could look at it as saying "the owner of this thing is
> whoever owns this particular sat" (eg instead of "whoever owns this
> share certificate is a shareholder", it's "whoever owns the $1 bill with
> serial number X is a shareholder").
>
> [2] https://www.espn.com/nfl/story/_/id/14375536/owner-100-bill-autograph-cleveland-browns-qb-johnny-manziel-getting-offers
>
> Implementing that is fairly straightforward: you just need a protocol
> for creating an asset offchain and associating it with an ordinal --
> nothing needs to happen on-chain at all. That is, you can do something
> as simple as posting a single nostr message:
>
> {
> "pubkey": <creator's pubkey>
> "kind": 0,
> "tags": [
> ["ord", "txid:vout:sat"]
> ],
> "content": [jpeg goes here],
> "id": <hash of the above>
> "sig": <signature of id by creator's pubkey>
> }
>
> You can prove current ownership of the message by showing a custody
> chain, that is the transaction specified by "txid" in the "ord" tag,
> then every transaction that spent the given sat, until you get to one
> that's still in the utxo set [3]. You don't need to provide witness
> data or validate any of these tx's signatures, as that is already
> implicit in that you end up at a tx in the utxo set. Just calculating
> the txids and comparing against the output containing the sat you're
> interested in is sufficient.
>
> [3] If the satoshi was lost to fees at some point, you could continue to
> follow ownership by including an entire block in the custody chain.
> But seems better to just consider it as "abandoned" or "lost to the
> public domain" at that point.
>
> This approach allows all the "inscription" data to be entirely off-chain,
> the only thing that requires a transaction on-chain is transferring
> ownership to someone else. That allows the NFT's existance can be kept
> entirely private if desired; it also makes it cheap to create a new NFT
> (you don't need to pay any on-chain fees at all); and it doesn't impose
> an outsized overhead on people who aren't interested in your inscriptions,
> but may be interested either in bitcoin per se, or in other inscriptions.
>
> For things that have real intrinsic value -- equity rights in a company,
> bragging rights for supporting an artist, etc -- this seems like it's
> probably a viable approach: owners can "self-custody" all the information
> about the things they own without having to rely on third parties,
> transfers are no more censorable than any other bitcoin transaction
> (especially if the association of the NFT with some particular sat is
> not widely known), etc.
>
> The "inscription" approach might still be desirable for broadcasting
> information that might otherwise be subject to heavy censorship; presuming
> that the censoring entity isn't also willing and able to censor bitcoin
> itself. It's not clear that there's any "rights" to be owned for such a
> case -- you can't buy the right to be the person that first published
> it, and the point of widely broadcasting the information is so it's
> not a secret only known to a few anymore. Also, claiming ownership of
> such information would presumably make you a target for the censor,
> even if just as an example for others. So I'm dubious of the value of
> associating an inscription with an ordinal for that use case.
>
> It's also possible that the perceived value of the NFT isn't due to
> the inscription, but rather due to the scarcity of the blockspace it
> was inscribed in (eg [4]). This is different from Bitcoin's scarcity
> -- by 2100 or so there'll be a total of 2100T satoshis available,
> but in that same time there will only have been about 4T vbytes of
> blockspace available, and perhaps it could make sense to value spent
> vbytes proportionally, so 4 spent vbytes is worth 2100 sats. In that
> case if you spent 50kvb inscribing a jpeg, perhaps the "rights" to that
> jpeg should be worth the same as 50k/4*2100 sats or 0.26 BTC. Doesn't
> seem like a sound argument to me -- there's always more blockspace being
> created, by fewer and fewer sats being created, and ordinals are far more
> awkward to deal with, but I suppose it's still conceivable, and people
> at least claim to believe it. If it were true, this argument suggests
> the price for blockspace today should be around 2488sat/vB (19.28MBTC /
> 774700 MvB), rather than 1sat/vB.
>
> [4] https://twitter.com/vnprc/status/1619876888687820801
>
> Anyway, comparisons to ordinal inscriptions aside, I think there's
> another interesting point from all this.
>
> Presume you have a tool that implements the nostr ordinal assignment
> suggested above: that is, a small modification of the "ord" tool that
> can track a chain of custody for an ordinal specified in a nostr event
> like the above. That allows you to do NFTs completely unobservably --
> you don't have to publish anything to the blockchain apart from ordinary
> looking transactions to transfer ownership of your NFT. To your benefit,
> that makes it hard for anyone to censor you; but to bitcoin more broadly,
> I think it means that the possibility of coloured bitcoins is largely
> unavoidable and simply something that must be dealt with, rather than
> something we should spend time trying to prevent/avoid. Compare with:
>
>> My personal, and possibly controversial, opinion is that colored coin
>> protocols have no business being on the Bitcoin chain, possibly beyond
>> committing to an occasional batched state update or so. Both because
>> there is little benefit for tokens with a trusted issuer already, and
>> because it competes with using Bitcoin for BTC - the token that pays
>> for its security (at least as long as the subsidy doesn't run out).
>>
>> Of course, personal opinions are no reason to dictate what people should
>> or can use the chain for, but I do think it's reason to voice hesitancy
>> to worsening the system's scalability properties only to benefit what
>> I consider misguided use.
> -- https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019500.html
>
> I don't think this actually results in majorly misaligned incentives
> though: in the nostr-nfts-on-btc world, everyone is still optimising
> bitcoin transactions for the same thing -- transfer of value. It's just
> that in some cases some sats are valued differently than others --
> perhaps my uninscribed sats are worth 0.025 cents each, but you have
> a particular inscribed sat that's worth $100k. But we're both dealing
> just spending utxos and creating new utxos, doing signatures and maybe
> some timelocks or hash reveals. And it's always been possible that
> your transaction transferring $100k won't get charged higher fees than
> my transfer of $50 -- we care about transaction size, not value after
> all. How much does it matter if your tx matters more to your because
> someone wants your particular sat, rather than what could happen today
> where you have a utxo with 4 BTC while my utxo only has 0.002 BTC?
>
> I think the only way to prevent that sort of NFT structure would be
> to have every transaction use fancy zero-knowledge proofs that make it
> impossible to associate who received bitcoin with who spent it -- *even
> if* both the sender and recipient were willing to cooperate to reveal
> that information. I think it would be hard to achieve that while still
> making it easy to audit bitcoin's total supply, but I might be wrong.
>
> Note that off-chain colouring here means that someone can create an NFT
> that you don't want it, and just assign it to a sat that's already in your
> wallet. However, they can do this anyway, by first creating the NFT, then
> sending it to your wallet address. A difference though is that they could
> create an NFT and assign it to the same ordinal/sat as some existing NFT
> that you do value, at which point it's (presumably) impossible to discard
> one without discarding both. But again, this is simply something they
> can do, just be writing a patch to ord and composing a nostr message;
> it's not something you can actually prevent even if you dislike it.
>
> Particularly for semi-fungible tokens, this is perhaps inferior to
> Liquid's multi-asset model -- here if you have a utxo with 1M sats, 500
> of which are inscribed to each represent rights to $1 worth of USDT,
> then rather than acting like a stable coin and being worth $500; it's
> actually worth $500+0.01BTC, which is more like $750, and changes as
> the value of bitcoin changes.
>
> Cheers,
> aj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Sophia-Antipolis, France
CV: https://www.peersm.com/CVAV.pdf
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
GitHub : https://www.github.com/Ayms
A Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7
A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com
Peersm : http://www.peersm.com

2023-06-07 23:19:05

- reply

📅 Original date posted:2023-02-18
🗒️ Summary of this message: Datacarrier allows for storing data in taproot annex with one transaction, potentially replacing OP_RETURN. Implementation timeline is unclear.
📝 Original message:So with datacarrier we can store data in taproot annex with one tx which
will be data and/or extension of the script validation via PUSH_ANNEX
I looked at your links and plenty of others, but had some hard time to
find the proposal
(https://github.com/bitcoin/bips/blob/9dc3f74b384f143b7f1bdad30dc0fe2529c8e63f/bip-annex.mediawiki
I suppose), when do you think datacarrier can happen for real on the
network?
Now I think the OP_RETURN debate remains relevant, it's a quite trivial
modification to do, from my standpoint it is certainly not intended to
store big things (but 80B, what do you want to do with this?), but if
people want to store big things and pay for it... what is the real
issue? (I saw your argument of "partial" block validation and others
like skipping witness data, at the end nodes must validate the whole thing)
Le 17/02/2023 à 13:49, Anthony Towns a écrit :
> On Sat, Feb 04, 2023 at 07:11:35PM -0500, Russell O'Connor via bitcoin-dev wrote:
>> Since bytes in the witness are cheaper than bytes in the script pubkey,
>> there is a crossover point in data size where it will simply be cheaper to
>> use witness data.
> Given today's standardness constraints, that's true (because you first
> need to construct a p2wsh/tapscript output that commits to the data,
> then you have to spend it), but it needn't stay that way. Allowing a data
> carrier entry in the annex (as contemplated for eltoo [0]) would allow
> you to publish the data with a single transaction, with malleability
> prevented because the annex content is committed to by the signature.
>
> [0] https://github.com/bitcoin-inquisition/bitcoin/pull/22
>
> I think the cost for publishing data via the witness today is roughly:
>
> 115 vb - for the commitment tx
> 115 vb + datalen/4 - for the publication tx
>
> versus
>
> 125 vb + datalen - for a tx with an OP_RETURN output
>
> so the crossover point is at a datalen of about 140 bytes. Perhaps
> slightly more or less depending on how much you can combine these
> inputs/outputs with other txs you would have made anyway.
>
> With a datacarrier in the annex that has similar or higher limits than
> OP_RETURN, I don't think OP_RETURN would ever be cheaper.
>
> The other advantage to using the witness for random data compared to
> OP_RETURN is that the txid commits to OP_RETURN output, so you must
> download all OP_RETURN data to validate a block's merkle tree, whereas
> you can partially validate a block (in particular, you can validate the
> spendable utxo set) without downloading witness data [1].
>
> [1] https://github.com/bitcoin/bitcoin/pull/27050
>
> Cheers,
> aj
--
Sophia-Antipolis, France
CV: https://www.peersm.com/CVAV.pdf
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
GitHub : https://www.github.com/Ayms
A Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7
A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com
Peersm : http://www.peersm.com

2023-06-07 23:19:04

- reply

📅 Original date posted:2023-02-17
🗒️ Summary of this message: Aymeric is unsure about a proposed solution to require all data in the op_return output and add a required op_return_hash field.
📝 Original message:Hi Claus,
Thanks but I am not sure to understand the solution, how the transaction
will look like and will it be standard ?
Regards
Aymeric
Le 16/02/2023 à 20:59, Claus Ehrenberg a écrit :
> I propose to require all data to be in the op_return output PLUS add a
> required op_return_hash field, which is checked by consensus. So that
> node can re-validate the chain without having to store/download/look
> at the contents of op_return data. The benefit of that little
> redundancy is that "content-sensitive" communities can ignore the date
> they don't like.
>
> Cheers
> Claus
>
> On Thu, Feb 16, 2023 at 7:30 PM Aymeric Vitte via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> It's super unclear how long it could take for such a change to be
> adopted
>
> Then the answer is simple, see:
> https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7#workaround-to-the-80b-op_return-limitation
>
> Outstandingly, very, mega, bad, but working, bringing bitcoin back
> 10 years ago
>
> But why not? If bitcoin folks don't get that we need a 1tx storage
> solution for the future, then let's bring back bitcoin into the
> past and destroy coins
>
> Le 12/02/2023 à 17:23, Aymeric Vitte a écrit :
>>
>> https://github.com/bitcoin/bitcoin/issues/27043#issuecomment-1427069403
>>
>> "What is the process to have someone do the PR for this? Or I do
>> it and most likely it will be a very shxtty one since I am not a
>> C/C++ expert, then wasting the time of everybody
>>
>> It's urgently required, I did consider OP_RETURN as a dart in the
>> past but changed my mind, it's adapted to the current evolutions,
>> not flooding bitcoin with 2 txs while only 1 is needed
>>
>> If not the best 1 tx solution is super simple: store in
>> addresses, and super bad at the end because burning bitcoins,
>> while still not expensive if you don't need to store big things"
>>
>>
>> Le 05/02/2023 à 19:12, Russell O'Connor via bitcoin-dev a écrit :
>>>
>>>
>>> On Sat., Feb. 4, 2023, 21:01 Peter Todd, <pete at petertodd.org
>>> <mailto:pete at petertodd.org>> wrote:
>>>
>>>
>>>
>>> On February 5, 2023 1:11:35 AM GMT+01:00, Russell O'Connor
>>> via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org
>>> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>>> >Since bytes in the witness are cheaper than bytes in the
>>> script pubkey,
>>> >there is a crossover point in data size where it will
>>> simply be cheaper to
>>> >use witness data. Where that crossover point is depends on
>>> the finer
>>> >details of the overhead of the two methods, but you could
>>> make some
>>> >reasonable assumptions. Such a calculation could form the
>>> basis of a
>>> >reasonable OP_RETURN proposal. I don't know if it would be
>>> persuasive, but
>>> >it would at least be coherent.
>>>
>>> I don't think it's worth the technical complexity trying to
>>> carefully argue a specific limit. Let users decide for
>>> themselves how they want to use OpReturn.
>>>
>>>
>>> Even better.
>>>
>>>
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> <mailto:bitcoin-dev at lists.linuxfoundation.org>
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>> --
>> Sophia-Antipolis, France
>> CV: https://www.peersm.com/CVAV.pdf
>> LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
>> GitHub : https://www.github.com/Ayms
>> A Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7
>> A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
>> Move your coins by yourself (browser version): https://peersm.com/wallet
>> Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
>> torrent-live: https://github.com/Ayms/torrent-live
>> node-Tor : https://www.github.com/Ayms/node-Tor
>> Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com
>> Peersm : http://www.peersm.com
>
> --
> Sophia-Antipolis, France
> CV: https://www.peersm.com/CVAV.pdf
> LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
> GitHub : https://www.github.com/Ayms
> A Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7
> A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
> Move your coins by yourself (browser version): https://peersm.com/wallet
> Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
> torrent-live: https://github.com/Ayms/torrent-live
> node-Tor : https://www.github.com/Ayms/node-Tor
> Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com
> Peersm : http://www.peersm.com
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
Sophia-Antipolis, France
CV: https://www.peersm.com/CVAV.pdf
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
GitHub : https://www.github.com/Ayms
A Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7
A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com
Peersm : http://www.peersm.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230217/e26f5760/attachment-0001.html>

2023-06-07 23:19:03

- reply

📅 Original date posted:2023-02-16
🗒️ Summary of this message: A workaround to the 80-byte OP_RETURN limitation in Bitcoin has been proposed, but it is unclear how long it will take to be adopted.
📝 Original message:It's super unclear how long it could take for such a change to be adopted
Then the answer is simple, see:
https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7#workaround-to-the-80b-op_return-limitation
Outstandingly, very, mega, bad, but working, bringing bitcoin back 10
years ago
But why not? If bitcoin folks don't get that we need a 1tx storage
solution for the future, then let's bring back bitcoin into the past and
destroy coins
Le 12/02/2023 à 17:23, Aymeric Vitte a écrit :
>
> https://github.com/bitcoin/bitcoin/issues/27043#issuecomment-1427069403
>
> "What is the process to have someone do the PR for this? Or I do it
> and most likely it will be a very shxtty one since I am not a C/C++
> expert, then wasting the time of everybody
>
> It's urgently required, I did consider OP_RETURN as a dart in the past
> but changed my mind, it's adapted to the current evolutions, not
> flooding bitcoin with 2 txs while only 1 is needed
>
> If not the best 1 tx solution is super simple: store in addresses, and
> super bad at the end because burning bitcoins, while still not
> expensive if you don't need to store big things"
>
>
> Le 05/02/2023 à 19:12, Russell O'Connor via bitcoin-dev a écrit :
>>
>>
>> On Sat., Feb. 4, 2023, 21:01 Peter Todd, <pete at petertodd.org
>> <mailto:pete at petertodd.org>> wrote:
>>
>>
>>
>> On February 5, 2023 1:11:35 AM GMT+01:00, Russell O'Connor via
>> bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org
>> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>> >Since bytes in the witness are cheaper than bytes in the script
>> pubkey,
>> >there is a crossover point in data size where it will simply be
>> cheaper to
>> >use witness data. Where that crossover point is depends on the
>> finer
>> >details of the overhead of the two methods, but you could make some
>> >reasonable assumptions. Such a calculation could form the basis
>> of a
>> >reasonable OP_RETURN proposal. I don't know if it would be
>> persuasive, but
>> >it would at least be coherent.
>>
>> I don't think it's worth the technical complexity trying to
>> carefully argue a specific limit. Let users decide for themselves
>> how they want to use OpReturn.
>>
>>
>> Even better.
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> --
> Sophia-Antipolis, France
> CV: https://www.peersm.com/CVAV.pdf
> LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
> GitHub : https://www.github.com/Ayms
> A Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7
> A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
> Move your coins by yourself (browser version): https://peersm.com/wallet
> Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
> torrent-live: https://github.com/Ayms/torrent-live
> node-Tor : https://www.github.com/Ayms/node-Tor
> Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com
> Peersm : http://www.peersm.com
--
Sophia-Antipolis, France
CV: https://www.peersm.com/CVAV.pdf
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
GitHub : https://www.github.com/Ayms
A Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7
A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com
Peersm : http://www.peersm.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230216/59e07bc2/attachment-0001.html>

2023-06-07 23:19:02

- reply

📅 Original date posted:2023-02-12
🗒️ Summary of this message: The discussion revolves around the use of OP_RETURN and the potential benefits of using witness data instead of script pubkey. The technical complexity of arguing a specific limit is debated.
📝 Original message:https://github.com/bitcoin/bitcoin/issues/27043#issuecomment-1427069403
"What is the process to have someone do the PR for this? Or I do it and
most likely it will be a very shxtty one since I am not a C/C++ expert,
then wasting the time of everybody
It's urgently required, I did consider OP_RETURN as a dart in the past
but changed my mind, it's adapted to the current evolutions, not
flooding bitcoin with 2 txs while only 1 is needed
If not the best 1 tx solution is super simple: store in addresses, and
super bad at the end because burning bitcoins, while still not expensive
if you don't need to store big things"
Le 05/02/2023 à 19:12, Russell O'Connor via bitcoin-dev a écrit :
>
>
> On Sat., Feb. 4, 2023, 21:01 Peter Todd, <pete at petertodd.org
> <mailto:pete at petertodd.org>> wrote:
>
>
>
> On February 5, 2023 1:11:35 AM GMT+01:00, Russell O'Connor via
> bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
> >Since bytes in the witness are cheaper than bytes in the script
> pubkey,
> >there is a crossover point in data size where it will simply be
> cheaper to
> >use witness data. Where that crossover point is depends on the finer
> >details of the overhead of the two methods, but you could make some
> >reasonable assumptions. Such a calculation could form the basis of a
> >reasonable OP_RETURN proposal. I don't know if it would be
> persuasive, but
> >it would at least be coherent.
>
> I don't think it's worth the technical complexity trying to
> carefully argue a specific limit. Let users decide for themselves
> how they want to use OpReturn.
>
>
> Even better.
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Sophia-Antipolis, France
CV: https://www.peersm.com/CVAV.pdf
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
GitHub : https://www.github.com/Ayms
A Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7
A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com
Peersm : http://www.peersm.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230212/715d4cbc/attachment.html>

2023-06-07 23:19:01

- reply

📅 Original date posted:2023-02-05
🗒️ Summary of this message: The debate is about the use of witness and OP_RETURN to store data in Bitcoin transactions, with suggestions to allow any number of OP_RETURN outputs and remove the size limit.
📝 Original message:I think logically:
- if you want to store something big and can afford several txs in your
design, then you use something like witness
- if you want to store small things like signatures, addresses hashes
and some metadata and your design does not make several txs easy, then
you use OP_RETURN
Then how can we move forward with several OP_RETURN and no size limit?
I can start posting a bug/enhancement proposal in bitcoin repo but can't
write the PR
Le 05/02/2023 à 01:04, Peter Todd a écrit :
>
> On February 5, 2023 12:09:02 AM GMT+01:00, Aymeric Vitte via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> I don't know, what number would you advise? When I made the
>> bitcoin-transactions nodejs module some years ago the limit (from the
>> specs) was 512B
> 1) Allowing only one OpReturn output causes problems trying to compose different uses of OpReturn. We should allow any number of OpReturn outputs.
>
> 2) There's no reason to put a size limit given all the other ways people can publish data, including with a 75% discount. Let the fee market deal with it.
--
Sophia-Antipolis, France
CV: https://www.peersm.com/CVAV.pdf
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
GitHub : https://www.github.com/Ayms
A Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7
A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com
Peersm : http://www.peersm.com

2023-06-07 23:19:01

- reply

📅 Original date posted:2023-02-05
🗒️ Summary of this message: The author suggests that since OP_RETURN has minimal impact, people should be allowed to decide how to use it without limits, similar to Taproot.
📝 Original message:Yes I agree, let people decide and since taproot has no limits then it
sould be the same for OP_RETURN
I posted https://github.com/bitcoin/bitcoin/issues/27043
Le 05/02/2023 à 13:06, Peter Todd a écrit :
>
> On February 5, 2023 12:40:38 PM GMT+01:00, Aymeric Vitte <aymeric at peersm.com> wrote:
>> I think logically:
>>
>> - if you want to store something big and can afford several txs in your
>> design, then you use something like witness
>>
>> - if you want to store small things like signatures, addresses hashes
>> and some metadata and your design does not make several txs easy, then
>> you use OP_RETURN
>>
>> Then how can we move forward with several OP_RETURN and no size limit?
> Because what matters is the impact on other users. OpReturn isn't in UTXO space and doesn't even take advantage of the witness discount, so it clearly has minimal impact.
>
> Since it has minimal impact, there's no reason to micromanage exactly how people use it. Let them decide for themselves with the fee market. This is exactly the same as how we didn't put artificial limits on Taproot.
--
Sophia-Antipolis, France
CV: https://www.peersm.com/CVAV.pdf
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
GitHub : https://www.github.com/Ayms
A Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7
A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com
Peersm : http://www.peersm.com

2023-06-07 23:19:00

- reply

📅 Original date posted:2023-02-04
🗒️ Summary of this message: A developer is seeking advice on what limit to set for a bitcoin-transactions nodejs module, with suggestions ranging from 512B to 520B.
📝 Original message:I don't know, what number would you advise? When I made the
bitcoin-transactions nodejs module some years ago the limit (from the
specs) was 512B
It's not a fork, super easy to do
And necessary because bitcoin on ground of I don't know what rule
allowing the IF/ENDIF "unlimited" storage just mimics ethereum for the
worse, and is again quite dubious to use
Le 04/02/2023 à 23:18, Christopher Allen a écrit :
> 520 because that is a similar limit in taproot? Some multiple of
> hash+signature+metadata to satisfy others (that still might not be
> satisfied by any choice).

2023-06-07 23:18:59

- reply

📅 Original date posted:2023-02-04
🗒️ Summary of this message: To request a change in the OP_RETURN size for Bitcoin, one must create a PR and address concerns, revise as needed, and gain community consensus.
📝 Original message:Thanks Christopher, then I understand the process:
- I must issue a PR where I switch 80 to another number, even if I am
not a C/C++ expert it looks easy
- I must stay calm and answer all outstanding concerns about this
trivial change
- Since I am not as clever as the bitcoin devs I must be ready to revise
my PR at any time
- This could lead for the change to be from 80B to 82.xB where x comes
from a non understandable crypto formula
- I must evangelize the change worldwide
- Once accepted, I must collude (pay) with the nodes/miners so they
update at a subtile block height decided by the community
And then I must pray that the PR does not survive myself
Looks like a pretty straight forward process
I am on this list since quite some time, so, seriously, this change is
needed, or, as I said before, deviant behaviours will happen, because
the "witness trick" or others do not work at all, and are clearly
similar to ethereum messy stuff
Le 04/02/2023 à 19:54, Christopher Allen a écrit :
> On Sat, Feb 4, 2023 at 9:01 AM Aymeric Vitte <aymeric at peersm.com
> <mailto:aymeric at peersm.com>> wrote:
>
> What is the official bitcoin channel to request the OP_RETURN size
> change? (press often mentions that ethereum is good to manage
> changes and bitcoin a complete zero.
>
> Here is the simplified version:
>
> Most of these changes start with discussions like these, but then are
> moved concretely to a PR to bitcoin-core with the code changes (in
> this case there is no fork so pretty easy) and an introductory comment
> pointing to discussions elsewhere.
>
> The conversation will also move to the PR itself. Part of the
> challenge now is getting review of your PRs - you’ll need to
> evangelize some and/or have social capital in the bitcoin community to
> get sufficient ACKs to your PR (and some NACKs which you will calmly
> addres), and someone will likely point something out you missed, so
> you revise the PR.
>
> At some point hopefully there looks like all reasonable objections
> have been addressed.
>
> If there is enough interest and few objections there will be
> discussions by the community & maintainers to merge it. It is this
> last part that isn’t very transparent, especially for even a good
> proposal. The maintainers, based on their sense of the community’s
> interest and consensus, must choose when to say it is ready, and then
> decide when and to which release they wish to merge it.
>
> They often start by requesting you to revise your changes to be off by
> default, and be turned on as an option for a specific release. Often
> PR contributors know this is coming and include it.
>
> Even once it is released, this type of change can only happen after
> sufficient miners and nodes update to the release and turn it on. If
> sufficient do, then the maintainers evaluate when to have the feature
> on by default.
>
> These articles offers more perspective:
>
> *
>
> https://unchained.com/blog/contributing-bitcoin-core-patience/
>
> *
>
> https://jonatack.github.io/articles/how-to-contribute-pull-requests-to-bitcoin-core
>
> *
>
> https://medium.com/@amitiu/onboarding-to-bitcoin-core-7c1a83b20365
>
> — Christopher Allen
>
>
--
Sophia-Antipolis, France
CV: https://www.peersm.com/CVAV.pdf
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
GitHub : https://www.github.com/Ayms
A Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7
A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com
Peersm : http://www.peersm.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230204/889a52b1/attachment-0001.html>

2023-06-07 23:18:58

- reply

📅 Original date posted:2023-02-04
🗒️ Summary of this message: Increasing the size of OP_RETURN to store proofs that can be checked using a third party/sidechain is reasonable, but storing on-chain is absurd.
📝 Original message:I don't get very well where all the current (other threats) discussions
are going, storing on-chain is absurd
It's absurd also to flood bitcoin with several useless transactions to
store in witness or others, looks like ethereum messy stuff
What is not absurd is to store the proofs that can be checked using a
notorious third party/sidechain but you need more than 80B
What is the official bitcoin channel to request the OP_RETURN size
change? (press often mentions that ethereum is good to manage changes
and bitcoin a complete zero)
As a very bad solution, I think I would be willing to store data in
addresses, with one single transaction, as people did in the past, then
burning bitcoins but still not expensive, or less than several txs,
because schemes involving several transactions do not work very well
In any case, we see the problem, then people will invent something and
most likely it will not comply at all with bitcoin good practices
Le 04/02/2023 à 15:11, Kostas Karasavvas via bitcoin-dev a écrit :
>
>
> On Fri, Feb 3, 2023 at 10:17 PM Christopher Allen via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> On Fri, Feb 3, 2023 at 3:52 AM Aymeric Vitte via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> I think the right way so people don't invent deviant things is to
> increase the size of OP_RETURN, I don't get this number of
> 80B, you can
> hardly store a signature (of what?) in there and not the
> "what" if the
> "what" is a hash for example
>
>
> Updating the size of OP_RETURN to support a hash (or two), a
> signature, and maybe a few more bytes for metadata, would be very
> helpful in a number of scenarios. It is still a limit but a
> reasonable one. Otherwise, I think we'll have a lot more
> inscription-style scenarios.
>
>
> I wouldn't be against an increase in OP_RETURN but I don't think it
> will make any difference in how often inscription-style use cases will
> be used. They will be used primarily for much larger datasets than,
> say 120 bytes, and they also have the segwit discount.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Sophia-Antipolis, France
CV: https://www.peersm.com/CVAV.pdf
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
GitHub : https://www.github.com/Ayms
A Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7
A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com
Peersm : http://www.peersm.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230204/5dfda935/attachment.html>

2023-06-07 23:18:57

- reply

📅 Original date posted:2023-02-02
🗒️ Summary of this message: The standard rule for OP_RETURN in Bitcoin is a maximum of 80 bytes and one output per transaction, but miners can mine non-standard transactions.
📝 Original message:Thanks, then this limitation should be rethought I think (see the email
I just sent replying to the coloured thread)
Because it forces people to store in witness (less easy to track/show I
believe) or adopt some deviant behavior (like storing in addresses where
the utxo will remain unspendable forever)
Le 02/02/2023 à 12:49, Peter Todd a écrit :
> On Thu, Feb 02, 2023 at 12:45:42PM +0100, Aymeric Vitte wrote:
>> As far as I can read nobody replied to the initial question: what is
>> considered as good/best practice to store in Bitcoin?
> Your answer is beyond not putting unspendable data in the UTXO set, the exact
> details don't really matter. Do what makes sense for your specific application.
>
>> Reiterating my question: what are the current rules for OP_RETURN, max
>> size and number of OP_RETURN per tx
> Max 80 bytes, one OpReturn output per tx.
>
> This of course is the standardness rule. With a miner willing to mine non-std
> transactions anything goes.
>
--
Sophia-Antipolis, France
CV: https://www.peersm.com/CVAV.pdf
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
GitHub : https://www.github.com/Ayms
A Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7
A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com
Peersm : http://www.peersm.com

2023-06-07 23:18:57

- reply

📅 Original date posted:2023-02-03
🗒️ Summary of this message: The witness envelope is less user-friendly and more expensive than OP_RETURN. Increasing the size of OP_RETURN is a better solution for storing data.
📝 Original message:Indeed the witness envelope is more costly and less easy to use (or
read/track)
But let's take a standard P2PKH or P2WPKH output, what prevents me from
adding in the beginning of scriptSig or witness while spending it:
OP_PUSH <data> OP_DROP ? Non standard ? This one makes one transaction only
There are probably plenty of ways to store data, another one would be to
use a dummy 1 of N multisig where only 1 corresponds to a pubkey and the
rest is data, but again several transactions...
I think the right way so people don't invent deviant things is to
increase the size of OP_RETURN, I don't get this number of 80B, you can
hardly store a signature (of what?) in there and not the "what" if the
"what" is a hash for example
Le 02/02/2023 à 14:25, Rijndael via bitcoin-dev a écrit :
> Hello Christopher,
>
> I think if the protocol that you were designing always had <80 bytes,
> I'd prefer the OP_RETURN. I think the "witness envelope" has two major
> disadvantages compared to the OP_RETURN method:
>
> 1. You need to first spend to he address that commits to the script that
> encodes your data payload. So you have a two step process of first
> spending to a "commitment" address and then a second spend to "reveal"
> your payload. You can CPFP to get them both into the same block, but its
> still two transactions, so more cost, etc.
>
> 2. Because of the two step process in (1), if for some reason you were
> unable to get the "reveal" transaction into a block (for example there's
> widespread censorship of transactions that match the format of the
> "reveal" script), then you might have money that's stuck in the "commit"
> stage of the protocol. The way out of this would be to get your money
> out via the keypath or another tapleaf, but then you need to spend money
> to cancel a step in your protocol. Of course there could be widespread
> censorship of your OP_RETURNs too, but you don't have to spend funds on
> the cancellation spends.
>
> I think (2) is actually a pretty weak argument because as we saw in the
> full-rbf discussion, as long as there's some threshold number of nodes
> in the network that relay transactions to miners, you can probably find
> a path to a miner (IIRC the number was on the order of 15% of the
> network?). So I think the big reason to pick OP_RETURN over the witness
> embedding is that you save a transaction and possibly some
> failure-recovery/cancellation logic.
>
> Obviously if your data is larger than 80 bytes, then you probably want
> to do the witness-embedding method. If your data smaller, then a
> pay-to-contract tweak probably the best thing from a space and
> fingerprinting perspective.
>
> - rijndael
>
>
> On 1/31/23 7:46 PM, Christopher Allen via bitcoin-dev wrote:
>> All other things being equal, which is better if you need to place a
>> 64-bytes into the Bitcoin blockchain? A traditional OP_RETURN or a
>> spent taproot transaction such as:
>>
>> OP_FALSE
>> OP_IF
>> OP_PUSH my64bytes
>> OP_ENDIF
>>
>> I know that the anti-OP_RETURN folk would say “neither.” But if there
>> was no other choice for a particular protocol, such as a timestamp or
>> a commitment, which is better? Or is there a safer place to put 64
>> bytes that is more uncensorable but also does not clog UTXO space,
>> only spent transaction `-txindex` space?
>>
>> My best guess was that the taproot method is better, but I suspect
>> there might be some who disagree. I'd love to hear all sides.
>>
>> -- Christopher Allen
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Sophia-Antipolis, France
CV: https://www.peersm.com/CVAV.pdf
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
GitHub : https://www.github.com/Ayms
A Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7
A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com
Peersm : http://www.peersm.com

2023-06-07 23:18:57

- reply

📅 Original date posted:2023-02-01
🗒️ Summary of this message: The debate is on the standard for OP_RETURN in Bitcoin, with data limited to 80B and only one allowed per transaction, leading to storage workarounds. Some suggest using spent taproot transactions instead.
📝 Original message:Could someone clarify what is the standard for OP_RETURN? As far as I
understand the data is limited to 80B and only one OP_RETURN is allowed
in one transaction, if not the tx is non standard, correct?
Then the debate can be to store in witness indeed
Or you can store in output addresses (with super big size), then you
will never be able to spend the dust and we have a utxo forever
In any case there is a storage workaround, probably others exist, not
sure why people are so opposed to a OP_RETURN bitcoin storage (I thought
the max size was 512B, but apparently I am wrong, 80B is ridiculous,
can't do anything with this, except bypassing this limit by other worse
means)
Storage is the main difference between bitcoin and other systems
(ethereum), without it, repeating myself here again the future of
bitcoin is very limited
PS: I saw the answer of Peter, I am proposing something else for
timestamp proofs
Le 01/02/2023 à 01:46, Christopher Allen via bitcoin-dev a écrit :
> All other things being equal, which is better if you need to place a
> 64-bytes into the Bitcoin blockchain? A traditional OP_RETURN or a
> spent taproot transaction such as:
>
> OP_FALSE
> OP_IF
> OP_PUSH my64bytes
> OP_ENDIF
>
> I know that the anti-OP_RETURN folk would say “neither.” But if there
> was no other choice for a particular protocol, such as a timestamp or
> a commitment, which is better? Or is there a safer place to put 64
> bytes that is more uncensorable but also does not clog UTXO space,
> only spent transaction `-txindex` space?
>
> My best guess was that the taproot method is better, but I suspect
> there might be some who disagree. I'd love to hear all sides.
>
> -- Christopher Allen
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Sophia-Antipolis, France
CV: https://www.peersm.com/CVAV.pdf
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
GitHub : https://www.github.com/Ayms
A Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7
A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com
Peersm : http://www.peersm.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230201/0fed77e3/attachment-0001.html>

2023-06-07 23:18:56

- reply

📅 Original date posted:2023-02-02
🗒️ Summary of this message: No one has answered the question of what is considered good practice for storing in Bitcoin, specifically regarding OP_RETURN rules, max size, and number of OP_RETURN per transaction.
📝 Original message:As far as I can read nobody replied to the initial question: what is
considered as good/best practice to store in Bitcoin?
Reiterating my question: what are the current rules for OP_RETURN, max
size and number of OP_RETURN per tx
Le 02/02/2023 à 12:22, Peter Todd via bitcoin-dev a écrit :
> On Wed, Feb 01, 2023 at 02:02:41PM +0000, Andrew Poelstra wrote:
>> On Tue, Jan 31, 2023 at 09:07:16PM -0500, Peter Todd via bitcoin-dev wrote:
>>>
>>> On January 31, 2023 7:46:32 PM EST, Christopher Allen via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>> All other things being equal, which is better if you need to place a
>>>> 64-bytes into the Bitcoin blockchain? A traditional OP_RETURN or a spent
>>>> taproot transaction such as:
>>>>
>>>> OP_FALSE
>>>> OP_IF
>>>> OP_PUSH my64bytes
>>>> OP_ENDIF
>>> What's wrong with OpPush <data> OpDrop?
>>>
>> This is a technical nit, but the reason is that <data> is limited to 520
>> bytes (and I believe, 80 bytes by standardness in Taproot), so if you
>> are pushing a ton of data and need multiple pushes, it's more efficient
>> to use FALSE IF ... ENDIF since you avoid the repeated DROPs.
> Yes, for more than 520 bytes you need to wrap the push in an IF/ENDIF so it's
> not executed. But in this example we're just talking about 64 bytes, so that
> limit isn't relevant and OpPush <data> OpDrop should be sufficient.
>
> Specifically for more than 520 bytes you run into the the
> MAX_SCRIPT_ELEMENT_SIZE check in script/interpreter.cpp, which applies to all
> scripts regardless of standardness at script execution:
>
> //
> // Read instruction
> //
> if (!script.GetOp(pc, opcode, vchPushValue))
> return set_error(serror, SCRIPT_ERR_BAD_OPCODE);
> if (vchPushValue.size() > MAX_SCRIPT_ELEMENT_SIZE)
> return set_error(serror, SCRIPT_ERR_PUSH_SIZE);
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Sophia-Antipolis, France
CV: https://www.peersm.com/CVAV.pdf
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
GitHub : https://www.github.com/Ayms
A Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7
A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com
Peersm : http://www.peersm.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230202/13100de1/attachment.html>

2023-06-07 23:18:49

- reply

📅 Original date posted:2023-01-28
🗒️ Summary of this message: Proposal for a "local bitcoin" (fork of Bitcoin code) for a metaverse, not storing anything in the main Bitcoin chain, but compatible for coin swapping. Bitcoin as an alternative to Ethereum for NFTs and web3.
📝 Original message:I saw the other posts, then storage in witness, no, ordinals no for now,
let's keep things simple and understandable
I forgot to mention that the proposals envision a "local bitcoin" (for a
metaverse for example) wich is a fork of Bitcoin code, but of course not
a fork of Bitcoin, and which of course does not store anything in the
main Bitcoin chain, but which remains compatible (tx format) and coins
between chains can be swapped
Maybe nobody care, but the idea is to put bitcoin into the party as an
alternative to this ethereum mess
Le 27/01/2023 à 16:43, Aymeric Vitte a écrit :
>
> Le 27/01/2023 à 14:21, Andrew Poelstra via bitcoin-dev a écrit :
>> if people were storing NFTs and other crap on the
>> chain, then the Bitcoin fee market would become entangled with random
>> pump&dump markets
> So you mean that Bitcoin is out for NFTs, Metaverse and "web3"?
>
> LN is good but I don't think it can really adapt to everything, what I
> proposed yesterday looks complementary
>
> I clearly dislike the current NFTs existing systems, and to make it
> short NFTs as a whole until recently, it depends on what people mean by
> "NFT", and I did dislike any solution based on OP_RETURN (shxtty stuff
> flooding bitcoin with stupid proofs of nothing)
>
> BUT I changed my mind, one can say that I am contradicting myself
> everywhere (links in the proposals), but no, explaining why in the proposals
>
> Note that in my proposals you don't need to "mint" the NFTs (using a
> third party but not a stupid ethereum/bitcoin like super sidechain) and
> that you can reference millions of them in one transaction (low value
> NFTs like loyalty programms, discount coupons) in that case of course
> the low value NFTs are centralized
>
> That's the future, Bitcoin being out of this does not look plausible,
> currently NOBODY envisions bitcoin or LN for a web3 system, so people
> here might destroy my proposals, then please do, but I find them quite
> good compared to whatever exist
>
>
>
--
Sophia-Antipolis, France
CV: https://www.peersm.com/CVAV.pdf
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
GitHub : https://www.github.com/Ayms
A Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7
A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com
Peersm : http://www.peersm.com

2023-06-07 23:18:48

- reply

📅 Original date posted:2023-01-27
🗒️ Summary of this message: Bitcoin developer proposes a Bitcoin-based NFT system that does not require minting and can reference millions of NFTs in one transaction.
📝 Original message:Le 27/01/2023 à 14:21, Andrew Poelstra via bitcoin-dev a écrit :
> if people were storing NFTs and other crap on the
> chain, then the Bitcoin fee market would become entangled with random
> pump&dump markets
So you mean that Bitcoin is out for NFTs, Metaverse and "web3"?
LN is good but I don't think it can really adapt to everything, what I
proposed yesterday looks complementary
I clearly dislike the current NFTs existing systems, and to make it
short NFTs as a whole until recently, it depends on what people mean by
"NFT", and I did dislike any solution based on OP_RETURN (shxtty stuff
flooding bitcoin with stupid proofs of nothing)
BUT I changed my mind, one can say that I am contradicting myself
everywhere (links in the proposals), but no, explaining why in the proposals
Note that in my proposals you don't need to "mint" the NFTs (using a
third party but not a stupid ethereum/bitcoin like super sidechain) and
that you can reference millions of them in one transaction (low value
NFTs like loyalty programms, discount coupons) in that case of course
the low value NFTs are centralized
That's the future, Bitcoin being out of this does not look plausible,
currently NOBODY envisions bitcoin or LN for a web3 system, so people
here might destroy my proposals, then please do, but I find them quite
good compared to whatever exist
--
Sophia-Antipolis, France
CV: https://www.peersm.com/CVAV.pdf
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
GitHub : https://www.github.com/Ayms
A Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7
A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com
Peersm : http://www.peersm.com

2023-06-07 23:18:45

- reply

📅 Original date posted:2023-01-31
🗒️ Summary of this message: Proposal for a simple NFT system and universal coin swap system based on Bitcoin blockchain. Emphasizes simplicity, security, and decentralization. Not in favor of using ordinals for NFTs.
📝 Original message:I am not sure to understand the current discussion about ordinals
relayed by the press, it's from my standpoint a no for storing things in
witness, and a no to use ordinals as a NFT system
Please remember that NFTs are not only electronic things, it can be real
things, or whatever you like, just referenced in the blockchain by a
"double hash" for my proposal
Bitcoin is currently completely out of the future: the so-called "web3",
and lightning will not solve everything
Then please see my two proposals and comment, it's simple and easy to
read, and just complies with all comments related to/against the
ordinals proposal (storing things for my proposals in a good old
OP_RETURN the hashes and signatures only, not flooding bitcoin with
proofs of nothing, docs, images, etc), or just point out other better
systems based on bitcoin
It just shows again that bitcoin is better in all aspects compared to
other systems
I am not against ordinals but don't see it for "web3"
Le 26/01/2023 à 21:15, Aymeric Vitte a écrit :
> Please see:
>
> "A Bitcoin NFT system"
> https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7 "The
> purpose of this proposal is to propose a simple NFT system based on the
> Bitcoin blockchain, assuming that the main purpose of a NFT is to be
> sold/bought, but not only, it can be something that you keep for
> yourself proving your ownership on the blockchain, or something that you
> offer to someone else, the advantages compared to using Ethereum or any
> blockchain/sidechain on both networks (or others) will be explained below"
>
> And the continuation:
>
> "A Universal Coin Swap system based on bitcoin"
> https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7 "The
> purpose here is to propose a simple Coin Swap decentralized system based
> on Bitcoin but that works for all blockchains/tokens"
>
> The idea is to propose something simple, that people can understand,
> secured, decentralized, easy to implement/use, not expensive for the
> users, unlike Ethereum solutions, showing also that bitcoin can easily
> do in a much more simple manner what ethereum is doing
>
> It's a bit similar to Lightning but not as sophisticated, basically the
> proof of deals are stored in OP_RETURN (looks trivial, yes, but unlike
> other solutions the proposals store a real proof and does not flood the
> bitcoin network with funny stuff, it could be turned into bitcoin
> contracts which most likely will not be recognized as standard), we
> cannot enforce everything like Lightning but the trust here is more
> based on a reputation model, and same as Lightning the cheater just lose
> its bitcoin or get tagged as a cheater, will be tracked and might assume
> the consequences later
>
> As written, I am a fan of Lightning but see it more as a middle/long
> term relationship between people since coins must be locked into a
> multisig transaction while here we are more talking about a one time
> deal, where you don't know if you will buy something else to the seller,
> with which coin and where (metaverse for example)
>
> For your review and comments, here or in private, no real inventions
> here but some non usual ideas like the double hash, the third party and
> others, solving also one of my personal problematic since years: "how to
> sell a secret NFT?"
>
> In any case it remains decentralized (but of course some tools/wallets
> must ease the process for the users), like Lightning, and unlike
> everything that is existing today in those areas to my knowledge, except
> Lightning again
>
> Regards
>
> Aymeric
>
>
--
Sophia-Antipolis, France
CV: https://www.peersm.com/CVAV.pdf
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
GitHub : https://www.github.com/Ayms
A Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7
A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com
Peersm : http://www.peersm.com

2023-06-07 23:18:45

- reply

📅 Original date posted:2023-01-26
🗒️ Summary of this message: The proposal suggests a simple NFT system and a universal coin swap system based on Bitcoin, which are decentralized, easy to use, and cost-effective compared to Ethereum solutions. The proof of deals is stored in OP_RETURN, and the trust is based on a reputation model. The proposal aims to solve the problem of selling a secret NFT and can be turned into Bitcoin contracts.
📝 Original message:Please see:
"A Bitcoin NFT system"
https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7 "The
purpose of this proposal is to propose a simple NFT system based on the
Bitcoin blockchain, assuming that the main purpose of a NFT is to be
sold/bought, but not only, it can be something that you keep for
yourself proving your ownership on the blockchain, or something that you
offer to someone else, the advantages compared to using Ethereum or any
blockchain/sidechain on both networks (or others) will be explained below"
And the continuation:
"A Universal Coin Swap system based on bitcoin"
https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7 "The
purpose here is to propose a simple Coin Swap decentralized system based
on Bitcoin but that works for all blockchains/tokens"
The idea is to propose something simple, that people can understand,
secured, decentralized, easy to implement/use, not expensive for the
users, unlike Ethereum solutions, showing also that bitcoin can easily
do in a much more simple manner what ethereum is doing
It's a bit similar to Lightning but not as sophisticated, basically the
proof of deals are stored in OP_RETURN (looks trivial, yes, but unlike
other solutions the proposals store a real proof and does not flood the
bitcoin network with funny stuff, it could be turned into bitcoin
contracts which most likely will not be recognized as standard), we
cannot enforce everything like Lightning but the trust here is more
based on a reputation model, and same as Lightning the cheater just lose
its bitcoin or get tagged as a cheater, will be tracked and might assume
the consequences later
As written, I am a fan of Lightning but see it more as a middle/long
term relationship between people since coins must be locked into a
multisig transaction while here we are more talking about a one time
deal, where you don't know if you will buy something else to the seller,
with which coin and where (metaverse for example)
For your review and comments, here or in private, no real inventions
here but some non usual ideas like the double hash, the third party and
others, solving also one of my personal problematic since years: "how to
sell a secret NFT?"
In any case it remains decentralized (but of course some tools/wallets
must ease the process for the users), like Lightning, and unlike
everything that is existing today in those areas to my knowledge, except
Lightning again
Regards
Aymeric
--
Sophia-Antipolis, France
CV: https://www.peersm.com/CVAV.pdf
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
GitHub : https://www.github.com/Ayms
A Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7
A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com
Peersm : http://www.peersm.com

2023-06-07 23:18:09

- reply

📅 Original date posted:2023-01-05
🗒️ Summary of this message: Aymeric Vitte proposes a decentralized and secure Bitcoin NFT system as an alternative to the centralized and insecure Ethereum-based NFTs.
📝 Original message:Hi Vincent,
Indeed the gist was recorded (by mistake) as secret but the link is
supposed to work anyway, I have made it public, thanks for confirming
that it's working now, just in case I am attaching the text file
Regards
Aymeric
Le 04/01/2023 à 21:59, Vincenzo a écrit :
> On Thu Dec 29, 2022 at 5:49 PM CET, Aymeric Vitte via bitcoin-dev wrote:
>> I am not a fan of NFTs as currently designed and used, centralized,
>> insecure, duplicable, virtual, stealable, not signed, expensive
>>
>> But if you consider that a NFT is anything that you can buy or store, as
>> something real, or electronic, or whatever, in the real world, web or
>> metaverse, then it becomes interesting
>>
>> NFTs are mostly used on Ethereum, and a "mess" to describe this stuff is
>> a weak word
>>
>> Then I wrote: "A Bitcoin NFT system":
>> https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7 ,
>> decentralized, secure, not expensive
>>
> The link is gone or just private.
>
> Cheers!
>
> Vincent.
--
Sophia-Antipolis, France
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
GitHub : https://www.github.com/Ayms
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com
Peersm : http://www.peersm.com
-------------- next part --------------
# A Bitcoin NFT system
## Introduction
NFT is another barbarous name invented by the crypto folks meaning quasi nothing, by NFT in this proposal we will refer to whatever can be sold or referenced from the real world, web and metaverse using a blockchain system
The easy way solution is usually to use Ethereum, create some NFT tokens via ERC-721/1155 contracts and/or use some marketplaces such as Opensea which always lead to a centralized and insecure system that can collapse at any moment, and which is still complicate since nobody understand what is behind, fortunately (or not) MetaMask will do the job for you without you understanding what you are doing, like wrapped ETH
This is explained here: [Bitcoin, Ethereum, smart contracts, lightning, sidechains, Defi, DApps, NFTs, DEX, DAO explained - Centralization vs Decentralization](https://gist.github.com/Ayms/04b3084a14ee202e707b3faec57ed26e)
Especially: [tokens and sidechains](https://gist.github.com/Ayms/04b3084a14ee202e707b3faec57ed26e#example-2-tokens-and-sidechains)
And: [Opensea](https://gist.github.com/Ayms/04b3084a14ee202e707b3faec57ed26e#example-6-opensea)
## Purpose
The purpose of this proposal is to propose <b>a simple NFT system based on the Bitcoin blockchain</b>, assuming that the main purpose of a NFT is to be sold/bought, but not only, it can be something that you keep for yourself proving your ownership on the blockchain, the advantages compared to using Ethereum or any blockchain/sidechain on both networks (or others) will be explained below
## Referencing a NFT
A NFT can be a physical good, an electronic item (such as image), something virtual or not, in fact anything
If we take a document or an image, a simple reference to the NFT is its hash (SHA-256), but it is not really relevant since it's easy for a thief to slightly modify the document or image which will lead to a different hash
Now in what follows we will allocate a hash to reference any NFT
## The final hash reference to a NFT
Depending on the conditions the hash can be known (public marketplace for example) or unknown (only the buyer and the seller know it or the owner)
Thererfore the reference to the NFT will be the SHA-256 of its hash, which then hides the original hash, this is of course useless if the hash is known but let's keep the same convention, called |reference| in what follows
## Minting a NFT on Bitcoin
"Minting a NFT" just means to record your ownership of the NFT in the blockchain
To mint a NFT that you own on Bitcoin, you can do a transaction whose output will be:
From address A (the seller):
OP_RETURN |reference|
DUST (A or B) or refund to an address of yourself (A or B)
Since the transaction is signed by A, we know that A is the owner of the reference, but note that from this point the public key of A is known, therefore if the purpose is to store a long term NFT then use another address B of yourself (because in some time it will be easier to crack a bitcoin address for which we know the public key rather than one that holds some bitcoins but has not been spent, so knowing only the hash of this address)
An OP_RETURN output is just something where you can store some data, limited to 512B
A lot of variations are possible in this article, for example you can decide to allocate one A address per NFT, it just depends on the use cases
For all the transactions mentioned in this article, opt-in for Replace By Fee must not be used [Replace By Fee](https://bitcoin.fr/replace-by-fee-rbf/)
It would be possible not to use OP_RETURN and for example store the |reference| in scriptSig, then construct an address (scriptPubKey) that will drop it while executing, but this would be a non standard transaction, so you shoud rely on some miners to mine it, without stealing your NFT, since it's easy for a miner to change the transaction and mint the NFT for himself
## Minting several NFTs in one transaction
You can do the very same using the Chainpoint protocol, which is to build a Merkle tree from |reference1| |reference2|....|reference N| (for which we recall will be the SHA-256 of the original NFTs hash), and replace the root of this tree in |reference| above
How Chainpoint work is well described here: [Chainpoint Proof](https://github.com/chainpoint/whitepaper/issues/5#issuecomment-304452107), basically while making a Chainpoint tree you get a proof to rebuild it from any |reference| (that you must know), which is just the other hashes that you need to know to reach the root
In that case only the owner of the multiple NFTs knows the proofs and/or the |references|, unless he decides to release them, which he should do as described in the next paragraph (because the hashes and proofs must be known to check the validity of NFT transfers)
In what follows we will make reference to a Chainpoint |reference|
## Avoiding double minting
Double minting of NFTs is quite trivial, as far as we know there are zero protections against this in existing systems (Ethereum and others), the principle is simple: you mint several time the same NFT and possibly sell it several time or get robbed (the thief does transactions using the |reference| that he saw), because it's easy for a malicious person to do the very same transaction that you did and pretend the ownership of the NFT, or it's easy for you to mint it to different marketplaces or mint it several time, and then sell it several time
To illustrate this, read [Solving the double minting problem](https://medium.com/geekculture/solving-the-nft-double-minting-problem-with-computer-vision-c57bbbb4652d)
Unfortunately the above article just refers to images and the solution does not work at all at the end, because associating the picture to the camera or whatever that took it does not work and is easy to fake
Coming back to our bitcoin case, it seems simple to elect you as the real owner of the NFT since you made the transaction first, then based on the timestamp you are definitely the owner, but no
The thief could intercept your transaction, decide not to broadcast it further, replace it by a transaction minting your NFT for himself, with higher network fees for example and more direct access to miners, then this transaction will be the first one and the thief would have stolen your NFT
You can't do anything against this without using a third party to record that you had the knowledge of the |reference| first
The same problematic exists for example for js code loading, see [Bitcoin-transactions wallet/tools](https://peersm.com/wallet), here our github account is used to check the code
Then the very same is proposed here, preferably using the [Wayback Machine](https://archive.org/web/) to store |reference| (that you are the only one to know at this stage) signed by A before minting the NFT, then for sure you are the owner of the NFT because you are the first one to have referenced |reference| and signed it with your address (note again that as soon as you sign something the public key of A is known)
You can use other systems, github, even Twitter
What if all of those systems disappear and I can't prove anything any longer? Well, then probably internet has disappeared too
Anyway like the WebRTC peer introduction mechanism you can do this by any means you like, your own website, even a letter, you just need to prove that A had the knowledge of the double hash first
Now the double minting case is supposed to be marginal, except if you are a thief yourself
## Transferring a NFT for free
For a gift or whatever other reason, A can decide to transfer a NFT for free to C, the transaction will be:
From address A (the seller):
OP_RETURN |some code||reference|
DUST (C) and refund to an address of yourself (A or B)
|some code| is just used to make the distinction between a minting operation
A sends the original hash to C
## C Buying a NFT from A
The transaction will be:
From address C (the buyer):
OP_RETURN |price||some code||reference|- signed by A
|price| to A and refund to C or other C address
Once A and C have agreed on a price then A should send to C the |price||some code||reference| signed by him, which proves that the deal is accepted
If C tries to cheat and does broadcast a transaction that does not match the agreed price (since C cannot fake the signature of A), then C is still not the owner of the NFT and has lost its bitcoin, if a thief intercepts the transaction and does another one for himself, that's the same, since he is not willing to pay for the price
If A receives the correct amount, then he will send to C the original hash of |reference|, the same principle applies for all following transactions
We can not really enforce this, A could not send the hash, but for what purpose? This represents the same trust model than when you are buying some goods (the hash is the ticket), now in normal conditions the original hash is not really mandatory
Note that we know from minting/signing the public key of A, therefore anybody can verify the signature in the OP_RETURN
Note again that the signature of A is enough to know its public key and check the signature, <b>therefore minting is not mandatory</b> (depending on the use cases again)
Note also that in Ethereum style, that's the other way around, where A would initiate the final transaction to the NFT contract that will transfer to C
## C selling a NFT to D
That's the same:
From address D (the buyer):
OP_RETURN |price||some code||reference|- signed by C
|price| to C and refund to D or other D address
C sends the original hash to D
## C Buying a NFT from A from a Chainpoint |reference|
A sends to C the |price||some code||reference||Chainpoint proof| signed by him, C then do the following transaction:
From address C (the buyer):
OP_RETURN |price||some code||reference||Chainpoint proof|- signed by A
|price| to A and refund to C or other C address
## Group/organization C of buyers
C is then a multisig address funded by the group, and as before:
From address C (the buyers):
OP_RETURN |price||some code||reference|- signed by A
|price| to A and refund to C or other C address
Same principle would apply for Chainpoint |reference|
## But, in all of this, what is the purpose of the double hash for |reference|?
Just to hide (if applicable) that the hash is only known by the buyer and the seller if the transactions are correct, then if anything unexpected happens they can prove that they are the only one to know the original hash of the NFT
We can take here the example of Kering (luxury group): [Kering NFT solution](https://www.ulysse-nardin.com/zh_en/blockchain-technology ), this is a variation of what is proposed here, when you buy a luxury product you get a certificate, then you go to their website, use the certificate information + your name & co, then you get a second certificate and the associated hash, the hash is then stored in the bitcoin blockchain in an OP_RETURN using the Chainpoint protocol via [Woleet](https://www.woleet.io/fr/accueil/) service
So here you are the only one to know the hash (with Kering), the problem of this solution is that it is very centralized and you can't correlate the hash to the product. That's where the double hash method could be used, you print on the luxury product the double hash (QR code or whatever) and give the original hash to the buyer, then if the product is counterfeit (with the same double hash) or stolen you can detect it since the malicious seller does not know the original hash
## Costs
Currently the network fees are 6-12 satoshis per byte, and the dust limit can be set at 546 satoshis
It's not possible to give a precise number here since the transactions depend on the number of inputs but an [estimation](https://www.bitstamp.net/learn/blockchain/how-are-btc-transaction-fees-determined/) would be less than 1 USD per transaction (probably 0.5 USD) against 70 to 100 USD on gas fees in Ethereum
This is far less than Ethereum NFT tokens see [Moxie experience](https://gist.github.com/Ayms/04b3084a14ee202e707b3faec57ed26e#example-7-moxies-experience)
## Is this system centralized?
No unlike whatever exists about sidechains (except Lightning), Ethereum NFTs or Dstuff, it is not, because you do not rely on any centralized platform to use it (the third party is the one you choose and it can't interact with the transactions), or Oracles that would be involved in your transactions creation/confirmation/transfer
## Is this system anonymous?
Not totally as currently designed, like Lightning again, since buyer/seller must "know" each others, but they can do it via anonymous means like Signal, Protonmail, Telegram or other stuff, or Tor, the advise is to create a new good old gmail address for this purpose and use PGP keys
In any case others around do not know what is going on
## Why not a super sidechain instead?
You can read this conclusion from a previous article: [Conclusion](https://gist.github.com/Ayms/04b3084a14ee202e707b3faec57ed26e#conclusion)
We have different examples, but let's take a few, Binance Smart Chain, supposedly compatible with Ethereum is a mess (or FTT/FTX token, see [Collapse of FTX and others: the Fxcking Token Theory](
https://www.linkedin.com/posts/aymeric-vitte-05855b26_the-fxcking-token-theory-as-a-coincidence-activity-6996493598653317120-vCpA)), and [Stacks](https://protos.com/what-is-stacks-and-does-it-really-serve-as-defi-for-bitcoin/) for Bitcoin supposedly allowing "smart contracts" and NFT on bitcoin is the same, both centralized, insecure, making it difficult to swap the tokens between one chain to another
Let's hope this article shows how powerfull (and less costly) is bitcoin, if we elaborate on Stacks it's another blockchain on top of Bitcoin, they register the blocks inside OP_RETURN in Bitcoin via a "proof of transfer". Why do they do this? No idea but surely because their blockchain is neither secured neither decentralized, this is just flooding the Bitcoin network with useless transactions duplicating proofs on two blockchains
There are many "proof-of-whatever" that are just fake stuff (like Filecoin proof of replication https://github.com/protocol/research/issues/4), useless, quite dubious, as stated in our conclusion above the intermediate states shoud be burned and only the final/relevant result stored in Bitcoin, this is very exactly what is doing Lightning
In any case, whatever sidechain/blockchain is proposed can only lead to something funny, because even the worldwide networks bitcoin and ethereum are still not decentralized today, despite of their age, because something like a few thousands nodes is not what we can call a decentralized system, then proposing something decentralized on top of it or not does not look serious, the only real decentralized network remains Bittorrent
This proposal seems to contradict one of our article [How stablecoins really work (Tether example), how to crack them and why you should take care if you use them](https://www.linkedin.com/pulse/how-stablecoins-really-work-tether-example-crack-them-aymeric-vitte/), but no in fact since everything is signed here
## Local Bitcoin
We will not talk here about the craziness of the Bitcoin forks period, which we have described here: ["Bitcoin Tartuffe - User guide: How to create your bitcoin fork in 5mn, fool everybody and become rich](https://www.linkedin.com/pulse/user-guide-how-create-your-bitcoin-fork-5mn-fool-everybody-vitte)
But we can envision a local Bitcoin, which would be limited to an area and is just a fork of the Bitcoin code (and not the Bitcoin network), restarting from the beginning
Then it's possible to adapt the rules according to the local area, for example reducing the costs by eliminating the dust limit, network fees by mining at lowest difficulty, unlimited supply and no halving
This seems to contradict the good practices of Bitcoin but not really, since the area is limited to people that are supposed to cooperate together, then the risk of attack is limited also
You might say that we are criticizing in [Bitcoin, Ethereum, smart contracts, lightning, sidechains, Defi, DApps, NFTs, DEX, DAO explained - Centralization vs Decentralization](https://gist.github.com/Ayms/04b3084a14ee202e707b3faec57ed26e) the fact that most of ERC-20/NFT tokens are of zero value, because coming from nowhere, but we are proposing the same
Not exactly, the local Bitcoin could be seen as a barter money, with a stable value, mined by everybody in the area, then unlike ERC-20 tokens you cannot issue 1 Billion of them all of a sudden
It remains decentralized since everybody is participating and get rewarded according to the probability distribution
To a certain extent, since the local area management might decide to shut down the system
An example is a cruise boat (who might have limited connectivity to interact with an outside blockchain and is not willing to burn its batteries with mining) where each element of the boat (cabins, kitchen, etc) would mine the local Bitcoin, then you can buy/exchange NFTs on the boat, services, use the token for the casino, restaurants, shops, the boat metaverse, etc
The local Bitcoin can be crawled from the outside and transactions can be sent from the outside, so, for example, luxury vendors and others can propose NFTs on board (and deliver them on board or when the boat is at some harbour), and NFTs can be proposed inside the boat shops/metaverse
Indeed since the local Bitcoin is not a fork of Bitcoin network, you don't have to implement replay protection (SIGHASH), then usual Bitcoin transactions can be built and sent to the local Bitcoin, of course you must not make mistakes between both chains
How can we bridge this with the Bitcoin network ? The first answer is: why would you need to do this? If so, then you need to use a bridge which will be of course something centralized, right now we are not aware of other possible methods (like atomic swap or other bulls)
This can apply to planes and many other local areas
## License and funding
While this work is public, it is not in the public area and under any open source license, then to use it, please contact: aymeric peersm com, PGP Key fingerprint : 65EF AE3D 973F D36A AB25 1225 2A1D 7B34 2627 AC39
The goal here is to reference who did fund this proposal
https://web.archive.org/web/20221231185645/https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7

2023-06-07 23:18:00

- reply

📅 Original date posted:2022-12-29
📝 Original message:I am not a fan of NFTs as currently designed and used, centralized,
insecure, duplicable, virtual, stealable, not signed, expensive
But if you consider that a NFT is anything that you can buy or store, as
something real, or electronic, or whatever, in the real world, web or
metaverse, then it becomes interesting
NFTs are mostly used on Ethereum, and a "mess" to describe this stuff is
a weak word
Then I wrote: "A Bitcoin NFT system":
https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7 ,
decentralized, secure, not expensive
It does envision also local Bitcoin chains
No invention here, maybe what I am describing already exists but I am
not aware of it (however it's a bit similar to coloured coins and other
things like this), this is simple compared to usual discussions on this
list, for your review and comments, here if applicable or to my personal
address
As we can see for those that would read it, it seems like that I am
contradicting myself everywhere with this proposal compared to previous
publications (links in the proposal), but in fact no, I am explaining why
--
Sophia-Antipolis, France
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
GitHub : https://www.github.com/Ayms
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com
Peersm : http://www.peersm.com

2023-06-07 23:02:12

- reply

📅 Original date posted:2022-01-14
📝 Original message:(P2P?) Electronic Cash (Defense?) Fund or Electronic Cash Foundation ?
More neutral, potentially covering others than Bitcoin, mimicking a bit
EFF (even if as stated US is not the only target), referring to
Satoshi's paper where everything started
Maybe I am not up to date but it would be good to know what are the
current procedures with the Tulip thing
Aymeric
Le 13/01/2022 à 19:20, jack via bitcoin-dev a écrit :
> Hi Prayank,
>
>> On 13 Jan 2022, at 10:13, Prayank <prayank at tutanota.de> wrote:
>> I had few suggestions and feel free to ignore them if they do not make sense:
>>
>> 1.Name of this fund could be anything and 'The Bitcoin Legal Defense Fund' can be confusing or misleading for newbies. There is nothing official in Bitcoin however people believe things written in news articles and some of them might consider it as an official bitcoin legal fund.
> Excellent point. Will come up with a better name.
>
>> 2.It would be better if people involved in such important funds do not comment/influence soft fork related discussions. Example: Alex Morcos had some opinions about activation mechanism during Taproot soft fork IIRC.
> Yes. Will think through this and board operating principles we can share publicly, which would probably include criteria for how cases are chosen, to protect against this board and fund influencing direction.
>
> Open to ideas and suggestions on all.
>
> jack
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 23:01:12

- reply

📅 Original date posted:2021-12-12
📝 Original message:Using the Tor network to bypass censorship for bitcoin can work but is a
very poor solution, the Tor network is very centralized, very small,
watched and controlled, with plenty of features that do not apply to
other protocols than those made to be used with the Tor Browser, Pieter
gave a simple example, that you can solve easily changing the circuits,
the problem remains that you really need to be a super expert to escape
all the dangers of the Tor network, not even sure it's possible unless
you use something else than the Tor project code
Believe it or not, node-Tor is a more than ten years old project (and
not a duplicate of the Tor network), so I know what I am talking about,
different studies of mine show also that the more you try to hide the
more you can get caught, even on really decentralized networks like
bittorrent, unlike another common belief that in such big networks it's
difficult to track/deanonymize peers, it is not
Extra measures like rebroadcasting can maybe add something, but back to
the previous sentence, extra measures can also help to catch/track you
if not well designed/thought
What I am proposing since years, not only to bitcoin, is to use the Tor
protocol independently of the Tor network, and from the browsers also
acting as nodes (not to be misunderstood with the Tor Browser, this has
nothing to do) probably someone one day will understand it
Le 12/12/2021 à 14:38, Karl a écrit :
>
>
> On Sun, Dec 12, 2021, 7:42 AM Aymeric Vitte via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> Indeed, I reiterate that using the Tor network for Bitcoin or
> whatever protocol not related to the Tor Browser (ie browsing and
> HS) does not make sense, for plenty of reasons
>
>
> Please cite this. It is very hard to believe.
>
> Personally, I have encountered network blocking of bitcoin peers, and
> Tor is one way to reconnect with the network when this happens.
>
>
> Regardless, reasonable rebroadcasting of nonlocal transactions is a
> hands-down good thing. This does not make them anonymous, but it does
> make it a little harder to track their origin, and additionally it
> makes their transmission more robust.
>
> Every extra measure is a good thing, as everything eventually fails.
>
--
Sophia-Antipolis, France
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
GitHub : https://www.github.com/Ayms
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com
Peersm : http://www.peersm.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211212/4e661983/attachment-0001.html>

2023-06-07 23:01:12

- reply

📅 Original date posted:2021-12-13
📝 Original message:> It's just one example of a downside of (a particular way of) using
> Tor. That doesn't mean I recommend against using Tor for Bitcoin
> traffic at all; my point was simply that there are trade-offs, and
> aspects of privacy of the P2P protocol that Tor does not address, and
> thus one shouldn't assume that all problems are solved by "just use Tor".
There are many downsides since the default behavior of the Tor network
does not apply to p2p networks, another example is a bitcoin node
exiting transactions (I thought you were referring to this), since the
same Tor circuit is used during some time most likely the transactions
are related to the same node even if we don't know its IP
According to the bitcoin github example discussion link I gave, I am not
saying that Tor network nodes should not be used, I am saying that they
should be used à la node-Tor, or more precisely like the github example
and http://www.peersm.com/Convergence-2020.pdf, one of the main
differences are how behave the first node (ie the originating bitcoin
node), HS/RDV, nb of hops, hybrid nodes
Another drawback is that bitcoin community lets bitcoin nodes operators
play the way they like with torrc
@Prayank, regarding js/webrtc my previous answer was not partial, please
email in private if you need more, it's just a part of the project (but
important since disruptive), which is already advertised widely
(bitcoin, ipfs, covid apps, videoconf, etc, there are plenty of links on
github, lists, specs discussion, probably I should reference them), the
answer is always the same: "very interesting, go ahead", but no, it is
designed to be integrated by the projects, not by myself, and the only
thing missing to get rid of myself is to release phase4

2023-06-07 23:01:11

- reply

📅 Original date posted:2021-12-12
📝 Original message:Indeed, I reiterate that using the Tor network for Bitcoin or whatever
protocol not related to the Tor Browser (ie browsing and HS) does not
make sense, for plenty of reasons
But using the Tor protocol outside of the Tor network (and inside
browsers for wallets for example) does:
https://github.com/Ayms/node-Tor#presentation and
https://github.com/Ayms/node-Tor#phase-4-and-phase-5, anonymizing nodes
can just be already existing bitcoin nodes, example:
https://github.com/bitcoin/bitcoin/pull/18988#issuecomment-646564853
Le 11/12/2021 à 17:21, Pieter Wuille via bitcoin-dev a écrit :
>> It is that the solution to privacy is to use privacy-enhancing network
>> communications, such as TOR. I am not against a mechanism to rebroadcast
>> transactions more robustly if the mempool of adjoining nodes has
>> forgotten about them, but the truth is, all transactions originate from
>> some node, and there are methods that allow an individual node to be
>> identified as the likely source of a transaction unless privacy-enabled
>> networks are utilised. Having a different method to cause rebroadcast
>> does not obfuscate the origin.
> You're talking about distinct aspects of transaction privacy.
>
> The rebroadcasting approach as it exists on the network, where wallets are responsible for their own rebroadcasting, directly reveals to your peers a relation between nodes and transactions: whenever any node relays the same transaction twice, it almost certainly implies they are the origin.
>
> This is just a node-transaction relation, and not necessarily IP-transaction relation. The latter can indeed be avoided by only connecting over Tor, or using other privacy networks, but just hiding the relation with IP addresses isn't sufficient (and has its own downsides; e.g. Tor-only connectivity is far more susceptible to partition/Eclipse/DoS attacks). For example seeing the same node (even without knowing its IP) rebroadcast two transaction lets an observe infer a relation between those transactions, and that too is a privacy leak.
>
> I believe moving to a model where mempools/nodes themselves are responsible for rebroadcasting is a great solution to improving this specific problem, simply because if everyone rebroadcasts, the original author doing it too does not stand out anymore. It isn't "fixing privacy", it's fixing a specific leak, one of many, but this isn't a black and white property.
>
> Cheers,
>
> --
> Pieter
>
> _______________________________________________
> 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/20211212/21aee049/attachment.html>

2023-06-07 22:58:20

- reply

📅 Original date posted:2021-08-29
📝 Original message:Hi,
Maybe let's discuss the details privately since some might be off topic
for this list, as a quick answer the discussion I linked to is about
using the Tor protocol between bitcoin nodes piping the bitcoin protocol
via node-Tor (not to be misunderstood with the Tor network again), nodes
can be whatever you like including browsers (but the use of the Tor
browser is not foreseen neither encouraged, disabling js and WebRTC is
valid when you are browsing, but browsing is not what is proposed here),
they can be wallets too, if you look at the browserification of
bitcoin-transactions (https://peersm.com/wallet) there is a mechanism to
make sure the js code you loaded is the correct one, you can also create
a bookmarklet button with the js code to run it directly inside the
browser without having to load it
Regards
Aymeric
Le 29/08/2021 à 00:40, Prayank a écrit :
> Hi Aymeric,
>
> Thanks for sharing the link. 'bitcoin-transactions' and 'node-Tor'
> looks interesting although I will have to check details and try things.
>
> One observation: I noticed it's in JavaScript and will use WebRTC.
> Users who care about privacy normally disable both while using a browser.
>
> --
> Prayank
>
> A3B1 E430 2298 178F
>
>
>
> Aug 28, 2021, 22:06 by aymeric at peersm.com:
>
> Probably you could add to your links this discussion/issue
> https://github.com/bitcoin/bitcoin/pull/18988#issuecomment-646564853
>
>
> Le 27/08/2021 à 23:29, Prayank via bitcoin-dev a écrit :
>> I wish Hal Finney was with us today and help us improve privacy
>> in Bitcoin. I like reading his posts and one of them is
>> https://bitcointalk.org/index.php?topic=156390.msg1659654#msg1659654
>>
>> I had emailed about Privacy related things on July 23:
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019276.html
>>
>> It was my birthday on 23 and had few beers so maybe email wasn't
>> very focused. Although basic idea was to initiate discussion
>> about improving privacy in different Bitcoin projects. I did not
>> receive any response except one person who liked the video I
>> mentioned in the email. So here is one project which uses GitHub
>> pages and will have the following things:
>>
>> 1.Issues and PRs related to privacy from different Bitcoin
>> projects. I have added few from Bitcoin Core (full node
>> implementation), Bisq(DEX) and LND (LN implementation) right now.
>> 2.Blog section for my opinion on different privacy related issues
>> and PRs.
>> 3.'Hall of Fame' section to appreciate the contribution of devs
>> who are improving privacy in different Bitcoin projects.
>>
>> I will be happy if this project helps in improving privacy or
>> helps users/devs in any other way. This project will never turn
>> in to a paid newsletter or needs any sponsors, however any
>> contribution to make the website better would be appreciated.
>> Edward Snowden can also contribute if he wants to do more than
>> just tweets to help improve Bitcoin privacy.
>>
>> Link: https://prayank23.github.io/camouflage/
>>
>> Will move everything to new repository this weekend:
>> https://github.com/BlockchainCommons/Bitcoin-Camouflage
>>
>> --
>> Prayank
>>
>> A3B1 E430 2298 178F
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> <mailto:bitcoin-dev at lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
--
Sophia-Antipolis, France
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
GitHub : https://www.github.com/Ayms
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com
Peersm : http://www.peersm.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210829/3e69e234/attachment.html>

2023-06-07 22:58:19

- reply

📅 Original date posted:2021-08-28
📝 Original message:Probably you could add to your links this discussion/issue
https://github.com/bitcoin/bitcoin/pull/18988#issuecomment-646564853
Le 27/08/2021 à 23:29, Prayank via bitcoin-dev a écrit :
> I wish Hal Finney was with us today and help us improve privacy in
> Bitcoin. I like reading his posts and one of them is
> https://bitcointalk.org/index.php?topic=156390.msg1659654#msg1659654
>
> I had emailed about Privacy related things on July 23:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019276.html
>
> It was my birthday on 23 and had few beers so maybe email wasn't very
> focused. Although basic idea was to initiate discussion about
> improving privacy in different Bitcoin projects. I did not receive any
> response except one person who liked the video I mentioned in the
> email. So here is one project which uses GitHub pages and will have
> the following things:
>
> 1.Issues and PRs related to privacy from different Bitcoin projects. I
> have added few from Bitcoin Core (full node implementation), Bisq(DEX)
> and LND (LN implementation) right now.
> 2.Blog section for my opinion on different privacy related issues and PRs.
> 3.'Hall of Fame' section to appreciate the contribution of devs who
> are improving privacy in different Bitcoin projects.
>
> I will be happy if this project helps in improving privacy or helps
> users/devs in any other way. This project will never turn in to a paid
> newsletter or needs any sponsors, however any contribution to make the
> website better would be appreciated. Edward Snowden can also
> contribute if he wants to do more than just tweets to help improve
> Bitcoin privacy.
>
> Link: https://prayank23.github.io/camouflage/
>
> Will move everything to new repository this weekend:
> https://github.com/BlockchainCommons/Bitcoin-Camouflage
>
> --
> Prayank
>
> A3B1 E430 2298 178F
>
>
> _______________________________________________
> 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/20210828/76d7d468/attachment.html>

2023-06-07 18:29:30

- reply

📅 Original date posted:2021-03-14
📝 Original message:It's incredible how this troll keeps trolling and the list (bitcoin-dev
!!) keeping attention
Good troll, really
Le 14/03/2021 à 11:13, LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev a
écrit :
> Good Afternoon,
>
> Since this is on the list I will open without my thank-you. You will
> kindly be advised that my title are recorded in both Scotland and with
> England, also provided by record in Australia's account with names
> recorded. If you wonder than am I Wills it is because a long time
> before we ever saw Wills in print with an article provided reference to
> any Prince in the past thirty-years there I am Wills already. Title The
> Australian was prepared a long time to my requiest to wait until it was
> better presented, with at least some acquired experience in business to
> understand a market like BHP services. Thereby you accept a separate
> title Lord being with feudal and Lord being with the appointments
> direct to the service of the monarch's house Earl and similar up to
> Duke and King and higher being heard usually the monarch's preference
> Your Excellency or Your Highness being His service. I have never been
> any Prince. If any Prince titles came the instructions were they were
> retained to be considered not accepted not refused.
>
> If you had each fools to inquire.
>
> KING JAMES HRMH
> Great British Empire
>
> Regards,
> The Australian
> LORD HIS EXCELLENCY JAMES HRMH (& HMRH)
> of Hougun Manor & Glencoe & British Empire
> MR. Damian A. James Williamson
> Wills
>
> et al.
>
>
> Willtech
> www.willtech.com.au
> www.go-overt.com
> and other projects
>
> earn.com/willtech
> linkedin.com/in/damianwilliamson
>
>
> m. 0487135719
> f. +61261470192
>
>
> This email does not constitute a general advice. Please disregard this
> email if misdelivered.
> ------------------------------------------------------------------------
> *From:* bitcoin-dev <bitcoin-dev-bounces at lists.linuxfoundation.org> on
> behalf of Eric Voskuil via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org>
> *Sent:* Saturday, 13 March 2021 9:30 AM
> *To:* R E Broadley <rebroad+linuxfoundation.org at gmail.com>; Bitcoin
> Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org>
> *Subject:* Re: [bitcoin-dev] Taproot NACK
>
> I’m pretty sure it’s subtle mockery. Even a legit title doesn’t
> warrant additional attention.
>
> e
>
> > On Mar 12, 2021, at 14:02, R E Broadley via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >
> > Can I just point out (to those addressing James as Lord/Excelency/etc
> > that he isn't noble nor a Lord, so just wanted to mention this in case
> > people were giving him more attention than the average person would be
> > afforded.
> >
> > My 2p (an equal 2p) on Taproot is ACK, by the way.
> _______________________________________________
> 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
--
Sophia-Antipolis, France
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210314/e2f3f7d7/attachment.html>

2023-06-07 18:27:56

- reply

📅 Original date posted:2020-12-25
📝 Original message:Resending to the list since I am using a different email
Complement: if anonymity is required from the browser (or elsewhere) you
might consider looking at https://github.com/Ayms/node-Tor too
Le 24/12/2020 à 20:40, Aymeric Vitte a écrit :
>
> You might want to take a look at: https://peersm.com/wallet
>
> And https://github.com/Ayms/bitcoin-transactions
>
> "wallet" is not the very correct word, it's more bitcoin cli outside
> of bitcoin core but for now not linked to an explorer/tx system which
> makes it probably still not so easy to use for the transactions part
> (which can be extended to lightning, etc)
>
> The idea is to propose to people most of the tools they need to manage
> their coins by themselves, or at least understand better what they are
> doing
>
> "People should not be encouraged to write or use web browsers for
> their wallet." --> yes and no, please crack the standalone webapp
> above, so it's finally a no when things are done correctly, of course
> there is no story of keys storage inside browsers or online stuff with
> keys
>
> Maybe this can be turned one day into a w3c api like webcrypto
> (window.bitcoin as you sketch)
>
> Le 23/12/2020 à 08:29, monokh via bitcoin-dev a écrit :
>> Thanks for the input Luke.
>>
>> > 1) People should not be encouraged to write or use web browsers for
>> their wallet.
>>
>> Indeed. Holding keys in the browser can be very insecure, however the
>> spec is not limited to this. I will amend to make this clear. The
>> same interface can be used to communicate from a web context or even
>> desktop application with hardware wallets where keys are segregated
>> safely. The prominent hardware wallets already have such an
>> interface. Unfortunately as there has been no standardisation, an
>> application must specifically provide an implementation for each
>> wallet to be compatible.
>>
>> > 2) You may want to look over earlier work in this area.
>>
>> Please share if you have specifics in mind. What has been considered
>> were mainly hardware wallet apis. The requests have been defined such
>> that they would be compatible. I will make references to such
>> considerations in the text. I welcome any feedback on what may be
>> missing or problematic for these providers - something I will also
>> pursue outwith the thread.
>>
>> -monokh
>>
>> On Wed, Dec 23, 2020 at 2:15 AM Luke Dashjr <luke at dashjr.org
>> <mailto:luke at dashjr.org>> wrote:
>>
>> 1) People should not be encouraged to write or use web browsers
>> for their
>> wallet.
>> 2) You may want to look over earlier work in this area.
>>
>> On Tuesday 22 December 2020 14:43:11 monokh via bitcoin-dev wrote:
>> > Hi
>> >
>> > This is a first draft of a BIP we intend to submit. The main
>> intention is
>> > to define a simple interface that wallets and applications can
>> agree on
>> > that would cover the vast majority of use cases. This can
>> enable writing
>> > bitcoin applications (e.g. time lock, multi sig) on the web
>> that can be
>> > seamlessly used with any compatible wallets. We have
>> implementations of
>> > such examples but I don't want to turn this thread into a
>> promotion and
>> > rather focus on the spec.
>> >
>> > Appreciate input from the list. Please share if there are
>> existing efforts,
>> > relevant specs or use cases.
>> >
>> > ------------------------------
>> >
>> > A wallet interface specification for bitcoin applications
>> >
>> > ## Abstract
>> >
>> > This BIP describes an API for Bitcoin wallets and applications as a
>> > standard.
>> >
>> > ## Summary
>> >
>> > Bitcoin wallets should expose their address derivation and signing
>> > functions to external applications. The interface would be
>> expressed as
>> > follows in javascript:
>> >
>> > ```
>> > {
>> > // Wallet Metadata
>> > wallet: {
>> > name: 'Bitcoin Core'
>> > },
>> >
>> > // Request access to the wallet for the current host
>> > async enable: (),
>> >
>> > // Request addresses and signatures from wallet
>> > async request ({ method, params })
>> > }
>> > ```
>> >
>> > In the web context the interface could be exposed at the top
>> level of a
>> > webpage, for example under `window.bitcoin`. However this spec
>> does not
>> > intend to define any standards for how and where the interfaces
>> should be
>> > exposed.
>> >
>> > ## Motivation
>> >
>> > Due to the seldom available APIs exposed by wallets,
>> applications (web or
>> > otherwise) are limited in how they are able to interact.
>> Generally only
>> > simple sends have been available. A more robust API that
>> introduces other
>> > requests will promote richer Bitcoin applications.
>> >
>> > Additionally, wallet APIs have frequently included
>> inconsistencies in their
>> > interfaces and behaviour. This has required applications to
>> build and
>> > maintain a separate client for each wallet, increasing the risk
>> of bugs and
>> > unintended behaviour as well as being a limiting factor for the
>> adoption of
>> > usable bitcoin applications.
>> >
>> > With a standardised wallet API:
>> >
>> > - Wallets have a clear API to implement
>> > - Applications have a clear expectation of wallet interface and
>> behaviour
>> > - Applications become agnostic to the wallet specifics,
>> increasing choice
>> > for users
>> >
>> > If more wallets implement the specification, applications will
>> be developed
>> > more confidently by benefiting from the wallet
>> interoperability. This
>> > creates a positive feedback loop.
>> >
>> > ## Specification
>> >
>> > For simplicity, the interface is defined in the context of web
>> applications
>> > running in the browser (JS) however, they are simple enough to
>> be easily
>> > implemented in other contexts.
>> >
>> > ### General Rules
>> >
>> > - For sensitive functions (e.g. signing), wallet software
>> should always
>> > prompt the user for confirmation
>> >
>> > ### Types
>> >
>> > **UserDeniedError**
>> > An error type indicating that the application's request has
>> been denied by
>> > the user
>> > Type: Error
>> >
>> > **Hex**
>> > Type: String
>> > Example:
>> >
>> `"0000000000000000000a24677957d1e50d70e67c513d220dbe8868c4c3aefc08"`
>> >
>> > **Address**
>> > Address details
>> > Type: Object
>> > Example:
>> >
>> > ```
>> > {
>> > "address": "bc1qn0fqlzamcfuahq6xuujrq08ex7e26agt20gexs",
>> > "publicKey":
>> >
>> "02ad58c0dced71a236f4073c3b6f0ee27dde6fe96978e9a9c9500172e3f1886e5a",
>> > "derivationPath": "84'/1'/0'/0/0"
>> > }
>> > ```
>> >
>> > ### API
>> >
>> > The wallet must implement the following methods.
>> >
>> > **enable**
>> >
>> > The enable call prompts the user for access to the wallet.
>> >
>> > If successful, it resolves to an address (`**Address**` type)
>> of the
>> > wallet. Typically the first external address to be used as an
>> identity.
>> >
>> > **`UserDeniedError`** will be thrown if the request is rejected.
>> >
>> > **request**
>> >
>> > The request method must take one parameter in the following format:
>> >
>> > ```
>> > {
>> > "method": "wallet_methodName",
>> > "params": ["foo", "bar", "baz"]
>> > }
>> > ```
>> >
>> > For a list of mandatory methods see Table
>> >
>> > The wallet should reject request calls unless `enable` has been
>> resolved.
>> >
>> > Sensitive requests that involve signing should always prompt
>> the user for
>> > confirmation
>> >
>> > On success the request should resolve to the response as
>> defined in the
>> > method table.
>> >
>> > **`UserDeniedError`** will be thrown if the request is rejected.
>> >
>> > **Mandatory methods**
>> >
>> > method: `wallet_getAddresses` params: [`index = 0, numAddresses
>> = 1, change
>> > = false`]
>> > return: `[ Address ]`
>> > error: UserDeniedError
>> >
>> > method: `wallet_signMessage` params: `[ message, address ]`
>> > return: Signature `Hex`
>> > error: UserDeniedError
>> >
>> > method: `wallet_signPSBT` params: `[ [psbtBase64, inputIndex,
>> address] ]`
>> > return: `psbtBase64`
>> > error: UserDeniedError
>> >
>> > method: `wallet_getConnectedNetwork` params: `[]`
>> > return: Network object `mainnet` | `testnet` | `regetst`
>> > error: UserDeniedError
>> >
>> > ## Rationale
>> >
>> > The purpose of the API is to expose a set of commonly used wallet
>> > operations. In addition, it should be flexible enough to serve
>> for other
>> > requests such as node RPC calls.
>> >
>> > **Why is there a singular request call instead of named methods?**
>> > The transport layer for the requests cannot be assumed,
>> therefore it is
>> > much more flexible to instead define an abstract format.
>> >
>> > **Why are the mandatory methods so primitive? Where is getBalance,
>> > getUtxos, ... ?**
>> > A wallet need not worry about providing every possible scenario
>> for usage.
>> > The primitives of keys and signing can expose enough to
>> applications to do
>> > the rest. Applications should have flexibility in how they
>> implement these
>> > functions. It is the role of a library rather than the wallet.
>> >
>> > ## Security Implications
>> >
>> > Great care should be taken when exposing wallet functionality
>> externally as
>> > the security and privacy of the user is at risk.
>> >
>> > ### Signing
>> >
>> > Operations that trigger signing using private keys should be
>> guarded behind
>> > confirmation screens where the user is fully aware of the
>> nature of the
>> > transaction. In the example of a PSBT signature request, the
>> outputs, the
>> > inputs and which key is being used should be clearly marked.
>> >
>> > ### Privacy
>> >
>> > Some api methods expose metadata about the user, such as public
>> keys.
>> > Depending on how privacy focused the wallet intends to be, the
>> wallet could
>> > protect these behind a confirmation. Commonly the wallet just
>> needs to give
>> > the origin access to all of its public keys, however it could
>> also allow
>> > the option to expose only selected derivation paths.
>> >
>> > -monokh
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> --
> Sophia-Antipolis, France
> LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
> Move your coins by yourself (browser version): https://peersm.com/wallet
> Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
> Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
> Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
> Get the torrent dynamic blocklist: http://peersm.com/getblocklist
> Check the 10 M passwords list: http://peersm.com/findmyass
> Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
> Peersm : http://www.peersm.com
> torrent-live: https://github.com/Ayms/torrent-live
> node-Tor : https://www.github.com/Ayms/node-Tor
> GitHub : https://www.github.com/Ayms
--
Sophia-Antipolis, France
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20201225/4362e66c/attachment-0001.html>

2023-06-07 18:25:13

- reply

📅 Original date posted:2020-06-08
📝 Original message:Le 08/06/2020 à 06:56, ZmnSCPxj via bitcoin-dev a écrit :
> Running both Bitcoin and Lightning nodes on clearnet automatically links them, making them easier to attack, whereas running Lightning on Tor does not.
> Of course, they could still be linked by onchain transaction monitoring, but at least this increases the effort to attack, hopefully it becomes marginally less desirable to attack you.
Or makes it easier in fact, correcting what I said in my previous
answer, stating a "yes" for a mixed bitcoin and/or LN node in clearnet
and Tor, with or without different IPs, it's probably not difficult for
the Tor attacker to identify you (for example pinging the nodes with a
new received tx to see who has it in mempool)
Similar to "Deanonymizing the VPN peers"
https://github.com/Ayms/torrent-live, this is not public but the method
uses the clearnet/VPN "mixity" and unexpectedly the more you try to hide
the better you can get deanonymized
The conclusion is always the same: do not use the Tor network for
services it is not designed for

2023-06-07 18:25:12

- reply

📅 Original date posted:2020-06-05
📝 Original message:Hi,
As far as I understand your answer is "let's try to use what exists",
this is not what I am proposing and not the Tor network, no "standard"
exit nodes, different hidden services, decentralized anonymizer network
unlike the Tor network, nodes are anonymizing themselves
Comments below, please let me know what is unclear in the description of
the project so I can modify it because all the time I get the impression
that it is mixed with the Tor network while it just has a very little to
do with it, and I don't get that the simple principle of communicating
between nodes using the Tor protocol without RDV points is never considered
Regards,
Le 05/06/2020 à 13:44, ZmnSCPxj a écrit :
> Good morning Aymeric,
>
>> The issue each time there are discussions/research linking to Tor is that it is biased since the beginning because based on a wrong postulate: using the Tor network
>>
> Well, in the interest of using the wrong tool for a highly important job, let me present this thought:
Then for an important job people should use the right tool...
>
> * The Tor network is weakened due to its dependence on a limited set of exit nodes.
And centralized structure, limited set of nodes to make it short, for
some (or a lot) misbehaving, not designed for bitcoin, nothing prevents
bitcoin from operating its own anonymizer system, which I am proposing
> * "Direct", within-Tor rendezvous points are good, i.e. Tor hidden services.
Good to a certain extent... if you want to hide that you are operating a
bitcoin node you can use RDV points (ie hidden services) but if you
don't care you just connect anonymized circuits between bitcoin nodes,
this is more "direct" and does not exist in the Tor network, this
includes light clients that can act as relays also
> * Thus, there is no issue with Tor-to-Tor or clearnet-to-clearnet connections, the issue is with Tor-to-clearnet connections.
There are plenty of Tor-to-Tor issues, not theoretical but in the real
world, "Tor-to-clearnet" can be done outside of the Tor network, ie the
bitcoin network
> * Of course, no miner is going to run over Tor because latency, so all the miners will be on clearnet.
Probably, again I am not proposing a remake of the Tor network, I don't
see the use for a miner to hide (neither for a bitcoin node to use RDV
points), but they can be part of the global anonymized system, please
see below
> * So make your own bridge between Tor and clearnet.
> * Run two fullnodes on your computer (with sufficient ingenuity, you can probably share their block storages, or make one pruning).
> * One fullnode is on the public network but runs in `blocksonly` so it does not propagate any transactions (which might be attached to your public IP).
> * The other fullnode is on the Tor network and has an `-addnode` to the public-network node via `localhost`, which I assume is very hard for an eclipse attacker to get at.
> * Use the Tor-fullnode to propagate your transactions.
Yes but one full node should be able to do this alone, ie implement both
interfaces, like miners and everybody in fact (or Peersm bridges with
bittorrent if you look at the history of the project)
>
> Of course, the eclipse attacker can still attack all Tor exit nodes and block outgoing transaction traffic to perform eclipse attacks.
> And if you decide to propagate transactions to the public-network node then you pretty much lose your privacy there.
Please see the convergence link, it's not based on the assumption that
"the more you are the better you can hide and the lesser you can get
attacked", this does not work at all, it's based on the assumption that
even with a reduced set of peers it becomes very difficult to know who
is doing what and whom is talking to whom, the concept of
exiting/bridging to clearnet(s) is not clearly detailed in this version
but appears on the drawings

2023-06-07 18:25:11

- reply

📅 Original date posted:2020-06-05
📝 Original message:Le 04/06/2020 à 04:58, ZmnSCPxj via bitcoin-dev a écrit :
>> [Tor is tricky](https://arxiv.org/abs/1410.6079) too
> Since the issue here is that eclipsing of Bitcoin nodes is risky, it strikes me that a mitigation would be to run your Bitcoin fullnode on clearnet while running your Lightning node over Tor.
> Eclipsing the Lightning node (but not the Bitcoin fullnode it depends on) "only" loses you the ability to pay, receive, or route (and thereby earn forwarding fees), but as long as your blockchain view is clear, it should be fine.
>
> Of course, the Lightning node could still be correlated with the Bitcoin node when transactions are broadcast with the attached Bitcoin node (as noted in the paper).
> Instead the Lightning node should probably connect, over Tor, to some random Bitcoin fullnodes / Electrum servers and broadcast txes to them.
>
> And this seems to tie with what you propose: that the LN node should use a different view-fullnode from the broadcast-fullnode.
>
The issue each time there are discussions/research linking to Tor is
that it is biased since the beginning because based on a wrong
postulate: using the Tor network
I will not elaborate on this again, it's an obvious very bad idea to use
the Tor network for bitcoin
It's not a bad idea to use the Tor protocol with no story of exit nodes
and hidden services, linking again to:
https://github.com/Ayms/node-Tor#phase-4-and-phase-5
And new link: http://www.peersm.com/Convergence-2020.pdf "A universal
and generic architecture to anonymize any application or protocol and
turn it into an independent decentralized p2p network inside browsers
and servers, with browsers acting as servers"
LN and bitcoin nodes would be relays and/or RDV points and/or clients
and serving parties, some Tor network nodes could be used in the middle
also (relays only) but in any case sybils/eclipse attacks become much
more difficult to perform (or unlikely depending on how the peer
discovery system is designed)
bitcoin | node-Tor |bitcoin and LN.pipe(node-Tor)
Then question for possible future tests: is there a simple way to pipe
the bitcoin protocol via stdin/stdout? (the socks interface could be
used but we already saw that it did raise issues)
--
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200605/c512ceb6/attachment.html>

2023-06-07 18:23:05

- reply

📅 Original date posted:2020-02-25
📝 Original message:Please see the current status here:
https://github.com/Ayms/node-Tor#phases-and-funding
Quick reminder: this is a javascript implementation of the Tor protocol
inside nodes and browsers
Phase 4 (evented pipes) has been developped (self funded) but is not
fully tested/released, however the doc is here:
https://github.com/Ayms/node-Tor/blob/master/docs/README.md, it allows
to simply anonymize any protocol piping it to the Tor protocol
We were about to implement phase 5 (elliptic crypto, Tor v3 features and
WebRTC) but are running out of funding, while we have self funded the
vast majority of this project since 2012 we can't continue (thanks to
NLnet for supporting phases 1 to 3) and are looking for funding to
complete this work (cf above link)
The timing is supposed to be now because restarting such a project in
months or years is not trivial and despite of the huge efforts for the
refactoring/update/cleaning of the initial code and split into modules
it's probably still difficult to use/integrate/modify (see
https://github.com/Ayms/node-Tor/issues/14), it will become quite easy
if the project goes to its targeted phase
The code is subtle and minimal, it represents only 1MB browserified not
minified, so 500kB minified, which is quite small for what it does with
zero external dependencies, redevelopping everything from scratch would
be long and difficult
Some examples of what node-Tor does (as nodes or inside browsers using
WebSockets/WebRTC/XHR):
http.pipe(parser).pipe(gzip).pipe(tls).pipe(node-Tor)
ipfs.pipe(node-Tor)
webtorrent.pipe(node-Tor)
bitcoin | node-Tor | bitcoin (via stdin/stdout or using IPC)
Of course the Tor protocol itself might not be enough and each project
might have to design the full anonymization system (peer discovery,
introduction, etc) but they can rely on node-Tor to implement the Tor
protocol (not to be misunderstood again with the Tor network)
It does implement direct p2p via the Tor protocol or via RendezVous
(RDV) points using also Tor protocol hops to connect to them, the peers
advertise what they have or do using a hash to the RDV points they are
connected to, please see
https://github.com/Ayms/node-Tor#phase-4-and-phase-5
Example: by convention a bitcoin node could advertise a hash of "Satoshi
Nakamoto" to tell it is a bitcoin node, then bitcoin nodes will connect
to each others via RDV points or several Tor protocol hops requesting
this hash, they can also connect directly via several hops for well
known bitcoin nodes that don't need to hide themselves but want to hide
to whom they are connected to, which can be wallets too, for example to
hide who originated a transaction
Since peers are implementing both direct p2p and RDV functions (both via
Tor protocol hops), and can extend to other peers as peers or RDV points
again, it becomes difficult to understand who is doing what and how many
hops finally are used between the peers (suggested setting for p2p is 2
hops instead of 3 for a Tor protocol circuit, knowing that the number of
hops can extend via RDV points)
This is the current design and can of course be adapted
It would look logical that this techno is integrated natively one day
inside browsers, again it must not be misunderstood with what the Tor
Browser is doing (with many specific features inside the browser itself)
and is not a replacement for it, this is different but could be used
also by the Tor network with browsers acting as real Tor nodes (a bit à
la Snowflake but not only relaying messages via WebRTC, implementing the
Tor protocol inside browsers), or uproxy-like for those that remember it
--
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms

2023-06-07 18:21:46

- reply

📅 Original date posted:2019-11-18
📝 Original message:So I must ask the question: what is the rational for a bitcoin node to
be hidden? ie to use RDV points like hidden services?
For me the rational for bitcoin is to anonymize communications between
nodes and/or clients, typically who sent this tx, not to hide that you
are operating a bitcoin node, then back to what I sent earlier
I tried to find the explaination in the bitcoin docs before sending this
post but did not find any, except referring to the fact that bitcoin
communications should be anonymized, which does not need RDV points
Another question is why to mimic the Tor network for RDV points with
.onion addresses?
The answers might be "this is what exists and we have no other way to do
it", I am proposing another way
I will not repeat what I wrote before, but I am operating node-Tor nodes
inside the Tor network since ~10 years, the js implementation of the Tor
protocol had not been easy (as well as putting everything inside
browsers) but I consider that the most difficult had been to handle all
unexpected events that happen inside the Tor network, even after
selecting carefully the nodes and testing them, this is a mess, nodes
are coming in, going out, responding, not responding, responding
correcltly or all of a sudden responding shxtty stuff, I was even
considering to get the entropy for the js prng from all of those
unexpected events
I don't think that any other people except the Tor project team know
this, a good example is http://peersm.com/peersm2, see the logs (destroy
and destroy and destroy) and how long it takes to establish 6 circuits
knowing that our server is the first one in the path (eliminating one
dubious node among 3)
I am not "promoting" this, everything is open source now and it is made
to be used, and I think that my proposal has some interest, using the
Tor network for bitcoin is a very bad idea, for security and
performances reasons
Le 18/11/2019 à 17:44, Carl Dong via bitcoin-dev a écrit :
> Hi Mr. Lee Chiffre,
>
> I have been working on an implementation of addrv2 (BIP-155). Is this what you meant by I2P and Torv3 address support?
>
> My WIP pull request: https://github.com/bitcoin/bitcoin/pull/16748
> Merged BIP: https://github.com/bitcoin/bips/blob/master/bip-0155.mediawiki
> Ongoing discussion: https://github.com/bitcoin/bips/pull/766
> Note: Even though the pull request to the BIP repo is merged, we’re still discussing some details in the pull request thread and will amend the BIP once it seems like we’ve worked out all the kinks
>
> Review and further discussion is very much welcome! :-)
>
> Cheers,
> Carl Dong
> contact at carldong.me
> "I fight for the users"
>
>> On Nov 16, 2019, at 11:33 PM, Mr. Lee Chiffre via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>
>> Right now bitcoin client core supports use of tor hidden service. It
>> supports v2 hidden service. I am in progress of creating a new bitcoin
>> node which will use v3 hidden service instead of v2. I am looking at
>> bitcoin core and btcd to use. Do any of these or current node software
>> support the v3 onion addresses for the node address? What about I2P
>> addresses? If not what will it take to get it to support the longer
>> addresses that is used by i2p and tor v3?
>>
>>
>> --
>> lee.chiffre at secmail.pro
>> PGP 97F0C3AE985A191DA0556BCAA82529E2025BDE35
>>
>> _______________________________________________
>> 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
--
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms

2023-06-07 18:21:45

- reply

📅 Original date posted:2019-11-18
📝 Original message:As I briefly sketched here before I think that a better long term
solution would be to link the bitcoin traffic with something like
node-Tor (https://github.com/Ayms/node-Tor)
Much more light (the whole code not minified is only ~1MB), not using
tons of libraries prone to security/maintenance issues, easy to
use/configure/maintain and you don't need the (heavy/complicate) onions
RDV concepts and addresses, which in addition is useless for bitcoin
As simple as a duplex stream *bitcoin.pipe(node-Tor)* inside servers or
browsers (difficult to imagine full nodes and the blocks inside browsers
but why not one day, so for light clients probably implementing part of
the bitcoin protocol like https://peersm.com/wallet, for now it's a
standalone offline webapp but of course it would be interesting to
connect it in a secure way to bitcoin nodes to retrieve info from the
utxo set and send txs for example since it's not obvious for users to
create their txs in its current form)
This would be a separate network using the Tor protocol over TCP,
WebSockets and WebRTC, making it possible also for browsers to relay the
traffic, probably the nodes discovery (to get the keys) could be linked
to the bitcoin peer discovery system (we just have to add the onion key
to the peer profile, and maybe long term id key), anyway that's simple
to setup, and probably for a p2p network 2 hops will be enough
I really don't think that the Tor network is designed and adapted to
support bitcoin nodes, using it for something else than browsing is just
a workaround and I would be surprised that the Tor project team
contradicts this and/or encourage this use
Le 18/11/2019 à 00:42, Matt Corallo via bitcoin-dev a écrit :
> There is effort ongoing to upgrade the Bitcoin P2P protocol to support other address types, including onion v3. There are various posts on this ML under the title “addrv2”. Further review and contributions to that effort is, as always, welcome.
>
>> On Nov 17, 2019, at 00:05, Mr. Lee Chiffre via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> Right now bitcoin client core supports use of tor hidden service. It
>> supports v2 hidden service. I am in progress of creating a new bitcoin
>> node which will use v3 hidden service instead of v2. I am looking at
>> bitcoin core and btcd to use. Do any of these or current node software
>> support the v3 onion addresses for the node address? What about I2P
>> addresses? If not what will it take to get it to support the longer
>> addresses that is used by i2p and tor v3?
>>
>>
>> --
>> lee.chiffre at secmail.pro
>> PGP 97F0C3AE985A191DA0556BCAA82529E2025BDE35
>>
>> _______________________________________________
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191118/d8a62908/attachment.html>

2023-06-07 18:21:41

- reply

📅 Original date posted:2019-11-09
📝 Original message:Do not find excuses (and vague statements or technical bulls) and learn,
you don't know what you are talking about and don't get the global
picture, we don't care about the Tor network and they don't care about
others neither do they care that they increase their network, so indeed
let's stop this discussion
Just replying here (for the last time) because expecting more clever
thoughts about what I wrote, maybe one day... but for sure something
like this will happen in the future
Le 09/11/2019 à 21:21, LORD HIS EXCELLENCY JAMES HRMH a écrit :
> We do not need to discuss this back and forward publickly. I am not
> concerned whether Tors seems or is much centralised or not, it is not
> the concern of m statements, and it required directory nodes of which
> there are several and we could discuss the operation of its nodes and
> infrastructure all day, even comparing directory nodes to seed nodes.
> The fact is that browsing is the most common publicly understood usage
> of Tor but like with and without Tor the internet provides many services.
>
> It seems you have misunderstood the reason I reference making so many
> Tor nodes also but do not concern I will no reiterate. Also, whether
> Tor can provide for the bandwidth and connectivity required for
> Bitcoin you have not tested and provide only your opinion, where it
> seems that actually it can. The matter is that Tor carries Bitcoin
> traffic quite easily now and in fact as there is more Bitcoin traffic
> likely the Tor capacity increases in some proportion.
>
> Also, socks proxy is not a door in, it is a door out, do you realise
> but just works at a different network layer to HTTP proxy which works
> at layer 7 of the OSI model and Socks a bit lower?
>
> I have had some communication difficulty before where the native
> language is not English and although the communication happens in
> native English the though is still being formed in another language
> and so the presentation of the thought is not clear to the English
> presentation. Even if not this I do not consider wrong just that we
> write to consider not the same thing.
>
> Good day.
>
> Regards,
> LORD HIS EXCELLENCY JAMES HRMH
>
>
> ------------------------------------------------------------------------
> *From:* Aymeric Vitte <vitteaymeric at gmail.com>
> *Sent:* Sunday, 10 November 2019 6:33 AM
> *To:* LORD HIS EXCELLENCY JAMES HRMH <willtech at live.com.au>; Bitcoin
> Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org>; Luke
> Dashjr <luke at dashjr.org>
> *Cc:* security at bitcoincore.org <security at bitcoincore.org>
> *Subject:* Re: [bitcoin-dev] CVE-2017-18350 disclosure
>
>
> ???
>
>
> Well, you obviously don't know what you are talking about and did not
> even consider reading correctly what I wrote, neither to read node-Tor
>
>
> What you are saying here is quite trivial, typical of people thinking
> that the Tor network will solve everything and is not centralized (but
> you seem unsure about it), that's not the case, it's completely wrong
> and the "normal" use of the Tor network is for browsing only,
> basically the Tor network is still the same since years: 1000 guards,
> 1000 relays, 1000 exits (so not "hundreds", happier, and there are of
> course intersections between them, knowing that they are the supposed
> working nodes as tested by node-Tor), quite small at the end with
> finally many misbehaving nodes among the 3000 set, not at all able or
> willing to handle bitcoin nodes load
>
>
> Using bitcoin with the Tor network is absurd, using socks proxy with
> bitcoin is absurd too (I don't get the comparison with a http proxy,
> nothing to do), except if limited to a local use, ie you socks proxy
> inside your device, for example to pipe to node-Tor, but this remains
> as a whole dangerous if the local proxy has been hacked, as we could
> see recently with malware Tor sw being used by people
>
>
> Using the Tor protocol for bitcoin is not absurd at all (do you
> understand the difference?) + browsers, webRTC, etc I will not repeat
> what I wrote
>
>
> Please do some readings or consider at least what I sent, or ask
> questions if what I am saying is unclear for you
>
>
> But from my standpoint the discussion on this list is not about
> explaining all of this that is probably well known by everybody but
> what can/could be next to anonymize/help anonymizing bitcoin
>
> when required and make it a real p2p network
>
>
> Unfortunately I am afraid that we get moderated here because that's
> not the place to give basic lessons about Tor that you don't know
>
>
> Le 09/11/2019 à 12:42, LORD HIS EXCELLENCY JAMES HRMH a écrit :
>> Socks proxies have their use in controlled gateway infrastructure and
>> is a relevant feature for any software required to operate behind a
>> secure network boundary and allows for UDP connectivity (whether it
>> is utilised in any particular application) which a HTTP proxy does not.
>>
>> You are obviously not well abreast of the Tor project, regardless of
>> whether it seems centralised, whether it is or it isn't, the Tor
>> project is to allow anonymity and connection privacy. For this it
>> works very well and there seem to be hundreds of known Tor nodes, to
>> be known they are not isolated and are connected.
>>
>> Even if an exit node performs all logging it is only aware of the
>> node one hop up but the originator is higher still. In the case where
>> we perform a Tor cluster and make hundreds of guard, middle and exit
>> nodes we still cannot with absolute certainty say that the connecting
>> node is the originator and, the eventual Bitcoin node is still
>> unaware of the originator IP which is the primary objective.
>> Otherwise, can you hide your IP from your ISP would be a better goal?
>>
>> You may prefer to familiarise yourself first with the history of Tor,
>> even a brief from [WikipediaTor_(anonymity_network)
>> <https://en.wikipedia.org/wiki/Tor_(anonymity_network)>](https://en.wikipedia.org/wiki/Tor_(anonymity_network))
>> and consider some of the possible uses, and consider how its
>> implementation benefits the privacy and anonymity of Bitcoin in
>> public where it is allowed in many countries; Tor is just as useful
>> in countries where Bitcoin is allowed to hide from third-parties. You
>> may also enjoy an example of activating Bitcoin Cores Tor
>> implementation: [How can I setup Bitcoin to be anonymous with
>> Tor?](https://bitcoin.stackexchange.com/questions/70069/how-can-i-setup-bitcoin-to-be-anonymous-with-tor/70070#70070)
>> <https://en.wikipedia.org/wiki/Tor_(anonymity_network)>
>>
>> Tor (anonymity network) - Wikipedia
>> <https://en.wikipedia.org/wiki/Tor_(anonymity_network)>
>> Tor is free and open-source software for enabling anonymous
>> communication.The name is derived from an acronym for the original
>> software project name "The Onion Router". Tor directs Internet
>> traffic through a free, worldwide, volunteer overlay network
>> consisting of more than seven thousand relays to conceal a user's
>> location and usage from anyone conducting network surveillance or
>> traffic analysis.
>> en.wikipedia.org
>>
>>
>> <https://bitcoin.stackexchange.com/questions/70069/how-can-i-setup-bitcoin-to-be-anonymous-with-tor/70070#70070>
>>
>> bitcoind - How can I setup Bitcoin to be anonymous with Tor? -
>> Bitcoin Stack Exchange
>> <https://bitcoin.stackexchange.com/questions/70069/how-can-i-setup-bitcoin-to-be-anonymous-with-tor/70070#70070>
>> Bitcoin is billed as many things, among them its anonymity is highly
>> regarded. While it is true that a transaction does not identify a
>> user or wallet, recent news shows that there is the potential ...
>> bitcoin.stackexchange.com
>>
>>
>>
>> There should be no rational consideration that gives rise to reducing
>> Tor connectivity, possibly v3 integration will be coming along.
>>
>> Regards,
>> LORD HIS EXCELLENCY JAMES HRMH
>>
>>
>> ------------------------------------------------------------------------
>> *From:* Aymeric Vitte <vitteaymeric at gmail.com>
>> <mailto:vitteaymeric at gmail.com>
>> *Sent:* Saturday, 9 November 2019 6:40 AM
>> *To:* LORD HIS EXCELLENCY JAMES HRMH <willtech at live.com.au>
>> <mailto:willtech at live.com.au>; Bitcoin Protocol Discussion
>> <bitcoin-dev at lists.linuxfoundation.org>
>> <mailto:bitcoin-dev at lists.linuxfoundation.org>; Luke Dashjr
>> <luke at dashjr.org> <mailto:luke at dashjr.org>
>> *Cc:* security at bitcoincore.org <mailto:security at bitcoincore.org>
>> <security at bitcoincore.org> <mailto:security at bitcoincore.org>
>> *Subject:* Re: [bitcoin-dev] CVE-2017-18350 disclosure
>>
>>
>> Sure, but what is questionable here is the use of SOCKS proxy, for
>> Tor I think as the main purpose, making it dangerous for the "whole
>> bitcoin world" while it's something like of zero interest/use (or
>> please let me know what it is beside Tor)
>>
>> The Tor network is very centralized and not designed at all to handle
>> p2p networks (which bitcoin is still not), it is designed to be used
>> via the Tor Browser to browse the web and to hide web servers, not
>> bitcoin nodes, and there are a lot of misbehaving/dangerous nodes
>> there, there is no encryption in bitcoin protocol, an exit node can
>> fake whatever it likes, this seems to be a use case as far as I can
>> see, but even if the initiator is configured to connect to a hidden
>> bitcoin node, I don't see the point
>>
>> I have advertised recentlty the open sourcing of node-Tor
>> (https://github.com/Ayms/node-Tor) here
>>
>> This one is designed for p2p, not over the Tor network but using the
>> Tor protocol, as simple as bitcoin.pipe(node-Tor), or <any
>> protocol>.pipe(node-Tor), which is the finality of the project as far
>> as I see it since years (maybe see
>> http://www.peersm.com/Convergence.pdf
>> <http://www.peersm.com/Convergence.pdf> even if I would modify some
>> parts now)
>>
>> Inside servers or browsers acting as servers also (WebRTC or
>> WebSockets), bitcoin peers (servers/browsers) relaying the bitcoin
>> anonymized protocol using the Tor protocol (and not the Tor network)
>> between each others, there is no story of exit nodes here and rdv
>> points would not apply for bitcoin use, this "just" adds the internal
>> missing encryption and anonymity layer to the bitcoin protocol
>>
>> Personally I would remove the socks proxy interface from bitcoin
>> core, independently of Tor this can be misused too and offers
>> absolutely zero security
>>
>>
>> Le 08/11/2019 à 18:03, LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev
>> a écrit :
>>> It goes without saying in that all privately known CVE should be
>>> handled so professionally but, that is, well done team.
>>>
>>> Regards,
>>> LORD HIS EXCELLENCY JAMES HRMH
>>>
>>>
>>> ------------------------------------------------------------------------
>>> *From:* bitcoin-dev-bounces at lists.linuxfoundation.org
>>> <mailto:bitcoin-dev-bounces at lists.linuxfoundation.org>
>>> <bitcoin-dev-bounces at lists.linuxfoundation.org>
>>> <mailto:bitcoin-dev-bounces at lists.linuxfoundation.org> on behalf of
>>> Luke Dashjr via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
>>> <mailto:bitcoin-dev at lists.linuxfoundation.org>
>>> *Sent:* Saturday, 9 November 2019 2:07 AM
>>> *To:* bitcoin-dev at lists.linuxfoundation.org
>>> <mailto:bitcoin-dev at lists.linuxfoundation.org>
>>> <bitcoin-dev at lists.linuxfoundation.org>
>>> <mailto:bitcoin-dev at lists.linuxfoundation.org>
>>> *Cc:* security at bitcoincore.org <mailto:security at bitcoincore.org>
>>> <security at bitcoincore.org> <mailto:security at bitcoincore.org>
>>> *Subject:* [bitcoin-dev] CVE-2017-18350 disclosure
>>>
>>> CVE-2017-18350 is a buffer overflow vulnerability which allows a
>>> malicious
>>> SOCKS proxy server to overwrite the program stack on systems with a
>>> signed
>>> `char` type (including common 32-bit and 64-bit x86 PCs).
>>>
>>> The vulnerability was introduced in
>>> 60a87bce873ce1f76a80b7b8546e83a0cd4e07a5
>>> (SOCKS5 support) and first released in Bitcoin Core v0.7.0rc1 in
>>> 2012 Aug 27.
>>> A fix was hidden in d90a00eabed0f3f1acea4834ad489484d0012372
>>> ("Improve and
>>> document SOCKS code") released in v0.15.1, 2017 Nov 6.
>>>
>>> To be vulnerable, the node must be configured to use such a
>>> malicious proxy in
>>> the first place. Note that using *any* proxy over an insecure
>>> network (such
>>> as the Internet) is potentially a vulnerability since the connection
>>> could be
>>> intercepted for such a purpose.
>>>
>>> Upon a connection request from the node, the malicious proxy would
>>> respond
>>> with an acknowledgement of a different target domain name than the one
>>> requested. Normally this acknowledgement is entirely ignored, but if
>>> the
>>> length uses the high bit (ie, a length 128-255 inclusive), it will be
>>> interpreted by vulnerable versions as a negative number instead.
>>> When the
>>> negative number is passed to the recv() system call to read the
>>> domain name,
>>> it is converted back to an unsigned/positive number, but at a much
>>> wider size
>>> (typically 32-bit), resulting in an effectively infinite read into
>>> and beyond
>>> the 256-byte dummy stack buffer.
>>>
>>> To fix this vulnerability, the dummy buffer was changed to an
>>> explicitly
>>> unsigned data type, avoiding the conversion to/from a negative number.
>>>
>>> Credit goes to practicalswift (https://twitter.com/practicalswift) for
>>> discovering and providing the initial fix for the vulnerability, and
>>> Wladimir
>>> J. van der Laan for a disguised version of the fix as well as
>>> general cleanup
>>> to the at-risk code.
>>>
>>> Timeline:
>>> - 2012-04-01: Vulnerability introduced in PR #1141.
>>> - 2012-05-08: Vulnerability merged to master git repository.
>>> - 2012-08-27: Vulnerability published in v0.7.0rc1.
>>> - 2012-09-17: Vulnerability released in v0.7.0.
>>> ...
>>> - 2017-09-21: practicalswift discloses vulnerability to security team.
>>> - 2017-09-23: Wladimir opens PR #11397 to quietly fix vulernability.
>>> - 2017-09-27: Fix merged to master git repository.
>>> - 2017-10-18: Fix merged to 0.15 git repository.
>>> - 2017-11-04: Fix published in v0.15.1rc1.
>>> - 2017-11-09: Fix released in v0.15.1.
>>> ...
>>> - 2019-06-22: Vulnerability existence disclosed to bitcoin-dev ML.
>>> - 2019-11-08: Vulnerability details disclosure to bitcoin-dev ML.
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> <mailto:bitcoin-dev at lists.linuxfoundation.org>
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191110/51ff57f0/attachment-0001.html>

2023-06-07 18:21:40

- reply

📅 Original date posted:2019-11-09
📝 Original message:???
Well, you obviously don't know what you are talking about and did not
even consider reading correctly what I wrote, neither to read node-Tor
What you are saying here is quite trivial, typical of people thinking
that the Tor network will solve everything and is not centralized (but
you seem unsure about it), that's not the case, it's completely wrong
and the "normal" use of the Tor network is for browsing only, basically
the Tor network is still the same since years: 1000 guards, 1000 relays,
1000 exits (so not "hundreds", happier, and there are of course
intersections between them, knowing that they are the supposed working
nodes as tested by node-Tor), quite small at the end with finally many
misbehaving nodes among the 3000 set, not at all able or willing to
handle bitcoin nodes load
Using bitcoin with the Tor network is absurd, using socks proxy with
bitcoin is absurd too (I don't get the comparison with a http proxy,
nothing to do), except if limited to a local use, ie you socks proxy
inside your device, for example to pipe to node-Tor, but this remains as
a whole dangerous if the local proxy has been hacked, as we could see
recently with malware Tor sw being used by people
Using the Tor protocol for bitcoin is not absurd at all (do you
understand the difference?) + browsers, webRTC, etc I will not repeat
what I wrote
Please do some readings or consider at least what I sent, or ask
questions if what I am saying is unclear for you
But from my standpoint the discussion on this list is not about
explaining all of this that is probably well known by everybody but what
can/could be next to anonymize/help anonymizing bitcoin
when required and make it a real p2p network
Unfortunately I am afraid that we get moderated here because that's not
the place to give basic lessons about Tor that you don't know
Le 09/11/2019 à 12:42, LORD HIS EXCELLENCY JAMES HRMH a écrit :
> Socks proxies have their use in controlled gateway infrastructure and
> is a relevant feature for any software required to operate behind a
> secure network boundary and allows for UDP connectivity (whether it is
> utilised in any particular application) which a HTTP proxy does not.
>
> You are obviously not well abreast of the Tor project, regardless of
> whether it seems centralised, whether it is or it isn't, the Tor
> project is to allow anonymity and connection privacy. For this it
> works very well and there seem to be hundreds of known Tor nodes, to
> be known they are not isolated and are connected.
>
> Even if an exit node performs all logging it is only aware of the node
> one hop up but the originator is higher still. In the case where we
> perform a Tor cluster and make hundreds of guard, middle and exit
> nodes we still cannot with absolute certainty say that the connecting
> node is the originator and, the eventual Bitcoin node is still unaware
> of the originator IP which is the primary objective. Otherwise, can
> you hide your IP from your ISP would be a better goal?
>
> You may prefer to familiarise yourself first with the history of Tor,
> even a brief from [WikipediaTor_(anonymity_network)
> <https://en.wikipedia.org/wiki/Tor_(anonymity_network)>](https://en.wikipedia.org/wiki/Tor_(anonymity_network))
> and consider some of the possible uses, and consider how its
> implementation benefits the privacy and anonymity of Bitcoin in public
> where it is allowed in many countries; Tor is just as useful in
> countries where Bitcoin is allowed to hide from third-parties. You may
> also enjoy an example of activating Bitcoin Cores Tor implementation:
> [How can I setup Bitcoin to be anonymous with
> Tor?](https://bitcoin.stackexchange.com/questions/70069/how-can-i-setup-bitcoin-to-be-anonymous-with-tor/70070#70070)
> <https://en.wikipedia.org/wiki/Tor_(anonymity_network)>
>
> Tor (anonymity network) - Wikipedia
> <https://en.wikipedia.org/wiki/Tor_(anonymity_network)>
> Tor is free and open-source software for enabling anonymous
> communication.The name is derived from an acronym for the original
> software project name "The Onion Router". Tor directs Internet traffic
> through a free, worldwide, volunteer overlay network consisting of
> more than seven thousand relays to conceal a user's location and usage
> from anyone conducting network surveillance or traffic analysis.
> en.wikipedia.org
>
>
> <https://bitcoin.stackexchange.com/questions/70069/how-can-i-setup-bitcoin-to-be-anonymous-with-tor/70070#70070>
>
> bitcoind - How can I setup Bitcoin to be anonymous with Tor? - Bitcoin
> Stack Exchange
> <https://bitcoin.stackexchange.com/questions/70069/how-can-i-setup-bitcoin-to-be-anonymous-with-tor/70070#70070>
> Bitcoin is billed as many things, among them its anonymity is highly
> regarded. While it is true that a transaction does not identify a user
> or wallet, recent news shows that there is the potential ...
> bitcoin.stackexchange.com
>
>
>
> There should be no rational consideration that gives rise to reducing
> Tor connectivity, possibly v3 integration will be coming along.
>
> Regards,
> LORD HIS EXCELLENCY JAMES HRMH
>
>
> ------------------------------------------------------------------------
> *From:* Aymeric Vitte <vitteaymeric at gmail.com>
> *Sent:* Saturday, 9 November 2019 6:40 AM
> *To:* LORD HIS EXCELLENCY JAMES HRMH <willtech at live.com.au>; Bitcoin
> Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org>; Luke
> Dashjr <luke at dashjr.org>
> *Cc:* security at bitcoincore.org <security at bitcoincore.org>
> *Subject:* Re: [bitcoin-dev] CVE-2017-18350 disclosure
>
>
> Sure, but what is questionable here is the use of SOCKS proxy, for Tor
> I think as the main purpose, making it dangerous for the "whole
> bitcoin world" while it's something like of zero interest/use (or
> please let me know what it is beside Tor)
>
> The Tor network is very centralized and not designed at all to handle
> p2p networks (which bitcoin is still not), it is designed to be used
> via the Tor Browser to browse the web and to hide web servers, not
> bitcoin nodes, and there are a lot of misbehaving/dangerous nodes
> there, there is no encryption in bitcoin protocol, an exit node can
> fake whatever it likes, this seems to be a use case as far as I can
> see, but even if the initiator is configured to connect to a hidden
> bitcoin node, I don't see the point
>
> I have advertised recentlty the open sourcing of node-Tor
> (https://github.com/Ayms/node-Tor) here
>
> This one is designed for p2p, not over the Tor network but using the
> Tor protocol, as simple as bitcoin.pipe(node-Tor), or <any
> protocol>.pipe(node-Tor), which is the finality of the project as far
> as I see it since years (maybe see
> http://www.peersm.com/Convergence.pdf even if I would modify some
> parts now)
>
> Inside servers or browsers acting as servers also (WebRTC or
> WebSockets), bitcoin peers (servers/browsers) relaying the bitcoin
> anonymized protocol using the Tor protocol (and not the Tor network)
> between each others, there is no story of exit nodes here and rdv
> points would not apply for bitcoin use, this "just" adds the internal
> missing encryption and anonymity layer to the bitcoin protocol
>
> Personally I would remove the socks proxy interface from bitcoin core,
> independently of Tor this can be misused too and offers absolutely
> zero security
>
>
> Le 08/11/2019 à 18:03, LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev
> a écrit :
>> It goes without saying in that all privately known CVE should be
>> handled so professionally but, that is, well done team.
>>
>> Regards,
>> LORD HIS EXCELLENCY JAMES HRMH
>>
>>
>> ------------------------------------------------------------------------
>> *From:* bitcoin-dev-bounces at lists.linuxfoundation.org
>> <mailto:bitcoin-dev-bounces at lists.linuxfoundation.org>
>> <bitcoin-dev-bounces at lists.linuxfoundation.org>
>> <mailto:bitcoin-dev-bounces at lists.linuxfoundation.org> on behalf of
>> Luke Dashjr via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
>> <mailto:bitcoin-dev at lists.linuxfoundation.org>
>> *Sent:* Saturday, 9 November 2019 2:07 AM
>> *To:* bitcoin-dev at lists.linuxfoundation.org
>> <mailto:bitcoin-dev at lists.linuxfoundation.org>
>> <bitcoin-dev at lists.linuxfoundation.org>
>> <mailto:bitcoin-dev at lists.linuxfoundation.org>
>> *Cc:* security at bitcoincore.org <mailto:security at bitcoincore.org>
>> <security at bitcoincore.org> <mailto:security at bitcoincore.org>
>> *Subject:* [bitcoin-dev] CVE-2017-18350 disclosure
>>
>> CVE-2017-18350 is a buffer overflow vulnerability which allows a
>> malicious
>> SOCKS proxy server to overwrite the program stack on systems with a
>> signed
>> `char` type (including common 32-bit and 64-bit x86 PCs).
>>
>> The vulnerability was introduced in
>> 60a87bce873ce1f76a80b7b8546e83a0cd4e07a5
>> (SOCKS5 support) and first released in Bitcoin Core v0.7.0rc1 in 2012
>> Aug 27.
>> A fix was hidden in d90a00eabed0f3f1acea4834ad489484d0012372
>> ("Improve and
>> document SOCKS code") released in v0.15.1, 2017 Nov 6.
>>
>> To be vulnerable, the node must be configured to use such a malicious
>> proxy in
>> the first place. Note that using *any* proxy over an insecure network
>> (such
>> as the Internet) is potentially a vulnerability since the connection
>> could be
>> intercepted for such a purpose.
>>
>> Upon a connection request from the node, the malicious proxy would
>> respond
>> with an acknowledgement of a different target domain name than the one
>> requested. Normally this acknowledgement is entirely ignored, but if the
>> length uses the high bit (ie, a length 128-255 inclusive), it will be
>> interpreted by vulnerable versions as a negative number instead. When
>> the
>> negative number is passed to the recv() system call to read the
>> domain name,
>> it is converted back to an unsigned/positive number, but at a much
>> wider size
>> (typically 32-bit), resulting in an effectively infinite read into
>> and beyond
>> the 256-byte dummy stack buffer.
>>
>> To fix this vulnerability, the dummy buffer was changed to an explicitly
>> unsigned data type, avoiding the conversion to/from a negative number.
>>
>> Credit goes to practicalswift (https://twitter.com/practicalswift) for
>> discovering and providing the initial fix for the vulnerability, and
>> Wladimir
>> J. van der Laan for a disguised version of the fix as well as general
>> cleanup
>> to the at-risk code.
>>
>> Timeline:
>> - 2012-04-01: Vulnerability introduced in PR #1141.
>> - 2012-05-08: Vulnerability merged to master git repository.
>> - 2012-08-27: Vulnerability published in v0.7.0rc1.
>> - 2012-09-17: Vulnerability released in v0.7.0.
>> ...
>> - 2017-09-21: practicalswift discloses vulnerability to security team.
>> - 2017-09-23: Wladimir opens PR #11397 to quietly fix vulernability.
>> - 2017-09-27: Fix merged to master git repository.
>> - 2017-10-18: Fix merged to 0.15 git repository.
>> - 2017-11-04: Fix published in v0.15.1rc1.
>> - 2017-11-09: Fix released in v0.15.1.
>> ...
>> - 2019-06-22: Vulnerability existence disclosed to bitcoin-dev ML.
>> - 2019-11-08: Vulnerability details disclosure to bitcoin-dev ML.
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> <mailto:bitcoin-dev at lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org <mailto: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/20191109/0e41bee1/attachment-0001.html>

2023-06-07 18:21:40

- reply

📅 Original date posted:2019-11-08
📝 Original message:Sure, but what is questionable here is the use of SOCKS proxy, for Tor I
think as the main purpose, making it dangerous for the "whole bitcoin
world" while it's something like of zero interest/use (or please let me
know what it is beside Tor)
The Tor network is very centralized and not designed at all to handle
p2p networks (which bitcoin is still not), it is designed to be used via
the Tor Browser to browse the web and to hide web servers, not bitcoin
nodes, and there are a lot of misbehaving/dangerous nodes there, there
is no encryption in bitcoin protocol, an exit node can fake whatever it
likes, this seems to be a use case as far as I can see, but even if the
initiator is configured to connect to a hidden bitcoin node, I don't see
the point
I have advertised recentlty the open sourcing of node-Tor
(https://github.com/Ayms/node-Tor) here
This one is designed for p2p, not over the Tor network but using the Tor
protocol, as simple as bitcoin.pipe(node-Tor), or <any
protocol>.pipe(node-Tor), which is the finality of the project as far as
I see it since years (maybe see http://www.peersm.com/Convergence.pdf
even if I would modify some parts now)
Inside servers or browsers acting as servers also (WebRTC or
WebSockets), bitcoin peers (servers/browsers) relaying the bitcoin
anonymized protocol using the Tor protocol (and not the Tor network)
between each others, there is no story of exit nodes here and rdv points
would not apply for bitcoin use, this "just" adds the internal missing
encryption and anonymity layer to the bitcoin protocol
Personally I would remove the socks proxy interface from bitcoin core,
independently of Tor this can be misused too and offers absolutely zero
security
Le 08/11/2019 à 18:03, LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev a
écrit :
> It goes without saying in that all privately known CVE should be
> handled so professionally but, that is, well done team.
>
> Regards,
> LORD HIS EXCELLENCY JAMES HRMH
>
>
> ------------------------------------------------------------------------
> *From:* bitcoin-dev-bounces at lists.linuxfoundation.org
> <bitcoin-dev-bounces at lists.linuxfoundation.org> on behalf of Luke
> Dashjr via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
> *Sent:* Saturday, 9 November 2019 2:07 AM
> *To:* bitcoin-dev at lists.linuxfoundation.org
> <bitcoin-dev at lists.linuxfoundation.org>
> *Cc:* security at bitcoincore.org <security at bitcoincore.org>
> *Subject:* [bitcoin-dev] CVE-2017-18350 disclosure
>
> CVE-2017-18350 is a buffer overflow vulnerability which allows a
> malicious
> SOCKS proxy server to overwrite the program stack on systems with a
> signed
> `char` type (including common 32-bit and 64-bit x86 PCs).
>
> The vulnerability was introduced in
> 60a87bce873ce1f76a80b7b8546e83a0cd4e07a5
> (SOCKS5 support) and first released in Bitcoin Core v0.7.0rc1 in 2012
> Aug 27.
> A fix was hidden in d90a00eabed0f3f1acea4834ad489484d0012372 ("Improve
> and
> document SOCKS code") released in v0.15.1, 2017 Nov 6.
>
> To be vulnerable, the node must be configured to use such a malicious
> proxy in
> the first place. Note that using *any* proxy over an insecure network
> (such
> as the Internet) is potentially a vulnerability since the connection
> could be
> intercepted for such a purpose.
>
> Upon a connection request from the node, the malicious proxy would
> respond
> with an acknowledgement of a different target domain name than the one
> requested. Normally this acknowledgement is entirely ignored, but if the
> length uses the high bit (ie, a length 128-255 inclusive), it will be
> interpreted by vulnerable versions as a negative number instead. When the
> negative number is passed to the recv() system call to read the domain
> name,
> it is converted back to an unsigned/positive number, but at a much
> wider size
> (typically 32-bit), resulting in an effectively infinite read into and
> beyond
> the 256-byte dummy stack buffer.
>
> To fix this vulnerability, the dummy buffer was changed to an explicitly
> unsigned data type, avoiding the conversion to/from a negative number.
>
> Credit goes to practicalswift (https://twitter.com/practicalswift) for
> discovering and providing the initial fix for the vulnerability, and
> Wladimir
> J. van der Laan for a disguised version of the fix as well as general
> cleanup
> to the at-risk code.
>
> Timeline:
> - 2012-04-01: Vulnerability introduced in PR #1141.
> - 2012-05-08: Vulnerability merged to master git repository.
> - 2012-08-27: Vulnerability published in v0.7.0rc1.
> - 2012-09-17: Vulnerability released in v0.7.0.
> ...
> - 2017-09-21: practicalswift discloses vulnerability to security team.
> - 2017-09-23: Wladimir opens PR #11397 to quietly fix vulernability.
> - 2017-09-27: Fix merged to master git repository.
> - 2017-10-18: Fix merged to 0.15 git repository.
> - 2017-11-04: Fix published in v0.15.1rc1.
> - 2017-11-09: Fix released in v0.15.1.
> ...
> - 2019-06-22: Vulnerability existence disclosed to bitcoin-dev ML.
> - 2019-11-08: Vulnerability details disclosure to bitcoin-dev ML.
> _______________________________________________
> 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
--
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191108/e9797500/attachment.html>

2023-06-07 18:21:28

- reply

📅 Original date posted:2019-10-28
📝 Original message:FYI, javascript implementation of the Tor protocol on server side and
inside browsers
Not related directly to bitcoin-dev but might be of some use one day to
anonymize bitcoin apps (light wallets for example)
-------- Message transféré --------
Sujet : node-Tor is now open source in clear (and modular)
Date : Thu, 24 Oct 2019 18:02:42 +0200
De : Aymeric Vitte <vitteaymeric at gmail.com>
Pour : tor-talk at lists.torproject.org
Please see https://github.com/Ayms/node-Tor and http://peersm.com/peersm2
This is a javascript implementation of the Tor protocol on server side
(nodejs) and inside browsers, please note that it is not intended to add
nodes into the Tor network, neither to implement the Tor Browser
features, it is intended to build projects using the Tor protocol from
the browser and/or servers (most likely P2P projects), the Onion Proxy
and Onion Router functions are available directly inside the browser
which establishes circuits with other nodes understanding the Tor
protocol (so it's not a "dumb" proxy), but it can of course establish
circuits with the Tor network nodes (see
https://github.com/Ayms/node-Tor#test-configuration-and-use) and act as
a Tor node
It is financed by NLnet via EU Horizon 2020 Next Generation Internet
Privacy & Trust Enhancing Technologies, now open source under a MIT
license and we made it modular, it is fast (extensively tested when
video streaming was there, especially with bittorrent or ORDB concept)
and the total unminified code
(https://github.com/Ayms/node-Tor/blob/master/html/browser.js) is only 1
MB (so ~600 kB minified) which is quite small for what it does, this is
not a browser extension/module but pure js
Possible next steps are to implement elliptic crypto and connections via
WebRTC Snowflake (peersm2 above uses WebSockets a bit the way flashproxy
was working, ie implementing the ws interface on bridges side), as well
as integrating it with "Discover and move your coins by yourself"
(https://peersm.com/wallet) for anonymous blockchain search and
anonymous sending of transactions from the browser
--
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191028/1c6957c0/attachment.html>

2023-06-07 18:20:24

- reply

📅 Original date posted:2019-09-02
📝 Original message:The browser version is now released, please see https://peersm.com/wallet
Comments/suggestions still welcome
Le 07/08/2019 à 12:54, Aymeric Vitte a écrit :
>
> FYI Phase 3 is released https://github.com/Ayms/bitcoin-transactions,
> features:
>
> - create transactions
>
> - decode transactions
>
> - verify transactions
>
> - convert/map addresses (including bech32)
>
> - create/map wallets (bip32,39,44, etc), wallets recovery
> (missing/wrong words) and check
>
> - decode/create multisig redeem scripts
>
> - pubkey/privkey mapping , conversion and formats
>
> - sign/verify messages
>
> Browserifying everything now for the end of the month
>
>
>
> -------- Message transféré --------
> Sujet : Discover and move your coins by yourself
> Date : Fri, 12 Jul 2019 20:35:00 +0200
> De : Aymeric Vitte <vitteaymeric at gmail.com>
> Pour : Bitcoin Dev <bitcoin-dev at lists.linuxfoundation.org>
>
>
>
>
> Please see https://github.com/Ayms/bitcoin-transactions this is a merge
> of former bitcoin-transactions and bitcoin-wallets nodejs modules with
> additional features to be implemented as described in the README
>
> It is financed by NLnet via EU Horizon 2020 Next Generation Internet
> Search and Discovery call
>
> So the initial dev fees have been removed and the code is now open
> source and provided in clear under a MIT license
>
> The intent is to provide all the necessary tools for anybody to discover
> and manage their coins, as well as making transactions by themselves,
> without having to sync a full node or as an alternative to wallets when
> people don't understand where their coins are (we saw quite a lot of
> confusion for people not understanding at all how to find their coins
> and to what keys their addresses did relate in case of multisig, segwit
> and now bech32)
>
> It's somewhere bitcoin-cli outside of bitcoin core more easy to use and
> not restricted to its own wallet, available for any bitcoin based coins
>
> At the end it will be a secure standalone offline js webapp inside
> browsers (like https://peersm.com/wallet but the app does not reflect
> the current state of the nodejs repo)
>
> It's not a remake of iancoleman's tool but of course some features
> overlap, as well as for other existing tools, we will also extend all of
> this inside one tool with no limitations (for example some tools do not
> accept "invalid" bip39 seeds, or bip32 seeds, etc)
>
> Comments/suggestions welcome
>
> PS: initially sent to bitcoin-discuss but the list seems to be dead
>
> --
> Move your coins by yourself (browser version): https://peersm.com/wallet
> Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
> Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
> Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
> Get the torrent dynamic blocklist: http://peersm.com/getblocklist
> Check the 10 M passwords list: http://peersm.com/findmyass
> Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
> Peersm : http://www.peersm.com
> torrent-live: https://github.com/Ayms/torrent-live
> node-Tor : https://www.github.com/Ayms/node-Tor
> GitHub : https://www.github.com/Ayms
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190902/3e4e3354/attachment.html>

2023-06-07 18:20:04

- reply

📅 Original date posted:2019-08-07
📝 Original message:FYI Phase 3 is released https://github.com/Ayms/bitcoin-transactions,
features:
- create transactions
- decode transactions
- verify transactions
- convert/map addresses (including bech32)
- create/map wallets (bip32,39,44, etc), wallets recovery (missing/wrong
words) and check
- decode/create multisig redeem scripts
- pubkey/privkey mapping , conversion and formats
- sign/verify messages
Browserifying everything now for the end of the month
-------- Message transféré --------
Sujet : Discover and move your coins by yourself
Date : Fri, 12 Jul 2019 20:35:00 +0200
De : Aymeric Vitte <vitteaymeric at gmail.com>
Pour : Bitcoin Dev <bitcoin-dev at lists.linuxfoundation.org>
Please see https://github.com/Ayms/bitcoin-transactions this is a merge
of former bitcoin-transactions and bitcoin-wallets nodejs modules with
additional features to be implemented as described in the README
It is financed by NLnet via EU Horizon 2020 Next Generation Internet
Search and Discovery call
So the initial dev fees have been removed and the code is now open
source and provided in clear under a MIT license
The intent is to provide all the necessary tools for anybody to discover
and manage their coins, as well as making transactions by themselves,
without having to sync a full node or as an alternative to wallets when
people don't understand where their coins are (we saw quite a lot of
confusion for people not understanding at all how to find their coins
and to what keys their addresses did relate in case of multisig, segwit
and now bech32)
It's somewhere bitcoin-cli outside of bitcoin core more easy to use and
not restricted to its own wallet, available for any bitcoin based coins
At the end it will be a secure standalone offline js webapp inside
browsers (like https://peersm.com/wallet but the app does not reflect
the current state of the nodejs repo)
It's not a remake of iancoleman's tool but of course some features
overlap, as well as for other existing tools, we will also extend all of
this inside one tool with no limitations (for example some tools do not
accept "invalid" bip39 seeds, or bip32 seeds, etc)
Comments/suggestions welcome
PS: initially sent to bitcoin-discuss but the list seems to be dead
--
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190807/57f7489c/attachment.html>

2023-06-07 18:19:28

- reply

📅 Original date posted:2019-07-12
📝 Original message:Please see https://github.com/Ayms/bitcoin-transactions this is a merge
of former bitcoin-transactions and bitcoin-wallets nodejs modules with
additional features to be implemented as described in the README
It is financed by NLnet via EU Horizon 2020 Next Generation Internet
Search and Discovery call
So the initial dev fees have been removed and the code is now open
source and provided in clear under a MIT license
The intent is to provide all the necessary tools for anybody to discover
and manage their coins, as well as making transactions by themselves,
without having to sync a full node or as an alternative to wallets when
people don't understand where their coins are (we saw quite a lot of
confusion for people not understanding at all how to find their coins
and to what keys their addresses did relate in case of multisig, segwit
and now bech32)
It's somewhere bitcoin-cli outside of bitcoin core more easy to use and
not restricted to its own wallet, available for any bitcoin based coins
At the end it will be a secure standalone offline js webapp inside
browsers (like https://peersm.com/wallet but the app does not reflect
the current state of the nodejs repo)
It's not a remake of iancoleman's tool but of course some features
overlap, as well as for other existing tools, we will also extend all of
this inside one tool with no limitations (for example some tools do not
accept "invalid" bip39 seeds, or bip32 seeds, etc)
Comments/suggestions welcome
PS: initially sent to bitcoin-discuss but the list seems to be dead
--
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms

2023-06-07 18:18:24

- reply

📅 Original date posted:2019-05-26
📝 Original message:I did not phrase correctly in fact, what I meant is: if the validator
sees empty or witness script in scriptSig, then this is a segwit input,
and doing this one by one the validator can associate the correct segwit
data to the correct segwit input, so 00 does not look to be needed
Le 26/05/2019 à 18:28, Johnson Lau a écrit :
> This is not how it works. While the transaction creator may know which inputs are segwit, the validators have no way to tell until they look up the UTXO set.
>
> In a transaction, all information about an input the validators have is the 36-byte outpoint (txid + index). Just by looking at the outpoint, there is no way to tell whether it is segwit-enabled or not. So there needs to be a way to tell the validator that “the witness for this input is empty”, and it is the “00”.
>
>> On 27 May 2019, at 12:18 AM, Aymeric Vitte <vitteaymeric at gmail.com> wrote:
>>
>> ……. for the 00 number of witness
>> data for non segwit inputs the one that is doing the transaction knows
>> which inputs are segwit or not, then parsing the transaction you can
>> associate the correct input to the correct witness data, without the
>> need of 00, so I must be missing the use case
>

2023-06-07 18:18:24

- reply

📅 Original date posted:2019-05-26
📝 Original message:Well, OK, then back to non standard stuff and bitcoin considers that an
OP_1 or empty scriptpubkey is something that can exist, sipa does not
like my questions on this list but this is a bit frightening in fact to
see that after 10 years an OP_1 scriptpubkey or empty one can be a use
case, thanks Thomas also, where all of this is clearly documented so
people don't bother the list not to produce approximative stuff remains
mysterious
Le 26/05/2019 à 19:24, Johnson Lau a écrit :
> Empty scriptSig doesn’t imply segwit input: if the previous scriptPubKey is OP_1 (which does not allow witness), it could still be spent with an empty scriptSig
>
> Similarly, a scriptSig looking like a spend of P2SH-segwit doesn’t imply segwit input: if the previous scriptPubKey is empty, it could be spent with a push of any non-zero value.
>
>> On 27 May 2019, at 1:09 AM, Aymeric Vitte <vitteaymeric at gmail.com> wrote:
>>
>> I did not phrase correctly in fact, what I meant is: if the validator
>> sees empty or witness script in scriptSig, then this is a segwit input,
>> and doing this one by one the validator can associate the correct segwit
>> data to the correct segwit input, so 00 does not look to be needed
>>
>> Le 26/05/2019 à 18:28, Johnson Lau a écrit :
>>> This is not how it works. While the transaction creator may know which inputs are segwit, the validators have no way to tell until they look up the UTXO set.
>>>
>>> In a transaction, all information about an input the validators have is the 36-byte outpoint (txid + index). Just by looking at the outpoint, there is no way to tell whether it is segwit-enabled or not. So there needs to be a way to tell the validator that “the witness for this input is empty”, and it is the “00”.
>>>
>>>> On 27 May 2019, at 12:18 AM, Aymeric Vitte <vitteaymeric at gmail.com> wrote:
>>>>
>>>> ……. for the 00 number of witness
>>>> data for non segwit inputs the one that is doing the transaction knows
>>>> which inputs are segwit or not, then parsing the transaction you can
>>>> associate the correct input to the correct witness data, without the
>>>> need of 00, so I must be missing the use case
>

2023-06-07 18:18:23

- reply

📅 Original date posted:2019-05-26
📝 Original message:OK, thanks, understood for OP_0 but still for the 00 number of witness
data for non segwit inputs the one that is doing the transaction knows
which inputs are segwit or not, then parsing the transaction you can
associate the correct input to the correct witness data, without the
need of 00, so I must be missing the use case
Le 26/05/2019 à 16:33, Johnson Lau a écrit :
>> On 26 May 2019, at 7:56 AM, Aymeric Vitte via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> I realized recently that my segwit implementation was not correct,
>> basically some time ago, wrongly reading the specs (and misleaded by
>> what follows), I thought that scriptsig would go into witness data as it
>> was, but that's not the case, op_pushdata is replaced by varlen
>>
> Witness is not script. There is no op_pushdata or any other opcodes.
>
> Witness is a stack. For each input, the witness starts with a CCompactSize for the number of stack elements for this input. Each stack element in turns starts with a CCompactSize for the size of this element, followed by the actual data
>
>
>> Now reading correctly the specs, they seem to be not totally correct,
>> then the first question is: why OP_0 is 00 in witness data and not 0100?
>> Does this apply to other op_codes? This does not look logical at all
>>
> A “00” element means the size of this element is zero. Since it’s zero size, no data is followed. This will create an empty element on the stack. It’s effectively same as OP_0 (Again, witness is not script)
>
> A “0100” element means the element size is one, and the data for this element is “00”. So it will leave an 1-byte element on the stack.
>
>
>> The second question is: why for non segwit inputs there is a 00 length
>> in segwit data, what is the rational for that? It should just be nothing
>> since you don't need this to reconciliate things
> The “00” here means "this input has no witness stack element”. You need this even for non segwit inputs, because there is no way to tell whether an input is segwit-enabled or not, until you look up the UTXO, which might not be always available. Transaction serialization couldn’t rely on contextual information.
>
> However, if all inputs have no stack element, the spec requires you to always use the non-segwit serialization.
>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms

2023-06-07 18:18:22

- reply

📅 Original date posted:2019-05-25
📝 Original message:I realized recently that my segwit implementation was not correct,
basically some time ago, wrongly reading the specs (and misleaded by
what follows), I thought that scriptsig would go into witness data as it
was, but that's not the case, op_pushdata is replaced by varlen
Now reading correctly the specs, they seem to be not totally correct,
then the first question is: why OP_0 is 00 in witness data and not 0100?
Does this apply to other op_codes? This does not look logical at all
The second question is: why for non segwit inputs there is a 00 length
in segwit data, what is the rational for that? It should just be nothing
since you don't need this to reconciliate things

2023-06-07 18:17:54

- reply

📅 Original date posted:2019-05-02
📝 Original message:Thanks for the answer, indeed for the redeem script and someone
attempting a 0/1 of 3, good example
So to summarize everything is standard as long as it matches P2PKH,
P2SH, P2WPKH or P2WSH , the redeem scripts for the sha bounties are in
op_return
Still the case of bch is unclear (it's related since based on bitcoin
code unless they changed the policy), was the story that nodes would not
propagate the fix or that people did not want to take the risk to
propagate it? And why a non segwit old bitcoin node would not accept it
either?
Le 02/05/2019 à 02:10, ZmnSCPxj a écrit :
> Good morning Aymeric,
>
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Tuesday, April 30, 2019 5:43 PM, Aymeric Vitte <vitteaymeric at gmail.com> wrote:
>
>> I must badly explain my point (or just wondering things that do not
>> exist finally), the question is indeed whether nodes will relay non
>> usual transactions or not and how to know what they will accept or not:
>>
>> - my modified multisig 2 of 3: I did put OP_2 out of the usual redeem
>> script, the redeem script still matches scriptpubkey and scriptsig will
>> execute succesfully, that's a normal legacy P2SH or segwit P2WSH
>>
>> - bch segwit recovery: it's a p2sh transaction without any signature
>> verification, as far as I remember there was a story that it could not
>> propagate in the network (even taking the risk to be stolen) and that
>> people had to contact a (honest) miner
>>
>> - sha bounties: same as above, p2sh transactions without signatures
>>
>> etc
>>
>> Will all of those transactions propagate normally? And then the rule is
>> just that it matches the P2PKH, P2WPKH, P2SH, or P2WSH templates
>> whatever scripts you put inside?
> P2PKH and P2WPKH cannot have custom script.
> However, yes, any custom script can be wrapped in P2SH and P2WSH and it will be propagated.
> The P2SH/P2WSH hides the details of your custom script so cannot be filtered based on your custom script.
> Do realize that once a claim on your modified x-of-3 is propagated your `redeemScript` is known and someone can attempt to RBF (or coordinate with a miner) with a modified `witness` stack or `scriptSig` to claim your UTXO.
> (I do not know if `OP_CHECKMULTISIG` supports 0-of-3 but at least one of your signatories could make it a 1-of-3 and bribe a miner to get it claimed)
>
> I cannot answer for BCH; arguably that is off-topic here.
>
> The old SHA bounty transactions were propagated in the days before `isStandard` I think.
> Either that or they were put in by miners.
> An SHA bounty can still be propagated today if they are wrapped in a P2SH or P2WSH, but you have to publish the `redeemScript` yourself in some other method.
> Or bribe a miner if the transaction is not time-sensitive (for an SHA bounty, unlikely to be time-sensitive).
>
> Regards,
> ZmnSCPxj
--
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms

2023-06-07 18:17:54

- reply

📅 Original date posted:2019-05-03
📝 Original message:Great doc, thanks, then my previous summarized conclusion was wrong,
trying on my side to write a "demistifying (simply) once for all bitcoin
scripting", not sure that "simply" can stay in the title at the end...
So my multisig modification is non standard, now I am still puzzled by
something, mainly the fact that we have op_pushdata inside op_pushdata,
maybe I am misreading the specs, but in case of p2sh only the last
op_pushdata (called {serialized script} (or redeem script) is executed,
then if succesfull it comes back onto the stack and scriptpubkey is executed
So, let's take again the BCH recovery example, scriptSig was OP_PUSHDATA
0014<hash160 of pubkey>, and scriptPubKey OP_HASH160 <hash160 of
0014<hash160 of pubkey> OP_EQUAL, then scriptSig executes pushing
nothing and <hash160 of pubkey> into the stack, then scriptSig is pushed
again and executed with scriptPubKey, at the end we get nothing +
<hash160 of pubkey> + 1 in the stack, then cleanstack (maybe among
others, I have to read in more details your doc) says it is a correct
transaction but non standard, is this correct?
Le 03/05/2019 à 01:33, James Prestwich a écrit :
> Hi Aymeric,
>
> As Luke and ZmnSCPxj have pointed out, documenting standardness is
> sisyphean, as it varies from version to version. I recently put
> together a reference for default TX_NONSTANDARD policies in v0.18,
> which can be found here: https://prestwi.ch/the-bitcoin-nonstandard/
>
> It applies only to v0.18, and may already be outdated.
>
> Best,
> James
>
> On Thu, May 2, 2019 at 4:29 PM Aymeric Vitte via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> Thanks for the answer, indeed for the redeem script and someone
> attempting a 0/1 of 3, good example
>
> So to summarize everything is standard as long as it matches P2PKH,
> P2SH, P2WPKH or P2WSH , the redeem scripts for the sha bounties are in
> op_return
>
> Still the case of bch is unclear (it's related since based on bitcoin
> code unless they changed the policy), was the story that nodes
> would not
> propagate the fix or that people did not want to take the risk to
> propagate it? And why a non segwit old bitcoin node would not
> accept it
> either?
>
> Le 02/05/2019 à 02:10, ZmnSCPxj a écrit :
> > Good morning Aymeric,
> >
> >
> > Sent with ProtonMail Secure Email.
> >
> > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> > On Tuesday, April 30, 2019 5:43 PM, Aymeric Vitte
> <vitteaymeric at gmail.com <mailto:vitteaymeric at gmail.com>> wrote:
> >
> >> I must badly explain my point (or just wondering things that do not
> >> exist finally), the question is indeed whether nodes will relay non
> >> usual transactions or not and how to know what they will accept
> or not:
> >>
> >> - my modified multisig 2 of 3: I did put OP_2 out of the
> usual redeem
> >> script, the redeem script still matches scriptpubkey and
> scriptsig will
> >> execute succesfully, that's a normal legacy P2SH or segwit
> P2WSH
> >>
> >> - bch segwit recovery: it's a p2sh transaction without any
> signature
> >> verification, as far as I remember there was a story that
> it could not
> >> propagate in the network (even taking the risk to be
> stolen) and that
> >> people had to contact a (honest) miner
> >>
> >> - sha bounties: same as above, p2sh transactions without
> signatures
> >>
> >> etc
> >>
> >> Will all of those transactions propagate normally? And then
> the rule is
> >> just that it matches the P2PKH, P2WPKH, P2SH, or P2WSH
> templates
> >> whatever scripts you put inside?
> > P2PKH and P2WPKH cannot have custom script.
> > However, yes, any custom script can be wrapped in P2SH and P2WSH
> and it will be propagated.
> > The P2SH/P2WSH hides the details of your custom script so cannot
> be filtered based on your custom script.
> > Do realize that once a claim on your modified x-of-3 is
> propagated your `redeemScript` is known and someone can attempt to
> RBF (or coordinate with a miner) with a modified `witness` stack
> or `scriptSig` to claim your UTXO.
> > (I do not know if `OP_CHECKMULTISIG` supports 0-of-3 but at
> least one of your signatories could make it a 1-of-3 and bribe a
> miner to get it claimed)
> >
> > I cannot answer for BCH; arguably that is off-topic here.
> >
> > The old SHA bounty transactions were propagated in the days
> before `isStandard` I think.
> > Either that or they were put in by miners.
> > An SHA bounty can still be propagated today if they are wrapped
> in a P2SH or P2WSH, but you have to publish the `redeemScript`
> yourself in some other method.
> > Or bribe a miner if the transaction is not time-sensitive (for
> an SHA bounty, unlikely to be time-sensitive).
> >
> > Regards,
> > ZmnSCPxj
>
> --
> Move your coins by yourself (browser version):
> https://peersm.com/wallet
> Bitcoin transactions made simple:
> https://github.com/Ayms/bitcoin-transactions
> Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
> Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
> Get the torrent dynamic blocklist: http://peersm.com/getblocklist
> Check the 10 M passwords list: http://peersm.com/findmyass
> Anti-spies and private torrents, dynamic blocklist:
> http://torrent-live.org
> Peersm : http://www.peersm.com
> torrent-live: https://github.com/Ayms/torrent-live
> node-Tor <https://github.com/Ayms/torrent-livenode-Tor> :
> https://www.github.com/Ayms/node-Tor
> GitHub : https://www.github.com/Ayms
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190503/fa40d55f/attachment-0001.html>

2023-06-07 18:17:51

- reply

📅 Original date posted:2019-04-29
📝 Original message:ZmnSCPxj, OK, but you can put whatever you like in the different
standard output script you mention (my example below whether legacy or
segwit)
Luke, I am still confused or missing something, from your answer I
understand that everything is accepted, so if we take the past example
of bch coins wrongly sent to a segwit address, why was the recovery
solution where scriptsig included the matching segwit address/program
not a standard transaction?
Le 29/04/2019 à 05:01, Luke Dashjr a écrit :
> On Saturday 27 April 2019 10:37:29 Aymeric Vitte via bitcoin-dev wrote:
>> Maybe trivial question but asking here because I can't find anything
>> clear (or updated) about it: is somewhere explained in details what txs
>> are considered standard and non standard today without having to read
>> the core code?
>>
>> For example, modification of multisig 2 of 3:
>>
>> scriptSig:
>>     OP_0
>>     OP_PUSHDATA sign1
>>     OP_PUSHDATA sign2
>>     OP_2
>>     OP_PUSHDATA <pubkey1><pubkey2><pubkey3> OP_3 OP_CHECKMULTISIG
>>
>> scriptPubKey:
>>     OP_HASH160 hash160(<pubkey1><pubkey2><pubkey3> OP_3
>> OP_CHECKMULTISIG) OP_EQUAL
>>
>> Is this standard? Are lightning txs standards ? etc
> The name is confusing. It has little to do with standards, really.
> IsStandard is just one of the functions which implement the node's policy.
> It allows many things for which there is no standard (eg, data carrier /
> OP_RETURN outputs), and can vary freely from node to node (either by
> configurable parameters, or by different/modified software) without breaking
> consensus.
>
> As it is a node-specific criteria, it is not itself even a possible *subject*
> for standards.
>
> Additionally, it should not be given much (if any) attention when defining new
> standards. Just do what makes sense for the standard, and node policies can
> be adapted around that.
>
> So, overall, there's limited use case for documenting this beyond the code.
> It makes far more sense to document actual standards instead.
>
> Luke
s

2023-06-07 18:17:51

- reply

📅 Original date posted:2019-04-30
📝 Original message:I must badly explain my point (or just wondering things that do not
exist finally), the question is indeed whether nodes will relay non
usual transactions or not and how to know what they will accept or not:
- my modified multisig 2 of 3: I did put OP_2 out of the usual redeem
script, the redeem script still matches scriptpubkey and scriptsig will
execute succesfully, that's a normal legacy P2SH or segwit P2WSH
- bch segwit recovery: it's a p2sh transaction without any signature
verification, as far as I remember there was a story that it could not
propagate in the network (even taking the risk to be stolen) and that
people had to contact a (honest) miner
- sha bounties: same as above, p2sh transactions without signatures
etc
Will all of those transactions propagate normally? And then the rule is
just that it matches the P2PKH, P2WPKH, P2SH, or P2WSH templates
whatever scripts you put inside?
Le 30/04/2019 à 06:29, ZmnSCPxj a écrit :
> Good morning Aymeric,
>
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Monday, April 29, 2019 5:30 PM, Aymeric Vitte <vitteaymeric at gmail.com> wrote:
>
>> ZmnSCPxj, OK, but you can put whatever you like in the different
>> standard output script you mention (my example below whether legacy or
>> segwit)
>>
> I am uncertain what you mean by this.
>
> For P2PKH and P2WPKH, you must present a hash of a public key.
> You cannot present a hash of anything else.
>
> The P2PKH template can be interpreted as a script, but is actually recognized as a template by most current nodes (in a way that is consistent with interpreting it as a script).
>
> For P2SH and P2WSH, you must present a hash of a script.
>
> It is more helpful to consider that *today* nodes recognize particular patterns (P2PKH, P2WPKH, P2SH, P2WSH) as templates and not as scripts to be executed.
>
> In any case, if you want to make anything more complicated than "single signer" you should use P2SH or P2WSH regardless, and give your script.
> If you want to assure somebody that a particular P2SH or P2WSH commits to a particular policy, just expose the policy script to them and have them (i.e. their client software) verify that the policy is what the user wants and that when hashed it matches the P2SH/P2WSH.
>
> As Luke said, nodes can have any policy for propagating transactions.
> However it is generally expected that P2PKH, P2WPKH, P2SH, and P2WSH will be propagated by a majority of nodes, if only because those are reliably "passed" by `isStandard` in the default latest Bitcoin Core and most people will not modify the Core code.
>
> Generally, anything that isn't P2PKH, P2WPKH, P2SH, or P2WSH will not likely be propagated by the network.
> You *could* still coordinate with one or more miners to get it mined: you can put anything in the block, it is simply that most nodes will not inform miners about transactions that do not pay out to P2PKH, P2WPKH, P2SH, or P2WSH.
>
> Regards,
> ZmnSCPxj
--
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms

2023-06-07 18:17:50

- reply

📅 Original date posted:2019-04-27
📝 Original message:Maybe trivial question but asking here because I can't find anything
clear (or updated) about it: is somewhere explained in details what txs
are considered standard and non standard today without having to read
the core code?
For example, modification of multisig 2 of 3:
scriptSig:
    OP_0
    OP_PUSHDATA sign1
    OP_PUSHDATA sign2
    OP_2
    OP_PUSHDATA <pubkey1><pubkey2><pubkey3> OP_3 OP_CHECKMULTISIG
scriptPubKey:
    OP_HASH160 hash160(<pubkey1><pubkey2><pubkey3> OP_3
OP_CHECKMULTISIG) OP_EQUAL
Is this standard? Are lightning txs standards ? etc

2023-06-07 18:17:35

- reply

📅 Original date posted:2019-04-08
📝 Original message:Hi,
I took the example of colored coins because you quoted ethereum and like
most of ethereum tokens most of them reflect something coming from
nowhere, worse I can send you 10K Tethers if you like that of course
will not be validated by the central system but will be recorded in
bitcoin blockchain
Bitcoin oulasting ethereum, maybe, but the bitcoin community must make
more efforts to explain things, like "both were obvious" below is not in
fact for an usual reader, so a few more words would be good indeed
For me a sidechain does not have to be a blockchain but a decentralized
system allowing to secure off chain transactions until the final state
is stored into the blockchain, I don't see the use of storing forever
the intermediate states neither why the sidechain should be a
blockchain, if not then the sidechain would just be another
bitcoin/ethereum, no? What would be the purpose of building a blockchain
on top of another one? Just do your own, and this would eliminate the
drawback of needing to have bitcoins or ethers to smart contract things
that have nothing to do with them, as well as mixing addresses between
the blockchain and the sidechains
Regards
Aymeric
Le 08/04/2019 à 12:45, ZmnSCPxj a écrit :
> Good morning Aymeric,
>
>> Hi,
>>
>> Apparently you are not a fan of ethereum, as far as I can tell ethereum
>> sidechains look like a mess with stupid tokens/transactions flooding the
>> network while they are completely centralized, but some bitcoin
>> sidechains can easily compete with this too, like Tether, don't even
>> understand how anyone can give some credit to that stuff the way it is
>> implemented, and if bitcoin fails that would be the same as for ethereum
> I prefer to be more precise in my terminology.
> Colored coins are not the same as sidechains, and there are colored coins and then there are colored coins.
> This mechanism does not propose some change in colored coins.
> An important aspect of colored coins is that one can foist them on somebody else to extract things of real value from them, but this mechanism is more strongly for a fixed set of participants.
>
> I strongly suspect that Bitcoin will outlast Ethereum, but that is rather not very related to this topic.
>
>> Most likely everyone would agree if the escrow disappears, but not sure
>> at all, let's imagine 1 to N put 10K on the table for a game, they
>> update the states and at the end N wins everything, N is rich and don't
>> care finally if the others cheaters have their coins locked (and to lose
>> 10K), same with setting up a new escrow to resolve the conflict
>>
> Indeed.
> Still, the option to do so exists, and sometimes all that is needed for humans to do the right thing, is to be given the option to do so.
>
>> I think that you should highlight this (and what private key corresponds
>> to E + h(E | s) * G, not sure it's trivial for everybody), probably a
>> way to get this more decentralized is to reward the escrows (what is the
>> interest here for people to run a smart contract platform?)
> I assumed both were obvious, but I suppose a few more words about those would not be amiss.
>
>> For lightning, maybe it's a question of wording, I consider it as a
>> sidechain AND methods that can be used by other sidechains, as well as
>> the others you quoted, even if only two people in the world use
>> lightning, it is still decentralized, because it sustains itself alone
> Again, I prefer precision in my terminology.
> For me, a sidechain is a blockchain of some sort.
> In particular, a kind of Merklized singly-linked list containing representations of transformations of state, is how I define blockchain to be.
>
> No such Merklized singly-linked list exists in Lightning Network, thus I do not consider it, "blockchain".
> And thus I do not consider it "sidechain", as a sidechain is a blockchain.
> Current LN does use "shachains" by Rusty, but shachains are not Merklized singly-linked lists, but are instead a kind of inverse mountain range structure.
>
> Still, one might consider both federated sidechains and Lightning Network to have a "federated" offchain structure.
> This is because the coins on the Bitcoin blockchain are locked to a multisignature and activity is not recorded on the Bitcoin blockchain.
> However, in LN, each channel is a 2-member federation (you and a counterparty) and the mechanism in LN requires consensus (2-of-2) rather than a quorum (m-of-n).
> This greatly increases the security of LN: the owner of funding on an LN channel can always refuse to sign an update if the other member of the federation is taken over.
> Compare this to the quorum that typical federations have, where takeover of a sufficient quorum is enough to steal funds from the remaining federation.
> https://zmnscpxj.github.io/offchain/safety.html
>
> Regards,
> ZmnSCPxj

2023-06-07 18:17:34

- reply

📅 Original date posted:2019-04-04
📝 Original message:What if the smart contract platform(s) disappear?
The proposal induces a very centralized system, to my knowledge all of
existing sidechains whether on bitcoin or ethereum are centralized,
except lightning (if we forget that someone must watch what others are
doing when you are on a trek in Nepal)
Now I don't get why a sidechain should be a blockchain on top on another
one (given also that we can't consider bitcoin or ethereum as
decentralized today, so the path might be long for the sidechains...),
the latest is used to store the final state, the former does not have to
store forever the intermediate states, then it could just use a
decentralized system (not necessarilly blockchain-like) to store the
intermediate states and maybe be a distributed escrow
I know, easy to say, please do it (why not), now the fact that
sidechains claim to be decentralized or that they will be is just
misleading people (that's not the case of your proposal but it does not
say what happens if the platforms go down)
Le 04/04/2019 à 03:55, ZmnSCPxj via bitcoin-dev a écrit :
> https://zmnscpxj.github.io/bitcoin/unchained.html
>
> Smart contracts have traditionally been implemented as part of the consensus rules of some blokchain. Often this means creating a new blockchain, or at least a sidechain to an existing blockchain. This writeup proposes an alternative method without launching a separate blockchain or sidechain, while achieving security similar to federated sidechains and additional benefits to privacy and smart-contract-patching.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Peersm : http://www.peersm.com
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms

2023-06-07 18:17:34

- reply

📅 Original date posted:2019-04-05
📝 Original message:Hi,
Apparently you are not a fan of ethereum, as far as I can tell ethereum
sidechains look like a mess with stupid tokens/transactions flooding the
network while they are completely centralized, but some bitcoin
sidechains can easily compete with this too, like Tether, don't even
understand how anyone can give some credit to that stuff the way it is
implemented, and if bitcoin fails that would be the same as for ethereum
Most likely everyone would agree if the escrow disappears, but not sure
at all, let's imagine 1 to N put 10K on the table for a game, they
update the states and at the end N wins everything, N is rich and don't
care finally if the others cheaters have their coins locked (and to lose
10K), same with setting up a new escrow to resolve the conflict
I think that you should highlight this (and what private key corresponds
to E + h(E | s) * G, not sure it's trivial for everybody), probably a
way to get this more decentralized is to reward the escrows (what is the
interest here for people to run a smart contract platform?)
For lightning, maybe it's a question of wording, I consider it as a
sidechain AND methods that can be used by other sidechains, as well as
the others you quoted, even if only two people in the world use
lightning, it is still decentralized, because it sustains itself alone
Regards
Aymeric
Le 05/04/2019 à 01:52, ZmnSCPxj a écrit :
> Good morning Aymeric,
>
>
>> What if the smart contract platform(s) disappear?
>>
> It is still possible to recover the funds, *if* you can convince all participants of some "fair" distribution of the funds.
> You do this by all participants simply signing with their participant keys and taking the first branch of the script.
> This branch does not require the participation of the smart contract platform, at all.
> If all participants can agree to the result of the smart contract without dispute, then they can exit the platform even after the platform disappears.
>
> Now of course there will be participants who will not cooperate in such a case, for example if they were doing some betting game and "lost".
> But at least it gives the possibility of doing so, and it will not be as massive a loss.
>
> Indeed, if the smart contract platform code is open source, it may be possible to set up another implementation of the smart contract platform.
> And it would be possible to at least try to convince all participants to switch to that new platform (again, via the "as long as everybody agrees" escape hatch).
> Again, this is not possible with current federated sidechains, or Ethereum (if Ethereum fails, all ETH becomes valueless).
>
>> The proposal induces a very centralized system, to my knowledge all of
>> existing sidechains whether on bitcoin or ethereum are centralized,
>> except lightning (if we forget that someone must watch what others are
>> doing when you are on a trek in Nepal)
> I would not lump together Lightning with sidechains.
> Indeed, this design moves things closer to true offchain techniques (as in Lightning) than to sidechain techniques.
>
> So while centralized, it is less centralized than a federated sidechains.
>
>> Now I don't get why a sidechain should be a blockchain on top on another
>> one (given also that we can't consider bitcoin or ethereum as
>> decentralized today, so the path might be long for the sidechains...),
>> the latest is used to store the final state, the former does not have to
>> store forever the intermediate states, then it could just use a
>> decentralized system (not necessarilly blockchain-like) to store the
>> intermediate states and maybe be a distributed escrow
>>
>> I know, easy to say, please do it (why not), now the fact that
>> sidechains claim to be decentralized or that they will be is just
>> misleading people (that's not the case of your proposal but it does not
>> say what happens if the platforms go down)
> Perhaps it can be a next step.
>
> Regards,
> ZmnSCPxj

2023-06-07 18:17:31

- reply

📅 Original date posted:2019-04-09
📝 Original message:What is not final finally and when do you expect it to be?
Le 09/04/2019 à 11:49, Pavol Rusnak a écrit :
> We are in process of finalizing it, so it is not live in Trezor yet.
> It will be soon, though. I suppose every wallet that uses BIP39 will
> adopt this one as well.
>
> On Tue, Apr 9, 2019, 11:46 Aymeric Vitte <vitteaymeric at gmail.com
> <mailto:vitteaymeric at gmail.com>> wrote:
>
> Is it final now and live in Trezor? Do you know who else will
> adopt it?
>
> Regards
>
> Aymeric
>
> Le 03/04/2019 à 11:19, Pavol Rusnak via bitcoin-dev a écrit :
>> I am the author of the wordlist. Feel free to use it without any
>> restrictions.
>>
>> However, we are finalizing SLIP39 standard for splitting shares
>> which uses a different wordlist with better properties. It might
>> be more suitable for your project.
>>
>> See https://github.com/satoshilabs/slips/blob/master/slip-0039.md
>> and https://github.com/satoshilabs/slips/blob/master/slip-0039/wordlist.txt
>>
>>
>>
>> On Wed, Apr 3, 2019, 09:32 Elia via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org
>> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>>
>> I would like to use the BIP39 word lists posted in the Github
>> BIP repo
>> for my own project.
>>
>>
>> Unfortunately there is no license associated with the lists
>> provided on
>> Github so I am not sure whether usage for other projects is
>> permitted. I
>> am not able to file issues on the repo either to suggest
>> adding a license.
>>
>> Does anybody know under which license these lists are published?
>>
>>
>> Best regards,
>>
>> Elia
>>
>>
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> <mailto:bitcoin-dev at lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org <mailto: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/20190409/2089a69e/attachment-0001.html>

2023-06-07 18:17:30

- reply

📅 Original date posted:2019-04-09
📝 Original message:Is it final now and live in Trezor? Do you know who else will adopt it?
Regards
Aymeric
Le 03/04/2019 à 11:19, Pavol Rusnak via bitcoin-dev a écrit :
> I am the author of the wordlist. Feel free to use it without any
> restrictions.
>
> However, we are finalizing SLIP39 standard for splitting shares which
> uses a different wordlist with better properties. It might be more
> suitable for your project.
>
> See https://github.com/satoshilabs/slips/blob/master/slip-0039.md
> and https://github.com/satoshilabs/slips/blob/master/slip-0039/wordlist.txt
>
>
>
> On Wed, Apr 3, 2019, 09:32 Elia via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> I would like to use the BIP39 word lists posted in the Github BIP repo
> for my own project.
>
>
> Unfortunately there is no license associated with the lists
> provided on
> Github so I am not sure whether usage for other projects is
> permitted. I
> am not able to file issues on the repo either to suggest adding a
> license.
>
> Does anybody know under which license these lists are published?
>
>
> Best regards,
>
> Elia
>
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> <mailto: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
--
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190409/4236b446/attachment-0001.html>

2023-06-07 18:17:19

- reply

📅 Original date posted:2019-04-02
📝 Original message:Right and everybody knows that Tether is the most clever sidechain ever
invented far more sophisticated than lightning, which makes me think
that a punishment should be added in the proposal for the cheater
advertising a price < 50 k (or 100) and/or selling before 1-3 years
(tbd) so all his coins go to the Bitcoin Mediator, a new notion here to
sustain the community (I modestly apply for the position)
Le 01/04/2019 à 13:50, Dana L. Coe via bitcoin-dev a écrit :
> I suggest in the spirit of the times that we not use USD as the
> reference, but USDT.
>
> Everyone knows Tethers are much more flexible in tracking the true
> value of the US dollar.
>
> Dana
>
>> On Apr 1, 2019, at 7:22 PM, Melvin Carvalho via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org
>> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>>
>>
>>
>> On Mon, 1 Apr 2019 at 02:32, Luke Dashjr via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org
>> <mailto:bitcoin-dev at lists.linuxfoundation.org>> 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.
>>
>> The BIPs are here, as well as included at the bottom of this
>> email for
>> convenience:
>> https://github.com/luke-jr/bips/blob/softfork_50k/bip-usdprice.mediawiki
>> https://github.com/luke-jr/bips/blob/softfork_50k/bip-softfork-50k-price.mediawiki
>>
>> A reference implementation is here:
>> https://github.com/bitcoin/bitcoin/compare/v0.17.1...luke-jr:softfork_50k
>>
>> Please review ASAP so we can get these deployed in Bitcoin Core
>> v0.18.
>>
>>
>> This seems a little arbitrary. Ask yourself, "Why the USD?". Yes,
>> it is the dominant currency now, but in 2, 6, 10, 14 years? Who knows.
>>
>> You could make equally an argument to denominate in euros. Or a
>> basket of currencies, or even the Bancor.
>>
>> However the wider question is why even denominate in fiat at all?
>>
>> I suggest denominating the minimum value in satoshsis themselves,
>> which would be a negligable upgrade to the network.
>>
>>
>> Luke
>>
>>
>> <pre>
>> BIP: ?
>> Layer: Applications
>> Title: Signed USD Price Indicator
>> Author: Luke Dashjr <luke+bip at dashjr.org
>> <mailto:luke%2Bbip at dashjr.org>>
>> Comments-Summary: No comments yet.
>> Comments-URI:
>> https://github.com/bitcoin/bips/wiki/Comments:BIP-????
>> Status: Draft
>> Type: Standards Track
>> Created: 2019-04-01
>> License: BSD-2-Clause
>> </pre>
>>
>> ==Abstract==
>>
>> This BIP proposes a method to explicitly specify and sign the
>> USD/BTC price
>> for transactions.
>>
>> ==Copyright==
>>
>> This BIP is licensed under the BSD 2-clause license.
>>
>> ==Motivation==
>>
>> 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.
>>
>> This problem can be fixed by setting a global minimum price for
>> bitcoins.
>> Unfortunately, today, the consensus protocol is completely
>> oblivious to the
>> price bitcoins are traded at. Therefore, we must first add a
>> field to Bitcoin
>> transactions to indicate their price.
>>
>> ==Specification==
>>
>> ===New field and legal implication===
>>
>> A new field is added to Bitcoin transactions. This field, if
>> present, must
>> represent the honest and true USD/BTC rate used for the
>> transaction. By
>> signing the transaction, the sender legally affirms this is the
>> valuation of
>> bitcoins used for the transaction.
>>
>> For the avoidance of doubt: when the transaction is valued in a
>> currency other
>> than USD, any reasonable exchange rate may be used to come up
>> with the USD
>> valuation.
>>
>> ===Serialisation===
>>
>> When serialising the transaction for any purpose, including
>> signing, weight
>> calculation, and so on, the output count must be incremented by
>> one. Prior to
>> the first real output, the following bytes must be inserted:
>>
>> * Constant: 00 00 00 00 00 00 00 00
>> * A single byte, the size in bytes of the remainder of the
>> inserted data
>> * Constant: 6a 04 55 53 44 24
>> * A single byte, the size in bytes of the remainder of the
>> inserted data
>> * The USD/BTC rate used for the transaction, in standard signed
>> integer
>> serialisation, with all leading zeros removed (except as
>> necessary to
>> preserve the sign bit).
>>
>> ==Backwards compatibility==
>>
>> ===Consensus===
>>
>> The new price field is serialised as a dummy output, with a value
>> of zero, and
>> a scriptPubKey that begins with OP_RETURN (6a). Existing nodes
>> will ignore
>> this dummy output, and the leading OP_RETURN in the scriptPubKey
>> ensures it
>> is never considered spendable.
>>
>> Therefore, current nodes will ignore the new field entirely, and
>> accept
>> transactions using it.
>>
>> ===Wallets===
>>
>> Existing wallets do not typically generate price indicators as
>> specified.
>> Under this BIP, this absence of the field is perfectly acceptable.
>>
>> ==Reference implementation==
>>
>> https://github.com/bitcoin/bitcoin/compare/v0.17.1...luke-jr:usd_price_tx_field
>>
>> <pre>
>> BIP: ?
>> Layer: Consensus (soft fork)
>> Title: $50k USD/BTC Minimum Price
>> Author: Luke Dashjr <luke+bip at dashjr.org
>> <mailto:luke%2Bbip at dashjr.org>>
>> Comments-Summary: No comments yet.
>> Comments-URI:
>> https://github.com/bitcoin/bips/wiki/Comments:BIP-????
>> Status: Draft
>> Type: Standards Track
>> Created: 2019-04-01
>> License: BSD-2-Clause
>> Requires: usdprice
>> </pre>
>>
>> ==Abstract==
>>
>> This BIP defines a minimum price of $50k USD/BTC for Bitcoin
>> transactions.
>>
>> ==Copyright==
>>
>> This BIP is licensed under the BSD 2-clause license.
>>
>> ==Motivation==
>>
>> 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.
>>
>> bip-usdprice defines a new field to indicate the price of
>> transactions. Using
>> this, we can softfork to require a minimum transaction price.
>>
>> ==Specification==
>>
>> Beginning with block height 622370 (expected approximately 2020
>> April 1), a
>> block is reject as invalid unless all transactions it contains
>> both declare a
>> USD/BTC price (as defined in bip-usdprice) and specify a price
>> that is at a
>> minimum $50k USD/BTC.
>>
>> ==Backwards compatibility==
>>
>> As a soft fork, older nodes will continue to accept the
>> blockchain without
>> modification. Non-upgraded nodes, however, will not validate the
>> minimum
>> price requirement, and may accept invalid blocks if miners choose
>> to make
>> them. Since transactions not declaring a price are at this time
>> still
>> common-place, the softfork activation has been set a full year
>> into the
>> future to ensure time to upgrade both nodes and wallet software.
>>
>> ==Reference implementation==
>>
>> https://github.com/luke-jr/bitcoin/compare/usd_price_tx_field...softfork_50k
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> <mailto:bitcoin-dev at lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> <mailto: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
--
Peersm : http://www.peersm.com
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190402/8ef5619c/attachment-0001.html>

2023-06-07 18:16:40

- reply

📅 Original date posted:2019-03-06
📝 Original message:Re-sending to the list since it never made it
BIP or not, at least this process desserves to be documented precisely
-------- Message transféré --------
Sujet : Re: [bitcoin-dev] BIP proposal - Signatures of Messages using
Bitcoin Private Keys
Date : Mon, 18 Feb 2019 16:29:34 -0800
De : Christopher Gilliard <christopher.gilliard at gmail.com>
Pour : Aymeric Vitte <vitteaymeric at gmail.com>
Copie à : Bitcoin Protocol Discussion
<bitcoin-dev at lists.linuxfoundation.org>
Trying the four possible options (p2pkh compressed, p2pkh uncompressed,
seg3, and bech32) is certainly a possibility and in fact, that's what I
ended up doing because not every wallet implements something like this,
but if there is a header field currently in use, it seemed reasonable to
me to use it specify which type of key is being used. If the header
includes whether the key is compressed or not compressed it seems
logical to include all data about what type of key it is and not just
this one type of information. That's why I thought the solution made
sense and I wrote it up.
On Mon, Feb 18, 2019 at 3:50 PM Aymeric Vitte <vitteaymeric at gmail.com
<mailto:vitteaymeric at gmail.com>> wrote:
Ah, OK, that's of course a good thing to document this undocumented
(and strange) stuff, as a matter of fact I implemented it after
reading your post (because this was on my todo list since some time)
and got annoyed quickly, mainly by what is doing
formatMessageForSigning (which is quite trivial when you know it but
would be good to document precisely)
So, yes, it's a good idea to write this, regarding the header I
still don't see the use, testing the different possibilities is not
a big deal, why the signature format is not the same as transactions
one is mysterious too
Le 19/02/2019 à 00:24, Christopher Gilliard a écrit :
> The proposal includes actual code that does verification, but I
> didn't include code for signing. I thought it could be inferred,
> but I could at least include a description of how to sign. I am
> not sure exactly what part you are referring to by "keys speech",
> but the signatures are done by ECDSA keys so it's hard to not
> include anything about keys even though that's not the main topic.
> The "Background on ECDSA keys" section was mainly meant to give
> background about what kind of keys Bitcoin uses, for people who
> already know that they can easily skip this section so I would
> probably think it's best just to leave in. Maybe it should be at
> the end as an addendum though. Yes, I did not invent any of this,
> I'm just documenting what people actually seem to do because I had
> to verify signatures as part of a project I'm working on. I would
> have liked to have had this document when I started the project so
> I thought it might be useful to others since as far as I can tell
> this was not specified anywhere. The reason for including this
> data in the header is the same that compressed/uncompressed is
> included in the header so that you know which type of key the
> signature is from and you don't have to try all options to see if
> any matches. This is why Trezor did that way and why I documented
> it. I'm sure there are other ways to do this, but since this is
> out there in the field being used and is a reasonable solution, I
> thought I'd write it up.
>
> On Mon, Feb 18, 2019 at 2:59 PM Aymeric Vitte
> <vitteaymeric at gmail.com <mailto:vitteaymeric at gmail.com>> wrote:
>
> Then, since you wrote this proposal, maybe you should add the
> very precise description of the signing/verification process
> since it is documented nowhere
>
> I don't get the use of the speech regarding keys while it
> should focus on signatures which are summarized in a vague
> sentence inspired by your ref [2] with a not very logical link
> to the next paragraph stating that r,s should be 32B and the
> whole thing 65B with a header of 1B, you did not invent it,
> that's probably the rule, not sure where it is specified again
> and for what purpose, the header seems completely of no use
> especially when you extend to segwit/bech32 since you just
> have to check that related compressed key matches
>
> Le 17/02/2019 à 15:14, Christopher Gilliard via bitcoin-dev a
> écrit :
>> I have written up a proposed BIP. It has to do with Signature
>> formats when using Bitcoin Private keys. It is
>> here: https://github.com/cgilliard/BIP/blob/master/README.md
>>
>> This BIP was written up as suggested in this github
>> issue: https://github.com/bitcoin/bitcoin/issues/10542
>>
>> Note that the proposal is inline with the implementation that
>> Trezor implemented in the above issue.
>>
>> Any feedback would be appreciated. Please let me know what
>> the steps are with regards to getting a BIP number assigned
>> or any other process steps required.
>>
>> Regards,
>> Chris
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> --
> Move your coins by yourself (browser version): https://peersm.com/wallet
> Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
> Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
> Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
> Get the torrent dynamic blocklist: http://peersm.com/getblocklist
> Check the 10 M passwords list: http://peersm.com/findmyass
> Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
> Peersm : http://www.peersm.com
> torrent-live: https://github.com/Ayms/torrent-live
> node-Tor : https://www.github.com/Ayms/node-Tor
> GitHub : https://www.github.com/Ayms
>
--
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190306/3814a315/attachment-0001.html>

2023-06-07 18:16:38

- reply

📅 Original date posted:2019-03-14
📝 Original message:Apparently I don't have the same experience than others here, what I
encountered is no reject message received for wrong txs, but from what I
understand here it's not unusual to receive reject message for valid
txs, then I don't see how it can be really helpful/relied, given also
that the reject messages are unclear and even can be misleading
As it was written already I found it useful only for debugging purposes,
at least it can give some kind of ideas about what happened,
bitcoin-transactions is implementing the bitcoin protocol but does not
act as a node and does not pretend to fake a node behavior waiting for
example to get the tx back, is the method of sending a getdata for a
given tx to see if it was accepted by a node wrong ? It can't guarantee
100% that it was successful and will propagate but I see that you are
doing completely different things
Le 13/03/2019 à 23:30, Dustin Dettmer via bitcoin-dev a écrit :
> I’ve solved the same problem in a different way.
>
> 1) Submit a transaction
> 2) Collect all reject messages (that have matching txid in the reject
> data)
> 3) Wait 16 seconds after first error message received (chosen
> semirandomly from trial and error) before processing errors
> 4) Wait for our txid to be submitted back to us through the mempool,
> if we get it notify success and delete all pending error events
> 5) Signal failure with the given reject code if present (after the 16
> seconds have elapsed)
> 6) If no error or success after 20 seconds, signal timeout failure
>
> This works fairly well in testing. Newer transaction types seem to
> generate reject codes 100% of the time (from at least one node when
> sending to 4 nodes) so this culling / time delay approach is
> essentially required.
>
> On a related note: One issue is that RBF attempts with too small a fee
> and accidental double spends (with enough fee for 1 tx but not a RBF)
> both generate the same reject code: not enough fee.
>
> A new reject code for RBF based too small of fee would definitely make
> for a better user experience as I’ve seen this exact problem create
> confusion for users.
>
> Removing reject codes would make for a much worse user experience.
> “Your tx failed and we have no idea why” would be the only message and
> it would require waiting for a full timeout.
>
> On Wed, Mar 13, 2019 at 3:16 PM Oscar Guindzberg via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> > I'd like to better understand this, but it would be easier to just
> > read the code than ask a bunch of questions. I tried looking for the
> > handling of reject messages in Android Bitcoin Wallet and BitcoinJ
> > and didn't really find and handling other than logging exceptions.
> > Would you mind giving me a couple pointers to where in the code
> > they're handled?
>
> https://github.com/bitcoinj/bitcoinj/blob/master/core/src/main/java/org/bitcoinj/core/TransactionBroadcast.java#L93-L108
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> <mailto: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
--
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190314/49975469/attachment-0001.html>

2023-06-07 18:16:38

- reply

📅 Original date posted:2019-03-07
📝 Original message:Bitcoin-transactions did use this "feature", but does not rely on it any
longer since I observed some strange behavior sometimes (no reject
message for bad tx, with suprnova for example as far as I remember),
then it doublechecks using getdata to see if the tx is in mempool
Indeed you can't trust what a node tells you with or without reject
(idem for getdata but more difficult to fake and better than nothing)
Then I don't see any problem to remove it, taking into account also that
the error message is too vague to be really helpful
https://github.com/bitcoin/bitcoin/issues/11891
Le 06/03/2019 à 01:53, Marco Falke via bitcoin-dev a écrit :
> Bitcoin Core may send "reject" messages as response to "tx", "block" or
> "version" messages from a network peer when the message could not be accepted.
>
> This feature is toggled by the `-enablebip61` command line option and has been
> disabled by default since Bitcoin Core version 0.18.0 (not yet released as of
> time of writing). Nodes on the network can not generally be trusted to send
> valid ("reject") messages, so this should only ever be used when connected to a
> trusted node. At this time, I am not aware of any software that requires this
> feature, and I would like to remove if from Bitcoin Core to make the codebase
> slimmer, easier to understand and maintain. Let us know if your application
> relies on this feature and you can not use any of the recommended alternatives:
>
> * Testing or debugging of implementations of the Bitcoin P2P network protocol
> should be done by inspecting the log messages that are produced by a recent
> version of Bitcoin Core. Bitcoin Core logs debug messages
> (`-debug=<category>`) to a stream (`-printtoconsole`) or to a file
> (`-debuglogfile=<debug.log>`).
>
> * Testing the validity of a block can be achieved by specific RPCs:
> - `submitblock`
> - `getblocktemplate` with `'mode'` set to `'proposal'` for blocks with
> potentially invalid POW
>
> * Testing the validity of a transaction can be achieved by specific RPCs:
> - `sendrawtransaction`
> - `testmempoolaccept`
>
> * Wallets should not use the absence of "reject" messages to indicate a
> transaction has propagated the network, nor should wallets use "reject"
> messages to set transaction fees. Wallets should rather use fee estimation
> to determine transaction fees and set replace-by-fee if desired. Thus, they
> could wait until the transaction has confirmed (taking into account the fee
> target they set (compare the RPC `estimatesmartfee`)) or listen for the
> transaction announcement by other network peers to check for propagation.
>
> I propose to remove "reject" messages from Bitcoin Core 0.19.0 unless there are
> valid concerns about its removal.
>
> Marco
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms

2023-06-07 18:16:30

- reply

📅 Original date posted:2019-02-18
📝 Original message:Then, since you wrote this proposal, maybe you should add the very
precise description of the signing/verification process since it is
documented nowhere
I don't get the use of the speech regarding keys while it should focus
on signatures which are summarized in a vague sentence inspired by your
ref [2] with a not very logical link to the next paragraph stating that
r,s should be 32B and the whole thing 65B with a header of 1B, you did
not invent it, that's probably the rule, not sure where it is specified
again and for what purpose, the header seems completely of no use
especially when you extend to segwit/bech32 since you just have to check
that related compressed key matches
Le 17/02/2019 à 15:14, Christopher Gilliard via bitcoin-dev a écrit :
> I have written up a proposed BIP. It has to do with Signature formats
> when using Bitcoin Private keys. It is
> here: https://github.com/cgilliard/BIP/blob/master/README.md
>
> This BIP was written up as suggested in this github
> issue: https://github.com/bitcoin/bitcoin/issues/10542
>
> Note that the proposal is inline with the implementation that Trezor
> implemented in the above issue.
>
> Any feedback would be appreciated. Please let me know what the steps
> are with regards to getting a BIP number assigned or any other process
> steps required.
>
> Regards,
> Chris
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190218/971a925a/attachment-0001.html>

2023-06-07 18:16:30

- reply

📅 Original date posted:2019-02-18
📝 Original message:Ah, OK, that's of course a good thing to document this undocumented (and
strange) stuff, as a matter of fact I implemented it after reading your
post (because this was on my todo list since some time) and got annoyed
quickly, mainly by what is doing formatMessageForSigning (which is quite
trivial when you know it but would be good to document precisely)
So, yes, it's a good idea to write this, regarding the header I still
don't see the use, testing the different possibilities is not a big
deal, why the signature format is not the same as transactions one is
mysterious too
Le 19/02/2019 à 00:24, Christopher Gilliard a écrit :
> The proposal includes actual code that does verification, but I didn't
> include code for signing. I thought it could be inferred, but I could
> at least include a description of how to sign. I am not sure exactly
> what part you are referring to by "keys speech", but the signatures
> are done by ECDSA keys so it's hard to not include anything about keys
> even though that's not the main topic. The "Background on ECDSA keys"
> section was mainly meant to give background about what kind of keys
> Bitcoin uses, for people who already know that they can easily skip
> this section so I would probably think it's best just to leave in.
> Maybe it should be at the end as an addendum though. Yes, I did not
> invent any of this, I'm just documenting what people actually seem to
> do because I had to verify signatures as part of a project I'm working
> on. I would have liked to have had this document when I started the
> project so I thought it might be useful to others since as far as I
> can tell this was not specified anywhere. The reason for including
> this data in the header is the same that compressed/uncompressed is
> included in the header so that you know which type of key the
> signature is from and you don't have to try all options to see if any
> matches. This is why Trezor did that way and why I documented it. I'm
> sure there are other ways to do this, but since this is out there in
> the field being used and is a reasonable solution, I thought I'd write
> it up.
>
> On Mon, Feb 18, 2019 at 2:59 PM Aymeric Vitte <vitteaymeric at gmail.com
> <mailto:vitteaymeric at gmail.com>> wrote:
>
> Then, since you wrote this proposal, maybe you should add the very
> precise description of the signing/verification process since it
> is documented nowhere
>
> I don't get the use of the speech regarding keys while it should
> focus on signatures which are summarized in a vague sentence
> inspired by your ref [2] with a not very logical link to the next
> paragraph stating that r,s should be 32B and the whole thing 65B
> with a header of 1B, you did not invent it, that's probably the
> rule, not sure where it is specified again and for what purpose,
> the header seems completely of no use especially when you extend
> to segwit/bech32 since you just have to check that related
> compressed key matches
>
> Le 17/02/2019 à 15:14, Christopher Gilliard via bitcoin-dev a écrit :
>> I have written up a proposed BIP. It has to do with Signature
>> formats when using Bitcoin Private keys. It is
>> here: https://github.com/cgilliard/BIP/blob/master/README.md
>>
>> This BIP was written up as suggested in this github
>> issue: https://github.com/bitcoin/bitcoin/issues/10542
>>
>> Note that the proposal is inline with the implementation that
>> Trezor implemented in the above issue.
>>
>> Any feedback would be appreciated. Please let me know what the
>> steps are with regards to getting a BIP number assigned or any
>> other process steps required.
>>
>> Regards,
>> Chris
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> --
> Move your coins by yourself (browser version): https://peersm.com/wallet
> Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
> Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
> Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
> Get the torrent dynamic blocklist: http://peersm.com/getblocklist
> Check the 10 M passwords list: http://peersm.com/findmyass
> Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
> Peersm : http://www.peersm.com
> torrent-live: https://github.com/Ayms/torrent-live
> node-Tor : https://www.github.com/Ayms/node-Tor
> GitHub : https://www.github.com/Ayms
>
--
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190218/c0f13f92/attachment.html>

2023-06-07 18:15:56

- reply

📅 Original date posted:2019-01-03
📝 Original message:What I have in mind is in my latest reply (difficult to have some kind
of fluent discussions on this list given the moderation and delayed posts)
I would just add that the derivation method (indeed something like what
you are sketching below) should estimate that there is enough entropy
from the secret, if not just throw
Le 02/01/2019 à 19:06, James MacWhyte via bitcoin-dev a écrit :
> On Wed, Jan 2, 2019 at 3:40 AM Alan Evans via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
>
> I think any method that doesn't use real entropy, but some fake
> source of randomness, such as a book is asking to be hacked and so
> is not a reasonable idea.
>
> If an algorithm for book text to BIP39 sentence ever became well
> used, common books will be systematically searched for accounts.
> People will also choose their favourite passages, so I would
> expect to see collisions.
>
>
> I tend to have this conversation a lot ;) I'm not sure what Aymeric
> has in mind, but my suggestions are for use by the small few who
> properly understand how these things work. I am not suggesting
> blockchain.info <http://blockchain.info> require every user to choose
> a book passage to use as their backup phrase!
>
> There are so many small things that could be done to make a text input
> unique. Choose the X number of words from the start of the Nth
> sentence. Replace all punctuation with exclamation points. Combine two
> sentences from different pages. It would be nigh impossible to brute
> force any of these, and would require hints/instructions from the
> owner to recover.
>
> But I admit if this is not intended for standardization, discussing it
> on this mailing list is probably unwarranted.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190104/d8b994a9/attachment.html>

2023-06-07 18:15:55

- reply

📅 Original date posted:2019-01-01
📝 Original message:You are simplifying too much what I am suggesting
What I am suggesting is: set a derivation method for BIP39 like for
BIP32 (having the seed for BIP32 and not the derivation path is just
like having nothing) and use this derivation method from a "book" (a
"book" being a book, a document, a link, an image, whatever your secret
can be), based on the fact that you will easily find from this
derivation method "valid" BIP39 seeds (even if BIP39 does not enforce
anything regarding valid phrases, everything can be valid as you
mention, and this does not help in fact)
The derivation method will just define the way you select the words in
the secret, and if everybody chooses the bible as the secret then this
will not change the fact that it will be impossible to find the real
seed without knowing the derivation path
Then you don't need to write the seed, you can easily plausible deny it,
you can easily pass it to the family (using a passphrase does not say to
them where they are supposed to use it)
"people lost"--> people think that there is some magic with BIP39 that
will save them whatever they do (ie they don't even care of managing
correctly the many easy to generate BIP39 seeds they are using) where
they will always recover their seed and keys from BIP39/44/49, of course
this does not work at all
Le 31/12/2018 à 17:52, Alan Evans a écrit :
> > Using some algorithm to take some input and generate a bip39 phrase
> that you can use with any bip39 wallet sounds perfectly reasonable.
>
> I think any method that doesn't use real entropy, but some fake source
> of randomness, such as a book is asking to be hacked and so is not a
> reasonable idea.
>
> If an algorithm for book text to BIP39 sentence ever became well used,
> common books will be systematically searched for accounts. People will
> also choose their favourite passages, so I would expect to see collisions.
>
> You should also note that BIP39 does not need input that is from the
> word list. You can use _any text as its input_, the word list and
> checksum check is just recommended to be a warning, but again, text
> chosen from public sources or common phrases is a bad idea for many
> reasons.
>
> From BIP0039:
> /> The conversion of the mnemonic sentence to a binary seed is
> completely independent from generating the sentence. This results in
> rather simple code; *there are no constraints on sentence structure*
> and clients are free to implement their own wordlists or even whole
> sentence generators, allowing for flexibility in wordlists for typo
> detection or other purposes./
> /> Although using a mnemonic not generated by the algorithm described
> in "Generating the mnemonic" section is possible, this is not advised
> and software must compute a checksum for the mnemonic sentence using a
> wordlist and issue a warning if it is invalid./
>
> What you could do is use a regular true random BIP39 sentence in
> conjunction with a phrase from a book as the "passphrase" giving you
> that plausible deniability, right up to the point you put that in your
> will or tell someone, i.e. for the "what if something happens to me"
> case. Though I still think redirecting people to a book phase is risky
> for this, e.g. books have editions, there may be a change in the key
> place.
>
> From BIP0039:/
> /
> /> The described method also provides plausible deniability, because
> every passphrase generates a valid seed (and thus a deterministic
> wallet) but only the correct one will make the desired wallet available./
>
> Alan
>
> P.S. "I have seen many people completely lost with their wallets
> because of [BIP39]": I would say "despite" not "because". These people
> would have lost/miss recorded a BIP32 hex seed as well.
>
>
> On Thu, 27 Dec 2018 at 11:02, Aymeric Vitte via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
>
> Le 26/12/2018 à 19:54, James MacWhyte a écrit :
>>
>> On Wed, Dec 26, 2018 at 11:33 AM Aymeric Vitte
>> <vitteaymeric at gmail.com <mailto:vitteaymeric at gmail.com>> wrote:
>>
>> so, even with a tool like yours, they can be misleaded, for
>> example trying a few words to replace the missing/incorrect
>> one, get a valid seed and stay stuck with it forever trying
>> to play with BIP44/49 to find their keys
>>
>>
>> Just a small detail, but my tool actually looks up all the
>> possible combinations and then finds which one has been used
>> before by looking for past transactions on the blockchain.
>> Therefore, it won't tell you your phrase is correct unless it is
>> a phrase that has actually been used before (preventing what you
>> described).
>
> I saw that your tool was querying blockchain.info
> <http://blockchain.info>, but it cannot guess what derivation path
> was used and if it is a standard one what addresses were used, and
> even if successful it works only for bitcoin (so maybe it should
> just output the ~1500 possible phrases and/or xprv, and be
> completely offline, this is still doable for people)
>
>>
>> Using some algorithm to take some input and generate a bip39
>> phrase that you can use with any bip39 wallet sounds perfectly
>> reasonable.
>
> I forgot to mention that this can help also solving the "what if
> something happens to me" case giving to the family the seed and
> the parameter(s) for the derivation path, or an easy way to find
> it (better than something like: remind this passphrase, take the
> sha256 of it, then use some other stuff to find the encryption
> algo, take n bytes of the hash, use it to decode my wallet or my
> seed... and then everybody looking at you like crazy)
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> <mailto: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/20190101/916f37ee/attachment-0001.html>

2023-06-07 18:15:52

- reply

📅 Original date posted:2018-12-27
📝 Original message:Le 26/12/2018 à 19:54, James MacWhyte a écrit :
>
> On Wed, Dec 26, 2018 at 11:33 AM Aymeric Vitte <vitteaymeric at gmail.com
> <mailto:vitteaymeric at gmail.com>> wrote:
>
> so, even with a tool like yours, they can be misleaded, for
> example trying a few words to replace the missing/incorrect one,
> get a valid seed and stay stuck with it forever trying to play
> with BIP44/49 to find their keys
>
>
> Just a small detail, but my tool actually looks up all the possible
> combinations and then finds which one has been used before by looking
> for past transactions on the blockchain. Therefore, it won't tell you
> your phrase is correct unless it is a phrase that has actually been
> used before (preventing what you described).
I saw that your tool was querying blockchain.info, but it cannot guess
what derivation path was used and if it is a standard one what addresses
were used, and even if successful it works only for bitcoin (so maybe it
should just output the ~1500 possible phrases and/or xprv, and be
completely offline, this is still doable for people)
>
> Using some algorithm to take some input and generate a bip39 phrase
> that you can use with any bip39 wallet sounds perfectly reasonable.
I forgot to mention that this can help also solving the "what if
something happens to me" case giving to the family the seed and the
parameter(s) for the derivation path, or an easy way to find it (better
than something like: remind this passphrase, take the sha256 of it, then
use some other stuff to find the encryption algo, take n bytes of the
hash, use it to decode my wallet or my seed... and then everybody
looking at you like crazy)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20181227/2d00c181/attachment-0001.html>

2023-06-07 18:15:52

- reply

📅 Original date posted:2018-12-26
📝 Original message:Another drawback I think is that people are not using it as seeds, they
just go to a wallet sw which proposes a new seed, write it somewhere, do
something with the wallet and forget about it, go to another one, create
another wallet, etc
Apparently it is not very well known even here that the probabilities
are very high to get a valid BIP39 seed even with 24 words, so, even
with a tool like yours, they can be misleaded, for example trying a few
words to replace the missing/incorrect one, get a valid seed and stay
stuck with it forever trying to play with BIP44/49 to find their keys
Probably what I am suggesting is not new (and therefore maybe not a good
suggestion): given a secret seed (a book, a document, a link, etc) and a
derivation path (an algo with secret parameter(s) to derive/order the
words and select the valid bip39 sequences), you get your BIP39 seeds
and don't have to write them
Of course we don't have to use necessarilly BIP39 for this but this is
what we have everywhere and this is what is compatible with it, then you
could use the same or a fake written "not very well hidden" BIP39 seed
to plausibly deny your real wallet
Le 25/12/2018 à 01:30, James MacWhyte a écrit :
>
>
> On Mon, Dec 24, 2018 at 2:48 PM Aymeric Vitte via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
>
> I don't see very well why it's easier to write n words that you
> cannot choose rather than a 32B BIP32 hex seed, and I have seen
> many people completely lost with their wallets because of this
>
>
> In practice it has quite a few qualities that make it a bit more
> resilient for physical (written) storage.
>
> If a few letters of a word get rubbed off or otherwise become
> illegible, it is pretty easy for a native speaker to figure out what
> the word is supposed to be. Even a non-native speaker could look
> through the word list and figure out which word fits. Missing
> characters in a hex string require more advanced brute force
> searching, which the average user isn't capable of.
>
> Additionally, having the bits grouped into words makes a more serious
> recovery easier. If you lose one entire word, it can be brute forced
> in about 5 minutes on a normal pc, even if you don't know which
> position the missing word is in (I have published a tool that does
> just this: https://jmacwhyte.github.io/recovery-phrase-recovery). If
> you are missing two words, you can brute force it in about a week
> (napkin math).
>
> If you were missing a random chunk of a hex string, I don't know how
> you'd go about brute forcing that in a timely manner.
>
> As an aside, from a UX standpoint we've seen that the 12 words don't
> *look* important so people don't take them seriously (and they get
> lost). A hex string or equivalent would look more password-y, and
> therefore would most likely be better protected by users.
>
> James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20181226/e047093a/attachment-0001.html>

2023-06-07 18:15:51

- reply

📅 Original date posted:2018-12-23
📝 Original message:Exactly
This is surprising, I would have expected the probabilities to be much
more lower
It just means that scanning whatever (secret) book, document, link, etc,
you will find easily BIP39 seeds, even of 24 words
So, it just means that you don't have to write your seed since you can
recover it that way, given a secret source and specific algo with custom
parameters, this could be used for plausible deniability also
For now I still dislike BIP39 and alike (because I don't see very well
why it's easier to write n words that you cannot choose rather than a
32B BIP32 hex seed, and I have seen many people completely lost with
their wallets because of this), but I could change my mind, and despite
of further improvements for this ratio, could what I am suggesting make
sense?
Le 23/12/2018 à 19:46, Pavol Rusnak a écrit :
> On 22/12/2018 00:58, Aymeric Vitte via bitcoin-dev wrote:
>> Has anybody already looked at this: given N randomly chosen words
>> belonging to a BIP39 2048 words dictionary, what is the probability to
>> get a "valid" BIP39 seed (ie with the right checksum)?
> 1:256 for 24 words
> 1:16 for 12 words
>
> This ratio is not too great and will be improved in the upcoming SLIP39
> standard: https://github.com/satoshilabs/slips/blob/master/slip-0039.md
>

2023-06-07 18:15:51

- reply

📅 Original date posted:2018-12-21
📝 Original message:Has anybody already looked at this: given N randomly chosen words
belonging to a BIP39 2048 words dictionary, what is the probability to
get a "valid" BIP39 seed (ie with the right checksum)?
The result looks (very) surprising to me and might have some use cases,
just would like to know if this topic has already been discussed before
going further
--
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms

2023-06-07 18:14:14

- reply

📅 Original date posted:2018-08-30
📝 Original message:Le 28/08/2018 à 20:36, Jonas Schnelli via bitcoin-dev a écrit :
> I’d like to hear some concrete use-cases for a such block explorer(ish) API.
https://github.com/Ayms/bitcoin-transactions which is somewhere
bitcoin-cli outside of bitcoin core with no wallet, which implies that
you don't want to mix/provide your wallet with/to the app creating your
transactions and/or you don't want to use wallet sw
Problem: quasi nobody succeeds to use it (and probably this trend is
unlikely to revert), that's why there is https://peersm.com/wallet which
is querying the info outside and output the right command to use with
the tool (or output the transaction if people put their keys, which is
of course not advised unless they are sure that the corresponding
addresses are dead ones)
It is planned to put the app for the advanced mode (ie people must know
all the parameters) as an offline one inside browsers, then back to the
above problem...
So probably the offline mode should include a phase where the tool
connects to some APIs/explorers like the one suggested here before
switching to the offline mode to enter the keys, this will always be not
very secure for the query phase unless it can become something
decentralized (and usable the same way on different networks), which as
far as I understand is envisioned here
--
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms

2023-06-07 18:13:53

- reply

📅 Original date posted:2018-07-31
📝 Original message:I know this list is not to advertise personal projects but
https://peersm.com/wallet might be of some interest, this is the web
interface for https://github.com/Ayms/bitcoin-transactions since
apparently quasi nobody succeeds to use it
As far as I know (and surprisingly) this is the only online tool that
converts bech32 addresses (Sipa's one does not output something
understandable by everybody, the tool is using his code), the only one
that converts from any address to any address, maybe the only one that
decodes simply redeem scripts and probably the only one that allows to
create transactions by its own (the advanced mode is not implemented for
now but will be soon)
Ideally it should be an offline tool if there is some incentive to do
so, so of course it is not advised to use his private keys for now
Maybe they are mistaken but some users are reporting invalid bech32
addresses from their Electrum wallet, after segwit, bech32 confusion
seems to be the topic of the moment
Regards
Aymeric
--
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms

2023-06-07 18:13:53

- reply

📅 Original date posted:2018-08-01
📝 Original message:You are right, that's what I have been saying for online services that
ask for private keys, and even the seeds
The problem is that people can't refrain to put their keys for example
to get "free" coins, typically they try to use bitcoin-transactions,
don't succeed and go put their seeds in an online service
At least it gives an alternative, private keys are optional and the tool
will output the command to use with bitcoin-transactions, and if they
want to put directly their keys, then...
"Move your coins by yourself" refers more to "don't get trapped by your
wallet(s) or things that you don't master like multisig, segwit, bech32,
etc"
As I said the idea would be to end up with an offline tool should some
people support/finance the effort
Le 01/08/2018 à 07:45, Marcel Jamin a écrit :
> IMHO you should almost never publish a service that asks users for
> private keys.
>
> A warning isn't enough. Your server might get compromised.
>
> "Move your coins by yourself" isn't even correct if your server is
> involved.
>
> On Tue, 31 Jul 2018 at 13:26, Aymeric Vitte via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> I know this list is not to advertise personal projects but
> https://peersm.com/wallet might be of some interest, this is the web
> interface for https://github.com/Ayms/bitcoin-transactions since
> apparently quasi nobody succeeds to use it
>
> As far as I know (and surprisingly) this is the only online tool that
> converts bech32 addresses (Sipa's one does not output something
> understandable by everybody, the tool is using his code), the only one
> that converts from any address to any address, maybe the only one that
> decodes simply redeem scripts and probably the only one that allows to
> create transactions by its own (the advanced mode is not
> implemented for
> now but will be soon)
>
> Ideally it should be an offline tool if there is some incentive to do
> so, so of course it is not advised to use his private keys for now
>
> Maybe they are mistaken but some users are reporting invalid bech32
> addresses from their Electrum wallet, after segwit, bech32 confusion
> seems to be the topic of the moment
>
> Regards
>
> Aymeric
>
> --
> Bitcoin transactions made simple:
> https://github.com/Ayms/bitcoin-transactions
> Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
> Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
> Get the torrent dynamic blocklist: http://peersm.com/getblocklist
> Check the 10 M passwords list: http://peersm.com/findmyass
> Anti-spies and private torrents, dynamic blocklist:
> http://torrent-live.org
> Peersm : http://www.peersm.com
> torrent-live: https://github.com/Ayms/torrent-live
> node-Tor : https://www.github.com/Ayms/node-Tor
> GitHub : https://www.github.com/Ayms
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180801/b5b352ad/attachment.html>

2023-06-07 18:11:35

- reply

📅 Original date posted:2018-04-10
📝 Original message:Indeed, this impacts jsbn only normally since all others from the time
getRandomValues was available are supposed to implement both
Le 10/04/2018 à 15:32, Jason Davies a écrit :
>>> Note that even with v1.4, it still does not use high-quality entropy for
>>> Internet Explorer, because getRandomValues is provided under window.msCrypto
>>> for that browser.
>> I don't know for that one, what was the issue?
> I simply meant that Internet Explorer implements the Web Cryptography API under
> window.msCrypto instead of window.crypto. Thus, unless
> msCrypto.getRandomValues is used, high-quality entropy will not have been used
> by any of these libraries under Internet Explorer.
>
> --
> Jason Davies, https://www.jasondavies.com/
>
--
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms

2023-06-07 18:11:34

- reply

📅 Original date posted:2018-04-10
📝 Original message:I used jsbn in the past, then I made some research too
Apparently window.crypto.getRandomValues was introduced in jsbn mid 2012
(according to the wayback machine, but 2012/2013 does not make any
difference, see below), was available in Chrome since 2011 (but indeed
see "window.crypto.getRandomValues() uses a weak CSPRNG"
https://bugs.chromium.org/p/chromium/issues/detail?id=552749 fixed *end
*of 2015, funny to see that those that did specify the Webcrypto API did
not implement it correctly...), in FF in 2013
(https://website-archive.mozilla.org/www.mozilla.org/firefox_releasenotes/en-US/firefox/21.0/releasenotes/)
, in IE in 2013 and Safari ~2012/2013, at least that's the official
dates for the Webcrypto API implementation, maybe something existed
before, but it's not so easy to seek for the history
The window.crypto.random check is in jsbn since the begining (2006) and
only returns true for Netscape browsers before Netscape 5/6, ie Firefox
(2000), see
https://books.google.fr/books?id=UooAblGoGN8C&pg=PA85&lpg=PA85&dq=browser+appversion+4&source=bl&ots=dVijsOR0ov&sig=6SnElm56-bAvmGlKqUAdoGLAs2A&hl=fr&sa=X&ved=2ahUKEwirhtaqva_aAhUFchQKHQ4JCk4Q6AEwBXoECAAQcQ#v=onepage&q=browser%20appversion%204&f=false)
>From the existing tools, there was not only jsbn, everybody was using
Math.random (sjcl, cryptoJS, forge, etc) with different implementations
and everybody did put a note stating that it might be insecure with an
"improvement to come" comment
We can probably assume that nobody was using Netscape any longer when
Bitcoin started
The conclusion seems to be that at least all wallets generated by js
tools inside browsers since bitcoin exists until 2011 are impacted by
the Math.random weakness if applicable to the related implementations,
the Math.random or RC4 (Chrome) weakness between 2011 and 2013, and RC4
weakness for Chrome users until end of 2015
And all wallets using jsbn are impacted by Math.random and RC4 until
2013 (or end 2015 for Chrome), then still by the RC4 fallback step after
> Note that even with v1.4, it still does not use high-quality entropy
for Internet Explorer, because getRandomValues is provided under
window.msCrypto for that browser
I don't know for that one, what was the issue?
Le 10/04/2018 à 10:51, Jason Davies via bitcoin-dev a écrit :
> On 10 Apr 2018, at 00:39, mus at musalbas.com wrote:
>
>> The original disclosure didn't contain any information about the library
>> in question, so I did some digging.
>>
>> I think that the vulnerability disclosure is referring to a pre-2013
>> version of jsbn, a JavaScript crypto library. Before it used the CSRNG
>> in the Web Crypto API, it tried to use nsIDOMCrypto, but incorrectly did
>> a string comparison when checking the browser version.
>>
>> In practice though, this doesn't really matter, because
>> navigator.appVersion < "5" returns true anyway for old browsers. The
>> real issue is that modern browsers don't have window.crypto.random
>> defined, so Bitcoin wallets using a pre-2013 version of jsbn may not be
>> using a CSPRNG, when run on a modern browser.
> Yes, it looks like high-quality entropy via crypto.getRandomValues was only
> added in Tom Wu's latest version (v1.4) in July 2013.
>
> Note that even with v1.4, it still does not use high-quality entropy for
> Internet Explorer, because getRandomValues is provided under window.msCrypto
> for that browser.
>
> http://www-cs-students.stanford.edu/~tjw/jsbn/rng.js
>
>> As is noted though, even if a CSPRNG is used, the library passes the
>> output of the CSPRNG through RC4, which generates some biased bits,
>> leading to possible private key recovery.
> I think this is the real issue: even if high-quality entropy is utilised, the
> RNG is RC4-based, which is known to generate biased output.
>
> Finally, note that even Chrome used RC4 for crypto.getRandomValues at one
> point (as recently as 2015)!
>
> https://bugs.chromium.org/p/chromium/issues/detail?id=552749
>
> --
> Jason Davies, https://www.jasondavies.com/
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180410/5f3954ea/attachment-0001.html>

2023-06-07 18:10:49

- reply

📅 Original date posted:2018-02-13
📝 Original message:I was thinking to post something very similar on this list but not sure
that it would get some kind of interest
Not sure how and if it can be done (ie license modification) but the
reuse of the bitcoin core code can allow even a child to launch a fork
and this mess should stop, maybe people like to get "free" coins but
they are misleaded, they can lose everything and there are some more
vicious side effects like replay protection collisions between forks,
this is already happening, nobody seems to care but I wrote:
Bitcoin Tartuffe, the ultimate fork - User guide: How to create your
bitcoin fork in 5mn, fool everybody and become rich
https://www.linkedin.com/pulse/user-guide-how-create-your-bitcoin-fork-5mn-fool-everybody-vitte
--> this is a parody of course but very close to the reality, some info
are intentionally wrong
The madness of bitcoin forks: risk, reward and ruin
https://www.linkedin.com/pulse/madness-bitcoin-forks-risk-reward-ruin-aymeric-vitte/
I don't think that it really impacts bitcoin itself but this is
definitely too easy for people to fork the bitcoin core code and launch
some shxtty fork
Probably nobody here follow this, as an example (among plenty) see this
https://bitcointalk.org/index.php?topic=2515675.msg30173307#msg30173307
completely absurd mess
Le 13/02/2018 à 13:25, JOSE FEMENIAS CAÑUELO via bitcoin-dev a écrit :
> Hi,
>
> Bitcoin is licensed under the MIT license (https://github.com/bitcoin/bitcoin/blob/master/COPYING <https://github.com/bitcoin/bitcoin/blob/master/COPYING>) which is one of the most permissive licenses widely in use.
> While this almost restriction-less license has proved useful to many software projects, I think it could be wise to question its current suitability for this project, given the recent history.
>
> The difficulty among the general population to distinguish between Bitcoin (the protocol and software) and bitcoin (the currency) arises spontaneously from the intimate entanglement of both.
> The current list of Bitcoin lookalikes includes: Bitcoin Cash, Bitcoin Gold, Bitcoin Diamond, Bitcoin God, Bitcoin Clashic, Super Bitcoin, Bitcoin Hot, Bitcoin X, Oil Bitcoin, Bitcoin World, Lightning Bitcoin...
>
> This recent flurry of hard forks is, IMHO, exacerbating the confusion about the very nature of the project, and harming it in many ways.
>
> Although the liberal MIT license is (rightfully) beneficial to many other projects, companies and individuals, it is my belief that several projects are unfairly taking advantage of this generous license to attack Bitcoin (both the software and the currency), confuse the public, and gain personal profit in a way that is severely harming the Bitcoin ecosystem.
>
> Therefore, I’d like to raise the possibility of amending the MIT license in a simple way, by adding a line such as:
>
>
> ***
> NO PART OF THIS SOFTWARE CAN BE INCLUDED IN ANY OTHER PROJECT THAT USES THE NAME BITCOIN AS PART OF ITS NAME AND/OR ITS MARKETING MATERIAL UNLESS THE SOFTWARE PRODUCED BY THAT PROJECT IS FULLY COMPATIBLE WITH THE BITCOIN (CORE) BLOCKCHAIN
> ***
>
> (This is just an approximation. A final version would probably have to include a restriction to some soundalikes like BITKOIN, BIITCOIN,…)
>
> This way, I could legitimate use this software to create my own crypto coin, or use it in Ethereum, Litecoin or any of the other legitimate cryptos, but I could not make my “Bitcoin Whatever” fork and keep using this software as the basis for it. I could also fork the bitcoin blockchain to create “Bcoin lightspeed” but not “Bitcoin lightspeed” for instance.
>
> I know this would probably not prevent the explosion of forks in the future, but maybe it could help mitigate the confusion among the users and the harm to this community. Even if its enforceability is dubious, at least any infringing project would be exposed to some liability. I see myself some possible loopholes the way the license addendum is written. My intention is not to arrive immediately to a final wording but to know if there is some value to the idea of changing the license with this purpose.
>
>
> Jose Femenias
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms

2023-06-07 18:10:47

- reply

📅 Original date posted:2018-02-13
📝 Original message:No, the problem is not bitcoin being under any kind of attack by the
forks for me, but the forks fooling people because, again, reusing the
bitcoin core code is too easy
I don't know if there can be a legal solution to this which would keep
some open source aspect of the code, but at least it deserves to be studied
Le 13/02/2018 à 16:24, Jameson Lopp via bitcoin-dev a écrit :
> If I'm understanding the problem being stated correctly:
>
> "Bitcoin is under a branding attack by fork coins."
>
> The proposed solution is to disincentivize fork coins from using the
> word Bitcoin by altering the license terms. I'm not a lawyer, but it
> seems to me that the words of the license are basically useless unless
> there is an entity that intends to make use of court systems to
> threaten noncompliant projects into submission.
>
> In my opinion, the perceived attack on Bitcoin here is social /
> marketing-based, thus it makes sense that any defense against said
> attack should also be social / marketing-based. I don't think that
> Bitcoin should be reliant upon courts or governments to defend itself
> against attacks of any form.
>
> On Tue, Feb 13, 2018 at 9:25 AM, Natanael via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
>
>
> Den 13 feb. 2018 15:07 skrev "JOSE FEMENIAS CAÑUELO via
> bitcoin-dev" <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>>:
>
> ***
> NO PART OF THIS SOFTWARE CAN BE INCLUDED IN ANY OTHER PROJECT
> THAT USES THE NAME BITCOIN AS PART OF ITS NAME AND/OR ITS
> MARKETING MATERIAL UNLESS THE SOFTWARE PRODUCED BY THAT
> PROJECT IS FULLY COMPATIBLE WITH THE BITCOIN (CORE) BLOCKCHAIN
> ***
>
>
> That's better solved with trademarks. (whoever would be the
> trademark holder - Satoshi?)
>
> This would also prohibit any reimplementation that's not formally
> verified to be perfectly compatible from using the name.
>
> It also adds legal uncertainty.
>
> Another major problem is that it neither affects anybody forking
> older versions of Bitcoin, not people using existing independent
> blockchain implementations and renaming them Bitcoin-Whatsoever.
>
> And what happens when an old version is technically incompatible
> with a future version by the Core team due to not understanding
> various new softforks? Which version wins the right to the name?
>
> Also, being unable to even mention Bitcoin is overkill.
>
> The software license also don't affect the blockchain data.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> <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 transactions made simple: https://github.com/Ayms/bitcoin-transactions
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180213/3121c4e7/attachment-0001.html>

2023-06-07 18:10:16

- reply

📅 Original date posted:2018-01-24
📝 Original message:Indeed... I would have bet that I had other examples with p2pkh this
time but apparently I imagined it
Le 24/01/2018 à 12:35, Gregory Maxwell a écrit :
> On Wed, Jan 24, 2018 at 11:16 AM, Aymeric Vitte <vitteaymeric at gmail.com> wrote:
>> Then what about
>> https://blockchain.info/tx/226a8b08dc46a00e9ecec5567a303a0b354bef3c1674476eb5e4b627b2ace493?format=hex
>> ?
>>
>> Scriptsig:
>>
>> 473044022057a1234709270325e7215200f982546304cf465971cbd55d54231ead54ef1a7802207a82e93ef2b0f87188abe87bccb67ee9d5c650b1b58948e5b1c80ba1b4c43dc301
>>
>> No pubkey...
> Because the pubkey is in the scriptPubKey of vout 0 of
> 40872a376e98a1f8b285827c2ad8c5b3eec7d779d752dc3a4adda5d9bb70f3b5 which
> it is spending.
--
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms

2023-06-07 18:10:16

- reply

📅 Original date posted:2018-01-24
📝 Original message:Then what about
https://blockchain.info/tx/226a8b08dc46a00e9ecec5567a303a0b354bef3c1674476eb5e4b627b2ace493?format=hex
?
Scriptsig:
473044022057a1234709270325e7215200f982546304cf465971cbd55d54231ead54ef1a7802207a82e93ef2b0f87188abe87bccb67ee9d5c650b1b58948e5b1c80ba1b4c43dc301
No pubkey...
Le 24/01/2018 à 11:31, Gregory Maxwell a écrit :
> On Wed, Jan 24, 2018 at 10:24 AM, Aymeric Vitte <vitteaymeric at gmail.com> wrote:
>> out the fact that pubkey is there now even for standard p2pkh
>> transactions and it was not the case some time ago
>>
>> But I never got any answer regarding what motivated this change
>> (compared to the previous behavior) and when, so whether I am missing
>> something obvious, whether nobody wants to answer
> No such behaviour ever existed, you are simply mistaken.
--
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms

2023-06-07 18:10:15

- reply

📅 Original date posted:2018-01-24
📝 Original message:34 bytes in fact
I have asked already the question at least twice on this list pointing
out the fact that pubkey is there now even for standard p2pkh
transactions and it was not the case some time ago
But I never got any answer regarding what motivated this change
(compared to the previous behavior) and when, so whether I am missing
something obvious, whether nobody wants to answer
Txs without pubkey are now rejected then what is the element in the code
(protocol, version, etc) that "decided" this?
Le 24/01/2018 à 05:25, Gregory Maxwell via bitcoin-dev a écrit :
> On Wed, Jan 24, 2018 at 3:50 AM, Артём Литвинович via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> Greetings.
>>
>> I wanted to ask what was the rationale behind still having both public
>> key and signature in Segwit witness?
>>
>> As is known for a while, the public key can be derived from the
>> signature and a quadrant byte, a trick that is successfully used both
>> in Bitcoin message signing algorithm and in Ethereum transaction
>> signatures. The later in particular suggests that this is a perfectly
>> functional and secure alternative.
>> Leaving out the public key would have saved 33 bytes per signature,
>> which is quite a lot.
>>
>> So, the question is - was there a good reason to do it the old way
>> (security, performance, privacy, something else?), or was it something
>> that haven't been thought of/considered at the time?
> It is slow to verify, incompatible with batch validation, doesn't save
> space if hashing isn't used, and is potentially patent encumbered.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms

2023-06-07 18:09:24

- reply

📅 Original date posted:2018-01-08
📝 Original message:That's the point indeed and the scope is wider than XYZIP-39, even if
what I mean is the very contrary of your point (really bitcoin is
reserved to an elite understanding english/ascii letters?)
This proposal is tailor made for Trezor and does not simplify anything
for people, that's the contrary again
As I suggested in another response to this thread (which was moderated
due probably to some uninteresting parts of the discussion) it's time to
take a break and really make a survey worldwide of what people need,
what they understand and what they need to secure their coins, nobody
has any feedback about this (and maybe does not even care)
Wallets created a big mess implementing non standard things (or things
they thought standard but that are not), or things not intended for the
final use, or things that people can't understand, it's time to correct
this, unless wallets want to keep people tied forever to them (when I
read Trezor or other wallets docs, it's quite misleading, "sending coins
to your wallet", what does it mean? Nothing, and people think it means
something, this should stop now)
And again, I don't see the point of wordlist (in addition in a language
that they don't understand) compared to backing up a 32B hex string
(that you can encrypt different ways at different places), assuming that
the hex format can be made available in all languages
"yet I would not advise users to use a wordlist that might not have
support across multiple wallet implementations, resulting in lock-in or
worse"--> this single sentence shows how the whole model is wrong and
how you think that you can lock people
Le 08/01/2018 à 15:54, Greg Sanders via bitcoin-dev a écrit :
> Let me re-phrase: Is it a known thing for users to actually use it?
>
> On Mon, Jan 8, 2018 at 9:52 AM, Matias Alejo Garcia <ematiu at gmail.com
> <mailto:ematiu at gmail.com>> wrote:
>
>
>
> On Mon, Jan 8, 2018 at 11:34 AM, Greg Sanders via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> Has anyone actually used the multilingual support in bip39?
>
>
>
> Copay (and all its clones) use it.
>
>
>
>
>
>
> If a feature of the standard has not been(widely?) used in
> years, and isn't supported in any major wallet(?), it seems
> indicative it was a mistake to add it in the first place,
> since it's a footgun in the making for some poor sap who can't
> even read English letters when almost all documentation is
> written in English.
>
> On Mon, Jan 8, 2018 at 6:13 AM, nullius via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> On 2018-01-08 at 07:35:52 +0000, 木ノ下じょな
> <kinoshitajona at gmail.com <mailto:kinoshitajona at gmail.com>>
> wrote:
>
> This is very sad.
>
> The number one problem in Japan with BIP39 seeds is
> with English words.
>
> I have seen a 60 year old Japanese man writing down
> his phrase (because he kept on failing recovery), and
> watched him write down "aneter" for "amateur"...
>
> [...]
>
> If you understand English and can spell, you read a
> word, your brain processes the word, and you can spell
> it on your own when writing down. Not many Japanese
> people can do that, so they need to copy letter for
> letter, taking a long time, and still messing up on
> occasion.
>
> [...]
>
> Defining "everyone should only use English, because
> ASCII is easier to plan for" is not a good way to move
> forward as a currency.
>
>
> Well said. Thank you for telling of these experiences.
> Now please, let’s put the shoe on the other foot.
>
> I ask everybody who wants an English-only mnemonic
> standard to entrust *their own money* to their abilities
> to very, very carefully write this down—then later, type
> it back in:
>
> すさん　たんろ　りゆう　しもん　ていおん　しとう
> とこや　はやい　おうさま　ほくろ　けちゃっふ　たもつ
>
> (Approximate translation: “Whatever would you do if
> Bitcoin had been invented by somebody named Satoshi
> Nakamoto?”)
>
> No, wait: That is only a 12-word mnemonic. We are
> probably talking about a Trezor; so now, hey you there,
> stake the backup of your life’s savings on your ability to
> handwrite *this*:
>
> にあう　しひょう　にんすう　ひえる　かいこう　いのる　ねんし　はあさん　ひこく
> とうく　きもためし　そなた　こなこな　にさんかたんそ　ろんき　めいあん　みわく
> へこむ　すひょう　おやゆひ　ふせく　けさき　めいきょく　こんまけ
>
> Ready to bet your money on *that* as a backup phrase in
> your own hands? No? Then please, stop demanding that
> others risk *their* money on the inverse case.
>
> ----
>
> If you cheat here by having studied Japanese, then
> remember that many Japanese people know English and other
> European languages, too. Then think of how much money
> would be lost by your non-Japanese-literate family and
> friends—if BIP 39 had only Japanese wordlists, and your
> folks needed to wrestle with the above phrases as their
> “mnemonics”.
>
> In such cases, the phrases cannot be called “mnemonics” at
> all. A “mnemonic” implies aid to memory. Gibberish in a
> wholly alien writing system is much worse even than
> transcribing pseudorandom hex strings. The Japanese man
> in the quoted story, who wrote “aneter” for “amateur”, was
> not dealing with a *mnemonic*: He was using the world’s
> most inefficient means of making cryptic bitstrings *less*
> userfriendly.
>
> ----
>
> I began this thread with a quite simple request: Is “日本語”
> an appropriate string for identifying the Japanese
> language to Japanese users? And what of the other strings
> I posted for other languages?
>
> I asked this as an implementer working on my own instance
> of the greatest guard against vendor lock-in and stale
> software: Independent implementations. — I asked,
> because obviously, I myself do not speak all these
> different languages; and I want to implement them all. *All.*
>
> Some replies have been interesting in their own right; but
> thus far, nobody has squarely addressed the substance of
> my question.
>
> Most worrisome is that much of the discussion has veered
> into criticism of multi-language support. I opened with a
> question about other languages, and I am getting replies
> which raise a hue and cry of “English only!”
>
> Though I am fluent and literate in English, I am
> uninterested in ever implementing any standard of this
> nature which is artificially restricted to English. I am
> fortunate; for as of this moment, we have a standard
> called “BIP 39” which has seven non-English wordlists, and
> four more pending in open pull requests (#432, #442, #493,
> #621).
>
> I request discussion of language identification strings
> appropriate for use with that standard.
>
> (P.S., I hope that my system did not mangle anything in
> the foregoing. I have seen weird copypaste behaviour mess
> up decomposed characters. I thought of this after I
> searched for and collected some visually fascinating
> phrases; so I tried to normalize these to NFC... It
> should go without saying, easyseed output the Japanese
> perfectly!)
>
>
> --
> nullius at nym.zone | PGP ECC:
> 0xC2E91CD74A4C57A105F6C21B5A00591B2F307E0C
> Bitcoin: bc1qcash96s5jqppzsp8hy8swkggf7f6agex98an7h |
> (Segwit nested:
> 3NULL3ZCUXr7RDLxXeLPDMZDZYxuaYkCnG) (PGP RSA:
> 0x36EBB4AB699A10EE)
> “‘If you’re not doing anything wrong, you have nothing to
> hide.’
> No! Because I do nothing wrong, I have nothing to show.”
> — nullius
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>
>
>
>
> --
> Matías Alejo Garcia
> @ematiu
> Roads? Where we're going, we don't need roads!
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180108/605d1ef0/attachment-0001.html>

2023-06-07 18:09:21

- reply

📅 Original date posted:2018-01-06
📝 Original message:Calm down now and stop your "do you want a" or "link" stupid comments,
whether you are really willing to propose some improvements, whether you
are just posting for nothing
BIP39:
"The length of the derived key is 512 bits (= 64 bytes).
This seed can be later used to generate deterministic wallets using
BIP-0032 or similar methods."
So the derived key is the seed? (derived key... this seed, really?
"similar methods",funny) That's not clear, then why everybody is using
xpriv which corresponds to the first step of the derivation (ie the
derived key)? And why BIP39 does not follow BIP32 recommendation (32B seed)?
Anyway, I don't really care about this stuff in fact, the only
interesting thing in this discussion beside arguing around unclear specs
misleading many people would be if you can convince that BIP39 & co are
really usefull for people (and easier than writing a seed): what
feedback do you have, don't you see how it's a pain in the xss for
everybody?
And if the answer is positive how can you can make it easier for people
(I am amazed too that people know about BIPXYZ, they should not),
probably this discussion will bore people and get moderated, but as
mentioned below, even maybe off topic, the subject is wider
Le 06/01/2018 à 19:28, Alan Evans a écrit :
> > Unfortunately, even "yourself" seems not to know what he is talking
> about (so imagine for other people, 256 bits is advised --> 32B),
> probably that's why you brought this discussion off the list, then
> making recommendations to improve something that is misleading and
> messy is quite dubious
>
> And yet you still fail to read the BIP, do you want a
> link? https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki I
> repeat it says:
>
> between 128 and 512 bits
>
> So, that's between 16 and 64 bytes, the advisory of 256 is clearly a
> minimum.
>
> > That's another thing I completely dislike with BIP39, it ends up
> with xpriv, not the 32B seed
>
> Please also read
> BIP0039 https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki,
> it generates *a BIP32 seed only*, no xpriv, that's completely false,
> then you use BIP0032 as normal with the seed. Because BIP0039 produces
> a seed, your whole argument goes out of the window, you can write the
> seed if that's what you want to do, and throw away the mnemonic.
>
>
>
> On Sat, Jan 6, 2018 at 1:40 PM, Aymeric Vitte <vitteaymeric at gmail.com
> <mailto:vitteaymeric at gmail.com>> wrote:
>
> Unfortunately, even "yourself" seems not to know what he is
> talking about (so imagine for other people, 256 bits is advised
> --> 32B), probably that's why you brought this discussion off the
> list, then making recommendations to improve something that is
> misleading and messy is quite dubious
>
> And maybe you should take a look at what people you are talking to
> are doing before arguing stuff that you apparently don't know very
> well (ie "the length of the *derived *key", not the seed), cf
> https://github.com/Ayms/bitcoin-wallets
> <https://github.com/Ayms/bitcoin-wallets> and even
> https://github.com/Ayms/zcash-wallets (not official but
> https://github.com/zcash/zips/issues/95)
> <https://github.com/Ayms/zcash-wallets>
>
> But as you can notice there is a missing feature, ie to derive the
> wallets from xpriv, there is a comment in the repo why I don't
> like some things "Surprisingly from ~32 bytes keys BIP32 ends up
> with a 78 bytes format to describe them with all the necessary
> information like indexes, parent to possibly allow to revert the tree"
>
> That's another thing I completely dislike with BIP39, it ends up
> with xpriv, not the 32B seed, there are many, many, many posts in
> forums of people fighting to figure out their private keys derived
> from bip39/44/etc
>
> "No offence too" but please keep your advises for yourself, I
> indeed don't read closely inept BIPs, and never said I did not
> like BIP32, that's the contrary, I really like it
>
> Before firing plenty of BIPs that do not fit together people maybe
> should take a break and see what people are doing today (this is
> quite amazing) and why they got stolen
>
> And you seem to know very little about security, if you suspect
> you home printer, then suspect you OS, your hw, etc, (you really
> envision to generate a seed from a mobile device ???) writing 64
> characters is not very difficult for a human being, even easier
> than writing x words of y length
>
> See this too
> https://bitcointalk.org/index.php?topic=2550529.msg26133887#msg26133887
> <https://bitcointalk.org/index.php?topic=2550529.msg26133887#msg26133887>,
> the tutorial was corrected, but basic things are still missing, an
> offline version is when you disconnect from the internet, not when
> you use the "offline version" (assuming that the browser storage
> or other stuff are not used...)
>
> Re-ccing the list because again at a certain point of time the
> theory should look at the reality and adapt accordingly, part of
> the example I gave is off topic for this thread but globally
> (which could become another thread) the message is: the bitcoin
> community should stop making things complicate for people,
> releasing BIPs of no use just ends up with complicating things
> more than it helps, people deserve to understand what they are
> doing, manage their keys by their own and stop syncing useless
> full nodes for every coin to sync their wallets, that's why I made
> the tool, the first people that used it made some outstanding
> mistakes that I did not envision now it's not possible any longer,
> except if they give wrong destination addresses and nobody can't
> do anything about this (btw the primary intent of the tool was for
> myself and you are right for once, I did not know that people
> could do so big mistakes, that's not their fault, I see it now, my
> mistake for underestimating this)
>
>
> Le 06/01/2018 à 16:00, Alan Evans a écrit :
>> You're mistaken. BIP32 does not require a particular length. It
>> recommends:
>>
>> * Generate a seed byte sequence S of a chosen length (between
>> 128 and 512 bits; 256 bits is advised) from a (P)RNG
>>
>> But BIP39 produces a 64 byte seed:
>>
>> The length of the derived key is 512 bits (= 64 bytes).
>>
>> If you don't believe me, why don't you just try it? That seed
>> will derive the same keys as that mnemonic, it's a real example.
>>
>> ---------
>>
>> About printing, there is a huge security risk involved in
>> printing anything. Networks, printers may have memory. People
>> will print to PDF when they don't have a printer on hand. Mobile
>> users often can't print.
>>
>> I wrote mine down, by hand, generated from an offline computer
>> booted with a readonly OS.
>>
>> Feel free to produce a recommendation to replace BIP39/32/44 if
>> you like, but it's not broken just because someone had trouble
>> using your tool/following your instructions. And no offence but
>> I'd be wary using a tool from someone who doesn't read the BIPs
>> closely yet is so confident about how other people are wrong.
>>
>>
>> On Sat, Jan 6, 2018 at 6:57 AM, Aymeric Vitte
>> <vitteaymeric at gmail.com <mailto:vitteaymeric at gmail.com>> wrote:
>>
>> And Alan, btw, a BIP32 seed is 32 bytes, then 64 characters,
>> not 64
>> bytes as your wrote below, which probably corresponds to
>> xprv, which is
>> another misleading element of BIP39
>>
>>
>> Le 06/01/2018 à 02:56, Aymeric Vitte a écrit :
>> > The fact is indeed that "we should really find a way to
>> overhaul this
>> > whole BIP 39 / 43/ 44 etc ad hoc mess"
>> >
>> > Because the git example I provided is about someone that
>> knows (to a
>> > certain extent) what he is doing, then made a mistake for the
>> > destination address, which is not related to this discussion
>> >
>> > This just shows how complicate it can become even for
>> people knowing
>> > this to retrieve their wallet and how wallets made it "the
>> easy way" (ie
>> > bip39, 44, multisig...)
>> >
>> > If people prefer to store mnemonics, why not, but "writing
>> down" in both
>> > messages above is not accurate, you would better print it
>> and cut it in
>> > n pieces if you like, then the point of using mnemonics
>> that you can't
>> > remember more than an hex string still remains useless from
>> my standpoint
>> >
>> > Beside the theory we should look now if BIP39 & all brought
>> more good
>> > than the contrary in practice, I think that the later wins
>> >
>> >
>> > Le 05/01/2018 à 21:38, Sjors Provoost a écrit :
>> >> Hi Alan,
>> >>
>> >> The Github issue is arguably unrelated, which is why I put
>> it at the end and said “some related”.
>> >>
>> >> However it does all tie together; we should really find a
>> way to overhaul this whole BIP 39 / 43/ 44 etc ad hoc mess,
>> ideally in a way that even Bitcoin Core would be willing to
>> use it. When you change the word list, it’s best to change
>> everything else at the same time. Otherwise you’d have too
>> many different standards, which is a pain for wallets to
>> implement.
>> >>
>> >> I share your view than a mnemonic is better than a bunch
>> of hex numbers. It’s easier to memorize and easier to write
>> down. Some people don’t like it when users write down
>> phrases, but they’re much, much more likely to lose their
>> coins than some burglar to find the piece of paper. My issue
>> is only with the way derivation currently works.
>> >>
>> >> Sjors
>> >>
>> >>> Op 5 jan. 2018, om 21:05 heeft Alan Evans
>> <thealanevans at gmail.com <mailto:thealanevans at gmail.com>> het
>> volgende geschreven:
>> >>>
>> >>> Taking it off the board. I can't read all of that issue.
>> BIP0039 mnemonic generates a seed. Everything past there to
>> do with addresses (BIP32/44/49/141 whatever) is the same as
>> if you started with the seed. So you can't blaim BIP0039 for
>> that person's misunderstanding, and the way different wallets
>> use different derivation paths.
>> >>>
>> >>> If someone has a BIP0039 mnemonic and would rather back
>> up the seed, they can go ahead. But one tiny mistake in
>> writing it down and you may have a hell of a time finding out
>> what's wrong as every seed is valid. A mistake in writing
>> down words is far harder to make. You can also memorize a
>> mnemonic (hence the name), the average person cannot memorize
>> a seed.
>> >>>
>> >>> fork canal mad beyond spike pool expire fuel region
>> impose ceiling video
>> >>>
>> >>> vs:
>> >>>
>> >>>
>> f54b80812b3a6f1834095370df82a2123aece2d6089da67d7871477c004684fbc399a6155e53de0b783a9be6388354846e51f59e4869984f0c554e6469788c64
>> >>>
>> >>> But they lead to the same addresses.
>> >>>
>> >>> Need I say more?
>> >>>
>> >>>
>> >>> On Fri, Jan 5, 2018 at 3:56 PM, Aymeric Vitte
>> <vitteaymeric at gmail.com <mailto:vitteaymeric at gmail.com>> wrote:
>> >>> No that's not, some parts of the answer might be but this
>> related, this just shows how people use wrongly BIP39 and
>> subsequent BIPs (and globally other things), misleading them,
>> while the advantage of using it is quite dubious compared to
>> backing up a seed, unless you can convince me of the contrary
>> >>>
>> >>> Le 05/01/2018 à 19:16, Alan Evans a écrit :
>> >>>> Sjors, well in Electrum, validation is optional, but
>> English only. As for the Ledger-S, that sounds like a Ledger
>> problem.
>> >>>>
>> >>>> Aymeric, that is way off topic, did you reply to wrong
>> email?
>> >>>>
>> >>>> On Fri, Jan 5, 2018 at 2:08 PM, Aymeric Vitte
>> <vitteaymeric at gmail.com <mailto:vitteaymeric at gmail.com>> wrote:
>> >>>> See:
>> https://github.com/Ayms/bitcoin-transactions/issues/3
>> <https://github.com/Ayms/bitcoin-transactions/issues/3>
>> >>>>
>> >>>> OK, maybe it's my fault, I did not foresee this case,
>> and now it's working for p2sh (non segwit)
>> >>>> From my standpoint this just means that BIP39/44 stuff
>> should be eradicated (not BIP141 but see what happened...),
>> this is of no use, confusing people, doing dangerous things
>> to recover
>> >>>> Really is it easier to save x words instead of a seed?
>> Knowing that people are creating several wallets not
>> understanding that this is not the purpose of BIP32?
>> >>>>
>> >>>> Multisig wallets (like Electrum) have created a big mess
>> too, on purpose or no, I don't know, but multisig is for
>> different parties involved, not just one
>> >>>>
>> >>>> Le 05/01/2018 à 18:13, Sjors Provoost via bitcoin-dev a
>> écrit :
>> >>>>> I don’t know about Electrum but many wallets validate
>> the English words, which helps in catching typos.
>> >>>>>
>> >>>>> Hardware wallets without a full keyboard, like the
>> Ledger Nano S, won’t even let you freely type characters; you
>> have to select words from a list.
>> >>>>>
>> >>>>> So although the standard technically allows what you
>> say, if you use anything other than 12, 16 or 24 English
>> words, you’ll have fewer wallets to choose from.
>> >>>>>
>> >>>>> I think it’s better to come up with a new standard than
>> trying to patch BIP-39 at this point, which is why I brought
>> it up.
>> >>>>>
>> >>>>> Sjors
>> >>>>>
>> >>>>>
>> >>>>>> Op 5 jan. 2018, om 17:27 heeft Alan Evans
>> <thealanevans at gmail.com <mailto:thealanevans at gmail.com>>
>> >>>>>> het volgende geschreven:
>> >>>>>>
>> >>>>>> "Very few wallets support anything other than English"
>> >>>>>>
>> >>>>>> By support do you mean allow recovery, validation or
>> generation or all three? For if you can freely type a phrase
>> in (such as Electrum), or even word by word, then the
>> likely-hood is it is supported if they remembered to normalize.
>> >>>>>>
>> >>>>>> Seed generation in BIP0039 requires no dictionary
>> what-so-ever! So there is no word list to lose in the first
>> place. Your funds are accessible with just the characters and
>> the algorithm as described in BIP0039.
>> >>>>>>
>> >>>>>> But your proposal is a million miles away from simply
>> adding some standard in-language names to some word lists
>> feels like it's derailing the OP's simple proposal. Maybe
>> start own email chain about it.
>> >>>>>>
>> >>>>>> Alan
>> >>>>>>
>> >>>>>> On Fri, Jan 5, 2018 at 12:04 PM, Sjors Provoost via
>> bitcoin-dev
>> >>>>>> <bitcoin-dev at lists.linuxfoundation.org
>> <mailto:bitcoin-dev at lists.linuxfoundation.org>>
>> >>>>>> wrote:
>> >>>>>> I’m not a fan of language specific word lists within
>> the current BIP-39 standard. Very few wallets support
>> anything other than English, which can lead to vendor lock-in
>> and long term loss of funds if a rare non-English wallet
>> disappears.
>> >>>>>>
>> >>>>>> However, because people can memorize things better in
>> their native tongue, supporting multiple languages seems
>> quite useful.
>> >>>>>>
>> >>>>>> I would prefer a new standard where words are mapped
>> to integers rather than to a literal string. For each
>> language a mapping from words to integers would be published.
>> In addition to that, there would be a mapping from original
>> language words to matching (in terms of integer value, not
>> meaning) English words that people can print on an A4 paper.
>> This would allow them to enter a mnemonic into e.g. a
>> hardware wallet that only support English. Such lists are
>> more likely to be around 100 years from now than some ancient
>> piece of software.
>> >>>>>>
>> >>>>>> This would not work with the current BIP-39 (duress)
>> password, but this feature could be replaced by appending
>> words (with or without a checksum for that addition).
>> >>>>>>
>> >>>>>> A replacement for BIP-39 would be a good opportunity
>> to produce a better English dictionary as Nic Johnson
>> suggested a while ago:
>> >>>>>> • all words are 4-8 characters
>> >>>>>> • all 4-character prefixes are unique (very
>> useful for hardware wallets)
>> >>>>>> • no two words have edit distance < 2
>> >>>>>>
>> >>>>>> Wallets need to be able to distinguish between the old
>> and new standard, so un-upgraded BIP 39 wallets should
>> consider all new mnemonics invalid. At the same time, some
>> new wallets may not wish to support BIP39. They shouldn't be
>> burdened with storing the old word list.
>> >>>>>>
>> >>>>>> A solution is to sort the new word list such that
>> reused words appear first. When generating a mnemonic, at
>> least one word unique to the new list must be present. A
>> wallet only needs to know the index of the last BIP39
>> overlapping word. They reject a proposed mnemonic if none of
>> the elements use a word with a higher index.
>> >>>>>>
>> >>>>>> For my above point and some related ideas, see:
>> >>>>>> https://github.com/satoshilabs/slips/issues/103
>> <https://github.com/satoshilabs/slips/issues/103>
>> >>>>>>
>> >>>>>>
>> >>>>>> Sjors
>> >>>>>>
>> >>>>>>
>> >>>>>>> Op 5 jan. 2018, om 14:58 heeft nullius via
>> bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org
>> <mailto:bitcoin-dev at lists.linuxfoundation.org>>
>> >>>>>>> het volgende geschreven:
>> >>>>>>>
>> >>>>>>> I propose and request as an enhancement that the BIP
>> 39 wordlist set should specify canonical native language
>> strings to identify each wordlist, as well as short ASCII
>> language codes. At present, the languages are identified
>> only by their names in English.
>> >>>>>>>
>> >>>>>>> Strings properly vetted and recommended by native
>> speakers should facilitate language identification in user
>> interface options or menus. Specification of language
>> identifier strings would also promote interface consistency
>> between implementations; this may be important if a user
>> creates a mnemonic in Implementation A, then restores a
>> wallet using that mnemonic in Implementation B.
>> >>>>>>>
>> >>>>>>> As an independent implementer who does not know *all*
>> these different languages, I monkey-pasted language-native
>> strings from a popular wiki site. I cannot guarantee that
>> they be all accurate, sensible, or even non-embarrassing.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> https://github.com/nym-zone/easyseed/blob/1a6e48bbdac9366d9d5d1912dc062dfc3f0db2c6/easyseed.c#L99
>> <https://github.com/nym-zone/easyseed/blob/1a6e48bbdac9366d9d5d1912dc062dfc3f0db2c6/easyseed.c#L99>
>> >>>>>>>
>> >>>>>>> ```
>> >>>>>>> LANG(english, u8"English",
>> "en", ascii_space ),
>> >>>>>>> LANG(chinese_simplified, u8"汉语",
>> "zh-CN",ascii_space ),
>> >>>>>>> LANG(chinese_traditional, u8"漢語",
>> "zh-TW",ascii_space ),
>> >>>>>>> LANG(french, u8"Français",
>> "fr", ascii_space ),
>> >>>>>>> LANG(italian, u8"Italiano",
>> "it", ascii_space ),
>> >>>>>>> LANG(japanese, u8"日本語",
>> "ja", u8"\u3000" ),
>> >>>>>>> LANG(korean, u8"한국어",
>> "ko", ascii_space ),
>> >>>>>>> LANG(spanish, u8"Español",
>> "es", ascii_space )
>> >>>>>>> ```
>> >>>>>>>
>> >>>>>>> Per the comment at #L85 of the quoted file, I also
>> know that for my short identifiers for Chinese, “zh-CN” and
>> “zh-TW”, are imprecise at best—insofar as Hong Kong uses
>> Traditional; and overseas Chinese may use either. For
>> differentiating the two Chinese writing variants, are there
>> any appropriate standardized or customary short ASCII
>> language IDs similar to ISO 3166-1 alpha-2 which are purely
>> linguistic, and not fit to present-day political boundaries?
>> >>>>>>>
>> >>>>>>> My general suggestion is that the specification of
>> appropriate strings in
>> >>>>>>> bitcoin:bips/bip-0039/bip-0039-wordlists.md
>> <http://bip-0039-wordlists.md>
>> >>>>>>> be made part of the process for accepting new
>> wordlists. My specific request is that such strings be
>> ascertained for the wordlists already existing, preferably
>> from the persons involved in the original pull requests therefor.
>> >>>>>>>
>> >>>>>>> Should this proposal be “concept ACKed” by
>> appropriate parties, then I may open a pull request
>> suggesting an appropriate format for specifying this
>> information in the repository. However, I will must needs
>> leave the vetting of appropriate strings to native speakers
>> or experts in the respective languages.
>> >>>>>>>
>> >>>>>>> Prior references: The wordlist additions at PRs #92,
>> #130 (Japanese); #100 (Spanish); #114 (Chinese, both
>> variants); #152 (French); #306 (Italian); #570 (Korean); #621
>> (Indonesian, *proposed*, open).
>> >>>>>>> ______________________________
>>
>
--
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180106/54801027/attachment-0001.html>

2023-06-07 18:09:20

- reply

📅 Original date posted:2018-01-06
📝 Original message:Unfortunately, even "yourself" seems not to know what he is talking
about (so imagine for other people, 256 bits is advised --> 32B),
probably that's why you brought this discussion off the list, then
making recommendations to improve something that is misleading and messy
is quite dubious
And maybe you should take a look at what people you are talking to are
doing before arguing stuff that you apparently don't know very well (ie
"the length of the *derived *key", not the seed), cf
https://github.com/Ayms/bitcoin-wallets
<https://github.com/Ayms/bitcoin-wallets> and even
https://github.com/Ayms/zcash-wallets (not official but
https://github.com/zcash/zips/issues/95)
<https://github.com/Ayms/zcash-wallets>
But as you can notice there is a missing feature, ie to derive the
wallets from xpriv, there is a comment in the repo why I don't like some
things "Surprisingly from ~32 bytes keys BIP32 ends up with a 78 bytes
format to describe them with all the necessary information like indexes,
parent to possibly allow to revert the tree"
That's another thing I completely dislike with BIP39, it ends up with
xpriv, not the 32B seed, there are many, many, many posts in forums of
people fighting to figure out their private keys derived from bip39/44/etc
"No offence too" but please keep your advises for yourself, I indeed
don't read closely inept BIPs, and never said I did not like BIP32,
that's the contrary, I really like it
Before firing plenty of BIPs that do not fit together people maybe
should take a break and see what people are doing today (this is quite
amazing) and why they got stolen
And you seem to know very little about security, if you suspect you home
printer, then suspect you OS, your hw, etc, (you really envision to
generate a seed from a mobile device ???) writing 64 characters is not
very difficult for a human being, even easier than writing x words of y
length
See this too
https://bitcointalk.org/index.php?topic=2550529.msg26133887#msg26133887,
the tutorial was corrected, but basic things are still missing, an
offline version is when you disconnect from the internet, not when you
use the "offline version" (assuming that the browser storage or other
stuff are not used...)
Re-ccing the list because again at a certain point of time the theory
should look at the reality and adapt accordingly, part of the example I
gave is off topic for this thread but globally (which could become
another thread) the message is: the bitcoin community should stop making
things complicate for people, releasing BIPs of no use just ends up with
complicating things more than it helps, people deserve to understand
what they are doing, manage their keys by their own and stop syncing
useless full nodes for every coin to sync their wallets, that's why I
made the tool, the first people that used it made some outstanding
mistakes that I did not envision now it's not possible any longer,
except if they give wrong destination addresses and nobody can't do
anything about this (btw the primary intent of the tool was for myself
and you are right for once, I did not know that people could do so big
mistakes, that's not their fault, I see it now, my mistake for
underestimating this)
Le 06/01/2018 à 16:00, Alan Evans a écrit :
> You're mistaken. BIP32 does not require a particular length. It
> recommends:
>
> * Generate a seed byte sequence S of a chosen length (between 128
> and 512 bits; 256 bits is advised) from a (P)RNG
>
> But BIP39 produces a 64 byte seed:
>
> The length of the derived key is 512 bits (= 64 bytes).
>
> If you don't believe me, why don't you just try it? That seed will
> derive the same keys as that mnemonic, it's a real example.
>
> ---------
>
> About printing, there is a huge security risk involved in printing
> anything. Networks, printers may have memory. People will print to PDF
> when they don't have a printer on hand. Mobile users often can't print.
>
> I wrote mine down, by hand, generated from an offline computer booted
> with a readonly OS.
>
> Feel free to produce a recommendation to replace BIP39/32/44 if you
> like, but it's not broken just because someone had trouble using your
> tool/following your instructions. And no offence but I'd be wary using
> a tool from someone who doesn't read the BIPs closely yet is so
> confident about how other people are wrong.
>
>
> On Sat, Jan 6, 2018 at 6:57 AM, Aymeric Vitte <vitteaymeric at gmail.com
> <mailto:vitteaymeric at gmail.com>> wrote:
>
> And Alan, btw, a BIP32 seed is 32 bytes, then 64 characters, not 64
> bytes as your wrote below, which probably corresponds to xprv,
> which is
> another misleading element of BIP39
>
>
> Le 06/01/2018 à 02:56, Aymeric Vitte a écrit :
> > The fact is indeed that "we should really find a way to overhaul
> this
> > whole BIP 39 / 43/ 44 etc ad hoc mess"
> >
> > Because the git example I provided is about someone that knows (to a
> > certain extent) what he is doing, then made a mistake for the
> > destination address, which is not related to this discussion
> >
> > This just shows how complicate it can become even for people knowing
> > this to retrieve their wallet and how wallets made it "the easy
> way" (ie
> > bip39, 44, multisig...)
> >
> > If people prefer to store mnemonics, why not, but "writing down"
> in both
> > messages above is not accurate, you would better print it and
> cut it in
> > n pieces if you like, then the point of using mnemonics that you
> can't
> > remember more than an hex string still remains useless from my
> standpoint
> >
> > Beside the theory we should look now if BIP39 & all brought more
> good
> > than the contrary in practice, I think that the later wins
> >
> >
> > Le 05/01/2018 à 21:38, Sjors Provoost a écrit :
> >> Hi Alan,
> >>
> >> The Github issue is arguably unrelated, which is why I put it
> at the end and said “some related”.
> >>
> >> However it does all tie together; we should really find a way
> to overhaul this whole BIP 39 / 43/ 44 etc ad hoc mess, ideally in
> a way that even Bitcoin Core would be willing to use it. When you
> change the word list, it’s best to change everything else at the
> same time. Otherwise you’d have too many different standards,
> which is a pain for wallets to implement.
> >>
> >> I share your view than a mnemonic is better than a bunch of hex
> numbers. It’s easier to memorize and easier to write down. Some
> people don’t like it when users write down phrases, but they’re
> much, much more likely to lose their coins than some burglar to
> find the piece of paper. My issue is only with the way derivation
> currently works.
> >>
> >> Sjors
> >>
> >>> Op 5 jan. 2018, om 21:05 heeft Alan Evans
> <thealanevans at gmail.com <mailto:thealanevans at gmail.com>> het
> volgende geschreven:
> >>>
> >>> Taking it off the board. I can't read all of that issue.
> BIP0039 mnemonic generates a seed. Everything past there to do
> with addresses (BIP32/44/49/141 whatever) is the same as if you
> started with the seed. So you can't blaim BIP0039 for that
> person's misunderstanding, and the way different wallets use
> different derivation paths.
> >>>
> >>> If someone has a BIP0039 mnemonic and would rather back up the
> seed, they can go ahead. But one tiny mistake in writing it down
> and you may have a hell of a time finding out what's wrong as
> every seed is valid. A mistake in writing down words is far harder
> to make. You can also memorize a mnemonic (hence the name), the
> average person cannot memorize a seed.
> >>>
> >>> fork canal mad beyond spike pool expire fuel region impose
> ceiling video
> >>>
> >>> vs:
> >>>
> >>>
> f54b80812b3a6f1834095370df82a2123aece2d6089da67d7871477c004684fbc399a6155e53de0b783a9be6388354846e51f59e4869984f0c554e6469788c64
> >>>
> >>> But they lead to the same addresses.
> >>>
> >>> Need I say more?
> >>>
> >>>
> >>> On Fri, Jan 5, 2018 at 3:56 PM, Aymeric Vitte
> <vitteaymeric at gmail.com <mailto:vitteaymeric at gmail.com>> wrote:
> >>> No that's not, some parts of the answer might be but this
> related, this just shows how people use wrongly BIP39 and
> subsequent BIPs (and globally other things), misleading them,
> while the advantage of using it is quite dubious compared to
> backing up a seed, unless you can convince me of the contrary
> >>>
> >>> Le 05/01/2018 à 19:16, Alan Evans a écrit :
> >>>> Sjors, well in Electrum, validation is optional, but English
> only. As for the Ledger-S, that sounds like a Ledger problem.
> >>>>
> >>>> Aymeric, that is way off topic, did you reply to wrong email?
> >>>>
> >>>> On Fri, Jan 5, 2018 at 2:08 PM, Aymeric Vitte
> <vitteaymeric at gmail.com <mailto:vitteaymeric at gmail.com>> wrote:
> >>>> See: https://github.com/Ayms/bitcoin-transactions/issues/3
> <https://github.com/Ayms/bitcoin-transactions/issues/3>
> >>>>
> >>>> OK, maybe it's my fault, I did not foresee this case, and now
> it's working for p2sh (non segwit)
> >>>> From my standpoint this just means that BIP39/44 stuff should
> be eradicated (not BIP141 but see what happened...), this is of no
> use, confusing people, doing dangerous things to recover
> >>>> Really is it easier to save x words instead of a seed?
> Knowing that people are creating several wallets not understanding
> that this is not the purpose of BIP32?
> >>>>
> >>>> Multisig wallets (like Electrum) have created a big mess too,
> on purpose or no, I don't know, but multisig is for different
> parties involved, not just one
> >>>>
> >>>> Le 05/01/2018 à 18:13, Sjors Provoost via bitcoin-dev a écrit :
> >>>>> I don’t know about Electrum but many wallets validate the
> English words, which helps in catching typos.
> >>>>>
> >>>>> Hardware wallets without a full keyboard, like the Ledger
> Nano S, won’t even let you freely type characters; you have to
> select words from a list.
> >>>>>
> >>>>> So although the standard technically allows what you say, if
> you use anything other than 12, 16 or 24 English words, you’ll
> have fewer wallets to choose from.
> >>>>>
> >>>>> I think it’s better to come up with a new standard than
> trying to patch BIP-39 at this point, which is why I brought it up.
> >>>>>
> >>>>> Sjors
> >>>>>
> >>>>>
> >>>>>> Op 5 jan. 2018, om 17:27 heeft Alan Evans
> <thealanevans at gmail.com <mailto:thealanevans at gmail.com>>
> >>>>>> het volgende geschreven:
> >>>>>>
> >>>>>> "Very few wallets support anything other than English"
> >>>>>>
> >>>>>> By support do you mean allow recovery, validation or
> generation or all three? For if you can freely type a phrase in
> (such as Electrum), or even word by word, then the likely-hood is
> it is supported if they remembered to normalize.
> >>>>>>
> >>>>>> Seed generation in BIP0039 requires no dictionary
> what-so-ever! So there is no word list to lose in the first place.
> Your funds are accessible with just the characters and the
> algorithm as described in BIP0039.
> >>>>>>
> >>>>>> But your proposal is a million miles away from simply
> adding some standard in-language names to some word lists feels
> like it's derailing the OP's simple proposal. Maybe start own
> email chain about it.
> >>>>>>
> >>>>>> Alan
> >>>>>>
> >>>>>> On Fri, Jan 5, 2018 at 12:04 PM, Sjors Provoost via bitcoin-dev
> >>>>>> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>>
> >>>>>> wrote:
> >>>>>> I’m not a fan of language specific word lists within the
> current BIP-39 standard. Very few wallets support anything other
> than English, which can lead to vendor lock-in and long term loss
> of funds if a rare non-English wallet disappears.
> >>>>>>
> >>>>>> However, because people can memorize things better in their
> native tongue, supporting multiple languages seems quite useful.
> >>>>>>
> >>>>>> I would prefer a new standard where words are mapped to
> integers rather than to a literal string. For each language a
> mapping from words to integers would be published. In addition to
> that, there would be a mapping from original language words to
> matching (in terms of integer value, not meaning) English words
> that people can print on an A4 paper. This would allow them to
> enter a mnemonic into e.g. a hardware wallet that only support
> English. Such lists are more likely to be around 100 years from
> now than some ancient piece of software.
> >>>>>>
> >>>>>> This would not work with the current BIP-39 (duress)
> password, but this feature could be replaced by appending words
> (with or without a checksum for that addition).
> >>>>>>
> >>>>>> A replacement for BIP-39 would be a good opportunity to
> produce a better English dictionary as Nic Johnson suggested a
> while ago:
> >>>>>> • all words are 4-8 characters
> >>>>>> • all 4-character prefixes are unique (very useful
> for hardware wallets)
> >>>>>> • no two words have edit distance < 2
> >>>>>>
> >>>>>> Wallets need to be able to distinguish between the old and
> new standard, so un-upgraded BIP 39 wallets should consider all
> new mnemonics invalid. At the same time, some new wallets may not
> wish to support BIP39. They shouldn't be burdened with storing the
> old word list.
> >>>>>>
> >>>>>> A solution is to sort the new word list such that reused
> words appear first. When generating a mnemonic, at least one word
> unique to the new list must be present. A wallet only needs to
> know the index of the last BIP39 overlapping word. They reject a
> proposed mnemonic if none of the elements use a word with a higher
> index.
> >>>>>>
> >>>>>> For my above point and some related ideas, see:
> >>>>>> https://github.com/satoshilabs/slips/issues/103
> <https://github.com/satoshilabs/slips/issues/103>
> >>>>>>
> >>>>>>
> >>>>>> Sjors
> >>>>>>
> >>>>>>
> >>>>>>> Op 5 jan. 2018, om 14:58 heeft nullius via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>>
> >>>>>>> het volgende geschreven:
> >>>>>>>
> >>>>>>> I propose and request as an enhancement that the BIP 39
> wordlist set should specify canonical native language strings to
> identify each wordlist, as well as short ASCII language codes. At
> present, the languages are identified only by their names in English.
> >>>>>>>
> >>>>>>> Strings properly vetted and recommended by native speakers
> should facilitate language identification in user interface
> options or menus. Specification of language identifier strings
> would also promote interface consistency between implementations;
> this may be important if a user creates a mnemonic in
> Implementation A, then restores a wallet using that mnemonic in
> Implementation B.
> >>>>>>>
> >>>>>>> As an independent implementer who does not know *all*
> these different languages, I monkey-pasted language-native strings
> from a popular wiki site. I cannot guarantee that they be all
> accurate, sensible, or even non-embarrassing.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> https://github.com/nym-zone/easyseed/blob/1a6e48bbdac9366d9d5d1912dc062dfc3f0db2c6/easyseed.c#L99
> <https://github.com/nym-zone/easyseed/blob/1a6e48bbdac9366d9d5d1912dc062dfc3f0db2c6/easyseed.c#L99>
> >>>>>>>
> >>>>>>> ```
> >>>>>>> LANG(english, u8"English",
> "en", ascii_space ),
> >>>>>>> LANG(chinese_simplified, u8"汉语",
> "zh-CN",ascii_space ),
> >>>>>>> LANG(chinese_traditional, u8"漢語",
> "zh-TW",ascii_space ),
> >>>>>>> LANG(french, u8"Français",
> "fr", ascii_space ),
> >>>>>>> LANG(italian, u8"Italiano",
> "it", ascii_space ),
> >>>>>>> LANG(japanese, u8"日本語",
> "ja", u8"\u3000" ),
> >>>>>>> LANG(korean, u8"한국어",
> "ko", ascii_space ),
> >>>>>>> LANG(spanish, u8"Español",
> "es", ascii_space )
> >>>>>>> ```
> >>>>>>>
> >>>>>>> Per the comment at #L85 of the quoted file, I also know
> that for my short identifiers for Chinese, “zh-CN” and “zh-TW”,
> are imprecise at best—insofar as Hong Kong uses Traditional; and
> overseas Chinese may use either. For differentiating the two
> Chinese writing variants, are there any appropriate standardized
> or customary short ASCII language IDs similar to ISO 3166-1
> alpha-2 which are purely linguistic, and not fit to present-day
> political boundaries?
> >>>>>>>
> >>>>>>> My general suggestion is that the specification of
> appropriate strings in
> >>>>>>> bitcoin:bips/bip-0039/bip-0039-wordlists.md
> <http://bip-0039-wordlists.md>
> >>>>>>> be made part of the process for accepting new wordlists.
> My specific request is that such strings be ascertained for the
> wordlists already existing, preferably from the persons involved
> in the original pull requests therefor.
> >>>>>>>
> >>>>>>> Should this proposal be “concept ACKed” by appropriate
> parties, then I may open a pull request suggesting an appropriate
> format for specifying this information in the repository.
> However, I will must needs leave the vetting of appropriate
> strings to native speakers or experts in the respective languages.
> >>>>>>>
> >>>>>>> Prior references: The wordlist additions at PRs #92, #130
> (Japanese); #100 (Spanish); #114 (Chinese, both variants); #152
> (French); #306 (Italian); #570 (Korean); #621 (Indonesian,
> *proposed*, open).
> >>>>>>> ______________________________
> >>>>>>> _________________
> >>>>>>> bitcoin-dev mailing list
> >>>>>>>
> >>>>>>> bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> >>>>>>>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
> >>>>>> ______________________________
> >>>>>> _________________
> >>>>>> bitcoin-dev mailing list
> >>>>>>
> >>>>>> bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> >>>>>>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> <signature.asc>
> >>>>>>
> >>>>> ______________________________
> >>>>> _________________
> >>>>> bitcoin-dev mailing list
> >>>>>
> >>>>> bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> >>>>>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
> >>>> --
> >>>> Bitcoin transactions made simple:
> >>>> https://github.com/Ayms/bitcoin-transactions
> <https://github.com/Ayms/bitcoin-transactions>
> >>>>
> >>>> Zcash wallets made simple:
> >>>> https://github.com/Ayms/zcash-wallets
> <https://github.com/Ayms/zcash-wallets>
> >>>>
> >>>> Bitcoin wallets made simple:
> >>>> https://github.com/Ayms/bitcoin-wallets
> <https://github.com/Ayms/bitcoin-wallets>
> >>>>
> >>>> Get the torrent dynamic blocklist:
> >>>> http://peersm.com/getblocklist
> >>>>
> >>>> Check the 10 M passwords list:
> >>>> http://peersm.com/findmyass
> >>>>
> >>>> Anti-spies and private torrents, dynamic blocklist:
> >>>> http://torrent-live.org
> >>>>
> >>>> Peersm :
> >>>> http://www.peersm.com
> >>>>
> >>>> torrent-live:
> >>>> https://github.com/Ayms/torrent-live
> <https://github.com/Ayms/torrent-live>
> >>>>
> >>>> node-Tor :
> >>>> https://www.github.com/Ayms/node-Tor
> <https://www.github.com/Ayms/node-Tor>
> >>>>
> >>>> GitHub :
> >>>> https://www.github.com/Ayms
> >>>>
> >>> --
> >>> Bitcoin transactions made simple:
> >>> https://github.com/Ayms/bitcoin-transactions
> <https://github.com/Ayms/bitcoin-transactions>
> >>>
> >>> Zcash wallets made simple:
> >>> https://github.com/Ayms/zcash-wallets
> <https://github.com/Ayms/zcash-wallets>
> >>>
> >>> Bitcoin wallets made simple:
> >>> https://github.com/Ayms/bitcoin-wallets
> <https://github.com/Ayms/bitcoin-wallets>
> >>>
> >>> Get the torrent dynamic blocklist:
> >>> http://peersm.com/getblocklist
> >>>
> >>> Check the 10 M passwords list:
> >>> http://peersm.com/findmyass
> >>>
> >>> Anti-spies and private torrents, dynamic blocklist:
> >>> http://torrent-live.org
> >>>
> >>> Peersm :
> >>> http://www.peersm.com
> >>>
> >>> torrent-live:
> >>> https://github.com/Ayms/torrent-live
> <https://github.com/Ayms/torrent-live>
> >>>
> >>> node-Tor :
> >>> https://www.github.com/Ayms/node-Tor
> <https://www.github.com/Ayms/node-Tor>
> >>>
> >>> GitHub :
> >>> https://www.github.com/Ayms
> >>>
>
> --
> Bitcoin transactions made simple:
> https://github.com/Ayms/bitcoin-transactions
> <https://github.com/Ayms/bitcoin-transactions>
> Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
> <https://github.com/Ayms/zcash-wallets>
> Bitcoin wallets made simple:
> https://github.com/Ayms/bitcoin-wallets
> <https://github.com/Ayms/bitcoin-wallets>
> Get the torrent dynamic blocklist: http://peersm.com/getblocklist
> Check the 10 M passwords list: http://peersm.com/findmyass
> Anti-spies and private torrents, dynamic blocklist:
> http://torrent-live.org
> Peersm : http://www.peersm.com
> torrent-live: https://github.com/Ayms/torrent-live
> node-Tor <https://github.com/Ayms/torrent-live%0Anode-Tor> :
> https://www.github.com/Ayms/node-Tor
> <https://www.github.com/Ayms/node-Tor>
> GitHub : https://www.github.com/Ayms
>
>
--
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180106/74d8e042/attachment-0001.html>

2023-06-07 18:09:19

- reply

📅 Original date posted:2018-01-05
📝 Original message:See: https://github.com/Ayms/bitcoin-transactions/issues/3
OK, maybe it's my fault, I did not foresee this case, and now it's
working for p2sh (non segwit)
From my standpoint this just means that BIP39/44 stuff should be
eradicated (not BIP141 but see what happened...), this is of no use,
confusing people, doing dangerous things to recover
Really is it easier to save x words instead of a seed? Knowing that
people are creating several wallets not understanding that this is not
the purpose of BIP32?
Multisig wallets (like Electrum) have created a big mess too, on purpose
or no, I don't know, but multisig is for different parties involved, not
just one
Le 05/01/2018 à 18:13, Sjors Provoost via bitcoin-dev a écrit :
> I don’t know about Electrum but many wallets validate the English words, which helps in catching typos.
>
> Hardware wallets without a full keyboard, like the Ledger Nano S, won’t even let you freely type characters; you have to select words from a list.
>
> So although the standard technically allows what you say, if you use anything other than 12, 16 or 24 English words, you’ll have fewer wallets to choose from.
>
> I think it’s better to come up with a new standard than trying to patch BIP-39 at this point, which is why I brought it up.
>
> Sjors
>
>> Op 5 jan. 2018, om 17:27 heeft Alan Evans <thealanevans at gmail.com> het volgende geschreven:
>>
>> "Very few wallets support anything other than English"
>>
>> By support do you mean allow recovery, validation or generation or all three? For if you can freely type a phrase in (such as Electrum), or even word by word, then the likely-hood is it is supported if they remembered to normalize.
>>
>> Seed generation in BIP0039 requires no dictionary what-so-ever! So there is no word list to lose in the first place. Your funds are accessible with just the characters and the algorithm as described in BIP0039.
>>
>> But your proposal is a million miles away from simply adding some standard in-language names to some word lists feels like it's derailing the OP's simple proposal. Maybe start own email chain about it.
>>
>> Alan
>>
>> On Fri, Jan 5, 2018 at 12:04 PM, Sjors Provoost via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> I’m not a fan of language specific word lists within the current BIP-39 standard. Very few wallets support anything other than English, which can lead to vendor lock-in and long term loss of funds if a rare non-English wallet disappears.
>>
>> However, because people can memorize things better in their native tongue, supporting multiple languages seems quite useful.
>>
>> I would prefer a new standard where words are mapped to integers rather than to a literal string. For each language a mapping from words to integers would be published. In addition to that, there would be a mapping from original language words to matching (in terms of integer value, not meaning) English words that people can print on an A4 paper. This would allow them to enter a mnemonic into e.g. a hardware wallet that only support English. Such lists are more likely to be around 100 years from now than some ancient piece of software.
>>
>> This would not work with the current BIP-39 (duress) password, but this feature could be replaced by appending words (with or without a checksum for that addition).
>>
>> A replacement for BIP-39 would be a good opportunity to produce a better English dictionary as Nic Johnson suggested a while ago:
>> • all words are 4-8 characters
>> • all 4-character prefixes are unique (very useful for hardware wallets)
>> • no two words have edit distance < 2
>>
>> Wallets need to be able to distinguish between the old and new standard, so un-upgraded BIP 39 wallets should consider all new mnemonics invalid. At the same time, some new wallets may not wish to support BIP39. They shouldn't be burdened with storing the old word list.
>>
>> A solution is to sort the new word list such that reused words appear first. When generating a mnemonic, at least one word unique to the new list must be present. A wallet only needs to know the index of the last BIP39 overlapping word. They reject a proposed mnemonic if none of the elements use a word with a higher index.
>>
>> For my above point and some related ideas, see: https://github.com/satoshilabs/slips/issues/103
>>
>> Sjors
>>
>>> Op 5 jan. 2018, om 14:58 heeft nullius via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> het volgende geschreven:
>>>
>>> I propose and request as an enhancement that the BIP 39 wordlist set should specify canonical native language strings to identify each wordlist, as well as short ASCII language codes. At present, the languages are identified only by their names in English.
>>>
>>> Strings properly vetted and recommended by native speakers should facilitate language identification in user interface options or menus. Specification of language identifier strings would also promote interface consistency between implementations; this may be important if a user creates a mnemonic in Implementation A, then restores a wallet using that mnemonic in Implementation B.
>>>
>>> As an independent implementer who does not know *all* these different languages, I monkey-pasted language-native strings from a popular wiki site. I cannot guarantee that they be all accurate, sensible, or even non-embarrassing.
>>>
>>> https://github.com/nym-zone/easyseed/blob/1a6e48bbdac9366d9d5d1912dc062dfc3f0db2c6/easyseed.c#L99
>>> ```
>>> LANG(english, u8"English", "en", ascii_space ),
>>> LANG(chinese_simplified, u8"汉语", "zh-CN",ascii_space ),
>>> LANG(chinese_traditional, u8"漢語", "zh-TW",ascii_space ),
>>> LANG(french, u8"Français", "fr", ascii_space ),
>>> LANG(italian, u8"Italiano", "it", ascii_space ),
>>> LANG(japanese, u8"日本語", "ja", u8"\u3000" ),
>>> LANG(korean, u8"한국어", "ko", ascii_space ),
>>> LANG(spanish, u8"Español", "es", ascii_space )
>>> ```
>>>
>>> Per the comment at #L85 of the quoted file, I also know that for my short identifiers for Chinese, “zh-CN” and “zh-TW”, are imprecise at best—insofar as Hong Kong uses Traditional; and overseas Chinese may use either. For differentiating the two Chinese writing variants, are there any appropriate standardized or customary short ASCII language IDs similar to ISO 3166-1 alpha-2 which are purely linguistic, and not fit to present-day political boundaries?
>>>
>>> My general suggestion is that the specification of appropriate strings in bitcoin:bips/bip-0039/bip-0039-wordlists.md be made part of the process for accepting new wordlists. My specific request is that such strings be ascertained for the wordlists already existing, preferably from the persons involved in the original pull requests therefor.
>>>
>>> Should this proposal be “concept ACKed” by appropriate parties, then I may open a pull request suggesting an appropriate format for specifying this information in the repository. However, I will must needs leave the vetting of appropriate strings to native speakers or experts in the respective languages.
>>>
>>> Prior references: The wordlist additions at PRs #92, #130 (Japanese); #100 (Spanish); #114 (Chinese, both variants); #152 (French); #306 (Italian); #570 (Korean); #621 (Indonesian, *proposed*, open).
>>> _______________________________________________
>>> 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
>>
>>
>> <signature.asc>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180105/82eb1beb/attachment-0001.html>

2023-06-07 18:09:19

- reply

📅 Original date posted:2018-01-05
📝 Original message:No that's not, some parts of the answer might be but this related, this
just shows how people use wrongly BIP39 and subsequent BIPs (and
globally other things), misleading them, while the advantage of using it
is quite dubious compared to backing up a seed, unless you can convince
me of the contrary
Le 05/01/2018 à 19:16, Alan Evans a écrit :
> Sjors, well in Electrum, validation is optional, but English only. As
> for the Ledger-S, that sounds like a Ledger problem.
>
> Aymeric, that is way off topic, did you reply to wrong email?
>
> On Fri, Jan 5, 2018 at 2:08 PM, Aymeric Vitte <vitteaymeric at gmail.com
> <mailto:vitteaymeric at gmail.com>> wrote:
>
> See: https://github.com/Ayms/bitcoin-transactions/issues/3
> <https://github.com/Ayms/bitcoin-transactions/issues/3>
>
> OK, maybe it's my fault, I did not foresee this case, and now it's
> working for p2sh (non segwit)
>
> From my standpoint this just means that BIP39/44 stuff should be
> eradicated (not BIP141 but see what happened...), this is of no
> use, confusing people, doing dangerous things to recover
>
> Really is it easier to save x words instead of a seed? Knowing
> that people are creating several wallets not understanding that
> this is not the purpose of BIP32?
>
> Multisig wallets (like Electrum) have created a big mess too, on
> purpose or no, I don't know, but multisig is for different parties
> involved, not just one
>
>
> Le 05/01/2018 à 18:13, Sjors Provoost via bitcoin-dev a écrit :
>> I don’t know about Electrum but many wallets validate the English words, which helps in catching typos.
>>
>> Hardware wallets without a full keyboard, like the Ledger Nano S, won’t even let you freely type characters; you have to select words from a list.
>>
>> So although the standard technically allows what you say, if you use anything other than 12, 16 or 24 English words, you’ll have fewer wallets to choose from.
>>
>> I think it’s better to come up with a new standard than trying to patch BIP-39 at this point, which is why I brought it up.
>>
>> Sjors
>>
>>> Op 5 jan. 2018, om 17:27 heeft Alan Evans <thealanevans at gmail.com> <mailto:thealanevans at gmail.com> het volgende geschreven:
>>>
>>> "Very few wallets support anything other than English"
>>>
>>> By support do you mean allow recovery, validation or generation or all three? For if you can freely type a phrase in (such as Electrum), or even word by word, then the likely-hood is it is supported if they remembered to normalize.
>>>
>>> Seed generation in BIP0039 requires no dictionary what-so-ever! So there is no word list to lose in the first place. Your funds are accessible with just the characters and the algorithm as described in BIP0039.
>>>
>>> But your proposal is a million miles away from simply adding some standard in-language names to some word lists feels like it's derailing the OP's simple proposal. Maybe start own email chain about it.
>>>
>>> Alan
>>>
>>> On Fri, Jan 5, 2018 at 12:04 PM, Sjors Provoost via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
>>> <mailto:bitcoin-dev at lists.linuxfoundation.org> wrote:
>>> I’m not a fan of language specific word lists within the current BIP-39 standard. Very few wallets support anything other than English, which can lead to vendor lock-in and long term loss of funds if a rare non-English wallet disappears.
>>>
>>> However, because people can memorize things better in their native tongue, supporting multiple languages seems quite useful.
>>>
>>> I would prefer a new standard where words are mapped to integers rather than to a literal string. For each language a mapping from words to integers would be published. In addition to that, there would be a mapping from original language words to matching (in terms of integer value, not meaning) English words that people can print on an A4 paper. This would allow them to enter a mnemonic into e.g. a hardware wallet that only support English. Such lists are more likely to be around 100 years from now than some ancient piece of software.
>>>
>>> This would not work with the current BIP-39 (duress) password, but this feature could be replaced by appending words (with or without a checksum for that addition).
>>>
>>> A replacement for BIP-39 would be a good opportunity to produce a better English dictionary as Nic Johnson suggested a while ago:
>>> • all words are 4-8 characters
>>> • all 4-character prefixes are unique (very useful for hardware wallets)
>>> • no two words have edit distance < 2
>>>
>>> Wallets need to be able to distinguish between the old and new standard, so un-upgraded BIP 39 wallets should consider all new mnemonics invalid. At the same time, some new wallets may not wish to support BIP39. They shouldn't be burdened with storing the old word list.
>>>
>>> A solution is to sort the new word list such that reused words appear first. When generating a mnemonic, at least one word unique to the new list must be present. A wallet only needs to know the index of the last BIP39 overlapping word. They reject a proposed mnemonic if none of the elements use a word with a higher index.
>>>
>>> For my above point and some related ideas, see: https://github.com/satoshilabs/slips/issues/103
>>> <https://github.com/satoshilabs/slips/issues/103>
>>>
>>> Sjors
>>>
>>>> Op 5 jan. 2018, om 14:58 heeft nullius via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
>>>> <mailto:bitcoin-dev at lists.linuxfoundation.org> het volgende geschreven:
>>>>
>>>> I propose and request as an enhancement that the BIP 39 wordlist set should specify canonical native language strings to identify each wordlist, as well as short ASCII language codes. At present, the languages are identified only by their names in English.
>>>>
>>>> Strings properly vetted and recommended by native speakers should facilitate language identification in user interface options or menus. Specification of language identifier strings would also promote interface consistency between implementations; this may be important if a user creates a mnemonic in Implementation A, then restores a wallet using that mnemonic in Implementation B.
>>>>
>>>> As an independent implementer who does not know *all* these different languages, I monkey-pasted language-native strings from a popular wiki site. I cannot guarantee that they be all accurate, sensible, or even non-embarrassing.
>>>>
>>>> https://github.com/nym-zone/easyseed/blob/1a6e48bbdac9366d9d5d1912dc062dfc3f0db2c6/easyseed.c#L99
>>>> <https://github.com/nym-zone/easyseed/blob/1a6e48bbdac9366d9d5d1912dc062dfc3f0db2c6/easyseed.c#L99>
>>>> ```
>>>> LANG(english, u8"English", "en", ascii_space ),
>>>> LANG(chinese_simplified, u8"汉语", "zh-CN",ascii_space ),
>>>> LANG(chinese_traditional, u8"漢語", "zh-TW",ascii_space ),
>>>> LANG(french, u8"Français", "fr", ascii_space ),
>>>> LANG(italian, u8"Italiano", "it", ascii_space ),
>>>> LANG(japanese, u8"日本語", "ja", u8"\u3000" ),
>>>> LANG(korean, u8"한국어", "ko", ascii_space ),
>>>> LANG(spanish, u8"Español", "es", ascii_space )
>>>> ```
>>>>
>>>> Per the comment at #L85 of the quoted file, I also know that for my short identifiers for Chinese, “zh-CN” and “zh-TW”, are imprecise at best—insofar as Hong Kong uses Traditional; and overseas Chinese may use either. For differentiating the two Chinese writing variants, are there any appropriate standardized or customary short ASCII language IDs similar to ISO 3166-1 alpha-2 which are purely linguistic, and not fit to present-day political boundaries?
>>>>
>>>> My general suggestion is that the specification of appropriate strings in bitcoin:bips/bip-0039/bip-0039-wordlists.md be made part of the process for accepting new wordlists. My specific request is that such strings be ascertained for the wordlists already existing, preferably from the persons involved in the original pull requests therefor.
>>>>
>>>> Should this proposal be “concept ACKed” by appropriate parties, then I may open a pull request suggesting an appropriate format for specifying this information in the repository. However, I will must needs leave the vetting of appropriate strings to native speakers or experts in the respective languages.
>>>>
>>>> Prior references: The wordlist additions at PRs #92, #130 (Japanese); #100 (Spanish); #114 (Chinese, both variants); #152 (French); #306 (Italian); #570 (Korean); #621 (Indonesian, *proposed*, open).
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev at lists.linuxfoundation.org
>>>> <mailto:bitcoin-dev at lists.linuxfoundation.org>
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> <mailto:bitcoin-dev at lists.linuxfoundation.org>
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>>>
>>>
>>> <signature.asc>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> <mailto:bitcoin-dev at lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>
> --
> Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
> <https://github.com/Ayms/bitcoin-transactions>
> Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
> <https://github.com/Ayms/zcash-wallets>
> Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
> <https://github.com/Ayms/bitcoin-wallets>
> Get the torrent dynamic blocklist: http://peersm.com/getblocklist
> Check the 10 M passwords list: http://peersm.com/findmyass
> Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
> Peersm : http://www.peersm.com
> torrent-live: https://github.com/Ayms/torrent-live
> <https://github.com/Ayms/torrent-live>
> node-Tor : https://www.github.com/Ayms/node-Tor
> <https://www.github.com/Ayms/node-Tor>
> GitHub : https://www.github.com/Ayms
>
>
--
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180105/1c88fd57/attachment-0001.html>

2023-06-07 18:09:01

- reply

📅 Original date posted:2017-12-22
📝 Original message:Le 22/12/2017 à 00:09, Luke Dashjr via bitcoin-dev a écrit :
> What is actually done, is using the signature + message to perform key
> recovery, to extract the public key of the signer, and then hashing that and
> comparing it to the address provided.
I already posted about this, then what is doing the pubkey in sigscript
for standard p2pkh transactions? (this was not the case some time ago)
--
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms

2023-06-07 18:09:01

- reply

📅 Original date posted:2017-12-22
📝 Original message:Scriptsig not "sigscript" below
Now you must answer this question, because this is what we call a hard fork
Le 22/12/2017 à 11:29, Aymeric Vitte a écrit :
>
> Le 22/12/2017 à 00:09, Luke Dashjr via bitcoin-dev a écrit :
>> What is actually done, is using the signature + message to perform key
>> recovery, to extract the public key of the signer, and then hashing that and
>> comparing it to the address provided.
> I already posted about this, then what is doing the pubkey in sigscript
> for standard p2pkh transactions? (this was not the case some time ago)
>
--
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms