<oembed><type>rich</type><version>1.0</version><author_name>npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgyd</author_name><author_url>https://nostr.ae/npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgyd</author_url><provider_name>njump</provider_name><provider_url>https://nostr.ae</provider_url><html>📅 Original date posted:2014-04-10&#xA;📝 Original message:&gt;&#xA;&gt; I find it is odd that we who hold the key to instant machine to machine&#xA;&gt; micro payments do not use it to incentivise committing resources to the&#xA;&gt; network.&#xA;&gt;&#xA;&#xA;It&#39;s not a new idea, obviously, but there are some practical consequences:&#xA;&#xA;1) To pay a node for serving, you have to have bitcoins. To get bitcoins,&#xA;you need to sync with the network via a node. Catch 22.&#xA;&#xA;2) If some nodes choose to charge and others choose to not charge, a smart&#xA;wallet will always use the free nodes. In the absence of any global load&#xA;balancing algorithms, this would lead to the free nodes getting overloaded&#xA;and collapsing whilst the for-pay nodes remain silent.&#xA;&#xA;3) The only payment channel implementations today are bitcoinj&#39;s (Java) and&#xA;one written by Jeff in Javascript. There are no C++ implementations. And as&#xA;Matt and I can attest to, doing a real, solid, fully debugged&#xA;implementation that&#39;s integrated into a real app is .... a lot of work.&#xA;&#xA;I still think the lowest hanging fruit is basic, boring optimisations&#xA;rather than architectural rethinks.&#xA;-------------- next part --------------&#xA;An HTML attachment was scrubbed...&#xA;URL: &lt;http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140410/47c486d0/attachment.html&gt;</html></oembed>