Re: [bitcoin-dev] Reducing energy consumption and increasing security at the same time
Hi Cheng, This is an interesting proposal! While the incentive analysis is sound, I have two concerns: ## What if a guy keeps mining easy blocks to launch 51% attacks? With PoLW, a miner can sacrifice the coinbase reward as much as possible to mine blocks faster. If the blockchain follows the longest chain rule, PoLW may make 51% attacks much easier. An easy way of fixing this is to choose the chain with most work rather than most blocks. ## What if the coinbase tx is no longer the majority of mining reward, but the fx fee? This might happen in the future. A possible solution is to limit the number of txs for easy blocks. For example, if a miner chooses to mine blocks N times easier, he can only include txs of which the total size is <= (block_size - metadata_size) / N. Best regards, Runchao > Date: Sun, 8 Dec 2019 11:43:49 +0100 > From: Cheng Wang > To: bitcoin-dev@lists.linuxfoundation.org > Subject: [bitcoin-dev] Reducing energy consumption and increasing > securityat the same time > Message-ID: > > Content-Type: text/plain; charset="utf-8" > > Hi Everyone, > > I would like to share my serious work on reducing the energy consumption of > PoW without sacrificing security. My new type of algorithm is called PoLW. > For a practical system where mining is profitable, PoLW could actually > improve the security of the system. > > The idea is to shift part of the external cost of mining in the physical > world (mainly energy consumption) to the internal cost of the network. In > PoLW, the miners are able to give up part of the coinbase reward so as to > get weight (> 1) for the block hash they produce. The total cost of > generating a new block would still be equal to maximal coinbase reward in > equilibrium. > > I analyzed two algorithms in the paper: linear PoLW and exponential PoLW. > Linear PoLW could reduce energy consumption by a factor close to 1/2 in > equilibrium, while exponential PoLW could reduce energy consumption by an > arbitrary factor in equilibrium. > > In a practical system, mining is usually (if not always) profitable. If we > transition from PoW to PoLW, the external costs of mining would decrease > and the internal costs will increase. However, the decrease in external > costs would be less than the increase in internal costs since mining is > profitable. The total cost of block generation would get higher, therefore, > the security will increase. > > Of course, we could not decrease the external costs of any existing system > by a factor close to zero immediately. There is a section in my paper > discussing this particularly. The principle of applying PoLW is that > keeping the absolute external cost increasing all the time, but the > percentage of external cost in the total cost gets lower eventually. > > This work is based on solid math calculation, and I am looking forward to > feedback and discussions. My paper is available at: > https://github.com/alephium/research/raw/master/polw.pdf > > It's inspired by the recent great paper of Itay, Alexander, and Ittay: > https://arxiv.org/abs/1911.04124 > > Best, > Cheng Wang ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Reducing energy consumption and increasing security at the same time
Hi Everyone, I would like to share my serious work on reducing the energy consumption of PoW without sacrificing security. My new type of algorithm is called PoLW. For a practical system where mining is profitable, PoLW could actually improve the security of the system. The idea is to shift part of the external cost of mining in the physical world (mainly energy consumption) to the internal cost of the network. In PoLW, the miners are able to give up part of the coinbase reward so as to get weight (> 1) for the block hash they produce. The total cost of generating a new block would still be equal to maximal coinbase reward in equilibrium. I analyzed two algorithms in the paper: linear PoLW and exponential PoLW. Linear PoLW could reduce energy consumption by a factor close to 1/2 in equilibrium, while exponential PoLW could reduce energy consumption by an arbitrary factor in equilibrium. In a practical system, mining is usually (if not always) profitable. If we transition from PoW to PoLW, the external costs of mining would decrease and the internal costs will increase. However, the decrease in external costs would be less than the increase in internal costs since mining is profitable. The total cost of block generation would get higher, therefore, the security will increase. Of course, we could not decrease the external costs of any existing system by a factor close to zero immediately. There is a section in my paper discussing this particularly. The principle of applying PoLW is that keeping the absolute external cost increasing all the time, but the percentage of external cost in the total cost gets lower eventually. This work is based on solid math calculation, and I am looking forward to feedback and discussions. My paper is available at: https://github.com/alephium/research/raw/master/polw.pdf It's inspired by the recent great paper of Itay, Alexander, and Ittay: https://arxiv.org/abs/1911.04124 Best, Cheng Wang ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Composable MuSig
Hi ZmnSCPxj, I think you're idea of allowing multiple Rs is a fine solution as it would essentially mean that you were just doing a three party MuSig with more specific communication structure. As you mentioned, this is not quite ideal though. > It seems to me that what is needed for a composable MuSig is to have a > commitment scheme which is composable. Maybe. Showing certain attacks don't work is a first step. It would take some deeper analysis of the security model to figure out what exactly the MuSig requires of the commitment scheme. > To create a commitment `c[A]` on the point A, such that `A = a * G`, the > committer: > > * Generates random scalars `r` and `m`. > * Computes `R` as `r * G`. > * Computes `s` as `r + h(R | m) * a`. > * Gives `c[A]` as the tuple `(R, s)`. This doesn't look binding. It's easy to find another ((A,a),m) which would validate against (R,s). Just choose m and choose a = (s - r) h(R||m)^-1. Cheers, LL ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] easypaysy - A layer-two protocol to send payments without addresses
Hi ZmnSCPxj, >> It seems possible, that, I do not. Haha, I’am starting to believe that’s not a joke ... >> >> This does not seem to mesh well with the other non-Master parts of the >> protocol, where further updates on the single account backed by a funding >> TXO are performed by spending the funding TXO and creating a transaction >> with `OP_RETURN`. >> >> You are right. The lifecycle of a regular easypaysy account states that you spend its TXO circularly as many times as you want, specifying changes in its OP_RETURN (you can’t change the Identity or Value key). When you want to revoke an account, you simply spend its last update (if any) to a different address (not the one it was funded originally with). > How about control transactions on top of the funding txo? > Who is able to make further control transactions? > If the service provider gives the user full control of the control > transactions on top of the funding txo, then it outright loses the money it > put in the funding txo and might as well operate as a full exchange. Nope, he will keep control of the TXO keys. > If the service provider retains even partial control, then it can refuse to > cooperate with the user and the user will be unable to update his or her > account. > > This is not fixable by the use of mirror servers. You are right about that too… (I wonder if some kind of MAST smart contract could fix this, maybe you have a suggestion for this; I am thinking K of M users can override the service provider if he misbehaves) What I have in mind, but haven’t completely figured out, in case of an uncooperative service provider -or just because one user decides to fly solo- is the possibility for a sub-account to ‘detach’ itself from the master account. The sub-account holder would do so by: a) Funding the multisig 2-of-2 address composed of his Id_key + Value_key, included in the common JSON file, not the Master TX. (And yes, in this event he will need to buy some btc, because life is hard...) b) Publishing his own update, much like a regular easypaysy account does. In any case, the account ID never changes, it would always keep pointing to the original place where it appeared on the blockchain. User wallets would have to query for the multisig address of a particular account to check whether the account is detached or not. As as side note, I expect most easypaysy accounts to choose only non-interactive payments, since they have fewer requirements than their interactive counterparts; so -in most cases- the majority of users won’t ever have to update their accounts. So, even if the ‘service provider’ goes away or becomes uncooperative, it is just business as usual for the sub-account owners, and they can work just fine with the mirrors. (Again, all of these is speculative for now. I hope scalability will become an issue for easypaysy one day, but I think we’ll have time to work out the best solution by then) >> In addition, I would like to suggest as well that instead of `OP_RETURN`, >> you could instead use "sign-to-contract”…. I really need to study this further before I can express an informed opinion on your suggestion. On the other hand, for Master accounts I don’t think cost or space should be a problem, since both can be shared among up to 2048 sub-accounts. For regular accounts, it could be. But, based on the private feedback I am having from two prominent figures in the space, making sure the protocol is easy to implement for SPV wallets is essential to encourage wallet adoption. A separate transport layer doesn’t fit well with this. So, maybe your suggestion will become more applicable in future iterations of the protocol. I may request your help for further clarification about this issue, if you are so kind (as you always are). >> d) Regarding your comments on the possibility of adding the output index in >> the account ID, I still don’t see the need for the use case of easypaysy >> (since, by definition, easypaysy accounts must have exactly one input and >> two outputs). > > Do you mean, that if the user makes a control transaction to change the > details of the account, then the user is forced to change the easypaysy > identifier? > > My initial reading of your whitepaper is that the easypaysy identifier refers > to the funding txo that roots the further control transactions. > If so, the funding txo is not necessarily a one-input two-output transaction. > The easypaysy identifier doesn’t point to the funding TXO. Instead it points to the first transaction that spends the funding TXO (the TX with the OP_RETURN containing the ‘Rendezvous descriptor’) So, you are right in that the funding TXO doesn’t need to be a one-input, two-output transaction. > If not, then each time a control transaction changes the details of the > easypaysy identifier, the identifier itself is changed. Nope. The easypaysy identifier always points the placement in the
