Karl [ARCHIVE] / is on Nostr

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

Last Notes

2023-06-09 13:04:33

- reply

📅 Original date posted:2021-12-06
📝 Original message:
Hi,
I'm not a bitcoin developer.
On Mon, Dec 6, 2021, 5:05 AM Héctor José Cárdenas Pacheco via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hello all,
>
> I’ve been thinking about how OP_RETURN is being used to create and trade
> NFTs on Bitcoin (think RarePepes, SoG and other new ones) and was wondering
> if it’s possible to
>
Do you have a link to any of these protocols?
make transactions with this opcode via Lightning.
>
> More specific questions could be:
>
> 1. Can opcodes like OP_RETURN be inside a channel’s opening or closing
> transaction?
> 2. If so, could that OP_RETURN change hands within that channel or
> network of channels?
>
> OP_RETURNs do not have ownership according to the bitcoin network. It is
not hard to define a protocol that associates an OP_RETURN with ownership,
and ownership could then be transferred via lightning by sending associated
currency via lightning. Robustness improvements seem possible.
> 1. If possible, could the OP_RETURN be divisible? Could one person
> send a piece of a OP_RETURN just like one can do right now on the primary
> ledger or would it need to maintain the OP_RETURN code intact?
>
> OP_RETURNs themselves do not have ownership, but you can define a protocol
that gives them divisible ownership, including via lightning.
I’m assuming that, if possible, this would need a protocol layer parallel
> to Bitcoin/Lightning that stores and reads all Bitcoin transactions and the
> ones which involve the node's channels as well as the ones with the
> OP_RETURN, just like CounterParty does right now with the primary ledger.
>
> Thank in advance.
> ——
>
> *Héctor Cárdenas*@hcarpach
>
> _______________________________________________
> 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/lightning-dev/attachments/20211206/f3253ec4/attachment.html>

2023-06-07 23:00:50

- reply

📅 Original date posted:2021-12-06
📝 Original message:Hi,
I'm not a bitcoin developer.
On Mon, Dec 6, 2021, 5:05 AM Héctor José Cárdenas Pacheco via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hello all,
>
> I’ve been thinking about how OP_RETURN is being used to create and trade
> NFTs on Bitcoin (think RarePepes, SoG and other new ones) and was wondering
> if it’s possible to
>
Do you have a link to any of these protocols?
make transactions with this opcode via Lightning.
>
> More specific questions could be:
>
> 1. Can opcodes like OP_RETURN be inside a channel’s opening or closing
> transaction?
> 2. If so, could that OP_RETURN change hands within that channel or
> network of channels?
>
> OP_RETURNs do not have ownership according to the bitcoin network. It is
not hard to define a protocol that associates an OP_RETURN with ownership,
and ownership could then be transferred via lightning by sending associated
currency via lightning. Robustness improvements seem possible.
> 1. If possible, could the OP_RETURN be divisible? Could one person
> send a piece of a OP_RETURN just like one can do right now on the primary
> ledger or would it need to maintain the OP_RETURN code intact?
>
> OP_RETURNs themselves do not have ownership, but you can define a protocol
that gives them divisible ownership, including via lightning.
I’m assuming that, if possible, this would need a protocol layer parallel
> to Bitcoin/Lightning that stores and reads all Bitcoin transactions and the
> ones which involve the node's channels as well as the ones with the
> OP_RETURN, just like CounterParty does right now with the primary ledger.
>
> Thank in advance.
> ——
>
> *Héctor Cárdenas*@hcarpach
>
> _______________________________________________
> 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/20211206/f3253ec4/attachment.html>

2023-06-07 22:58:09

- reply

📅 Original date posted:2021-08-19
📝 Original message:Something that could work really well here could be having a norm of using
the checksum for bright colors, weights, sizes, capitalizations, and/or
spacing of the characters of the address, making different addresses more
clearly visually distinct.
Ethereum uses mixed case to do this a little bit:
https://eips.ethereum.org/EIPS/eip-55#implementation
It seems to me the checksum at the end of the address is sufficient for
differentiating error, but making a checksum more visually distinctive is
indeed an opportunity to add another digest, reducing collisions and such.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210819/566d8d96/attachment.html>

