@Murch
stacking since: #127838
I don’t know about the other people, but I have been on this platform longer than you. It comes off as pretty odd that you post a newbie greeting to accounts that are older than your own. And you seem to be posting it a lot—does anyone ever respond to it?
I don’t understand how Civil Forfeiture is not outright unconstitutional. Objects don’t have agency, and people are innocent until proven guilty. How is taking anyone’s stuff without due process or compensation so widely tolerated?
I think you are projecting your values on others. I’d rather have a smaller house in walking/biking distance of a supermarket, kindergarten, school etc. than a bigger house and needing two cars. I once lived in a 1200 sqft apartment with another person and we ended up not using one of the rooms. I‘d prefer a 800–1000 sqft with a nice cut in a better location any day of the week at least until there are more than two people to be housed.
Rediscovered Bitcoin the third or so time and actually read the Whitepaper. Realized that it might actually work.
Spring 2013 – Bought ice-cream for two with bitcoins.
Summer 2013 – Lost 0.2 bitcoin by accidentally uninstalling a wallet app when my phone’s disk was full.
June 2013 – Made account on Bitcoin Stack Exchange. I went on to ask 185 questions and write 1,722 answers which have accumulated some 5m reads since.
March 2014 – Became a moderator on Bitcoin Stack Exchange editing over 6,500 posts, deleting and closing about as many.
May 2014 – Attended Bitcoin2014 in Amsterdam meeting a bunch of the active devs and spent 0.4 BTC on a Bitcoin pin that I don’t even know where it is now.
September 2014 – Opened my first PR to Bitcoin Core to make a small coin selection improvement. It later got reverted when a senior contributor noticed that the UTXO set had started growing faster and partially attributed it to the change I made.
Summer 2016 – Wrote my Master’s thesis on Coin Selection which went on to be cited by 10 papers and is still being read occasionally.
October 2016 – Traveled to Milan to give a talk at Scaling Bitcoin.
April 2017 – Became a fulltime bitcoiner when I started working at BitGo on the backend, leading the project to implement segwit support and a bunch of other wallet features. Significantly reduced the overall blockspace footprint of BitGo customers. At times over 10% of all Bitcoin transactions were being built using my coin selection implementation.
June 2017 – Responded to Jonald Fyookball’s lightning fud piece within a couple hours.
Februar 2018 – Wrote Excited for Schnorr signatures giving an overview of my current understanding of the idea for Taproot.
Oct 2020 – Started working at Chaincode Labs to work on Bitcoin fulltime.
2021 – Started co-hosting the monthly New York Bitcoin developer meetup.
July 2022 – Started co-hosting to the Optech Recap Podcast, I’ve since recorded 80 episodes.
Other than, I have since spoken at a number of conferences and meetups, appeared on a number of other podcasts, e.g. Chaincode podcast (as guest and co-host), Stephan Livera, Noded, Honigdachs, Bitcoin im Turm, 21, and Nodesignal, written a bunch of blog posts, reviewed a bunch of pull requests in Bitcoin Core and other projects, even implemented a few pull requests myself.
Why would it ever make sense to spend more in fees than the current fiat value!?
You're essentially saying that paying a miner out of band will be cheaper than paying them in band. That doesn't make sense to me.
I think I see where you are coming from but that is a bit too imprecise.
There is a standardness rule that prevents creation of outputs with small amounts. The concrete amounts differ per output type: https://bitcoin.stackexchange.com/a/41082/5406
Additionally, UTXOs with a low amount may cost more to add to a transaction than their own amount at some feerate. I describe such UTXOs as having a negative effective value at a given feerate. E.g. a P2WPKH input weighs 68 vB, so a 500 sat P2WPKH output would be able to pay for itself at up to 7.35 s/vB. It's own cost would eat a significant proportion of it's value, though, so I would not recommend receiving such small UTXOs.
I don't think this is well reasoned.
A miner that includes your transaction has the opportunity cost of not using the blockspace for another transaction. In order for an economically rational miner to prioritize including your transaction over something else, you must provide now value to them than they'd otherwise earn.
As long as we have a block weight limit, transaction fees will always scale with the weight of transactions. If bitcoin continued to increase in value it will be because people find more utility in it. More utility implies that users will send larger amounts of value on the network. Larger payments can pay more for blockspace than smaller payments.
So, I don't think that bitcoin getting more valuable is compatible with smaller UTXOs becoming easier to spend—unless you expect the block weight limit to be significantly raised or altogether removed.
Since having a block weight limit is important for network security, this is unlikely.
Occasionally there might be a spell of low feerate, and you should use that to consolidate and move funds to more blockspace-efficient output scripts, but generally I expect small amounts to get harder to spend over time.
A block’s time stamp is valid when it's greater than the median of the last eleven blocks and less than the evaluating node’s current time plus two hours: https://bitcoin.stackexchange.com/q/915/5406
From the context in the thread it appears that Luke thinks being against gimping script to fight ordinals is to be equated with being a big blocker.
TBH, there are a lot of hardfork proposals that would give me fewer nightmares than one that implements additional divisibility. It would require that every single piece of Bitcoin software and hardware be updated to handle entirely different magnitudes of amounts and feerates as well as a change in the transaction format because anything more than three more digits of additional precision would no longer fit in a 64-bit integer (which is the current size of the amount field in the output).