<unnamed>

Public Key

npub1hzkv59ax7ax80nv2fzvcgmveqyk3k5sg9gq695n48l9scenf5c9sa7nzv7

Profile Code

nprofile1qqst3tx2z7n0wnrhek9y3xvydkvsztgm2gyz5qdz6f6nljcvve56vzcpz4mhxue69uhhyetvv9ujumn0wd68ytnwv46qz9rhwden5te0wfjkccte9ejxzmt4wvhxjmcpp4mhxue69uhkummn9ekx7mq9ae22l

Publishing to

relay.nostr.net

relay.damus.io

nos.lol

Last Notes

2023-06-07 20:02:01 CEST

- reply

📅 Original date posted:2017-05-30
📝 Original message:Yann, Unfortunately sybil attacks [[https://en.wikipedia.org/wiki/Sybil_attack#Description]](https://en.wikipedia.org/wiki/Sybil_attack#Description) would prevent this from working... even if there was some way to prove that an entity performed the transaction validation. Proving the relay of transaction data to others is also vulnerable to sybil attack.
-------- Original Message --------
Subject: [bitcoin-dev] Improvement Proposal
Local Time: May 30, 2017 8:48 AM
UTC Time: May 30, 2017 1:48 PM
From: bitcoin-dev at lists.linuxfoundation.org
To: bitcoin-dev at lists.linuxfoundation.org
Improvement Proposal
To allow users devices (including mobile and/or IoT devices). to connect and some how participate in the same BTC bock chain network without mining.
The incentive for this participants can be a lottery schema, running in "parallel to mining in the same network" and in the block-chain.
Rewarding some lucky participant user (and/or miner?) randomly every specific period of time.
Participants will pay the price on each connection round.
Yann
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170530/773e2132/attachment-0001.html>

2023-06-07 20:00:33 CEST

- reply

📅 Original date posted:2017-04-26
📝 Original message:Johnson Lau,
> not change the commitment structure as suggested by another post
Not sure if you realize my proposal is backwards compatible. We could also merge the two arrays, which would be harder to compress, but a more simple format. Below I gave an example of how this would be backwards compatible.
1-byte - OP_RETURN (0x6a)
1-byte - Push the following 36 bytes (0x24)
4-byte - Commitment header (0xaa21a9ed)
32-byte - Commitment hash: Double-SHA256(witness root hash|witness reserved value*)
variable bytes - Extension roots: array of {extension identifier, extension root length, extension root}
bytes onwards: Optional data with no consensus meaning
* "witness reserved value" _must_ also go in the input's scriptSig/witness field
Here is an example of the "Extension roots" with this format:
Extension roots: 2, {0, 0, []}, {1, 0, []}
size = 2 // two elements in Commitment hash
{ext.id = 0, length = 0, empty} // First element is the wtxid merkle root hash, must be calculated, not specified here
{ext.id = 1, length = 0, empty} // Second element is the "witness reserved value", which is found in the scriptSig
Later after all the miners upgrade, we could stop using the ext.id = 1 and also stop putting the unneccesary value in scriptSig.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170426/b8487e38/attachment-0001.html>

2023-06-07 20:00:04 CEST

- reply

📅 Original date posted:2017-04-14
📝 Original message:Chris,
>Food for thought, why are we rejecting *all* blocks that do not signal segwit? Can't we just reject blocks that *do not* signal segwit, but *do* contain segwit transactions? It seems silly to me that if a miner mines a block with all pre segwit txs to reject that block. Am I missing something here?
If you read my email, you will see that I am requesting that gmaxwell or someone code up an alternative that doesn't unnecessarily orphan blocks, just as you are requesting.
> Re: old blocks containing SegWit transactions
From my understanding, old blocks can contain txos w/ the new SegWit format. But if transaction tries to spend a new SegWit format txo in an old block, such would already break protocol rules, particularly for SegWit activated nodes. And old nodes don't have code that even knows how to spend SegWit format txos. Worst case, such may lead to a fork if <= 50% of the miners are verifying SegWit blocks.
> Re: Reckless hand waving:
Maybe first you need to prove that forks are necessarily bad for our long term success. How much do we need to be getting delayed in rolling out new good policy before we come to consensus on forking from the delayers?
The operating assumption of 148 is that no matter what we are going to fork. So might as well do it then in a controlled manner instead of later when someone creates an invalid SegWit block. Then my only recommendation would be to also implement a boilerplate replay attack prevention just in case the SegWit delayers aren't bluffing.
Cheers,
Praxeology Guy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170414/9c02fbf0/attachment.html>

2023-06-07 20:00:03 CEST

- reply

📅 Original date posted:2017-04-14
📝 Original message:Gregory Maxwell,
Criticizing 148 without suggesting a specific alternative leaves the community in disarray.
I know you are emphasizing patience. But at the same time, with your patience we are allowing ourselves to get dicked for longer than necessary.
I think that core could easily develop code that could create a solid/reliable date/height based activation to allow miners to create SegWit block candidates and having nodes fully verify them. Shaolinfry is the only person Ive seen actually make such a proposal: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/014049.html. His makes it so that SegWit default gets activated at the end of the BIP9 signalling timeframe instead of default leaving it non-activated.
I agree that 148 is is not ideal. Non-SegWit signaling blocks are not a Denial of Service, given that other activation methods are available. Someone just needs to code something up that is better that we can all use in a satisfying time frame. So far 148 is the most practical and reliable method I'm aware of.
If 148 causes orphaning and a fork, I don't think such really matters in the long term. The non-SegWit miners will probably just quickly give up their orphans once they realize that money users like being able to have non-mutable TX IDs. If they do create a long lasting branch... well that is good too, I'd be happy to no longer have them in our community. Good luck to them in creating a competitive money, so that we can all enjoy lower transaction fees.
SegWit has already undergone enough testing. It is time to activate it.
Cheers,
Praxeology Guy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170414/a6c9a6ec/attachment.html>

2023-06-07 19:59:49 CEST

- reply

📅 Original date posted:2017-04-08
📝 Original message:Eric Voskuil,
TL;DR: Electrical power is a general purpose consumer good vs PoW mining equipment is a single purpose consumer good. Hence the mining equipment rent is the barrier to entry, given if you invest in power generation capital you could use the power for a different purpose.
Each unit of electrical power (1 V* A = 1 Watt) is a finite unit of a highly non-durable consumable good.
It is true that electrical power is created by utilizing capital equipment, and the capital rent + labor of generating such power is the basis for the "Power Cost" component of the ideal miner competition profit equation.
But... electrical power is a general consumer good that can be used for many things, so investing in the capital to create it is not a very risky endeavor.
On the other hand, Bitcoin mining equipment capital is an EXTEREMELY specific kind of capital that only has exactly one use: efficiently/competitively mining a coin that has a particular PoW algorithm. Hence investing in bitcoin mining equipment is a more risky endeavor than power generation capital. Such a risk is a barrier to entry, and it is the barrier that is most considered when an entity considers mining Bitcoins.
Mature Arithmetic Logic Unit (ALU) bound PoW algorithms lacking new attacks (cryptographic definition) can only be out-dated by more efficient, more general purpose (less specific case proprietary) transistor fabrication technology.
Memory Latency bound PoW algorithms lacking new attacks (cryptographic definition) have the risk of being encumbered by all sorts of physical hardware patent inventions. This is because latency has significantly more room for such specific-to-PoW non-general purpose inventions... beyond additional patents relating to memory technology on top of ALU patents. Patents, I should point out, either cause the price of capital equipment to increase or enforce a monopoly on the capital... neither of which are desirable.
The capital maturity outlook of memory latency bound algorithms is also significantly worse than ALU bound... due to all of the expected future patent-able optimizations that could improve memory latency. Hence investing in memory latency bound mining equipment is even riskier because of the likeliness of a new patented optimization making your capital non-competitive, and given its specific nature, worthless.
This discussion brings me to a new insight. We have said that some places have "cheaper" power than others, due to the non-durable nature of electrical power. With the existence of Bitcoin, given other cost factors being less significant, Bitcoin causes all sources of power everywhere to be more equal in price at a particular time.
Now you might argue that memory latency bound PoW algorithms result in the mining capital component being the larger component than the electricity component being a good thing because: then mining would be less local to otherwise untapped (cheap) power sources. The problem with this is that as the mining capital matures (as all the optimizations are found, and the patents run out), we go strait back to the power cost being the largest component... and we had to suffer all the years of various entities unpredictably attaining a monopoly on mining in order to get there.
Please let me know if I made a mistake.
Thanks,
Praxeology Guy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170408/f2ddc5bf/attachment-0001.html>

2023-06-07 19:59:48 CEST

- reply

📅 Original date posted:2017-04-08
📝 Original message:ASICBOOST causes Bitcoin's PoW to become more memory/latency throttled instead of raw computation throttled.
There is the equation:
Power Cost + Captial Rent + Labor ~= block reward + fees
Capital Rent is a barrier to entry, and hence in desiring a more distributed system, we would like to minimize the Capital Rent portion of the equation.
Resolving memory/latency throttle requires a greater Captial Rent than raw computation throttle.
Hence (agreeing with Luke), ASICBOOST is not desirable, even if it wasn't a government enforced monopoly on mining.
Please let me know if I made a mistake.
Thanks,
Praxeology Guy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170408/57669e84/attachment.html>

2023-06-07 19:59:47 CEST

- reply

📅 Original date posted:2017-04-07
📝 Original message:Jimmy Song,
Why would the actual end users of Bitcoin (the long term and short term owners of bitcoins) who run fully verifying nodes want to change Bitcoin policy in order to make their money more vulnerable to 51% attack?
If anything, we would be making policy changes to prevent the use of patented PoW algorithms instead of making changes to enable them.
Thanks,
Praxeology Guy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170407/94f12622/attachment.html>

2023-06-07 19:59:31 CEST

- reply

📅 Original date posted:2017-04-07
📝 Original message:shaolinfry,
Not sure if you noticed my comments on your earlier orphaning proposal... but if you did you should already know that I really like this proposal... particularly since orphaning valid old blocks is completely unnecessary.
I really like how you pulled out the "lockinontimeout" variable so that this same method could be used in future softfork proposals... instead of hardcoding a special case hack for SegWit.
- it would be nice if the user could set this variable in a configuration file.
- it would be nice if the user could set the "nTimeout" in "src/chainparams.cpp" in a configuratoin file too. This could be used allow a user to expedite when a softfork would become active on his node when combined with ."lockinontimeout".
Developers such as the Core team could put more conservative values in the program, and then community members such as miners and nodes who feel more strongly about SegWit could either compile their own settings or maybe copy a popular configuration file if such was made possible.
Cheers,
Praxeology Guy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170407/5c37bfa4/attachment-0001.html>

2023-06-07 19:58:15 CEST

- reply

📅 Original date posted:2017-03-29
📝 Original message:Peter R said: "On that topic, are there any existing proposals detailing a canonical ordering of the UTXO set and a scheme to calculate the root hash?"
I created such here: "A Commitment-suitable UTXO set "Balances" file data structure": https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013692.html
In short it periodically makes snapshots on the state of the UTXO N blocks ago, where N = the snapshot period. UTXOs are ordered by TXID. I've also implemented it in C and tested making them.
gmaxwell says the utxo data format will change and I have other recommended changes to the chainstate database in order to make this more efficient. He pointed me to another similar solution... and suggested this would be done later after SegWit and after the UTXO data format was changed in the chainstate database.
Cheers,
Praxeology Guy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170329/7498459c/attachment.html>

2023-06-07 19:58:07 CEST

- reply

📅 Original date posted:2017-03-29
📝 Original message:I think at least the three following things have to be done before the block size can be increased by any significant amount:
1. A network protocol defined UTXO snapshot format be defined, UTXO snapshots being created automatically in a deterministic periodic and low-cost fashion. Ability to synchronize starting from such a UTXO snapshot as requested by a user.
2. SPV support from a pruned node that has the latest UTXO snapshot. Probably requires committing the UTXO snapshot hash to the block.
3. Given the above fixes the problem of needing full block chain history storage, and people are comfortable with such a security model, a good portion of the network can switch to this security model, and still satisfy our desire for the system to be sufficiently distributed. This requires lots of testing.
4. More current studies on the effect of increasing the block size on synchronizing node drop out due to other reasons such as network bandwidth, memory, and CPU usage.
Without doing the above, scheduling to increasing the block size would be wreckless.
Cheers,
Praxeology Guy
-------- Original Message --------
Subject: Re: [bitcoin-dev] Hard fork proposal from last week's meeting
Local Time: March 29, 2017 2:10 PM
UTC Time: March 29, 2017 7:10 PM
From: bitcoin-dev at lists.linuxfoundation.org
To: Martin Lízner <martin.lizner at gmail.com>, Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org>
In order for any blocksize increase to be agreed upon, more consensus is needed. The proportion of users believing no blocksize increases are needed is larger than the hardfork target core wants(95% consensus). The proportion of users believing in microtransactions for all is also larger than 5%, and both of those groups may be larger than 10% respectively. I don't think either the Big-blocks faction nor the low-node-costs faction have even a simple majority of support. Getting consensus is going to be a big mess, but it is critical that it is done.
On Wed, Mar 29, 2017 at 12:49 AM, Martin Lízner via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
If there should be a hard-fork, Core team should author the code. Other dev teams have marginal support among all BTC users.
Im tending to believe, that HF is necessary evil now. But lets do it in conservative approach:
- Fix historical BTC issues, improve code
- Plan HF activation date well ahead - 12 months+
- Allow increasing block size on year-year basis as Luke suggested
- Compromise with miners on initial block size bump (e.g. 2MB)
- SegWit
Martin Lizner
On Tue, Mar 28, 2017 at 6:59 PM, Wang Chun via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
I've proposed this hard fork approach last year in Hong Kong Consensus
but immediately rejected by coredevs at that meeting, after more than
one year it seems that lots of people haven't heard of it. So I would
post this here again for comment.
The basic idea is, as many of us agree, hard fork is risky and should
be well prepared. We need a long time to deploy it.
Despite spam tx on the network, the block capacity is approaching its
limit, and we must think ahead. Shall we code a patch right now, to
remove the block size limit of 1MB, but not activate it until far in
the future. I would propose to remove the 1MB limit at the next block
halving in spring 2020, only limit the block size to 32MiB which is
the maximum size the current p2p protocol allows. This patch must be
in the immediate next release of Bitcoin Core.
With this patch in core's next release, Bitcoin works just as before,
no fork will ever occur, until spring 2020. But everyone knows there
will be a fork scheduled. Third party services, libraries, wallets and
exchanges will have enough time to prepare for it over the next three
years.
We don't yet have an agreement on how to increase the block size
limit. There have been many proposals over the past years, like
BIP100, 101, 102, 103, 104, 105, 106, 107, 109, 148, 248, BU, and so
on. These hard fork proposals, with this patch already in Core's
release, they all become soft fork. We'll have enough time to discuss
all these proposals and decide which one to go. Take an example, if we
choose to fork to only 2MB, since 32MiB already scheduled, reduce it
from 32MiB to 2MB will be a soft fork.
Anyway, we must code something right now, before it becomes too late.
_______________________________________________
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/20170329/44936f5e/attachment-0001.html>