Re: [Lightning-dev] [bitcoin-dev] Pawn (chess piece) | Breaking bitcoin by playing chess
The frivolous use of block space - ie. to increase the demand for block space - is not encouraged. Although it is possible you may write chess moves on a wrap of dollar bills and send them to your friends, nowhere that I know of has this been recorded in a ledger as a valid past time. KING JAMES HRMH Great British Empire Regards, The Australian LORD HIS EXCELLENCY JAMES HRMH (& HMRH) of Hougun Manor & Glencoe & British Empire MR. Damian A. James Williamson Wills et al. Willtech www.willtech.com.au www.go-overt.com duigco.org DUIGCO API and other projects m. 0487135719 f. +61261470192 This email does not constitute a general advice. Please disregard this email if misdelivered. From: bitcoin-dev on behalf of Prayank via bitcoin-dev Sent: Saturday, 4 December 2021 3:36 PM To: Lightning Dev Cc: Bitcoin Dev Subject: [bitcoin-dev] Pawn (chess piece) | Breaking bitcoin by playing chess Hello World, Link with what, why and how: https://gist.github.com/prayank23/22763f48199ed106e59801be43ad4efc Two related things that I found: 1.Koala Studio tried chess on LN in 2019 but shutdown in August 2019 2.Etleneum still has chess but works differently Primary goal of this project can be different and focus on testing Bitcoin transactions. Secondary goal is to have fun and contribute in increasing demand for block space. Maybe an app for developers to play chess, friendly competitions, learn and share new things. If chess sounds boring it can be replaced with any 2 player game that works for such setup and can be played with patience over few hours/days. Spam? Sorry zero fee transactions do not work anymore. In fact, nothing below 1 sat/vbyte fee rate would work and all transactions will pay fees that are required long term. OP_RETURN is used by many projects and excluded from UTXO set. Let me know if something looks wrong. I won't be working on this as busy with another project and recently started contributing in Wasabi. -- Prayank A3B1 E430 2298 178F ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] [bitcoin-dev] Removing the Dust Limit
Good Afternoon, Further, if it is entirely necessary to prevent the creation of utxo's that are considered dust, and I am not by any means convinced, then it is simple to provide the most circumspect solution to transfer the value of any dust utxo that would be created in a transaction to the fee. I do not believe this answer is any more than robbery of the future value of the wallet as my wallet must be able to keep any change but if it is must then this is the answer. KING JAMES HRMH Great British Empire Regards, The Australian LORD HIS EXCELLENCY JAMES HRMH (& HMRH) of Hougun Manor & Glencoe & British Empire MR. Damian A. James Williamson Wills et al. Willtech www.willtech.com.au www.go-overt.com duigco.org DUIGCO API and other projects m. 0487135719 f. +61261470192 This email does not constitute a general advice. Please disregard this email if misdelivered. ____ From: LORD HIS EXCELLENCY JAMES HRMH Sent: Thursday, 7 October 2021 7:34 PM To: Erik Aronesty ; ZmnSCPxj ; Bitcoin Protocol Discussion Cc: lightning-dev Subject: Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit Good Afternoon, The underlying consideration is the same concerning the handling of 1c and 2c coins in an economy. Although you may argue the cost of counting those coins throughout the course of minting, drafting to banks, paying to bank customers, including in change, and at every handling counting, is less than the value of those coins, hpwever, the solution in traditional currency is to round the value of the transaction either per line of goods or per total before calculating the Grand Total, in which case the payment either from a non-utxo set of accumulation in a traditional account or, from a known series of denominations, is adjusted. In the case of Bitcoin, the denominations available are effectively the utxo set and there is no effective way to round the transactions without accepting overpayments as valid, and with what consideration, in which case the protocol may avoid creating dust in change by sending the additional rounded amount that would otherwise be dust to the recipient. I suppose that this gets difficult where the transaction has multiple outputs and you could argue to distribute to all outputs as an overpayment. It is the same effectively as rounding to 10c. KING JAMES HRMH Great British Empire Regards, The Australian LORD HIS EXCELLENCY JAMES HRMH (& HMRH) of Hougun Manor & Glencoe & British Empire MR. Damian A. James Williamson Wills et al. Willtech www.willtech.com.au www.go-overt.com duigco.org DUIGCO API and other projects m. 0487135719 f. +61261470192 This email does not constitute a general advice. Please disregard this email if misdelivered. ________ From: LORD HIS EXCELLENCY JAMES HRMH Sent: Thursday, 7 October 2021 7:17 PM To: Erik Aronesty ; ZmnSCPxj ; Bitcoin Protocol Discussion Cc: lightning-dev Subject: Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit Good Afternoon, Returning to this subject, there should be no restriction to the value of utxo's that keep in one's own wallet as change can be created in any value. With obvious intent, the wallet should avoid creating utxo's below the current dust limit at the time the transaction is created but it cannot guarantee it. The wallet should avoid including utxo's that by weight sat/KB are more expensive to include that their value at the time a transaction is created, ie. do not include utxo's in a transaction that lower the input value after fees for automatic utxo selection, however, perhaps consider this is valid for manual utxo selection since it is in every example 'my money' and I can spend some of it if I decide. There is no discipline in complaining that the dust set of utxo's slows down the process of block validation during mining. Every conceivable computerised business bears the expense of the cost of a database transaction. The actual answer to this genuine business concern of database speed is to build a faster database. It is correct knowledge to know that the Bitcoin protocol cannot speculate as to the future but we can. The case exists where it is conceivable for example, that the transaction fee is paid only for the first utxo inclusion in a transaction due to changes to the calculation of block-size. There are other easily plausible examples where the inclusion of what is today considered dust may not be ill-considered. KING JAMES HRMH Great British Empire Regards, The Australian LORD HIS EXCELLENCY JAMES HRMH (& HMRH) of Hougun Manor & Glencoe & British Empire MR. Damian A. James Williamson Wills et al. Willtech www.willtech.com.au www.go-overt.com duigco.org DUIGCO API and other projects m. 0487135719 f. +61261470192 This email does not constitute a general advice. Please disregard this email if misdelivered. _
Re: [Lightning-dev] [bitcoin-dev] Removing the Dust Limit
Good Afternoon, The underlying consideration is the same concerning the handling of 1c and 2c coins in an economy. Although you may argue the cost of counting those coins throughout the course of minting, drafting to banks, paying to bank customers, including in change, and at every handling counting, is less than the value of those coins, hpwever, the solution in traditional currency is to round the value of the transaction either per line of goods or per total before calculating the Grand Total, in which case the payment either from a non-utxo set of accumulation in a traditional account or, from a known series of denominations, is adjusted. In the case of Bitcoin, the denominations available are effectively the utxo set and there is no effective way to round the transactions without accepting overpayments as valid, and with what consideration, in which case the protocol may avoid creating dust in change by sending the additional rounded amount that would otherwise be dust to the recipient. I suppose that this gets difficult where the transaction has multiple outputs and you could argue to distribute to all outputs as an overpayment. It is the same effectively as rounding to 10c. KING JAMES HRMH Great British Empire Regards, The Australian LORD HIS EXCELLENCY JAMES HRMH (& HMRH) of Hougun Manor & Glencoe & British Empire MR. Damian A. James Williamson Wills et al. Willtech www.willtech.com.au www.go-overt.com duigco.org DUIGCO API and other projects m. 0487135719 f. +61261470192 This email does not constitute a general advice. Please disregard this email if misdelivered. ____ From: LORD HIS EXCELLENCY JAMES HRMH Sent: Thursday, 7 October 2021 7:17 PM To: Erik Aronesty ; ZmnSCPxj ; Bitcoin Protocol Discussion Cc: lightning-dev Subject: Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit Good Afternoon, Returning to this subject, there should be no restriction to the value of utxo's that keep in one's own wallet as change can be created in any value. With obvious intent, the wallet should avoid creating utxo's below the current dust limit at the time the transaction is created but it cannot guarantee it. The wallet should avoid including utxo's that by weight sat/KB are more expensive to include that their value at the time a transaction is created, ie. do not include utxo's in a transaction that lower the input value after fees for automatic utxo selection, however, perhaps consider this is valid for manual utxo selection since it is in every example 'my money' and I can spend some of it if I decide. There is no discipline in complaining that the dust set of utxo's slows down the process of block validation during mining. Every conceivable computerised business bears the expense of the cost of a database transaction. The actual answer to this genuine business concern of database speed is to build a faster database. It is correct knowledge to know that the Bitcoin protocol cannot speculate as to the future but we can. The case exists where it is conceivable for example, that the transaction fee is paid only for the first utxo inclusion in a transaction due to changes to the calculation of block-size. There are other easily plausible examples where the inclusion of what is today considered dust may not be ill-considered. KING JAMES HRMH Great British Empire Regards, The Australian LORD HIS EXCELLENCY JAMES HRMH (& HMRH) of Hougun Manor & Glencoe & British Empire MR. Damian A. James Williamson Wills et al. Willtech www.willtech.com.au www.go-overt.com duigco.org DUIGCO API and other projects m. 0487135719 f. +61261470192 This email does not constitute a general advice. Please disregard this email if misdelivered. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] [bitcoin-dev] Removing the Dust Limit
Good Afternoon, Returning to this subject, there should be no restriction to the value of utxo's that keep in one's own wallet as change can be created in any value. With obvious intent, the wallet should avoid creating utxo's below the current dust limit at the time the transaction is created but it cannot guarantee it. The wallet should avoid including utxo's that by weight sat/KB are more expensive to include that their value at the time a transaction is created, ie. do not include utxo's in a transaction that lower the input value after fees for automatic utxo selection, however, perhaps consider this is valid for manual utxo selection since it is in every example 'my money' and I can spend some of it if I decide. There is no discipline in complaining that the dust set of utxo's slows down the process of block validation during mining. Every conceivable computerised business bears the expense of the cost of a database transaction. The actual answer to this genuine business concern of database speed is to build a faster database. It is correct knowledge to know that the Bitcoin protocol cannot speculate as to the future but we can. The case exists where it is conceivable for example, that the transaction fee is paid only for the first utxo inclusion in a transaction due to changes to the calculation of block-size. There are other easily plausible examples where the inclusion of what is today considered dust may not be ill-considered. KING JAMES HRMH Great British Empire Regards, The Australian LORD HIS EXCELLENCY JAMES HRMH (& HMRH) of Hougun Manor & Glencoe & British Empire MR. Damian A. James Williamson Wills et al. Willtech www.willtech.com.au www.go-overt.com duigco.org DUIGCO API and other projects m. 0487135719 f. +61261470192 This email does not constitute a general advice. Please disregard this email if misdelivered. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] [bitcoin-dev] Removing the Dust Limit
Good Afternoon, It is worth reconsidering the value accumulated in dust. Speculatively, when the value of 1 BTC reaches US$ 1,000,000.00 then the value of one satoshi will be US$ 0.01 so, for 1 satoshi to be of any substantial value the value of Bitcoin will have to rise substantially higher. I ask what then should the value of fees be? Is there not a future case foreseeable at least in consideration of Bitcoin's comparison with Gold that the value may be so high as to allow that 1 satoshi may cover the mining cost of any transaction despite the reduction in sat/B for including the additional transaction. Is it not that we can foresee the dust has value and that the wealthy may have in fact millions of dust transactions that are inheritable, though I hesitate to make my business collecting them I may set up a website. The current reason for excluding dust is because it costs more to the transaction to add the dust than its value but that does not say that will always be the case. KING JAMES HRMH Great British Empire Regards, The Australian LORD HIS EXCELLENCY JAMES HRMH (& HMRH) of Hougun Manor & Glencoe & British Empire MR. Damian A. James Williamson Wills et al. Willtech www.willtech.com.au www.go-overt.com and other projects earn.com/willtech linkedin.com/in/damianwilliamson m. 0487135719 f. +61261470192 This email does not constitute a general advice. Please disregard this email if misdelivered. From: bitcoin-dev on behalf of shymaa arafat via bitcoin-dev Sent: Friday, 27 August 2021 7:07 PM To: Billy Tetrud ; Bitcoin Protocol Discussion Cc: lightning-dev Subject: Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit Allow me to ask: -Untill you find a mitigation that consolidate all dust UTXOS, why don't you separate them and all probably Unspendable UTXOS in a different partition? -I'm talking at the real UTXO storage level (to be kept in secondary storage), and at the Merkleization level in any accumulator design Utreexo or what so ever(putting them in one or two subtree/forest with hardly changing roots according to the categorization will reduce the proof size, even if slightly) -This will also help things like Bloom filters, assume UTXOs,...etc when about 10% with almost zero probability are trimmed from the pool you are withdrawing from. . -The paper I mentioned earlier says in Feb 2018, there was about 2.4m UTXOS less than 1000 Satoshi, of which ~824,892 holds exactly 1 Satoshi -I don't think any of those were spent since that time, in fact there could be a possibility that the numbers may have increased -As the last previous reply mentioned you have to consider the long run effect on the UTXO set forever, this is a straight forward improvement that comes with almost no effort . Ps. -If there is something wrong, something I missed in this idea please explain it to me -Or do you find the improvement itself a "dust" that doesn't worth the effort??? . Regards & thank you all for your time in reading & replying Shymaa M. Arafat On Fri, Aug 27, 2021, 00:06 Billy Tetrud via bitcoin-dev mailto:bitcoin-...@lists.linuxfoundation.org>> wrote: One interesting thing I thought of: the cost of maintenance of the dust creates a (very) small incentive to mine transactions that *use* dust outputs with a slightly lower fee that contain dust, in order to reduce the future maintenance cost for themselves. However, the rational discount would likely be vanishingly small. It would be interesting to add something to the consensus rules to decrease the vbytes for a transaction that consumes dust outputs such that the value of removing them from the system (saving the future cost of maintenance) is approximately equal to the amount that the fee could be made lower for such transactions. Even measuring this as a value over the whole (future) bitcoin network, I'm not sure how to evaluate the magnitude of this future cost. On Fri, Aug 20, 2021 at 8:12 PM ZmnSCPxj via bitcoin-dev mailto:bitcoin-...@lists.linuxfoundation.org>> wrote: Good morning Jeremy, > one interesting point that came up at the bitdevs in austin today that favors > remove that i believe is new to this discussion (it was new to me): > > the argument can be reduced to: > > - dust limit is a per-node relay policy. > - it is rational for miners to mine dust outputs given their cost of > maintenance (storing the output potentially forever) is lower than their > immediate reward in fees. > - if txn relaying nodes censor something that a miner would mine, users will > seek a private/direct relay to the miner and vice versa. > - if direct relay to miner becomes popular, it is both bad for privacy and > decentralization. > - therefore the dust limit, should there be demand to create dust at > prevailing mempool feerates, causes an incentive to increase network