2023-06-07 22:54:00

- reply

📅 Original date posted:2021-05-24
📝 Original message:If bitcoin were to ever consider changing their PoW algorithm a
little, it seems that would immediately make purchased ASIC mining
equipment partially or wholly unusable to compromise the chain (and
temporarily reduce energy usage without necessarily reducing
security). One possible plan to deter a multibillionaire attack.
Also regarding the word "security" here, a 51% attack impacts some
parts of chain operations, but not others.
It seems to me bitcoin's biggest vulnerabilities are either covert
compromise of mining pool operations, or widespread compromise of
networked mining systems and client nodes. Far easier than
outcompeting the mining network with hardware.
I don't see why it would necessarily be made public if a government
compromised their nation's mining farms. Governments have skilled
operatives for things like that. People would guess it happened, and
the government would cover up the guesses with more powerful stories.

2023-06-07 22:53:58

- reply

📅 Original date posted:2021-05-23
📝 Original message:>> The turn-around time for that takes a population of both users and
>> miners to cause. Increasing popularity of bitcoin has a far bigger
>> impact here, and it is already raising fees and energy use at an
>> established rate.
>>
>> If it becomes an issue, as bandwidth increases block size could be
>> raised to lower fees.
>>
>
> Which increases block rewards somewhat (at least to some level that matches
> the overall security of the network) and you still have the same amount of
> energy consumed.
If you mean to implicitly propose that even if halved all the way with
very large blocks, block rewards would just increase to the same
level, meaning that any attempt to decrease them has no effect, I
disagree. I expect that if you raise the block size, eventually
there is so much supply for transactions that there are no fees at all
(nor security). The numbers are all things the devs, miners, and
users can together control.
> How to prove this is not happening?
> The best you can do is to have some number of authorities sign off on
> whether or not they are doing this.
> The problem is that authorities are bribeable.
You could make the proof of work be a proof of environmental kindness
by coding incentives for people to place and verify proof on the
chain, and then rewarding people for acting on it as desired. You
could code the chain to pay people to investigate and prove miners'
business practices, for example. You could define the main chain as
one where everyone consents the proofs are valid. There are a lot of
issues to resolve and it would be a very different chain.
There is not a single solution here. There are innumerable possible
solutions, any one of which could be made to work with enough brains
working on it. To use one, we need to agree on what kinds of
solutions are acceptable.
> Alternately, other entities in the locality can use force to require the
> polluting entity to clean up or suffer significant consequences.
> This at least is better incentive-wise, as they others in the same locality
> are the ones most affected, but the ability to enforce may be difficult due
> to various political constructions; the miners could be in such deep cahoots
> with the local government that the local government would willingly hurt
> other local entities in the vicinity of the polluting entity.
As bitcoin grows, if people ask some locality to enforce behavior,
they may need to be willing to enforce it themselves, too, or they
might outcompete the locality.

2023-06-07 22:53:26

- reply

