greg misiorek [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2016-10-13 to 2017-10-10
💬 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 18:06:54

- reply

📅 Original date posted:2017-10-10
📝 Original message:Yes, I agree. Hard forks should be as much scrutinized by fellow bitcoiners, i.e. developers and holders and not only rushed by miners or some other investment gurus, whose incentives are not entirely clear, to remain as decentralized as economically possible.
________________________________
From: bitcoin-dev-bounces at lists.linuxfoundation.org <bitcoin-dev-bounces at lists.linuxfoundation.org> on behalf of Mark Friedenbach via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
Sent: Monday, October 9, 2017 10:19 PM
To: Scott Roberts; Bitcoin Protocol Discussion
Subject: Re: [bitcoin-dev] New difficulty algorithm needed for SegWit2x fork? (reformatted text)
The problem of fast acting but non vulnerable difficulty adjustment algorithms is interesting. I would certainly like to see this space further explored, and even have some ideas myself.
However without commenting on the technical merits of this specific proposal, I think it must be said upfront that the stated goal is not good. The largest technical concern (ignoring governance) over B2X is that it is a rushed, poorly reviewed hard fork. Hard forks should not be rushed, and they should receive more than the usual level of expert and community review.
I’m that light, doing an even more rushed hard fork on an even newer idea with even less review would be hypocritical at best. I would suggest reframing as a hardfork wishlist research problem for the next properly planned hard fork, if one occurs. You might also find the hardfork research group a more accommodating venue for this discussion:
https://bitcoinhardforkresearch.github.io/
Welcome - Bitcoin Hard Fork Research<https://bitcoinhardforkresearch.github.io/>
bitcoinhardforkresearch.github.io
Bitcoin Hard Fork Research This website will be updated with relevant ongoing information about Bitcoin hard fork research. Resources: BIP-MMHF, draft patch last ...
On Oct 9, 2017, at 3:57 PM, Scott Roberts via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org<mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
Sorry, my previous email did not have the plain text I intended.
Background:
The bitcoin difficulty algorithm does not seem to be a good one. If there
is a fork due to miners seeking maximum profit without due regard to
security, users, and nodes, the "better" coin could end up being the
minority chain. If 90% of hashrate is really going to at least initially go
towards using SegWit2x, BTC would face 10x delays in confirmations
until the next difficulty adjustment, negatively affecting its price relative
to BTC1, causing further delays from even more miner abandonment
(until the next adjustment). The 10% miners remaining on BTC do not
inevitably lose by staying to endure 10x delays because they have 10x
less competition, and the same situation applies to BTC1 miners. If the
prices are the same and stable, all seems well for everyone, other things
aside. But if the BTC price does not fall to reflect the decreased hashrate,
he situation seems to be a big problem for both coins: BTC1 miners will
jump back to BTC when the difficulty adjustment occurs, initiating a
potentially never-ending oscillation between the two coins, potentially
worse than what BCH is experiencing. They will not issue coins too fast
like BCH because that is a side effect of the asymmetry in BCH's rise and
fall algorithm.
Solution:
Hard fork to implement a new difficulty algorithm that uses a simple rolling
average with a much smaller window. Many small coins have done this as
a way to stop big miners from coming on and then suddenly leaving, leaving
constant miners stuck with a high difficulty for the rest of a (long) averaging
window. Even better, adjust the reward based on recent solvetimes to
motivate more mining (or less) if the solvetimes are too slow (or too fast).
This will keep keep coin issuance rate perfectly on schedule with real time.
I recommend the following for Bitcoin, as fast, simple, and better than any
other difficulty algorithm I'm aware of. This is the result of a lot of work the
past year.
=== Begin difficulty algorithm ===
# Zawy v6 difficulty algorithm (modified for bitcoin)
# Unmodified Zawy v6 for alt coins:
# http://zawy1.blogspot.com/2017/07/best-difficulty-algorithm-zawy-v1b.html
# All my failed attempts at something better:
# https://github.com/seredat/karbowanec/commit/231db5270acb2e673a641a1800be910ce345668a
#
# Keep negative solvetimes to correct bad timestamps.
# Do not be tempted to use:
# next_D = sum(last N Ds) * T / [max(last N TSs) - min(last N TSs];
# ST= Solvetime, TS = timestamp
# set constants until next hard fork:
T=600; # coin's TargetSolvetime
N=30; # Averaging window. Smoother than N=15, faster response than N=60.
X=5;
limit = X^(2/N); # limit rise and fall in case of timestamp manipulation
adjust = 1/(1+0.67/N); # keeps avg solvetime on track
# begin difficulty algorithm
avg_ST=0; avg_D=0;
for ( i=height; i > height-N; i--) { # go through N most recent blocks
avg_ST += (TS[i] - TS[i-1]) / N;
avg_D += D[i]/N;
}
avg_ST = T*limit if avg_ST > T*limit;
avg_ST = T/limit if avg_ST < T/limit;
next_D = avg_D * T / avg_ST * adjust;
# Tim Olsen suggested changing reward to protect against hash attacks.
# Karbowanek coin suggested something similar.
# I could not find anything better than the simplest idea below.
# It was a great surprise that coin issuance rate came out perfect.
# BaseReward = coins per block
next_reward = BaseReward * avg_ST / T;
======= end algo ====
Due to the limit and keeping negative solvetimes in a true average,
timestamp errors resulting in negative solvetimes are corrected in the next
block. Otherwise, one would need to do like Zcash and cause a 5-block
delay in the response by resorting to the median of past 11 blocks (MPT)
as the most recent timestamp, offsetting the timestamps from their
corresponding difficulties by 5 blocks. (it does not cause an averaging
problem, but it does cause a 5-block delay in the response.)
_______________________________________________
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/20171010/423c22c5/attachment.html>

2023-06-07 18:06:54

- reply

2023-06-07 17:59:10

- reply

📅 Original date posted:2017-04-05
📝 Original message:I'm not an expert to refute this classification, but would love to see those points addressed by those in the know, without resorting to ad hominem, even though I know it's really hard.
thx, gm
________________________________
From: Johnson Lau via bitcoin-dev<mailto:bitcoin-dev at lists.linuxfoundation.org>
Sent: ‎4/‎5/‎2017 6:28 AM
To: bitcoin-dev<mailto:bitcoin-dev at lists.linuxfoundation.org>
Subject: [bitcoin-dev] A different approach to define and understand softforks and hardforks
Softforks and hardforks are usually defined in terms of block validity (BIP99): making valid blocks invalid is a softfork, making invalid blocks valid is a hardfork, and SFs are usually considered as less disruptive as it is considered to be “opt-in”. However, as shown below this technical definition could be very misleading. Here I’m trying to redefine the terminology in terms of software upgrade necessity and difficulty.
Softforks are defined as consensus rule changes that non-upgraded software will be able to function exactly as usual, as if the rule changes have never happened
Hardforks are defined as consensus rule changes that non-upgraded software will cease to function or be severely handicapped
SFs and HFs under this definitions is a continuum, which I call it “hardfork-ness”. A pure softfork has no hardfork-ness.
*Mining node
Under this definitions, for miners, any trivial consensus rule changes is somewhat a hardfork, as miners can’t reliably use non-upgraded software to create blocks. However, there is still 3 levels of “hardfork-ness”, for example:
1. Those with lower hardfork-ness would be the SFs that miners do not need to upgrade their software at all. Instead, the minimum requirement is to setup a boarder node with latest rules to make sure they won’t mine on top of an invalid block. Examples include CSV and Segwit
2. Some SFs have higher hardfork-ness, for example BIP65 and BIP66. The minimum actions needed include setting up a boarder node and change the block version. BIP34 has even higher hardfork-ness as more actions are needed to follow the new consensus.
3. Anything else, ranging from simple HFs like BIP102 to complete HFs like spoonnet, or soft-hardfork like forcenet, have the highest hardfork-ness. In these cases, boarder nodes are completely useless. Miners have to upgrade their servers in order to stay with the consensus.
*Non-mining full node
Similarly, in terms of non-mining full node, as the main function is to fully-validate all applicable rules on the network, any consensus change is a hardfork for this particular function. However, a technical SF would have much lower hardfork-ness than a HF, as a border node is everything needed in a SF. Just consider a company has some difficult-to-upgrade software that depends on Bitcoin Core 0.8. Using a 0.13.1+ boarder node will make sure they will always follow the latest rules. In case of a HF, they have no choice but to upgrade the backend system.
So we may use the costs of running a boarder node to further define the hardfork-ness of SFs, and it comes to the additional resources needed:
1. Things like BIP34, 65, 66, and CSV involves trivial resources use so they have lowest hardfork-ness.
2. Segwit is higher because of increased block size.
3. Extension block has very high hardfork-ness as people may not have enough resources to run a boarder node.
* Fully validating wallets
In terms of the wallet function in full node, without considering the issues of validation, the hardfork-ness could be ranked as below:
1. BIP34, 65, 66, CSV, segwit all have no hardfork-ness for wallets. Non-upgraded wallets will work exactly in the same way as before. Users won’t notice any change at all. (In some cases they may not see a new tx until it has 1 confirmation, but this is a mild issue and 0-conf is unsafe anyway)
2. Extension block, as presented in my January post ( https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013490.html ), has higher hardfork-ness, as users of legacy wallets may find it difficult to receive payments from upgraded wallet. However, once they got paid, the user experience is same as before
3. Another extension block proposal ( https://github.com/tothemoon-org/extension-blocks ) has very high hardfork-ness for wallets, as legacy wallets will frequently and suddenly find that incoming and outgoing txs becoming invalid, and need to sign the invalidated txs again, even no one is trying to double spend.
4. Hardfork rule changes have highest hardfork-ness for full node wallets
I’ll explain the issues with extension block in a separate post in details
* Real SPV wallet
The SPV wallets as proposed by Satoshi should have the ability to fully validate the rules when needed, so they could be somehow seen as fully validating wallets. So far, real SPV wallet is just vapourware.
* Fake SPV wallet, aka light wallet
All the so-called SPV wallets we have today are fake SPV according to whitepaper definition. Since they validate nothing, the hardfork-ness profile is very different:
1. BIP34, 65, 66, CSV, segwit has no hardfork-ness for light wallets. Block size HF proposals (BIP10x) and Bitcoin Unlimited also have no hardfork-ness (superficially, but not philosophically). Along the same line, even an inflation hardfork has no hardfork-ness for light wallets.
2. Extension block has the same kind of hardfork-ness issue as I mentioned.
3. HFs that deliberately breaks light wallets, such as spoonnet, is a complete hardfork.
While some people try to leverage weakness of light wallets, the inability to validate any important rules like block size, double spending, and inflation is a serious vulnerability.
===========
Before I finish, I’d also like to analyse some other interesting cases.
1. Soft-hardfork: which requires miners to mine empty blocks with 0 reward, and put the tx merkle tree in the legacy coinbase (e.g. https://github.com/luke-jr/bips/blob/bip-mmhf/bip-mmhf.mediawiki ). This allows most hardfork-ing changes including block size and inflation. In terms of block validity this is a softfork. But with the definition I presented, soft-hardforks are clearly hardforks for every practical purposes.
2. On-chain KYC, blacklist, account freezing: technically softforks, but all are very disruptive hardforks in terms of user experience.
3. Lightning network and side chains are not consensus rule changes, and they could provide new features without any hardfork-ness.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170405/8a579a9b/attachment.html>

2023-06-07 17:59:10

- reply

2023-06-07 17:57:31

- reply

📅 Original date posted:2017-03-26
📝 Original message:agreed, the 'miner' term has run its course and plays a different role than it was originally set out to do, esp its original distributed nature. the 'mining business' has become concentrated too much and resembles today's financial institutions or simply banks, imho.
still, any form forking has dilutive effect on existing BTC holders.
thx, gm
________________________________
From: bitcoin-dev-bounces at lists.linuxfoundation.org <bitcoin-dev-bounces at lists.linuxfoundation.org> on behalf of Martin Stolze via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
Sent: Saturday, March 25, 2017 1:15 PM
To: praxeology_guy
Cc: bitcoin-dev at lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Inquiry: Transaction Tiering
Thanks, those are valid concerns.
> Potentially miners could create their own private communication channel/listening port for submitting transactions that they would not relay to other miners/the public node relay network.
That is the idea. Transaction Processors could source transactions
from the public mempool as well their proprietary mempool(s).
> Miners would be incentivized to not relay higher fee transactions, because they would want to keep them to themselves for higher profits.
Not so, a user may want to incentivise a specific Transaction
Processor or many. A user can detect this behavior and withdraw his
future business if he notices that his transaction is not included in
a block despite there being transactions with lower fees included.
Remember, the transaction can be advertised to different mempools and
a Transaction Processor could lose this business to a competitor who
processes the next block if he holds it back.
Best Regards
Martin
PS: It seems not too late to get rid of misleading terms like "miner".
Block rewards (infrastructure subsidies) will be neglectable for
future generations and the analogy is exceedingly poor.
On Sat, Mar 25, 2017 at 4:42 AM, praxeology_guy
<praxeology_guy at protonmail.com> wrote:
> Potentially miners could create their own private communication
> channel/listening port for submitting transactions that they would not relay
> to other miners/the public node relay network. Users could then chose who
> they want to relay to. Miners would be incentivized to not relay higher fee
> transactions, because they would want to keep them to themselves for higher
> profits.
>
> Cheers,
> Praxeology Guy
>
>
> -------- Original Message --------
> Subject: Re: [bitcoin-dev] Inquiry: Transaction Tiering
> Local Time: March 22, 2017 12:48 PM
> UTC Time: March 22, 2017 5:48 PM
> From: bitcoin-dev at lists.linuxfoundation.org
> To: bitcoin-dev at lists.linuxfoundation.org
>
> Hi Tim,
> After writing this I figured that it was probably not evident at first
> sight as the concept may be quite novel. The physical location of the
> "miner" is indeed irrelevant, I am referring to the digital location.
> Bitcoins blockchain is a digital location or better digital "space".
> As far as I am concerned the authority lies with whoever governs this
> particular block space. A "miner" can, or can not, include my
> transaction.
>
> To make this more understandable:
>
> Abu Bakr al-Baghdadi can extend his caliphate into Bitcoins block
> space and rule sovereign(!) over a given block. If he processes my
> transaction my fee goes directly into the coffers of his organization.
> The same goes for the Queen of England or the Emperor of China. My
> interest is not necessarily aligned with each specific authority, yet
> as you point out, I can only not use Bitcoin.
> Alternatively, however, I can very well sign my transaction and send
> it to an authority of my choosing to be included into the ledger, say
> BitFurry. - This is what I describe in option 1.
>
> In order to protect my interest I do need to choose, maybe not today,
> but eventually.
>
> I also think that people do care who processes transactions and a lot
> of bickering could be spared if we could choose.
>
> If we assume a perfectly competitive market with 3 authorities that
> govern the block space equally, the marginal cost of 1/3 of the block
> space is the same for each, however, the marginal revenue absent of
> block rewards is dependent on fees.
> If people are willing to pay only a zero fee to a specific authority
> while a fee greater than zero to the others it's clear that one would
> be less competitive.
>
> Let us assume the fees are 10% of the revenue and the cost is 95 we
> have currently the following situation:
>
> A: Cost=95; Revenue=100; Profit=5
> B: Cost=95; Revenue=100; Profit=5
> C: Cost=95; Revenue=100; Profit=5
>
> With transaction tiering, the outcome could be different!
>
> A: Cost=95; Revenue=90; Loss=5 // BSA that does not respect user interest.
> B: Cost=95; Revenue=105; Profit=10
> C: Cost=95; Revenue=105; Profit=10
>
> This could motivate transaction processors to behave in accordance
> with user interest, or am I missing something?
>
> Best Regards,
> Martin
>
>> From: Tim Ruffing <tim.ruffing at mmci.uni-saarland.de>
>> To: bitcoin-dev at lists.linuxfoundation.org
>> Cc:
>> Bcc:
>> Date: Tue, 21 Mar 2017 16:18:26 +0100
>> Subject: Re: [bitcoin-dev] Inquiry: Transaction Tiering
>> (I'm not a lawyer...)
>>
>> I'm not sure if I can make sense of your email.
>>
>> On Mon, 2017-03-20 at 20:12 +0000, Martin Stolze via bitcoin-dev wrote:
>>> As a participant in the economy in general and of Bitcoin in
>>> particular, I desire an ability to decide where I transact. The
>>> current state of Bitcoin does not allow me to choose my place of
>>> business. As a consequence, I try to learn what would be the best way
>>> to conduct my business in good faith. [2]
>>
>> Ignoring the rest, I don't think that the physical location /
>> jurisdiction of the miner has any legal implications for law applicable
>> to the relationship between sender and receiver of a payment.
>>
>> This is not particular to Bitcoin. We're both in Germany (I guess).
>> Assume we have a contract without specific agreements and I pay you in
>> Icelandic kronur via PayPal (in Luxembourg) and my HTTPS requests to
>> PayPal went via Australia and the US. Then German law applies to our
>> contract, nothing in the middle can change that.
>>
>> Also ignoring possible security implications, there is just no need for
>> a mechanism that enables users to select miners. I claim that almost
>> nobody cares who will mine a transaction, because it makes no technical
>> difference. If you don't want a specific miner to mine your
>> transaction, then don't use Bitcoin.
>>
>> Tim
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
bitcoin-dev -- Bitcoin Protocol Discussion - Linux Foundation<https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
lists.linuxfoundation.org
Bitcoin development and protocol discussion. This list is lightly moderated. - No offensive posts, no personal attacks. - Posts must concern development of bitcoin ...
>
>
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
bitcoin-dev -- Bitcoin Protocol Discussion - Linux Foundation<https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
lists.linuxfoundation.org
Bitcoin development and protocol discussion. This list is lightly moderated. - No offensive posts, no personal attacks. - Posts must concern development of bitcoin ...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170326/f13f0828/attachment-0001.html>

2023-06-07 17:57:31

- reply

2023-06-07 17:53:53

- reply

📅 Original date posted:2016-10-13
📝 Original message:Interesting and thx for sharing what a DPL is.
gm
________________________________
From: Peter Todd via bitcoin-dev<mailto:bitcoin-dev at lists.linuxfoundation.org>
Sent: ‎10/‎13/‎2016 4:51 AM
To: bitcoin-dev at lists.linuxfoundation.org<mailto:bitcoin-dev at lists.linuxfoundation.org>
Cc: defensivepatent at gmail.com<mailto:defensivepatent at gmail.com>
Subject: [bitcoin-dev] Defensive Patent License Offer Notice
Also published at https://petertodd.org/2016/defensive-patent-license-offer,
and Bitcoin txid b4bf94f5c457d080924aa163106d423670373cfe3b10f8ec00742c2234b01b72
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
I, Peter Todd, hereby declare myself and all technology companies that I
control as "Defensive" by committing to offer a Defensive Patent License,
version 1.1, for any of my patents either existing or future, to any DPL User.
Neither I nor any companies that I control have any patents at this time.
My contact address is pete at petertodd.org
-----BEGIN PGP SIGNATURE-----
iQEcBAEBCAAGBQJX/t11AAoJEGOZARBE6K+yR00H/0xp3oO7FiMvM4pjfoHZPPOa
m3KjT4RSbFQLa9uniz0u/9bkc5I70CggkY3jtNLtDMbMBTwcMP61ABsvx+5y2gGD
zE6VZ9DPcHVg/Eup6WSBlQO3HQKuFVz7vXSMuaidG7A+fpkU71SjDpB4M6hdvWnS
+L9XBQ1GtQe0lSM73s4mld/IvB1giwPN1bOheQ9koYcQjj+B8PWyt2gIUwctxyvA
7bC+KtCQT4RJPsQHbHx569CDkyIi3dNt0rTjCo5bOeUKrJF7eA3YktYdTJefZ+Rf
00dbRZMslrg3dW9VWECfC0xC/kn+heStJ7WqJJKqYWo4apm6IiKPZxlwIcVscF0=
=xrPk
-----END PGP SIGNATURE-----
# Notes
* On the advice of my lawyer, I'm currently offering only a specific version of
the DPL. I probably will offer licenses under subsequent versions in the
future, but I'd prefer to see how the DPL evolves and whether or not the
license stewards behind it prove trustworthy before committing to doing so.
* The language "all technology companies I control" is there to avoid any
complications with non-technology companies that I may control in the future,
e.g. family real-estate holding companies, and the non-profit caving group
I'm a part of. To my knowledge, I only control one company as of writing, the
numbered company I do all my consulting through; I consider that company a
"technology company", and thus the above offer applies to it.
* Equally, if by some stroke of luck I do end up in control of any other
technology companies - maybe Bill Gate's blockchain smart-contract will
mysteriously gives me control of Microsoft - then the above offer will apply.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161013/ecf32a56/attachment.html>
-------------- next part --------------
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 17:53:53

- reply