{"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:2013-12-01\n📝 Original message:On Sun, Dec 01, 2013 at 07:18:07PM +0100, Mike Hearn wrote:\n\u003e \u003e Bitcoin is and always will be limited in capacity - transactions may not\n\u003e \u003e confirm in a reasonable about of time because of high-demand and/or DoS\n\u003e \u003e attacks.\n\u003e \n\u003e 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.\n\nMaybe, maybe not. We have no idea what fees will be because the system's\nentire capacity is, and always will be, limited. That's just how\nfundementally unscalable systems with huge global state work. What\ndemand will be for that limited capacity is unknown.\n\n\n\u003e \u003e re: merchants paying tx fees, child-pays-for-parent is inefficient\n\u003e \n\u003e 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.\t\n\nNo, Luke's existing code uses good algorithms with O(n) scaling for n\ntransactions. The inefficiency is needing a second transaction, bloating\nthe blockchain and driving up fees.\n\n-- \n'peter'[:-1]@petertodd.org\n000000000000000f9102d27cfd61ea9e8bb324593593ca3ce6ba53153ff251b3\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 490 bytes\nDesc: Digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131201/b55f69e4/attachment.sig\u003e"}