Paul Sztorc [ARCHIVE]

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

Public Key

npub10tqt6wdc2neye0cxwyphtre6n5uccgur94khtqjdry9wxhrvywlq6w9uu9

Profile Code

nprofile1qqs84s9a8xu9fujvhur8zqm43uaf6wvvywpj6mt4sfx3jzhrt3kz80sncdg22

Author Public Key

npub10tqt6wdc2neye0cxwyphtre6n5uccgur94khtqjdry9wxhrvywlq6w9uu9

Show more details

Last Notes

2023-06-09 13:05:26

- reply

📅 Original date posted:2022-02-26
📝 Original message:
Not bad, but not particularly good either.
Definitely correct:
1 (plus extra credit, it was originally 1008+2016),
3a "whales"
3b (atomic swaps is the "official" answer, but otc trading is also
acceptable, or just "trade" in general)
6
9 part one
Close, but not quite right:
2 (part one "~4" is correct, but you didn't answer part two)
3a "attacker- miners" is not the way I see it at all
3c true, but I was talking about withdrawal security, not hashrate,
[this is related to the 3a "attacker miners" mis-answer]
4 ? you seem to have not very seriously answered this. The
parameters are spelled out in the original Nov 2015 post
Some kind of miscommunication may have happened:
8 -- I was more thinking, what happens if the UASF fails (in
thwarting miners) vs succeeds. (I take it for granted that non-DC users
will prefer to do nothing, and prefer to be unaffected.)
Seems wrong to me:
0 seems like a pretty big misunderstanding happened here, or else
you mistakenly typo'd the wrong word
5 (you started with m=1 examples, which is not what was requested;
and finished with something not a sidechain attribute)
7 [related to the miss on #5] ; it is not a re-ask of question #0
9 part two is wrong
10 you did not answer
Paul
On 2/26/2022 2:39 AM, ZmnSCPxj wrote:
> Good morning Paul,
>
>
>> I don't think I can stop people from being ignorant about Drivechain. But I can at least allow the Drivechain-knowledgable to identify each other.
>>
>> So here below, I present a little "quiz". If you can answer all of these questions, then you basically understand Drivechain:
>>
>> 0. We could change DC to make miner-theft impossible, by making it a layer1 consensus rule that miners never steal. Why is this cure worse than the disease?
> Now miners are forced to look at all sideblocks, not optionally do so if it is profitable for them.
>
>> 1. If 100% hashrate wanted to steal coins from a DC sidechain *as quickly as possible*, how long would this take (in blocks)?
> 13,150 (I think this is how you changed it after feedback from this list, I think I remember it was ~3000 before or thereabouts.)
>
>> 2. Per sidechain per year (ie, per 52560 blocks), how many DC withdrawals can take place (maximum)? How many can be attempted?
>> (Ie, how does the 'train track metaphor' work, from ~1h5m in the "Overview and Misconceptions" video)?
> I hate watching videos, I can read faster than anyone can talk (except maybe Laolu, he speaks faster than I can process, never mind read).
>
> ~4 times (assuming 52560 block per year, which may vary due to new miners, hashrate drops, etc)
>
>> 3. Only two types of people should ever be using the DC withdrawal system at all.
>> 3a. Which two?
> a. Miners destroying the sidechain because the sidechain is no longer viable.
> b. Aggregators of sidechain-to-minechain transfers and large whales.
>
>> 3b. How is everyone else, expected to move their coins from chain to chain?
> Cross-system atomic swaps.
> (I use "System" here since the same mechanism works for Lightning channels, and channels are not blockchains.)
>
>> 3c. (Obviously, this improves UX.) But why does it also improve security?
> Drivechain-based pegged transfers are aggregates of many smaller transfers and thus every transfer out from the sidechain contributes its "fee" to the security of the peg.
>
>> --
>> 4. What do the parameters b and m stand for (in the DC security model)?
> m is how much people want to kill a sidechain, 0 = everybody would be sad if it died and would rather burn all their BTC forever than continue living, 1 = do not care, > 1 people want to actively kill the sidechain.
>
> b is how much profit a mainchain miner expects from supporting a sidechain (do not remember the unit though).
> Something like u = a + b where a is the mainchain, b is the sidechain, u is the total profit.
> Or fees? Something like that.
>
>> 5. How can m possibly be above 1? Give an example of a sidechain-attribute which may cause this situation to arise.
> The sidechain is a total scam.
> A bug may be found in the sidechain that completely negates any security it might have, thus removing any desire to protect the sidechain and potentially make users want to destroy it completely rather than let it continue.
> People end up hating sidechains completely.
>
>> 6. For which range of m, is DC designed to deter sc-theft?
> m <= 1
>
>> 7. If DC could be changed to magically deter theft across all ranges of m, why would that be bad for sidechain users in general?
> Because the sidechain would already be part of mainchain consensus.
>
>> --
>> 8. If imminent victims of a DC-based theft, used a mainchain UASF to prohibit the future theft-withdrawal, then how would this affect non-DC users?
> If the non-DC users do not care, then they are unaffected.
> If the non-DC users want to actively kill the sidechain, they will counterattack with an opposite UASF and we have a chainsplit and sadness and mutual destruction and death and a new subreddit.
>
>> 9. In what ways might the BTC network one day become uncompetitive? And how is this different from caring about a sidechain's m and b?
> If it does not enable scaling technology fast enough to actually be able to enable hyperbitcoinization.
>
> Sidechains are not a scaling solution, so caring about m and b is different because your focus is not on scaling.
>
>> --
>> 10. If DC were successful, Altcoin-investors would be harmed. Two Maximalist-groups would also be slightly harmed -- who are these?
> Dunno!
>
>
> Regards,
> ZmnSCPxj

2023-06-09 13:05:25

- reply

📅 Original date posted:2022-02-24
📝 Original message:
On 2/24/2022 7:49 AM, ZmnSCPxj via bitcoin-dev wrote:
...
>> ... it is easy for 51% hashrate to double-spend in the LN ...
> ... the above statement is unequivocally ***true***.
Both LN and Drivechain are vulnerable to miner-theft; and both use their design to deter theft.
> However, I believe that the following important points must be raised:
>
> * A 51% miner can only attack LN channels it is a participant in.
> * A 51% miner can simultaneously attack all Drivechain-based sidechains and steal all of their funds.
In LN, the main obstacle is that your miner-coalition must first join the channel.
In DC, the main obstacle is that your miner-coalition must construct a txn obeying the Bip300 rules. Knowing that SPV proofs allow miner-theft, the Bip300 rules are designed specifically to try to thwart miner-theft.
***
I don't think I can stop people from being ignorant about Drivechain. But I can at least allow the Drivechain-knowledgable to identify each other.
So here below, I present a little "quiz". If you can answer all of these questions, then you basically understand Drivechain:
0. We could change DC to make miner-theft impossible, by making it a layer1 consensus rule that miners never steal. Why is this cure worse than the disease?
1. If 100% hashrate wanted to steal coins from a DC sidechain *as quickly as possible*, how long would this take (in blocks)?
2. Per sidechain per year (ie, per 52560 blocks), how many DC withdrawals can take place (maximum)? How many can be attempted?
(Ie, how does the 'train track metaphor' work, from ~1h5m in the "Overview and Misconceptions" video)?
3. Only two types of people should ever be using the DC withdrawal system at all.
3a. Which two?
3b. How is everyone else, expected to move their coins from chain to chain?
3c. (Obviously, this improves UX.) But why does it also improve security?
--
4. What do the parameters b and m stand for (in the DC security model)?
5. How can m possibly be above 1? Give an example of a sidechain-attribute which may cause this situation to arise.
6. For which range of m, is DC designed to deter sc-theft?
7. If DC could be changed to magically deter theft across all ranges of m, why would that be bad for sidechain users in general?
--
8. If imminent victims of a DC-based theft, used a mainchain UASF to prohibit the future theft-withdrawal, then how would this affect non-DC users?
9. In what ways might the BTC network one day become uncompetitive? And how is this different from caring about a sidechain's m and b?
--
10. If DC were successful, Altcoin-investors would be harmed. Two Maximalist-groups would also be slightly harmed -- who are these?
***
> Thus, LN usage is safer than Drivechain usage.
Neither LN nor DC, are intended for use by everyone in every circumstance.
DC can simulate a zcash sidechain, but it can not allow for instant off-chain payments. So DC-vs-LN would never be an apples-to-apples comparison, on any criterion.
The end user should be free to decide, what risks they take with their money. Today, users can sell their BTC for Solana (or BSV or whatever). So, to me it seems clear that they should be "allowed" to spend their BTC to a Bip300 script, just as they are allowed to open a LN channel.
-Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220224/29005c37/attachment.html>

2023-06-07 23:11:16

- 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:10:24

- reply

📅 Original date posted:2022-06-11
📝 Original message:FYI there is a version 3 of bip47 (which Ranvier published somewhere else
[0]). It already gets them down to a marginal 64 bytes, with a small
privacy drawback.
The transaction from A can be double used as both a notification to Bob and
a payment to Bob. The notification output is multisig OP [Key1] [Key2]
[Key3] , one being change for A (a sunk cost), K2 being the signal to B,
and K3 being a blinded code only B can read.
>From there you can simply insert another output to Bob (to actually pay
him), insert decoy change outputs, or swap Key1 for Bobs key, making it
impossible (at least) to tell *how much* someone is paying to Bob and how
much is change for Alice.
But everyone does know that a new bidirectional relationship to Bob (from
someone) is being established, of course.
[0]
https://github.com/OpenBitcoinPrivacyProject/rfc/blob/master/obpp-05.mediawiki
Paul
On Sat, Jun 11, 2022, 6:03 AM Ruben Somsen via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> This discussion took place at Pizza Day Prague 2022[0] after a brief
> discussion on Silent Payments[1]. The main points have been summarized
> below.
>
> The discussion was mainly between Alekos Filini, Martin Habovštiak, and
> myself, as well as Daniela Brozzoni, Eric Sirion, Pavol Rusnak, Salvatore
> Ingala, and others.
>
> Also available as a gist:
> https://gist.github.com/RubenSomsen/21c477c90c942acf45f8e8f5c1ad4fae
>
> And my personal opinion can be found in the comments:
>
> https://gist.github.com/RubenSomsen/21c477c90c942acf45f8e8f5c1ad4fae?permalink_comment_id=4197284#gistcomment-4197284
>
>
> Improving BIP47
>
> BIP47 requires a notification transaction prior to making payments. This
> transaction takes up on-chain space and can easily leak privacy if not
> handled with extreme caution. In practice this is quite hard.
>
> The discussion revolved around whether we can a.) minimize the on-chain
> space required and b.) outsource the notification transaction so the link
> between the sender and recipient is no longer apparent on-chain.
>
>
> BIP47 space requirements
>
> As currently implemented, BIP47 (V1/V2)[2] requires an input key for
> blinding, the blinded sender payment code in an op_return, and the
> recipient key in an output.
>
> The first question that came up was whether it is necessary for the
> recipient to learn the payment code of the sender. The benefit is that this
> enables the recipient to send a notification transaction and subsequent
> payment to the sender, but in practice this never happens. It therefore
> seems acceptable to forego this requirement, as this potentially saves
> space. The minimum notification payload that seems required is a fresh
> sender key and a static recipient key.
>
> The sender key should ideally be deterministically derived from the sender
> xpub based on the recipient key. If the user checks all the keys that were
> registered with the recipient prior to notification, it can statelessly
> find out whether the sender key was already previously registered. This
> step can be skipped, which is easier for light clients, but means the
> notification transaction will have to be resent if the user ever forgets
> they already sent a notification (such as when restoring from backup).
>
>
> Outsourcing the notification
>
> The next part of the discussion revolved around the idea of putting
> multiple notifications in a single transaction that can be outsourced to a
> third party in order to break the sender/recipient link. This third party
> could be paid over the Lightning Network for their services.
>
> One idea was to use the taproot annex to insert the notification payload
> as (discounted) witness data. One downside with this approach is that it
> requires custom software for the recipient to notice the notification,
> since it's not tied to an easily noticeable output. The middle ground
> solution would be to put the sender keys there but still create an output
> for each recipient key.
>
>
> Allowing collisions
>
> One interesting point that came up was that you could represent the
> recipient key using e.g. only 4 bytes (provided you put it in the annex).
> This leaves a window of 1 in ~4.3 billion for a collision, but the extra
> work that needs to be performed when it does happen is negligible
> (essentially expecting a payment while there is none). This would reduce
> the payload from 64 bytes to 36 bytes of witness data.
>
> While this did not come up in the discussion, it should be noted that
> using the annex makes the transaction non-standard[3]. It could either be
> standardized as the first use case for the annex, or perhaps an alternative
> method[4] should be considered.
>
>
> [0] Pizza Day Prague 2022: https://www.pizzaday.cz
>
> [1] Silent Payments:
> https://gist.github.com/RubenSomsen/c43b79517e7cb701ebf77eec6dbb46b8
>
> [2] BIP47: https://github.com/bitcoin/bips/blob/master/bip-0047.mediawiki
>
> [3] Annex non-standard:
> https://github.com/bitcoin/bitcoin/pull/17977/files#diff-ea6d307faa4ec9dfa5abcf6858bc19603079f2b8e110e1d62da4df98f4bdb9c0R250
>
> [4] Using p2wsh:
> https://gist.github.com/RubenSomsen/21c477c90c942acf45f8e8f5c1ad4fae?permalink_comment_id=4189419#gistcomment-4189419
>
> _______________________________________________
> 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/20220611/7a1001f1/attachment.html>

2023-06-07 23:05:03

- 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

- 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:04:57

- reply

