{"type":"rich","version":"1.0","author_name":"npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2","author_url":"https://nostr.ae/npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-05-08\n📝 Original message:On Fri, May 08, 2015 at 03:32:00PM +0300, Joel Joonatan Kaartinen wrote:\n\u003e Matt,\n\u003e \n\u003e It seems you missed my suggestion about basing the maximum block size on\n\u003e the bitcoin days destroyed in transactions that are included in the block.\n\u003e I think it has potential for both scaling as well as keeping up a constant\n\u003e fee pressure. If tuned properly, it should both stop spamming and increase\n\u003e block size maximum when there are a lot of real transactions waiting for\n\u003e inclusion.\n\nThe problem with gating block creation on Bitcoin days destroyed is\nthere's a strong potential of giving big mining pools an huge advantage,\nbecause they can contract with large Bitcoin owners and buy dummy\ntransactions with large numbers of Bitcoin days destroyed on demand\nwhenever they need more days-destroyed to create larger blocks.\nSimilarly, with appropriate SIGHASH flags such contracting can be done\nby modifying *existing* transactions on demand.\n\nUltimately bitcoin days destroyed just becomes a very complex version of\ntransaction fees, and it's already well known that gating blocksize on\ntotal transaction fees doesn't work.\n\n-- \n'peter'[:-1]@petertodd.org\n00000000000000000f53e2d214685abf15b6d62d32453a03b0d472e374e10e94\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 650 bytes\nDesc: Digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150508/aad39559/attachment.sig\u003e"}