Claus Ehrenberg [ARCHIVE] / is on Nostr

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

Last Notes

2023-06-07 23:19:21

- reply

📅 Original date posted:2023-02-06
🗒️ Summary of this message: The use of inscriptions to store NFT content on the Bitcoin chain is a topic of discussion among developers, with concerns about unlimited storage and potential malicious content. A size limit similar to OP_RETURN may be necessary, and an opt-out feature for potentially harmful content should be considered. However, the ordinal scheme is praised for its elegance and potential use in linking real-world property ownership to the blockchain.
📝 Original message:The inscriptions are designed to be easy to use, they even specify that
mime types should be used. I'd say, the way the data is stored is anything
but 'obscure'. UIs will be popping up to make this really easy. The main
chain can't be censored, what's in a block is in a block. I'm predicting a
huge success.
So, are we ready to accept that we'll likely see the first pictures with
insults or worse in the Bitcoin chain? I really like the idea, but the risk
is pretty obvious. I think it would be prudent to have at least an opt-out
feature for the data. So that it's possible to use the chain without the
potentially malicious content. That means the content shouldn't live in the
essential data of the main chain. Better would be something like the
extension blocks in Litecoin.
Best Regards
Claus
On Fri, Jan 27, 2023 at 1:47 PM Robert Dickinson via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I'm curious what opinions exist and what actions might be taken by core
> developers regarding storing unlimited amounts of NFT (or other?) content
> as witness data (https://docs.ordinals.com/inscriptions.html). The
> ordinal scheme is elegant and genius IMHO, but when I think about the
> future disk use of all unpruned nodes, I question whether unlimited storage
> is wise to allow for such use cases. Wouldn't it be better to find a way to
> impose a size limit similar to OP_RETURN for such inscriptions?
>
> I think it would be useful to link a sat to a deed or other legal
> construct for proof of ownership in the real world, so that real property
> can be transferred on the blockchain using ordinals, but storing the
> property itself on the blockchain seems nonsensical to me.
> _______________________________________________
> 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/20230206/b8d52343/attachment.html>

2023-06-07 23:19:03

- reply

📅 Original date posted:2023-02-16
🗒️ Summary of this message: Proposal to require all data in op_return output and add a required op_return_hash field checked by consensus, allowing nodes to re-validate the chain without storing op_return data.
📝 Original message: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> 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> wrote:
>
>>
>>
>> On February 5, 2023 1:11:35 AM GMT+01:00, Russell O'Connor via
>> bitcoin-dev <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 listbitcoin-dev at lists.linuxfoundation.orghttps://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
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230216/8a0f80cf/attachment.html>

2023-06-07 22:53:45

- reply

📅 Original date posted:2021-05-18
📝 Original message:> Ultimately all currency security derives from energy consumption.
> Everything eventually resolves down to proof-of-work.
This is ideology. Yes, without energy and work, not many things happen. But
the amounts of energy and work to achieve a goal vary widely. Detailed
analysis comparing one alternative with the other in depth is required.
And I would not look for order-of-magnitude improvements, 25% better is
also a big deal, if discovered.
> * Proof-of-space simply moves the work to the construction of more
storage devices.
One needs a cost/benefit analysis, not just an account of the cost. For
example, if PoW could do calculations that are otherwise useful (maybe
solve a queue of standardized math-jobs, such as climate simulations) there
would be more benefit, or, let's say the data storage in proof-of-space is
useful.
> * Proof-of-stake simply moves the work to stake-grinding attacks.
Simply not true, there are PoS implementations that are immune to
stake-grinding attacks, and even where not, the possible amount of
computations is limited compared to PoW
> * The optical proof-of-work simply moves the work to the construction of
more miners.
The idea was to shift from energy to cap-ex. We can get a financial penalty
for misbehavior from three sources:
- cost of energy/labor (PoW)
- cost of capital (PoS)
- cost of cap-ex
There might be a better mix than PoW only. I have written code for mixed
PoW/PoS systems and it works. Adding more cap-ex to the mix can make sense,
but the environmental impact needs to be analyzed, it could also make it
worse than just the use of electricity. At least electricity as such does
not leave waste behind. Mining in orbit with solar power would be totally
acceptable.
> At least, proof-of-work is honest about its consumption of resources.
Agreed, but we can't be satisfied with that. If we try hard enough we can
do better.
Cheers
Claus
On Tue, May 18, 2021 at 8:47 AM ZmnSCPxj via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> > A few things jump out at me as I read this proposal
> >
> > First, deriving the hardness from capex as opposed to opex switches the
> privilege from those who have cheap electricity to those who have access to
> chip manufacturers/foundries. While this is similarly the case for Bitcoin
> ASICS today, the longevity of the PoW algorithm has led to a better
> distribution of knowledge and capital goods required to create ASICS. The
> creation of a new PoW of any kind, hurts this dimension of decentralization
> as we would have to start over from scratch on the best way to build,
> distribute, and operate these new pieces of hardware at scale. While I have
> not combed over the PoW proposed here in fine detail, the more complicated
> the algorithm is, the more it privileges those with specific knowledge
> about it and the manufacturing process.
> >
> > The competitive nature of Bitcoin mining is such that miners will be
> willing to spend up to their expected mining reward in their operating
> costs to continue to mine. Let's suppose that this new PoW was adopted,
> miners will continue to buy these chips in ever increasing quantities,
> turning the aforementioned CAPEX into a de facto OPEX. This has a few
> consequences. First it just pushes the energy consumption upstream to the
> chip manufacturing process, rather than eliminating it. And it may trade
> some marginal amount of the energy consumption for the set of resources it
> takes to educate and create chip manufacturers. The only way to avoid that
> cost being funneled back into more energy consumption is to make the
> barrier to understanding of the manufacturing process sufficiently
> difficult so as to limit the proliferation of these chips. Again, this
> privileges the chip manufacturers as well as those with close access to the
> chip manufacturers.
> >
> > As far as I can tell, the only thing this proposal actually does is
> create a very lucrative business model for those who sell this variety of
> chips. Any other effects of it are transient, and in all likelihood the
> transient effects create serious centralization pressure.
> >
> > At the end of the day, the energy consumption is foundational to the
> system. The only way to do away with authorities, is to require
> competition. This competition will employ ever more resources until it is
> unprofitable to do so. At the base of all resources of society is energy.
> You get high energy expenditure, or a privileged class of bitcoin
> administrators: pick one. I suspect you'll find the vast majority of
> Bitcoin users to be in the camp of the energy expenditure, since if we pick
> the latter, we might as well just pack it in and give up on the Bitcoin
> experiment.
>
>
> Keagan is quite correct.
> Ultimately all currency security derives from energy consumption.
> Everything eventually resolves down to proof-of-work.
>
> * Proof-of-space simply moves the work to the construction of more storage
> devices.
> * Proof-of-stake simply moves the work to stake-grinding attacks.
> * The optical proof-of-work simply moves the work to the construction of
> more miners.
> * Even government-enforced fiat is ultimately proof-of-work, as the
> operation and continued existence of any government is work.
>
> It is far better to move towards a more *direct* proof-of-work, than to
> add more complexity and come up with something that is just proof-of-work,
> but with the work moved off to somewhere else and with additional moving
> parts that can be jammed or hacked into.
>
> When considering any new proof-of-foo, it is best to consider all effects
> until you reach the base physics of the arrow of time, at which point you
> will realize it is ultimately just another proof-of-work anyway.
>
> At least, proof-of-work is honest about its consumption of resources.
>
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> 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/20210518/623830ce/attachment-0001.html>

2023-06-07 22:51:25

- reply

📅 Original date posted:2021-04-07
📝 Original message:As a user, I think it's very important for me to know if Taproot is
eventually coming or not. So why not make it so that if _either_ miners
_or_ users decide for Taproot, it will activate no matter what. Accepting a
chain split is imo the fairest way to 'resolve the conflict' (it can't be
resolved anyway).
That would probably mean running ST and and UASF concurrently.
The upside would be that we've got a safe date for Taproot, except neither
users nor miners want it.
Cheers,
Claus
On Wed, Apr 7, 2021 at 7:02 AM Rusty Russell via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Ryan Grant <bitcoin-dev at rgrant.org> writes:
> > On Tue, Apr 6, 2021 at 11:58 PM Rusty Russell via bitcoin-dev
> > <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >> The core question always was: what do we do if miners fail to activate?
> >>
> >> [...] Speedy Trial takes the approach that "let's pretend we didn't
> >> *actually* ask [miners]".
> >
> > What ST is saying is that a strategy of avoiding unnecessary risk is
> > stronger than a strategy of brinkmanship when brinkmanship wasn't
> > our only option. Having deescalation in the strategy toolkit makes
> > Bitcoin stronger.
>
> I don't believe that having a plan is brinkmanship or an escalation.
>
> During the segwit debate, Pieter Wuille said that users should decide.
> I've been thinking about that a lot, especially about what that means in
> a practical sense where the normal developer / miner dynamic has failed.
>
> >> It's totally a political approach, to avoid facing the awkward question.
> >> Since I believe that such prevaricating makes a future crisis less
> >> predictable, I am forced to conclude that it makes bitcoin less robust.
> >
> > LOT=true does face the awkward question, but there are downsides:
> >
> > - in the requirement to drop blocks from apathetic miners (although
> > as Luke-Jr pointed out in a previous reply on this list they have
> > no contract under which to raise a complaint); and
>
> Surely, yes. If the users of bitcoin decide blocks are invalid, they're
> invalid. With a year's warning, and developer and user consensus
> against them, I think we've reached the limits of acceptable miner
> apathy.
>
> > - in the risk of a chain split, should gauging economic majority
> > support - which there is zero intrinsic tooling for - go poorly.
>
> Agreed that we should definitely do better here: in practice people
> would rely on third party explorers for information on the other side of
> the split. Tracking the cumulative work on invalid chains would be a
> good idea for bitcoind in general (AJ suggested this, IIRC).
>
> >> Personally, I think the compromise position is using LOT=false and
> >> having those such as Luke and myself continue working on a LOT=true
> >> branch for future consideration. It's less than optimal, but I
> >> appreciate that people want Taproot activated more than they want
> >> the groundwork future upgrades.
> >
> > Another way of viewing the current situation is that should
> > brinkmanship be necessary, then better tooling to resolve a situation
> > that requires brinkmanship will be invaluable. But:
> >
> > - we do not need to normalize brinkmanship;
> >
> > - designing brinkmanship tooling well before the next crisis does
> > not require selecting conveniently completed host features to
> > strap the tooling onto for testing; and
>
> Again, openly creating a contingency plan is not brinkmanship, it's
> normal. I know that considering these scenarios is uncomfortable; I
> avoid conflict myself! But I feel obliged to face this as a real
> possibility.
>
> I think we should be normalizing the understanding that bitcoin users
> are the ultimate decider. By offering *all* of them the tools to do so
> we show this isn't lip-service, but something that businesses and
> everyone else in the ecosystem should consider.
>
> > - it's already the case that a UASF branch can be prepared along
> > with ST (ie. without requiring LOT=false), although the code is a
> > bit more complex and the appropriate stopheight a few blocks later.
>
> I don't believe this is true, unless you UASF before ST expires? ST is
> explicitly designed *not* to give time to conclude that miners are
> stalling (unless something has changed from the initial 3 month
> proposal?).
>
> > Although your NACK is well explained, for the reasons above I am
> > prepared to run code that overrides it.
>
> Good. In the end, we're all at the whim of the economic majority.
>
> Cheers!
> Rusty.
> _______________________________________________
> 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/20210407/e1e7b86a/attachment.html>

2023-06-07 18:31:20

- reply