From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 02 Aug 2024 05:31:49 -0700 Received: from mail-yw1-f187.google.com ([209.85.128.187]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sZrRk-0003lG-DX for bitcoindev@gnusha.org; Fri, 02 Aug 2024 05:31:49 -0700 Received: by mail-yw1-f187.google.com with SMTP id 00721157ae682-66b3b4415c7sf172078877b3.0 for ; Fri, 02 Aug 2024 05:31:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1722601902; x=1723206702; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=GbRZmeZbYbx2vnTxKAakwD6rKhCq09VW56HeIaHHZdQ=; b=RRSPEkR4H7hukWPYkbh0neHIaBDXCkKk/jFFeRJJ8M72AAM1aR71TlHiJNUgEUlo4i 4yC67AXvhoQB2oAMIEehRM597O9dzkp24Jjx7EPdFFF/xVAImwhQo7DnCMHv4tw3Qdum EYphhes4cQxhVteEun3CbxLNP0/opOOJa26cKPp4ChMsJ4NYZTqDp6dPz7vANv3Uhs+B yoPD+S5XFrPI/GWTJBSdFwsZ2ntMedgprm/43+a3/jd3bUjDeYBuDbxINfph6+SJIL4n vHR2urDRsDaM1MgSe214K4quztGKOQJ8ddAJjBhUV+7wQA7PxnkfmNfEeIbGbq1E0rNQ 7R+Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1722601902; x=1723206702; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=GbRZmeZbYbx2vnTxKAakwD6rKhCq09VW56HeIaHHZdQ=; b=YJHkSCgxvsPt4Q9026o7rSbE4EbcDkInp9RWCBiZyo/5xgDNHr1Nn3tWU1xq96D/7m +h67fFTj5NHh6em8Q6aSfTk8GUuJvLw3pNKfgweoh9sZsofZkjko8LDoZgn0+zgI2NZ6 bvJWT9mxvSXefEu82NRFmy6ncbAqdM68yCFwCbTUcp56blxVH5qx+sS1mPwGmCx0fHuJ M24PJNSeoxLIy0jhZbqI/Ti4Cp9UGk6zchD6K8GdvTUcJX2uJw7gnTWOBS7qKq2N9abV 5MWbL989RrQ/HrUII5Z+7K4YWiEX29QIeOqFTH8jBMNOqS3Kr3pUNhhhcJLb7yl/Idb3 f4+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722601902; x=1723206702; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=GbRZmeZbYbx2vnTxKAakwD6rKhCq09VW56HeIaHHZdQ=; b=EIJ7GU5wTxWTKwp6Gja7tDZ+DBHVasNMrK+yPsnT49GuYeKImOQFAXVWORxhvBfL8S fPSQ5W2C0PSaGgCBEa2BawnsIfxFO4+BmFnuU6uBlepNjox84rSK9vUS5gYsJuSqxAdr ld/Q4Cgg0zXBqeP4HhwosCuPyPliFe5ZST70mtRoVhhDDhib1GxpZ6UB+ZkTI3GCEUlu 14QZjzsTF0JredfIfUmMinOLyuym3LD6qAdECZnj7UbEZ5nUZmdDB4RKgRmGNUsqFvEo AO/PYaHWhZLHLb5y2m5cREBYa05iAhjxQeDRNsXH8NCVsOfE8o78BL7fHE4tXdJdS8e0 igOg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCWv2LVdXuMlJqcJ2E1LVtXSc+3WeW210OolpciN2prpJ51S0BCJye7kFZd9nADkBW8dMx7uCSGnj+ZFWJL+eGp70vtJubg= X-Gm-Message-State: AOJu0YysTy7CTkyTxFaqzWrNiROzLLn+7zUeob2BPnRRDJvpDgkopFaL UjFt4f8IPQSaUiaT8t2+3WO/GCp/MMmRHWKxHNpL2E5x4nK8ksPL X-Google-Smtp-Source: AGHT+IHssYFZ3Ax5irGsG+gCUKuBUeftCpli9OBrJAaB6Zkk0ceyAb1gbaKNDeBbH/+iswLtHBTmyA== X-Received: by 2002:a05:6902:110c:b0:e0b:edef:3e10 with SMTP id 3f1490d57ef6-e0bedef410fmr741868276.55.1722601901978; Fri, 02 Aug 2024 05:31:41 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:a05:6902:729:b0:e05:a978:7726 with SMTP id 3f1490d57ef6-e0b228e5276ls479654276.2.-pod-prod-00-us; Fri, 02 Aug 2024 05:31:40 -0700 (PDT) X-Received: by 2002:a81:e707:0:b0:665:24b0:e936 with SMTP id 00721157ae682-68854e1829bmr394637b3.4.1722601900456; Fri, 02 Aug 2024 05:31:40 -0700 (PDT) Received: by 2002:a05:690c:2a92:b0:627:7f59:2eee with SMTP id 00721157ae682-689a1161eb5ms7b3; Fri, 2 Aug 2024 01:45:19 -0700 (PDT) X-Received: by 2002:a05:6902:1004:b0:e0b:bafe:a7f6 with SMTP id 3f1490d57ef6-e0bde439e04mr26054276.8.1722588318535; Fri, 02 Aug 2024 01:45:18 -0700 (PDT) Date: Fri, 2 Aug 2024 01:45:18 -0700 (PDT) From: Garlo Nicon To: Bitcoin Development Mailing List Message-Id: In-Reply-To: <6512db18-bd15-462e-92fd-7549b5e885e7n@googlegroups.com> References: <6512db18-bd15-462e-92fd-7549b5e885e7n@googlegroups.com> Subject: [bitcoindev] Re: HODL Tax Proposal MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_191046_1478998838.1722588318288" X-Original-Sender: garlonicon@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) ------=_Part_191046_1478998838.1722588318288 Content-Type: multipart/alternative; boundary="----=_Part_191047_1023545908.1722588318288" ------=_Part_191047_1023545908.1722588318288 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Good luck implementing it in test networks first, for example testnet3.=20 Some people were complaining, that they cannot get enough coins, and there= =20 is no other test chain, which is close to the mainnet, and has a lot of=20 history, and a lot of halvings. So, if you think seriously about it, then= =20 you should start from testnet3. Other networks, including mainnet, have not= =20 enough blocks, and have too big rewards for that. > addresses that do not engage in any outgoing transactions for over 60 day= s Miners can easily attack your network by mining empty blocks. It is=20 profitable to block regular payments today, to get high demurrage fees=20 tomorrow. Also, it is possible to easily censor any transaction, just by=20 refusing to include it. Then, required demurrage fees will be higher, than= =20 what was originally sent as fees, and all nodes will just throw it away,=20 while respecting your consensus. Which also means, that this proposal=20 enables "transaction expiration" in some implicit way: if a transaction is= =20 not confirmed in N blocks, then everything is eaten by demurrage fees, so= =20 the old transaction simply expires. > action needs to be taken before Peter Todd's suggestion of tail emissions= =20 get any serious momentum Assuming that "tail supply" will ever be implemented, then guess what:=20 people will count each and every overprinted satoshi. Creating coins is=20 hard, burning them is easy. If people will inflate Bitcoin, then other=20 people will bring it back to the equilibrium, just by burning all=20 overprinted coins, and refusing to accept any overprinted satoshi. You will= =20 see charts, and statistics, how many "tail supply coins" were mined in a=20 given block, and people will burn the same amount, if not more. > A proposed rate is 0.1% of the address balance per inactivity period. Ouch. This is way more than the current fees. Some people stopped using LN,= =20 because of fees like that. If you have 1 BTC, and you have to pay 100k=20 satoshis, then you can compare it with on-chain fees, where you can get it= =20 confirmed for 1k sats. Which means, that this "0.1% fees" will remove all= =20 whales from your network, where "a whale" is "anyone with >=3D 0.01 BTC".= =20 Good luck maintaining the chain without any whales, it will be just an=20 altcoin, similar to CPU-mined altcoins, where "miners=3Dusers" is the only= =20 use-case. Also note, that miners can simply send those demurrage fees back to the=20 users, just to get something. Then, they will have the choice: reject=20 user's transaction entirely (because of missing demurrage fees), or confirm= =20 two transactions: one paying demurrage fees, and one sending them back to= =20 the user. Congratulations, your rule just doubled the number of=20 transactions for no reason. Because only miners getting proper fees will=20 survive, everyone else will reject too many transactions, and end up with= =20 nothing. > The inactivity threshold and fee rate can be adjusted based on community= =20 feedback and network conditions. So, is it a local node policy, instead of being a consensus rule? Good,=20 then I can just edit my config file, put "demurragefee=3D0.00000000" and=20 "inactivity=3D999999999". Good to know, that a proposal like that, can be= =20 turned off that simply. czwartek, 1 sierpnia 2024 o 23:13:42 UTC+2 Richard Greaser napisa=C5=82(a): > Hi everyone,=20 > > It has become apparent to me that there is an issue where users of the=20 > network holding their coins, are not adding value to the network.=20 > > As miners continue to get squeezed post halving, they would benefit=20 > tremendously from fees being taken from individuals refusing to move thei= r=20 > coins, providing increased security to the network.=20 > > I have written out a proposal more in depth and is attached below.=20 > --=20 You received this message because you are subscribed to the Google Groups "= Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/= bitcoindev/cab2d0fd-e5f0-40e1-b648-3741e69822f5n%40googlegroups.com. ------=_Part_191047_1023545908.1722588318288 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Good luck implementing it in test networks first, for example testnet3. Som= e people were complaining, that they cannot get enough coins, and there is = no other test chain, which is close to the mainnet, and has a lot of histor= y, and a lot of halvings. So, if you think seriously about it, then you sho= uld start from testnet3. Other networks, including mainnet, have not enough= blocks, and have too big rewards for that.

> addresses that = do not engage in any outgoing transactions for over 60 days

Mine= rs can easily attack your network by mining empty blocks. It is profitable = to block regular payments today, to get high demurrage fees tomorrow. Also,= it is possible to easily censor any transaction, just by refusing to inclu= de it. Then, required demurrage fees will be higher, than what was original= ly sent as fees, and all nodes will just throw it away, while respecting yo= ur consensus. Which also means, that this proposal enables "transaction exp= iration" in some implicit way: if a transaction is not confirmed in N block= s, then everything is eaten by demurrage fees, so the old transaction simpl= y expires.

> action needs to be taken before Peter Todd's sug= gestion of tail emissions get any serious momentum

Assuming that= "tail supply" will ever be implemented, then guess what: people will count= each and every overprinted satoshi. Creating coins is hard, burning them i= s easy. If people will inflate Bitcoin, then other people will bring it bac= k to the equilibrium, just by burning all overprinted coins, and refusing t= o accept any overprinted satoshi. You will see charts, and statistics, how = many "tail supply coins" were mined in a given block, and people will burn = the same amount, if not more.

> A proposed rate is 0.1% of th= e address balance per inactivity period.

Ouch. This is way more = than the current fees. Some people stopped using LN, because of fees like t= hat. If you have 1 BTC, and you have to pay 100k satoshis, then you can com= pare it with on-chain fees, where you can get it confirmed for 1k sats. Whi= ch means, that this "0.1% fees" will remove all whales from your network, w= here "a whale" is "anyone with >=3D 0.01 BTC". Good luck maintaining the= chain without any whales, it will be just an altcoin, similar to CPU-mined= altcoins, where "miners=3Dusers" is the only use-case.

Also not= e, that miners can simply send those demurrage fees back to the users, just= to get something. Then, they will have the choice: reject user's transacti= on entirely (because of missing demurrage fees), or confirm two transaction= s: one paying demurrage fees, and one sending them back to the user. Congra= tulations, your rule just doubled the number of transactions for no reason.= Because only miners getting proper fees will survive, everyone else will r= eject too many transactions, and end up with nothing.

> The i= nactivity threshold and fee rate can be adjusted based on community feedbac= k and network conditions.

So, is it a local node policy, instead= of being a consensus rule? Good, then I can just edit my config file, put = "demurragefee=3D0.00000000" and "inactivity=3D999999999". Good to know, tha= t a proposal like that, can be turned off that simply.

czwartek, 1 sierpn= ia 2024 o=C2=A023:13:42 UTC+2 Richard Greaser napisa=C5=82(a):
Hi everyone,=C2=A0
It has become apparent to me that there is an issue where user= s of the network holding their coins, are not adding value to the network. =

As miners continue to get squeezed post halving, they wo= uld benefit tremendously from fees being taken from individuals refusing to= move their coins, providing increased security to the network.=C2=A0
I have written out a proposal more in depth and is attached below.=C2=A0<= /div>

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg= id/bitcoindev/cab2d0fd-e5f0-40e1-b648-3741e69822f5n%40googlegroups.com.=
------=_Part_191047_1023545908.1722588318288-- ------=_Part_191046_1478998838.1722588318288--