<unnamed>

Public Key

npub10tqt6wdc2neye0cxwyphtre6n5uccgur94khtqjdry9wxhrvywlq6w9uu9

Profile Code

nprofile1qqs84s9a8xu9fujvhur8zqm43uaf6wvvywpj6mt4sfx3jzhrt3kz80spz4mhxue69uhhyetvv9ujumn0wd68ytnwv46qms0gga

Publishing to

relay.nostr.net

Last Notes

2023-06-07 23:11:16 UTC

- reply

📅 Original date posted:2022-07-08
📝 Original message:What do you do if the "first" word (of 12), happens to be the last word in
the list alphabetically? So that seems like a dead end.
Since users are never expected to memorize the "whole list" (of 2048 words)
in any case, it seems that the smarter thing to do (if this "order"
criterion is desirable) may have been to just make the whole list 12x
longer and cut it into 12 sections. Each of the 12 slots would have 2048
distinct words. Then the computer would handle the order; the user could
neglect it.
I can guess why people weren't particularly interested in this: words
always have to be written down in some order or another. Even if you write
them down in a 3x4 grid, there are very few combinations needed to guess
the one true ordering. I wonder how obscure the words would have to be, by
the 12th list of 2048? But still it might be fun - the 4th word might
always be a nautical word, the 5th word a farm word, etc. And no one would
confuse it with a bip39 phrase -- in fact since they are just lists of
integers 1 to 2048, it would be pretty easy to make them interoperable.
Very easy but perhaps still not worth doing.
Paul
On Fri, Jul 8, 2022, 4:48 AM vjudeu via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Isn't it enough to just generate a seed in the same way as today, then
> sort the words alphabetically, and then use that as a seed? I know, the
> last word is a checksum, but there are only 2048 words, so it is not a big
> deal to get any checksum we want. If that is insecure, because of lower
> possible combinations, then it is always possible to increase the number of
> words to compensate that.
>
>
> On 2022-07-08 04:27:21 user Eric Voskuil via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
> Without a performance requirement there is no reason you can’t store the
> BIP39 words in any order you want. So it’s certainly possible, just brute
> force the recovery. If you have less than a second vs. a few days then it’s
> a different question.
>
>
> e
>
>
> On Jul 7, 2022, at 18:48, Bram Cohen via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> Part of the rules of my challenge is that the 'new' words need to be in
> the same pool as the 'old' words, so any ordering is okay. Without that
> requirement it's mathematically very straightforward.
>
>
> On Thu, Jul 7, 2022 at 10:52 AM Pavol Rusnak <stick at satoshilabs.com>
> wrote:
> There is. Just encode the index of permutation used to scramble the
> otherwise sorted list. For 12 words you need to store 12! = ~32 bits so 3
> words should be enough.
>
>
> Repetitions make this more difficult, though.
>
>
> On Thu 7. 7. 2022 at 19:41, Bram Cohen via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Thu, Jul 7, 2022 at 7:43 AM Anton Shevchenko via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> I made a python implementation for a different mnemonic encoding. The
> encoding requires user to remember words but not the order of those words.
> The code is open (MIT license) at https://github.com/sancoder/noomnem
>
>
>
> Thanks Anton. There's an interesting mathematical question of whether it's
> possible to make a code like this which always uses the BIP-39 words for
> the same key as part of its encoding, basically adding a few words as error
> correction in case the order is lost or confused. If the BIP-39 contains a
> duplicate you can add an extra word.
> _______________________________________________
> 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/20220708/d55f7008/attachment.html>

2023-06-07 23:05:03 UTC

- reply