📅 Original date posted:2022-02-26
📝 Original message:Not bad, but not particularly good either.
Definitely correct:
1 (plus extra credit, it was originally 1008+2016),
3a "whales"
3b (atomic swaps is the "official" answer, but otc trading is also
acceptable, or just "trade" in general)
6
9 part one
Close, but not quite right:
2 (part one "~4" is correct, but you didn't answer part two)
3a "attacker- miners" is not the way I see it at all
3c true, but I was talking about withdrawal security, not hashrate,
[this is related to the 3a "attacker miners" mis-answer]
4 ? you seem to have not very seriously answered this. The
parameters are spelled out in the original Nov 2015 post
Some kind of miscommunication may have happened:
8 -- I was more thinking, what happens if the UASF fails (in
thwarting miners) vs succeeds. (I take it for granted that non-DC users
will prefer to do nothing, and prefer to be unaffected.)
Seems wrong to me:
0 seems like a pretty big misunderstanding happened here, or else
you mistakenly typo'd the wrong word
5 (you started with m=1 examples, which is not what was requested;
and finished with something not a sidechain attribute)
7 [related to the miss on #5] ; it is not a re-ask of question #0
9 part two is wrong
10 you did not answer
Paul
On 2/26/2022 2:39 AM, ZmnSCPxj wrote:
> Good morning Paul,
>
>
>> I don't think I can stop people from being ignorant about Drivechain. But I can at least allow the Drivechain-knowledgable to identify each other.
>>
>> So here below, I present a little "quiz". If you can answer all of these questions, then you basically understand Drivechain:
>>
>> 0. We could change DC to make miner-theft impossible, by making it a layer1 consensus rule that miners never steal. Why is this cure worse than the disease?
> Now miners are forced to look at all sideblocks, not optionally do so if it is profitable for them.
>
>> 1. If 100% hashrate wanted to steal coins from a DC sidechain *as quickly as possible*, how long would this take (in blocks)?
> 13,150 (I think this is how you changed it after feedback from this list, I think I remember it was ~3000 before or thereabouts.)
>
>> 2. Per sidechain per year (ie, per 52560 blocks), how many DC withdrawals can take place (maximum)? How many can be attempted?
>> (Ie, how does the 'train track metaphor' work, from ~1h5m in the "Overview and Misconceptions" video)?
> I hate watching videos, I can read faster than anyone can talk (except maybe Laolu, he speaks faster than I can process, never mind read).
>
> ~4 times (assuming 52560 block per year, which may vary due to new miners, hashrate drops, etc)
>
>> 3. Only two types of people should ever be using the DC withdrawal system at all.
>> 3a. Which two?
> a. Miners destroying the sidechain because the sidechain is no longer viable.
> b. Aggregators of sidechain-to-minechain transfers and large whales.
>
>> 3b. How is everyone else, expected to move their coins from chain to chain?
> Cross-system atomic swaps.
> (I use "System" here since the same mechanism works for Lightning channels, and channels are not blockchains.)
>
>> 3c. (Obviously, this improves UX.) But why does it also improve security?
> Drivechain-based pegged transfers are aggregates of many smaller transfers and thus every transfer out from the sidechain contributes its "fee" to the security of the peg.
>
>> --
>> 4. What do the parameters b and m stand for (in the DC security model)?
> m is how much people want to kill a sidechain, 0 = everybody would be sad if it died and would rather burn all their BTC forever than continue living, 1 = do not care, > 1 people want to actively kill the sidechain.
>
> b is how much profit a mainchain miner expects from supporting a sidechain (do not remember the unit though).
> Something like u = a + b where a is the mainchain, b is the sidechain, u is the total profit.
> Or fees? Something like that.
>
>> 5. How can m possibly be above 1? Give an example of a sidechain-attribute which may cause this situation to arise.
> The sidechain is a total scam.
> A bug may be found in the sidechain that completely negates any security it might have, thus removing any desire to protect the sidechain and potentially make users want to destroy it completely rather than let it continue.
> People end up hating sidechains completely.
>
>> 6. For which range of m, is DC designed to deter sc-theft?
> m <= 1
>
>> 7. If DC could be changed to magically deter theft across all ranges of m, why would that be bad for sidechain users in general?
> Because the sidechain would already be part of mainchain consensus.
>
>> --
>> 8. If imminent victims of a DC-based theft, used a mainchain UASF to prohibit the future theft-withdrawal, then how would this affect non-DC users?
> If the non-DC users do not care, then they are unaffected.
> If the non-DC users want to actively kill the sidechain, they will counterattack with an opposite UASF and we have a chainsplit and sadness and mutual destruction and death and a new subreddit.
>
>> 9. In what ways might the BTC network one day become uncompetitive? And how is this different from caring about a sidechain's m and b?
> If it does not enable scaling technology fast enough to actually be able to enable hyperbitcoinization.
>
> Sidechains are not a scaling solution, so caring about m and b is different because your focus is not on scaling.
>
>> --
>> 10. If DC were successful, Altcoin-investors would be harmed. Two Maximalist-groups would also be slightly harmed -- who are these?
> Dunno!
>
>
> Regards,
> ZmnSCPxj

2023-06-07 23:04:56

- reply

📅 Original date posted:2022-02-24
📝 Original message:On 2/24/2022 7:49 AM, ZmnSCPxj via bitcoin-dev wrote:
...
>> ... it is easy for 51% hashrate to double-spend in the LN ...
> ... the above statement is unequivocally ***true***.
Both LN and Drivechain are vulnerable to miner-theft; and both use their design to deter theft.
> However, I believe that the following important points must be raised:
>
> * A 51% miner can only attack LN channels it is a participant in.
> * A 51% miner can simultaneously attack all Drivechain-based sidechains and steal all of their funds.
In LN, the main obstacle is that your miner-coalition must first join the channel.
In DC, the main obstacle is that your miner-coalition must construct a txn obeying the Bip300 rules. Knowing that SPV proofs allow miner-theft, the Bip300 rules are designed specifically to try to thwart miner-theft.
***
I don't think I can stop people from being ignorant about Drivechain. But I can at least allow the Drivechain-knowledgable to identify each other.
So here below, I present a little "quiz". If you can answer all of these questions, then you basically understand Drivechain:
0. We could change DC to make miner-theft impossible, by making it a layer1 consensus rule that miners never steal. Why is this cure worse than the disease?
1. If 100% hashrate wanted to steal coins from a DC sidechain *as quickly as possible*, how long would this take (in blocks)?
2. Per sidechain per year (ie, per 52560 blocks), how many DC withdrawals can take place (maximum)? How many can be attempted?
(Ie, how does the 'train track metaphor' work, from ~1h5m in the "Overview and Misconceptions" video)?
3. Only two types of people should ever be using the DC withdrawal system at all.
3a. Which two?
3b. How is everyone else, expected to move their coins from chain to chain?
3c. (Obviously, this improves UX.) But why does it also improve security?
--
4. What do the parameters b and m stand for (in the DC security model)?
5. How can m possibly be above 1? Give an example of a sidechain-attribute which may cause this situation to arise.
6. For which range of m, is DC designed to deter sc-theft?
7. If DC could be changed to magically deter theft across all ranges of m, why would that be bad for sidechain users in general?
--
8. If imminent victims of a DC-based theft, used a mainchain UASF to prohibit the future theft-withdrawal, then how would this affect non-DC users?
9. In what ways might the BTC network one day become uncompetitive? And how is this different from caring about a sidechain's m and b?
--
10. If DC were successful, Altcoin-investors would be harmed. Two Maximalist-groups would also be slightly harmed -- who are these?
***
> Thus, LN usage is safer than Drivechain usage.
Neither LN nor DC, are intended for use by everyone in every circumstance.
DC can simulate a zcash sidechain, but it can not allow for instant off-chain payments. So DC-vs-LN would never be an apples-to-apples comparison, on any criterion.
The end user should be free to decide, what risks they take with their money. Today, users can sell their BTC for Solana (or BSV or whatever). So, to me it seems clear that they should be "allowed" to spend their BTC to a Bip300 script, just as they are allowed to open a LN channel.
-Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220224/29005c37/attachment-0001.html>

2023-06-07 23:03:43

- reply

📅 Original date posted:2022-02-28
📝 Original message:On 2/28/2022 1:49 AM, ZmnSCPxj wrote:
> ...
>>>> ...
>>>>
>>>> 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.
>>> Yes, using channel factories.
>> I think you may be wrong about this.
>> ...
> I am not wrong about this.
Well, let's take a closer look then.
The topic was: "a way, to LN-onboard [a new pubkey] WITHOUT needing new layer1 bytes".
By which I meant, that I could generate a new pubkey right now, and add it to the LN, without any onchain action.
I can shorten and restate the two requirements (and reorder them) as:
#2: Can later add a new public key to the membership set.
#1: Without an onchain action.
And yet you yourself say, very clearly:
> ... That is why I said changing the membership set requires onchain action.
Which would seem to directly contradict what you say about channel factories.
Unless you can show me how to add my new pubkey_4, to a 3-of-3 channel factory opened last year. Without using an onchain action.
You seem to want to instead change the subject. (To something like: 'we can do better the rate (32 bytes per 5 onboards), from your footnote'.)
Which is fine. But it is not what I bought up.
***
In general, you seem to have a future in mind, where new users onboard via factory.
For example, 50,000 new users want to onboard in the next block. These strangers, spontaneously organize into 1000 factories of 55 people each, (50 newbies with zero coins + 5 wealthier BTCs who have lots of coins). They then broadcast into the block and join Bitcoin.
And this one factory provides them with many channels, so it can meet most/all of their needs.
I am not here to critique factories. I was simply observing that your logic "sidechains don't scale, because you have to share your messages" is not quite airtight, because in the case of onboarding the situation is reversed and so supports the exact opposite conclusion.
I believe I have made my point by now. It should be easy for people to see what each of us has in mind, and the strengths and weaknesses.
I am curious about something, though. Maybe you can help me.
Presumably there are risks to large factories. Perhaps an attacker could join each new factory with just $1 of BTC, spend this $1, and then refuse to cooperate with the factory any further. Thus they can disable the factory at a cost of $1 rented dollar.
If 1000 factories are opened per block, this would be 52.5 M factories per year, $52.5 million USD per year to disable all the factories out of spite. (All of which they would eventually get back.) I can think of a few people who might try it.
> I mean, like, LN ... has a lot more onboarding activity than half-hearted sidechains like Liquid or Rootstock.
I don't see the relevance of this. We are talking about the future (theoretical), not the past (empirical).
For example, someone could say "Ethereum has a lot more onboarding activity than LN ..." but this would also make no difference to anything.
> ...The onboarding rate only needs to be as fast as the rate at which people want to join Bitcoin.
> ...
>
> As I pointed out in the other thread:
>
> * LN:
> * Funds can be stolen IF:
> * There is a 51% miner, AND
> * The 51% miner is a member of a channel/channel factory you are in.
> * Drivechains:
> * Funds can be stolen IF:
> * There is a 51% miner.
> ...
> So there is a real degradation of security in Drivechains, and if you compute the numbers, I am reasonably sure that 33% of the world is unlikely to want to use Bitcoin within one month.
> I mean we already had a pandemic and everyone going online and so on, and yet Bitcoin blockchain feerates are *still* small, I had to fix a bug in CLBOSS that came up only due to hitting the minimum feerate, so no --- people are not joining Bitcoin at a rate faster than Bitcoin + LN can handle it, even with a pretty good reason to move payments online.
>
> Worse, once 100% of the world is onboarded, the extra onboarding capacity is useless since the onboarding rate can only match the birth rate (including birth of legal persons such as corporations), which we expect is much lower than 33% increase per ***month***.
>
> You are buying too much capacity at a real degradation in security, and I am not convinced the extra capacity is worth the loss of security.
>
> Separating the onboarding rate from the payment rate is a *good thing*, because we can then design their structures differently.
> Make onboarding slow but secure (so that their money is very secure), but make payment rate faster and less secure (because in-flight payments are likely to be much smaller than the total owned funds).
Obviously I don't agree with any of these sentences (most are irrelevant, some false). But I would only be repeating myself.
Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220228/b74a2e78/attachment-0001.html>

2023-06-07 23:03:40

- reply

📅 Original date posted:2022-02-27
📝 Original message:On 2/26/2022 9:00 PM, ZmnSCPxj wrote:
> ...
>> 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.
> Yes, using channel factories.
I think you may be wrong about this.
Channel factories do not meet requirement #2, as they cannot grow to onboard new users (ie, new pubkeys).
The factory-open requires that people pay to (for example), a 5-of-5 multisig. So all 5 fixed pubkeys must be known, before the factory-open is confirmed, not after.
> We assume that onboarding new members is much rarer than existing members actually paying each other
Imagine that Bitcoin could only onboard 5 new users per millennium, but once onboarded they had payment nirvana (could transact hundreds of trillions of times per second, privately, smart contracts, whatever).
Sadly, the payment nirvana would not matter. The low onboarding rate would kill the project.
The difference between the two rates [onboarding and payment], is not relevant. EACH rate must meet the design goal.
It is akin to saying: " Our car shifts from park to drive in one-millionth of a second, but it can only shift into reverse once per year; but that is OK because 'we assume that going in reverse is much rarer than driving forward' ".
> Continuous operation of the sidechain then implies a constant stream of 32-byte commitments, whereas continuous operation of a channel factory, in the absence of membership set changes, has 0 bytes per block being published.
That's true, but I think you have neglected to actually take out your calculator and run the numbers.
Hypothetically, 10 largeblock-sidechains would be 320 bytes per block (00.032%, essentially nothing).
Those 10, could onboard 33% of the planet in a single month [footnote], even if each sc-onboard required an average of 800 sc-bytes.
Certainly not a perfect idea, as the SC onboarding rate is the same as the payment rate. But once they are onboarded, those users can immediately join the LN *from* their sidechain. (All of the SC LNs would be interoperable.)
Such a strategy would take enormous pressure *off* of layer1 (relative to the "LN only" strategy). The layer1 blocksize could even **shrink** from 4 MB (wu) to 400 kb, or lower. That would cancel out the 320 bytes of overhead, many hundreds of times over.
Paul
[footnote] Envelope math, 10 sidechains, each 50 MB forever-fixed blocksize (which is a mere 12.5x our current 4M wu limit): 10 * 6*24*30 * ((50*1000*1000)/800) / 8.2 billion = .32926
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220227/3ca47607/attachment-0001.html>

2023-06-07 23:03:39

- reply

📅 Original date posted:2022-02-27
📝 Original message:On 2/27/2022 11:59 AM, Billy Tetrud via bitcoin-dev wrote:
> @Paul
> > I think largeblocksidechainsshould be reconsidered:
> > * They are not a blocksize increase.
> This is short sighted. They would absolutely be a blocksize increase
> for those following a large block sidechain. While sure, it wouldn't
> affect bitcoin users who don't follow that sidechain, its misleading
> to call it "not a blocksize increase" for everyone.
Your larger explanation is entirely correct.
Many of the important anti-largeblock arguments are not relevant to the largeblock sidechain strategy, but some of them still are.
My concern is that people will jump to conclusions, and use the old 2015 arguments against "a blocksize increase" against this idea.
Hence my small bullet point.
> > * They allow users to be different. Some can pay more (for more decentralization), some less (for less decentralization).
> > gambling the entire future of BTC, on the premise that strong decentralization will always be needed at all points in time.
> Decentralization isn't just something where more is more valuable and less is less valuable. Decentralization is either enough to stop a class of attack or its not. Its pretty binary. If the decentralization is not enough, it would be a pretty huge catastrophe for those involved. Its pretty clear that making the blocksize eg 10 times larger is a poor design choice. So advocating for such a thing on a sidechain is just as bad as advocating for it on an altcoin.
> Even if people only put a couple satoshis in such a sidechain at a time, and don't feel the loss very much, the *world* would feel the loss. Eg if everyone had $1 in such a system, and someone stole it all, it would be a theft of billions of dollars. The fact that no individual would feel much pain would make it not much less harmful to society.
I believe that you have missed my point. Let me try to explain it in more detail.
First, imagine a magic spell is cast, which 100% prevents the "class of attack" which you mention. In that situation, all of the work that BTC does to remain decentralized, is a pure burden with absolutely no benefit whatsoever. Rational users will then become indifferent to centralization. Since decentralization has tradeoffs, users will tend to be drawn towards 'crypto' projects that have very low decentralization.
Next, imagine that the spell is lifted, and the attacks start. Users will be, of course, drawn back towards BTC, and they will appreciate it for its decentralization.
So what's the problem? Well, I believe that money has very strong network effects. Therefore, I believe that "user inertia" will be much stronger than usual. At a certain critical mass it may be insurmountable. So, at certain points along the spectrum, users will "clump up" and get "stuck".
Thus, we may "clump" on a chain that is not the most decentralized one. And an adversary can use this to their advantage. They can "grow" the centralized chain at first, to help it, and help ensure that they do not have to deal with the most decentralized chain.
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.
As for the phrase " Its pretty clear that making the blocksize eg 10 times larger is a poor design choice" I think this entire way of reasoning about the blocksize, is one that only applies to a non-sidechain world.
In contrast, in a world where many chains can be created, it does not matter what Some Guy thinks is "pretty clear". The only thing that matters is that people can try things out, are rewarded for successes, and are punished for mistakes.
So: if someone makes a largeblock sidechain, and the design is bad, the chain fails, and their reputation suffers.
In my way-of-reasoning, 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.
In fact, it is often best for everyone (especially the end user), if a creator keeps their ideas secret (from the "peer review" community). That way they can at least get credit/glory. The soon-to-be-successful experiments of tomorrow, should be incomprehensible to the experts of today. That's what makes them innovations.
Finally, to me it makes no difference if users have their funds stolen from a centralized Solana contract (because there is only one full node which the operator resets), or from a bip300 centralized bit-Solana sidechain (for the same reason). I don't see why the tears shed would be any different.
> > 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.
> If there's some design principles that *allow* for safely increasing the blocksize substantially like that, then I'd advocate for it in bitcoin. But the goal of sidechains should not be "shoot from the hip and after everyone on that sidechain gets burned we'll have learned valuable lessons". That's not how engineering works. That's akin to wreckless human experimentation.
Again, we perhaps have a fundamental disagreement on this point.
In 2008 a FED chairman might have said to Satoshi, "If there were design principles that *allowed* for private, digital, bearer-instrument, payments, then of course I'd advocate for it here at the FED. But the goal of bitcoin should not be 'shoot from the hip ...'. That's not how engineering works. That's akin to wreckless human experimentation."
I think that the most dangerous experiment of all, is to adopt the 'reckless' policy of suppressing creativity.
If instead you said something like, "If a 10x blocksize chain is ever demonstrated to have property XYZ, then I will repent my error by putting my own children to death", then the audience would at least have some idea of your confidence and sincerity. But, again, a FED chairman could say exactly that, about Bitcoin. And they would still have been wrong. And even if they were right (on a fluke) they would still have been wrong to prevent the idea from being tried.
Censorship (the suppression of ideas, merely because you disagree with them) is not only immoral, on this issue it is also largely pointless. Today, a Bitcoiner can sell their BTC for Solana, or BSV, and there is nothing anyone here can do about it. Altcoin Solana vs bip300 bit-Solana, would seem to be equivalently reckless to me. So, your implicit advice (of bureaucracy-based sidechain drop/add), seems to fail to meet your own criterion (of preventing human recklessness). And it certainly does other bad things for no reason (pumps an altcoin, decreases btc fee revenues /hashrate, etc).
Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220227/bb030454/attachment.html>

2023-06-07 23:03:37

- 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

- 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:08:12

- reply

📅 Original date posted:2017-12-12
📝 Original message:Hi Zmn,
I'm actually not sure that the existence of these tools makes the
attacker's collective action problem that much easier to solve.
As I said: "...even the most straightforward attack (of "a 51% hashrate
group attacks a sidechain and distributes the proceeds to the group
proportional to hashpower") is actually one that contains a difficult
(and potentially interminable) negotiation."
But even under your scheme, there is someone who has to seek out the
Accomplices, and has to try to figure out what is acceptable to pay
them. This sparks a tiresome negotiation that drains both parties of
time and effort and might potentially last forever. Problematically,
there is a Market for Lemons problem with respect to how many blocks an
Accomplice "will" mine. If many people try to be Thieves at once, then
each individual Thief has less of an incentive to bother trying to steal
in the first place.
And so, even if your scheme does work, the improvement seems small. And
even if the improvement is very great, the remaining collective action
problem is still more difficult than the one in the comparative "reorg
case" (in which the problem is just to "pick the block number from which
to start the reorg").
Paul
On 12/5/2017 11:49 PM, ZmnSCPxj wrote:
> Good morning Paul and Chris,
>
> >3. Collective Action Problem
> >
> >There actually is a collective action problem inherent to fraudulent
> withdrawals.
> >
> >If miners wish to fraudulently withdraw from the sidechain, they need
> to choose the destination addresses (on mainchain Bitcoin Core) months
> in advance. Then they need to upvote/downvote this
> >destination, despite that fact that --during this time-- new
> hashpower might be coming online/offline, and/or hashers might be
> joining/leaving specific pools. I bring this up to demonstrate that
> even the most
> >straightforward attack (of "a 51% hashrate group attacks a sidechain
> and distributes the proceeds to the group proportional to hashpower")
> is actually one that contains a difficult (and potentially
> >interminable) negotiation. The effort required to initiate the
> negotiation is the source of the collective action problem here.
> >
> >I think that this collective action problem is actually more
> burdensome than Bitcoin's -- for mainchain Bitcoin miners merely need
> to decide which block height they intend to reorganize from.
>
> I actually devised a way to work around this collective action
> problem, and discussed it obliquely in a private e-mail with Chris,
> while I was preparing my article on sidechain weaknesses. I removed
> it before publication of the sidechain weaknesses article, but perhaps
> I should not have.
>
> Collective action can be ensured by contract. In a world where some
> system can enforce certain actions programmatically, it is possible to
> ensure collective action via a program, i.e. a "smart contract".
>
> The thief pays out to the destination address that is a P2SH of the
> below script:
>
> OP_IF
> OP_HASH160 <hash> OP_EQUALVERIFY
> OP_DUP OP_HASH160 <thiefPubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
> OP_ELSE
> <withdrawTime+1week> OP_CHECKLOCKTIMEVERIFY OP_DROP
> OP_TRUE
> OP_ENDIF
>
> If the thief does not publish the preimage of the hash within 1 week
> of the withdrawal time, then it becomes possible for anyone to spend
> the above script; basically, some lucky miner who wins the first block
> past the specified time will get the entire winnings. Let us call the
> above script, the Theft Contract.
>
> The thief then recruits accomplices to the theft. Note that the
> attack can be prepared and initiated before the accomplices are even
> recruited.
>
> The thief locks some coins (the "cut" the accomplice gets), to the
> below script, for each accomplice it tries to entice:
>
> OP_IF
> OP_HASH160 <hash> OP_EQUALVERIFY
> OP_DUP OP_HASH160 <accomplicePubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
> OP_ELSE
> <withdrawTime+2week> OP_CHECKLOCKTIMEVERIFY OP_DROP
> OP_DUP OP_HASH160 <thiefPubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
> OP_ENDIF
>
> Let us call the above script, the Accomplice Contract. If the
> accomplice accepts, he or she then starts to vote for the invalid
> withdrawal.
>
> If the invalid withdrawal succeeds, the thief acquires the entire
> theft price from the Theft Contract by publishing the preimage to the
> <hash>. (If he or she does not, then, some randomly-selected miner
> will acquire the money after the timeout, so the thief needs to
> publish the hash, before the timeout in the Theft Contract).
>
> This publishes the preimage on the blockchain. Each accomplice can
> then acquire their "cut" of the theft by copying the preimage and
> claiming from the Accomplice Contract.
>
> If the theft never succeeds, then there is no reason for the thief to
> ever publish the preimage, and after the timeout on the Accomplice
> Contract, the thief can recover his or her offered funds at no loss
> (minus transaction fees), This incentivizes accomplices to actually
> cooperate with the thief, as they will not get paid if the theft does
> not push through.
>
> All that is necessary is for a single "mastermind" thief to begin this
> process. Accomplices can be recruited later, with the "cut" they get
> negotiated according to how much hashpower they can bring to bear on
> theft.
>
> Newly-created miners and mining pools can be enticed at the time they
> arise by offering an Accomplice Contract to them. Thus, newly-created
> miners and mining pools can be brought into cooperation with the thief
> as soon as they make a presence on the blockchain.
>
> Even if some mining pool makes a public statement that they will not
> assist in the theft, the thief may still commit an Accomplice Contract
> for them on-chain anyway, and publicize it, in order to put the
> integrity of that mining pool in question and drive out support from
> that mining pool. True accomplices may pretend to initially be honest
> and then signal dishonestly later, in order to make it more plausible
> that a pool that "committed" to not support the theft is not trustable
> since they have an Accomplice Contract that will compensate them if
> they support the theft, creating further confusion and discord among
> honest miners. The thief may also use the existence of such an
> Accomplice Contract while negotiating with more minor miners and
> mining pools, in order to entice those also to join, and thus gain
> additional buffer against the stochastic process of miner voting.
>
> With the Theft Contract and the Accomplice Contract, negotiation can
> be done in parallel with the theft attempt, reducing the cost of
> organizing collective action, as we have all hoped "smart contracts"
> would do.
>
> ----
>
> While it is true, that this requires that the thief have significant
> funds in reserve prior to theft (in order to fund the Accomplice
> Contracts he or she will have to offer to potential accomplices), we
> have always been assured that theft can be initiated by miners only,
> and that miners already have a significant amount of money they
> control. So it will be no problem for a potential thief to reserve
> some funds for paying to Accomplice Contracts.
>
> This vulnerability can be fixed if withdrawals are restricted to
> simple P2PKH or P2WPKH only, but in the presence of Scriptless Script
> and Bellare-Neven signatures, that may be sufficient to create the
> Theft Contract and the Accomplice Contract (but I know too little of
> Scriptless Script to be sure).
>
> Regards,
> ZmnSCPxj

2023-06-07 18:08:10

- reply

📅 Original date posted:2017-12-05
📝 Original message:Hello Chris,
1. Marginal Cost
There actually is a very small cost to casting a malicious vote,
relative to an honest vote. This is because the software (when run
as-is), will automatically vote correctly. But to vote fraudulently you
must decide on what to do instead, and configure that! This might not be
as easy as it seems (see collective action part, below).
It is true that there is no *marginal* cost to creating a bad vote, in
the fraudulent withdrawal case. But then again there is no marginal cost
to creating a good vote either -- in fact there is no cost at all. In
fact, there is no marginal cost to creating a bad block either, in the
51% hashrate reorganization case. Epistemologically, the protocol has no
way of differentiating a "bad" block/vote from a good one. So one cannot
"cost" more than the other, in a narrow sense.
I suppose in the reorganization case there is the risk of lost mining
effort on a chain that actually does *not* have 51% and therefore won't
catch up. But this only encourages conformity to the longest chain,
including fraudulent chains. For example, imagine that the
reorganization is done via secretly mining a longer chain -- once that
chain is published, it will be the longest. Then, according to your
framework, there will be a "marginal cost" to doing the *right* thing
(trying to preserve the honest, transparent chain). So I'm afraid I
don't understand what you mean.
2. Repercussions
As for there being no repercussions, that is incorrect. The miner's
choice to engage in a fraudulent withdraw is one that has several
negative consequences. They take a variety of forms and likelihoods, but
they definitely exist and are very relevant.
The first repercussion is the loss of victim-sidechain future tx-fees. A
second is the loss of all future tx fees on all sidechains. A third is
that the Bitcoin super-network is changed from being a "sidechain
enabled" network to a "sidechain disabled" network.
The impact of these repercussions is still unclear and open to
interpretation. On one hand, the impact may be small and therefore not
very persuasive (as in the case where a sidechain has few tx-fees, few
sidechains are used, few are expected to be created/used, and so little
is lost by attacking). On the other hand, a single fraudulent withdrawal
might motivate the creation of a new spinoff network that is exactly the
same as the old network, but with merely two changes: the fraudulent
withdrawal surgically removed (as if it were never attempted) AND a new
proof of work algorithm. Since the withdrawals are so slow, there would
be plenty of time to organize such an option (and people who already
want a pow-change would jump at this glaring opportunity). Will the
repercussions be small or large? Even if there is only a *risk* of large
repercussions, it can be very persuasive. (Just as the IRS is very
persuasive to tax-paying Americans, even though only a tiny proportion
of tax returns are audited.)
0. Useless Sidechain Fallacy
Finally, you are joining the long list of people who are committing the
"useless sidechain fallacy". You are saying that because you believe the
sidechain is useless, therefore everyone must believe as you do, and
therefore the option to use a sidechain must be one that has zero value.
However, in the real world people are heterogeneous. They may decide
that your interpretation contains errors, or else their circumstances
might incline them towards a different risk-reward tradeoff. Finally,
this fallacy obfuscates the main benefit of sidechains, which is that
they are optional -- the sidechain-designer must convince users to
deposit funds there.
3. Collective Action Problem
There actually is a collective action problem inherent to fraudulent
withdrawals.
If miners wish to fraudulently withdraw from the sidechain, they need to
choose the destination addresses (on mainchain Bitcoin Core) months in
advance. Then they need to upvote/downvote this destination, despite
that fact that --during this time-- new hashpower might be coming
online/offline, and/or hashers might be joining/leaving specific pools.
I bring this up to demonstrate that even the most straightforward attack
(of "a 51% hashrate group attacks a sidechain and distributes the
proceeds to the group proportional to hashpower") is actually one that
contains a difficult (and potentially interminable) negotiation. The
effort required to initiate the negotiation is the source of the
collective action problem here.
I think that this collective action problem is actually more burdensome
than Bitcoin's -- for mainchain Bitcoin miners merely need to decide
which block height they intend to reorganize from.
You may wish to read Drivechain's security model to learn more:
http://www.truthcoin.info/blog/drivechain/#drivechains-security
In this case, I don't see a way to measure "security" cardinally or
ordinally. Instead, I am only able to see it as either "secure enough"
or "not secure enough". But perhaps someone can enlighten me as to the
math they are using to produce these cardinal/ordinal rankings.
--Paul
On 12/4/2017 2:36 PM, Chris Pacia wrote:
>
> I think you are missing a few things.
>
> First of all, I think the security model for sidechains is the same as
> that of every blockchain
>
> People will say things, like "but with sidechains 51% hashrate can
> steal
> your coins!", but as I have repeated many times, this is also true of
> mainchain btc-tx. is something else?
>
>
> There are substantial opportunity costs as well as a collective action
> problem when it comes to re-writing the mainchain.
>
> Is there anything similar for drivechains? As far as I can tell there
> is no opportunity cost to casting a malicious vote, no repercussions,
> and no collective action barrier that needs to be overcome.
>
> Unless I'm missing something I wouldn't liken the security of a
> drivechain to that of the mainchain.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171205/cabb88c2/attachment.html>

2023-06-07 18:08:09

- reply

📅 Original date posted:2017-12-12
📝 Original message:Hello ZmnSCPxj,
Thanks for contributing your thoughts. I wish I were able to respond sooner!
1. I'm a little confused about the second half of your message, and its
emphasis on pools. As you know, pools can be created or destroyed an
unbounded number of times, costing only a small time lag. So I do not
see why anyone would care about pool-death (except for the administrator
of the pool of course -- and this exception is, itself, strong evidence
that pools will reflect the interests of their members). Pools are just
some naturally-occurring phenomenon that arise when many different
hashers all want similar things.
2. You have quoted a section where I suppose that miners are offering an
'atomic swaps' service. And you usually talk about that hypothetical
scenario I've outlined. But sometimes you talk in a way that leads me to
believe that you have departed from that hypothetical. For example you
talk about frozen withdrawals, invalid withdrawals, and miner-to-user
harm. But that isn't possible in my hypothetical, because users can
escape all of those things by using atomic swaps (which, recall are
instant and competitively priced, see #4). Moreover, miners can pretend
to be users (for the purpose of using these atomic swaps). If you want
to talk about a world where users aren't using these swaps, I would
appreciate it if you were more clear.
3. The question of miners harassing each other using strategy is a very
interesting one.
First, (as you seem to know) the withdrawals are designed to be
combine-able. This is in fact not only the default behavior but also the
most efficient behavior. (Assuming that n quantity of economic transfers
must go across, it is of course best to do them in one transaction.) So,
your complaint must immediately be limited to the case of "spiteful"
miners who care more about blocking opponent's transfers (for whatever
reason) than they care about upvoting their own transfers.
However, if any miner pursues a spiteful strategy, the victim(s) can
respond by orphaning. For example, if 33% are producing 'spiteful
blocks', the other 66% can easily orphan these. The central issues, as I
see it, is that to be *spiteful* is also to be *different* and
*noticeable*. Thus, different blocks can be orphaned.
Some may worry that this opens the door to endless vindictive arbitrary
orphaning (and that this is either the reason that such an alternative
will not work and therefore not be persuasive, or else that the outcome
of endless arbitrary orphaning would itself be a bad one). My view (and
observation) is that the threat of eventual orphaning is sufficient, and
that therefore there will be no actual orphaning. This is because the
antagonizing 33% group is now its own victim group, and they now have an
overwhelming incentive to either [a] stop being different (in this case,
spiteful), or else to [b] quickly obtain an additional 18% hashrate so
as to survive the orphaning. Should they add 18% to their 33%, "they"
will have 51%, and we might wonder if they will try orphaning of their
own. However, if they do, it merely restarts the above logic, with the
49% fighting to persuade a critical 2% to join.
So far, this logic may terminate with two 50% pools that each stubbornly
refuse to interact. But eventually chance will one of their blockchains
ahead of the other's, and the members of the disfavored group will feel
pressure to defect (or else they are likely to be left behind). It is no
different from traditional miner-bitterness over having not found the
most-recent block.
Users who move side-to-main via atomic swaps will have no reason to care
about any of this.
4. As I point out in the Nov 2015 specification and security model, and
as you have suggested, the atomic swaps will only be ultra-cheap and
ultra-available if there exists *some other way* of *eventually* moving
side-to-main with *certainty*. The goal is to have a side-to-main method
that definitely will work, even if it takes a very long time to work.
Then the atomic swap is paying a premium for speed only, relative to
this method. This is why the security model of drivechain relies
(partially) on investor disappointment that sidechains are no longer
going to be supported. And it is why the slow (non-AtomicSwap)
withdrawal process is so slow and delay-able in the first place -- to
increase its security. If it is secure enough to withstand any attack,
then attackers will eventually give up (or else, they will never attack
in the first place). This satisfies the criterion of an alternative
withdrawal process that is certain and eventual.
Paul
On 12/7/2017 2:28 AM, ZmnSCPxj wrote:
> Good morning Paul and Chris,
>
> >I don't agree with the conclusion (that the optimal policy is "always
> downvoting", see above), but even if this analysis turns out to be
> correct, it isn't a total disaster. The result (which is in the
> original Nov
> >2015 specification) is that miners are the ones who perform the
> atomic swaps. Then they walk the coins side-to-main (which, at this
> point, are *their* coins). As long as there are a few large mining
> groups,
> >competition will drive the atomic swap fees down to negligible levels.
>
> Assuming there are three large mining groups who will ruthlessly want
> to undercut their competition, and with roughly 33% of total hashpower
> each (with the remaining 1% being some negligible hoi polloi), then
> one strategy to undercut your competitors would be to upvote only your
> own withdrawals and downvote that of your competitors. A miner using
> this strategy hopes that the other miners will give up on withdrawing
> their own coin and trade their sidecoins at a discount to the
> undercutting miner. That is, it is a hostage attempt of the sidecoin
> funds of the other miners.
>
> In the case of three large mining pools that mistrust one another,
> then, no withdrawal would ever push through and drivechains stabilize
> to one-way pegs.
>
> Now suppose that two of the mining pools collude. They join their
> withdrawals into a single withdrawal proposal and upvote that, while
> downvoting the withdrawal of the third miner. I observe that this is
> an opposite disaster: the 66% colluding miners can instead decide to
> simply outright make an invalid withdrawal of all funds, split up in
> half between themselves.
>
> --
>
> But three exactly equal mining pools is unnatural, for that matter
>
> Suppose that there are three mining pools: A with 34%, B with 33%, C
> with 32%, and the hoi polloi making up the remaining 1%. Those three
> pools cannot safely let the others withdraw funds.
>
> Suppose A colludes with C to join their withdrawal proposals and their
> hashpower to withdraw. This means that B can be pressured to sell its
> sidecoins for a discount to the joint coalition of A and C, since B
> cannot withdraw its own coins. This lowers the profitability of B,
> causing grinders to leave them in favor of either A or C. Since A is
> slightly larger than C, it is slightly more preferable, so it grows in
> size slightly more than C does. Eventually B dies due to the
> coalition of A and C. A and C are the only remaining pools, with A
> slightly larger than C. In this case, A can break from the coalition
> and squeeze C of its sidecoins, since only A can withdraw (as it has
> more hashpower than C). Again, grinders will leave C for A. A
> rational C that is capable of considering this possible future path
> will thus never ally with A in a coalition to crush B, as it will then
> be next in line for being destroyed.
>
> Similar analyses for coalitions of (B, C) and (A, B).
>
> Knowing this, and knowing that they will end up sidecoin bagholders if
> they cannot withdraw coins, all miners decide to collude together and
> put all their withdrawals into a single withdrawal proposal. But this
> removes any check-and-balance that the single withdrawal proposal is
> truthful to the sidechain: that is, the single coalition of A,B, and C
> can decide to just steal all sidechain funds and reassign them in
> proportion to their hashpower. This might be stable at end-of-life
> for the sidechain where all ordinary users of the sidechain have
> exited it, but is otherwise a theft risk if the sidechain is operating
> normally.
>
> Regards,
> ZmnSCPxj

2023-06-07 18:08:08

- reply

📅 Original date posted:2017-12-05
📝 Original message:Hi Other Chris,
Thanks for pointing this out. Here are my responses.
On 12/4/2017 3:11 PM, Chris Stewart wrote:
>There is another interesting analysis on BMM and drivechains from
/u/almkglor on reddit. I'm going to share here for visibility.
>> 3 and 7 will mean that non-verifying miners will be (inadvertently)
complicit in theft. Drivechains have 1008-block cycles ostensibly to
protect against theft, so that someone can "raise the alarm" and tell
miners to downvote a particular theft withdrawal, but that sounds too
much like centralized collusion to me.
Well, that is simply not what "centralized" means. "Centralized" means
that one person has special, irreplaceable influence. In contrast,
"decentralized" means that the process is not uniquely influenced by
what any *one* individual does or believes. Which is the case here: each
miner can independently make a decision about what to check, how to
check it, and what to do as a result. They could do undertake this
process, even if they ignored what everyone else was doing.
>> ...
>>
>> It seems Drivechain's security model is: miners always upvote by
default. If a theft withdrawal is done on the mainchain, some sidechain
nodes call up their miner friends (which makes me worry about miner
centralization) to downvote it instead.
>>
>> The problem is: what if after a theft withdrawal is defeated, another
theft withdrawal is done? And another, and another? This weakens the
peg: while a theft withdrawal is on-going, a genuine withdrawal can't be
posted (at least as I understand Sztorc's explanation). This chokes the
sidechain withdrawal.
This is a good question.
The answer is that there are mechanisms in place to address these
problems. Contrary to the reviewer's interpretation, multiple
withdrawal-attempts *are* allowed simultaneously. (This part of design
may have changed between now and Nov 2015, and I'm not sure if it was
ever documented anywhere until very recently). Second, only one
withdrawal can be upvoted at a time [ie, per sidechain per main:block].
Third, upvoting one withdrawal automatically downvotes all of the other
withdrawals (all in-progress withdrawals for that sidechain). Thus, we
have the asymmetry we desire. An "auditor class" can ignore all of the
withdrawals, until a significant amount of time has been invested in one
candidate. This makes the attempt more futile. Since they are unlikely
to be meaninglessly harassed, this opens the door to a "farmer class"
who can take it upon themselves to make sure the good withdrawals get
in, and get upvotes (especially early upvotes). Thus, the system can
tolerate a large "loafer class" who just lazily upvotes everything (or
nothing, or only the front-runner).
> TLDR: a miner is most profitable if he always accepts BMM bribes, but
downvotes withdrawal transactions (WT). This obviously isn't ideal
because a withdrawal will never occur from the drivechain if enough
miners employ this strategy -- which seems to be the most profitable
strategy.
>
>-Chris
I agree that miners should "always accept BMM bribes". In my recent
email to Matt Corallo, I described that this is basically the same as
saying that miners should "always mine on top of the heaviest chain".
(Of course, in mainchain Bitcoin miners are advised to mine atop the
heaviest *valid* chain, which is different from this case. It is
different because blind-merged-miners have no way of knowing if the
sidechain blocks they are mining are valid or not, which is kind of the
point. In practice I estimate that between 70% and 100% of today's
hashpower is already mining the mainchain "blind" -- through some
combination of pools, spv and spy mining.)
I don't agree with the conclusion (that the optimal policy is "always
downvoting", see above), but even if this analysis turns out to be
correct, it isn't a total disaster. The result (which is in the original
Nov 2015 specification) is that miners are the ones who perform the
atomic swaps. Then they walk the coins side-to-main (which, at this
point, are *their* coins). As long as there are a few large mining
groups, competition will drive the atomic swap fees down to negligible
levels. This slightly encourages mining to consolidate into two large
pools...but of course that is also true of the status quo!
Paul
>
> On Mon, Dec 4, 2017 at 1:36 PM, Chris Pacia via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
>
> I think you are missing a few things.
>
> First of all, I think the security model for sidechains is the
> same as
> that of every blockchain
>
> People will say things, like "but with sidechains 51% hashrate
> can steal
> your coins!", but as I have repeated many times, this is also
> true of
> mainchain btc-tx. is something else?
>
>
> There are substantial opportunity costs as well as a collective
> action problem when it comes to re-writing the mainchain.
>
> Is there anything similar for drivechains? As far as I can tell
> there is no opportunity cost to casting a malicious vote, no
> repercussions, and no collective action barrier that needs to be
> overcome.
>
> Unless I'm missing something I wouldn't liken the security of a
> drivechain to that of the mainchain.
>
> _______________________________________________
> 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
> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171205/1ade3365/attachment.html>

2023-06-07 18:08:07

- reply

📅 Original date posted:2017-12-04
📝 Original message:Hi Matt,
Thanks for very much for your thoughtful review
Comments below.
On 12/3/2017 4:32 PM, Matt Corallo wrote:
> ...
>
> ...
>
> Comments on BIP 1:
>
> At a high level, I'm rather dissapointed by the amount of data that is
> going into the main chain here. Things such as a human readable name
> have no place in the chain, IMO.
Well, that is quite a minor quibble, because it is just a one-time cost
of 120 bytes per sidechain.
To address it, there could instead be a hash commitment to this
information. That commitment could be "optional", in that old nodes
wouldn't need to possess the 120 bytes. Although, all of the sidechains
are themselves optional. And old nodes will be ignoring all of this data
anyways. So I do not think
The inclusion of this field is deliberate. Probably, you do not buy my
lengthy argument about "categorical control".
http://www.drivechain.info/faq/#categorical-control
Perhaps you have seen my May 2016 presentation on the topic. It was
itself a lengthy reply to comments that Greg Maxwell made about the
original Nov 2015 Drivechain post.
https://www.youtube.com/watch?v=xGu0o8HH10U&list=PLw8-6ARlyVciMH79ZyLOpImsMug3LgNc4&index=1
Either you aren't aware [of why I want each sidechain to have a
comprehensible category]. Or, you are aware and you disagree. But if it
is the latter we might just have to agree to disagree.
> ....                                 Further, the use of a well-known
> private key seems misplaced, why not just track the sidechain balance
> with something that looks like `OP_NOPX genesis_block_hash`?
I agree. I myself am unhappy with the private key approach, as it
results in a totally pointless signature being generated, and a
pointless CheckSig operation. (Somewhere, buried in
documentation/GitHub-issue purgatory, there is a discussion of replacing
it with OP TRUE.)
Basically, our way was just a hack to make sure uses knew where they had
to send the money, and also to get the balances to show up in all user's
wallets. I do not pretend to have any expertise in this area (or even
experience) so it is surely an area for improvement.
>
> I'm not convinced by the full semantics of proposal/ack of new
> sidechains. ...           I'd say its pretty important that
> new sidechains be an incredibly rare event.
Well, I partially agree.
However, if drivechain is a soft fork, and if 51% hashrate can add new
softforks at any time, then our ability to alter the rate of
sidechain-creation is very low. While we might use the rules of
"Drivechain I" to impose restrictions on the "add a sidechain" process,
nothing prevents 51% hashrate from re-adding Drivechain to Core a second
time, creating a "Drivechain II" system with its own "add a sidechain"
rules. Thus, the activation speed can increase, even if miners are
incapable of writing any code. Or, miners might add "Drivechain I" to
one of the sidechains. (And of course the new-sidechain-rate can
decrease, through mere miner-censorship.)
So, I think there really is no threat model, other than to say: we
either open Pandora's box or we do not. My vision (for any Redditors who
may be reading this, years in the future!!) is of a stable, conservative
Bitcoin Core with 3-8 sidechains, of which at least one is rather
experimental, and at least one of which has its own sidechains. But who
knows.
More importantly, the problem you've outlined is much much worse for
extension blocks.
(It can scarcely be denied that hashrate wants more block space, and
that they can easily add one or many extension blocks, in public or in
secret, at any time. Will a UASF really be able to disable an in-use
extension block? I think the UASF-case is much less persuasive,
especially since it involves loss/freezing of user funds.)
So I would argue that one of *the* greatest benefits of Drivechain is
that it neutralizes the threat of extension blocks by giving everyone a
better alternative. In fact, I do not know of any other way to
neutralize this threat.
> ... Thus, a much simpler system
> (eg a version-bits-based upgrade cycle with high threshold) could be
> used to add new sidechains based on well-known public parameters.
I don't have a problem with this. In fact that is mostly how we have it
today.
My concern is a scenario where:
Person A: is running the latest version of Bitcoin (which has
drivechain), and full nodes for 3 out of 3 sidechains
Person B: is running the 2nd-latest version of Bitcoin (which has
drivechain), and was disconnected when the 3rd sidechain activated
Person C: is running the 3rd-latest version of Bitcoin (which has
drivechain), but was disconnected for the activation of all sidechains.
Person D: is running 0.5.3 and has no idea what drivechain is.
Then, we consider a case where someone attempts a side-to-main
withdrawal from sidechain #2, but which tries to cheat the drivechain
rules (which are mainchain-enforced).
In one setup, C's security is downgraded. But in other settings it is
not. And in other settings it might do something complicated.
(Although, I also plan to introduce minimum parameter values, both to
prevent C from being harassed in this case, and to force all
drivechain-killing actions to be comparable to each other.)
My thought was to have all drivechain parts to either stand or fall by
themselves. But I am open-minded on this.
> The semantics of the deposit process seem very suboptimal. You note that
> only one user can deposit at a time, but this seems entirely
> unnecessary. As implemented in the first Elements Alpha release (though
> I believe subsequently removed in later versions due to the nature of
> Elements of targeting asymmetric "federated" sidechains), if you have
> outputs that look like `OP_NOPX genesis_block_hash` as the sidechain
> deposit/storage address, deposit can be fully parallel. To reduce
> blockchain bloat, spending them for the purpose of combining such
> outputs is also allowed. ....
Well, your proposal doesn't reduce the bloat, it merely makes
bloat-reduction possible. And your way relies (slightly) on
miner-charity, because it imposes an opportunity cost on miners. (Miners
could sell their blockspace for fees, but instead they must use it to
make these combinations you describe.)
In contrast, the one-user-deposits-at-a-time not only allows bloat to be
addressed, but also forces it to be addressed. It is like forcing
someone who uses a shared kitchen to leave it exactly as clean as they
found it.
While I am concerned by the one-at-a-time concept, I would point out:
* It is NOT one deposit per block. Just one at a time. In general, there
can be as many deposits as needed.
* It will not be a problem if [a] transactions propagate very quickly,
and [b] transactions are signed very quickly.
* If the deposit fails, it will likely be easy for the user to re-do it
(or, this will be made easy, in the UX eventually).
* It may ultimately be the case, that the task of shepherding the coins
around is one that is only ever performed by specialists. They would
have their own ways of batching txns to deal with this issue. In
contrast, regular users might always use atomic swaps / ShapeShift-like
tools.
Nonetheless, I think this is another opportunity for improvement.
Probably, if someone goes deeper into the scripting language and block
validation rules, they will be able to achieve all of the objectives
simultaneously. As you say:
> ...                       You could even go further and allow some new
> sighash type to define something like SIGHASH_ALL|SIGHASH_ANYONECANPAY
> which further specifies some semantics for combining inputs which all
> pay into the same output.
> Finally, you may also want to explore some process for the removal of
> sidechain balances from the main chain. As proposed it seems like a
> sidechain might, over time, fade into an insecure state as mining power
> shifts and new miners no longer consider it worth the value to mine an
> old sidechain (as has happened over time with namecoin, arguably).
Yes, I think there should be some kind of switch for saying "please
withdraw all of your funds because this chain is being closed down".
However, if miners stopped mining a chain, I think sidechain-users would
notice because their blocktimes would start to increase (under blind
merged mining, anyway).
> Comments on BIP 2:
>
> I may be missing something, but I find the security model here kind of
> depressing...Not only do hashpower-secured sidechains already have a
> significantly reduced security level, but now you're proposing to
> further (drastically) reduce it by requiring users to potentially pay in
> excess of the value an attacker is willing to pay to keep their chain
> secure, on a recurring basis?
I think you are missing a few things.
First of all, I think the security model for sidechains is the same as
that of every blockchain
People will say things, like "but with sidechains 51% hashrate can steal
your coins!", but as I have repeated many times, this is also true of
mainchain btc-tx. As I say on drivechain.info:
""" In theory, the incentives of miners and investors are very strongly
aligned: both are compensated most when the exchange rate is highest.
And, in practice, we do not see large reorganizations (where miners can
“steal”, by first depositing BTC to major exchanges, then selling that
BTC for fiat (which they withdraw), and finally rewriting the last 3 or
4 days of chain history, to un-confirm the original deposits). These
reorgs would devastate the exchange rate, as they would cast doubt on
the entire Bitcoin experiment. The thesis of Drivechain is that
sidechain-theft would also devastate the exchange rate, as it would cast
doubt on the entire sidechain experiment (which would itself cast doubt
on the Bitcoin experiment, given the anti-competitive power of
sidechains). """
In fact, it is true of everything, including the lightning network. LN
has the advantage of allowing victims to spend the attacker's funds on
tx fees (as these victims desperately try to get their txn included).
But the LN loses the blockchain's "strength in numbers" advantage --
miners can single-out unpopular individuals, figure out their channels,
and steal from them (and only them) at an inopportune time.
This is not to knock the lightning network -- I believe it is
well-designed and likely to be secure. I am merely saying that this
concept of stringing these security models on a line from "most secure"
to "least secure" is a concept which is reductionist and incorrect.
Drivechain will be more secure if sidechains are popular. But if they
are not popular, the question of how secure they are is not really
interesting, is it?
Secondly, I think you have overlooked something very important indeed.
Sidechains are optional, and so their use should be up to each
individual user, and no one else. Users should be free to make their own
mistakes -- specifically, they should be the ones to decide for
themselves if they want to use an "insecure" system or not.
It would be another matter, if you had a competing sidechain idea which
accomplished the same goal. But you do not.
Thirdly, I do not agree with your claim that the security model is
reduced by BMM. In fact, the way I see it, it is the same as the model
we already have, if not better.
To make this point, let me ask: Who determines the contents (valid or
otherwise) of "the next block that meets the difficulty requirement"?
In Mainchain Bitcoin Core: "Highest Cumulative Difficulty"
BMM Sidechain: "Highest BTC Payment"
But these are actually the very same thing! We merely need to clarify
our thinking with a few simplifications. First, substitute "Most Hashes"
for "Cumulative Difficulty" (as these are expected converge to each
other). Second, ignore *unexpected* fluctuations in the two denominator
prices in the following:
"Most Hashes" = "Most USD Spent on Mining" / (hashes-per-usd price)
"Highest BTC Payment" = "Most USD Spent on Mining" / (btc-per-usd price)
"Most Hashes" = "Highest BTC Payment" = "Most USD Spent on Mining"
It should be clearer now that they are the same model. While the
mainchain follows the heaviest chain, measured in hashes, the sidechain
follows the heaviest chain, measured in BTC. Both are expressions of the
same concept ("value sacrificed")...just expressed in different units.
With that explained, let me bring in this:
>      ...                  It seems like if a chain has 10 BTC stored
> in it, and I wish to reorg it for a potential gain of, lets say, 6 BTC,
> I can pay 6 * 1 BTC (1 per block) to reorg it, and users on the chain
> would be forced to pay >6 BTC to avoid this?
Your example (which is a great example) sounds bleak, but it is in fact
the security model of Bitcoin itself, in the long future without the
block subsidy. Likely, Bitcoin will have new advantages by then
(assuming it survives that long). But this is a problem that just
*can't* be solved without a new block subsidy (which can't be added to
sidechains).
So, you may be successfully arguing that sidechains can never work. (But
that is different from saying that users should be prohibited from
trying them out, as I said above). Or, you may be successfully arguing
that Bitcoin itself will stop working when fees overwhelm the block
subsidy. (Since that hour is rapidly approaching, we might as well start
running experiments now).
The equivalence between hashes and purchases is not perfect. Certainly,
regular miners might be better-behaved than BM-miners, because r-miners
stand to lose their entire hardware investment if the system fails,
whereas BM-miners do not. On the other hand, BMM is *better* in a few
ways, namely that it makes "mining" much more competitive, because it
lowers the barriers to entry for sidechain-mining all the way to zero.
Any node can do it. Furthermore, BM-miners are more cypherpunk-like:
they will not be confined to any physical location, they do not give
away their location (via power usage or thermal exhaust), when they
greedily move into high-efficiency spaces (data centers, EC2 instances)
they can instantly destroy themselves and reappear somewhere else.
I'm not sure if that made you more, or less depressed. But here is a
smiley face :-] .
> While I appreciate the desire to implement the proposed mitigation in
> section 4.3 of the sidechains paper (delegating the mining effort of a
> merge-mined sidechain to an external entity), I believe it was primarily
> referencing pooling the sidechain work, not blindly taking the highest
> bidder.
Well, BMM is more efficient when there are pools. Without them, the
sidechain nodes would be trying to connect to all mainchain miners.
And there's no need for that. In my view, pools are cannot really do
anything wrong (ie, pools cannot do anything except what their members
want them to do). If a pool operator goes rogue and attempts to censor a
transaction, what has actually happened is just that the transaction is
delayed (until the hashers learn about the inefficient policy, and
switch pools). Same for everything else.
In other words, yes pool operators would almost certainly be running a
node of each sidechain.
> ... I suppose, indeed, that, ultimately, as long as the sidechain is
> of relatively small value in comparison to BTC, miners do not risk the
> value of their BTC/mining investment in simply taking the highest bidder
> of a merge-mined block, even if its a clear attack, ...
It is not about the amount of BTC on the sidechain. It is about miner's
estimations of user's valuation of their option to use the sidechain at
any point in the future. The idea of "911 emergency response" is
valuable, and people would complain about a motion to get rid of it,
even though most of those people wouldn't currently be using it.
> Ultimately, I dont believe your proposal here really solves the drawback
> in section 4.3 of the paper, and possibly makes it worse.
That is interesting because that section reads:
""" As miners provide work for more blockchains, more resources are
needed to track and validate them all. Miners that provide work for a
subset of blockchains are compensated less than those which provide work
for every possible blockchain. Smaller-scale miners may be unable to
afford the full costs to mine every blockchain, and could thus be put at
a disadvantage compared to larger, established miners who are able to
claim greater compensation from a larger set of blockchains. """
Which is exactly what BMM does address. It allows miners to ignore the
resource-cost of the sidechain, and therefore smaller miners will not be
at a revenue-disadvantage.
Do you think that the drawback is something else?
And, are you ever going to define "miner centralization"? Is it "the
economic barrier-to-entry for mining", to you?
Paul
>
> On 12/01/17 13:38, Paul Sztorc via bitcoin-dev wrote:
>> Hello,
>>
>> First, Drivechain has vaguely escaped vaporware status. If you've ever
>> thought "I'd like to take a look into Drivechain when there is code",
>> then now is a pretty good time. (Unfinished items include M1, and M8_V2.)
>>
>> https://github.com/drivechain-project/bitcoin/tree/mainchainBMM
>>
>> Also,
>> Site: http://www.drivechain.info/
>> Blank sidechain:
>> https://github.com/drivechain-project/bitcoin/tree/sidechainBMM
>>
>> Second, I think drivechain's documentation / BIP-Drafts are tolerably
>> readable.
>>
>> Here they are:
>>
>> 1.
>>
https://github.com/drivechain-project/docs/blob/master/bip1-hashrate-escrow.md
>> 2.
>>
https://github.com/drivechain-project/docs/blob/master/bip2-blind-merged-mining.md
>>
>> cc: Luke, I think they are ready to be assigned formal BIP Numbers.
>>
>> This is also a request for code review. The most helpful review will
>> probably take place on GitHub.
>>
>> Regular review is also welcome. Although, please read our
>> recently-updated FAQ, at: http://www.drivechain.info/faq .
>> And also see major earlier discussions:
>>
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014364.html
>>
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014559.html
>>
>> Have a nice weekend everyone,
>> Paul
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>

