rich1.0npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2https://nostr.ae/npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2njumphttps://nostr.ae📅 Original date posted:2013-12-01 📝 Original message:On Sun, Dec 01, 2013 at 07:18:07PM +0100, Mike Hearn wrote: > > Bitcoin is and always will be limited in capacity - transactions may not > > confirm in a reasonable about of time because of high-demand and/or DoS > > attacks. > > I agree in the general case, but I was talking about the mobile wallet case specifically (i.e. people who are sending money between themselves or making small purchases of physical things). I think Bitcoin should be able to scale to handle these sorts of ordinary every-day transactions. Where I’d expect to see transactions falling off the edge is in more specialised cases like very small single micropayments, or “optional” internal transactions like mixing/re/defragmentation of wallets that don’t correspond to an actual payment. Those sorts of transactions would I guess be the first to go when faced with a sudden capacity crunch, but they wouldn’t show up in a mobile wallet UI anyway. Maybe, maybe not. We have no idea what fees will be because the system's entire capacity is, and always will be, limited. That's just how fundementally unscalable systems with huge global state work. What demand will be for that limited capacity is unknown. > > re: merchants paying tx fees, child-pays-for-parent is inefficient > > I know the existing code is, but is that fundamentally the case or just how the code has been written? I haven’t looked at this issue much but I know you’ve worked on it, so I’m curious to learn about why it’s inefficient and whether there are any fixes possible. No, Luke's existing code uses good algorithms with O(n) scaling for n transactions. The inefficiency is needing a second transaction, bloating the blockchain and driving up fees. -- 'peter'[:-1]@petertodd.org 000000000000000f9102d27cfd61ea9e8bb324593593ca3ce6ba53153ff251b3 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: Digital signature URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131201/b55f69e4/attachment.sig>