📅 Original date posted:2021-05-16
📝 Original message:[sorry if I haven't replied to the other thread on this, I get swamped
by email and don't catch them all]
This solution is workable but it seems somewhat difficult to me at this time.
The clock might be implementable on a peer network level by requiring
inclusion of a transaction that was broadcast after a 9 minute delay.
Usually a 50% hashrate attack is needed to reverse a transaction in
bitcoin. With this change, this naively appears to become a 5%
hashrate attack, unless a second source of truth around time and order
is added, to verify proposed histories with.
A 5% hashrate attack is much harder here, because the users of mining
pools would be mining only 10% of the time, so compromising mining
pools would not be as useful.
Historically, hashrate has increased exponentially. This means that
the difficulty of performing an attack, whether it is 5% or 50%, is
still culturally infeasible because it is a multiplicative, rather
than an exponential, change.
If this approach were to be implemented, it could be important to
consider how many block confirmations people wait for to trust their
transaction is on the chain. A lone powerful miner could
intentionally fork the chain more easily by a factor of 10. They
would need to have hashrate that competes with a major pool to do so.
> How would you prevent miners to already compute the simpler difficulty problem directly after the block was found and publish their solution directly after minute 9? We would always have many people with a finished / competing solution.
Such a chain would have to wait a longer time to add further blocks
and would permanently be shorter.
> Your proposal won’t save any energy because it does nothing to decrease the budget available to mine a block (being the block reward).
You are assuming this budget is directly related to energy
expenditure, but if energy is only expended for 10% of the same
duration, this money must now be spent on hardware. The supply of
bitcoin hardware is limited.
In the long term, it won't be, so a 10% decrease is a stop-gap
measure. Additionally, in the long term, we will have quantum
computers and AI-designed cryptography algorithms, so things will be
different in a lot of other ways too.

2023-06-07 22:52:39

- reply

📅 Original date posted:2021-05-08
📝 Original message:>
> What is more important;
> Bitcoin mining introduces the first free-market demand for the cheapest
> energy source.
This is a really great idea but I think access to technologically advanced
hardware is a stronger component than energy here.
Making open community chip fabs might change that. Then anybody could get
on the bandwagon. But right now the hardware barrier keeps the common
person out.
If you can build a chip fab, you may also be able to build a powerplant.
Not many others can do that to compete with you. The energy economy still
has more supply than competition or renewable energy would quickly
outcompete nonrenewable as the price dropped.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210508/416f416a/attachment.html>

2023-06-07 22:52:38

- reply

📅 Original date posted:2021-05-09
📝 Original message:On Sun, May 9, 2021, 6:21 AM R E Broadley <
rebroad+linuxfoundation.org at gmail.com> wrote:
> On Sat, 8 May 2021 at 15:36, Karl via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > Bitcoin would get better mainstream public reputation if the block
> reward were reduced to reduce mining. This would quickly and easily reduce
> energy expenditure.
>
> You're in luck then, as the block reward is being reduced by 50%, every 4
> years.
>
I'm aware of that and it is why I mentioned "block reward termination" in
the next paragraph... did you receive the rest of my message? Or why do
you say this?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210509/6cd06ec8/attachment-0001.html>

2023-06-07 22:52:37

- reply

📅 Original date posted:2021-05-08
📝 Original message:Bitcoin would get better mainstream public reputation if the block reward
were reduced to reduce mining. This would quickly and easily reduce energy
expenditure.
A system would be needed to do that with consensus, to make it political.
For example, making a norm of extending the block reward termination
farther into the future, spreading the remaining coins out more thinly, but
never doing the opposite.
PoS can be made to work but it's hard to do so amid such disagreement. It
is so hard to express one's relevant information concisely and effectively.
I recommended earlier finding or hiring an experienced facilitator who
could make sure all concerns around the chain are included by engaging all
the dialog more productively. Somebody would need to be available to do
the work of finding such a person and any compensation they might need.
On Fri, May 7, 2021, 7:05 PM Eric Voskuil via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> https://github.com/libbitcoin/libbitcoin-system/wiki/Proof-of-Stake-Fallacy
>
This wiki states things as impossible but does not at all demonstrate them
to be so.
The assumption that something is impossible always relies on many other
assumptions, and the reader may have different ones from the author.
Quote from Proof-of-Stake-Fallacy
> In Other Means Principle it is shown that censorship resistance depends
on people paying miners to overpower the censor.
> Overcoming censorship is not possible in a PoS system, as the censor has
acquired majority stake and cannot be unseated.
If the link in that text is followed you get,
Quote from Other Means Principle:
> Given that mining is necessarily anonymous, there is no way for the
economy to prevent state participation in mining.
The article then goes on to assume this, but "no way" is a circular link
back to Proof-of-Stake-Fallacy!
Never is it demonstrated that a censor will always be able to have majority
stake. In a PoS system, they would have to be able to form false chain
histories to do that. In a PoW system, they would have to outcompete the
work.
These are not inherent limitations. The whole world is open. Consider a
proof of work algorithm that requires the freeing of prisoners: a state a
very different state if it does this. Or a communication protocol that
already cannot be intercepted. These things are exotically hard, but not
impossible, and show that the logic of the articles is not valid.
Another random idea: incentivising out-of-band channels, for example.
Mining blocks based on finding and uniting illegitimate forks. Now a chain
functions by defeating its own censorship.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210508/0f6fc4e7/attachment.html>