Eric Lombrozo [ARCHIVE] on Nostr: 📅 Original date posted:2015-07-23 📝 Original message:I think it’s pretty ...
đź“… Original date posted:2015-07-23
📝 Original message:I think it’s pretty clear by now that the assumption that all nodes have pretty similar computational resources leads to very misplaced incentives. Ultimately, cryptocurrencies will allow direct outsourcing of computation, making it possible to distribute computational tasks in an economically sensible way.
Wallets should be assumed to have low computational resources and intermittent Internet connections for the foreseeable future if we ever intend for this to be a practical payment system, methinks.
> On Jul 23, 2015, at 6:28 PM, Eric Lombrozo <elombrozo at gmail.com> wrote:
>
> I suppose you can use a timelocked output that is spendable by anyone you could go somewhat in this direction…the thing is it still means the wallet must make fee estimations rather than being able to get a quick quote.
>
>> On Jul 23, 2015, at 6:25 PM, Jean-Paul Kogelman <jeanpaulkogelman at me.com> wrote:
>>
>> I think implicit QoS is far simpler to implement, requires less parties and is closer to what Bitcoin started out as: a peer-to-peer digital cash system, not a peer-to-let-me-handle-that-for-you-to-peer system.
>>
>> jp
>>
>>> On Jul 24, 2015, at 9:08 AM, Eric Lombrozo <elombrozo at gmail.com> wrote:
>>>
>>> By using third parties separate from individual miners that do bidding on your behalf you get a mechanism that allows QoS guarantees and shifting the complexity and risk from the wallet with little computational resources to a service with abundance of them. Using timelocked contracts it’s possible to enforce the guarantees.
>>>
>>> Negotiating directly with miners via smart contracts seems difficult at best.
>>>
>>>
>>>> On Jul 23, 2015, at 6:03 PM, Jean-Paul Kogelman via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>>
>>>> Doesn't matter.
>>>>
>>>> It's not going to be perfect given the block time variance among other factors but it's far more workable than guessing whether or not your transaction is going to end up in a block at all.
>>>>
>>>> jp
>>>>
>>>>
>>>>> On Jul 24, 2015, at 8:53 AM, Peter Todd <pete at petertodd.org> wrote:
>>>>>
>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>> Hash: SHA256
>>>>>
>>>>>
>>>>>
>>>>>> On 23 July 2015 20:49:20 GMT-04:00, Jean-Paul Kogelman via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>>>>
>>>>>> And it's obvious how a size cap would interfere with such a QoS scheme.
>>>>>> Miners wouldn't be able to deliver the below guarantees if they have to
>>>>>> start excluding transactions.
>>>>>
>>>>> As mining is a random, poisson process, obviously giving guarantees without a majority of hashing power isn't possible.
>>>>>
>>>>>
>>>>> -----BEGIN PGP SIGNATURE-----
>>>>>
>>>>> iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJVsYyK
>>>>> AAoJEMCF8hzn9Lnc47AH/28WlecQLb37CiJpcvXO9tC4zqYEodurtB9nBHTSJrug
>>>>> VIEXZW53pSTdd3vv2qpGIlHxuYP8QmDSATztwQLuN6XWEszz7TO8MXBfLxKqZyGu
>>>>> i83WqSGjMAfwqjl0xR1G7PJgt4+E+0vaAFZc98vLCgZnedbiXRVtTGjhofG1jjTc
>>>>> DFMwMZHP0eqWTwtWwqUvnA7PTFHxdqoJruY/t1KceN+JDbBCJWMxBDswU64FXcVH
>>>>> 0ecsk9nhLMyylBX/2v4HjCXyayocH8jQ+FpLSP0xxERyS+f1npFX9cxFMq24uXqn
>>>>> PcnZfLfaSJ6gMbmhbYG5wYDKN3u732j7dLzSJnMW6jk=
>>>>> =LY1+
>>>>> -----END PGP SIGNATURE-----
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev at lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150723/61072561/attachment.sig>;
📝 Original message:I think it’s pretty clear by now that the assumption that all nodes have pretty similar computational resources leads to very misplaced incentives. Ultimately, cryptocurrencies will allow direct outsourcing of computation, making it possible to distribute computational tasks in an economically sensible way.
Wallets should be assumed to have low computational resources and intermittent Internet connections for the foreseeable future if we ever intend for this to be a practical payment system, methinks.
> On Jul 23, 2015, at 6:28 PM, Eric Lombrozo <elombrozo at gmail.com> wrote:
>
> I suppose you can use a timelocked output that is spendable by anyone you could go somewhat in this direction…the thing is it still means the wallet must make fee estimations rather than being able to get a quick quote.
>
>> On Jul 23, 2015, at 6:25 PM, Jean-Paul Kogelman <jeanpaulkogelman at me.com> wrote:
>>
>> I think implicit QoS is far simpler to implement, requires less parties and is closer to what Bitcoin started out as: a peer-to-peer digital cash system, not a peer-to-let-me-handle-that-for-you-to-peer system.
>>
>> jp
>>
>>> On Jul 24, 2015, at 9:08 AM, Eric Lombrozo <elombrozo at gmail.com> wrote:
>>>
>>> By using third parties separate from individual miners that do bidding on your behalf you get a mechanism that allows QoS guarantees and shifting the complexity and risk from the wallet with little computational resources to a service with abundance of them. Using timelocked contracts it’s possible to enforce the guarantees.
>>>
>>> Negotiating directly with miners via smart contracts seems difficult at best.
>>>
>>>
>>>> On Jul 23, 2015, at 6:03 PM, Jean-Paul Kogelman via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>>
>>>> Doesn't matter.
>>>>
>>>> It's not going to be perfect given the block time variance among other factors but it's far more workable than guessing whether or not your transaction is going to end up in a block at all.
>>>>
>>>> jp
>>>>
>>>>
>>>>> On Jul 24, 2015, at 8:53 AM, Peter Todd <pete at petertodd.org> wrote:
>>>>>
>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>> Hash: SHA256
>>>>>
>>>>>
>>>>>
>>>>>> On 23 July 2015 20:49:20 GMT-04:00, Jean-Paul Kogelman via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>>>>
>>>>>> And it's obvious how a size cap would interfere with such a QoS scheme.
>>>>>> Miners wouldn't be able to deliver the below guarantees if they have to
>>>>>> start excluding transactions.
>>>>>
>>>>> As mining is a random, poisson process, obviously giving guarantees without a majority of hashing power isn't possible.
>>>>>
>>>>>
>>>>> -----BEGIN PGP SIGNATURE-----
>>>>>
>>>>> iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJVsYyK
>>>>> AAoJEMCF8hzn9Lnc47AH/28WlecQLb37CiJpcvXO9tC4zqYEodurtB9nBHTSJrug
>>>>> VIEXZW53pSTdd3vv2qpGIlHxuYP8QmDSATztwQLuN6XWEszz7TO8MXBfLxKqZyGu
>>>>> i83WqSGjMAfwqjl0xR1G7PJgt4+E+0vaAFZc98vLCgZnedbiXRVtTGjhofG1jjTc
>>>>> DFMwMZHP0eqWTwtWwqUvnA7PTFHxdqoJruY/t1KceN+JDbBCJWMxBDswU64FXcVH
>>>>> 0ecsk9nhLMyylBX/2v4HjCXyayocH8jQ+FpLSP0xxERyS+f1npFX9cxFMq24uXqn
>>>>> PcnZfLfaSJ6gMbmhbYG5wYDKN3u732j7dLzSJnMW6jk=
>>>>> =LY1+
>>>>> -----END PGP SIGNATURE-----
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev at lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150723/61072561/attachment.sig>;