Re: [bitcoin-dev] Selfish Mining Prevention
@ Eric: Yes I forgot to mention that cost (in addition to price) also determines the profitability of mining and thus the total hashpower. I disagree with your assessment of merge mining as really what matters is opportunity cost of honestly mining vs attacking, and one reason we are currently safe from other networks attacking is that SHA256 is ASIC friendly and currently the main network utilising this (the ASICs) is Bitcoin mining. It would be hard for people computing prime numbers to quickly switch to Bitcoin mining, since they would need the ASICs. But if you really want to discuss this then I suggest opening a new thread here or bitcointalk since this is off-topic from my thread. Also there is a discussion about merge mining here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-January/003981.html On Mon, Sep 17, 2018 at 2:09 PM, Zawy via bitcoin-dev wrote: > The 51% problem is deep. Any discussion of a solution to it should > begin with a link to an article that shows a profound discovery has > been made. Selfish mining prevention and pollution should be on > bitcoin-discussion, but it appears that list is not active. > > The problem with Andrew's idea below is that it is a positive feedback > loop that amplifies oscillations. If h goes up or down due to price > changes or random solvetime variation, then the net reward goes in the > same direction, which motivates miners to cause h to go even further > in the same direction, which is a positive feedback loop until some > limit is reached. To make matters worse, miner profit motivation in > choosing which coin to mine is a non-linear function: a 30% drop in > difficulty (or 30% increase in this reward function) in an alt coin > can cause a 300% increase in hashrate. > > Average of 144 past blocks to determine h are needed so that it does > not vary too much. A selfish mine of 72 blocks would result in only a > 12.5% loss compared to not using this pro-oscillation function. I've > tried similar reward functions in trying to reduce on-off mining. > > There may also be a problem of issuing too many or too few coins, > depending on how fast h rises in the long term. > > An alternative is to increase difficulty with this or a similar > function instead of reward. From a miner's perspective, there is not a > difference (they are only interested in the (price+fees)/difficulty > ratio. This would have the same problems. @Zawy: Are you talking about my proposal to modulate the subsidies? Because if you read my second post you see that I scrapped that part as it can be disruptive, and I am only proposing to let users have more control over how their fees are spent. A certain portion of fees is put in reserve and gets allocated to miners based on hashrate conditions, and once the "contract" expires, the remaining part goes back to the user for future fee payments. I understand it is unclear whether this will cause a significant benefit (I can work on simulations if I have time), but what could possibly go wrong with giving users more choice over how their fees are spent? Also if you see my post, I am not just trying to prevent Selfish Mining (33%) or 51% attacks, but in general any types of attacks that try to drive away mining competition (like block withholding attacks, networking attacks, etc). Someone on bitcointalk was also worried about a positive feedback loop, and I think my answer remains valid: "First, I think a price drop will be slightly offset by the lower rate of coins being mined. Also, confirmation times will get longer: Both the time to get a block will increase and the number of confirmations needed to have enough work done on the chain so that your transaction is considered safe. The fees would likely rise and this would increase rewards to miners, especially in a fee-market dominated future." Merge mining can also help to smooth hashrate so it doesn't depend so much on price, but even without merge mining it is not so clear that a there would be a destructive feedback loop and that's where simulations / math equations would help. Your idea of increasing difficulty, I haven't thought about much, but I don't think it's the same effect. When you increase the difficulty, the reward per block remains the same, only reward per real time falls, but it could also have the negative effect of incentivizing selfish mining or timestamp attacks to reverse the increased difficulty. Though actually timestamp attacks would sort of be dis-incentivized if underestimates of hashrate led to lower rewards. Obviously I will not work on a pull request if there is no strong interest for this. I think it is a harmless addition, so if I have time I can work on simulations to try to prove that there is a significant benefit with doing this. -- PGP: B6AC 822C 451D 6304 6A28 49E9 7DB7 011C D53B 5647 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org
Re: [bitcoin-dev] Selfish Mining Prevention
> I see what you say, however, since the proposal as I have read it says "And > this will keep happening as long as hashrate keeps rising," - what actually > happens in the case hashrate stagnates or falls? In general, a target hashrate can be set by users (can be less or more than the peak hashrate). As long as hashrate is rising and still didn't reach the target, miners will incrementally get the reserve fees. Once the "contract" times out, the remaining part can be used as fees by the users who created the reserve fee "contract". So if hashrate remains the same or falls, then users get the reserve fees back. I agree that we can't stop people from being greedy. If they are not Bitcoin mining, they will try to put their energy to earn in some other way...The hashrate is related the demand for Bitcoin (price) and the amount of fees/subsidies the miners will get paid. For every level of mining rewards (based on demand) there exists a limit on the hashrate. Once hashrate gets large enough, no new miners (additional hashrate) will want to join since their share of the hashrate is too small to make a profit. Also with merge mining and proof of space we can be quite efficient in the future. But of course I sympathize with the "don't be greedy" philosophy, and it can be good to educate people to use less resources than they need, just I think it's a bit outside of the scope of what the Bitcoin software protocol does. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Selfish Mining Prevention
@Moral Agent: No problem. I did ask in the first post what the current plans are for selfish miner prevention. So if anyone has any other relevant ideas (not just for selfish mining but for making mining more decentralized and competetive), then please post it, but I just prefer to focus on my proposal more than others. @Damian: I think you are concerned that this will incentivize more global resource consumption and will be detrimental to our environment? Personally, I believe centralization of energy does more harm to the environment rather than total energy consumption. If Bitcoin helps "power" to become more decentralized, then I wouldn't be surprised if total (global) energy consumption actually decreases. The debt based economy is forcing us to continuously grow and use up more resources, and collectivism is turning individuals into super-organisms capable of doing much more harm to the environment than can be done by one or a just a few individuals working independently. In my proposal, I actually allow for changing environmental conditions by measuring only the peak hashrate of the past year, and not the full history of blocks. On Sat, Sep 15, 2018 at 5:29 AM, Damian Williamson wrote: >>This "reserve" part of the fee will be paid to miners if the hashrate >> rises. > > > Anticipating ongoing hashrate rise shows that you have not yet thought about > moving outside of the current greed model, a model wherein mining will > consume all available resources within the colony's objective just to spread > as far as possible with each new miner bringing diminishing individual > returns and shortening the life of Earth for no additional gain. Greed model > := bacteria. > > > From: bitcoin-dev-boun...@lists.linuxfoundation.org > on behalf of Andrew via > bitcoin-dev > Sent: Friday, 14 September 2018 9:19:37 AM > To: Bitcoin Dev > Subject: Re: [bitcoin-dev] Selfish Mining Prevention > > I discussed this more at bitcointalk: > https://bitcointalk.org/index.php?topic=4998410.0 > > The attacks I'm interested in preventing are not only selfish mining > and collusion, but also more subtle attacks like block withholding, > and in general anything that aims to drive out the competition in > order to increase hashrate fraction. I also scrapped the idea of > changing the block subsidies, and I am only focuses on fees. > > You can read more about the motivation and details in the bitcointalk > thread, but my proposal in short would be to add the concept of > "reserve fees". When a user makes a transaction, for each txout > script, they can add parameters that specify the fraction of the total > fee that is held in "reserve" and the time it is held in "reserve" > (can set a limit of 2016 blocks). This "reserve" part of the fee will > be paid to miners if the hashrate rises. So if hashrate is currently h > and peak hashrate (from past year) is p, then for each period (1 day), > a new hashrate is calculated h1, and if h1 > h, then the fraction > (h1-h)/p from the reserve fees created in the past 2016 blocks will be > released to miners for that period (spread out over the 144 blocks in > that period). And this will keep happening as long as hashrate keeps > rising, until the "contract" expires, and the leftover part can be > used by the owner of the unspent output, but it can only be used for > paying fees, not as inputs for future transactions (to save on block > space). > > This should incentivize miners to not drive out the competition, since > if they do, there will be less of these reserve fees given to miners. > Yes in the end the miners will get all the fees, but with rising > hashrate they get an unconditional subsidy that does not require > transactions, thus more space for transactions with fees. > > I can make a formal BIP and pull request, but I need to know if there > is interest in this. Now fees don't play such a large part of the > block reward, but they will get more important, and this change > wouldn't force anything (would be voluntary by each user), just miners > have to agree to it with a soft fork (so they don't spend from the > anyone-can-spend outputs used for reserve fees). Resource requirements > for validation are quite small I believe. > > On Sat, Sep 1, 2018 at 12:11 AM, Andrew wrote: >> As I understand, selfish mining is an attack where miners collude to >> mine at a lower hashrate then with all miners working independently. >> What are the current strategies used to prevent this and what are the >> future plans? >> >> One idea I have is to let the block reward get "modulated" according >> to peak hashrate. Say p is the peak hashrate for 365 peri
Re: [bitcoin-dev] Selfish Mining Prevention
(reposting to whole list instead of just him) @Moral Agent: Interesting proposal though it introduces some elements of proof of stake so it would be more controversial in my view. Also, something needs to be explained about how this would not create an attack where difficulty is frequently dropping by 25%, and suddenly we find ourselves with a very low difficulty and PoW attacks can easily happen. I need to analyse your proposal more, but I prefer to discuss it on your blog instead of here just to limit the side topics and focus only on my proposal. No one has yet given me a good reason for why not to support my proposal... On Fri, Sep 14, 2018 at 2:49 PM, Moral Agent wrote: > You might be interested in an idea I wrote about that is in a similar spirit > here: > > https://medium.com/coinmonks/taming-large-miners-with-helper-blocks-6ae67ac242f6 > > From the article: > > When a block is solved, it randomly selects one satoshi from the utxo set > and gives whomever controls that satoshi the power to generate a “Helper > Block”. The Helper Block commits to a subset of transactions for inclusion > in the next block. A miner can accept the Helper Block by including the > suggested transactions and giving the associated transaction fees to a > payment address specified in the Helper Block. Miners who do not use a > Helper Block must satisfy a 25% higher difficulty. > > On Fri, Sep 14, 2018 at 9:56 AM Andrew via bitcoin-dev > wrote: >> >> I discussed this more at bitcointalk: >> https://bitcointalk.org/index.php?topic=4998410.0 >> >> The attacks I'm interested in preventing are not only selfish mining >> and collusion, but also more subtle attacks like block withholding, >> and in general anything that aims to drive out the competition in >> order to increase hashrate fraction. I also scrapped the idea of >> changing the block subsidies, and I am only focuses on fees. >> >> You can read more about the motivation and details in the bitcointalk >> thread, but my proposal in short would be to add the concept of >> "reserve fees". When a user makes a transaction, for each txout >> script, they can add parameters that specify the fraction of the total >> fee that is held in "reserve" and the time it is held in "reserve" >> (can set a limit of 2016 blocks). This "reserve" part of the fee will >> be paid to miners if the hashrate rises. So if hashrate is currently h >> and peak hashrate (from past year) is p, then for each period (1 day), >> a new hashrate is calculated h1, and if h1 > h, then the fraction >> (h1-h)/p from the reserve fees created in the past 2016 blocks will be >> released to miners for that period (spread out over the 144 blocks in >> that period). And this will keep happening as long as hashrate keeps >> rising, until the "contract" expires, and the leftover part can be >> used by the owner of the unspent output, but it can only be used for >> paying fees, not as inputs for future transactions (to save on block >> space). >> >> This should incentivize miners to not drive out the competition, since >> if they do, there will be less of these reserve fees given to miners. >> Yes in the end the miners will get all the fees, but with rising >> hashrate they get an unconditional subsidy that does not require >> transactions, thus more space for transactions with fees. >> >> I can make a formal BIP and pull request, but I need to know if there >> is interest in this. Now fees don't play such a large part of the >> block reward, but they will get more important, and this change >> wouldn't force anything (would be voluntary by each user), just miners >> have to agree to it with a soft fork (so they don't spend from the >> anyone-can-spend outputs used for reserve fees). Resource requirements >> for validation are quite small I believe. >> >> On Sat, Sep 1, 2018 at 12:11 AM, Andrew wrote: >> > As I understand, selfish mining is an attack where miners collude to >> > mine at a lower hashrate then with all miners working independently. >> > What are the current strategies used to prevent this and what are the >> > future plans? >> > >> > One idea I have is to let the block reward get "modulated" according >> > to peak hashrate. Say p is the peak hashrate for 365 periods (1 year) >> > consisting of 144 blocks, h is the hashrate of the last 144 block (1 >> > day) period, and r is the base subsidy (12.5 BTC currently). You can >> > then make the max block reward 0.5 r (1 + h/p). So if hashrate is at >> > peak you get the full reward. Otherwise you get l
Re: [bitcoin-dev] Selfish Mining Prevention
I discussed this more at bitcointalk: https://bitcointalk.org/index.php?topic=4998410.0 The attacks I'm interested in preventing are not only selfish mining and collusion, but also more subtle attacks like block withholding, and in general anything that aims to drive out the competition in order to increase hashrate fraction. I also scrapped the idea of changing the block subsidies, and I am only focuses on fees. You can read more about the motivation and details in the bitcointalk thread, but my proposal in short would be to add the concept of "reserve fees". When a user makes a transaction, for each txout script, they can add parameters that specify the fraction of the total fee that is held in "reserve" and the time it is held in "reserve" (can set a limit of 2016 blocks). This "reserve" part of the fee will be paid to miners if the hashrate rises. So if hashrate is currently h and peak hashrate (from past year) is p, then for each period (1 day), a new hashrate is calculated h1, and if h1 > h, then the fraction (h1-h)/p from the reserve fees created in the past 2016 blocks will be released to miners for that period (spread out over the 144 blocks in that period). And this will keep happening as long as hashrate keeps rising, until the "contract" expires, and the leftover part can be used by the owner of the unspent output, but it can only be used for paying fees, not as inputs for future transactions (to save on block space). This should incentivize miners to not drive out the competition, since if they do, there will be less of these reserve fees given to miners. Yes in the end the miners will get all the fees, but with rising hashrate they get an unconditional subsidy that does not require transactions, thus more space for transactions with fees. I can make a formal BIP and pull request, but I need to know if there is interest in this. Now fees don't play such a large part of the block reward, but they will get more important, and this change wouldn't force anything (would be voluntary by each user), just miners have to agree to it with a soft fork (so they don't spend from the anyone-can-spend outputs used for reserve fees). Resource requirements for validation are quite small I believe. On Sat, Sep 1, 2018 at 12:11 AM, Andrew wrote: > As I understand, selfish mining is an attack where miners collude to > mine at a lower hashrate then with all miners working independently. > What are the current strategies used to prevent this and what are the > future plans? > > One idea I have is to let the block reward get "modulated" according > to peak hashrate. Say p is the peak hashrate for 365 periods (1 year) > consisting of 144 blocks, h is the hashrate of the last 144 block (1 > day) period, and r is the base subsidy (12.5 BTC currently). You can > then make the max block reward 0.5 r (1 + h/p). So if hashrate is at > peak you get the full reward. Otherwise you get less, down to a min of > 0.5 r. > > If miners were to collude to mine at a lower than peak hashrate, then > they may be able to do it profitably for 144 blocks, but after that, > the reward would get modulated and it wouldn't be so much in their > interest to continue mining at the lower hashrate. > > What flaws are there with this? I know it could be controversial due > to easier mining present for early miners, so maybe it would have to > be done in combination with a new more dynamic difficulty adjustment > algorithm. But I don't see how hashrate can continue rising > indefinitely, so a solution should be made for selfish mining. > > Also when subsidies stop and a fee market is needed, I guess a portion > of the fees can be withheld for later if hashrate is not at peak. > > > -- > PGP: B6AC 822C 451D 6304 6A28 49E9 7DB7 011C D53B 5647 -- PGP: B6AC 822C 451D 6304 6A28 49E9 7DB7 011C D53B 5647 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Selfish Mining Prevention
As I understand, selfish mining is an attack where miners collude to mine at a lower hashrate then with all miners working independently. What are the current strategies used to prevent this and what are the future plans? One idea I have is to let the block reward get "modulated" according to peak hashrate. Say p is the peak hashrate for 365 periods (1 year) consisting of 144 blocks, h is the hashrate of the last 144 block (1 day) period, and r is the base subsidy (12.5 BTC currently). You can then make the max block reward 0.5 r (1 + h/p). So if hashrate is at peak you get the full reward. Otherwise you get less, down to a min of 0.5 r. If miners were to collude to mine at a lower than peak hashrate, then they may be able to do it profitably for 144 blocks, but after that, the reward would get modulated and it wouldn't be so much in their interest to continue mining at the lower hashrate. What flaws are there with this? I know it could be controversial due to easier mining present for early miners, so maybe it would have to be done in combination with a new more dynamic difficulty adjustment algorithm. But I don't see how hashrate can continue rising indefinitely, so a solution should be made for selfish mining. Also when subsidies stop and a fee market is needed, I guess a portion of the fees can be withheld for later if hashrate is not at peak. -- PGP: B6AC 822C 451D 6304 6A28 49E9 7DB7 011C D53B 5647 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Multisig with hashes instead of pubkeys
Hi Is there a worked out scriptPubKey for doing multisig with just hashes of the participants? I think it is doable and it is more secure to a compromised ECDSA. I'm thinking something like this for the scriptPubKey: 2 OP_SWAP OP_SWAP OP_SWAP OP_DUP OP_HASH160 OP_EQUALVERIFY OP_DUP OP_HASH160 OP_EQUALVERIFY OP_DUP OP_HASH160 OP_EQUALVERIFY 3 OP_CHECKMULTISIG and for the scriptSig Can anyone confirm or send me a link to the worked out script? Thanks -- PGP: B6AC 822C 451D 6304 6A28 49E9 7DB7 011C D53B 5647 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Scaling by Partitioning
Hi Akiva I sketched out a similar proposal here: https://bitcointalk.org/index.php?topic=1083345.0 It's good to see people talking about this :). I'm not quite convinced with segregated witness, as it might mess up some things, but will take a closer look. On Dec 9, 2015 7:32 AM, "Loi Luu via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > Dear Akiva, > > Its Loi Luu, one of the authors of the SCP protocol ( > http://eprint.iacr.org/2015/1168.pdf ). > > Before SCP, we had been thinking hard about how to do sharding efficiently > without degrading any security guarantee. A simple solution which splits > the coins, or TXs in to several partitions will just not work. You have to > answer more questions to have a good solutions. For example, I wonder in > your proposal, if a transaction spends a "coin" that ends in "1" and > creates a new coin that ends in "1", which partition should process the > transaction? What is the prior data needed to validate that kind of TXs? > > The problem with other proposals, and probably yours as well, that we see > is that the amount of data that you need to broadcast immediately to the > network increases linearly with the number of TXs that the network can > process. Thus, sharding does not bring any advantage than simply using > other techniques to publish more blocks in one epoch (like Bitcoin-NG, > Ghost). The whole point of using sharding/ partition is to localize > the bandwidth used, and only broadcast only a minimal data to the network. > > Clearly we are able to localize the bandwidth used with our SCP protocol. > The cost is that now recipients need to themselves verify whether a > transaction is double spending. However, we think that it is a reasonable > tradeoff, given the potential scalability that SCP can provides. > > Thanks, > Loi Luu. > > On Wed, Dec 9, 2015 at 12:27 AM, Akiva Lichtner via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> Hello, >> >> I am seeking some expert feedback on an idea for scaling Bitcoin. As a >> brief introduction: I work in the payment industry and I have twenty years' >> experience in development. I have some experience with process groups and >> ordering protocols too. I think I understand Satoshi's paper but I admit I >> have not read the source code. >> >> The idea is to run more than one simultaneous chain, each chain defeating >> double spending on only part of the coin. The coin would be partitioned by >> radix (or modulus, not sure what to call it.) For example in order to >> multiply throughput by a factor of ten you could run ten parallel chains, >> one would work on coin that ends in "0", one on coin that ends in "1", and >> so on up to "9". >> >> The number of chains could increase automatically over time based on the >> moving average of transaction volume. >> >> Blocks would have to contain the number of the partition they belong to, >> and miners would have to round-robin through partitions so that an attacker >> would not have an unfair advantage working on just one partition. >> >> I don't think there is much impact to miners, but clients would have to >> send more than one message in order to spend money. Client messages will >> need to enumerate coin using some sort of compression, to save space. This >> seems okay to me since often in computing client software does have to >> break things up in equal parts (e.g. memory pages, file system blocks,) and >> the client software could hide the details. >> >> Best wishes for continued success to the project. >> >> Regards, >> Akiva >> >> P.S. I found a funny anagram for SATOSHI NAKAMOTO: "NSA IS OOOK AT MATH" >> >> >> ___ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> > > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