📅 Original date posted:2022-03-04
📝 Original message:On 3/4/2022 7:35 AM, Billy Tetrud wrote:
>> sidechains cannot exist without their mainchain ...
>
> A sidechain could stop supporting deposits from or withdrawals to
> bitcoin and completely break any relationship with the main chain.
> I agree this is not as sure of a thing as starting with an altcoin
> (which of course never has that kind of relationship with bitcoin).
> So I do think there are some merits to sidechains in your scenario.
> However, I don't think its quite accurate to say it completely
> solves the problem (of a less-secure altcoin becoming dominant).
It is hard to see how this "sidechain cuts off the mainchain" scenario
could plausibly be in enough people's interest:
* Miners would lose the block subsidy (ie, the 6.25 BTC, or whatever of
it that still remains), and txn fees from the mainchain and all other
merged mined chains.
* Developers would lose the ability to create a dissenting new piece of
software (and would instead be forced into a permanent USSR-style "one
party system" intellectual monoculture).
* Users would lose --permanently-- the ability to take their coins to
new blockchains, removing almost all of their leverage.
Furthermore, because sidechains cannot exist without their parent (but
not vice-versa), we can expect a large permanent interest in keeping
mainchain node costs low. Aka: very small mainchain blocks forever. So,
the shut-it-down mainchain-haters, would have to meet the question "why
not just leave things the way they are?". And the cheaper the
mainchain-nodes are, the harder that question is to answer.
However, if a sidechain really were so overwhelmingly popular as to
clear all of these hurdles, then I would first want to understand why it
is so popular. Maybe it is a good thing and we should cheer it on.
> Your anecdote about not running a full node is amusing, and I've often
> found myself in that position. I certainly agree different people are
> different and so different trade offs can be better for different
> people. However, the question is: what tradeoffs does a largeblock
> sidechain do better than both eg Visa and lightning?
Yes, that's true. There are very many tradeoffs in general:
1. Onboarding
2. Route Capacity / Payment Limits
3. Failed Payments
4. Speed of Payment
5. Receive while offline / need for interaction/monitoring/watchtowers
6. Micropayments
7. Types of fees charged, and for what
8. Contribution to layer1 security budget
9. Auditability (re: large organizations) / general complexity
LN is certainly better for 4 and 6. But everything else is probably up
for grabs. And this is not intended to be an exhaustive list. I just
made it up now.
(And, if the layer2 is harmless, then its existence can be justified via
one single net benefit, for some users, somewhere on the tradeoff-list.)
Paul

2023-06-07 23:05:02 UTC

- reply

📅 Original date posted:2022-03-01
📝 Original message:On 3/1/2022 12:39 AM, Billy Tetrud wrote:
>> This entire issue is avoided completely, if all the chains
>> --decentralized and centralized-- and in the same monetary unit.
>> Then, the monetary network effects never interfere, and the
>> decentralized chain is always guaranteed to exist.
> It sounds like what you're saying is that without side chains,
> everyone might switch entirely to some altcoin and bitcoin will
> basically die. And at that point, the insecurity of that coin people
> switched to can be heavily exploited by some attacker(s). Is that right?
Yes, precisely.
> Its an interesting thought experiment. However, it leads me to wonder:
> if a sidechain gets so popular that it dominates the main chain, why
> would people keep that main chain around at all?
For some reason, this is a very popular question. I suppose if you believe in "one size fits all" chain philosophy (see comment below), it makes sense to say "these sidechains are terrible" on Monday and then "these sidechains are so good they will replace the mainchain" on Tuesday.
In any event, sidechains cannot exist without their mainchain (as I see it). For example, imagine that you are on a zcash sidechain, and someone claims they deposited 1000 BTC, from Bitcoin Core into this sidechain? Do you give them 1000 z-BTC, or not? Without the mainchain,
you can't tell.
If you run the Bip300 DriveNet demo software (drivechain.info/releases), you will see for yourself: the test-sidechains are absolutely inert, UNTIL they have rpc access to the mainchain. (Exactly the same way that a LN node needs a Bitcoin Core node.)
> > someone is actually in the wrong, if they proactively censor an
> experiment of any type. If a creator is willing to stand behind
> something, then it should be tried.
> > it makes no difference if users have their funds stolen from a
> centralized Solana contract or from a bip300 centralized bit-Solana
> sidechain. I don't see why the tears shed would be any different.
> I agree with you. My point was not that we should stop anyone from
> doing this. My point was only that we shouldn't advocate for ideas we
> think aren't good. You were advocating for a "largeblock sidechain",
> and unless you have good reasons to think that is an idea likely to
> succeed and want to share them with us, then you shouldn't be
> advocating for that. But certainly if someone *does* think so and has
> their own reasons, I wouldn't want to censor or stop them. But I
> wouldn't advocate for them to do it unless their ideas were convincing
> to me, because I know enough to know the dangers of large block
> blockchains.
Yes, I strongly agree, that we should only advocate for ideas we believe in.
I do not believe in naive layer1 largeblockerism. But I do believe in sidechain largeblockism.
Something funny once happened to me when I was on a Bitcoin conference panel*. There were three people: myself, a Blockstream person, and an (ex)BitPay person. The first two of us, were valiantly defending the small block position. I gave my usual speech: that node costs must remain low, so that people can run full nodes. The largeblocker mentioned that they ran many nodes (including BCH nodes etc) and didn't mind the cost, so I disclosed --in a good-natured way-- that I do not even run a BTC full node myself (out of choice). Thus, I was yammering about software I wasn't even running, I had no skin in the game! Lo and behold -- my Blockstream smallblocker ally-on-the-panel, immediately admitted to everyone that he did not run a full node either. The only node-runner was the largeblocker. The audience found this very amusing (as did I).
We smallblockers, justified our sinful nodeless behavior, as follows (paraphrasing): we receive BTC mainly from people that we know (and have a long-term relationship with); our receipts are not time sensitive; we are not paid in BTC that often; if payments turned out to be forged we would have enormous recourse against our counterparties; etc.
We did not run full nodes, because we did not need to draw on the blockchain's powers, **for those transactions**.
Which is my point: people are different, and transactions are different. I make many transactions today, with VISA or Venmo. These are not censorship-resistant, but somehow I survive the month, without bursting into flames.
Wouldn't life be better, if we Bitcoiners could easily sweep those fiat transactions into *some* part of the BTC universe? (For example, a family of largeblock sidechains). To me the answer is clearly yes.
Unlike layer1-largeblockism, no one running Bitcoin Core ever needs to see these 'btc' transactions (the same as we don't see them today, on account of them not existing at all); they do not burden Bitcoin Core full nodes. Hence why it seems like a good idea to me.
An SPV-wallet-of-a-largeblock-sidechain, is of course, a *disgrace* compared to a full-node-of-smallblock-mainchain-Bitcoin-Core. But, it is emphatically superior to Venmo / VISA or even "custodial LN". And certainly superior to nothing.
Paul
*https://www.youtube.com/watch?v=V3cvH2eWqfU
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220301/30a4d2aa/attachment-0001.html>

2023-06-07 23:03:37 UTC

- reply

📅 Original date posted:2022-02-26
📝 Original message:On 2/26/2022 1:43 AM, ZmnSCPxj via bitcoin-dev wrote:
> ...
> Drivechains are not a scaling solution [FOOTNOTE 1] ...
> I personally am interested only in scaling solutions, adding more non-scaling-useable functionality is not of interest to me and I do not really care
> ...
> But if there is consensus that those arguments are bogus, then go ahead --- add Drivechains and/or recursive covenants.
> ...
>
> [FOOTNOTE 1] Sidechains are not a scaling solution ... Blockchains are inefficient ... and you have to show your transaction to everyone.
> ...
> Now you might conter-argue that you can have multiple smaller sidechains and just use HTLCs to trade across them ... I would then counter-counter-argue that bringing this to the most extreme conclusion, you would have tons of sidechains with only 2 participants each ...
Do you really hang your entire --"sidechains are not a scaling solution"-- argument on this frail logic?
The scaling strategy (in LN and DC) is the same: try NOT to "show your transaction to everyone". The details are of course different.
I think largeblock sidechains should be reconsidered:
* They are not a blocksize increase.
* They endorse the principle of scaling in layers.
* They allow users to be different. Some can pay more (for more decentralization), some less (for less decentralization).
(We are currently gambling the entire future of BTC, on the premise that strong decentralization will always be needed at all points in time.)
(This leaves us vulnerable to a strategy where our adversaries temporarily favor/promote centralized chains, so as to "domesticate" / control these in the future.)
* We can learn from past mistakes -- when a new largeblock sidechain is needed, we can make a new one from scratch, using everything we know.
* Different teams can compete, releasing different chains independently; thus curtailing "toxicity".
* All of the fees, paid on all blockchains, arrive as revenue to the same group of miners, thus improving total hashrate/difficulty.
* Sidechains will organize geographically, which may help security (ie, USA could spitefully run full nodes of the "China" largeblock sidechain).
* Relative to LN, users enjoy: unlimited "inbound liquidity", can receive money while offline, no risk that the channel will close, etc.
Certainly, sidechains are NOT for everyone. (Just as [I imagine] the LN is not for everyone.)
However, in 2015, many hardfork-largeblockers said: "we do not run a full node, full nodes are not important; we use SPV; read the whitepaper" etc.
They used SPV completely; and wanted large blocks. Presumably they would be happy users of a largeblock sidechain. So it would be >0 users.
Sadly, this idea is neglected, (I think) because of its unfortunate resemblance to naive-largeblock-ism. This is irrational.
***
You have emphasized the following relation: "you have to show your transaction to everyone" = "thing doesn't scale".
However, in LN, there is one transaction which you must, in fact, "show to everyone": your channel-opener.
Amusingly, in the largeblock sidechain, there is not. You can onboard using only the blockspace of the SC.
(One "rich guy" can first shift 100k coins Main-to-Side, and he can henceforth onboard many users over there. Those users can then onboard new users, forever.)
So it would seem to me, that you are on the ropes, even by your own criterion. [Footnote 1]
***
Perhaps, someone will invent a way, to LN-onboard WITHOUT needing new layer1 bytes.
If so, a "rich man" could open a LN channel, and gradually transfer it to new people.
Such a technique would need to meet two requirements (or, so it seems to me):
#1: The layer1 UTXO (that defines the channel) can never change (ie, the 32-bytes which define the p2sh/tapscript/covenant/whatever, must stay what-they-were when the channel was opened).
#2: The new part-owners (who are getting coins from the rich man), will have new pubkeys which are NOT known, until AFTER the channel is opened and confirmed on the blockchain.
Not sure how you would get both #1 and #2 at the same time. But I am not up to date on the latest LN research.
Paul
[Footnote 1]
I am certainly not a LN expert, so perhaps this analysis is misconceived. But consider these "best case scenario" assumptions for LN:
* Each new channel-open consumes just 32 vbytes (since they are all done via one or more "rich men" who batches all these into one block, 24/7/365)
* Each new channel-open, onboards 5 users at once who are a permanent trust group / channel factory / what-have-you
(these five newcomers must coordinate with each other and the "rich man", presumably via calendly link or whatever, for their one shot at getting on the blockchain).
* That one single channel is able to meet 100% of the user's payment needs
(it never has any problems, with liquidity /balancing /routing /uptime /hotwallet-crashing /counterparty-fees /etc)
(and also, people do NOT desire >1 channel for other reasons: their alt nyms, small business, church, etc)
* 99.9% of the 1MB (vB) blocksize is used for channel-opens (the spare 1000 vb = the coinbase + the single "rich man"-input)
* World population becomes a fixed 8.2 billion (and henceforth stops growing)
By simple envelop math, 6*24*365*(((1000000*.999)/32)*5) / 8.2 billion = ~exactly one year to onboard everyone.
But if the above assumptions contain, say, two orders of magnitude of "optimism", then it would instead take 100 years.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220226/58dfa5d7/attachment.html>

2023-06-07 23:03:32 UTC

- reply

📅 Original date posted:2022-02-23
📝 Original message:On 2/23/2022 6:28 AM, ZmnSCPxj via bitcoin-dev wrote:
> ... Drivechains is implementable on a Turing-complete
> language.
> And we have already rejected Drivechains, for the following reason:
>
> 1. Sidechain validators and mainchain miners have a strong incentive to
> merge their businesses.
> 2. Mainchain miners end up validating and commiting to sidechain blocks.
> 3. Ergo, sidechains on Drivechains become a block size increase.
Is this indeed the reason? Because it is not a good one.
First, (as always) we must ignore BIP 301*. (Since it was invented to cancel point 1. Which it does -- by giving an incentive for side-validators and main-miners to UN-merge their businesses.)
With that out of the way, let's swap "blocksize increase" for "mining via natural gas flaring" :
1. Oil drillers and mainchain miners have a strong incentive** to merge their businesses.
2. Mainchain miners end up drilling for oil.
3. Ergo, sidechains on Drivechains become a requirement, that full nodes mine for oil.
The above logic is flawed, because full nodes can ignore the mining process. Nodes outrank miners.
Merged mining is, in principle, no different from any other source of mining profitability. I believe there is an irrational prejudice against merged mining, because MM takes the form of software. It would be like an NFL referee who refuses to allow their child to play an NFL videogame, on the grounds that the reffing in the game is different from how the parent would ref. But that makes no difference to anything. The only relevant issue is if the child has fun playing the videogame.
(And of course, merged mining long predates drivechain, and miners are MMing now, and have been for years. It was Satoshi who co-invented merged mining, so the modern prejudice against it is all the more mysterious.)
> Also:
>
> 1. The sidechain-to-mainchain peg degrades the security of sidechain
> users from consensus "everyone must agree to the rules" to democracy
> "if enough enfranchised voters say so, they can beat you up and steal
> your money".
>
> In this write-up, I will...
This is also a mischaracterization.
Drivechain will not work if 51% hashrate is attacking the network. But that is the case for everything, including the Lightning Network***.
So there is no sense in which the security is "degraded". To establish that, one would need arguments about what will probably happen and why. Which is exactly what my original Nov 2015 article contains: truthcoin.info/blog/drivechain/#drivechains-security , as does my Peer Review section :https://www.drivechain.info/peer-review/peer-review-new/
(And, today Largeblocker-types do not have any "everyone must agree to the rules" consensus, at all. Anyone who wants to use a sidechain-feature today, must obtain it via Altcoin or via real-world trust. So the current security is "nothing" and so it is hard to see how that could be "degraded".)
--
I am not sure it is a good use of my time to talk to this list about Drivechain. My Nov 2015 article anticipated all of the relevant misunderstandings. Almost nothing has changed since then.
As far as I am concerned, Drivechain was simply ahead of its time. Eventually, one or more of the following --the problem of Altcoins, the human desire for freedom and creativity, the meta-consensus/upgrade/ossification problem, the problem of persistently low security budget, and/or the expressiveness of Bitcoin smart contracts-- will force Bitcoiners to relearn drivechain-lore and eventually adopt something drivechain-like. At which point I will write to historians to demand credit. That is my plan so far, at least.
--
As to the actual content of your post, it seems pro-Drivechain.
After all, you are saying that Recursive Covenants --> Turing Completeness --> Drivechain. So, which would you rather have? The hacky, bizzaro, covenant-Drivechain, or my pure optimized transparent Bip300-Drivechain? Seems that this is exactly what I predicted: people eventually reinventing Drivechain.
On this topic, in 2015-2016 I wrote a few papers and gave a few recorded talks****, in which I compared the uncontrollable destructive chaos of Turing Completeness, to a "categorical" Turing Completeness where contracts are sorted by category (ie, all of the BitName contracts in the Namecoin-sidechain, all of the oracle contracts in the oracle sidechain, etc). The categorical strategy allows, paradoxically (and perhaps counterintuitively), for more expressive contracts, since you can prevent smart contracts from attacking each other. (They must have a category, so if they aren't Name-contracts they cannot live in the Namecoin-sidechain -- they ultimately must live in an "Evil Sidechain", which the miners have motive and opportunity to simply disable.) If people are now talking about how Turing Completeness can lead to smart contracts attacking each other, then I suppose I was years ahead-of-my-time with that, as well. Incidentally, my conclusion was that this problem is BEST solved by allowing miners to censor contract-categories (aka censor sidechain-categories, aka 'beat people up' as you put it), which is how I invented drivechain in the first place.
*Shrug*,
Paul
*A small table which explains how this works:https://github.com/bitcoin/bips/blob/master/bip-0301.mediawiki#notation-and-example
**Doubtless many of you have heard of this new trend: oil drillers encounter unwanted natural gas, in areas where there are no natural gas customers. Instead of waste this gas, they have begun selling it to miners.https://economictimes.indiatimes.com/news/international/business/oil-drillers-and-bitcoin-miners-bond-over-natural-gas/articleshow/82828878.cms .
***As is well known, it is easy for 51% hashrate to double-spend in the LN, by censoring 'justice transactions'. Moreover, miners seem likely to evade retribution if they do this, as they can restrain the scale, timing, victims, circumstances etc of the attack.
****https://www.youtube.com/watch?v=xGu0o8HH10U&list=PLw8-6ARlyVciMH79ZyLOpImsMug3LgNc4&index=1
https://www.truthcoin.info/blog/contracts-oracles-sidechains/
https://www.truthcoin.info/blog/drivechain-op-code/
https://www.truthcoin.info/blog/wise-contracts/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220223/c5e2b726/attachment.html>

2023-06-07 18:07:24 UTC

- reply

📅 Original date posted:2017-11-06
📝 Original message:+1 to all of Peter Todd's comments
On Nov 6, 2017 11:50 AM, "Peter Todd via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Wed, Nov 01, 2017 at 05:48:27AM +0000, Devrandom via bitcoin-dev wrote:
>
> Some quick thoughts...
>
> > Hi all,
> >
> > Feedback is welcome on the draft below. In particular, I want to see if
> > there is interest in further development of the idea and also interested
> in
> > any attack vectors or undesirable dynamics.
> >
> > (Formatted version available here:
> > https://github.com/devrandom/btc-papers/blob/master/aux-pow.md )
> >
> > # Soft-fork Introduction of a New POW
>
> First of all, I don't think you can really call this a soft-fork; I'd call
> it a
> "pseudo-soft-fork"
>
> My reasoning being that after implementation, a chain with less total work
> than
> the main chain - but more total SHA256^2 work than the main chain - might
> be
> followed by non-supporting clients. It's got some properties of a
> soft-fork,
> but it's security model is definitely different.
>
> > ### Aux POW intermediate block
> >
> > Auxiliary POW blocks are introduced between normal blocks - i.e. the
> chain
> > alternates between the two POWs.
> > Each aux-POW block points to the previous normal block and contains
> > transactions just like a normal block.
> > Each normal block points to the previous aux-POW block and must contain
> all
> > transactions from the aux-POW block.
>
> Note how you're basically proposing for the block interval to be decreased,
> which has security implications due to increased orphan rates.
>
> > ### Heaviest chain rule change
> >
> > This is a semi-hard change, because non-upgraded nodes can get on the
> wrong
> > chain in case of attack. However,
>
> Exactly! Not really a soft-fork.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
> _______________________________________________
> 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/20171106/4c91278d/attachment.html>

2023-06-07 18:04:13 UTC

- reply

📅 Original date posted:2017-07-11
📝 Original message:On 7/11/2017 5:40 PM, Pieter Wuille wrote:
> On Tue, Jul 11, 2017 at 1:36 PM, Paul Sztorc <truthcoin at gmail.com> wrote:
>> Pieter,
>>
>> I think that you have misrepresented Chris' view by taking it out of
>> context. His complete quote reads "If drivechains are successful they should
>> be viewed as the way we scale -- not hard forking the protocol." Chris is
>> comparing Drivechains/sidechains to a hard fork.
> I apologize here; I didn't mean to misrepresent his viewpoint.
I'm sure you did not intend to do so, of course.
>> You went on to "disagree", but every point of contention you introduced was
>> something that would apply to both drivechain-sourced capacity and
>> hardfork-sourced capacity. Neither improves scalability, and both allow
>> users only the opportunity to select a different security model. If I
>> understand you, the point at which a security model does not become
>> "interesting" to you, would be the exact same point in the drivechain and
>> hardfork worlds. Both, at any rate, have the same effect on "validation cost
>> to auditors".
> If you're talking about the extreme case where every full node in the
> increased capacity single chain model corresponds to a node that
> validates both chains and all transfers between them in the
> drivechains, I agree. At that point they become nearly equivalent in
> terms of ease of adoption, resource costs, and capacity.
>
> However, I don't think that is a realistic expectation. When
> considering drivechains as a capacity increase, I believe most people
> think about a situation where there are many chains that give an
> increased capacity combined, but not everyone verifies all of them.
> This is what I meant with uninteresting security model, as it requires
> increased miner trust for preventing the other chains' coins from
> being illegally transferred to the chain you're operating on.
I think I understand what you are saying, but in this case "it" [your
experience] isn't a different security model *for you*. Perhaps we
disagree on the significance of this qualification.
It seems to be me that your position puts you in danger of having to go
out and protect users from investing in insecure _Altcoins_. Probably,
in a world where altcoins were magically impossible, there would be an
even greater demand for Bitcoin capacity than there is in our
Altcoin-filled world (for a few reasons).
> Regardless, people are free experiment and adopt such an approach. The
> nice thing about it not being a hardfork is that it does not require
> network-wide consensus to deploy. However, I don't think they offer a
> security model that should be encouraged, and thus doesn't have a
> place on a roadmap.
I think this is reasonable. It is true that, if no one used drivechains
ever for anything, there would be no transactions offloaded to those
chain, and then no capacity freed up on the original mainchain.
However, though I think your logic is correct in general, I think in
this specific instance it would be somewhat unreasonable to ignore the
fact that, today, we have clear evidence that many people *are* in fact
chomping at the bit to literally leave this blockchain for one that is
almost identical save for a larger maxblocksize.
>> Since their sidechain coins cannot appreciate in value relative
>> to the mainchain coins, users would only opt-in if they felt that they were
>> sufficiently compensated for any and all risks. Hence, it is difficult to
>> list this item as a drawback when, to the user, it is a strict improvement
>> (at least, by any epistemological standard that I can think of). If you have
>> new objections to these claims, I'm sure we would all benefit from hearing
>> them, myself most of all.
> Am I right in summarizing your point here as "This approach cannot
> hurt, because if it were insecure, people can choose to not use it."?
> I'm not sure I agree with that, as network effects or misinformation
> may push users beyond what is reasonable.
Again, I think you may be right. However, users may be similarly misled
in the case of Altcoins (or in the case of investments in fiat
currency), and they may be misled in their use of all kinds of
cryptographic software, and in the clothes that they buy and all of
their other activities.
I would strongly support clear expectations, and constant reminders to
users that the security models are different. Perhaps, even, annoying
dialogue boxes that pop up when/if a user tries to move their funds to a
sidechain.
But, again, this (I think) is something that would *also* apply to a
hard fork. We cannot know if Pieter Wuille, for example, believes that a
given hard fork is "push[ing] users beyond what is reasonable" until we
ask him.
--Paul

2023-06-07 18:04:13 UTC

- reply

📅 Original date posted:2017-07-11
📝 Original message:Pieter,
I think that you have misrepresented Chris' view by taking it out of
context. His complete quote reads "If drivechains are successful they
should be viewed as the way we scale -- not hard forking the protocol."
Chris is comparing Drivechains/sidechains to a hard fork.
You went on to "disagree", but every point of contention you introduced
was something that would apply to both drivechain-sourced capacity and
hardfork-sourced capacity. Neither improves scalability, and both allow
users only the opportunity to select a different security model. If I
understand you, the point at which a security model does not become
"interesting" to you, would be the exact same point in the drivechain
and hardfork worlds. Both, at any rate, have the same effect on
"validation cost to auditors".
The only true difference is the "extra risk of miners being able to vote
to steal your money", but as I have pointed out on this mailing list
several times, I do not actually believe that there is any marginal risk
-- miners can already "vote to steal your money" in the double-spend and
ln-channel-theft contexts. I have also argued that the "risk" is
actually desirable in an opt-in context, because it puts the burden of
proof on miners/developers (to convince users that they should move over
to the sidechain). Since their sidechain coins cannot appreciate in
value relative to the mainchain coins, users would only opt-in if they
felt that they were sufficiently compensated for any and all risks.
Hence, it is difficult to list this item as a drawback when, to the
user, it is a strict improvement (at least, by any epistemological
standard that I can think of). If you have new objections to these
claims, I'm sure we would all benefit from hearing them, myself most of all.
Paul
On 7/11/2017 4:01 PM, Pieter Wuille wrote:
> On Jul 11, 2017 09:18, "Chris Stewart via bitcoin-dev"
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> Concept ACK.
>
> If drivechains are successful they should be viewed as the way we
> scale
>
>
> I strongly disagree with that statement.
>
> Drivechains, and several earlier sidechains ideas, are not a
> scalability improvement, but merely enabling users to opt-in for
> another security model.
>
> While obviously any future with wider adoption will need different
> technologies that have different trade-offs, and anyone is free to
> choose their security model, I don't think this particular one is
> interesting. In terms of validation cost to auditors, it is as bad as
> just a capacity increase on chain, while simultaneously adding the
> extra risk of miners being able to vote to steal your money.
>
> Cheers,
>
> --
> Pieter
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170711/3fa37fbd/attachment.html>

2023-06-07 18:04:10 UTC

- reply

📅 Original date posted:2017-07-10
📝 Original message:Summary
=========
In my opinion, Greg Maxwell's scaling roadmap [1] succeeded in a few
crucial ways. One success was that it synchronized the entire Bitcoin
community, helping to bring finality to the (endless) conversations of
that time, and get everyone back to work. However, I feel that the Dec
7, 2015 roadmap is simply too old to serve this function any longer. We
should revise it: remove what has been accomplished, introduce new
innovations and approaches, and update deadlines and projections.
Why We Should Update the Roadmap
=================================
In a P2P system like Bitcoin, we lack authoritative info-sources (for
example, a "textbook" or academic journal), and as a result
conversations tend to have a problematic lack of progress. They do not
"accumulate", as everyone must start over. Ironically, the scaling
conversation _itself_ has a fatal O(n^2) scaling problem.
The roadmap helped solve these problems by being constant in size, and
subjecting itself to publication, endorsement, criticism, and so forth.
Despite the (unavoidable) nuance and complexity of each individual
opinion, it was at least globally known that X participants endorsed Y
set of claims.
Unfortunately, the Dec 2015 roadmap is now 19 months old -- it is quite
obsolete and replacing it is long overdue. For example, it highlights
older items (CSV, compact blocks, versionbits) as being _future_
improvements, and makes no mention of new high-likelihood improvements
(Schnorr) or mis-emphasizes them (LN). It even contains mistakes (SegWit
fraud proofs). To read the old roadmap properly, one must already be a
technical expert. For me, this defeats the entire point of having one in
the first place.
A new roadmap would be worth your attention, even if you didn't sign it,
because a refusal to sign would still be informative (and, therefore,
helpful)!
So, with that in mind, let me present a first draft. Obviously, I am
strongly open to edits and feedback, because I have no way of knowing
everyone's opinions. I admit that I am partially campaigning for my
Drivechain project, and also for this "scalability"/"capacity"
distinction...that's because I believe in both and think they are
helpful. But please feel free to suggest edits.
I emphasized concrete numbers, and concrete dates.
And I did NOT necessarily write it from my own point of view, I tried
earnestly to capture a (useful) community view. So, let me know how I did.
==== Beginning of New ("July 2017") Roadmap Draft ====
This document updates the previous roadmap [1] of Dec 2015. The older
statement endorsed a belief that "the community is ready to deliver on
its shared vision that addresses the needs of the system while upholding
its values".
That belief has not changed, but the shared vision has certainly grown
sharper over the last 18 months. Below is a list of technologies which
either increase Bitcoin's maximum tps rate ("capacity"), or which make
it easier to process a higher volume of transactions ("scalability").
First, over the past 18 months, the technical community has completed a
number of items [2] on the Dec 2015 roadmap. VersonBits (BIP 9) enables
Bitcoin to handle multiple soft fork upgrades at once. Compact Blocks
(BIP 152) allows for much faster block propagation, as does the FIBRE
Network [3]. Check Sequence Verify (BIP 112) allows trading partners to
mutually update an active transaction without writing it to the
blockchain (this helps to enable the Lightning Network).
Second, Segregated Witness (BIP 141), which reorganizes data in blocks
to handle signatures separately, has been completed and awaits
activation (multiple BIPS). It is estimated to increase capacity by a
factor of 2.2. It also improves scalability in many ways. First, SW
includes a fee-policy which encourages users to minimize their impact on
the UTXO set. Second, SW achieves linear scaling of sighash operations,
which prevents the network from crashing when large transactions are
broadcast. Third, SW provides an efficiency gain for everyone who is not
verifying signatures, as these no longer need to be downloaded or
stored. SegWit is an enabling technology for the Lightning Network,
script versioning (specifically Schnorr signatures), and has a number of
benefits which
are unrelated to capacity [4].
Third, the Lightning Network, which allows users to transact without
broadcasting to the network, is complete [5, 6] and awaits the
activation of SegWit. For those users who are able to make a single
on-chain transaction, it is estimated to increase both capacity and
scalability by a factor of ~1000 (although these capacity increases will
vary with usage patterns). LN also greatly improves transaction speed
and transaction privacy.
Fourth, Transaction Compression [7], observes that Bitcoin transaction
serialization is not optimized for storage or network communication. If
transactions were optimally compressed (as is possible today), this
would improve scalability, but not capacity, by roughly 20%, and in some
cases over 30%.
Fifth, Schnorr Signature Aggregation, which shrinks transactions by
allowing many transactions to have a single shared signature, has been
implemented [8] in draft form in libsecp256k1, and will likely be ready
by Q4 of 2016. One analysis [9] suggests that signature aggregation
would result in storage and bandwidth savings of at least 25%, which
would therefore increase scalability and capacity by a factor of 1.33.
The relative savings are even greater for multisignature transactions.
Sixth, drivechain [10], which allows bitcoins to be temporarily
offloaded to 'alternative' blockchain networks ("sidechains"), is
currently under peer review and may be usable by end of 2017. Although
it has no impact on scalability, it does allow users to opt-in to
greater capacity, by moving their BTC to a new network (although, they
will achieve less decentralization as a result). Individual drivechains
may have different security tradeoffs (for example, a greater reliance
on UTXO commitments, or MimbleWimble's shrinking block history) which
may give them individually greater scalability than mainchain Bitcoin.
Finally, the capacity improvements outlined above may not be sufficient.
If so, it may be necessary to use a hard fork to increase the blocksize
(and blockweight, sigops, etc) by a moderate amount. Such an increase
should take advantage of the existing research on hard forks, which is
substantial [11]. Specifically, there is some consensus that Spoonnet
[12] is the most attractive option for such a hardfork. There is
currently no consensus on a hard fork date, but there is a rough
consensus that one would require at least 6 months to coordinate
effectively, which would place it in the year 2018 at earliest.
The above are only a small sample of current scaling technologies. And
even an exhaustive list of scaling technologies, would itself only be a
small sample of total Bitcoin innovation (which is proceeding at
breakneck speed).
Signed,
<Names Here>
[1]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html
[2] https://bitcoincore.org/en/2017/03/13/performance-optimizations-1/
[3] http://bluematt.bitcoin.ninja/2016/07/07/relay-networks/
[4] https://bitcoincore.org/en/2016/01/26/segwit-benefits/
[5]
http://lightning.community/release/software/lnd/lightning/2017/05/03/litening/
[6] https://github.com/ACINQ/eclair
[7] https://people.xiph.org/~greg/compacted_txn.txt
[8]
https://github.com/ElementsProject/secp256k1-zkp/blob/d78f12b04ec3d9f5744cd4c51f20951106b9c41a/src/secp256k1.c#L592-L594
[9] https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/
[10] http://www.drivechain.info/
[11] https://bitcoinhardforkresearch.github.io/
[12]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013542.html
==== End of Roadmap Draft ====
In short, please let me know:
1. If you agree that it would be helpful if the roadmap were updated.
2. To what extent, if any, you like this draft.
3. Edits you would make (specifically, I wonder about Drivechain
thoughts and Hard Fork thoughts, particularly how to phrase the Hard
Fork date).
Google Doc (if you're into that kind of thing):
https://docs.google.com/document/d/1gxcUnmYl7yM0oKR9NY9zCPbBbPNocmCq-jjBOQSVH-A/edit?usp=sharing
Cheers,
Paul
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170710/60d2fe7d/attachment.sig>

2023-06-07 18:03:41 UTC

- reply

📅 Original date posted:2017-06-28
📝 Original message:Hi Luke,
On 6/28/2017 1:20 AM, Luke Dashjr via bitcoin-dev wrote:
> On Wednesday 28 June 2017 12:37:13 AM Chris Stewart via bitcoin-dev wrote:
>> BRIBEVERIFY redefines the existing NOP4 opcode. When executed, if the given
>> critical hash is included at the given vout index in the coinbase
>> transaction
>> the script evaluates to true. Otherwise, the script will fail.
>>
>> This allows sidechains to be merged mined against
>> bitcoin without burdening bitcoin miners with extra resource requirements.
>
> I don't see how. It seems like the logical outcome from this is "whoever pays
> the most gets the next sidechain block"... That's not particularly useful for
> merge mining.
This is one of the assumptions which BMM exploits, see #4 of:
http://www.truthcoin.info/blog/blind-merged-mining/#focus
The idea is that this is a safe assumption, because it is already the
case today. If we assume that miners revenue-maximize, and further that
the "bidder" frames his payments in tx-fees, then a willing buyer can
control the next block by simply filling it with high tx-fee spam.
Anyone who is willing to pay the most can already 'get' the next
mainchain block (only, indirectly).
>
>> This enables sidechains in Bitcoin.
>
> There are different kinds of sidechains...
>
> Federated peg: this already works on Bitcoin.
> SPV/SNARK peg: this isn't enabled by your BIP.
> Drivechains: this isn't enabled by your BIP.
>
> How do you say this enables any kind of sidechain?
Yes, it is unclear, but Chris' email is specific to blind merged mining
(BMM), which is kind of a "sidechains +". So this does not directly
enable any sidechains. Instead, it enables the "+" part.
--Paul

2023-06-07 17:52:04 UTC

- reply

📅 Original date posted:2016-07-30
📝 Original message:Dear list,
As we know, it would be desirable for Alice, running an SPV client, to tip (say $5) anyone who can prove to her that a given block has invalid content.
If no one takes these tips, then this is weak evidence that the entire block is valid. Alice gets validation, full nodes can get paid...this idea goes back to Satoshi's whitepaper.
In my view, "alerts" are relatively straightforward: a new OP CODE (details below) st. the txn only succeeds if it references invalid block content on a "pretender block".
However, my background reading seems to reveal that "fraud proofs" (as they are now called) require some kind of tremendous engineering overhaul. Can anyone point me to these large problem(s)?
Regards,
Paul Sztorc
------------------------------------
Fraud Proof, Simple (?)
1. "OP FraudProof", which:
1. Contains arguments [a] block number (from Alice), [b] block header, and [c] merkle path from header to an invalid transaction*.
2. Checks to see if the provided header _is_ in the position which Alice requested.
2. Checks to see if the header _is_ valid (ie, has sufficient work).
3. Checks to see if the merkle path _does_ lead from the header to "something invalid"*.
2. This OP Code can then be used in a transaction of the form:
Inputs:
1 from Alice
0.2 from X**
Output:
1.2 to Alice, timelocked
(or)
1.2 to X, OP FraudProof .
3. Alice could sign this txn and circulate it, waiting for "X" to add the second signature.
"Eric", for example, might sign. As soon as Alice get's Eric's signature, she [1] assumes the block *is* invalid, and [2] stops offering to buy FraudProofs on it.
If Eric does not deliver the fraud proof, Alice gets her money back + 0.2 BTC from Eric (for wasting her time). Alice can't lose -- she either buys a fraud proof for 1, or she gets a free 0.2.
Eric can't lose either. Either he doesn't sign (and nothing happens), or he places himself in a position to trade a FraudProof for 1 BTC.
- FraudProof can use "OP Equal" to request fraud for a certain block.
- This can all happen through the lightning network.
* "invalid transaction" is defined either [1] as a script which fails, or [2] a double-spend (headers/paths to 2 txns spending the same input). This definition does not catch bad coinbase transactions, but this doesn't concern me. Those outputs aren't spendable for 100 blocks, and anyway, SPV clients could be programmed to never accept them (it would be annoying, but possible).
** For simplicity, I assume that "FraudProof sellers" will pre-identify themselves (and their unspent outputs, etc, by making them "watching only" or whatever).
---
Now, I wouldn't describe this as a "weekend project", but I wouldn't describe it as an "engineering overhaul" either. Just a new OP Code, and code to create / scan for these "Alert Transactions". So, if the idea is 5+ years old, what's the hold up?
I've also heard that segwit will help, but don't understand why.

2023-06-07 17:49:36 UTC

- reply

📅 Original date posted:2016-03-02
📝 Original message:On 3/2/2016 12:53 PM, Gregory Maxwell via bitcoin-dev wrote:
> What you are proposing makes sense only if it was believed that a very
> large difficulty drop would be very likely.
>
> This appears to be almost certainly untrue-- consider-- look how long
> ago since hashrate was 50% of what it is now, or 25% of what it is
> now-- this is strong evidence that supermajority of the hashrate is
> equipment with state of the art power efficiency.
I don't understand the relevance of this.
In my view, we would prefer miners to invest in hardware just a mere
2016 blocks away from the halving. Instead, they've made them too soon.
Assuming that miners are already located in low-power-cost areas, the
difficulty will be quickly rising to compensate for "state of the art
power efficiency".
So it will have canceled out by July.
If anything, the more efficient miners become today, the bigger our
potential problem in July, because chip-manufacturers may have used up
all of the easy efficiency-increasing moves, such that investments do
not take place in June.
Paul

2023-06-07 17:49:36 UTC

- reply

📅 Original date posted:2016-03-09
📝 Original message:My recent conversations with miners revealed:
* Many have made "extra-large" hardware investments recently.
* Some wonder if we have just reached (or are quickly reaching) a
plateau of hardware-efficiency. This would mean that
hardware-investments might not be made in the critical period
immediately preceding the halving.
However, some good news:
* For Chinese miners, power is often purchased in fixed quantities, for
long-durations (of around 12 months, and these contracts -fortunately-
do overlap the July halving). Because power is difficult to store, this
implies that miners will *need* to mine, at all times, even at a loss.
So miners may continue to mine after the halving, no matter what.
On the other hand, miners can default on these contracts by simply
declaring bankruptcy, at which point their equipment would be entirely
unusable, by anyone, for a very long time.
So the problem is less likely, but more potentially-catastrophic.
Paul
On 3/2/2016 8:06 PM, Paul Sztorc wrote:
>
> On 3/2/2016 12:53 PM, Gregory Maxwell via bitcoin-dev wrote:
>> What you are proposing makes sense only if it was believed that a very
>> large difficulty drop would be very likely.
>>
>> This appears to be almost certainly untrue-- consider-- look how long
>> ago since hashrate was 50% of what it is now, or 25% of what it is
>> now-- this is strong evidence that supermajority of the hashrate is
>> equipment with state of the art power efficiency.
> I don't understand the relevance of this.
>
> In my view, we would prefer miners to invest in hardware just a mere
> 2016 blocks away from the halving. Instead, they've made them too soon.
> Assuming that miners are already located in low-power-cost areas, the
> difficulty will be quickly rising to compensate for "state of the art
> power efficiency".
>
> So it will have canceled out by July.
>
> If anything, the more efficient miners become today, the bigger our
> potential problem in July, because chip-manufacturers may have used up
> all of the easy efficiency-increasing moves, such that investments do
> not take place in June.
>
> Paul

2023-06-07 17:49:34 UTC

- reply

📅 Original date posted:2016-03-09
📝 Original message:On 3/9/2016 1:30 PM, Dave Hudson via bitcoin-dev wrote:
> The hash rate has jumped up by almost 70% in the last 6 to 7 months and that implies some pretty serious investments by miners who are quite aware of the halving.
There are a few ways in which that information would be irrelevant:
[1.] It is possible that miners expect to breakeven before the halving.
[2.] It is also possible that miners earnestly believe that there will
be no problem -- however:
... [2a.] This belief may be mistaken.
... [2b.] Miners may be counting on Core Devs to fix any problems that
come up with anything, this one included.
Also, [3.] many miners believe that the price will increase around the
time of the halving, either for market-microstructure reasons or
marketing reasons. I, personally, think that the price is as likely to
go down as up.
On 3/9/2016 1:30 PM, Dave Hudson via bitcoin-dev wrote:
> These same miners were mining with a coin price around $250 last year so in terms of profitability I'm pretty sure that one around $400 won't be a huge concern.
For some miners, currently it costs $X in electricity per coin mined,
and $400 / 2 is less than X. I do not know how representative this
information is.
Paul

2023-06-07 17:49:30 UTC

- reply

📅 Original date posted:2016-03-02
📝 Original message:It is **essential** that emergency code be prepared. This code must be
able to lower the difficulty by a large factor.
---
This halving-difficulty-drop problem can, with some bad luck, get quite
disastrous, very quickly.
( I did a micro-study of this problem here, for those who are unaware:
http://www.truthcoin.info/blog/mining-heart-attack )
For example, it is theoretically possible that 100% of miners (not 50%
or 10%) will shut off their hardware. This is because it is revenue
which ~halves, not profit. If miners are all equal, difficulty causes
their profit margin to narrow over time (for example, if BTC revenues
are $100, and amortized fixed costs are $10, then difficulty adjustments
will cause total energy costs to rise to ~ $89, such that total
pre-halving profit is $1 for everyone...post-halving, profit is -$49 for
everyone).
So, if miners are homogenous the result is disastrous. Fortunately,
miners are probably still somewhat heterogenous. However, we don't know
how their power contracts (or their hardware turnover) are
scheduled...many miners might (?) have already planned, in private, to
close down (or substantially reduce) operations after the halving.
As the coinbase rewards are currently orders of magnitude larger than
tx-fees, fees are unlikely to be able to compensate for this. Users may
decide to simply hold-off on transacting until fees decrease.
Worse, if the price crashes (possibly as a result of uncertainty
surrounding this episode), it will begin to affect miner-revenue.
As a result, miners may decide to temporarily halt mining until the
difficulty falls naturally.
But such a temporary halt is also (potentially) disastrous. Recall the
simple fact that difficulty adjustments are measured in blocks, not time
(it appears that we have exactly 1015 blocks between the halving block
and the next difficulty adjustment block). If excessive difficulty
chokes the system, next difficulty adjustment may *never* arrive naturally.
In this worst-case (but somewhat plausible) scenario, we will be
*forced* to lower the difficulty via hard fork, and we will be forced to
do so very very QUICKLY, as word will be spreading that the Bitcoin
system has broken!
If a specific hard fork is not coded and tested for this, in advance,
the delay might be accompanied by endless [contentious] conversations
about what else should be included in this hard fork.
Worse, since all users will need to upgrade, there will be uncertainty
over contentious versions, malicious agents may try to tamper with
versions (to steal Bitcoins), etc. We should consider pushing a version
out for users to upgrade, in advance of the halving, as soon as possible.
What a disaster! I certainly hope it does not happen, but if it does we
should have already agreed on what to do.
One choice is "which number do we set the difficulty to?". Half may be
too much, or too little. However, allow me to suggest that, if this
disastrous scenario occurs, we shouldn't take any chances, and reduce
difficulty by a huge proportion...80% or so. The difficulty will then
quickly begin to increase again...we can warn users of the increased
orphan risk, and that they should wait for many confirmations (which
should be happening faster).
So, "Allow the alert key to reduce the difficulty by 80%, exactly once
on one of the 1015 blocks between halving and difficulty adjustment."
And we should consider smoothing the rewards (as described in my post,
can be done via soft fork) to prevent this from happening again. In
microeconomics literature, 'kinks' in incentive-systems are
almost-universally agreed to be very undesirable.
Paul
On 3/2/2016 10:42 AM, Luke Dashjr via bitcoin-dev wrote:
> On Wednesday, March 02, 2016 2:56:14 PM Luke Dashjr via bitcoin-dev wrote:
>> so it may even be possible to have such a proposal ready in time to be
>> deployed alongside SegWit to take effect in time for the upcoming subsidy
>> halving.
>
> Lapse of thinking/clarity here. This probably isn't a practical timeframe for
> deployment, unless/until there's an emergency situation. So if the code were
> bundled with SegWit, it would need some way to avoid its early activation
> outside of such an emergency (which could possibly be detected in code, in
> this case).
>
> Luke
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

2023-06-07 17:42:38 UTC

- reply

📅 Original date posted:2015-10-05
📝 Original message:On 10/5/2015 12:56 PM, Mike Hearn via bitcoin-dev wrote:
>
> As everyone in the Bitcoin community has been clearly told that
> controversial changes to the consensus rules must not happen, it's
> clear that CLTV cannot happen in its current form.

2023-06-07 17:37:49 UTC

- reply

📅 Original date posted:2015-08-21
📝 Original message:You said:
> There is a perception that Bitcoin cannot easily respond to raising
the blocksize limit if popularity was to suddenly increase
From this, my understanding is that you are operating on the principle
that "the optimum blocksize" is related to "popularity/use of Bitcoin".
It seems that others on this list instead feel that "the optimum
blocksize" is a function of "technical limitations (namely bandwidth)".
Do you acknowledge this as an irreconcilable difference in approach?
Also, I'm not sure, but your principle would seem to imply that
"outsourcing the decision to Miners" is superfluous. You are concerned
(according to you) with "not reacting to 'popularity' quickly enough",
and you are only against "predetermined increases" and "hashpower
influences" (according to you), so why not measure "popularity" directly
(by using "transaction volume" or "fees paid") and use that number to
set the blocksize?
--
However, thank you very much for actually stating a principle. Unless
one knows what a person's principle is, one *can't even check if* what
they are saying makes any sense (according to *them*), so my completely
sincere congratulations on an intelligible email.
On 8/21/2015 6:22 PM, Btc Drak via bitcoin-dev wrote:
> I wanted to offer a potential way to adjust the block size limit in a
> democratic way without making it easy to game. This is meant only as a
> starting point for a general idea. Thresholds and exact figures and
> the details of the algorithm are up for debate, and possibly some
> formula based determination.
>
> The living document is currently a gist available at
> https://gist.github.com/btcdrak/1c3a323100a912b605b5
>
>
> <pre>
> BIP: XX
> Title: Consensus based block size retargeting algorithm
> Author: BtcDrak <btcdrak at gmail.com>
> Status: Draft
> Type: Standards Track
> Created: 2015-08-21
> </pre>
>
> ==Abstract==
>
> A method of altering the maximum allowed block size of the Bitcoin
> protocol using a consensus based approach.
>
> ==Motivation==
>
> There is a perception that Bitcoin cannot easily respond to raising
> the blocksize limit if popularity was to suddenly increase due to a
> mass adoption curve, because co-ordinating a hard fork takes
> considerable time, and being unable to respond in a timely manner
> would irreparably harm the credibility of bitcoin.
>
> Additionally, predetermined block size increases are problematic
> because they attempt to predict the future, and if too large could
> have unintended consequences like damaging the possibility for a fee
> market to develop as block subsidy decreases substantially over the
> next 9 years; introducing or exacerbating mining attack vectors; or
> somehow affect the network in unknown or unpredicted ways. Since fixed
> changes are hard to deploy, the damage could be extensive.
>
> Dynamic block size adjustments also suffer from the potential to be
> gamed by the larger hash power.
>
>
> ==Rationale==
>
> By introducing a cost to increase the block size ensures the mining
> community will collude to increase it only when there is a clear
> necessity, and reduce it when it is unnecessary. Rogue miners cannot
> force their wishes so easily because not only will they have to pay
> extra a difficulty target, then can be downvoted at no cost by the
> objecting hash power.
>
>
> ==Specification==
>
> The initial "base block size limit" shall be 1MB.
>
> Miners can vote for a block size increase by signalling the proposed
> percentage increase of the "base block size limit" in the coinbase
> field. For the vote to be considered valid the block they mine must
> meets a difficulty target which is proportionally larger than the
> standard difficulty target based on the percentage increase they voted
> for. If a miner does not vote, or the vote is invalid, it shall be
> counted as a vote for no change.
>
> Miners may vote the size down by signalling in the coinbase field
> without paying a difficulty penalty.
>
> Every 2016 blocks, the maximum allowed block size will be recalculated
> by the average of all votes in the last 2016 blocks, i.e. sum each
> vote from each block and divide by 2016 then multiply by the base
> block size limit. This will redefine the base block size limit for the
> next 2016 blocks.
>
> Blocks that are larger than the calculated base block size limit are
> invalid and MUST be rejected.
>
> The maximum change up or down each retargeting period shall be limited
> to 10% of the base block size limit.
>
> The maximum block size may not increase above 8MB.
>
> Votes shall be cast by adding the following human readable multiplier
> to the coinbase string “/BXn.nnn/” where valid votes would exist
> between the ranges “/BX0.900/” (10% decrease) and “/BX1.100/” (10%
> increase). “/BX1.000/” would be a vote for no change. Invalid votes
> will be counted as a vote for no change: “/BX1.000/”.
>
>
> ==Acknowledgements==
>
> This proposal is based on ideas and concepts derived from the writings
> of Meni Rosenfeld and Gregory Maxwell.
>
>
> ==Copyright==
>
> This work is placed in the public domain.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 15:49:14 UTC

- reply