Re: [bitcoin-dev] No Order Mnemonic

2022-07-08 Thread Paul Sztorc via bitcoin-dev
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)

Re: [bitcoin-dev] BIP47 Prague Discussion

2022-06-11 Thread Paul Sztorc via bitcoin-dev
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 [Key

Re: [bitcoin-dev] Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

2022-03-04 Thread Paul Sztorc via bitcoin-dev
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

Re: [bitcoin-dev] Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

2022-03-01 Thread Paul Sztorc via bitcoin-dev
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 wh

Re: [bitcoin-dev] Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

2022-02-28 Thread Paul Sztorc via bitcoin-dev
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 m

Re: [bitcoin-dev] Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

2022-02-27 Thread Paul Sztorc via bitcoin-dev
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 channe

Re: [bitcoin-dev] Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

2022-02-27 Thread Paul Sztorc via bitcoin-dev
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

Re: [bitcoin-dev] Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

2022-02-26 Thread Paul Sztorc via bitcoin-dev
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

Re: [bitcoin-dev] A Comparison Of LN and Drivechain Security In The Presence Of 51% Attackers

2022-02-26 Thread Paul Sztorc via bitcoin-dev
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  (p

Re: [bitcoin-dev] A Comparison Of LN and Drivechain Security In The Presence Of 51% Attackers

2022-02-24 Thread Paul Sztorc via bitcoin-dev
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 th

Re: [bitcoin-dev] Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

2022-02-23 Thread Paul Sztorc via bitcoin-dev
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. Mai

Re: [bitcoin-dev] Two Drivechain BIPs

2017-12-12 Thread Paul Sztorc via bitcoin-dev
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 has

Re: [bitcoin-dev] Two Drivechain BIPs

2017-12-12 Thread Paul Sztorc via bitcoin-dev
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

Re: [bitcoin-dev] Two Drivechain BIPs

2017-12-05 Thread Paul Sztorc via bitcoin-dev
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

Re: [bitcoin-dev] Two Drivechain BIPs

2017-12-05 Thread Paul Sztorc via bitcoin-dev
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 mig

Re: [bitcoin-dev] Two Drivechain BIPs

2017-12-04 Thread Paul Sztorc via bitcoin-dev
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 bloc

[bitcoin-dev] Two Drivechain BIPs

2017-12-01 Thread Paul Sztorc via bitcoin-dev
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

Re: [bitcoin-dev] Introducing a POW through a soft-fork

2017-11-06 Thread Paul Sztorc via bitcoin-dev
+1 to all of Peter Todd's comments On Nov 6, 2017 11:50 AM, "Peter Todd via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Wed, Nov 01, 2017 at 05:48:27AM +, Devrandom via bitcoin-dev wrote: > > Some quick thoughts... > > > Hi all, > > > > Feedback is welcome on the draft b

Re: [bitcoin-dev] Generalized sharding protocol for decentralized scaling without Miners owning our BTC

2017-10-10 Thread Paul Sztorc via bitcoin-dev
, 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" wrote: 2017-10-09 22:39 GMT-03:00 Paul Sztorc via bitcoin-dev : > That is only a

Re: [bitcoin-dev] Generalized sharding protocol for decentralized scaling without Miners owning our BTC

2017-10-10 Thread Paul Sztorc via bitcoin-dev
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 ne

Re: [bitcoin-dev] Generalized sharding protocol for decentralized scaling without Miners owning our BTC

2017-10-10 Thread Paul Sztorc via bitcoin-dev
Haha, no. Because you "burned" the coins. On Oct 10, 2017 1:20 AM, "Tao Effect" 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

Re: [bitcoin-dev] Generalized sharding protocol for decentralized scaling without Miners owning our BTC

2017-10-09 Thread Paul Sztorc via bitcoin-dev
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 v

Re: [bitcoin-dev] Fwd: Sidechain headers on mainchain (unification of drivechains and spv proofs)

2017-09-09 Thread Paul Sztorc via bitcoin-dev
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

Re: [bitcoin-dev] Updating the Scaling Roadmap [Update]

2017-07-17 Thread Paul Sztorc via bitcoin-dev
k 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 >

Re: [bitcoin-dev] Updating the Scaling Roadmap [Update]

2017-07-17 Thread Paul Sztorc via bitcoin-dev
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 >&

Re: [bitcoin-dev] Updating the Scaling Roadmap [Update]

2017-07-17 Thread Paul Sztorc via bitcoin-dev
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

Re: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains

2017-07-13 Thread Paul Sztorc via bitcoin-dev
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'

Re: [bitcoin-dev] Drivechain RfD -- Follow Up

2017-07-13 Thread Paul Sztorc via bitcoin-dev
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) > chains

Re: [bitcoin-dev] Drivechain RfD -- Follow Up

2017-07-13 Thread Paul Sztorc via bitcoin-dev
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 ad

Re: [bitcoin-dev] Drivechain RfD -- Follow Up

2017-07-12 Thread Paul Sztorc via bitcoin-dev
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

Re: [bitcoin-dev] Drivechain RfD -- Follow Up

2017-07-12 Thread Paul Sztorc via bitcoin-dev
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 exper

Re: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains

2017-07-12 Thread Paul Sztorc via bitcoin-dev
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 h

Re: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains

2017-07-12 Thread Paul Sztorc via bitcoin-dev
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 w

Re: [bitcoin-dev] Updating the Scaling Roadmap

2017-07-11 Thread Paul Sztorc via bitcoin-dev
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

Re: [bitcoin-dev] Updating the Scaling Roadmap

2017-07-11 Thread Paul Sztorc via bitcoin-dev
On 7/11/2017 5:31 PM, Gregory Maxwell wrote: > On Tue, Jul 11, 2017 at 8:18 PM, Paul Sztorc via bitcoin-dev > 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 contrib

Re: [bitcoin-dev] Updating the Scaling Roadmap

2017-07-11 Thread Paul Sztorc via bitcoin-dev
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,

Re: [bitcoin-dev] Updating the Scaling Roadmap

2017-07-11 Thread Paul Sztorc via bitcoin-dev
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 objection

Re: [bitcoin-dev] Updating the Scaling Roadmap

2017-07-11 Thread Paul Sztorc via bitcoin-dev
On 7/11/2017 5:40 PM, Pieter Wuille wrote: > On Tue, Jul 11, 2017 at 1:36 PM, Paul Sztorc 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 --

Re: [bitcoin-dev] Updating the Scaling Roadmap

2017-07-11 Thread Paul Sztorc via bitcoin-dev
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 v

Re: [bitcoin-dev] Updating the Scaling Roadmap

2017-07-11 Thread Paul Sztorc via bitcoin-dev
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 "disa

Re: [bitcoin-dev] Updating the Scaling Roadmap

2017-07-11 Thread Paul Sztorc via bitcoin-dev
lso 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

[bitcoin-dev] Updating the Scaling Roadmap

2017-07-11 Thread Paul Sztorc via bitcoin-dev
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 De

Re: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains

2017-07-02 Thread Paul Sztorc via bitcoin-dev
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 ear

Re: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains

2017-06-28 Thread Paul Sztorc via bitcoin-dev
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

Re: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains

2017-06-28 Thread Paul Sztorc via bitcoin-dev
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 >> tra

Re: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains

2017-06-28 Thread Paul Sztorc via bitcoin-dev
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,

Re: [bitcoin-dev] Drivechain RfD -- Follow Up

2017-06-23 Thread Paul Sztorc via bitcoin-dev
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

Re: [bitcoin-dev] Drivechain RfD -- Follow Up

2017-06-22 Thread Paul Sztorc via bitcoin-dev
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

Re: [bitcoin-dev] Drivechain RfD -- Follow Up

2017-06-22 Thread Paul Sztorc via bitcoin-dev
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

Re: [bitcoin-dev] Drivechain RfD -- Follow Up

2017-06-20 Thread Paul Sztorc via bitcoin-dev
miners that already > have too much power. > > > On Mon, Jun 19, 2017 at 12:04 PM, Paul Sztorc via bitcoin-dev > <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote: > > Hi Greg, > > Responses below: > > On 6/18/2017 5:30 PM, Tao Effect wrot

Re: [bitcoin-dev] Drivechain RfD -- Follow Up

2017-06-19 Thread Paul Sztorc via bitcoin-dev
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

[bitcoin-dev] Drivechain RfD -- Follow Up

2017-06-10 Thread Paul Sztorc via bitcoin-dev
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

Re: [bitcoin-dev] Drivechain -- Request for Discussion

2017-06-10 Thread Paul Sztorc via bitcoin-dev
gt; 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 > &l

Re: [bitcoin-dev] Drivechain -- Request for Discussion

2017-05-29 Thread Paul Sztorc via bitcoin-dev
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 pu

[bitcoin-dev] Fwd: Re: Drivechain -- Request for Discussion

2017-05-24 Thread Paul Sztorc via bitcoin-dev
Responses below. On 5/23/2017 7:26 PM, ZmnSCPxj wrote: > Good morning, > > >>> >>> How is OP_BRIBE superior to just using a 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, b

Re: [bitcoin-dev] Drivechain -- Request for Discussion

2017-05-23 Thread Paul Sztorc via bitcoin-dev
On 5/23/2017 5:51 AM, Tier Nolan via bitcoin-dev wrote: > On Mon, May 22, 2017 at 9:00 PM, Paul Sztorc > 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

Re: [bitcoin-dev] Drivechain -- Request for Discussion

2017-05-23 Thread Paul Sztorc via bitcoin-dev
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 supp

Re: [bitcoin-dev] Drivechain -- Request for Discussion

2017-05-22 Thread Paul Sztorc via bitcoin-dev
On May 22, 2017 3:13 PM, "Tier Nolan via bitcoin-dev" wrote: On Mon, May 22, 2017 at 5:19 PM, Paul Sztorc via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > In the future, when there is no block subsidy, a rich attacker can also do > that in mainchain

Re: [bitcoin-dev] Drivechain -- Request for Discussion

2017-05-22 Thread Paul Sztorc via bitcoin-dev
On May 22, 2017 10:39 AM, "ZmnSCPxj" 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 transacti

Re: [bitcoin-dev] Drivechain -- Request for Discussion

2017-05-22 Thread Paul Sztorc via bitcoin-dev
low: On May 22, 2017 9:33 AM, "Peter Todd" 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-

[bitcoin-dev] Drivechain -- Request for Discussion

2017-05-22 Thread Paul Sztorc via bitcoin-dev
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://git

[bitcoin-dev] Holdup on Block Alerts / Fraud Proofs ?

2016-07-30 Thread Paul Sztorc via bitcoin-dev
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 pai

[bitcoin-dev] Sidechains pre-BIP Discussion

2016-04-20 Thread Paul Sztorc via bitcoin-dev
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"

Re: [bitcoin-dev] Hardfork to fix difficulty drop algorithm

2016-03-09 Thread Paul Sztorc via bitcoin-dev
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,

Re: [bitcoin-dev] Hardfork to fix difficulty drop algorithm

2016-03-09 Thread Paul Sztorc via bitcoin-dev
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.]

Re: [bitcoin-dev] Hardfork to fix difficulty drop algorithm

2016-03-09 Thread Paul Sztorc via bitcoin-dev
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 immediat

Re: [bitcoin-dev] Hardfork to fix difficulty drop algorithm

2016-03-03 Thread Paul Sztorc via bitcoin-dev
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

Re: [bitcoin-dev] Hardfork to fix difficulty drop algorithm

2016-03-02 Thread Paul Sztorc via bitcoin-dev
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

Re: [bitcoin-dev] Lightning Network's effect on miner fees

2015-10-14 Thread Paul Sztorc via bitcoin-dev
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.

Re: [bitcoin-dev] Lightning Network's effect on miner fees

2015-10-14 Thread Paul Sztorc via bitcoin-dev
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 wi

Re: [bitcoin-dev] This thread is not about the soft/hard fork technical debate

2015-10-05 Thread Paul Sztorc via bitcoin-dev
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. ___ bit

[bitcoin-dev] Improving Blocksize Communication Through Markets

2015-09-18 Thread Paul Sztorc via bitcoin-dev
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 alre

Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft)

2015-08-21 Thread Paul Sztorc via bitcoin-dev
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