2023-06-07 18:08:06

- reply

📅 Original date posted:2017-12-01
📝 Original message:Hello,
First, Drivechain has vaguely escaped vaporware status. If you've ever
thought "I'd like to take a look into Drivechain when there is code",
then now is a pretty good time. (Unfinished items include M1, and M8_V2.)
https://github.com/drivechain-project/bitcoin/tree/mainchainBMM
Also,
Site: http://www.drivechain.info/
Blank sidechain:
https://github.com/drivechain-project/bitcoin/tree/sidechainBMM
Second, I think drivechain's documentation / BIP-Drafts are tolerably
readable.
Here they are:
1.
https://github.com/drivechain-project/docs/blob/master/bip1-hashrate-escrow.md
2.
https://github.com/drivechain-project/docs/blob/master/bip2-blind-merged-mining.md
cc: Luke, I think they are ready to be assigned formal BIP Numbers.
This is also a request for code review. The most helpful review will
probably take place on GitHub.
Regular review is also welcome. Although, please read our
recently-updated FAQ, at: http://www.drivechain.info/faq .
And also see major earlier discussions:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014364.html
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014559.html
Have a nice weekend everyone,
Paul

2023-06-07 18:07:24

- 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:07:03

- reply

📅 Original date posted:2017-10-10
📝 Original message:What if two sidechains are implemented at once? What if people get excited
about one sidechain today, but a second even-better one is published the
very next week? What if the original mainchain decides to integrate the
features of the sidechain that you just one-way pegged to?
In these cases, the user looses money, whereas in the two-way peg they
would not lose a thing.
While the one-way peg is interesting, it really doesn't compare.
Paul
On Oct 10, 2017 4:19 PM, "Lucas Clemente Vella" <lvella at gmail.com> wrote:
2017-10-09 22:39 GMT-03:00 Paul Sztorc via bitcoin-dev <bitcoin-dev at lists.
linuxfoundation.org>:
> That is only a one-way peg, not a two-way.
>
> In fact, that is exactly what drivechain does, if one chooses parameters
> for the drivechain that make it impossible for any side-to-main transfer to
> succeed.
>
> One-way pegs have strong first-mover disadvantages.
>
I understand the first-mover disadvantages, but I keep thinking that if the
new chain is Pareto optimal, i.e. is in all aspects at least good as the
original chain, but in some so much better to justify the change, the
initial resistance is an unstable equilibrium. Like a herd of buffaloes
attacking a lion: the first buffalo to attack is in awful disadvantage, but
if a critical mass of the herd follows, the movement succeeds beyond
turning back, and every buffalo benefited, both those who attacked the lion
and those that didn't (because the lion was chased away or killed).
--
Lucas Clemente Vella
lvella at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171010/a29725fb/attachment.html>

2023-06-07 18:07:01

- reply

📅 Original date posted:2017-10-10
📝 Original message:I think this response speaks for itself.
On 10/10/2017 10:09 AM, Tao Effect wrote:
> Hi Paul,
>
> I thought it was clear, but apparently you are getting stuck on the
> semantics of the word "burn".
>
> The "burning" applies to the original coins you had.
>
> When you transfer them back, you get newly minted coins, equivalent to
> the amount you "burned" on the chain you're transferring from — as
> stated in the OP.
>
> If you don't like the word "burn", pick another one.
>
> --
> Please do not email me anything that you are not comfortable also
> sharing with the NSA.
>
>> On Oct 10, 2017, at 4:20 AM, Paul Sztorc <truthcoin at gmail.com
>> <mailto:truthcoin at gmail.com>> wrote:
>>
>> Haha, no. Because you "burned" the coins.
>>
>> On Oct 10, 2017 1:20 AM, "Tao Effect" <contact at taoeffect.com
>> <mailto:contact at taoeffect.com>> wrote:
>>
>> Paul,
>>
>> It's a two-way peg.
>>
>> There's nothing preventing transfers back to the main chain.
>>
>> They work in the exact same manner.
>>
>> Cheers,
>> Greg
>>
>> --
>> Please do not email me anything that you are not comfortable also
>> sharing with the NSA.
>>
>>> On Oct 9, 2017, at 6:39 PM, Paul Sztorc <truthcoin at gmail.com
>>> <mailto:truthcoin at gmail.com>> wrote:
>>>
>>> That is only a one-way peg, not a two-way.
>>>
>>> In fact, that is exactly what drivechain does, if one chooses
>>> parameters for the drivechain that make it impossible for any
>>> side-to-main transfer to succeed.
>>>
>>> One-way pegs have strong first-mover disadvantages.
>>>
>>> Paul
>>>
>>> On Oct 9, 2017 9:24 PM, "Tao Effect via bitcoin-dev"
>>> <bitcoin-dev at lists.linuxfoundation.org
>>> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>>>
>>> Dear list,
>>>
>>> In previous arguments over Drivechain (and Drivechain-like
>>> proposals) I promised that better scaling proposals — that
>>> do not sacrifice Bitcoin's security — would come along.
>>>
>>> I planned to do a detailed writeup, but have decided to just
>>> send off this email with what I have, because I'm unlikely
>>> to have time to write up a detailed proposal.
>>>
>>> The idea is very simple (and by no means novel*), and I'm
>>> sure others have mentioned either exactly it, or similar
>>> ideas (e.g. burning coins) before.
>>>
>>> This is a generic sharding protocol for all blockchains,
>>> including Bitcoin.
>>>
>>> Users simply say: "My coins on Chain A are going to be sent
>>> to Chain B".
>>>
>>> Then they burn the coins on Chain A, and create a minting
>>> transaction on Chain B. The details of how to ensure that
>>> coins do not get lost needs to be worked out, but I'm fairly
>>> certain the folks on this list can figure out those details.
>>>
>>> - Thin clients, nodes, and miners, can all very easily
>>> verify that said action took place, and therefore accept the
>>> "newly minted" coins on B as valid.
>>> - Users client software now also knows where to look for the
>>> other coins (if for some reason it needs to).
>>>
>>> This doesn't even need much modification to the Bitcoin
>>> protocol as most of the verification is done client-side.
>>>
>>> It is fully decentralized, and there's no need to give our
>>> ownership of our coins to miners to get scale.
>>>
>>> My sincere apologies if this has been brought up before (in
>>> which case, I would be very grateful for a link to the
>>> proposal).
>>>
>>> Cheers,
>>> Greg Slepak
>>>
>>> * This idea is similar in spirit to Interledger.
>>>
>>> --
>>> Please do not email me anything that you are not comfortable
>>> also sharing with the NSA.
>>>
>>>
>>> _______________________________________________
>>> 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
>>> <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/0bebbbfd/attachment-0001.html>

2023-06-07 18:07:00

- reply

📅 Original date posted:2017-10-10
📝 Original message:Haha, no. Because you "burned" the coins.
On Oct 10, 2017 1:20 AM, "Tao Effect" <contact at taoeffect.com> wrote:
> Paul,
>
> It's a two-way peg.
>
> There's nothing preventing transfers back to the main chain.
>
> They work in the exact same manner.
>
> Cheers,
> Greg
>
> --
> Please do not email me anything that you are not comfortable also sharing with
> the NSA.
>
> On Oct 9, 2017, at 6:39 PM, Paul Sztorc <truthcoin at gmail.com> wrote:
>
> That is only a one-way peg, not a two-way.
>
> In fact, that is exactly what drivechain does, if one chooses parameters
> for the drivechain that make it impossible for any side-to-main transfer to
> succeed.
>
> One-way pegs have strong first-mover disadvantages.
>
> Paul
>
> On Oct 9, 2017 9:24 PM, "Tao Effect via bitcoin-dev" <bitcoin-dev at lists.
> linuxfoundation.org> wrote:
>
> Dear list,
>
> In previous arguments over Drivechain (and Drivechain-like proposals) I
> promised that better scaling proposals — that do not sacrifice Bitcoin's
> security — would come along.
>
> I planned to do a detailed writeup, but have decided to just send off this
> email with what I have, because I'm unlikely to have time to write up a
> detailed proposal.
>
> The idea is very simple (and by no means novel*), and I'm sure others have
> mentioned either exactly it, or similar ideas (e.g. burning coins) before.
>
> This is a generic sharding protocol for all blockchains, including Bitcoin.
>
> Users simply say: "My coins on Chain A are going to be sent to Chain B".
>
> Then they burn the coins on Chain A, and create a minting transaction on
> Chain B. The details of how to ensure that coins do not get lost needs to
> be worked out, but I'm fairly certain the folks on this list can figure out
> those details.
>
> - Thin clients, nodes, and miners, can all very easily verify that said
> action took place, and therefore accept the "newly minted" coins on B as
> valid.
> - Users client software now also knows where to look for the other coins
> (if for some reason it needs to).
>
> This doesn't even need much modification to the Bitcoin protocol as most
> of the verification is done client-side.
>
> It is fully decentralized, and there's no need to give our ownership of
> our coins to miners to get scale.
>
> My sincere apologies if this has been brought up before (in which case, I
> would be very grateful for a link to the proposal).
>
> Cheers,
> Greg Slepak
>
> * This idea is similar in spirit to Interledger.
>
> --
> Please do not email me anything that you are not comfortable also sharing with
> the NSA.
>
>
> _______________________________________________
> 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/20171010/25fb5d8e/attachment.html>

2023-06-07 18:06:59

- reply

📅 Original date posted:2017-10-09
📝 Original message:That is only a one-way peg, not a two-way.
In fact, that is exactly what drivechain does, if one chooses parameters
for the drivechain that make it impossible for any side-to-main transfer to
succeed.
One-way pegs have strong first-mover disadvantages.
Paul
On Oct 9, 2017 9:24 PM, "Tao Effect via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
Dear list,
In previous arguments over Drivechain (and Drivechain-like proposals) I
promised that better scaling proposals — that do not sacrifice Bitcoin's
security — would come along.
I planned to do a detailed writeup, but have decided to just send off this
email with what I have, because I'm unlikely to have time to write up a
detailed proposal.
The idea is very simple (and by no means novel*), and I'm sure others have
mentioned either exactly it, or similar ideas (e.g. burning coins) before.
This is a generic sharding protocol for all blockchains, including Bitcoin.
Users simply say: "My coins on Chain A are going to be sent to Chain B".
Then they burn the coins on Chain A, and create a minting transaction on
Chain B. The details of how to ensure that coins do not get lost needs to
be worked out, but I'm fairly certain the folks on this list can figure out
those details.
- Thin clients, nodes, and miners, can all very easily verify that said
action took place, and therefore accept the "newly minted" coins on B as
valid.
- Users client software now also knows where to look for the other coins
(if for some reason it needs to).
This doesn't even need much modification to the Bitcoin protocol as most of
the verification is done client-side.
It is fully decentralized, and there's no need to give our ownership of our
coins to miners to get scale.
My sincere apologies if this has been brought up before (in which case, I
would be very grateful for a link to the proposal).
Cheers,
Greg Slepak
* This idea is similar in spirit to Interledger.
--
Please do not email me anything that you are not comfortable also sharing with
the NSA.
_______________________________________________
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/20171009/ca05b959/attachment.html>

2023-06-07 18:05:48

- reply

📅 Original date posted:2017-09-09
📝 Original message:Hi everyone,
I have some agreements and disagreements.
I agree with Zmn:
1. That the sidechain's header is fully defined by the bits of data
included in mainchain headers. These bits include "h*" (some hash that
is either of the header itself or side:hashMerkleRoot), something that
forces these hashes into a DAG-like structure (in Zmn's case, it is a
full hashPrevBlock, whereas for us it is just a tiny integer).
2. That "miner-voting" (for lack of better phrase) accomplishes the same
task as any SPV Proof of any kind.
3. That sidechains basically need to be merged-mined; to do otherwise,
there are marginal costs but really no marginal benefits.
However:
On 9/8/2017 12:19 AM, ZmnSCPxj wrote:
> Good morning.
>
> The obvious reply to all this is: what does
> sidechain-headers-on-mainchain do that drivechain cannot do cheaper?
>
> 1. Unifies merge mining (h* commitment) and WT^ validity voting.
> Merge-mined headers increase the vote on a WT^, by increasing the depth
> of the WT^.
1. I think it is a mistake for SHOM ("Sidechain Headers on Mainchain")
to "unify merged-mining and the WT^ validity voting". This causes the
SHOM to regress to mere extension blocks, and they therefore take on
many of the negative properties of extension blocks.
See: http://www.drivechain.info/faq/index.html#usefulness
> 2. Through OP_BRIBEVERIFY, the power to decide the validity of a
> sidechain lies in the economic majority rather than in the miners.
I don't think that this is true. 51% miner-group can pay bribes to
themselves, and orphan any block or txn that disagrees with them.
I also don't think that there is any meaningful difference between "what
the economic majority wants" and "what the miners do". To me it is a
blindingly obvious fact: miners are paid more, only if they increase the
value of { exchange_rate * ([x>=0] + txn_fees) }. This only increases if
Bitcoin is expected to be more objectively useful, and if its users
treasure its use sufficiently to warrant the payment of high tx fees.
When miners disagree with, for example, the bitcoin-dev mailing list,
this is because miners are attempting to guess what the economic
majority wants, and, in making this earnest attempt, miners believe that
the bitcoin-dev interest is different from the economic majority interest.
Obviously, I don't expect to change any minds on this list. After all,
(since no one dares oppose the economic majority), it is a smart
strategy to pretend that the economic majority always agrees with you.
And it is extra smart to avoid examining that belief too carefully.
2.2.1. This seems to imply that sidechains where unified merge-mining
> and WT^ voting are paid for by economic majority, effectively work as
> proof-of-stake. The difference here is that the proof does not have to
> cover itself (i.e. the stake being used to prove is outside the system
> which the proof is proving) and it is really more of a
> proof-of-sacrifice-of-stake, since the economic majority needs to pay
> (and thus lose) the stake for continued operation of the sidechain. One
> can argue that proof-of-work is just an instance of
> proof-of-sacrifice-of-stake anyway.
I agree with most of this, but I think in proof of work and proof of
stake the security guarantee is more reasonable.. In SHOM, there is no
reason to believe that the the quantity "total amount of money available
for withdrawal in a given time" will always be smaller than "sum of 288
bribes".
> 2.2.2. Miner behavior on Bcash and Bitcoin suggests to me that a good
> portion of the miners are interested more in short-term profits than
> long-term.
As long as some critical mass of investors exist, there is no difference
between short and long term profits. It is impossible for an investor to
act in a way that affects the long term, but does not immediately also
affect the short term.
> I have not seen a good explanation of how drivechain WT^ validity voting
> works in detail; my understanding is that a WT^ is presented on the
> mainchain, then a voting period is established during which miners
> somehow vote for whether the WT^ is valid or not, then the voting ends
> and a UTXO is somehow created. If it is in some Sztorc video, I
> apologize, I am unable to usefully view them.
Some documentation is here:
https://github.com/drivechain-project/docs/blob/master/bip1-hashrate-escrow.md
> --
>
> I think lockboxes should have fixed value. The value should be big
> enough that the cost of OP_WITHDRAWPROOFVERIFY is low. Particularly for
> privacy-oriented sidechains, all lockboxes having the same value will
> help tremendously in continuing obscurity after side-to-main transfers.
> However, I am uncertain whether sidechain or mainchain should enforce
> this fixed value. This parameter is something to be endlessly debated.
> Perhaps it should be sidechain that enforces this, but then mistakes
> could occur on the mainchain where some lockbox on the mainchain is
> deemed invalid on the sidechain, and cannot be unlocked validly except
> by destroying the sidechain.
I don't think this makes any sense, because it implies that the value of
288 block's worth of mainchain BTC transaction fees should always be
worth more than the entire market capitalization of Bitcoin.
Specifically, in this case, the error it introduces is that someone
could get around the fixed value by just using multiple sidechains. Then
the miners would just attack all the sidechains simultaneously. (And
these smaller sidechains would themselves have much smaller fees.)
>
> Sidechains may first be deployed as federated peg, then at some
> sidechain height the federation may announce a move to
> drivechain/sidechain-headers-on-mainchain. The move from federated to
> economic-majority-controlled would involve the federation moving its
> controlled lockboxes to OP_WITHDRAWPROOFVERIFY lockboxes.
Sergio likes this idea, but I think that this attitude represents a lack
of faith in the design. Either the design works or it does not. Either
the federation works or it does not.
>
> Sidechain hardforks would be very contentious, with only one clear
> winner that can unlock lockboxes. I think, part of sidechain design
> must be the understanding that sidechains must never be hardforked, and
> only softforked. Indeed, I am very much convinced that it is impossible
> to safely hardfork mainchain at all, and any block size increase must by
> necessity be softforked in.
This is already the case in what we have done...the only way to
guarantee that all clients report the same WT^ is if they are all
running softforks of the first version.
> The mechanism that supports sidechains supports any financial system,
> including centralized, non blockchain ones. The h* commitments can be
> made into commitments to the financial system's state. Basically, it is
> an implementation of CoinWitness, without using zk-SNARKs and instead
> using some mainchain-voted proof, where validity is judged by how much
> maincoin was sacrified to advance that proof. The supported financial
> system might even allow arbitrary execution of Turing-complete code for
> more vulnerabilities.
This is why I do not want ultra-easy, completely-permissionless creation
of sidechains. Miners (and therefore, users) may NOT desire the EXPECTED
behavior of the sidechain.
> Is there some spec for WT^ layout?
Yes, see above.
Thanks,
Paul

2023-06-07 18:04:37

- reply

