📅 Original date posted:2015-12-29
📝 Original message:How could this possibly be enforced?
On Tue, Dec 29, 2015 at 12:59 PM, Dave Scotese via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> There have been no decent objections to altering the block-selection
> mechanism (when two block solutions appear at nearly the same time) as
> described at
>
> http://bitcoin.stackexchange.com/questions/39226
>
> Key components are:
>
> - Compute BitcoinDaysDestroyed using only transactions that have been
> in your mempool for some time as oBTCDD ("old BTCDD").
> - Use "nearly the same time" to mean separated in time by your guess
> of the average duration of block propagation times.
> - When two block solutions come in at nearly the same time, build on
> the one that has the most oBTCDD, rather than the one that came in first.
>
> The goal of this change is to reduce the profitability of withholding
> block solutions by severely reducing the chances that a block solved a
> while ago can orphan one solved recently. "Came in first" seems more
> easily gamed than "most oBTCDD". As I wrote there, "*old coins* is
> always a dwindling resource and *global nodes willing to help cheat* is
> probably a growing one."
>
> I will write a BIP if anyone agrees it's a good idea.
>
> On Mon, Dec 28, 2015 at 12:26 PM, Ivan Brightly via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> On Mon, Dec 28, 2015 at 2:12 PM, Peter Todd via bitcoin-dev <
>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>> Far more concerning is network propagation effects between large and
>>> small miners. For that class of issues, if you are in an environemnt
>>> where selfish mining is possible - a fairly flat, easily DoS/sybil
>>> attacked network topology - the profitability difference between small
>>> and large miners even *without* attacks going on is a hugely worrying
>>> problem. OTOH, if you're blocksize is small enough that propagation time
>>> is negligable to profitability, then selfish mining attacks with <30%
>>> hashing power aren't much of a concern - they'll be naturally defeated
>>> by anti-DoS/anti-sybil measures.
>>>
>>
>> Let's agree that one factor in mining profitability is bandwidth/network
>> reliability/stability. Why focus on that vs electricity contracts or
>> vertically integrated chip manufacturers? Surely, sufficient network
>> bandwidth is a more broadly available commodity than <$0.02/kwh
>> electricity, for example. I'm not sure that your stranded hydroelectric
>> miner is any more desirable than thousands of dorm room miners with access
>> to 10gbit university connections and free electricity.
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
>
> --
> I like to provide some work at no charge to prove my value. Do you need a
> techie?
> I own Litmocracy <http://www.litmocracy.com>; and Meme Racing
> <http://www.memeracing.net>; (in alpha).
> I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com>;
> which now accepts Bitcoin.
> I also code for The Dollar Vigilante <http://dollarvigilante.com/>;.
> "He ought to find it more profitable to play by the rules" - Satoshi
> Nakamoto
>
> _______________________________________________
> 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/20151229/01725358/attachment.html>;
Allen Piscitello [ARCHIVE] /
npub1xv…c5rqg
2023-06-07 17:46:59
in reply to nevent1q…8srf
Author Public Key
npub1xvnnyhz8e4eklaakjc9xgm5w8pzkuckt923uacz2cftqdqx23g7q3c5rqgSeen on
wss://relay.noswhere.comPublished at
2023-06-07 17:46:59Event JSON
{
"id": "6ecff772f22aaaf8eea456b4134a91df4c1fa9c0acdb921263ecab91a9c00e54",
"pubkey": "3327325c47cd736ff7b6960a646e8e38456e62cb2aa3cee04ac2560680ca8a3c",
"created_at": 1686160019,
"kind": 1,
"tags": [
[
"e",
"29b7621364af8f1f611558ed33ab90fd2b7daff5f620fc02b9ca3019fe1123e5",
"",
"root"
],
[
"e",
"a693e33ce78773fb7d3bb13f021c0a87acf0d56ca33caf552bba5e319ba2eece",
"",
"reply"
],
[
"p",
"0ff56c09ef879c89ea04bfa2d5f5e0d96000ed6eaf5ac38e7b538a9d92767569"
]
],
"content": "📅 Original date posted:2015-12-29\n📝 Original message:How could this possibly be enforced?\n\nOn Tue, Dec 29, 2015 at 12:59 PM, Dave Scotese via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e There have been no decent objections to altering the block-selection\n\u003e mechanism (when two block solutions appear at nearly the same time) as\n\u003e described at\n\u003e\n\u003e http://bitcoin.stackexchange.com/questions/39226\n\u003e\n\u003e Key components are:\n\u003e\n\u003e - Compute BitcoinDaysDestroyed using only transactions that have been\n\u003e in your mempool for some time as oBTCDD (\"old BTCDD\").\n\u003e - Use \"nearly the same time\" to mean separated in time by your guess\n\u003e of the average duration of block propagation times.\n\u003e - When two block solutions come in at nearly the same time, build on\n\u003e the one that has the most oBTCDD, rather than the one that came in first.\n\u003e\n\u003e The goal of this change is to reduce the profitability of withholding\n\u003e block solutions by severely reducing the chances that a block solved a\n\u003e while ago can orphan one solved recently. \"Came in first\" seems more\n\u003e easily gamed than \"most oBTCDD\". As I wrote there, \"*old coins* is\n\u003e always a dwindling resource and *global nodes willing to help cheat* is\n\u003e probably a growing one.\"\n\u003e\n\u003e I will write a BIP if anyone agrees it's a good idea.\n\u003e\n\u003e On Mon, Dec 28, 2015 at 12:26 PM, Ivan Brightly via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e\u003e On Mon, Dec 28, 2015 at 2:12 PM, Peter Todd via bitcoin-dev \u003c\n\u003e\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\u003e Far more concerning is network propagation effects between large and\n\u003e\u003e\u003e small miners. For that class of issues, if you are in an environemnt\n\u003e\u003e\u003e where selfish mining is possible - a fairly flat, easily DoS/sybil\n\u003e\u003e\u003e attacked network topology - the profitability difference between small\n\u003e\u003e\u003e and large miners even *without* attacks going on is a hugely worrying\n\u003e\u003e\u003e problem. OTOH, if you're blocksize is small enough that propagation time\n\u003e\u003e\u003e is negligable to profitability, then selfish mining attacks with \u003c30%\n\u003e\u003e\u003e hashing power aren't much of a concern - they'll be naturally defeated\n\u003e\u003e\u003e by anti-DoS/anti-sybil measures.\n\u003e\u003e\u003e\n\u003e\u003e\n\u003e\u003e Let's agree that one factor in mining profitability is bandwidth/network\n\u003e\u003e reliability/stability. Why focus on that vs electricity contracts or\n\u003e\u003e vertically integrated chip manufacturers? Surely, sufficient network\n\u003e\u003e bandwidth is a more broadly available commodity than \u003c$0.02/kwh\n\u003e\u003e electricity, for example. I'm not sure that your stranded hydroelectric\n\u003e\u003e miner is any more desirable than thousands of dorm room miners with access\n\u003e\u003e to 10gbit university connections and free electricity.\n\u003e\u003e\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\n\u003e\u003e\n\u003e\n\u003e\n\u003e --\n\u003e I like to provide some work at no charge to prove my value. Do you need a\n\u003e techie?\n\u003e I own Litmocracy \u003chttp://www.litmocracy.com\u003e and Meme Racing\n\u003e \u003chttp://www.memeracing.net\u003e (in alpha).\n\u003e I'm the webmaster for The Voluntaryist \u003chttp://www.voluntaryist.com\u003e\n\u003e which now accepts Bitcoin.\n\u003e I also code for The Dollar Vigilante \u003chttp://dollarvigilante.com/\u003e.\n\u003e \"He ought to find it more profitable to play by the rules\" - Satoshi\n\u003e Nakamoto\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151229/01725358/attachment.html\u003e",
"sig": "9590c5bf34dc8d513cffdaa43385491153bf14e2294d090a71300313acdb7bd9298b66408d8e1a6f0b247f84e0a0112d08d4558e540b373a8b6480b3330946fe"
}