Tamas Blummer [ARCHIVE] on Nostr: 📅 Original date posted:2014-04-10 📝 Original message:I know the idea is not ...
📅 Original date posted:2014-04-10
📝 Original message:I know the idea is not new. Just bringing it up to emphasize that if we don’t use it how could we expect other networks using it.
Machine to machine micro payments could become the killer application for Bitcoin.
1) There is no catch 22 as there are plenty of ways getting bitcoin without bootstrapping a full node.
2) let markets work out and not speculate what would happen.
3) Serving archive bolcks does not have to be part of core but could be a distinct service written in a language of your choice using new protocol.
As mentioned earlier I am for a stripped down core that does nothing else than consensus and stores nothing else needed for that task and offering SPV api to the wallets.
Tamas Blummer
http://bitsofproof.com
On 10.04.2014, at 11:17, Mike Hearn <mike at plan99.net> wrote:
> I find it is odd that we who hold the key to instant machine to machine micro payments do not use it to incentivise committing resources to the network.
>
> It's not a new idea, obviously, but there are some practical consequences:
>
> 1) To pay a node for serving, you have to have bitcoins. To get bitcoins, you need to sync with the network via a node. Catch 22.
>
> 2) If some nodes choose to charge and others choose to not charge, a smart wallet will always use the free nodes. In the absence of any global load balancing algorithms, this would lead to the free nodes getting overloaded and collapsing whilst the for-pay nodes remain silent.
>
> 3) The only payment channel implementations today are bitcoinj's (Java) and one written by Jeff in Javascript. There are no C++ implementations. And as Matt and I can attest to, doing a real, solid, fully debugged implementation that's integrated into a real app is .... a lot of work.
>
> I still think the lowest hanging fruit is basic, boring optimisations rather than architectural rethinks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140410/2fb654ae/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140410/2fb654ae/attachment.sig>;
📝 Original message:I know the idea is not new. Just bringing it up to emphasize that if we don’t use it how could we expect other networks using it.
Machine to machine micro payments could become the killer application for Bitcoin.
1) There is no catch 22 as there are plenty of ways getting bitcoin without bootstrapping a full node.
2) let markets work out and not speculate what would happen.
3) Serving archive bolcks does not have to be part of core but could be a distinct service written in a language of your choice using new protocol.
As mentioned earlier I am for a stripped down core that does nothing else than consensus and stores nothing else needed for that task and offering SPV api to the wallets.
Tamas Blummer
http://bitsofproof.com
On 10.04.2014, at 11:17, Mike Hearn <mike at plan99.net> wrote:
> I find it is odd that we who hold the key to instant machine to machine micro payments do not use it to incentivise committing resources to the network.
>
> It's not a new idea, obviously, but there are some practical consequences:
>
> 1) To pay a node for serving, you have to have bitcoins. To get bitcoins, you need to sync with the network via a node. Catch 22.
>
> 2) If some nodes choose to charge and others choose to not charge, a smart wallet will always use the free nodes. In the absence of any global load balancing algorithms, this would lead to the free nodes getting overloaded and collapsing whilst the for-pay nodes remain silent.
>
> 3) The only payment channel implementations today are bitcoinj's (Java) and one written by Jeff in Javascript. There are no C++ implementations. And as Matt and I can attest to, doing a real, solid, fully debugged implementation that's integrated into a real app is .... a lot of work.
>
> I still think the lowest hanging fruit is basic, boring optimisations rather than architectural rethinks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140410/2fb654ae/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140410/2fb654ae/attachment.sig>;