📅 Original date posted:2017-07-13
📝 Original message:Hello,
On 7/13/2017 9:17 AM, Hampus Sjöberg wrote:
> In softforks, I would argue that 100% of all nodes and miners need to
> upgrade to the new rules.
> This makes sure that trying to incorrectly spend an "AnyOneCanSpend"
> will result in a hardfork, instead of a temporary (or permanent)
> chainsplit.
>
> With drivechains, it seems like the current plan is to only let the
> nodes that are interested in the drivechain validate the other chain,
> and not necessarily 100% of the network.
Correct.
> I guess this could be any percentage of the network, which could lead
> to a temporary/permanent chainsplit depending on how many percentage
> of the miners are also validating the other chain (am I missing
> something here?).
> I have no way to evaluate if this is an okay trade-off.
> It seems like major disruption could very likely happen if say only 5%
> of all fullnodes validate the drivechain.
You are correct that some % of the network would be validating both
chains. However, if miners improperly withdraw from a sidechain, it --by
design-- does not lead to any chainsplit of any kind. Instead, the
sidechain in question just dies a painful death (notice that, if any
withdrawals are improper, it is quite as bad as if all of the sidechain
funds were withdrawn improperly -- this is because the sidechain would
instantly have a bunch of problems, including that it would be
something-like 'fractional reserve' which would lead to an immediate
bank run of withdrawals [none of which could have any real expectation
of success, in my view]).
In practice, a concern of mine is that people *would* try to turn a
sidechain-theft even into some kind of grand UASF-style campaign. I
would prefer for people not to do this. Then again, I do not hold this
preference unconditionally -- I see it as comparable to Bitcoin's
commitment to "the code is the spec". Which is to say that this
commitment is overwhelmingly held, but not dogmatically as in
exceptional cases such as theValue overflow incident [1].
I think that in such ambiguous cases, we must rely on [a] the miner's
desire to maximize the purchasing power of each Bitcoin, and [b] the
technical wisdom of Bitcoin's future leaders in helping miners to
achieve this goal.
[1] https://en.bitcoin.it/wiki/Value_overflow_incident
> To be fully secure, it seems like 100% of all nodes should also have a
> fullnode for the drivechain as well...
Perhaps, but this is exactly what I am trying to avoid. The design goal,
in some sense, is to have "half security", ie <100%. This is because the
only way to achieve "full" 100% security is with full enforcement of all
rules. Full enforcement of the rules, in turn, means either that we are
exactly where we are right now (where we only add compatible rules, aka
the traditional "soft fork") or we are [also] exactly where we are right
now (in that if we add an incompatible rule, it results in a "hard
fork"). I would like to build something new, which trades off on the
qualities of each, and therefore lies (intentionally) somewhere in between.
> This is one of the reasons I don't advocate sidechains/drivechains as
> a scaling solution, it looks like it would have to the same outcome as
> a blocksize increase on the mainchain, but with more complexity.
Keep in mind that, if some people leave the small chain (what you might
call the "Core" chain, although some disagree with summarizing it this
way) for some other chain, it does free up more space on this chain.
I'm not really sure the extent to which that "counts" as increasing
capacity.
Also, I agree that sc/dc do not help with "scalability", if that problem
is defined as "better technology" or as "how to do more with less".
Actually my full view is a little nuanced and it is here:
http://www.drivechain.info/faq/index.html#can-sidechains-really-help-with-scaling
> Thanks for all your work so far Paul.
You're welcome!
Paul

2023-06-07 18:04:35

- reply

📅 Original date posted:2017-07-13
📝 Original message:Greg is still conflating two different usages of the word "theft":
1. Whether the soft fork rules have been followed, and
2. Whether the WT^ submitted by a majority hashrate matches the one
calculated by sidechain nodes.
In his message he claims to uniquely adopt definition #2, saying
(emphasis added):
> I was very clear what I meant by "invalid" in my email: WT^
> transactions that represent miners stealing funds. **Please stick to
> that** and do not play word games.
...however, he revokes that commitment below when it suits his purposes.
Since Greg's message is probably too confusing to be helpful, I will
first clarify both cases:
Case 1 -- soft fork rules -- all "invalid_1" txns are regarded as
"theft_1" and are rejected.
Case 2 -- sidechain's unique consensus rules -- all WT^ are accepted (if
these WT^ are valid_1 under the Case 1 rules), whether they match the
sidechain's reported WT^ or not (in other words, whether they are
valid_2 or not).
In Case 2, the mainchain accepts all WT^ transactions as "valid", in
that they can be included in a block, whether or not they are
"valid_2". By design, sidechains make no effort to validate the rules
specific to each sidechain, just as they make no effort to validate the
rules of Altcoins. In this way, a WT^ transaction is comparable to
someone who is selling an Altcoin to purchase some Bitcoin -- Bitcoin
doesn't care how they got the Altcoin.
On 7/12/2017 11:24 PM, Tao Effect wrote:
> Dear Paul,
>
>> In point of fact, he is wrong, because nodes do the counting. When
>> miners find a block, they can choose to move the counter up, down, or
>> not at all. But nodes do the counting.
>
> I may very well have confused who counts what
To be clear: yes, Greg did get it confused.
And it is very important, because a neglect of the node-enforced rules
is a neglect of **both** theft_1 and theft_2 simultaneously, making it
easier to conflate the both of them as Greg is still doing.
>> In the second case, it so happens that [DC#1], [DC#2], and [DC#3]
>> would also accept any WT^ *that followed the Drivechain rules*, even
>> if they did not like the outcome (because the outcome in question was
>> arbitrarily designated as a "theft" of funds -- again, see the second
>> case in the list above). In this way, it is exactly similar to P2SH
>> because nodes will accept *any* p2sh txn **that follows the p2sh
>> rules**, even if they don't "like" the specific script contained
>> within (for example, because it is a theft of "their" BitFinex funds,
>> or a donation to a political candidate they dislike, etc).
>
> This is false.
>
> For miners to steal P2SH funds, the P2SH script would have to be coded
> to explicitly allow them to do it.
>
> How many P2SH scripts are you aware of that are used for the purpose
> of facilitating such theft?
>
> I know of none, and I bet there are none.
This is the instance I mentioned above -- despite committing to only
discussing theft_2, Greg has secretly switched back to theft_1, when he
talks about a "P2SH script...used for the purpose of facilitating theft".
Under theft_2, there is no way to infer the theft-ness of the
transaction from the script itself. For example, if someone made a
2-of-3 multisig with a third party escrow , and these funds were
"stolen", this would be an example of funds "stolen" from a P2SH under
"theft_2".
At which point Greg would angrily say that whoever wrote P2SH was
reckless and...allowed Bitcoins to be "stolen". Or perhaps he would
switch definitions yet again, and say that "that doesn't count as
theft". blah blah blah yada yada yada
It is true that moving from pre-P2SH to post-P2SH has not --yet--
enabled any theft_2 as a result. But P2SH has also failed to enable
sidechains. Sidechains logically must open the door to theft_2, else
they will regress to the undesirable cases of hard/evil fork (as I
explain in the spec). Empirically, we do not know how much theft_2 will
be enabled by drivechain. Theoretically, it is possible that there will
never be a theft_2 on drivechain.
>> The [DC#2] and [DC#3] nodes would do exactly what the [DC#0] and
>> [DC#1] nodes do. This is what I mean by "every withdrawal is valid".
>
> So, here you are again re-affirming that WT^ transactions representing
> stolen funds are allowed in DC, and by tying them all together you are
> also affirming that the SPV proofs mentioned in DC are completely
> irrelevant / pointless / unused.
I do not affirm the latter. The SPV proofs in DC are very important, as
they are what allow nodes to enforce the delayed withdrawal upon miners.
In fact, this is exactly what Greg admits to being confused about above.
He is correct that he is confused.
Experts including Adam Back (co-author of original sidechains paper, CEO
of Blockstream which started the sidechains conversation) have publicly
stated that they share my belief that this delayed withdrawal technique
is likely to mitigate the threat of theft_2. Greg S is free to hold a
different opinion.
>>> Again, in P2SH miners cannot steal funds, because all full nodes
>>> have a fully automatic enforcement policy.
>>
>> In DC, miners cannot steal funds, because all full nodes have a fully
>> automatic enforcement policy.
>>
>> However, DC *allows* users to choose to place some of their BTC at
>> the relative mercy of the miners in creative ways, if they wish (as
>> does P2SH -- someone could write a script which donates funds to
>> miners, and then fund it... "paying" to that script). This is another
>> example of conflating [DC#1] and [DC#3].
>
> So in the first sentence you say they "cannot steal funds", but
> everything else you've said, including the following paragraph, and
> your specification, indicates they can.
Greg did not specify which theft so I had to guess in the above case.
Above, I refer to "theft_1", the [DC#0] style theft. As always, no one
can "steal_1" funds in that case.
The reason I assumed Greg was talking about theft_1 and not theft_2, is
because he mentioned P2SH and the fact that full nodes automatically
enforce the network's rules. Drivechain's rules impose a new format,
like P2SH, and have new rules which are automatically enforced by nodes.
Greg's style is basically to confuse two things, ask unclear questions
about them, and then try to discover "contradictions" in the mess that
follows. But it is all a function of his conflation of terminology and
nothing else.
> I've finally collected all my thoughts / concerns and have also
> summarized them in this document:
>
> https://gist.github.com/taoeffect/9ff64cf78cf1408ec29f13ed39e534c9
Given how little Greg understands, even after being hand-fed by me for
days and weeks, I admit a totally nonexistent interest in reading it.
Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170713/0d4d25a4/attachment-0001.html>

2023-06-07 18:04:34

- reply

📅 Original date posted:2017-07-12
📝 Original message:I will repeat that Drivechain can sometimes be confusing because it is
different things to different people.
Here is my attempt to break it down into different modes:
[DC#0] -- Someone who does not upgrade their Bitcoin software (and is
running, say, 0.13). However, they experience the effects of the new
rules which miners add (as per the soft fork[s] to add drivechain
functionality and individual drivechains).
[DC#1] -- Someone who always upgrades to the latest version of the
Bitcoin software, but otherwise has no interest in running/using sidechains.
[DC#2] -- Someone who upgrades to the latest Bitcoin version, and
decides to also become a full node of one or more sidechains, but who
ever actually uses the sidechains.
[DC#3] -- Someone who upgrades their software, runs sidechain full
nodes, and actively moves money to and from these.
Greg is still conflating modes [DC#1] and [DC#3]. Specifically, he
equivocates on the team "steal", using it to mean two different things:
[a] spending an invalid transaction, and [b] a withdrawal that would not
match the report given by a sidechain node.
The two are quite different, see my comments below:
On 7/12/2017 9:15 PM, Tao Effect wrote:
>> FYI that document is nearly two years old, and although it is still
>> overwhelmingly accurate, new optimizations allow us (I think) to push
>> the waiting period to several weeks and the total ACK counting period
>> up to several months.
> What does that have to do with my question? The counting period, if I
> understood correctly, is something miners do, not full nodes.
Greg quoted a passage that contained an older parameter estimate of "a
few days", and I thought it would be helpful and informative if I
clarified that the parameter estimate had been updated to a new (more
secure) value.
In point of fact, he is wrong, because nodes do the counting. When
miners find a block, they can choose to move the counter up, down, or
not at all. But nodes do the counting.
> Also, if the document is old and/or outdated, do you happen to have a
> link to a more update-to-date version of the spec? It would be helpful
> for review.
As I stated above, the document is mostly accurate. There is no other
more up to date version.
>> Because if a node doesn't have the sidechain's information, it will
>> just assume every withdrawal is valid. This is comparable to someone
>> who still hasn't upgraded to support P2SH, in cases [DC#0] and [#1].
>
> Right, for [DC#0] and [DC#1], but for [DC#2] an [DC#3] you marked it
> as "Yes" without substantiating why you did so.
Above, Greg omitted his original question. For reference, it was:
> The Drivechain spec seems to claim that its use of anyone-can-pay is the same as P2SH
The answer is that both DC and P2SH use transactions which are 'always
valid' to some group of people (un-upgraded users) but which are
sometimes invalid to new users. So the only difference would be for
[DC#0] vs other versions, but this difference is trivial as miners will
censor invalid txns.
It is your classic soft fork situation.
>> Again, from the perspective of a mainchain user, every withdrawal is
>> valid.
> And that is not how P2SH works.
Again, keep in mind that Greg continually conflates two different things:
1. Whether the soft fork rules have been followed, and
2. Whether the WT^ submitted by a majority hashrate matches the one
calculated by sidechain nodes.
The first case is exactly equal to P2SH. Just as old nodes accept every
P2SH transaction, so too will [DC#0] users accept every WT^ transaction.
In the second case, it so happens that [DC#1], [DC#2], and [DC#3] would
also accept any WT^ *that followed the Drivechain rules*, even if they
did not like the outcome (because the outcome in question was
arbitrarily designated as a "theft" of funds -- again, see the second
case in the list above). In this way, it is exactly similar to P2SH
because nodes will accept *any* p2sh txn **that follows the p2sh
rules**, even if they don't "like" the specific script contained within
(for example, because it is a theft of "their" BitFinex funds, or a
donation to a political candidate they dislike, etc).
>> [DC#2] and [DC#3] would certainly have an interest in understanding
>> what is going on, but that has absolutely nothing whatsoever to do
>> with Bitcoin Core and so is off-topic for this mailing list.
> How is that an answer to my question?
Greg is, of course, not entitled to an answer to irrelevant questions --
just as he would not be entitled to an answer if he asked for my
favorite color or my home address. And such answers would needlessly
consume the mailing list's scarce time.
> What does "[DC#2] and [DC#3] would certainly have an interest in
> understanding what is going on" mean?
It is clear to me that, if we are not clear on the basics first, we
cannot hope to tackle anything intermediate. We will come back to this
after clearing up soft fork part.
> In P2SH, all upgraded nodes will reject invalid P2SH transactions, period.
In DC, all upgraded nodes will reject invalid DC transactions, period.
> What exactly would [DC#2] and [DC#3] nodes do when faced with an
> invalid WT^ transaction — invalid in the sense that it contains funds
> which miners are stealing?
The [DC#2] and [DC#3] nodes would do exactly what the [DC#0] and [DC#1]
nodes do. This is what I mean by "every withdrawal is valid".
> Again, in P2SH miners cannot steal funds, because all full nodes have
> a fully automatic enforcement policy.
In DC, miners cannot steal funds, because all full nodes have a fully
automatic enforcement policy.
However, DC *allows* users to choose to place some of their BTC at the
relative mercy of the miners in creative ways, if they wish (as does
P2SH -- someone could write a script which donates funds to miners, and
then fund it... "paying" to that script). This is another example of
conflating [DC#1] and [DC#3].
Paul
>> On Jul 12, 2017, at 5:26 PM, Paul Sztorc <truthcoin at gmail.com
>> <mailto:truthcoin at gmail.com>> wrote:
>>
>> The confusion below stems from his conflation of several different ideas.
>>
>> I will try to explicitly clarify a distinction between several types
>> of user (or, "modes" of use if you prefer):
>>
>> [DC#0] -- Someone who does not upgrade their Bitcoin software (and is
>> running, say, 0.13). However, they experience the effects of the new
>> rules which miners add (as per the soft fork[s] to add drivechain
>> functionality and individual drivechains).
>> [DC#1] -- Someone who always upgrades to the latest version of the
>> Bitcoin software, but otherwise has no interest in running/using
>> sidechains.
>> [DC#2] -- Someone who upgrades to the latest Bitcoin version, and
>> decides to also become a full node of one or more sidechains, but who
>> ever actually uses the sidechains.
>> [DC#3] -- Someone who upgrades their software, runs sidechain full
>> nodes, and actively moves money to and from these.
>>
>>
>> On 7/12/2017 6:43 PM, Tao Effect wrote:
>>>
>>> I am now looking closer again at step number 4 in the Drivechain
>>> specification [2]:
>>>
>>> 4. Everyone waits for a period of, say, 3 days. This gives
>>> everyone an opportunity to make sure the same WT^ is in both the
>>> Bitcoin coinbase and the Sidechain header. If they’re different,
>>> everyone has plenty of time to contact each other, figure out
>>> what is going on, and restart the process until its right.
>>>
>>> It seems to me that where our disagreement lies is in this point.
>>> The Drivechain spec seems to claim that its use of anyone-can-pay is
>>> the same as P2SH (and in later emails you reference SegWit as well).
>>> Is this really true?
>> FYI that document is nearly two years old, and although it is still
>> overwhelmingly accurate, new optimizations allow us (I think) to push
>> the waiting period to several weeks and the total ACK counting period
>> up to several months.
>>
>> [DC#0] Yes
>> [DC#1] Yes
>> [DC#2] Yes
>> [DC#3] Yes
>>
>> Because if a node doesn't have the sidechain's information, it will
>> just assume every withdrawal is valid. This is comparable to someone
>> who still hasn't upgraded to support P2SH, in cases [DC#0] and [#1].
>>
>> (And this is the main advantage of DC over extension blocks).
>>
>>
>>> 2. Per the question in [1], it's my understanding that P2SH
>>> transactions contain all of the information within themselves for
>>> full nodes to act as a check on miners mishandling the
>>> anyone-can-spend nature of P2SH transactions. However, that does not
>>> seem to be the case with WT^ transactions.
>> [DC#0] They do.
>> [DC#1] They do.
>> [DC#2] They do.
>> [DC#3] They do.
>>
>> Again, from the perspective of a mainchain user, every withdrawal is
>> valid.
>>
>>
>>> In P2SH txns, there is no need for anyone to, as the Drivechain spec
>>> says, "to contact each other, figure out what is going on".
>>> Everything just automatically works.
>> There is no *need* to this in Drivechain, either, for [DC#0] or [DC#1].
>>
>> [DC#2] and [DC#3] would certainly have an interest in understanding
>> what is going on, but that has absolutely nothing whatsoever to do
>> with Bitcoin Core and so is off-topic for this mailing list.
>>
>>
>>> If the security of WT^ transactions could be brought up to actually
>>> be in line with the security of P2SH and SegWit transactions, then I
>>> would have far less to object to.
>> Somehow I doubt it.
>>
>>
>> Paul
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170712/c2d0f02b/attachment-0001.html>

2023-06-07 18:04:33

- reply

📅 Original date posted:2017-07-12
📝 Original message:The confusion below stems from his conflation of several different ideas.
I will try to explicitly clarify a distinction between several types of
user (or, "modes" of use if you prefer):
[DC#0] -- Someone who does not upgrade their Bitcoin software (and is
running, say, 0.13). However, they experience the effects of the new
rules which miners add (as per the soft fork[s] to add drivechain
functionality and individual drivechains).
[DC#1] -- Someone who always upgrades to the latest version of the
Bitcoin software, but otherwise has no interest in running/using sidechains.
[DC#2] -- Someone who upgrades to the latest Bitcoin version, and
decides to also become a full node of one or more sidechains, but who
ever actually uses the sidechains.
[DC#3] -- Someone who upgrades their software, runs sidechain full
nodes, and actively moves money to and from these.
On 7/12/2017 6:43 PM, Tao Effect wrote:
>
> I am now looking closer again at step number 4 in the Drivechain
> specification [2]:
>
> 4. Everyone waits for a period of, say, 3 days. This gives
> everyone an opportunity to make sure the same WT^ is in both the
> Bitcoin coinbase and the Sidechain header. If they’re different,
> everyone has plenty of time to contact each other, figure out what
> is going on, and restart the process until its right.
>
> It seems to me that where our disagreement lies is in this point.
> The Drivechain spec seems to claim that its use of anyone-can-pay is
> the same as P2SH (and in later emails you reference SegWit as well).
> Is this really true?
FYI that document is nearly two years old, and although it is still
overwhelmingly accurate, new optimizations allow us (I think) to push
the waiting period to several weeks and the total ACK counting period up
to several months.
[DC#0] Yes
[DC#1] Yes
[DC#2] Yes
[DC#3] Yes
Because if a node doesn't have the sidechain's information, it will just
assume every withdrawal is valid. This is comparable to someone who
still hasn't upgraded to support P2SH, in cases [DC#0] and [#1].
(And this is the main advantage of DC over extension blocks).
> 2. Per the question in [1], it's my understanding that P2SH
> transactions contain all of the information within themselves for full
> nodes to act as a check on miners mishandling the anyone-can-spend
> nature of P2SH transactions. However, that does not seem to be the
> case with WT^ transactions.
[DC#0] They do.
[DC#1] They do.
[DC#2] They do.
[DC#3] They do.
Again, from the perspective of a mainchain user, every withdrawal is valid.
> In P2SH txns, there is no need for anyone to, as the Drivechain spec
> says, "to contact each other, figure out what is going on". Everything
> just automatically works.
There is no *need* to this in Drivechain, either, for [DC#0] or [DC#1].
[DC#2] and [DC#3] would certainly have an interest in understanding what
is going on, but that has absolutely nothing whatsoever to do with
Bitcoin Core and so is off-topic for this mailing list.
> If the security of WT^ transactions could be brought up to actually be
> in line with the security of P2SH and SegWit transactions, then I
> would have far less to object to.
Somehow I doubt it.
Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170712/72bb7ebe/attachment-0001.html>

2023-06-07 18:04:32

- reply

📅 Original date posted:2017-07-17
📝 Original message:On 7/17/2017 5:47 PM, David A. Harding wrote:
> On Mon, Jul 17, 2017 at 01:13:30PM -0400, Paul Sztorc via bitcoin-dev wrote:
>> However, without interest from the maintainers of bitcoincore.org
>> (specifically these [3, 4] pages and similar) the document will probably
>> be unable to gain traction.
>> [...]
>> [3] https://bitcoincore.org/en/2015/12/21/capacity-increase/
>> [4] https://bitcoincore.org/en/2015/12/23/capacity-increases-faq/
> The BitcoinCore.org maintainers are not psychic. If you want your
> document to appear on the website, please open a PR. If you would like
> help formatting your document for the website, please feel free to send
> me an email off list or open an issue[1] regarding the inadequacy of
> the site's readme.
I meant only to convey that the document would appear on bitcoincore.org
iff the PR were ultimately accepted. In other words, while it is up to
"the community of Core Contributors" in a philosophical sense, it is up
to the maintainers of BitcoinCore.org in a practical sense, because they
are the ones who ultimately decide if the standard has been met.
I think it is perfectly reasonable to keep site-updates narrowly
organized in the GitHub PR sphere (and to ignore everything else).
> [1] https://github.com/bitcoin-core/bitcoincore.org/issues/new
>
> Speaking as the instigator of [3] and the primary author of [4] (both
> originally published on Bitcoin.org), I'll point out that Maxwell's
> reply to you was a slightly rewritten version of a reply to me sent on 4
> November 2016 (as noted elsewhere in the thread and confirmed in my
> mailbox). I include below my signature a complete copy of my reply to
> him (and CC'd to others).
>
> If I had followed through on my earlier plan to post a copy of Maxwell's
> reply on BitcoinCore.org (assuming Bitcoin Core contributors supported
> publishing it), you probably would've known that some Bitcoin Core
> contributors were resistant to roadmaps prior to you writing your
> proposed roadmap. For that failure, and the time you may have wasted
> because of it, I offer you my apologies.
I appreciate you saying that. Thank you.
-Paul
> I will make opening a PR to BitcoinCore.org with his statement a priority
> so that hopefully future confusion can be avoided.
>
> Sincerely,
>
> -Dave
>
> On Fri, Nov 04, 2016 at 07:17:11PM +0000, Gregory Maxwell wrote:
>> [...]
> I just wanted to say that I thought this was an amazing reply. I was
> hoping that if I waited long enough to respond I might find something
> meaningful to add, but nothing has come to mind and I didn't want to
> leave the impression that your reply didn't merit a response.
>
> Maybe we can find a place on the website to post something like this so
> that we can link to it when other people ask for roadmaps and other
> commitments to future plans.
>
> Thanks!,
>
> -Dave

2023-06-07 18:04:31

- reply

📅 Original date posted:2017-07-17
📝 Original message:On 7/17/2017 2:49 PM, Alex Morcos wrote:
> I felt like this whole conversation was putting the cart before the
> horse.
> You might very well have some good ideas in your roadmap update, to
> tell you the truth, I didn't even read it.
Fine, but, before the roadmap itself, I wrote exactly about why I
thought we should update it. Evidently you disagree with the horse, but
it is in front of the cart where it belongs.
> But I don't think we should be taking relatively new/untested ideas
> such as Drivechain and sticking them on a roadmap.
It isn't a "roadmap" anymore -- I changed it to a "forecast".
And I edited the drivechain part to emphasize only that mainchain space
would likely be freed as defectors leave for an alt-chain. The departing
individuals (ir hardcore LargeBlockers) will leave, despite a
security-model NACK from anyone here (in fact, it would probably only
encourage them). That leaves more space for those who remain.
> There is a tendency in this community to hear about the latest and
> greatest idea and immediately fixate on it as our salvation. ... But
> please, lets be conservative and flexible with how we evolve Bitcoin.
> We don't even know if or when we'll get segwit yet.
Drivechain (c. bitcointalk Feb 2014, blog Nov 2015) is actually much
older than "the" SegWit to which you refer. As for being "conservative"
and "flexible", I have tried to do everything I know -- Scaling
conferences, in-person discussions, papers, posts, and presentations,
adding BMM, and posting here for additional peer review. I'm sure you
have lots of ideas about how it could be more conservative and/or
flexible, which I would love to hear.
But again I think people are getting hung up on the drivechain part --
it can be easily taken out, I just thought that, if the plan included
more overall flexibility for industry, then it would help deter network
splits and scaling drama.
Paul
> On Mon, Jul 17, 2017 at 1:13 PM, Paul Sztorc via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> Hello,
>
> Last week I posted about updating the Core Scalability Roadmap.
>
> I'm not sure what the future of it is, given that it was concept
> NACK'ed
> by Greg Maxwell the author of the original roadmap, who said that he
> regretted writing the first one.
>
> Nonetheless, it was ACKed by everyone else that I heard from,
> except for
> Tom Zander (who objected that it should be a specific project
> document,
> not a "Bitcoin" document -- I sortof agree and decided to label it a
> "Core" document -- whether or not anything happens with that label
> is up
> to the community).
>
> I therefore decided to:
> 1. Put the draft on GitHub [1]
> 2. Update it based on all of the week 1 feedback [2]
> 3. Add some spaces at the bottom for comments / expressions of
> interest [2]
>
> However, without interest from the maintainers of bitcoincore.org
> <http://bitcoincore.org>
> (specifically these [3, 4] pages and similar) the document will
> probably
> be unable to gain traction.
>
> Cheers,
> Paul
>
> [1]
> https://github.com/psztorc/btc-core-capacity-2/blob/master/draft.txt
> <https://github.com/psztorc/btc-core-capacity-2/blob/master/draft.txt>
> [2]
> https://github.com/psztorc/btc-core-capacity-2/commit/2b4f0ecc9015ee398ce0486ca5c3613e3b929c00
> <https://github.com/psztorc/btc-core-capacity-2/commit/2b4f0ecc9015ee398ce0486ca5c3613e3b929c00>
> [3] https://bitcoincore.org/en/2015/12/21/capacity-increase/
> <https://bitcoincore.org/en/2015/12/21/capacity-increase/>
> [4] https://bitcoincore.org/en/2015/12/23/capacity-increases-faq/
> <https://bitcoincore.org/en/2015/12/23/capacity-increases-faq/>
>
>
> On 7/10/2017 12:50 PM, Paul Sztorc wrote:
> > 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
> <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html>
> > [2]
> https://bitcoincore.org/en/2017/03/13/performance-optimizations-1/
> <https://bitcoincore.org/en/2017/03/13/performance-optimizations-1/>
> > [3] http://bluematt.bitcoin.ninja/2016/07/07/relay-networks/
> <http://bluematt.bitcoin.ninja/2016/07/07/relay-networks/>
> > [4] https://bitcoincore.org/en/2016/01/26/segwit-benefits/
> <https://bitcoincore.org/en/2016/01/26/segwit-benefits/>
> > [5]
> >
> http://lightning.community/release/software/lnd/lightning/2017/05/03/litening/
> <http://lightning.community/release/software/lnd/lightning/2017/05/03/litening/>
> > [6] https://github.com/ACINQ/eclair
> <https://github.com/ACINQ/eclair>
> > [7] https://people.xiph.org/~greg/compacted_txn.txt
> <https://people.xiph.org/%7Egreg/compacted_txn.txt>
> > [8]
> >
> https://github.com/ElementsProject/secp256k1-zkp/blob/d78f12b04ec3d9f5744cd4c51f20951106b9c41a/src/secp256k1.c#L592-L594
> <https://github.com/ElementsProject/secp256k1-zkp/blob/d78f12b04ec3d9f5744cd4c51f20951106b9c41a/src/secp256k1.c#L592-L594>
> > [9]
> https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/
> <https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/>
> > [10] http://www.drivechain.info/
> > [11] https://bitcoinhardforkresearch.github.io/
> <https://bitcoinhardforkresearch.github.io/>
> > [12]
> >
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013542.html
> <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
> <https://docs.google.com/document/d/1gxcUnmYl7yM0oKR9NY9zCPbBbPNocmCq-jjBOQSVH-A/edit?usp=sharing>
> >
> > Cheers,
> > Paul
> >
>
>
> _______________________________________________
> 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
> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170717/5c86ddb8/attachment-0001.html>

2023-06-07 18:04:30

- reply

📅 Original date posted:2017-07-17
📝 Original message:Hello,
Last week I posted about updating the Core Scalability Roadmap.
I'm not sure what the future of it is, given that it was concept NACK'ed
by Greg Maxwell the author of the original roadmap, who said that he
regretted writing the first one.
Nonetheless, it was ACKed by everyone else that I heard from, except for
Tom Zander (who objected that it should be a specific project document,
not a "Bitcoin" document -- I sortof agree and decided to label it a
"Core" document -- whether or not anything happens with that label is up
to the community).
I therefore decided to:
1. Put the draft on GitHub [1]
2. Update it based on all of the week 1 feedback [2]
3. Add some spaces at the bottom for comments / expressions of interest [2]
However, without interest from the maintainers of bitcoincore.org
(specifically these [3, 4] pages and similar) the document will probably
be unable to gain traction.
Cheers,
Paul
[1] https://github.com/psztorc/btc-core-capacity-2/blob/master/draft.txt
[2]
https://github.com/psztorc/btc-core-capacity-2/commit/2b4f0ecc9015ee398ce0486ca5c3613e3b929c00
[3] https://bitcoincore.org/en/2015/12/21/capacity-increase/
[4] https://bitcoincore.org/en/2015/12/23/capacity-increases-faq/
On 7/10/2017 12:50 PM, Paul Sztorc wrote:
> 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
>

2023-06-07 18:04:24

- reply

📅 Original date posted:2017-07-11
📝 Original message:On 7/11/2017 7:12 PM, Tao Effect wrote:
> Paul,
>
> There is a difference between replying to an email, and addressing the
> issues that were brought up in it.
>
> I did read your reply, and I chose not to respond to it because it did
> not address anything I said.
In that case you should clarify, which is exactly what you are doing now.
>
> Here's an example:
>
>> It would not be accurate to say that miners have "total" control. Miners
>> do control the destination of withdrawals, but they do not control the
>> withdrawal-duration nor the withdrawal-frequency.
>>
>> So, if miners wish to 'steal' from a sidechain, they _can_ initiate a
>> theft, but they can not change the fact that their malfeasance will be
>> [a] obvious, and [b] on display for a long period of time.
>
> Here, you admit that the security of the sidechains allows miners to
> steal bitcoins, something they cannot do currently.
If that were the case, then DC would need to be a hard fork. It so
happens that it is *not* the case -- if users choose to deposit to an
anyone-can-spend output, then miners can take the Bitcoins, which *is*
something that miners can do currently.
>
> You next tried to equate three different types of theft, what you
> called "Classic Theft", "Channel Theft", and "Drivechain Theft", saying:
>
>> I do not think that any of the three stands out as being categorically
>> worse than the others
>
> To anyone who understands bitcoin, there is a very clear,
> unmistakeable difference between double-spending ("Classic Theft"),
> and *ownership* of the private key controlling the bitcoins.
>
> Similarly, to anyone who understands bitcoin, there is also a very
> clear, unmistakeable difference between censorship ("Channel Theft"),
> and *ownership* of the private key controlling the bitcoins.
I am not sure what you are disagreeing with. The three thefts involve
different attacker resources and behaviors, and in that way they are
different. But in all three cases the user has lost the BTC they would
have otherwise owned, and in that way they are not different.
And users are under no obligation to use DC, just as they are under no
obligation to open a LN channel (or use P2SH, etc).
>
> I am not sure how else to respond to that email, given that none of
> the issues were really addressed.
Other than your complaint about being freely given the option to upgrade
to software which will give you the option to freely opt-in to a
different security model that you can otherwise ignore, feel free to
bring up any other issues you feel need to be addressed.
> Drivechain is an unmistakeable weakening of Bitcoin's security
> guarantees. This you have not denied.
That is false. I do deny it. Per the logic of the soft fork, the
security properties are at best unchanged (as I think almost everyone
else on this list would acknowledge). And even for those users who
opt-in, I feel the risk of theft is low, as I explain in the very
passage you've quoted above.
And please try to avoid going off-topic -- this is supposed to be about
the idea of a new roadmap.
Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170711/4b60c333/attachment.html>

2023-06-07 18:04:21

- reply

📅 Original date posted:2017-07-11
📝 Original message:Greg,
I would summarize your email as stating that: you regret writing the
first email, and regret the fact that it became a roadmap that everyone
signed. And that therefore it is obviously a concept NACK from you.
( That's pretty surprising to me, and I would expect others to find it
surprising as well. And I wonder whether you think we should take the
old one *down*, and why you would allow (?) so many other people to sign
it, etc. But I am not willing to press the issue. Some of your other
comments I also find confusing but there is little to be gained in
clarifying them. )
Generally, I still think that the roadmap was a helpful communication
device, which did more good than harm. And I am interested in hearing
what other people think.
Separately, and very important to me, is that you feel that there are
unresolved objections to drivechain's security model, which you decline
to share with me and/or the list. So I would hope that you instead
choose to share your thoughts (as is, presumably, the purpose of this list).
I will also respond to this:
>>> A fine intention, but I've checked with many of the top contributors
>>> and it sounds like the only regular developer you spoke with was
>>> Luke-Jr. Next time you seek to represent someone you might want to
>>> try talking to them!
>> That is false. I could provide a list of names but I'm really not sure
>> what would be gained as result. You yourself admit that it is an
>> excellent list of research, almost all which you support directly.
>>
>> So I think your only real objection is that I didn't talk to you
>> specifically.
> Come now, this is needlessly insulting. I would have made the same
> comment if you had talked to me because you didn't talk to most/all of
> Matt Corallo, Wladimir, Pieter Wuille, Alex Morcos, etc.... e.g. the
> people doing most of the work of actually building the system. Before
> making that comment I went and checked with people to find out if only
> I was left out. Talking to Adam (who isn't involved in the project)
> and Luke-jr (who is but is well known for frustratingly extreme
> minority positions and also contracts for Blockstream sometimes) isn't
Let me try to explain my point of view. I did speak to several people,
in addition to the two names that I privately volunteered to you when
you asked me in a personal email earlier today. From my point of view
you had done no research (you failed to uncover any additional names),
used the information I volunteered to you against me (in the form of
false characterizations of negligent email writing!), and you also
suggested that, other than yourself and a few others, no one is
qualified even to write a first draft of a summary of present day
activities. This response is typical of the hostile review environment
which has existed in Bitcoin for years (I am more than used to it). If
instead of writing the first draft, I had written nothing, I would be
accused of being the ideas guy and/or "not contributing". You also
(rather rudely), put me in an awkward position, as the people who I
*did* ask now almost certainly prefer that I not reveal their names
(yet, a low name count is held as a strike against my competence).
Such are the perils of posting to bitcoin-dev! Let all be warned! : )
Paul
On 7/11/2017 8:07 PM, Gregory Maxwell wrote:
> On Tue, Jul 11, 2017 at 10:17 PM, Paul Sztorc <truthcoin at gmail.com> wrote:
>> I don't understand this at all. This document attempts to do exactly
>> what its predecessor did -- nothing more or less.
> That might be your impression, then you've misunderstood what I
> intended-- What I wrote was carefully constructed as a personal view
> of how things might work out. It never claimed to be a a project
> roadmap. Though as usual, I work hard to propose things that I believe
> will be successful... and people are free to adopt what they want.
>
> And to the extent that it got taken that way I think it was an error
> and that it has harmed progress in our community; and created more
> confusion about control vs collaboration.
>
> With perfect hindsight I wouldn't have posted it; especially since
> we've learned that the demand for increased capacity from many people
> was potentially less than completely earnest. (The whole, can't double
> capacity until we quadruple it thing...)
>
>> As to your specific complaints, I have addressed both the security model
> and the concept of mining centralization on this list in the recent
> past.
>
> I don't agree that you have; but for the purpose of this thread
> doesn't really matter if I (specifically) do or don't agree. It's an
> objective truth that many people do not yet believe these concerns
> have been addressed.
>
>> I really don't understand what you are disclosing. That Adam asked you
>> for feedback on the draft? And then, in the next sentence, that not
> That Adam asked me to write publish a new "roadmap" for Bitcoin as
> you've done here, with particular features and descriptions, which I
> declined; and explained why I didn't believe that was the right
> approach. And Adam worked with you on the document, and provided
> content for it (which I then recognized in the post).
>
> Set aside what you know to be true for a moment and consider how this
> might look to an outsider who found out about it. It could look a
> like Blockstream was trying to influence the direction of Bitcoin by
> laundering proposals through an apparently unaffiliated third party.
> Doubly so considering who participated in your drafting and who didn't
> (more below).
>
> I don't think in actuality you did anything remotely improper
> (ill-advised, perhaps, since your goal to speak for developers but you
> didn't speak to them, IMO--) but I think transparency is essential to
> avoid any appearance of misconduct.
>
>> But surely you can
>> appreciate how bizarre your position on roadmaps is. What exactly, did
>> you intended to create at [1]? Since it is described explicitly as "the
>> roadmap in Capacity increases for the Bitcoin system", have you been
>> disagreeing with it's characterization as a 'roadmap' this entire time?
>> One wonders why you haven't said anything until now.
> I did--
>
> As Bryan pointed out... with the exception of the intro and end and a
> couple sentences in the middle my entire response to your post, with
> the position on "roadmaps" was written a long time ago, specifically
> to complain about and argue against that particular approach.
>
>> In my first email I list the benefits of having a roadmap. One benefit
>> is that, without one, it is likely that a large majority of outsiders
>> have almost no idea at all what is being worked on, what effect it will
>> have, or when it might be ready, or to whom/what they should turn to for
>> advice on such matters. Do you have a different way of addressing this
>> communication problem?
> I think you may be mistaking a roadmap with "communications"-- people
> taking about research they are exploring is great! and we should have
> more of it. But like with RedHat and kernel features, we can't really
> roadmap things that are unresourced and currently just unimplemented
> exploration or test code-- without seeing things which are more or
> less done the community can't rightfully decide if they'd want to
> support something or not. Perhaps they'll be good things perhaps
> awful-- the devil is in the details, and until an effort is fairly
> mature, you cannot see the details.
>
> There have, for example, been signature aggregation proposals in the
> past that required address reuse (could only aggregate if they're
> reused). I would strongly oppose such a proposal, and I hope everyone
> else here would too. So if I were a third party looking at your
> message, rather than the person who initially proposed the agg sig
> thing you're talking about, I wouldn't know if I could love it or hate
> it yet; and probably couldn't be expected to have much of an opinion
> on it until there is a BIP and/or example implementation.
>
> To the extent that a roadmap differs from communications in general,
> it is in that it also implies things that none of us can promise
> except for our own efforts; Completion of implementations, success of
> experiments, adoption-- basically assuming a level of top down control
> that doesn't exist in a wide public collaboration.
>
> One of the great challenges in our industry is that we don't have
> rings of communication: We don't have much in the way of semi-experts
> to communicate to semi-semi-experts to communicate to media pundits to
> communicate to the unwashed masses-- at each level closing the
> inferential gap and explaining things in terms the audience
> understands. We don't have things like LWN. We'll get there, but it
> it took the Linux world decades to build to what it has now. I think
> various forces in the industry work against us-- e.g. we lose a mot of
> mid tier technical people to the allure of striking it rich printing
> money in their own altcoins.
>
> It might be attractive to try to end-run the slow development
> appropriate web of reliable communications by deploying high authority
> edicts, but it ultimately can't work because it doesn't map to how
> things are accomplished, not in true collaborative open source, and
> certainly not in an effort whos value comes substantially from
> decentralization. Doing so, I fear, creates a false understanding of
> authority.
>
> (It's a common misunderstanding, for example, that people do what I
> want (for example); but in reality, I just try to avoid wasting my
> time advocating things that I don't think other people are already
> going to do; :) otherwise, if _I_ want something done I've got to do
> it myself or horse trade for it, just like anyone else.)
>
> One of the great things about general communications is anyone can do
> it. Of course, unless they're talking about their own work, they
> can't promise any of it will be completely-- but that is always true.
> If someone wants some guarantee about work, they have to be willing
> to get it done themselves (and, of course, if it's a consensus
> feature-- that much is necessary, but still not sufficient to get a
> guarantee).
>
> [from your other reply]
>>> A fine intention, but I've checked with many of the top contributors
>>> and it sounds like the only regular developer you spoke with was
>>> Luke-Jr. Next time you seek to represent someone you might want to
>>> try talking to them!
>> That is false. I could provide a list of names but I'm really not sure
>> what would be gained as result. You yourself admit that it is an
>> excellent list of research, almost all which you support directly.
>>
>> So I think your only real objection is that I didn't talk to you
>> specifically.
> Come now, this is needlessly insulting. I would have made the same
> comment if you had talked to me because you didn't talk to most/all of
> Matt Corallo, Wladimir, Pieter Wuille, Alex Morcos, etc.... e.g. the
> people doing most of the work of actually building the system. Before
> making that comment I went and checked with people to find out if only
> I was left out. Talking to Adam (who isn't involved in the project)
> and Luke-jr (who is but is well known for frustratingly extreme
> minority positions and also contracts for Blockstream sometimes) isn't
> a great approach for the stated goal of speaking for developers!

2023-06-07 18:04:17

- reply

📅 Original date posted:2017-07-11
📝 Original message:On 7/11/2017 6:41 PM, Tao Effect wrote:
> Dear Paul,
>
> Drivechain has several issues that you've acknowledged but have not,
> IMO, adequately (at all really) addressed [1].
I replied to your email at length, at [2]. You should read that email,
and then reply to it with your outstanding objections, if you still have
them (per the usual customs of a mailing list).
[2]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014609.html
> Adopting DC would be an irreversible course of action,
This is false -- it is easily reversible with a second soft fork.
Also, I would say to everyone that, (in my opinion as the OP) this
conversation will go off-topic if it veers exclusively into 'drivechain
review'.
Paul

2023-06-07 18:04:16

- reply

📅 Original date posted:2017-07-11
📝 Original message:Hi Greg,
On 7/11/2017 5:11 PM, Gregory Maxwell wrote:
> I think it's great that people want to experiment with things like
> drivechains/sidechains and what not, but their security model is very
> distinct from Bitcoin's and, given the current highly centralized
> mining ecosystem, arguably not very good. So positioning them as a
> major solution for the Bitcoin project is the wrong way to go. Instead
> we should support people trying cool stuff, at their own risk.
>
> So, given that although the vast majority of the things in the document
> are things I've been supporting for months (Please see Note 1 way down
> at the bottom) I cannot support your document.
Is this the only reason you do not support the document? If so I would
be happy to take out the section, if enough people share such a view.
As to your specific complaints, I have addressed both the security model
and the concept of mining centralization on this list in the recent
past. I would like to hear your responses to my claims, if you are
willing to share them. As for positioning DC as a major solution, it is
a little confusing because Luke-Jr and Adam back seem to feel it is at
least worth discussing on those terms (and I know of no reason why it
would not be discussed on those terms). The peer review here on
[bitcoin-dev] seemed to be moving forward without any serious
objections. And it seems unsportsmanlike for you to object, for reasons
which you keep only to yourself.
> On a more meta-subject, I think grandly stated "top down" roadmaps
> in highly collaborative development are of minimal utility at best
I'm aiming for minimal utility.
> IMO the way to do "roadmaps" in Bitcoin is to roadmap the finalization
> and release process once the basic technology is done; because it's
> only past that point that guarantees can really start being made.
>
> But that isn't what your document does-- it names a lot of things which
> are still various shades of research at this point
I don't understand this at all. This document attempts to do exactly
what its predecessor did -- nothing more or less.
> This was an incredible benefit to our customers, but the only way it was
> possible was because _features_ were not guaranteed in a release.
No one is suggesting that features be guaranteed, either ever or in
releases.
> One of the big screwups with segwit handling was people sticking
> some random unrealistic date on it it which was done AFAIK,
> by well meaning folks who took some random numbers from people
> working on it for when they'd be done with the development-- not the
> testing, not the integration, and certainly not deployment and published
> it as The Date. Then even though the development was actually done
> by them, segwit was portrayed as massively delayed, because what
> matters to the users is deployment-- which we can't control.
I really don't think they are related. For a start, software is almost
always delayed. An obvious second is that this entire scaling
conversation is polarized to the hilt and everyone that can be blamed
for something has been blamed for something.
No one likes to be held to a certain deadline, but this roadmap is just
about producing some clarity for people who do not do this 24/7.
> I see you've done this yourself with signature aggregation, sticking Q4 2016
> right on it, which as far as I can tell is a figure that comes from mars.
I asked Adam Back for it.
> It's also not really appropriate to ask people to sign onto stuff when they
> can't even review it. Perhaps the signature aggregation stuff is insecure,
> patent encumbered, or practically useless... (It won't be but no one could
> tell that from your post; because it doesn't even exist as a concrete proposal)
Again, I think you're missing the point. If there is a problem with SA,
you can just suggest it be removed from the document.
> I think people would rightly protest about a number of these things-- especially
> things like the the agg sigs and tx compaction, "wtf, I've not heard
> of this. Who
> are you to insist this goes into Bitcoin?"
This is a very strange argument. I would consider it a benefit if people
learned from the document, and discovered things that they had not heard
of before.
There is no "insisting" of any kind.
> [ Note 1: I think it is important to disclose that several of the
> items in this list appear to be more or less quoted out of my own
> blockstream-internal descriptions of things we've been working on in
> Bitcoin.
> A while back Adam Back asked me to publish something which contained
> significant chunks of this document more or less verbatim,
He probably showed you an earlier draft. But I wrote almost all of this
myself, and I can only recall 2 or 3 phrases (not even complete
sentences) included from Adam Back. And most of the phrases are
themselves just boring descriptions that I'm sure anyone could write.
Some phrases may have simply been taken from bitcoincore.org or
somewhere similar.
I am not exactly sure what you are insinuating but I encourage you to
clarify it.
> and I
> declined saying that I personally disagree with some of his points and
> didn't think that Blockstream attempting to redirect the Bitcoin
> project (esp towards drivechains) was appropriate-- along with my
> (above) views on roadmaps (which I have included here a private email
> thread on the subject). I feel it's important to disclose this, and
> that the document was not otherwise created with the input of project
> contributors (except Luke-Jr, apparently). I wasn't previously aware
> that Adam had been working with Paul on this, had I been I would have
> also encouraged people to be a little more transparent about it. ]
I really don't understand what you are disclosing. That Adam asked you
for feedback on the draft? And then, in the next sentence, that not
enough experts were asked for feedback on the draft? I'm legitimately
confused by this part.
As I stated, we can remove the drivechain section. But surely you can
appreciate how bizarre your position on roadmaps is. What exactly, did
you intended to create at [1]? Since it is described explicitly as "the
roadmap in Capacity increases for the Bitcoin system", have you been
disagreeing with it's characterization as a 'roadmap' this entire time?
One wonders why you haven't said anything until now.
[1] https://bitcoincore.org/en/2015/12/21/capacity-increase/
In my first email I list the benefits of having a roadmap. One benefit
is that, without one, it is likely that a large majority of outsiders
have almost no idea at all what is being worked on, what effect it will
have, or when it might be ready, or to whom/what they should turn to for
advice on such matters. Do you have a different way of addressing this
communication problem?
Paul

2023-06-07 18:04:14

- reply

📅 Original date posted:2017-07-11
📝 Original message:Hi Chris,
On 7/11/2017 12:03 PM, Chris Stewart wrote:
> Concept ACK.
>
> I think you are overstating the readiness of drivechains though. I
> think the optimistic estimate for drivechains to be ready for bitcoin
> core is a year out from today. More likely the date should be early
> 2018. Still a lot of work to be done! :-)
It depends on interest, I think. What remains to be done is more easily
parallelized, and in some cases (eg smartphone wallets) there are
incentives for private individuals and businesses to hustle their part
out (merely for reasons of competitiveness).
> Also I don't know if I would put a hard fork suggestion in the scaling
> map. If drivechains are successful they should be viewed as the way we
> scale -- not hard forking the protocol. Do you still have capacity
> concerns if drivechains are successful?
I wrote the roadmap to try to be representative of a Core / developer
position. I am philosophically against hard forks, but HFs were in the
end of the previous roadmap so I felt it should stay. And, I felt that
if I decided to unilaterally remove it, it would be perceived as
excessive campaigning for Drivechain. And I also felt that to remove it,
when so many industry members recently put their weight behind a fast
hard fork, would be perceived as a reaction to that attempt, and would
then overwhelm the document with political polarization, for really no
benefit.
Paul
>
> -Chris
>
> On Mon, Jul 10, 2017 at 11:50 AM, Paul Sztorc via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170711/6b8452e0/attachment.html>

2023-06-07 18:04:14

- reply

📅 Original date posted:2017-07-11
📝 Original message:On 7/11/2017 5:31 PM, Gregory Maxwell wrote:
> On Tue, Jul 11, 2017 at 8:18 PM, Paul Sztorc via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> I wrote the roadmap to try to be representative of a Core / developer
>> position.
> A fine intention, but I've checked with many of the top contributors
> and it sounds like the only regular developer you spoke with was
> Luke-Jr. Next time you seek to represent someone you might want to
> try talking to them!
That is false. I could provide a list of names but I'm really not sure
what would be gained as result. You yourself admit that it is an
excellent list of research, almost all which you support directly.
So I think your only real objection is that I didn't talk to you
specifically.
>> I am philosophically against hard forks, but HFs were in the end
>> of the previous roadmap so I felt it should stay. And, I felt that if I
> I think the project is not philosophically against hardforks, at least
> not in an absolute sense.
That is why I included them despite being personally against them.
> But if you were instead to talk about things like fixing timewarp,
> recovering header bits, etc. It would clearly be the other way.
It links to bitcoinhardforkresearch.github.io , which I assumed would
contain the hard fork wishlist somewhere, but perhaps it does not.
> In any case, I think it's safe to say that people's opinions on
> hardforks are complicated. And all the smoke right now with unusually
> poorly executed proposals probably clouds clear thinking.
Yes, of course. But is your position that if something is complicated we
should not try to clarify it?

2023-06-07 18:04:13

- 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

- 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

- 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:54

- reply

📅 Original date posted:2017-07-13
📝 Original message:On 7/13/2017 4:22 PM, Chris Stewart wrote:
> In general though, I'm still unclear of what purpose the 'Ratchet'
> serves. Can you either link to documentation about it or write
> something up quick?
>
> -Chris
In Bitcoin, new coins are held for 100 blocks. One result of this is
that the coins can't be spent until there is at least 100 blocks worth
of evidence that they actually are in the longest chain, and are
unlikely to be orphaned.
In BMM, we are concerned about exactly this. For example, imagine that I
bribe you $20 to find my side:block (and, in that block I earn $20.50
worth of side:BTC tx fees), which you do. But then, moments later, you
(or some other miner) orphans the block! So I don't get my $20.50, but
you still keep my $20!
And yet, we want the mainchain to validate as little as possible about
each sidechain. We want a "light touch". So we force the h* to be
accompanied by the modulus of its sidechain block number (we call it
"BlockMod"). The sidechain has a new rule that requires h* to be
included AND that the BlockMod be accurate, in order for the sidechain
block to meet the "synthetic" difficulty requirement. The mainchain has
a new rule forcing each new BlockMod to be in range [-X000,+1] relative
to the old BlockMod (ie, "no skipping ahead, but you can reorg by
starting a new chain from up to a=-X000 blocks ago" ... likely values of
X might be 2 or 4). And finally, BMM has a new rule that the bribe isn't
paid unless the sidechain block in question has been buried by [for
example] 100 sidechain blocks.
Hope that helps,
Paul

2023-06-07 18:03:53

- reply

📅 Original date posted:2017-07-12
📝 Original message:I still think it may be more inefficient, in equilibrium. (In other
words, in the future steady state of Bitcoin that includes LN or
something LN-like).
Assume there are N sidechains.
In the coinbase version:
1. There is some single event, per N, that causes nodes to notice that a
new sidechain has been created.
2. Per block, there are N hash commitments (32 bytes) and N instances of
the ratchet's block counter (2 bytes).
3. Per block, some node operator _may_ have BMMed the block, and a miner
therefore might want redeem an OP Bribe that pays BTC from a sidechain
node operator to the miner. But they are likely to negotiate the payment
through the Lightning Network (when this is possible).
4. Sidechains running in SPV mode know exactly where to find the
information they need in order to discover the "longest" chain.
In the OP RETURN version:
1. [same] There is some single event, per N, that causes nodes to notice
that a new sidechain has been created.
2. [+30 bytes (+more?)] Per block, there are N hash commitments (32
bytes) and also N prevBlockHashes (32 bytes). Also, to make this
transaction, someone needs to spend something in the UTXO set (or select
no inputs in a kind of 'hollow transaction'), whereas one coinbase will
always exist per block.
3. [same] No need for a new transaction.
4. [same?] Due to Rusty's soft fork rule of only one h* per sidechain
per block, sidechains need just a merkle tree path, but they don't
necessarily know where it is. They must store extra [?] data to help
them find the data's location?
On 7/12/2017 2:02 PM, Chris Stewart via bitcoin-dev wrote:
> Hi Russell/ZmnSCPxj,
>
> I think you guys are right. The only problem I can see with it is
> replaceability of the bribe transaction. If the 'Bribe' is the fee on
> the transaction it isn't clear to me what the best way to
> replace/remove it is.
I think that that is the purpose of Rusty's soft fork rule about only
including one per sidechain -- miners would have one "slot" per
sidechain, and they would therefore have an incentive to make the slot
count, and would be only selecting the highest fee txn to fill each slot.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170712/589abaa0/attachment.html>

2023-06-07 18:03:52

- reply

📅 Original date posted:2017-07-12
📝 Original message:On 7/12/2017 4:50 AM, ZmnSCPxj wrote:
>
> >>In my scheme, if you read carefully through the pseudocode, a block
> list node is valid only if its block is valid.
> >
> >It seems this is a contradiction against the "blind" part of blind
> merge mining. How can a bitcoin blockchain node enforce this without
> tracking the sidechain?
>
> From:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014668.html
> >>>>2. When a sidechain-node wants to know the consensus, it downloads
> mainchain-blocks and looks for OP_RETURN's.
> >>>>2.1. Starting with its genesis cons-pair hash (equivalent to the
> empty list) as the current cons-pair, it scans each OP_RETURN transaction.
> >>>>2.1.1. If an OP_RETURN is 64-byte and has the parent cons-pair
> equal to the current cons-pair, look for the side block indicated and
> confirm its correctness. If correct, update the current cons-pair for
> the hash of the OP_RETURN data.
> >>>>2.2. When reaching the latest mainchain block, the current
> cons-pair is now the sidecoin/altcoin latest block.
> >>>>2.3. Note that if multiple OP_RETURN in a block match the current
> cons-pair, the first one is considered the correct chain. This
> property means that the sidechain/altchain can only have a chainsplit
> if the mainchain has a chainsplit.
>
> It's the sidechain node which needs to learn about the sidechain
> blockchain anyway. So it's the one that does the checking of this.
>
> For that matter, a mainchain miner can be bribed to commit to a random
> number rather than a valid h* block, and it will still lead all the
> sidechain nodes on a random chase to look for the indicated block.
I do agree with this description. And I am not exactly comfortable with
it, but theoretically the random chase would serve no direct benefit to
any attacker (and thus be a ~purposeless use of attacker's money), and
empirically I do not recall anyone complaining about this happening in
Namecoin. And I think it is generally agreed that low-conf transactions
are of categorically lower reliability -- and therefore that we are
relatively less interested in taking care of users who want the
blockchain to provide them with...immediate gratification (for lack of a
better term).
> >I'll follow your discussion with Paul about sidechain reorgs, but I
> think his proposal is more desirable -- it follows what actually
> happens in the bitcoin mining process where we *can* have chain splits
> when
> >miners simultaneously find a block. Other miners will pick one of the
> two blocks to mine on top of and eventually one chain will become
> longer than the other. Therefore that chain will have it's block's
> >orphaned and the miners/nodes following the dead chain will reorg on
> top of the longest chain.
>
> In this paper:
> http://diyhpl.us/~bryan/papers2/bitcoin/On%20the%20instability%20of%20Bitcoin%20without%20the%20block%20reward%20-%202016.pdf
> <http://diyhpl.us/%7Ebryan/papers2/bitcoin/On%20the%20instability%20of%20Bitcoin%20without%20the%20block%20reward%20-%202016.pdf>
>
> As far as I understood that paper, it means that if the block reward
> no longer exists, miners can profitably attempt to undercut any full
> blocks.
>
> Sidechains do not have block rewards (unless the sidechain issues its
> own asset type that is separate from and not convertible to mainchain
> bitcoins).
>
> Thus, to protect against undercutting attacks in the sidechain, we
> would need to ensure that the sidechain cannot be reorged without the
> mainchain (which currently still has a block reward) being reorged.
>
> At least, this is my consideration. Perhaps the paper is wrong?
Yes, it is a valid concern. I'm glad you brought this up. My view is
that there will be no undercutting attempts in the future, if Bitcoin is
popular enough and transactions are constantly arriving.
In short, the reason I feel that way is because miners will be both [1]
willing and [2] able, to maximize their fee income by imposing a
blocksize limit on themselves. They would do this by orphaning
non-compliants -- this would be something softfork-esque, but not
necessarily enforced by non-mining nodes as it is limited to miner
tx-acceptance policy.
Here is a link to a presentation of my thoughts on the issue:
https://www.youtube.com/watch?v=YErLEuOi3xU&list=PLw8-6ARlyVciNjgS_NFhAu-qt7HPf_dtg&index=4
As I say there, I believe that miners currently have no significant
reason to fee-maximize today, which is why we haven't seen this
behavior. (Also, someone would need to write the fee-maximization code
for this, and that not only would take time, but it would require a
person with a very complex intersection of skills.)
The paper you mention was written 1.5 months after my presentation was
recorded. My conclusion contradicts the first sentence of the last
paragraph of "3.1 Model of the system" which reads: "We also assume that
miners always have space to include all available transactions." In my
model miners do NOT always (or, really, ever) have space to include all
available transactions. And miners are happy that they do not, because
all of them make more total money as a result (both per block and overall).
I think the arguments of the presentation were original, so I would be
grateful to you if you offered me your thoughts on it.
> In any case, let me propose actual improvements to the OP_BRIBEVERIFY
> proposal:
>
> 1. Remove the necessity of coinbase commitments. The miner commits
> to the sidechain_id and h* in the transaction that pays the
> OP_BRIBEVERIFY anyway. That way the h* commitment occurs only once in
> the block, in the transaction that does the OP_BRIBEVERIFY. In
> addition, there is no need to impose particular ordering on the
> coinbase outputs, which would be problematic as pointed out by others,
> for example if the miner is interested only in merge mining for
> sidechain id #35 and nobody else.
I don't understand the word "anyway" in the second sentence. Is that a
summary of my proposal, or an assertion of yours. Because as it stands,
the bribe part is quite optional -- miners could just mine both chains
themselves, and then they would know which h* to include, paying
themselves the sidechain's tx fees. (Of course, under what you propose
here, miners could also mine it themselves, by placing it in an
OP_BRIBEVERIFY). However, if it is limited to a coinbase, then there is
at most only 1 hash to process every 10 minutes, which I think is desirable.
I like your idea as it is simpler. But a second concern I have is that
if a sidechain user wants to use SPV mode, the software will want to
know exactly where to find the sidechain headers. If they are always in
a known part of the coinbase, then the spv sidechain wallet knows where
to look.
Re: impose ordering on coinbase outputs, what do you think of a scheme
which searches index 1 for an OP RETURN, and if it finds something it
interprets that as the root hash of merkle tree of merged mined
sidechain h*'s ? If it doesn't find a hash commitment in index 1 it just
assumes that no sidechains were mined in this ~10 minute period.
> 2. When verifying a block, keep a set of sidechain ID's. When
> processing a transaction in that block with OP_BRIBEVERIFY, check if
> the sidechain ID is in that set. If not in that set, add it to that
> set and continue script processing. If already in the set, fail the
> script processing. This ensures that at most one OP_BRIBEVERIFY
> exists for each sidechain_id in a mainchain block.
>
> 3. Don't number sidechain_id from 0, 1, 2, 3..., because people will
> fight over the small numbers. Instead identify sidechains by, for
> example, the hash of their names or the hash of their genesis block or
> whatever. This allows true permissionless creation of sidechains,
> without some authority existing that centrally allocates sidechain ID's.
I am actually not in favor of permiessionless creation of sidechains,
because the sidechains can interfere with each other to a degree that
impacts their usefulness. We do not allow "permissionless creation of
transactions", because we do not allow invalid or double-spent
transactions. I feel the same logic should apply to the chains themselves.
Another youtube presenation about this:
https://www.youtube.com/watch?v=xGu0o8HH10U&list=PLw8-6ARlyVciMH79ZyLOpImsMug3LgNc4&index=1
(Much shorter) written post: http://www.truthcoin.info/blog/wise-contracts/
That said, I am fully in favor of forcing the sidechain's permanent
deposit address to be equal to some deterministic function of the sha256
hash of its version 0.1 release.
Paul

2023-06-07 18:03:50

- reply

📅 Original date posted:2017-07-02
📝 Original message:Hi,
Sorry for the delay, I overlooked this email until now. I see that Chris
and CryptAxe both answered but I will also answer, because the message
was addressed to me.
On 6/30/2017 12:00 AM, ZmnSCPxj wrote:
> >Your way is actually very similar to mine. Mine _forces_ the bribe to be
> >in the earliest txn (the coinbase) and to only occur once. Yours doesn"t
> >do anything to refund the briber, if the sidechain (but not the
> >mainchain) reorganizes (as it can easily do, if an older sidechain
> >parent is extended while the mainchain proceeds normally). This creates
> >additional risk.
>
> I don't understand this part. In my scheme, a sidechain cannot
> reorganize unless the mainchain reorganizes, since the consensus loop
> only cares about matching the current block; it ignores splits and
> does not consider them valid.
If I've understood you correctly, you have said that each OP Return
links the (ex)-latest block to a brand new block, and that whichever
message of this kind comes first (in the mainchain) wins and the rest
are discarded.
So what if I had a sidechain represented by a jumble of capital letters,
discarded entries as lowercase letters.
Mainchain Block #200001: [0 --> Q], [0 -->v], [0 -->s], [0 -->b],
Mainchain Block #200002: [Q --> H], [Q --> z],
Mainchain Block #200003: [H --> F]
Mainchain Block #200004: [F --> J], [F -->w]
Mainchain Block #200005: [H --> P], [J -->x]
Mainchain Block #200006: [P --> D]
Isn't the chain {{ Q --> H --> F --> J }} now starting to reorg, with a
competing chain {{ Q --> H --> P --> D }} ?
> But I suppose you are considering something like the Ethereum
> mutability feature, which I do not think is something you would want
> in a sidechain.
What I do want to do, is retain the existing model to some extent.
Specifically, to the degree where sidechains could salvage some bad
situations (eg value overflow incident, or March 2013 incident).
> >I think mine is also much more space-efficient. Even if ours each had
> >exactly one h* per sidechain per block, it seems that I only require one
> >hash to be communicated (plus an indicator byte, and a ~2 byte counter
> >for the ratchet), whereas you require two. Since its overhead per
> >sidechain per block, it actually might really add up.
>
> Do you not provide a single sidechain's h* twice in the block? Once
> in the coinbase and once in the briber's separate transaction?
That is a good point. Technically, we do include it twice, but the
second instance (briber-transaction) can be "shuffled" out if the
counterparties are part of the same Lightning Network (which I expect to
the be the case, in equilibrium).
>
> In my scheme at least there is no indicator byte -- the "previous
> block" hash is the indicator of which sidechain it is extending. From
> your other emails on this list, it seems the ratchet is for
> withdrawals from sidechain to mainchain? If so, should it not only
> appear in only some of the sidechains (the ones which are currently
> doing some withdrawal?)?
No, sorry. There are many tangled issues (Drivechain (total system);
side-to-main withdrawals (OP CountACKs); individual Drivechains
themselves; Blind Merged Mining (OP BribeVerify)). The ratchet is not
about withdrawals, it is exclusively about Blind Merged Mining, and
making a better OP BribeVerify that offers better guarantees to both sides.
Paul

2023-06-07 18:03:41

- reply

📅 Original date posted:2017-06-28
📝 Original message:Hi ZmnSCPxj,
It seems that, in your version, the "bribers" would react to the scheme
in inefficient ways, particularly when the mainchain's tx-fee-rate (ie
fee per Kb) is low.
In short, there would be many bribe-attempts (each of which would take
up space in mainchain blocks), almost all of which would be unsuccessful.
In turn, miners would likely react to this, and try to improve the state
of affairs by offering users the privilege of occupying transaction slot
#2 (ie, the one right after the coinbase). Users would need to trust
miners for this, which introduces a cost friction which is pure
deadweight loss. And, it might be easier for larger/older miners to be
trustworthy than smaller/newer ones.
Your way is actually very similar to mine. Mine _forces_ the bribe to be
in the earliest txn (the coinbase) and to only occur once. Yours doesn't
do anything to refund the briber, if the sidechain (but not the
mainchain) reorganizes (as it can easily do, if an older sidechain
parent is extended while the mainchain proceeds normally). This creates
additional risk.
I think mine is also much more space-efficient. Even if ours each had
exactly one h* per sidechain per block, it seems that I only require one
hash to be communicated (plus an indicator byte, and a ~2 byte counter
for the ratchet), whereas you require two. Since its overhead per
sidechain per block, it actually might really add up.
Thanks,
Paul
On 6/28/2017 4:26 AM, ZmnSCPxj via bitcoin-dev wrote:
> Good morning.
>
> I still do not see what this does that cannot be done by:
>
> OP_RETURN <sidechain-id> <sidechain-block-id>
>
> A transaction with such an output would allow sidechain-miners to bribe
> mainchain-miners by paying a transaction fee if the transaction
> containing this OP_RETURN is included in a block and committed to by a
> mainchain-miner in the Merkle tree root.
>
> It would not require a softfork.
>
> --
>
> I have an alternate proposal that sidechains and altcoins that want to
> do "blinded" merge mining can use without a softfork:
>
> 1. Encode a block header as a simple cons-pair, with the head as the
> block and the tail as the parent cons-pair.
> 1.1. This can be encoded as a 32-byte hash of the block including its
> header, and the 32-byte hash of the parent cons-pair.
> 1.2. This is now the actual "chain" in the sidecoin/altcoin blockchain.
> 2. When a sidechain-node wants to know the consensus, it downloads
> mainchain-blocks and looks for OP_RETURN's.
> 2.1. Starting with its genesis cons-pair hash (equivalent to the empty
> list) as the current cons-pair, it scans each OP_RETURN transaction.
> 2.1.1. If an OP_RETURN is 64-byte and has the parent cons-pair equal to
> the current cons-pair, look for the side block indicated and confirm its
> correctness. If correct, update the current cons-pair for the hash of
> the OP_RETURN data.
> 2.2. When reaching the latest mainchain block, the current cons-pair is
> now the sidecoin/altcoin latest block.
> 2.3. Note that if multiple OP_RETURN in a block match the current
> cons-pair, the first one is considered the correct chain. This property
> means that the sidechain/altchain can only have a chainsplit if the
> mainchain has a chainsplit.
> 3. When a sidechain-miner wants to create a side-block, it generates a
> new cons-pair and creates an OP_RETURN transaction for it, paying a
> mainchain-miner to include it in the next mainchain-block.
> 3.1. The sidechain-miner risks that its competitors will outbid it and
> get its OP_RETURN earlier in a mainchain-block (or earlier in the order
> of transactions). It can mitigate this risk by updating itself to
> become a mainchain-miner, it can then keep its OP_RETURN transaction
> private and put it earlier in the block, ensuring it will "win" the
> sidechain-consensus if it wins the mainchain-consensus.
>
> Regards,
> ZmnSCPxj
>
> -------- Original Message --------
> Subject: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind
> Merge Mined drivechains
> Local Time: June 28, 2017 8:37 AM
> UTC Time: June 28, 2017 12:37 AM
> From: bitcoin-dev at lists.linuxfoundation.org
> To: Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org>
>
> <pre>
> BIP: <BIP number>
> Layer: Consensus (Soft fork)
> Title: OP_BRIBEVERIFY
> Author: Chris Stewart <chris at suredbits.com>
> Status: Draft
> Type: Standards Track
> Created: 2017-06-27
> </pre>
>
>
> ==Abstract==
>
> This BIP describes a new opcode, OP_BRIBEVERIFY, for the Bitcoin
> scripting system that allows for a user to bribe a miner to include a hash
> in the coinbase transaction's output.
>
>
> ==Summary==
>
> 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.
>
> ==Motivation==
>
> The current political climate of bitcoin is extremely contentious. Many
> community members
> have different visions of what bitcoin is. This op code is meant to
> enable [http://www.truthcoin.info/blog/blind-merged-mining/ Blind Merge
> Mining].
> This enables sidechains in Bitcoin. With OP_BRIBEVERIFY, sidechains
> miners can
> bribe bitcoin miners to to include their block hash in the bitcoin
> blockchain. If their block
> is included in the coinbase transaction's vout, it is assumed that block
> is a mined block on the sidechain.
>
> This will allow various factions of the community to realize their
> vision on their own separate
> blockchain that is interoperable with the bitcoin blockchain. This
> allows those factions to use
> bitcoin as a 'reserve currency' for their own network.
>
>
> ===Commitment Structure===
>
> A new block rule is added which requires that the miner's coinbase
> reward be at index 0 in the coinbase transaction's output vector.
>
> It also fixes the witness commitment output to be at index 1 of the
> coinbase transaction's output vector.
>
> This is needed so we can reliably tell what vout corresponds to what
> drivechain. For instance, the mimblewimble sidechain
> could correspond to index 2 of the vector outputs on the coinbase
> transaction.
>
> The commitment is recorded in a <code>scriptPubKey</code> of the
> coinbase transaction. It must be at least 34 bytes in size
> 1-byte - OP_RETURN (0x6a)
> 1-byte - Push the following 32 bytes (0x20)
> 32-byte - block hash
>
> the 35th byte and onward have no consensus meaning.
>
> ===OP_BRIBEVERIFY op code===
>
> This op code reads two arguments from the stack. The stack top is
> expected to be a sidechain id for which this user attempting to blind
> merge mine for.
> The next element on the stack is expected to be a block hash. This op
> code looks into the coinbase transaction's output vector at the given
> index (which is derived from the sidechain id) and checks
> to see if the hash in the block matches the hash inside of the
> BRIBEVERIFY program. If the hashes match, the OP_BRIBEVERIFY acts as an
> OP_NOP. If the
> comparison between the two hashes fail, the script fails.
>
> ===BRIBEVERIFY program===
>
> A standard BRIBEVERIFY program has the format:
> 1-byte - Push the following 32 bytes (0x20)
> 32-byte - block hash
> 1 byte - Push operation? (needed if number can't be encoded as OP_0 -
> OP_16)
> 1 byte - sidechain id
> 1 byte - OP_BRIBEVERIFY op code
>
> ==Detailed Specification==
>
> Refer to the reference implementation, reproduced below, for the precise
> semantics and detailed rationale for those semantics.
>
>
> case OP_NOP4:
> {
> //format: block_hash sidechain_id OP_BRIBEVERIFY
> if (!(flags & SCRIPT_VERIFY_BRIBEVERIFY)) {
> // not enabled; treat as a NOP4
> if (flags & SCRIPT_VERIFY_DISCOURAGE_UPGRADABLE_NOPS) {
> return set_error(serror, SCRIPT_ERR_DISCOURAGE_UPGRADABLE_NOPS);
> }
> break;
> }
>
> if (stack.size() < 2)
> return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);
>
> const CScriptNum scriptNumSidechainId(stacktop(-1),fRequireMinimal);
> uint8_t nSidechainId;
> if (!checker.CheckSidechainId(scriptNumSidechainId,nSidechainId)) {
> return set_error(serror, SCRIPT_ERR_UNKNOWN_SIDECHAIN);
> }
>
> // Check block hash
> bool fHashCritical =
> checker.CheckCriticalHash(stacktop(-2),nSidechainId);
> if (!fHashCritical) {
> return set_error(serror, SCRIPT_ERR_UNSATISFIED_BRIBE);
> }
> break;
> }
>
>
>
> https://github.com/Christewart/bitcoin/blob/94b6f33f2278c42d4d8758a3c8ffe2078e4ec933/src/script/interpreter.cpp#L427
>
> https://github.com/drivechain-project/bitcoin/pull/13
>
> ==Deployment==
>
> TODO
>
> ==Credits==
>
> Credit to Paul Sztorc for the original idea of Blind Merge Mined sidechains.
>
> Credit to CryptAxe for writing the foundational layer of software for
> drivechains so I could implement OP_BRIBEVERIFY.
>
>
> ==References==
>
> Blind Merge Mined Sidechains -
> http://www.truthcoin.info/blog/blind-merged-mining/
> Mailing list discussion -
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014408.html
>
> ==Copyright==
>
> This document 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 18:03:41

- 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 18:03:40

- reply

📅 Original date posted:2017-06-28
📝 Original message:Chris/Greg,
For pending withdrawals (side-to-main transfers), all of the data is
stored in a teeny tiny extension block which contains all the drivechain
data (which we called "MinerDB"). And miners were supposed to commit to
this and put it in the coinbase in some locate-able place (for example,
index 1).
I had assumed that this would go the same for BMM, since it is all
drivechain-themed. Thus, all drivechains, and all drivechain-stuff (BMM
included), would claim one output index.
Moreover, while DC claims an output "slot", the claim doesn't need to be
permanent...if the BTC-value of the relevant output is not equal to
zero, the BMM code could just ignore it. The sidechains would each
assume that no sidechain block was merged-mined in this period. And DC
would assume that no forward progress was made on any side-to-main
transfers (ie, that everyone "abstained").
Perhaps that addresses Greg's third, first, and second concerns.
I am having some trouble understanding concern #4. I think you mean to
say that the output coins of a transaction which is encumbered by OP
BribeVerify are different from other coins. Indeed they are, and coins
locked by OP BribeVerify cannot be moved until their associated
sidechain header ("h*") is ~100 blocks deep in the sidechain (hence the
earlier conversation about the "ratchet", which attempts to measure this).
The timeline that CryptAxe and I discussed, as I last remember it, is that:
0. (setup) The sidechain node is run by a briber, and this briber
constructs a sidechain block paying himself all the fees. These fees
total q=4 BTC.
1. Negotiations happen out of bound, between Briber and all miners.
(still setting up) Each new transaction the Briber makes, he chooses a
completely new h* (which is trivial for him to do by incrementing a
nonce/anything), and he may as well also fund each of these txns with
the same unspent output (owned by him). This prevents a miner from
annoying the Briber by including many ultimately-invalid transactions.
2. Miner1 includes h* in the coinbase of today's block thus BMMing a
sidechain block today, he also includes the transaction he just
negotiated with the Briber (call it, "tx1"). This tx1 is one where
Briber pays z=(q-0.001) to an op_bribe script that will eventually pay z
BTC to Bitcoin address M owned by "miner1".
3. After ~123 blocks, the ratchet (on mainchain) indicates that the
sidechain headers have advanced sequentially by x=100 places. This
allows miner1 to spend from tx1 to address M.
3. OR, after ~250 blocks, the second timing threshold is reached*, and
the Briber can spend from his script back to an address he controls
(also predefined in steps 1 and 2).
*This is the dual-threshold time-locking technique that the LN uses to
prove a negative.
The second timelock setup is required because it is possible that miner
will earnestly BMM a sidechain block, but then reorg such that this
block is orphaned out of the longest (side)chain. In this case, the
Briber doesn't get paid his tx-fees, so he is entitled to a refund.
So, maybe this BIP will need to be edited a little. : ) Nonetheless, I'm
glad Chris is taking the initiative and doing this work. And I'm sorry
if the documentation has shifted too much. At the bottom of the spec
blog post there are some notes, but they probably aren't very helpful.
On 6/28/2017 12:07 AM, Gregory Maxwell via bitcoin-dev wrote:
> On Wed, Jun 28, 2017 at 12:37 AM, Chris Stewart via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> A new block rule is added which requires that the miner's coinbase reward be
>> at index 0 in the coinbase transaction's output vector.
>
> This is an absurd restriction-- I hope it was not your intent to
> directly ban P2Pool and probably any other form of decentralized or
> less centralized mining pooling... but thats what doing that does.
>
>> It also fixes the witness commitment output to be at index 1 of the coinbase transaction's output vector.
>
> This removes important flexibility that was intentionally preserved.
> What happens when an additional commitment is needed for bitcoin?
> must some sidechain be irreparably destroyed? looks like it in your
> proposal.
>
>> For instance, the mimblewimble sidechain could correspond to index 2 of the vector outputs on the coinbase transaction.
>
> And what happens if index 1 isn't present? if index 35 is used must
> there be 34 dummy outputs?
>
>> This op code looks into the coinbase transaction's output vector at the given index (which is derived from the sidechain id) and checks to see if the hash in the block matches the hash inside of the BRIBEVERIFY progra
>
> This is not monotone/reorg safe. It means that the output coins (if
> any) are not equivalently fungible with other bitcoins (for, e.g. 100
> blocks) because if there is a reorg this transaction cannot be
> restored to the chain. It's also impure and not compatible with
> caching, which would be unfortunate and slow block propagation.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

2023-06-07 18:03:04

- reply

📅 Original date posted:2017-06-23
📝 Original message:On 6/23/2017 10:19 AM, Erik Aronesty wrote:
> > They would certainly not be cheap, because they are relatively more expensive due to the
> extra depreciation cost.
>
> If you design the inflation schedule correctly, it should be balance
> transaction costs *precisely*.
You have not explained how your scheme would cause a relative decrease
in transaction costs. The way I see it, tx costs would be exactly the
same, so it would in fact be impossible to design an inflation schedule
to "balance" these costs (other than inflation of zero as I suggest).
>
> > I don't think that blind merged mining messes with the main chain's
> incentive structure
>
> Miners who are able to deal with the bandwidth caused by drivechain
> coffee transactions
There is no additional bandwidth requirement. That is the point of BMM.
They do not even need to run a sidechain node (to be paid just as much
as if they had).
--Paul
>
> On Thu, Jun 22, 2017 at 4:30 PM, Paul Sztorc <truthcoin at gmail.com
> <mailto:truthcoin at gmail.com>> wrote:
>
> Responses inline.
>
> On 6/22/2017 9:45 AM, Erik Aronesty wrote:
>> Users would tolerate depreciation because the intention is to
>> have a cheap way of transacting using a two-way pegged chain that
>> isn't controlled by miners. Who cares about some minor
>> depreciation when the purpose of the chain is to do cheap secure
>> transactions forever?
>
> Thus far you've claimed that these transactions would be "cheap",
> "[not] controlled by miners", and "secure".
>
> They would certainly not be cheap, because they are relatively
> more expensive due to the extra depreciation cost.
>
> I also doubt that they would be free of control by miners. 51%
> hashrate can always filter out any message they want from anywhere.
>
> For the same reason, I don't understand why they would be any more
> or less secure.
>
> So I think your way is just a more expensive way of accomplishing
> basically the same result.
>
>>
>> Add in UTXO commitments and you've got a system that is cheap and
>> secure-enough for transfer. storage and accumulation of a
>> ledger... before moving in to the main chain.
>
> As I posted to bitcoin-discuss last week, I support UTXO
> commitments for sidechains.
>
>> Seems better to me than messing with the main chain's incentive
>> structure via merged mining.
>
> I don't think that blind merged mining messes with the main
> chain's incentive structure. Miners are free to ignore the
> sidechain (and yet still get paid the same as other miners), as
> are all mainchain users.
>
> Paul
>>
>> On Thu, Jun 22, 2017 at 9:27 AM, Paul Sztorc <truthcoin at gmail.com
>> <mailto:truthcoin at gmail.com>> wrote:
>>
>> Hi Erik,
>>
>> I don't think that your design is competitive. Why would
>> users tolerate a depreciation of X% per year, when there are
>> alternatives which do not require such depreciation? It seems
>> to me that none would.
>>
>> Paul
>>
>> On 6/20/2017 9:38 AM, Erik Aronesty wrote:
>>> - a proof-of-burn sidechain is the ultimate two-way peg.
>>> you have to burn bitcoin *or* side-chain tokens to mine the
>>> side chain. the size of the burn is the degree of
>>> security. i actually wrote code to do randomized blind
>>> burns where you have a poisson distribution
>>> (non-deterministic selected burn). there is no way to
>>> game it... it's very similar to algorand - but it uses burns
>>> instead of staking
>>>
>>> - you can then have a secure sidechain that issues a mining
>>> reward in sidechain tokens, which can be aggrregated and
>>> redeemed for bitcoins. the result of this is that any
>>> bitcoins held in the sidechain depreciate in value at a rate
>>> of X% per year. this deflation rate pays for increased
>>> security
>>>
>>> - logically this functions like an alt coin, with high
>>> inflation and cheap transactions. but the altcoin is
>>> pegged to bitcoin's price because of the pool of unredeemed
>>> bitcoins held within the side chain.
>>>
>>>
>>>
>>> On Tue, Jun 20, 2017 at 7:54 AM, Paul Sztorc
>>> <truthcoin at gmail.com <mailto:truthcoin at gmail.com>> wrote:
>>>
>>> Hi Erik,
>>>
>>> As you know:
>>>
>>> 1. If a sidechain is merged mined it basically grows out
>>> of the existing Bitcoin mining network. If it has a
>>> different PoW algorithm it is a new mining network.
>>> 2. The security (ie, hashrate) of any mining network
>>> would be determined by the total economic value of the
>>> block. In Bitcoin this is (subsidy+tx_fees)*price, but
>>> since a sidechain cannot issue new tokens it would only
>>> be (tx_fees)*price.
>>>
>>> Unfortunately the two have a nasty correlation which can
>>> lead to a disastrous self-fulfilling prophecy: users
>>> will avoid a network that is too insecure; and if users
>>> avoid using a network, they will stop paying txn fees
>>> and so the quantity (tx_fees)*price falls toward zero,
>>> erasing the network's security. So it is quite
>>> problematic and I recommend just biting the bullet and
>>> going with merged mining instead.
>>>
>>> And, the point may be moot. Bitcoin miners may decide
>>> that, given their expertise in seeking out cheap sources
>>> of power/cooling, they might as well mine both/all
>>> chains. So your suggestion may not achieve your desired
>>> result (and would, meanwhile, consume more of the
>>> economy's resources -- some of these would not
>>> contribute even to a higher hashrate).
>>>
>>> Paul
>>>
>>>
>>>
>>>
>>> On 6/19/2017 1:11 PM, Erik Aronesty wrote:
>>>> It would be nice to be able to enforce that a
>>>> drivechain *not* have the same POW as bitcoin.
>>>>
>>>> I suspect this is the only way to be sure that a
>>>> drivechain doesn't destabilize the main chain and push
>>>> more power to miners that already have too much power.
>>>>
>>>>
>>>
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170623/f6a7f0fc/attachment.html>

2023-06-07 18:03:02

- reply

📅 Original date posted:2017-06-22
📝 Original message:Responses inline.
On 6/22/2017 9:45 AM, Erik Aronesty wrote:
> Users would tolerate depreciation because the intention is to have a
> cheap way of transacting using a two-way pegged chain that isn't
> controlled by miners. Who cares about some minor depreciation when
> the purpose of the chain is to do cheap secure transactions forever?
Thus far you've claimed that these transactions would be "cheap", "[not]
controlled by miners", and "secure".
They would certainly not be cheap, because they are relatively more
expensive due to the extra depreciation cost.
I also doubt that they would be free of control by miners. 51% hashrate
can always filter out any message they want from anywhere.
For the same reason, I don't understand why they would be any more or
less secure.
So I think your way is just a more expensive way of accomplishing
basically the same result.
>
> Add in UTXO commitments and you've got a system that is cheap and
> secure-enough for transfer. storage and accumulation of a ledger...
> before moving in to the main chain.
As I posted to bitcoin-discuss last week, I support UTXO commitments for
sidechains.
> Seems better to me than messing with the main chain's incentive
> structure via merged mining.
I don't think that blind merged mining messes with the main chain's
incentive structure. Miners are free to ignore the sidechain (and yet
still get paid the same as other miners), as are all mainchain users.
Paul
>
> On Thu, Jun 22, 2017 at 9:27 AM, Paul Sztorc <truthcoin at gmail.com
> <mailto:truthcoin at gmail.com>> wrote:
>
> Hi Erik,
>
> I don't think that your design is competitive. Why would users
> tolerate a depreciation of X% per year, when there are
> alternatives which do not require such depreciation? It seems to
> me that none would.
>
> Paul
>
> On 6/20/2017 9:38 AM, Erik Aronesty wrote:
>> - a proof-of-burn sidechain is the ultimate two-way peg. you
>> have to burn bitcoin *or* side-chain tokens to mine the side
>> chain. the size of the burn is the degree of security. i
>> actually wrote code to do randomized blind burns where you have a
>> poisson distribution (non-deterministic selected burn). there
>> is no way to game it... it's very similar to algorand - but it
>> uses burns instead of staking
>>
>> - you can then have a secure sidechain that issues a mining
>> reward in sidechain tokens, which can be aggrregated and redeemed
>> for bitcoins. the result of this is that any bitcoins held in
>> the sidechain depreciate in value at a rate of X% per year.
>> this deflation rate pays for increased security
>>
>> - logically this functions like an alt coin, with high inflation
>> and cheap transactions. but the altcoin is pegged to bitcoin's
>> price because of the pool of unredeemed bitcoins held within the
>> side chain.
>>
>>
>>
>> On Tue, Jun 20, 2017 at 7:54 AM, Paul Sztorc <truthcoin at gmail.com
>> <mailto:truthcoin at gmail.com>> wrote:
>>
>> Hi Erik,
>>
>> As you know:
>>
>> 1. If a sidechain is merged mined it basically grows out of
>> the existing Bitcoin mining network. If it has a different
>> PoW algorithm it is a new mining network.
>> 2. The security (ie, hashrate) of any mining network would be
>> determined by the total economic value of the block. In
>> Bitcoin this is (subsidy+tx_fees)*price, but since a
>> sidechain cannot issue new tokens it would only be
>> (tx_fees)*price.
>>
>> Unfortunately the two have a nasty correlation which can lead
>> to a disastrous self-fulfilling prophecy: users will avoid a
>> network that is too insecure; and if users avoid using a
>> network, they will stop paying txn fees and so the quantity
>> (tx_fees)*price falls toward zero, erasing the network's
>> security. So it is quite problematic and I recommend just
>> biting the bullet and going with merged mining instead.
>>
>> And, the point may be moot. Bitcoin miners may decide that,
>> given their expertise in seeking out cheap sources of
>> power/cooling, they might as well mine both/all chains. So
>> your suggestion may not achieve your desired result (and
>> would, meanwhile, consume more of the economy's resources --
>> some of these would not contribute even to a higher hashrate).
>>
>> Paul
>>
>>
>>
>>
>> On 6/19/2017 1:11 PM, Erik Aronesty wrote:
>>> It would be nice to be able to enforce that a drivechain
>>> *not* have the same POW as bitcoin.
>>>
>>> I suspect this is the only way to be sure that a drivechain
>>> doesn't destabilize the main chain and push more power to
>>> miners that already have too much power.
>>>
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170622/cb6a08cf/attachment-0001.html>

2023-06-07 18:03:01

- reply

📅 Original date posted:2017-06-22
📝 Original message:Hi Erik,
I don't think that your design is competitive. Why would users tolerate
a depreciation of X% per year, when there are alternatives which do not
require such depreciation? It seems to me that none would.
Paul
On 6/20/2017 9:38 AM, Erik Aronesty wrote:
> - a proof-of-burn sidechain is the ultimate two-way peg. you have to
> burn bitcoin *or* side-chain tokens to mine the side chain. the size
> of the burn is the degree of security. i actually wrote code to do
> randomized blind burns where you have a poisson distribution
> (non-deterministic selected burn). there is no way to game it...
> it's very similar to algorand - but it uses burns instead of staking
>
> - you can then have a secure sidechain that issues a mining reward in
> sidechain tokens, which can be aggrregated and redeemed for bitcoins.
> the result of this is that any bitcoins held in the sidechain
> depreciate in value at a rate of X% per year. this deflation rate
> pays for increased security
>
> - logically this functions like an alt coin, with high inflation and
> cheap transactions. but the altcoin is pegged to bitcoin's price
> because of the pool of unredeemed bitcoins held within the side chain.
>
>
>
> On Tue, Jun 20, 2017 at 7:54 AM, Paul Sztorc <truthcoin at gmail.com
> <mailto:truthcoin at gmail.com>> wrote:
>
> Hi Erik,
>
> As you know:
>
> 1. If a sidechain is merged mined it basically grows out of the
> existing Bitcoin mining network. If it has a different PoW
> algorithm it is a new mining network.
> 2. The security (ie, hashrate) of any mining network would be
> determined by the total economic value of the block. In Bitcoin
> this is (subsidy+tx_fees)*price, but since a sidechain cannot
> issue new tokens it would only be (tx_fees)*price.
>
> Unfortunately the two have a nasty correlation which can lead to a
> disastrous self-fulfilling prophecy: users will avoid a network
> that is too insecure; and if users avoid using a network, they
> will stop paying txn fees and so the quantity (tx_fees)*price
> falls toward zero, erasing the network's security. So it is quite
> problematic and I recommend just biting the bullet and going with
> merged mining instead.
>
> And, the point may be moot. Bitcoin miners may decide that, given
> their expertise in seeking out cheap sources of power/cooling,
> they might as well mine both/all chains. So your suggestion may
> not achieve your desired result (and would, meanwhile, consume
> more of the economy's resources -- some of these would not
> contribute even to a higher hashrate).
>
> Paul
>
>
>
>
> On 6/19/2017 1:11 PM, Erik Aronesty wrote:
>> It would be nice to be able to enforce that a drivechain *not*
>> have the same POW as bitcoin.
>>
>> I suspect this is the only way to be sure that a drivechain
>> doesn't destabilize the main chain and push more power to miners
>> that already have too much power.
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170622/3ba60e24/attachment.html>

2023-06-07 18:02:59

- reply

📅 Original date posted:2017-06-20
📝 Original message:Hi Erik,
As you know:
1. If a sidechain is merged mined it basically grows out of the existing
Bitcoin mining network. If it has a different PoW algorithm it is a new
mining network.
2. The security (ie, hashrate) of any mining network would be determined
by the total economic value of the block. In Bitcoin this is
(subsidy+tx_fees)*price, but since a sidechain cannot issue new tokens
it would only be (tx_fees)*price.
Unfortunately the two have a nasty correlation which can lead to a
disastrous self-fulfilling prophecy: users will avoid a network that is
too insecure; and if users avoid using a network, they will stop paying
txn fees and so the quantity (tx_fees)*price falls toward zero, erasing
the network's security. So it is quite problematic and I recommend just
biting the bullet and going with merged mining instead.
And, the point may be moot. Bitcoin miners may decide that, given their
expertise in seeking out cheap sources of power/cooling, they might as
well mine both/all chains. So your suggestion may not achieve your
desired result (and would, meanwhile, consume more of the economy's
resources -- some of these would not contribute even to a higher hashrate).
Paul
On 6/19/2017 1:11 PM, Erik Aronesty wrote:
> It would be nice to be able to enforce that a drivechain *not* have
> the same POW as bitcoin.
>
> I suspect this is the only way to be sure that a drivechain doesn't
> destabilize the main chain and push more power to miners that already
> have too much power.
>
>
> On Mon, Jun 19, 2017 at 12:04 PM, Paul Sztorc via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> Hi Greg,
>
> Responses below:
>
> On 6/18/2017 5:30 PM, Tao Effect wrote:
> > In Drivechain, 51% of miners have total control and ownership
> over all
> > of the sidechain coins.
>
> It would not be accurate to say that miners have "total" control.
> Miners
> do control the destination of withdrawals, but they do not control the
> withdrawal-duration nor the withdrawal-frequency.
>
> So, if miners wish to 'steal' from a sidechain, they _can_ initiate a
> theft, but they can not change the fact that their malfeasance will be
> [a] obvious, and [b] on display for a long period of time.
>
> We might draw a comparison between:
>
> 1. Classic Theft -- A majority hashrate reorganizes the main Bitcoin
> chain to double-spend funds (or coordinate with someone who is
> double-spending). This is prevented/discouraged by waiting for many
> confirmations.
> 2. Channel Theft -- A majority hashrate assists a Lightning-Network
> thief, by censoring the punitive audit txn (possibly by exploiting
> some
> excuse regarding fullness of blocks, or possibly induced to do so
> by the
> thief provably splitting the proceeds with miners). This is
> prevented/discouraged by using lengthy custodial periods, paying high
> fees with your attacker's money, and using
> fungibility/non-communication
> to interact with miners as little as possible (so as to frame LN-theft
> as undermining the entire LN system, and not merely a single tragedy).
> 3. Drivechain Theft -- A majority hashrate initiates an
> unrepresentative
> withdrawal from some sidechain. This is prevented/discouraged by only
> using 'popular' sidechains (those that [a] increase the usefulness
> ("market price") of bitcoin, and [b] generate tx fees for miners).
> It is
> also discouraged by the fact that egregious theft would probably
> end the
> sidechain experiment, meaning that all present and future sidechains
> would be forever unavailable (and unable to buoy the price or the tx
> revenues).
>
> I do not think that any of the three stands out as being categorically
> worse than the others, especially when we consider the
> heterogeneity of
> use-cases and preferences. As Luke-Jr has been pointing out on social
> media recently, the very group which is more associated with
> miners (and
> explicitly more willing to trust them, ie Bitcoin Unlimited et al),
> happens to be the same group that would be expected to make use of a
> LargeBlock drivechain. Some can argue that one type of security is
> more
> "cryptographic" than others, but I think this is misguided (how many
> 'bits' of security does each have?) -- imho, all three security models
> are 'game theoretic' (neither computer scientific, nor cryptographic).
>
> More importantly, before a miner has any "control" over the sidechain
> coins, users must voluntarily agree to subject themselves to these new
> rules. This is similar to how an arbitrary piece of (open source)
> software can have "total" control over your computer...if you
> choose to
> install it.
>
> > Thus the effect of Drivechain appears to be the creation of a
> new kind
> > of digital border imposed onto the network ...
>
> I'm not sure it would "create a border", given that sidechains are
> currently not accessible at all. If anything drivechain cuts a
> door into
> an existing impassible border.
>
> > ... where everyone hands over ownership of their Bitcoins to a
> > /single/ mining cartel when they wish to interact with /any/ sidechain.
>
> The qualifier "/any/ sidechain" would seem to imply that there is
> a way
> to do sidechains that does not involve handing over some control
> to 51%
> hashrate...I think this is false (even in the fabled case of
> ZK-SNARKS).
> The first thing I do in the drivechain spec (
> truthcoin.info/blog/drivechain
> <http://truthcoin.info/blog/drivechain> ) is explain why.
>
> > Drivechain would be a reasonable idea if that weren't the case, but
> > since it is, Drivechain now introduces a very real possible future
> > where Bitcoins can be confiscated by the Chinese government in
> exactly
> > the same manner that the Chinese government today confiscates
> > financial assets in other financial networks within China.
>
> Yes, but money could also be confiscated from _any_ Bitcoin users
> (Chinese or otherwise) using any of the three methods I mentioned
> above.
> And confiscation could strike Chinese Bitcoin users if they decided to
> sell their Bitcoin for Chinese Yuan, which they then deposited in a
> Chinese bank. Or if they sold their Bitcoin for an Altcoin
> controlled by
> the Chinese govt in some other way.
>
> It is not up to the members of this list to decide, USSR style, what
> other people are allowed to do with their own money.
>
> The exceptions to this rule would be (ie, "bitcoin-dev should care
> about
> what users are doing when..."):
>
> 1. [Unreasonable use of Reviewer Time] The user's use-case is either
> nonexistent (ie "no one wants that"), or totally unachievable ("we
> can't
> do that") thus rendering the conversation a complete waste of time /
> reviewer attention.
> 2. [Harmful Interference] The user's use-case would impose harm on
> some
> existing use-case(s).
>
> No reasonable person will claim the first, given today's scaling
> debate
> (not to mention today's 'bitcoin dominance index'). Therefore, critics
> must claim the second (as, for example, Peter Todd has been doing on
> this list).
>
> Which is why I narrowly focus on inter-chain harms [1], leading
> ultimately to a focus on the mining ecosystem [2,3] and the
> development
> of Blind Merged Mining [4].
>
> [1]
> https://www.youtube.com/watch?v=0goYH2sDw0w&list=PLw8-6ARlyVciNjgS_NFhAu-qt7HPf_dtg&index=1
> <https://www.youtube.com/watch?v=0goYH2sDw0w&list=PLw8-6ARlyVciNjgS_NFhAu-qt7HPf_dtg&index=1>
> [2] http://www.truthcoin.info/blog/mirage-miner-centralization/
> <http://www.truthcoin.info/blog/mirage-miner-centralization/>
> [3] http://www.truthcoin.info/blog/mining-threat-equilibrium/
> <http://www.truthcoin.info/blog/mining-threat-equilibrium/>
> [4] http://www.truthcoin.info/blog/blind-merged-mining/
> <http://www.truthcoin.info/blog/blind-merged-mining/>
> [5] http://www.truthcoin.info/blog/measuring-decentralization/
> <http://www.truthcoin.info/blog/measuring-decentralization/>
>
> > 1. The Bitcoin network centralizes more, because more power (both
> > financial power and power in terms of capability/control) is granted
> > to miners.
>
> I think that one has some duty to very clearly define something (like
> "mining centralization" [2] or "centralization" [5]) before
> complaining
> about it. I feel that people will occasionally use selfless complaints
> to accomplish a selfish goal...especially when the artificial selfless
> part is hard to discuss by virtue of its being poorly defined
> (especially vague or abstract items like "the company", "our country",
> etc). For example, those who take it upon themselves to "defend" "the
> Bitcoin community" may have exactly that in mind as their primary
> goal...but they may also end up with more visibility (and with it:
> more
> influence, more job offers, more conference invites, more friends,
> etc)
> and they may also end up with a megaphone for which to broadcast their
> other views, or just a defend-able excuse for bragging loudly
> about how
> great cypherpunks are and/or how devoted they-in-particular are to the
> cypherpunk tribe, et cetera. To avoid this problem in my own technical
> discourse, I try to avoid abstractions like "centralization" until I
> have defined them [2,5].
>
> You have defined centralization above, but the definition is itself
> vague to the point where I do not think even you actually endorse it.
> For example, you would need to say that Bitcoin centralizes
> whenever the
> exchange rate increases (as this grants additional financial power to
> miners) or when any new user joins Bitcoin, or when tx fee revenues
> increase for any reason. You might also be forced to say that LN
> centralizes Bitcoin (as LN grants new capability/control to
> miners), and
> probably even that Bitcoin becomes more centralized when developers
> release new software (as this grants new capability to miners,
> specifically the ability to deny upgrades). This probably isn't
> what you
> meant, but since you did not clearly explain what you meant we have no
> way of knowing for sure.
>
> It seems to me that you reject the premise that BMM [4] addresses
> these
> issues. This is probably because BMM only addresses miner's
> interactions
> with each other, and it does not address miner abilities as a group in
> relation to other groups (for example, vs. users, developers,
> investors). But, as I consistently emphasize, these groups of
> people are
> free to ignore any sidechains that they do not like. In law there is a
> saying 'volenti non fit injuria' which I would translate as "he who
> volunteers cannot claim later to have been injured". This is a legal
> theory, because otherwise everyone would be arbitrarily liable for
> choices beyond their control (ie, responsible for decisions of other
> unrelated people), which would be nonsense.
>
> > 3. Drivechain limits user's existing choice when it comes to who is
> > acting as custodian of their Bitcoins, from any trustworthy
> exchange,
> > down to a single mining cartel under the control of a single set
> of laws.
>
> Currently no (P2P) sidechains exist, and therefore the set of choices
> today would seem to be more "limited" than in a post-sidechain future.
> (The set of options may decrease later, for ecological reasons, if and
> only if 'exchanges' are a strictly inferior option to 'sidechains' for
> some reason...I don't see why this would be the case. I also don't
> understand the emphasis on "exchanges" [SCs are much more like
> Altcoins,
> than exchanges] in the first place, nor the dubious qualifier
> "trustworthy".)
>
> --Paul
>
> _______________________________________________
> 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
> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170620/36c542b5/attachment-0001.html>

2023-06-07 18:02:58

- reply

📅 Original date posted:2017-06-19
📝 Original message:Hi Greg,
Responses below:
On 6/18/2017 5:30 PM, Tao Effect wrote:
> In Drivechain, 51% of miners have total control and ownership over all
> of the sidechain coins.
It would not be accurate to say that miners have "total" control. Miners
do control the destination of withdrawals, but they do not control the
withdrawal-duration nor the withdrawal-frequency.
So, if miners wish to 'steal' from a sidechain, they _can_ initiate a
theft, but they can not change the fact that their malfeasance will be
[a] obvious, and [b] on display for a long period of time.
We might draw a comparison between:
1. Classic Theft -- A majority hashrate reorganizes the main Bitcoin
chain to double-spend funds (or coordinate with someone who is
double-spending). This is prevented/discouraged by waiting for many
confirmations.
2. Channel Theft -- A majority hashrate assists a Lightning-Network
thief, by censoring the punitive audit txn (possibly by exploiting some
excuse regarding fullness of blocks, or possibly induced to do so by the
thief provably splitting the proceeds with miners). This is
prevented/discouraged by using lengthy custodial periods, paying high
fees with your attacker's money, and using fungibility/non-communication
to interact with miners as little as possible (so as to frame LN-theft
as undermining the entire LN system, and not merely a single tragedy).
3. Drivechain Theft -- A majority hashrate initiates an unrepresentative
withdrawal from some sidechain. This is prevented/discouraged by only
using 'popular' sidechains (those that [a] increase the usefulness
("market price") of bitcoin, and [b] generate tx fees for miners). It is
also discouraged by the fact that egregious theft would probably end the
sidechain experiment, meaning that all present and future sidechains
would be forever unavailable (and unable to buoy the price or the tx
revenues).
I do not think that any of the three stands out as being categorically
worse than the others, especially when we consider the heterogeneity of
use-cases and preferences. As Luke-Jr has been pointing out on social
media recently, the very group which is more associated with miners (and
explicitly more willing to trust them, ie Bitcoin Unlimited et al),
happens to be the same group that would be expected to make use of a
LargeBlock drivechain. Some can argue that one type of security is more
"cryptographic" than others, but I think this is misguided (how many
'bits' of security does each have?) -- imho, all three security models
are 'game theoretic' (neither computer scientific, nor cryptographic).
More importantly, before a miner has any "control" over the sidechain
coins, users must voluntarily agree to subject themselves to these new
rules. This is similar to how an arbitrary piece of (open source)
software can have "total" control over your computer...if you choose to
install it.
> Thus the effect of Drivechain appears to be the creation of a new kind
> of digital border imposed onto the network ...
I'm not sure it would "create a border", given that sidechains are
currently not accessible at all. If anything drivechain cuts a door into
an existing impassible border.
> ... where everyone hands over ownership of their Bitcoins to a
> /single/ mining cartel when they wish to interact with /any/ sidechain.
The qualifier "/any/ sidechain" would seem to imply that there is a way
to do sidechains that does not involve handing over some control to 51%
hashrate...I think this is false (even in the fabled case of ZK-SNARKS).
The first thing I do in the drivechain spec (
truthcoin.info/blog/drivechain ) is explain why.
> Drivechain would be a reasonable idea if that weren't the case, but
> since it is, Drivechain now introduces a very real possible future
> where Bitcoins can be confiscated by the Chinese government in exactly
> the same manner that the Chinese government today confiscates
> financial assets in other financial networks within China.
Yes, but money could also be confiscated from _any_ Bitcoin users
(Chinese or otherwise) using any of the three methods I mentioned above.
And confiscation could strike Chinese Bitcoin users if they decided to
sell their Bitcoin for Chinese Yuan, which they then deposited in a
Chinese bank. Or if they sold their Bitcoin for an Altcoin controlled by
the Chinese govt in some other way.
It is not up to the members of this list to decide, USSR style, what
other people are allowed to do with their own money.
The exceptions to this rule would be (ie, "bitcoin-dev should care about
what users are doing when..."):
1. [Unreasonable use of Reviewer Time] The user's use-case is either
nonexistent (ie "no one wants that"), or totally unachievable ("we can't
do that") thus rendering the conversation a complete waste of time /
reviewer attention.
2. [Harmful Interference] The user's use-case would impose harm on some
existing use-case(s).
No reasonable person will claim the first, given today's scaling debate
(not to mention today's 'bitcoin dominance index'). Therefore, critics
must claim the second (as, for example, Peter Todd has been doing on
this list).
Which is why I narrowly focus on inter-chain harms [1], leading
ultimately to a focus on the mining ecosystem [2,3] and the development
of Blind Merged Mining [4].
[1]
https://www.youtube.com/watch?v=0goYH2sDw0w&list=PLw8-6ARlyVciNjgS_NFhAu-qt7HPf_dtg&index=1
[2] http://www.truthcoin.info/blog/mirage-miner-centralization/
[3] http://www.truthcoin.info/blog/mining-threat-equilibrium/
[4] http://www.truthcoin.info/blog/blind-merged-mining/
[5] http://www.truthcoin.info/blog/measuring-decentralization/
> 1. The Bitcoin network centralizes more, because more power (both
> financial power and power in terms of capability/control) is granted
> to miners.
I think that one has some duty to very clearly define something (like
"mining centralization" [2] or "centralization" [5]) before complaining
about it. I feel that people will occasionally use selfless complaints
to accomplish a selfish goal...especially when the artificial selfless
part is hard to discuss by virtue of its being poorly defined
(especially vague or abstract items like "the company", "our country",
etc). For example, those who take it upon themselves to "defend" "the
Bitcoin community" may have exactly that in mind as their primary
goal...but they may also end up with more visibility (and with it: more
influence, more job offers, more conference invites, more friends, etc)
and they may also end up with a megaphone for which to broadcast their
other views, or just a defend-able excuse for bragging loudly about how
great cypherpunks are and/or how devoted they-in-particular are to the
cypherpunk tribe, et cetera. To avoid this problem in my own technical
discourse, I try to avoid abstractions like "centralization" until I
have defined them [2,5].
You have defined centralization above, but the definition is itself
vague to the point where I do not think even you actually endorse it.
For example, you would need to say that Bitcoin centralizes whenever the
exchange rate increases (as this grants additional financial power to
miners) or when any new user joins Bitcoin, or when tx fee revenues
increase for any reason. You might also be forced to say that LN
centralizes Bitcoin (as LN grants new capability/control to miners), and
probably even that Bitcoin becomes more centralized when developers
release new software (as this grants new capability to miners,
specifically the ability to deny upgrades). This probably isn't what you
meant, but since you did not clearly explain what you meant we have no
way of knowing for sure.
It seems to me that you reject the premise that BMM [4] addresses these
issues. This is probably because BMM only addresses miner's interactions
with each other, and it does not address miner abilities as a group in
relation to other groups (for example, vs. users, developers,
investors). But, as I consistently emphasize, these groups of people are
free to ignore any sidechains that they do not like. In law there is a
saying 'volenti non fit injuria' which I would translate as "he who
volunteers cannot claim later to have been injured". This is a legal
theory, because otherwise everyone would be arbitrarily liable for
choices beyond their control (ie, responsible for decisions of other
unrelated people), which would be nonsense.
> 3. Drivechain limits user's existing choice when it comes to who is
> acting as custodian of their Bitcoins, from any trustworthy exchange,
> down to a single mining cartel under the control of a single set of laws.
Currently no (P2P) sidechains exist, and therefore the set of choices
today would seem to be more "limited" than in a post-sidechain future.
(The set of options may decrease later, for ecological reasons, if and
only if 'exchanges' are a strictly inferior option to 'sidechains' for
some reason...I don't see why this would be the case. I also don't
understand the emphasis on "exchanges" [SCs are much more like Altcoins,
than exchanges] in the first place, nor the dubious qualifier
"trustworthy".)
--Paul

2023-06-07 18:02:57

- reply

📅 Original date posted:2017-06-10
📝 Original message:Hi everyone,
It has been 3 weeks -- responses so far have been really helpful. People
jumped right in, and identified unfinished or missing parts much faster
than I thought they would (ie, ~two days). Very impressive.
Currently, we are working on the sidechain side of blind merged mining.
As you know, most of the Bitcoin cryptosystem is about finding the
longest chain, and displaying information about this chain. CryptAxe is
editing the sidechain code to handle reorganizations in a new way (an
even bigger departure than Namecoin's, imho).
I believe that I have responded to all the on-list objections that were
raised. I will 1st summarize the on-list objections, and 2nd summarize
the off-list discussion (focusing on three key themes).
On-List Objection Summary
---------------------------
In general, they were:
* Peter complained about the resources required for the BMM 'crisis
audit', I pointed out that it is actually optional (and, therefore,
free), and that it doesn't affect miners relative to each other, and
that it can be done in an ultra-cheap semi-trusted way with high
reliability.
* Peter also asked about miner incentives, I replied that it is profit
maximizing to BMM sidechains, because the equation (Tx Fees - Zero Cost)
is always positive.
* ZmnSCPxj asked a long series of clarifying questions, and I responded.
* Tier Nolan complained about my equivocation of the "Bitcoin: no block
subsidy" case and the "sidechain" case. He cites the asymmetry I point
out below (in #2). I replied, and I give an answer below.
* ZmnSCPxj pointed out an error in our OP Code (that we will fix).
* ZmnSCPxj also asked a number of new questions, I responded. Then he
responded again, in general he seemed to raise many of the points
addressed in #1 (below).
* ZmnSCPxj wanted reorg proofs, to punish reorgers, but I pointed out
that if 51% can reorg, they can also filter out the reorg proof. We are
at their mercy in all cases (for better or worse).
* ZmnSCPxj also brought up the fact that a block size limit is necessary
for a fee market, I pointed out that this limit does not need to be
imposed on miners by nodes...miners would be willing-and-able to
self-impose such a limit, as it maximizes their revenues.
* ZmnSCPxj also protested the need to soft fork in each individual
sidechain, I pointed out my strong disagreement ("Unrestrained smart
contract execution will be the death of most of the interesting
applications...[could] destabilize Bitcoin itself") and introduced my
prion metaphor.
* ZmnSCPxj and Tier Nolan both identified the problem solved by our
'ratchet' concept. I explained it to ZmnSCPxj in my reply. We had not
coded it at the time, but there is code for it now [1]. Tier proposed a
rachet design, but I think ours is better (Tier did not find ours at
all, because it is buried in obscure notes, because I didn't think
anyone would make it this far so quickly).
* Tier also advised us on how to fix the problem that ZmnSCPxj had
identified with our NOP earlier.
* Tier also had a number of suggestions about the real-time negotiation
of the OP Bribe amount between nodes and miners. I'm afraid I mostly
ignored these for now, as we aren't there yet.
* Peter complained that ACKing the sidechain could be exploited for
political reasons, and I responded that in such a case, miners are free
to simply avoid ACKing, or to acquiesce to political pressure. Neither
affect the mainchain.
* Peter complained that sidechains might provide some miners with the
opportunity to create a pretext to kick other miners off the network. I
replied that it would not, and I also brought up the fact that my
Bitcoin security model was indifferent to which people happened to be
mining at any given time. I continue to believe that "mining
centralization" does not have a useful definition.
* Peter questioned whether or not sidechains would be useful. I stated
my belief that they would be useful, and linked to my site
(drivechain.info/projects) which contains a number of sidechain
use-cases, and cited my personal anecdotal experiences.
* Peter wanted to involve miners "as little as possible", I pointed out
that I felt that I had indeed done this minimization. My view is that
Peter felt erroneously that it was possible to involve miners less,
because he neglected [1] that a 51% miner group is already involved
maximally, as they can create most messages and filter any message, and
[2] that there are cases where we need miners to filter out harmful
interactions among multiple chains (just as they filter out harmful
interactions among multiple txns [ie, "double spends"]). Peter has not
yet responded to this rebuttal.
* Peter also suggested client-side validation as "safer", and I pointed
out that sidechains+BMM _is_ client-side validation. I asked Peter for
CS-V code, so that we can compare the safety and other features.
* Sergio reminded us of his version of drivechain. Sergio and I disagree
over the emphasis on frequency/speed of withdrawals. Also Sergio
emphasizes a hybrid model, which does not interest me.
If I missed any objections, I hope someone will point them out.
Off-List / Three Points of Ongoing Confusion
---------------------------------------------
Off list, I have repeated the a similar conversation perhaps 6-10 times
over the past week. There is a cluster of remaining objections which
centers around three topics -- speed, theft, and antifragility. I will
reply here, and add the answers to my FAQ (drivechain.info/faq).
1. Speed
This objection is voiced after I point out that side-to-main transfers
("withdrawals") will probably take a long time, for example 5 months
each ( these are customizable parameters, and open for debate -- but if
withdrawals are every x=3 months, and only x=1 withdrawal can make
forward progress [on the mainchain] at a time, and only x=1 prospective
withdrawal can be assembled [by the sidechain] at a time, then we can
expect total withdrawal time to average 4.5 months [(.5)*3+3] ). The
response is something like "won't such a system be too slow, and
therefore unusable?".
Imho, replies of this kind disregard the effect of atomic cross-chain
swaps, which are instant.
( In addition, while side-to-main transfers are slow, main-to-side
transfers are quite fast, x~=10 confirmations. I would go as far as to
say that, just as the Lightning Network is enabled by SegWit and CSV,
Drivechain is enabled by the atomic swaps and of Counterparty-like
embedded consensus. )
Thanks to atomic swaps, someone can act as an investment banker or
custodian, and purchase side:BTC at a (tiny, competitive discount) and
then transfer those side-to-main at a minimal inconvenience (comparable
to that of someone who buys a bank CD). Through market activities, the
_entire system_ becomes exactly as patient as its most-patient members.
As icing on the cake, people who aren't planning on using their BTC
anytime soon (ie "the patient") can even get a tiny investment yield, in
return for providing this service.
2. Security
This objection usually says something like "Aren't you worried that 51%
[hashrate] will steal the coins, given that mining is so centralized
these days?"
The logic of drivechain is to take a known fact -- that miners do not
steal from exchanges (by coordinating to doublespend deposits to those
exchanges) -- and generalize it to a new situation -- that [hopefully]
miners will not steal from sidechains (by coordinating to make 'invalid'
withdrawals from them).
My generalization is slightly problematic, because "a large mainchain
reorg today" would hit the entire Bitcoin system and de-confirm *all* of
the network's transactions, whereas a sidechain-theft would hit only a
small portion of the system. This asymmetry is a problem because of the
1:1 peg, which is explicitly symmetrical -- the thief makes off coins
that are worth _just as much_ as those coins that he did _not_ attack.
The side:BTC are therefore relatively more vulnerable to theft, which
harms the generalization.
As I've just explained, to correct this relative deficiency, we add
extra inconvenience for any sidechain thievery, which is in this case
the long long withdrawal time of several months. (Which is also the main
distinction between DC and extension blocks).
I cannot realistically imagine an erroneous withdrawal persisting for
several weeks, let alone several months. First, over a timeframe of this
duration, there can be no pretense of 'we made an innocent mistake', nor
one that 'it is too inconvenient for us to fix this problem'. This
requires the attacker to be part of an explicitly malicious conspiracy.
Even in the conspiring case, I do not understand how miners would
coordinate the distribution of the eventual "theft" payout, ~3 months
from now -- if new hashrate comes online between now and then, does it
get a portion? -- if today's hashrate closes down, does it get a reduced
portion? -- who decides? I don't think that an algorithm can decide
(without creating a new mechanism, which -I believe- would have to be
powered by ongoing sustainable theft [which is impossible]), because the
withdrawal (ie the "theft") has to be initiated, with a known
destination, *before* it accumulates 3 months worth of acknowledgement.
Even if hashrate were controlled exclusively by one person, such a theft
would obliterate the sidechain-tx-fee revenue from all sidechains, for a
start. It would also greatly reduce the market price of [mainchain] BTC,
I feel, as it ends the sidechain experiment more-or-less permanently.
And even _that_ dire situation can be defeated by UASF-style maneuvers,
such as checkpointing. Even the threat of such maneuvers can be
persuasive enough for them never to be needed (especially over long
timeframes, which make these maneuvers convenient).
A slightly more realistic worst-case scenario is that a monopolist
imposes large fees on side-to-main transfers (which he contrives so that
only he can provide). Unless the monopoly is permanent, market forces
(atomic swaps) will still lower the fee to ultra-competitive levels,
making this mostly pointless.
3. Antifragility
There is an absolutely crucial distinction of "layers", which is often
overlooked. Which is a shame, because its importance really cannot be
understated.
Taleb's concept of antifragility is explicitly fractal -- it has layers,
and an upper layer can only be antifragile if it is composed of
individual members of a lower layer who are each *fragile*. In one of my
videos I give the example of NYC food providers -- it is _because_ the
competition is so brutal, and because each individual NYC
restaurant/supermarket/food-truck is so likely to fail, (and because
there is no safety net to catch them if they do fail), that the
consumer's experience is so positive (in NYC, you can find almost any
kind of food, at any hour of the day, at any price, despite the fact
that a staggering ~15 million people will be eating there each day).
By this, I mean there is an absolutely crucial distinction between:
1. A problem with a sidechain that negatively impacts its parent chain.
2. A problem with a sidechain that only impacts the sidechain users.
The first type of problem is unacceptable, but the second type of
problem is actually _desirable_.
If we wanted to have the best BTC currency unit possible, we would want
everyone to try all kinds of things out, _especially_ the things that we
think are terrible. We'd want lots of things to be tried, and for the
losers to "fail fast".
In practice I highly doubt the sidechain ecosystem would be anywhere
near as dynamic as NYC or Silicon Valley. But certain questions, such as
"What if a sidechain breaks / has DAO-like problems?"; "What if the
sidechain has only a few nodes? Who will run them?"; "Who will maintain
these projects?"; -- really just miss the point, I think.
Ultimately, users can vote with their feet -- if the benefits of a
sidechain outweigh its risks, some users will send some BTC there. It is
a strict improvement over the current situation, where users would need
to use an Altcoin to achieve as much. Users who aren't comfortable with
the risks of new chains / new features, can simply decline to use them.
Another Objection
------------------
Finally, two people raised an objection which I will call the "too
popular" objection or "too big to fail (tbtf)". Something like "what if
a *majority* of BTC is moved to one sidechain, and then that sidechain
has some kind of problem?".
One simple step would be to cap the quantity of BTC that can be moved to
each sidechain, (at x=10% ? aka 210,000).
Other than that, I would point out that Bitcoin has always been the
"money of principle", and that we survived the MtGox announcement (in
which ~850,000/12,400,000 = 6.85% of the total BTC were assumed to be
stolen).
I look forward to the continued feedback! Thank you all very much!
Paul
[1]
https://github.com/drivechain-project/bitcoin/commit/c4beef5c2aa8e52d2c1e11de7c044528bbde6c60
On 5/22/2017 2:17 AM, Paul Sztorc wrote:
> Dear list,
>
> I've been working on "drivechain", a sidechain enabling technology, for
> some time.
>
> * The technical info site is here: www.drivechain.info
> * The changes to Bitcoin are here:
> https://github.com/drivechain-project/bitcoin/tree/mainchainBMM
> * A Blank sidechain template is here:
> https://github.com/drivechain-project/bitcoin/tree/sidechainBMM
>
> As many of you know, I've been seeking feedback in person, at various
> conferences and meetups over the past year, most prominently Scaling
> Milan. And I intend to continue to seek feedback at Consensus2017 this
> week, so if you are in NYC please just walk up and start talking to me!
>
> But I also wanted to ask the list for feedback. Initially, I was
> hesitant because I try not to consume reviewers' scarce time until the
> author has put in a serious effort. However, I may have waiting too
> long, as today it is actually quite close to a working release.
>
>
> Scaling Implications
> ---------------------
>
> This upgrade would have significant scaling implications. Since it is
> the case that sidechains can be added by soft fork, and since each of
> these chains will have its own blockspace, this theoretically removes
> the blocksize limit from "the Bitcoin system" (if one includes
> sidechains as part of such a system). People who want a LargeBlock
> bitcoin can just move their BTC over to such a network [1], and their
> txns will have no longer have an impact on "Bitcoin Core". Thus, even
> though this upgrade does not actually increase "scalability" per se, it
> may in fact put an end to the scalability debate...forever.
>
> This work includes the relatively new concept of "Blind Merged Mining"
> [2] which I developed in January to allow SHA256^2 miners to merge-mine
> these "drivechains", even if these miners aren't running the actual
> sidechain software. The goal is to prevent sidechains from affecting the
> levelness of the mining "playing field". BMM is conceptually similar to
> ZooKeeV [3] which Peter Todd sketched out in mid-2013. BMM is not
> required for drivechain, but it would address some of the last remaining
> concerns.
>
>
> Total Transaction Fees in the Far Future
> -----------------------------------------
>
> Some people feel that a maximum blocksize limit is needed to ensure that
> future total equilibrium transaction fees are non-negligible. I
> presented [4] on why I don't agree, 8 months ago. The reviewers I spoke
> to over the last year have stopped bringing this complaint up, but I am
> not sure everyone feels that way.
>
>
> Juxtaposition with a recent "Scaling Compromise"
> -------------------------------------------------
>
> Recently, a scalability proposal began to circulate on social media. As
> far as I could tell, it goes something like "immediately activate
> SegWit, and then HF to double the nonwitness blockspace to 2MB within 12
> months". But such a proposal is quite meager, compared to a "LargeBlock
> Drivechain". The drivechain is better on both fronts, as it would not
> require a hardfork, and could *almost immediately* add _any_ amount of
> extra blockspace (specifically, I might expect a BIP101-like LargeBlock
> chain that has an 8 MB maxblocksize, which doubles every two years).
>
> In other words, I don't know why anyone would support that proposal over
> mine. The only reasons would be either ignorance (ie, unfamiliarity with
> drivechain) or because there are still nagging unspoken complaints about
> drivechain which I apparently need to hear and address.
>
>
> Other Thoughts
> ---------------
>
> Unfortunately, anyone who worked on the "first generation" of sidechain
> technology (the skiplist) or the "second generation" (federated /
> Liquid), will find that this is very different.
>
> I will admit that I am very pessimistic about any conversation that
> involves scalability. It is often said that "talking politics lowers
> your IQ by 25 points". Bitcoin scalability conversations seem to drain
> 50 points. (Instead of conversing, I think people should quietly work on
> whatever they are passionate about until their problem either is solved,
> or it goes away for some other reason, or until we all agree to just
> stop talking about it.)
>
> Cheers,
> Paul
>
> [1] http://www.drivechain.info/faq/#can-sidechains-really-help-with-scaling
> [2] http://www.truthcoin.info/blog/blind-merged-mining/
> [3] https://s3.amazonaws.com/peter.todd/bitcoin-wizards-13-10-17.log
> [4]
> https://www.youtube.com/watch?v=YErLEuOi3xU&list=PLw8-6ARlyVciNjgS_NFhAu-qt7HPf_dtg&index=4
>

2023-06-07 18:02:55

- reply

📅 Original date posted:2017-06-10
📝 Original message:Hi Sergio / everyone,
As some of you may know, Sergio and I each did an implementation of
drivechain. I started working on mine, and he started working on his,
and then I didn't hear from him for awhile about what he was doing.
Anyways, with two versions, we each have an opportunity to double-check
our work. For example, this already happened wrt the "ACK size". Let me
share from his linked BIP:
"By allowing miners to refer to transaction candidates by
transaction id prefixes, the space consumption for a single ack can be
as low as 2 bytes."
Sergio shared this with me last October at Scaling Milan. After
listening to him, we saw an opportunity to improve our design: now, our
miners can conjecture that miners will grant ACKs in a few simple ways
[always honest, honest+ignore some, ignore all], and it will precompute
these possibilities (guessing what rival miners will do, even before
they find and broadcast a new block). Therefore, in all honest cases,
our ACK-counting now requires zero (0) bytes to be sent over the
network. In dishonest cases it requires only a few bits per sidechain,
because we also maintain a deterministically ordered list, both of
sidechains and withdrawal attempts -- therefore it can just be a string
of binary information. This is not part of consensus, and so can be
further improved over time.
I'm sure there are still a few opportunities for mutual improvements
going forward.
In general, Sergio and I disagree over the withdrawal-frequency. a major
difference of opinion is over the withdrawal-frequency. I view
infrequent withdrawal as essential to the security model, but Sergio
does not. In both our designs, the withdrawal-time is configurable, but
Sergio's design seems to be optimized for cases with frequent withdrawal
attempts, whereas mine is optimized for cases with very infrequent
withdrawal attempts.
Another difference is that, as a direct result of earlier peer review, I
have been integrating 'blind merged mining' into my version. It may be
easy for Sergio to add BMM to his version, or it may not.
It is true that I am not interested in the hybrid model. I would not
make use of the multisig / centralized part, and so for me it
complicates the security properties for no benefit. I see why some
people are interested in it, though.
Paul
On 6/9/2017 5:54 PM, Sergio Demian Lerner wrote:
> I'm a bit late to this party. I just want to add that there exists an
> hybrid model where both a federation and the miners provide acknowledges
> (sometimes known as "votes" in drivechain terms and "multi-signatures"
> in a federation) of the sidechain state.
>
> My Drivechain proposal (Feb 2016) was tailored to enable this particular
> use-case, which I'm not sure Paul's proposal enable.
>
>
> The proposal is on this list under the following subject: Drivechain
> proposal using OP_COUNT_ACKS
>
> BIP (draft):
> https://github.com/rootstock/bips/blob/master/BIP-R10.md
> <https://github.com/rootstock/bips/blob/master/BIP-R10.md>
>
> Code & Test cases:
> https://github.com/rootstock/bitcoin/tree/op-count-acks_devel
> <https://github.com/rootstock/bitcoin/tree/op-count-acks_devel>
>
> In this proposal, the "poll" time is sidechain-configurable, and I
> proposed a few days delay was enough.
> Some have said that a longer times are needed, such as 2 months.
> So if you want to have a 2 month dalay for sidechain->mainchain
> transfers in this code, you still can. However a better dynamic cache of
> acks/nacks would be needed. However, for the hybrid use-case, one day is
> more than enough.
>
> Regards
>
>
>
>
> On Tue, May 30, 2017 at 2:11 AM, Paul Sztorc via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> Hi Peter,
>
> Responses below.
>
> On 5/28/2017 5:07 PM, Peter Todd wrote:
> > On Mon, May 22, 2017 at 05:30:46PM +0200, Paul Sztorc wrote:
> >> Surprisingly, this requirement (or, more precisely, this incentive) does
> >> not effect miners relative to each other. The incentive to upgrade is only
> >> for the purpose of preventing a "theft" -- defined as: an improper
> >> withdrawal from a sidechain. It is not about miner revenues or the ability
> >> to mine generally (or conduct BMM specifically). The costs of such a theft
> >> (decrease in market price, decrease in future transaction fee levels) would
> >> be shared collectively by all future miners. Therefore, it would have no
> >> effect on miners relative to each other.
> >
> > That's not at all true. If I'm a miner with a better capability than another
> > miner to prevent that theft, I have reasons to induce it to happen to give me
> > political cover to pushing that other miner off the network.
>
> Miners can abstain from 'voting', which is politically neutral. Or, if
> they wish, smaller miners could acquiesce to the coercion and just copy
> the votes of the attacking 51% group. For users who are only running
> Bitcoin Core, there is nothing bad about that.
>
> As you say, a 51% group can arbitrarily start orphaning the blocks that
> are mined by non-member rivals. This _may_ be a problem, or it may not,
> but it is not exacerbated by drivechain.
>
> So, what exactly is "not at all true"?
>
>
> >
> > This is a very similar problem to what we had with zeroconf double-spending,
> > where entities such as Coinbase tried to pay off miners to guarantee something
> > that wasn't possible in a geninely decrentralized system: safe zeroconf
> > transactions.
>
> I don't see what you mean here. You can't stop Coinbase from donating
> BTC to a subset of miners. That will always be possible, and it has
> nothing to do with drivechain (as I see it).
>
>
> >
> >> Moreover, miners have other recourse if they are unable to run the node.
> >> They can adopt a policy of simply rejecting ("downvoting") any withdrawals
> >> that they don't understand. This would pause the withdraw process until
> >> enough miners understand enough of what is going on to proceed with it.
> >
> > Why are you forcing miners to run this code at all?
>
> Could we not say the same thing about the code behind CLTV?
>
> The nature of a contract, is that people are happier to be bound by some
> rules that they themselves construct (for example, a nuclear
> non-proliferation treaty).
>
> In this case, miners prefer sidechains to exist (as existence makes the
> BTC they mine more valuable, and provides additional tx fee revenues),
> and so they would like to run code which makes them possible.
>
>
> >
> > Equally, you're opening up miners to huge political risks, as rejecting all
> > withdrawals is preventing users' from getting their money, which gives other
> > miners a rational for kicking those miners off of Bitcoin entirely.
>
> As I explained above, miners can abstain from voting, which is
> politically neutral, or else they can delegate their vote to an
> aggressive miner. The "51% can orphan" concern could be raised, even in
> a world without drivechain. All that is required, is for the miners to
> be anonymous, or in private 'dark' pools (and to thereby escape
> censure).
>
> But there is a much bigger issue here, which is that our threat models
> are different.
>
> As you may know, my threat model [1] does not include miners "pushing
> each other off". It only cares about the miner-experience, to the extent
> that it impacts the user-experience.
>
> Moreover, I reject [2] the premise that we can even measure "miner
> centralization", or even that such a concept exists. If someone has a
> definition of this concept, which is both measurable and useful, I would
> be interested to read it.
>
> ( For what it's worth, Satoshi did not care about this, either. For
> example: "If a greedy attacker is able to assemble more CPU power than
> all the honest nodes, he...ought to find it more profitable to play by
> the rules." which implies robustness to 51% owned by one entity. )
>
> [1] http://www.truthcoin.info/blog/mining-threat-equilibrium/
> <http://www.truthcoin.info/blog/mining-threat-equilibrium/>
> [2] http://www.truthcoin.info/blog/mirage-miner-centralization/
> <http://www.truthcoin.info/blog/mirage-miner-centralization/>
>
>
> >
> >> Finally, the point in dispute is a single, infrequent, true/false question.
> >> So miners may resort to semi-trusted methods to supplement their decision.
> >> In other words, they can just ask people they trust, if the withdrawal is
> >> correct or not. It is up to users to decide if they are comfortable with
> >> these risks, if/when they decide to deposit to a sidechain.
> >
> > Why do you think this will be infrequent? Miners with a better ability to
> > validate the drivechain have every reason to make these events more frequent.
>
> It is part of the spec. These timing parameters must be agreed upon when
> the sidechain is added, ie _before_ users deposit to the sidechain. Once
> the sidechain is created, the timing is enforced by nodes, the same as
> with any other protocol rules. Miner-validation-ability has no effect on
> the frequency.
>
>
> >
> >> It is a matter of comparing the costs and benefits. Ignoring theft, the
> >> costs are near-zero, and the benefits are >0. Specifically, they are: a
> >> higher BTC price and greater transaction fees. Theft is discouraged by
> >> attempting to tie a theft to a loss of confidence in the miners, as
> >> described in the spec/website.
> >> In general the incentives are very similar to those of Bitcoin itself.
> >
> > This is also a very dubious security model - I would argue that Bitcoin is much
> > *more* valuable if miners do everything they can to ensure that drivechains
> > fail, given the huge risks involved.
>
> I don't see how. Users are free to ignore the sidechain, so it can only
> benefit them.
>
> Fortunately for you, if that is actually what miners believe, then there
> will be no problem, as miners will just filter out drivechains (so that
> Bitcoin will be "much *more* valuable"), which they can easily do.
>
>
> > I would also argue that users should do
> > user-activated-soft-forks to ensure they fail.
>
> Again, I don't think that kind of UASF can succeed, because one option
> strictly dominates the other. But the users get the final say, of
> course.
>
> Empirically, I have observed overwhelming support for sidechains among
> users, business, and other developers. The btc-investors I spoke to were
> all very excited about the prospect of sidechains, even more so than
> they were excited about SegWit.
>
>
> >
> > By comparison, note Adam Back and my own efforts to ensure miners have a
> > smaller part in the ecosystem, with things like committed (encrypted)
> > transactions and my closed-seal-set/truth-list approach(1). We want to involve
> > miners as little as possible in the consensus, not more.
>
> I agree that miners should have as little influence as possible (and
> they probably agree, as well). But a 51% group can filter any message
> they like from the blockchain. For sidechains, there will need to be two
> public networks, so concealment is not an option.
>
> And, I repeat, for regular users of Bitcoin Core, drivechain does not
> make a 51% group more dangerous than they already are.
>
> Moreover, there are cases [1] where miner-involvement can make a big
> _positive_ impact. Just as it can be beneficial (essential, in fact) for
> Bitcoin to filter out harmful interactions among txns (in other words,
> good for miners to filter out double spends), I have discovered
> situations where it is beneficial and essential for miners to filter out
> harmful interactions among multiple chains.
>
> So I think I am actually hitting the "as little as possible" target.
>
> [1] http://www.truthcoin.info/blog/wise-contracts/#wise-contracts
> <http://www.truthcoin.info/blog/wise-contracts/#wise-contracts>
>
>
> >
> > I have to ask: What use-cases do you actually see for drivechains? Why can't
>
> Here is a tentative project list:
> http://www.drivechain.info/projects/index.html
> <http://www.drivechain.info/projects/index.html>
>
> And, as I say on the FAQ, "If each individual user is free to sell
> his/her BTC in exchange for an Altcoin (or for fiat), we can hardly deny
> users the opportunity to move their money between two sidechains."
>
> So, in a strong way, the entire altcoin market makes the case for a
> usefulness of sidechains. Bitcoin is a form of money, and only one form
> of money can exist per currency area. So, if Bitcoin is not the winner,
> it will eventually cease to exist altogether. Altcoin-competition is an
> existential threat to Bitcoin, one which is far more relevant than
> anything you've presented so far.
>
> Secondly, one important value of permissionless innovation is that one
> doesn't really know, today, what cool ideas other people are going to
> come up with tomorrow. If you did, they'd be today's ideas.
>
> Third, Core's review process has two opposite problems: on one hand it
> is slow and grueling, and on the other it is fraught with the
> possibility of catastrophic error. It would be better, for everyone, to
> allow people to try their own (non-aggressive) experiments, and to make
> their own mistakes. Already, I have seen the review process abused to
> create/maintain fiefdoms of expertise, so that the abusers can extract
> money from clients/employers/VCs.
>
> Just think of all of the free time you would have, Peter, if you didn't
> have to spend it all reviewing these projects!
>
>
> > those use-cases be done in the much safer client-side validation fashion?
>
> ? How is drivechain _not_ within the category of client-side validation?
> With BMM, validation is only performed by those users ("clients") who
> opt-in to the new features. The economic model of BMM is directly
> comparable to that of Bitcoin's PoW -- the highest-bid chain should be
> the healthiest one.
>
> Can you post the Github link for your most up-to-date client-side
> validation work so that we can compare the safety and other features?
>
> Thanks,
> Paul
>
> >
> > 1)
> https://petertodd.org/2016/closed-seal-sets-and-truth-lists-for-privacy
> <https://petertodd.org/2016/closed-seal-sets-and-truth-lists-for-privacy>
> >
> _______________________________________________
> 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
> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>
>

2023-06-07 18:01:51

- reply

📅 Original date posted:2017-05-24
📝 Original message:Responses below.
On 5/23/2017 7:26 PM, ZmnSCPxj wrote:
> Good morning,
>
>
>>>
>>> How is OP_BRIBE superior to just using a <h*> OP_RETURN script? Cannot
>>> a sidechain scan the block for OP_RETURN attesting that the block hash
>>> is present in the block?
>>
>>The sidechain software can indeed, but the mainchain software cannot
>>(without making validation of both chains part of the mainchain, which
>>defeats the original purpose of sidechains).
>>
>>The purpose of OP_BRIBE is to allow "Sam" (on the sidechain) and "Mary"
>>(a mainchain miner) to work together. Sam would pay X BTC to Mary, if
>>Mary could provide Sam with some guarantee that Sam's sidechain block
>>[defined by h*] would make it into the largest chain.
>
> Regarding "largest chain", do you mean mainchain or sidechain?
Sidechain. Sam is paying himself the revenues of the sidechain's block.
These are side:btc, that he gets, if this block is part of the largest
chain.
>
> An OP_RETURN is still some guarantee that it will make it into the
> longest mainchain. If OP_RETURN tx is in a shorter mainchain but not on
> the longer mainchain, then on the longer mainchain, the utxo's funding
> the OP_RETURN tx is still unspent and the OP_RETURN tx will still be
> mineable by any miner following the longer mainchain. The X BTC would
> be the OP_RETURN transaction's fee, which Mary would still want to mine
> into the longest mainchain, as it is still money on the table if it is
> not mined on the longest mainchain.
As you say below, it is about the sidechain, not mainchain. (Anything
not in the longest mainchain is just discarded by everyone, as always.)
>
> Or, does OP_BRIBE somehow assure that Sam's block goes onto the longer
> sidechain? But then, do not side blocks refer to their previous side
> block to define the sidechain?
Yes, there is a new construction for this, which might be called "SPV
squared". Classical merged mining (ie Namecoin) does not require the
mainchain to do anything, except occasionally keep track of an ordered
list of hash commitments. BMM is different, it does require the
mainchain to keep track of a minimal amount of things. One is the total
number of sidechains, but the second is what you have hit on here.
In addition to a list of commitments (ideally, one commitment per
block), the mainchain also keeps track of the block number ( ..or, as
you'll see, perhaps "block number modulo x".. ) of recent sidechain
blocks (for the last x=65,536 mainchain blocks). It then subsets the
most recent y=4000 of these, and only allows new sidechain blocks to
appear if they have a blocknumber equal to a member of set Y', where Y'
is the set of all sidechain blocknumbers y blocks ago + 1.
Then, the sidechain nodes simply reject the block if the h* commitment
refers to a side:blockheader that has a different block number.
Perhaps these notes..
http://www.truthcoin.info/images/bmm-outline.txt
..would be helpful. Looking back, this is probably the hackiest part of
the entire system, by a wide margin, so it is good that you bring it up.
>
>
> Is there some predictable schedule for side->main withdrawals? If a
> withdrawal is imminent, or if some actor can get "insider information"
> about whether a withdrawal is imminent, cannot some actor induce the
> above, with potentially shorter time to reach step 3?
Yes, these delays are parameters, which are defined per sidechain. So
once the sidechain has been 'added' to bitcoin, the schedule would be
fully predictable.
>
> From my reading, Blockstream's sidechains proposal supports a reorg
> proof after a side->main withdrawal on the mainchain side, with a reorg
> proof burn window after the main:side->main withdrawal, preventing its
> utxo from being used. If the reorg proof is published and shows that a
> sidechain reorg invalidates a particular side->main withdrawal, then the
> main:side->main withdrawal's utxo is burned.
In this, there is no reorg proof (the miners would simply prevent the
withdrawal from accumulating enough ACKs). A 51% miner coalition can
always filter any message they like from the blockchain, including the
reorg proofs.
>
>>For extraordinary DAO-like situations, disinterested mainchain miners
>>merely need a single bit of information (per sidechain), which is
>>"distress=true", and indicates to them to temporarily stop ACKing
>>withdrawals from the sidechain. This alone is enough to give the reorg
>>an unlimited amount of time to work itself out.
>
> Do you have some document containing these details? I cannot find this
> in the blog posts I've read so far.
This specific detail is not documented. I feel it is comparable to, for
example, the March 2013 chain fork.
>
>>>>I feel that my proposal is more secure, as it can operate healthily and
>>> quickly while using spv proofs which are much slower and much much
>>> easier to audit.
>>>
>>> I don't quite understand how Drivechain handles sidechain reorgs, while
>>> keeping Bitcoin miners blinded. It seems sidechains need to be known
>>> ("seen") by the miner, so I don't see what is being blinded by blinded
>>> merge mining.
>>
>>Mainchain miners do need to maintain some data about the sidechains, but
>>this is very minimal, and certainly does not include the transaction
>>data (or arbitrary messages) of the sidechain.
>
> As above, do you have document containing what data mainchain needs to
> track?
Yes, I think the notes (above) may be helpful.
>
>>>>>Blind merged mining seems strictly inferior ... a rich attacker can
>>> simply reorg the sidechain outright without playing such games.
>>>>
>>>>In the future, when there is no block subsidy, a rich attacker can also
>>> do that in mainchain Bitcoin.
>>>
>>> I see. However, block subsidies will drop far in the future, do you
>>> mean to say, that sidechains will be used only in the far future?
>>
>>In one sense, I mean "you have already endorsed this 'fees only will
>>work' premise, by endorsing Bitcoin".
>
> I endorse this on the basis of Greg Maxwell's analysis that a block size
> limit is necessary to have a fee market.
Even were that the case, the limit does not need to be imposed by nodes.
Miners are likely to self-impose a limit, on nodes and each other, in
order to maximize their total revenues. In fact they will eventually be
required to do so (even though they do not now, beyond the naive
maximization of imposing minimum tx fee requirements).
In fact, in that case, the larger the range of possible blocksizes, the
greater the ability of miners to extract fees from users -- ie the less
limited the blocksize, the more hashpower security.
Simply, if revenue = R = f(demand, supply), and miners choose the supply
which argmax R , then R can only go down as supply is constrained.
And, the effect is even more beneficial to security than _that_ ...if
the sidechains are different from each other, such that blockspace in
one chain is _not_ a perfect substitute for blockspace in another. In
this case miners can choke up on some (or each) individual S_i, forcing
sum(R_i) to go even higher.
>
>
>>That mechanism is enforced by drivechain itself, not OP_BRIBE. (OP Bribe
>>is itself only ~half of BMM. I admit it is getting a little confusing.)
>
> Can you provide the details of this mechanism? For example, does h*
> actually include some information identifying the sidechain and OP_BRIBE
> is supposed to do some additional checking not shown in your current
> code, or ....?
Yes. Yes.
This is what we nicknamed the "ratchet", I cannot easily check the code
right now but will get back to you.
https://github.com/drivechain-project/bitcoin/commit/c4fe067e298f57252789c28161272db3d7483dca#diff-be5f6bb690c9898e44cbd7e78c465e43R83
>
>>Drivechain requires a soft fork to add each new sidechain
>
> Oh.
>
> My understanding is that with Blockstream's zk-SNARKs, a new sidechain
> would not require a soft fork at all (or even miner voting on the
> validity of WT^: the validity of side:side->main transactions is assured
> by proof that the zk-SNARK checking that transaction was executed
> correctly, and the lack of a reorg proof during the burn window after
> the main:side->main).
>
> Is your model then, that each sidechain maintainer has to maintain a
> patchset or some plugin system to Core? And miners who want to support
> particular sidechains to modify their software, applying the patch for
> each sidechain they want to support?
Not necessarily, but I think "plugins" are a good metaphor.
>
> It seems this is somewhat brittle and may cause sidechain coding
> problems to leak into mainchain.
>
> I think, it is much less interesting to have to softfork in every
> sidechain, rather than to support a general mechanism (zk-SNARK) to
> allow sidechains to be launched without any modification to Core code.
>
I completely disagree. Unrestrained smart contract execution will be the
death of most of the interesting applications of sidechains, and would
probably destabilize Bitcoin itself.
I would be as if your body "added" the ability to synthesize any
protein, including prions. Then you make one prion and your entire body
dies.
I thought this would come up, I have a presentation on this:
https://www.youtube.com/watch?v=xGu0o8HH10U&list=PLw8-6ARlyVciMH79ZyLOpImsMug3LgNc4&index=1
You don't need to watch the whole thing, maybe just parts 1 and 5.
>
>>. It requires
>>this literally for a few good reasons...but the best is: there is an
>>implicit requirement that the miners not steal from the sidechain
>>anyway. In this way drivechain knows how to keep track of what it should
>>expect.
>
> It seems to be, more of "completely sighted merged mining" than "blind
> merge mining".
You can call it microscope mining if you like..it attempts to address
the concerns that were raised earlier in the peer review process.
>
>
>
>>> Perhaps the datacenter point is simply that your proposal suggests to
>>> reduce the size of the datacenter by removing surge suppressors and
>>> UPS's, to avoid some definition of "datacenter is a room with >$XXX of
>>> equipment".
>>
>>I hope that my replies above already help with these. If not, let me know.
>
> I find this point now moot, as drivechains require a softfork for each
> sidechain, and the size of the datacenter is pointless if there is some
> need to softfork in every sidechain.
You might be confused...miners can soft fork in a sidechain that they
have *no* intention of merged mining, or BMM ing. I do not know why, as
they would be leaving money on the table, but it is possible. Perhaps
only 5% of miners want to bother with it. The point is that the other
90% hashpower has no inherent reason *not* to allow that the experiment
be run.
>
> Regards,
> ZmnXCPxj

2023-06-07 18:01:33

- reply

📅 Original date posted:2017-05-23
📝 Original message:On 5/22/2017 8:13 PM, ZmnSCPxj wrote:
> Good morning,
>
>
>
>>What you read is only an introduction of BMM. You may also consult the
> notes (at the bottom of the BMM post) or the code, although this is time
> consuming of course.
>
> Looking over the code, I have a question: Is OP_BRIBE supposed to be
> softforked in, or hardforked?
Softforked, of course.
From my understanding, the code as
> published in your linked github cannot be softforked in, since it is not
> a softfork-compatible replacement for OP_NOP: it replaces the stack top
> value with a 0/1 value. Both CLTV and CSV do not touch the stack, only
> flag an error if they fail.
Your understanding may exceed my own. I don't understand the principle
of your distinction, as it seems to me that one could add a new protocol
rule which says that the block is invalid unless the OP Code does
results in arbitrary-item-x. The intent is to mimic CLTV or CSV
behavior, by causing something that would otherwise succeed, to fail, if
arbitrary new conditions are met.
>
> (What happens if the h* to be put in the coinbase, by chance - even very
> unlikely chance - is 0? Then <h*> OP_NOP4 is not the same as <h*>
> OP_BRIBE scripts in result - the former will be rejected by old nodes,
> the latter will be accepted by new nodes)
That would indeed be a bug, if it happened as you described. I will
check when I get the chance, thanks.
>
> Is OP_BRIBE the same as the OP_h_is_in_coinbase operation you described?
Yes. Sorry if that was confusing.
>
> How is OP_BRIBE superior to just using a <h*> OP_RETURN script? Cannot
> a sidechain scan the block for OP_RETURN attesting that the block hash
> is present in the block?
The sidechain software can indeed, but the mainchain software cannot
(without making validation of both chains part of the mainchain, which
defeats the original purpose of sidechains).
The purpose of OP_BRIBE is to allow "Sam" (on the sidechain) and "Mary"
(a mainchain miner) to work together. Sam would pay X BTC to Mary, if
Mary could provide Sam with some guarantee that Sam's sidechain block
[defined by h*] would make it into the largest chain.
So, as I see it, this needs to be a mainchain consensus rule, but one
which enforces the bare minimum criteria.
>
>>The literal answer to your question is that mainchain Bitcoin will
> notice that, for the second withdrawal, the sum of the inputs is less
> than the sum of the outputs and they the transaction is therefore invalid.
>
> You misunderstand. The first withdrawal was done by double-spending,
> and exchanging your sidechain funds for mainchain funds using some
> off-chain method. The second withdrawal is done on-chain.
If A, B, and C are transacting, and each has an account on both chains.
Then your example would be something like:
1. main:A sends 100 to side:A, then transfers 100 to side:B in exchange
for B's good or service (provided on the sidechain)
2. side:B attempts to move side-to-main with the 100 BTC, using the
lightning network. He swaps 100 side:BTC for 100 of C's main:BTC.
3. C attempts to move side-to-main, using the slow, settlement method.
4. C's side-to-main sidechain tx (wt) is bundled with others and becomes
a withdrawal attempt (WT^)
5. The WT^ attempt is initiated on the mainchain.
6. After a waiting period, the WT^ begins to accumulate ACKs or NACKs
(upvotes / downvotes), on the mainchain.
7. The transaction either succeeds or fails.
I'm not sure, but your question seems to concern B, who exploits a reorg
that happens just after step 2. After the reorg, the sidechain chain
history will have a different side-to-main withdrawal in part 3. The
time between each of these step is very long, on the order of weeks
(summing to a length of time totaling months), for exactly this reason
(as well as to encourage people to avoid using this 'formal' method, in
favor of the cooperative LN and Atomic Swaps).
I think that this principle of scale (ie, very VERY slow withdrawals) is
important and actually makes the security categorically different.
For extraordinary DAO-like situations, disinterested mainchain miners
merely need a single bit of information (per sidechain), which is
"distress=true", and indicates to them to temporarily stop ACKing
withdrawals from the sidechain. This alone is enough to give the reorg
an unlimited amount of time to work itself out.
>
> That said, I confused OP_h_is_in_coinbase as your method of getting out
> of the sidechain into the mainchain. It seems, OP_h_is_in_coinbase is
> only for blind mining?
Correct
>
>
>
>>I feel that my proposal is more secure, as it can operate healthily and
> quickly while using spv proofs which are much slower and much much
> easier to audit.
>
> I don't quite understand how Drivechain handles sidechain reorgs, while
> keeping Bitcoin miners blinded. It seems sidechains need to be known
> ("seen") by the miner, so I don't see what is being blinded by blinded
> merge mining.
Mainchain miners do need to maintain some data about the sidechains, but
this is very minimal, and certainly does not include the transaction
data (or arbitrary messages) of the sidechain.
>
>
>>>seems to me that your OP_is_h_in_coinbase should scan a series of
> sidechain block headers backed by mainchain (meaning at the minimum that
> sidechains should have some common header format prefix), rather than
> just mainchain depth as your article seems to imply.
>>
>>How would security be improved as a result? In either case, 51% of
> hashrate can cause a reorg. The sidechain software itself does scan
> block headers, of course.
>
> I misunderstand the purpose of your OP_is_h_in_coinbase, sorry.
>
No problem.
>
>>>Blind merged mining seems strictly inferior ... a rich attacker can
> simply reorg the sidechain outright without playing such games.
>>
>>In the future, when there is no block subsidy, a rich attacker can also
> do that in mainchain Bitcoin.
>
> I see. However, block subsidies will drop far in the future, do you
> mean to say, that sidechains will be used only in the far future?
In one sense, I mean "you have already endorsed this 'fees only will
work' premise, by endorsing Bitcoin".
In another sense I mean "isn't it great that you will get a tiny
preview, today, of future-Bitcoin's behavior?".
>
>>>How does your proposal handle multiple side block creators on the same
> sidechain, with the possibility that chain splits occur?
>>
>>The side block is only "mined" if it is committed to in a mainchain
> Bitcoin blog, and each mainchain block can only contain one block per
> sidechain. In this way, drivechain sidechains are different from
> classical Namecoin merged mining (where one _could_ run the entire
> system, mining included, without interfacing with Bitcoin at all).
>
> I assume you mean "mainchain Bitcoin block" here.
>
> What mechanism ensures only one mainchain block can contain only one
> sidechain block? It seems, this isn't implemented by OP_BRIBE yet. Can
> you elaborate on this mechanism?
That mechanism is enforced by drivechain itself, not OP_BRIBE. (OP Bribe
is itself only ~half of BMM. I admit it is getting a little confusing.)
Drivechain requires a soft fork to add each new sidechain. It requires
this literally for a few good reasons...but the best is: there is an
implicit requirement that the miners not steal from the sidechain
anyway. In this way drivechain knows how to keep track of what it should
expect.
>
>
>>>Regarding your dig about people who dislike data centers, the main
> issue with miners blindly accepting sidechain commitments is that it
> violates "Don't trust, verify", not that allows datacenters to be
> slightly smaller by not including side:nodes.
>>
>>As I explain early on, in earlier rounds of peer review, the focus was
> on harms the sidechain technology might do to mainchain Bitcoin, and the
> "datacenter point" was specifically the chief objection raised. So I am
> afraid you are entirely incorrect.
>
> I see. It seems, the main problem, is that sidechains can be used to
> sneak in block size increases. Of course, the advantage of sidechains,
> is that when it increases block size irresponsibly, only those who
> participated in the sidechain will suffer.
Precisely.
>
>>In point of fact, the transactions *are* validated...by sidechain full
> nodes, same as Bitcoin proper.
>
> But from blind merge mining by itself, how would the blinded merge miner
> know that there exists an actual sidechain full node that actually did
> validation?
>
> It seems, that the "blinding" in merge mining does not seem to be at all
> useful without the miner actually seeing the sidechain. If you want
> miners to upgrade to side:fullnode as well, what would then be the point
> of blinding? Why not just ordinary merge mining?
>
> Perhaps the datacenter point is simply that your proposal suggests to
> reduce the size of the datacenter by removing surge suppressors and
> UPS's, to avoid some definition of "datacenter is a room with >$XXX of
> equipment".
I hope that my replies above already help with these. If not, let me know.
Thanks for your attention,
Paul

2023-06-07 18:01:30

- reply

📅 Original date posted:2017-05-23
📝 Original message:On 5/23/2017 5:51 AM, Tier Nolan via bitcoin-dev wrote:
> On Mon, May 22, 2017 at 9:00 PM, Paul Sztorc <truthcoin at gmail.com
> <mailto:truthcoin at gmail.com>> wrote:
>
> I would replace "Bitcoins you manage to steal" with "Bitcoins you
> manage to double-spend". Then, it still seems the same to me.
>
>
> With double spending, you can only get ownership of coins that you owned
> at some point in the past. Coins that are owned by someone else from
> coinbase to their current owners cannot be stolen by a re-org (though
> they can be moved around).
I'm not sure it makes much of a difference. First of all, in point of
fact, the miners themselves own the coins from the coinbase. But more
importantly, even if miners did not explicitly own the coins, they might
profit by being bribed -- these bribes would come from people who did
own the coins.
The principle is that value "v' has been taken from A and given to B.
This is effectively coercive activity, and therefore itself has value
proportional to 'v'.
>
> With BMM, you can take the entire reserve. Creating a group of double
> spenders can help increase the reward.
>
>
>
> It may destroy great value if it shakes confidence in the sidechain
> infrastructure. Thus, the value of the stolen BTC may decrease, in
> addition to the lost future tx fee revenues of the attacked chain.
>
> http://www.truthcoin.info/blog/drivechain/#drivechains-security
> <http://www.truthcoin.info/blog/drivechain/#drivechains-security>
>
>
> That is a fair point. If sidechains are how Bitcoin is scaled, then
> shaking confidence in a side-chain would shake confidence in Bitcoin's
> future.
Yes. The more value _on_ the sidechain, the more abhorrent the malfeasance.
>
> I wasn't thinking of a direct miner 51% attack. It is enough to assume
> that a majority of the miners go with the highest bidder each time.
What do you think of my argument, that we already labor under such an
assumption? An attacker could pay fees today equal to greater than
sum(blockreward_(last N block)). According to you this would force a
reorg, even on mainchain (pre-sidechain) Bitcoin. Yet this has never
happened.
It seems that this argument fully reduces to the "what will happen when
the block subsidy falls to zero" question.
>
> If (average fees) * (timeout) is less than the total reserves, then it
> is worth it for a 3rd party to just bid for his theft fork. Miners
> don't have to be assumed to be coordinating, they just have to be
> assumed to take the highest bid.
>
> Again, I don't really think it is that different. One could
> interchange "recent txns" (those which could be double-spent within
> 2-3 weeks) with "sidechain deposit tnxs".
>
>
> It is not "recent txns", it is recent txns that you (or your group) have
> the key for. No coordination is required to steal the entire reserve
> from the sidechain.
See above (?) for why I still feel they are comparable, if not identical.
>
> Recent txns and money on the sidechain have the property that they are
> riskier than money deep on the main chain. This is the inherent point
> about sidechains, so maybe not that big a deal.
Yes. Sidechains have newer, more interesting features, and
simultaneously more risk.
>
> My concern is that you could have a situation where an attack is
> possible and only need to assume that the miners are indifferent.
Again, I think that we _already_ need to eliminate any assumption of
"charitable miners".
>
> If the first attacker who tries it fails (say after creating a fork that
> is 90% of the length required, so losing a lot of money), then it would
> discourage others. If he succeeds, then it weakens sidechains as a
> concept and that creates the incentive for miners to see that he fails.
>
> I wonder how the incentives work out. If a group had 25% of the money
> on the sidechain, they could try to outbid the attacker.
Yes, we may see interesting behavior where people buy up these
liabilities using the LN. In my original post, I mention that miners
themselves may purchase these liabilities (at competitive rates, even if
these arent the idealized 1:1). At this point, miners would be paying
themselves and there would be no agency problem.
>
> In fact, since the attacker, by definition, creates an illegal fork, the
> effect is that he reduces the block rate for the side chain (possibly to
> zero, if he wins every auction). This means that there are more
> transactions per block, if there is space, or more fees per transaction,
> if the blocks are full.
>
> In both cases, this pushes up the total fees per block, so he has to pay
> more per block, weakening his attack. This is similar to where
> transaction spam on Bitcoin is self-correcting by increasing the fees
> required to keep the spam going.
>
> Is there a description of the actual implementation you decided to go
> with, other than the code?
If you haven't seen http://www.truthcoin.info/blog/drivechain/ , that is
probably the most human-readable description.
Cheers,
Paul

2023-06-07 18:01:30

- reply

📅 Original date posted:2017-05-22
📝 Original message:On May 22, 2017 3:13 PM, "Tier Nolan via bitcoin-dev" <bitcoin-dev at lists.
linuxfoundation.org> wrote:
On Mon, May 22, 2017 at 5:19 PM, Paul Sztorc via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> In the future, when there is no block subsidy, a rich attacker can also do
> that in mainchain Bitcoin.
>
I don't think they are the same.
With Bitcoin, you only get to reverse recent transactions. If you actually
reversed 2-3 weeks of transactions, then the Bitcoin price would fall,
destroying the value of the additional coins you managed to obtain. Even
if their was no price fall, you can only get a fraction of the total.
I would replace "Bitcoins you manage to steal" with "Bitcoins you manage to
double-spend". Then, it still seems the same to me.
With BMM, you can "buy" the entire reserve of the sidechain by paying
(timeout) * (average tx fees). If you destroy a side-chain's value, then
that doesn't affect the value of the bitcoins you manage to steal.
It may destroy great value if it shakes confidence in the sidechain
infrastructure. Thus, the value of the stolen BTC may decrease, in addition
to the lost future tx fee revenues of the attacked chain.
http://www.truthcoin.info/blog/drivechain/#drivechains-security
In my view, sidechains should only exist at all if they positively impact
Bitcoin's value. It is therefore desirable for miners to steal from chains
that provide no value-add.
> In point of fact, the transactions *are* validated...by sidechain full
> nodes, same as Bitcoin proper.
>
>
The big difference is that Bitcoin holds no assets on another chain. A
side-chain's value is directly linked to the fact that it has 100% reserves
on the Bitcoin main chain. That can be targeted for theft.
Again, I don't really think it is that different. One could interchange
"recent txns" (those which could be double-spent within 2-3 weeks) with
"sidechain deposit tnxs".
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170522/8a42bd04/attachment.html>

2023-06-07 18:01:29

- reply

📅 Original date posted:2017-05-22
📝 Original message:On May 22, 2017 10:39 AM, "ZmnSCPxj" <ZmnSCPxj at protonmail.com> wrote:
Good morning Paul,
I read only http://www.truthcoin.info/blog/blind-merged-mining/
>From just this document, I can't see a good justification for believing
that a main->side locking transaction can be safely spent into a side->main
unlocking transaction. Do you have a better explanation?
Yes, a better explanation is in the drivechain spec, at:
http://www.truthcoin.info/blog/drivechain/
What you read is only an introduction of BMM. You may also consult the
notes (at the bottom of the BMM post) or the code, although this is time
consuming of course.
If I attempt to spend a main->side locking transaction on the basis of a
"mistaken" side block #49, what prevents me from this sequence:
The literal answer to your question is that mainchain Bitcoin will notice
that, for the second withdrawal, the sum of the inputs is less than the sum
of the outputs and they the transaction is therefore invalid.
1. Put a side:side->main transaction into a block together with TheDAO's
hacked money.
So far, the only good side->main transfer I know of is in Blockstream's
original sidechains paper, with the main:side->main transaction ... Is your
proposal at the technical level actually similar, or does it truly seem to
be riskier?
I feel that my proposal is more secure, as it can operate healthily and
quickly while using spv proofs which are much slower and much much easier
to audit.
seems to me that your OP_is_h_in_coinbase should scan a series of sidechain
block headers backed by mainchain (meaning at the minimum that sidechains
should have some common header format prefix), rather than just mainchain
depth as your article seems to imply.
How would security be improved as a result? In either case, 51% of hashrate
can cause a reorg. The sidechain software itself does scan block headers,
of course.
Blind merged mining seems strictly inferior ... a rich attacker can simply
reorg the sidechain outright without playing such games.
In the future, when there is no block subsidy, a rich attacker can also do
that in mainchain Bitcoin.
Or is your proposal strictly for centralized sidechains, where only one
entity creates side blocks?
Not at all.
How does your proposal handle multiple side block creators on the same
sidechain, with the possibility that chain splits occur?
The side block is only "mined" if it is committed to in a mainchain Bitcoin
blog, and each mainchain block can only contain one block per sidechain. In
this way, drivechain sidechains are different from classical Namecoin
merged mining (where one _could_ run the entire system, mining included,
without interfacing with Bitcoin at all).
Regarding your dig about people who dislike data centers, the main issue
with miners blindly accepting sidechain commitments is that it violates
"Don't trust, verify", not that allows datacenters to be slightly smaller
by not including side:nodes.
As I explain early on, in earlier rounds of peer review, the focus was on
harms the sidechain technology might do to mainchain Bitcoin, and the
"datacenter point" was specifically the chief objection raised. So I am
afraid you are entirely incorrect.
In point of fact, the transactions *are* validated...by sidechain full
nodes, same as Bitcoin proper.
Paul
Regards,
ZmnSCPxj
Sent with ProtonMail Secure Email.
-------- Original Message --------
Subject: [bitcoin-dev] Drivechain -- Request for Discussion
Local Time: May 22, 2017 6:17 AM
UTC Time: May 22, 2017 6:17 AM
From: bitcoin-dev at lists.linuxfoundation.org
To: Bitcoin Dev <bitcoin-dev at lists.linuxfoundation.org>
Dear list,
I've been working on "drivechain", a sidechain enabling technology, for
some time.
* The technical info site is here: www.drivechain.info
* The changes to Bitcoin are here:
https://github.com/drivechain-project/bitcoin/tree/mainchainBMM
* A Blank sidechain template is here:
https://github.com/drivechain-project/bitcoin/tree/sidechainBMM
As many of you know, I've been seeking feedback in person, at various
conferences and meetups over the past year, most prominently Scaling
Milan. And I intend to continue to seek feedback at Consensus2017 this
week, so if you are in NYC please just walk up and start talking to me!
But I also wanted to ask the list for feedback. Initially, I was
hesitant because I try not to consume reviewers' scarce time until the
author has put in a serious effort. However, I may have waiting too
long, as today it is actually quite close to a working release.
Scaling Implications
---------------------
This upgrade would have significant scaling implications. Since it is
the case that sidechains can be added by soft fork, and since each of
these chains will have its own blockspace, this theoretically removes
the blocksize limit from "the Bitcoin system" (if one includes
sidechains as part of such a system). People who want a LargeBlock
bitcoin can just move their BTC over to such a network [1], and their
txns will have no longer have an impact on "Bitcoin Core". Thus, even
though this upgrade does not actually increase "scalability" per se, it
may in fact put an end to the scalability debate...forever.
This work includes the relatively new concept of "Blind Merged Mining"
[2] which I developed in January to allow SHA256^2 miners to merge-mine
these "drivechains", even if these miners aren't running the actual
sidechain software. The goal is to prevent sidechains from affecting the
levelness of the mining "playing field". BMM is conceptually similar to
ZooKeeV [3] which Peter Todd sketched out in mid-2013. BMM is not
required for drivechain, but it would address some of the last remaining
concerns.
Total Transaction Fees in the Far Future
-----------------------------------------
Some people feel that a maximum blocksize limit is needed to ensure that
future total equilibrium transaction fees are non-negligible. I
presented [4] on why I don't agree, 8 months ago. The reviewers I spoke
to over the last year have stopped bringing this complaint up, but I am
not sure everyone feels that way.
Juxtaposition with a recent "Scaling Compromise"
-------------------------------------------------
Recently, a scalability proposal began to circulate on social media. As
far as I could tell, it goes something like "immediately activate
SegWit, and then HF to double the nonwitness blockspace to 2MB within 12
months". But such a proposal is quite meager, compared to a "LargeBlock
Drivechain". The drivechain is better on both fronts, as it would not
require a hardfork, and could *almost immediately* add _any_ amount of
extra blockspace (specifically, I might expect a BIP101-like LargeBlock
chain that has an 8 MB maxblocksize, which doubles every two years).
In other words, I don't know why anyone would support that proposal over
mine. The only reasons would be either ignorance (ie, unfamiliarity with
drivechain) or because there are still nagging unspoken complaints about
drivechain which I apparently need to hear and address.
Other Thoughts
---------------
Unfortunately, anyone who worked on the "first generation" of sidechain
technology (the skiplist) or the "second generation" (federated /
Liquid), will find that this is very different.
I will admit that I am very pessimistic about any conversation that
involves scalability. It is often said that "talking politics lowers
your IQ by 25 points". Bitcoin scalability conversations seem to drain
50 points. (Instead of conversing, I think people should quietly work on
whatever they are passionate about until their problem either is solved,
or it goes away for some other reason, or until we all agree to just
stop talking about it.)
Cheers,
Paul
[1] http://www.drivechain.info/faq/#can-sidechains-really-help-with-scaling
[2] http://www.truthcoin.info/blog/blind-merged-mining/
[3] https://s3.amazonaws.com/peter.todd/bitcoin-wizards-13-10-17.log
[4]
https://www.youtube.com/watch?v=YErLEuOi3xU&list=PLw8-
6ARlyVciNjgS_NFhAu-qt7HPf_dtg&index=4
_______________________________________________
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/20170522/1d29ff66/attachment-0001.html>

2023-06-07 18:01:27

- reply

📅 Original date posted:2017-05-30
📝 Original message:Hi Peter,
Responses below.
On 5/28/2017 5:07 PM, Peter Todd wrote:
> On Mon, May 22, 2017 at 05:30:46PM +0200, Paul Sztorc wrote:
>> Surprisingly, this requirement (or, more precisely, this incentive) does
>> not effect miners relative to each other. The incentive to upgrade is only
>> for the purpose of preventing a "theft" -- defined as: an improper
>> withdrawal from a sidechain. It is not about miner revenues or the ability
>> to mine generally (or conduct BMM specifically). The costs of such a theft
>> (decrease in market price, decrease in future transaction fee levels) would
>> be shared collectively by all future miners. Therefore, it would have no
>> effect on miners relative to each other.
>
> That's not at all true. If I'm a miner with a better capability than another
> miner to prevent that theft, I have reasons to induce it to happen to give me
> political cover to pushing that other miner off the network.
Miners can abstain from 'voting', which is politically neutral. Or, if
they wish, smaller miners could acquiesce to the coercion and just copy
the votes of the attacking 51% group. For users who are only running
Bitcoin Core, there is nothing bad about that.
As you say, a 51% group can arbitrarily start orphaning the blocks that
are mined by non-member rivals. This _may_ be a problem, or it may not,
but it is not exacerbated by drivechain.
So, what exactly is "not at all true"?
>
> This is a very similar problem to what we had with zeroconf double-spending,
> where entities such as Coinbase tried to pay off miners to guarantee something
> that wasn't possible in a geninely decrentralized system: safe zeroconf
> transactions.
I don't see what you mean here. You can't stop Coinbase from donating
BTC to a subset of miners. That will always be possible, and it has
nothing to do with drivechain (as I see it).
>
>> Moreover, miners have other recourse if they are unable to run the node.
>> They can adopt a policy of simply rejecting ("downvoting") any withdrawals
>> that they don't understand. This would pause the withdraw process until
>> enough miners understand enough of what is going on to proceed with it.
>
> Why are you forcing miners to run this code at all?
Could we not say the same thing about the code behind CLTV?
The nature of a contract, is that people are happier to be bound by some
rules that they themselves construct (for example, a nuclear
non-proliferation treaty).
In this case, miners prefer sidechains to exist (as existence makes the
BTC they mine more valuable, and provides additional tx fee revenues),
and so they would like to run code which makes them possible.
>
> Equally, you're opening up miners to huge political risks, as rejecting all
> withdrawals is preventing users' from getting their money, which gives other
> miners a rational for kicking those miners off of Bitcoin entirely.
As I explained above, miners can abstain from voting, which is
politically neutral, or else they can delegate their vote to an
aggressive miner. The "51% can orphan" concern could be raised, even in
a world without drivechain. All that is required, is for the miners to
be anonymous, or in private 'dark' pools (and to thereby escape censure).
But there is a much bigger issue here, which is that our threat models
are different.
As you may know, my threat model [1] does not include miners "pushing
each other off". It only cares about the miner-experience, to the extent
that it impacts the user-experience.
Moreover, I reject [2] the premise that we can even measure "miner
centralization", or even that such a concept exists. If someone has a
definition of this concept, which is both measurable and useful, I would
be interested to read it.
( For what it's worth, Satoshi did not care about this, either. For
example: "If a greedy attacker is able to assemble more CPU power than
all the honest nodes, he...ought to find it more profitable to play by
the rules." which implies robustness to 51% owned by one entity. )
[1] http://www.truthcoin.info/blog/mining-threat-equilibrium/
[2] http://www.truthcoin.info/blog/mirage-miner-centralization/
>
>> Finally, the point in dispute is a single, infrequent, true/false question.
>> So miners may resort to semi-trusted methods to supplement their decision.
>> In other words, they can just ask people they trust, if the withdrawal is
>> correct or not. It is up to users to decide if they are comfortable with
>> these risks, if/when they decide to deposit to a sidechain.
>
> Why do you think this will be infrequent? Miners with a better ability to
> validate the drivechain have every reason to make these events more frequent.
It is part of the spec. These timing parameters must be agreed upon when
the sidechain is added, ie _before_ users deposit to the sidechain. Once
the sidechain is created, the timing is enforced by nodes, the same as
with any other protocol rules. Miner-validation-ability has no effect on
the frequency.
>
>> It is a matter of comparing the costs and benefits. Ignoring theft, the
>> costs are near-zero, and the benefits are >0. Specifically, they are: a
>> higher BTC price and greater transaction fees. Theft is discouraged by
>> attempting to tie a theft to a loss of confidence in the miners, as
>> described in the spec/website.
>> In general the incentives are very similar to those of Bitcoin itself.
>
> This is also a very dubious security model - I would argue that Bitcoin is much
> *more* valuable if miners do everything they can to ensure that drivechains
> fail, given the huge risks involved.
I don't see how. Users are free to ignore the sidechain, so it can only
benefit them.
Fortunately for you, if that is actually what miners believe, then there
will be no problem, as miners will just filter out drivechains (so that
Bitcoin will be "much *more* valuable"), which they can easily do.
> I would also argue that users should do
> user-activated-soft-forks to ensure they fail.
Again, I don't think that kind of UASF can succeed, because one option
strictly dominates the other. But the users get the final say, of course.
Empirically, I have observed overwhelming support for sidechains among
users, business, and other developers. The btc-investors I spoke to were
all very excited about the prospect of sidechains, even more so than
they were excited about SegWit.
>
> By comparison, note Adam Back and my own efforts to ensure miners have a
> smaller part in the ecosystem, with things like committed (encrypted)
> transactions and my closed-seal-set/truth-list approach(1). We want to involve
> miners as little as possible in the consensus, not more.
I agree that miners should have as little influence as possible (and
they probably agree, as well). But a 51% group can filter any message
they like from the blockchain. For sidechains, there will need to be two
public networks, so concealment is not an option.
And, I repeat, for regular users of Bitcoin Core, drivechain does not
make a 51% group more dangerous than they already are.
Moreover, there are cases [1] where miner-involvement can make a big
_positive_ impact. Just as it can be beneficial (essential, in fact) for
Bitcoin to filter out harmful interactions among txns (in other words,
good for miners to filter out double spends), I have discovered
situations where it is beneficial and essential for miners to filter out
harmful interactions among multiple chains.
So I think I am actually hitting the "as little as possible" target.
[1] http://www.truthcoin.info/blog/wise-contracts/#wise-contracts
>
> I have to ask: What use-cases do you actually see for drivechains? Why can't
Here is a tentative project list:
http://www.drivechain.info/projects/index.html
And, as I say on the FAQ, "If each individual user is free to sell
his/her BTC in exchange for an Altcoin (or for fiat), we can hardly deny
users the opportunity to move their money between two sidechains."
So, in a strong way, the entire altcoin market makes the case for a
usefulness of sidechains. Bitcoin is a form of money, and only one form
of money can exist per currency area. So, if Bitcoin is not the winner,
it will eventually cease to exist altogether. Altcoin-competition is an
existential threat to Bitcoin, one which is far more relevant than
anything you've presented so far.
Secondly, one important value of permissionless innovation is that one
doesn't really know, today, what cool ideas other people are going to
come up with tomorrow. If you did, they'd be today's ideas.
Third, Core's review process has two opposite problems: on one hand it
is slow and grueling, and on the other it is fraught with the
possibility of catastrophic error. It would be better, for everyone, to
allow people to try their own (non-aggressive) experiments, and to make
their own mistakes. Already, I have seen the review process abused to
create/maintain fiefdoms of expertise, so that the abusers can extract
money from clients/employers/VCs.
Just think of all of the free time you would have, Peter, if you didn't
have to spend it all reviewing these projects!
> those use-cases be done in the much safer client-side validation fashion?
? How is drivechain _not_ within the category of client-side validation?
With BMM, validation is only performed by those users ("clients") who
opt-in to the new features. The economic model of BMM is directly
comparable to that of Bitcoin's PoW -- the highest-bid chain should be
the healthiest one.
Can you post the Github link for your most up-to-date client-side
validation work so that we can compare the safety and other features?
Thanks,
Paul
>
> 1) https://petertodd.org/2016/closed-seal-sets-and-truth-lists-for-privacy
>

2023-06-07 18:01:26

- reply

📅 Original date posted:2017-05-22
📝 Original message:Charlie, I'll be mostly in the tech track, of course. And I've already
planned to meet RSK guys after their event tomorrow.
Ryan, the more review the better. We aren't in any direct rush, other than
the natural desire to have cool things as early as possible.
Peter, responses below:
On May 22, 2017 9:33 AM, "Peter Todd" <pete at petertodd.org> wrote:
On Mon, May 22, 2017 at 02:17:07AM -0400, Paul Sztorc via bitcoin-dev wrote:
> This work includes the relatively new concept of "Blind Merged Mining"
> [2] which I developed in January to allow SHA256^2 miners to merge-mine
> these "drivechains", even if these miners aren't running the actual
> sidechain software. The goal is to prevent sidechains from affecting the
> levelness of the mining "playing field". BMM is conceptually similar to
> ZooKeeV [3] which Peter Todd sketched out in mid-2013. BMM is not
> required for drivechain, but it would address some of the last remaining
> concerns.
Thanks for the credit, although I think the security properties of what
you're
proposing are very different - and much weaker - than what I proposed in
Zookeyv.
As you state in [2] "if miners never validate sidechains at all, whoever
bids
the most for the chain (on a continuous basis), can spam a 3-month long
stream
of invalid headers, and then withdraw all of the coins deposited to the
sidechain." and "Since the mining is blind, and the sidechain-withdrawal
security-level is SPV, miners who remain blind forever have no way of
telling
who “should” really get the funds."
Finally, you suggest that in this event, miners *do* have to upgrade to a
full
node, an expensive and time-consuming operation (and one that may be
impossible
for some miners if necessary data isn't available).
Surprisingly, this requirement (or, more precisely, this incentive) does
not effect miners relative to each other. The incentive to upgrade is only
for the purpose of preventing a "theft" -- defined as: an improper
withdrawal from a sidechain. It is not about miner revenues or the ability
to mine generally (or conduct BMM specifically). The costs of such a theft
(decrease in market price, decrease in future transaction fee levels) would
be shared collectively by all future miners. Therefore, it would have no
effect on miners relative to each other.
Moreover, miners have other recourse if they are unable to run the node.
They can adopt a policy of simply rejecting ("downvoting") any withdrawals
that they don't understand. This would pause the withdraw process until
enough miners understand enough of what is going on to proceed with it.
Finally, the point in dispute is a single, infrequent, true/false question.
So miners may resort to semi-trusted methods to supplement their decision.
In other words, they can just ask people they trust, if the withdrawal is
correct or not. It is up to users to decide if they are comfortable with
these risks, if/when they decide to deposit to a sidechain.
It's unclear to me what the incentive is for miners to do any of this. Could
you explain in more detail what that incentive is?
It is a matter of comparing the costs and benefits. Ignoring theft, the
costs are near-zero, and the benefits are >0. Specifically, they are: a
higher BTC price and greater transaction fees. Theft is discouraged by
attempting to tie a theft to a loss of confidence in the miners, as
described in the spec/website.
In general the incentives are very similar to those of Bitcoin itself.
Paul
> [2] http://www.truthcoin.info/blog/blind-merged-mining/
> [3] https://s3.amazonaws.com/peter.todd/bitcoin-wizards-13-10-17.log
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170522/9bb81395/attachment.html>

2023-06-07 18:01:26

- reply

📅 Original date posted:2017-05-22
📝 Original message:Dear list,
I've been working on "drivechain", a sidechain enabling technology, for
some time.
* The technical info site is here: www.drivechain.info
* The changes to Bitcoin are here:
https://github.com/drivechain-project/bitcoin/tree/mainchainBMM
* A Blank sidechain template is here:
https://github.com/drivechain-project/bitcoin/tree/sidechainBMM
As many of you know, I've been seeking feedback in person, at various
conferences and meetups over the past year, most prominently Scaling
Milan. And I intend to continue to seek feedback at Consensus2017 this
week, so if you are in NYC please just walk up and start talking to me!
But I also wanted to ask the list for feedback. Initially, I was
hesitant because I try not to consume reviewers' scarce time until the
author has put in a serious effort. However, I may have waiting too
long, as today it is actually quite close to a working release.
Scaling Implications
---------------------
This upgrade would have significant scaling implications. Since it is
the case that sidechains can be added by soft fork, and since each of
these chains will have its own blockspace, this theoretically removes
the blocksize limit from "the Bitcoin system" (if one includes
sidechains as part of such a system). People who want a LargeBlock
bitcoin can just move their BTC over to such a network [1], and their
txns will have no longer have an impact on "Bitcoin Core". Thus, even
though this upgrade does not actually increase "scalability" per se, it
may in fact put an end to the scalability debate...forever.
This work includes the relatively new concept of "Blind Merged Mining"
[2] which I developed in January to allow SHA256^2 miners to merge-mine
these "drivechains", even if these miners aren't running the actual
sidechain software. The goal is to prevent sidechains from affecting the
levelness of the mining "playing field". BMM is conceptually similar to
ZooKeeV [3] which Peter Todd sketched out in mid-2013. BMM is not
required for drivechain, but it would address some of the last remaining
concerns.
Total Transaction Fees in the Far Future
-----------------------------------------
Some people feel that a maximum blocksize limit is needed to ensure that
future total equilibrium transaction fees are non-negligible. I
presented [4] on why I don't agree, 8 months ago. The reviewers I spoke
to over the last year have stopped bringing this complaint up, but I am
not sure everyone feels that way.
Juxtaposition with a recent "Scaling Compromise"
-------------------------------------------------
Recently, a scalability proposal began to circulate on social media. As
far as I could tell, it goes something like "immediately activate
SegWit, and then HF to double the nonwitness blockspace to 2MB within 12
months". But such a proposal is quite meager, compared to a "LargeBlock
Drivechain". The drivechain is better on both fronts, as it would not
require a hardfork, and could *almost immediately* add _any_ amount of
extra blockspace (specifically, I might expect a BIP101-like LargeBlock
chain that has an 8 MB maxblocksize, which doubles every two years).
In other words, I don't know why anyone would support that proposal over
mine. The only reasons would be either ignorance (ie, unfamiliarity with
drivechain) or because there are still nagging unspoken complaints about
drivechain which I apparently need to hear and address.
Other Thoughts
---------------
Unfortunately, anyone who worked on the "first generation" of sidechain
technology (the skiplist) or the "second generation" (federated /
Liquid), will find that this is very different.
I will admit that I am very pessimistic about any conversation that
involves scalability. It is often said that "talking politics lowers
your IQ by 25 points". Bitcoin scalability conversations seem to drain
50 points. (Instead of conversing, I think people should quietly work on
whatever they are passionate about until their problem either is solved,
or it goes away for some other reason, or until we all agree to just
stop talking about it.)
Cheers,
Paul
[1] http://www.drivechain.info/faq/#can-sidechains-really-help-with-scaling
[2] http://www.truthcoin.info/blog/blind-merged-mining/
[3] https://s3.amazonaws.com/peter.todd/bitcoin-wizards-13-10-17.log
[4]
https://www.youtube.com/watch?v=YErLEuOi3xU&list=PLw8-6ARlyVciNjgS_NFhAu-qt7HPf_dtg&index=4

2023-06-07 17:52:04

- 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:50:08

- reply

📅 Original date posted:2016-04-20
📝 Original message:Dear list,
This message concerns pegged "sidechains", namely the Two Way Peg [1].
Specifically, it is to introduce a new OP Code (perhaps called
"OP_CheckVotesVerify"). This OP code can be deployed by soft fork, and
has (as we all probably know) many benefits, including:
1. ("Optional hard forks") Sidechains allow 'opt in' adoption of new
features. As a result, Bitcoin (the bearer asset, not the software) will
never need to worry about competing with an alternate system. This
includes competitors such as Ripple or Ethereum (supposedly
"innovative"), as well as BitcoinXT and Bitcoin Classic (supposedly
"popular").
2. ("Staging Upgrades") SCs allow complex updates to Bitcoin to be
tested, in a realistic environment (where actual BTC are at risk, and
utilizing actual network mining resources). If these updates fail, they
can be revised; if they succeed, they can be incorporated into the
mainchain.
3. Directing "blockchain resources" to Bitcoin. This includes money,
developer talent, public attention, etc.
4. Less time spent debating controversial features. Instead, we return
to a culture of "permissionless innovation".
Again, as we all know, the concept has generally received high interest
and favorable appraisal.
--
However, this feature has highly complex effects on the Bitcoin
ecosystem, and so the details should command our full attention.
First, the deployment of this OP Code involves new block validation
rules ("Drivechain") which are described on my blog [2].
In addition to that post, I intend to release short presentations:
1. On the overall design justification.
2. On "Enforcing Limits on Shared Resources". This explores the
potential for SCs to have a detrimental effect on users of vanilla BTC,
and how this proposal confronts these problems.
3. On the governance of SCs-- aka the degree of 'coupling',
inter-relatedness, and/or hierarchy --- and how Drivechain's design acts
to maximize the total value of the "chain portfolio".
My purpose, in emailing today, is to begin the conversation. The scope
of the concept is simply too large, to draft a readable BIP without
knowing what the actual points of interest are. Please express your
reactions!
Thank you for reading,
Paul
P.S. In assessing the proposal, you may find a recent technical paper
[3] by Sergio Demian Lerner to be of interest.
--
[1]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-March/004724.html
[2] http://www.truthcoin.info/blog/drivechain/
[3] http://www.rootstock.io/#resources (
https://uploads.strikinglycdn.com/files/27311e59-0832-49b5-ab0e-2b0a73899561/Drivechains_Sidechains_and_Hybrid_2-way_peg_Designs_R9.pdf
)

2023-06-07 17:49:38

- reply

📅 Original date posted:2016-03-09
📝 Original message:On 3/9/2016 3:18 PM, Henning Kopp via bitcoin-dev wrote:
> Hi,
>
> > However, I think it could actually increase
> > confidence in the system if the community is able to demonstrate a good
> > process for making such decisions, and show that we can separate the
> > meaningful underlying principles, such as the coin limit and overall
> > inflation rate, from what is more akin to an implementation detail, as I
> > consider the large-step reward reduction to be.
>
> I do not think that a line can be drawn here. As far as I understood,
> you think that the coin limit is a meaningful underlying principle
> which should not be touched, whereas the halving of mining rewards is
> an implementation detail. The two are very closely tied together and
> changes to both of them would result in a hardfork, if I am not
> mistaken.
I believe that you are mistaken.
The two are almost-completely unrelated, and (as Dr. Back has been
pointing out for a very long time now) the halving of mining rewards can
be modified with a soft fork.
http://www.truthcoin.info/blog/mining-heart-attack/#smooth-the-disinflation-out

2023-06-07 17:49:36

- 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

- 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

- 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

- 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:43:26

- reply

📅 Original date posted:2015-10-14
📝 Original message:On 10/14/2015 6:37 PM, s7r wrote:
> On 10/14/2015 6:19 PM, Paul Sztorc wrote:
> > LN transactions are a substitute good for on-chain transactions.
>
> > Therefore, demand for on-chain transactions will decrease as a
> > result of LN, meaning that fees will be lower than they would
> > otherwise be.
>
> > However, the two are also perfect compliments, as LN transactions
> > cannot take place at all without periodic on-chain transactions.
>
> > The demand for *all* Bitcoin transactions (LN and otherwise) is
> > itself a function of innumerable factors, one of which is the
> > question "Which form of money [Bitcoin or not-Bitcoin] do I think
> > my trading partners will be using?". By supporting a higher rate of
> > (higher-quality) Bitcoin transactions, the net result is highly
> > uncertain, but will probably be that LN actually increases trading
> > fees.
>
> Probably yes. But probably no. Having less hashing power is not good,
> and it's unrelated to scalability and decentralization, it's related
> to security. Of course we could argue that the hashing power is not
> super decentralized at this moment but it's unrelated to the topic.
Who are you talking to? Who said anything about any of this? If you are
talking to me, please don't imply that I don't already know these things.
>
> I'd rather have less decentralized big amount of hashing power as
> opposite to less hashing power.
>
> One theory, very close to yours, is that if Bitcoin transactions
> demand grows so high that we need the lightning network, there should
> be plenty of on chain transactions for miners to collect fees from.
For a given fee amount, LN transactions are worse than on-chain
transactions. So people would only use LN if they preferred cheaper txns.
>
> I haven't yet seen the incentives of everyone involved in lightning
> network (payment channel end points, hub operators, miners, etc.) but
> would it make sense to enforce a % of the fees collected by on payment
> hubs to be spent as miner fees, regardless if the transactions from
> that hub go on the main chain or not?
If you want fees to go up, either decrease supply (lower the blocksize
limit) or increase demand (a popular Bitcoin). There's no need to do
anything roundabout.
Regards,
Paul

2023-06-07 17:43:25

- reply

📅 Original date posted:2015-10-14
📝 Original message:LN transactions are a substitute good for on-chain transactions.
Therefore, demand for on-chain transactions will decrease as a result of
LN, meaning that fees will be lower than they would otherwise be.
However, the two are also perfect compliments, as LN transactions cannot
take place at all without periodic on-chain transactions.
The demand for *all* Bitcoin transactions (LN and otherwise) is itself a
function of innumerable factors, one of which is the question "Which
form of money [Bitcoin or not-Bitcoin] do I think my trading partners
will be using?". By supporting a higher rate of (higher-quality) Bitcoin
transactions, the net result is highly uncertain, but will probably be
that LN actually increases trading fees.
On 10/14/2015 6:14 AM, s7r via bitcoin-dev wrote:
> Hello,
>
> I am reading about the Lightning Network and the BIPs which need to be
> deployed until it can be fully functional. I have to say it's a neat
> solution to scale and have almost instant transactions in a peer 2
> peer, distributed and trustless way. I already knows what the needed
> BIPs are and what each one does, I am curios about the impact this
> will have on miner fees.
>
> If transactions happen in a big percent offchain, and they are only
> broadcasted on the mainchain where funds are moved in or out of the
> lightning network, this means there will be less transactions on the
> mainchain -> less fees collected by the miners. What will happen when
> the block reward will go away? Either the fees for the little amount
> of onchain transactions will increase to unpractical levels, either
> the miners will find it not profitable to keep their hardware plugged
> in to mine, so will leave and the effect will be that the hashing
> power of the network will decrease. Since the network's hashing power
> is a security feature (it makes some attacks impossible or insanely
> expensive) I think it's important to anticipate what will happen in
> this scenario.
> _______________________________________________ > 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/20151014/e035b6d3/attachment.html>

2023-06-07 17:42:38

- 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:40:39

- reply

📅 Original date posted:2015-09-18
📝 Original message:Dear List,
1. Are you sick of hearing about THE BLOCKSIZE?
2. Do you feel that long-settled blocksize issues are coming up again
and again, resulting in duplicated work and communications burnout?
3. Do you feel that, while scalability is important and all, people
should just shut up about it already so that you can talk about X
Feature that you actually spent your time on?
4. Do you ever stop and think: How much *money* was spent for everyone
to travel to Montreal, stay at their hotels, and to rent the conference
venue and broadcasting accommodations? Shouldn't there be a way of just
*purchasing* the information we wanted more directly?
5. Do you feel that the inherent subjectivity of the conversation
encourages “political maneuvers” such as character assassination,
reduction of complex issues to minimal (two) unrepresentative “parties”,
and harassment / threats of violence (for the “greater good”)?
As I presented at the Montreal Conference, there is a way to
substantially improve the discussion. Would you believe that Hal Finney
himself advocated it just seven short years ago?
I happen to know it back-to-front, and the (simple) pieces are already
coded into my own more-complex project Truthcoin.
You could wait for me to hack the pieces together myself (which might
take a long time), or you, a competent/fast C++ developer familiar with
Bitcoin and/or Sidechain-Elements, could talk to me for 30 minutes, and
(depending on your skill level) bang it out in, probably, one weekend.
More details are on the project page ( http://bitcoinblocksize.com/ ),
some technical details are in the Github README.
I have also created a Slack:
https://blocksize-markets.slack.com/messages/general/
Sincerely,
Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150918/7718057d/attachment.html>

2023-06-07 17:37:49

- 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

- reply