đź“… Original date posted:2015-07-23
đź“ť Original message:Miners could include their fee tiers in the coinbase, but this is obviously open to manipulation, with little recourse (unless they are a pool and miners move away because of it).
In any event, I think that trying out a solution that is both simple and involves the least number of parties necessary is preferable.
Have miners set their tiers, have users select the level of quality they want, ignore the block size.
Miners will adapt their tiers depending on how many transactions actually end up in them. If for example they set the first tier to be $1 to be included in the current block and no user chooses that level of service, they've obviously priced themselves out of the market. The opposite is also true; if a tier is popular they can choose to increase the cost of that tier.
jp
> On Jul 24, 2015, at 9:28 AM, 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
>
Jean-Paul Kogelman [ARCHIVE] /
npub1sa…8y304
2023-06-07 15:42:59
in reply to nevent1q…qzt5
Author Public Key
npub1sa86gng3pvs3jgyt5majwcrhn8ck5qxgy9pjqxkh79u638cd7dys28y304Published at
2023-06-07 15:42:59Event JSON
{
"id": "439890d243ab87803ff5fe37fd447cf5edc61bd5a6081c298c974a4fc543cfe7",
"pubkey": "874fa44d110b2119208ba6fb27607799f16a00c82143201ad7f179a89f0df349",
"created_at": 1686152579,
"kind": 1,
"tags": [
[
"e",
"95a36d78d6bf18f4b8ede735f044f5cc9630ae9f0b1198d008835777ff84eede",
"",
"root"
],
[
"e",
"d20be6090c19c6cef5e1d062dc15562552c0bae69c4b0bff197861b2ced4380a",
"",
"reply"
],
[
"p",
"e899768d254f3537af7e26455968583632d0ab0bd4c780445eacfa087ac80d8f"
]
],
"content": "📅 Original date posted:2015-07-23\n📝 Original message:Miners could include their fee tiers in the coinbase, but this is obviously open to manipulation, with little recourse (unless they are a pool and miners move away because of it). \n\nIn any event, I think that trying out a solution that is both simple and involves the least number of parties necessary is preferable.\n\nHave miners set their tiers, have users select the level of quality they want, ignore the block size.\n\nMiners will adapt their tiers depending on how many transactions actually end up in them. If for example they set the first tier to be $1 to be included in the current block and no user chooses that level of service, they've obviously priced themselves out of the market. The opposite is also true; if a tier is popular they can choose to increase the cost of that tier.\n\njp \n\n\u003e On Jul 24, 2015, at 9:28 AM, Eric Lombrozo \u003celombrozo at gmail.com\u003e wrote:\n\u003e \n\u003e 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.\n\u003e \n\u003e\u003e On Jul 23, 2015, at 6:25 PM, Jean-Paul Kogelman \u003cjeanpaulkogelman at me.com\u003e wrote:\n\u003e\u003e \n\u003e\u003e 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.\n\u003e\u003e \n\u003e\u003e jp\n\u003e\u003e \n\u003e\u003e\u003e On Jul 24, 2015, at 9:08 AM, Eric Lombrozo \u003celombrozo at gmail.com\u003e wrote:\n\u003e\u003e\u003e \n\u003e\u003e\u003e 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.\n\u003e\u003e\u003e \n\u003e\u003e\u003e Negotiating directly with miners via smart contracts seems difficult at best.\n\u003e\u003e\u003e \n\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e On Jul 23, 2015, at 6:03 PM, Jean-Paul Kogelman via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e Doesn't matter.\n\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e 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.\n\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e jp\n\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e\u003e On Jul 24, 2015, at 8:53 AM, Peter Todd \u003cpete at petertodd.org\u003e wrote:\n\u003e\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e\u003e -----BEGIN PGP SIGNED MESSAGE-----\n\u003e\u003e\u003e\u003e\u003e Hash: SHA256\n\u003e\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e\u003e\u003e On 23 July 2015 20:49:20 GMT-04:00, Jean-Paul Kogelman via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e\u003e\u003e And it's obvious how a size cap would interfere with such a QoS scheme.\n\u003e\u003e\u003e\u003e\u003e\u003e Miners wouldn't be able to deliver the below guarantees if they have to\n\u003e\u003e\u003e\u003e\u003e\u003e start excluding transactions.\n\u003e\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e\u003e As mining is a random, poisson process, obviously giving guarantees without a majority of hashing power isn't possible.\n\u003e\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e\u003e -----BEGIN PGP SIGNATURE-----\n\u003e\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e\u003e iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJVsYyK\n\u003e\u003e\u003e\u003e\u003e AAoJEMCF8hzn9Lnc47AH/28WlecQLb37CiJpcvXO9tC4zqYEodurtB9nBHTSJrug\n\u003e\u003e\u003e\u003e\u003e VIEXZW53pSTdd3vv2qpGIlHxuYP8QmDSATztwQLuN6XWEszz7TO8MXBfLxKqZyGu\n\u003e\u003e\u003e\u003e\u003e i83WqSGjMAfwqjl0xR1G7PJgt4+E+0vaAFZc98vLCgZnedbiXRVtTGjhofG1jjTc\n\u003e\u003e\u003e\u003e\u003e DFMwMZHP0eqWTwtWwqUvnA7PTFHxdqoJruY/t1KceN+JDbBCJWMxBDswU64FXcVH\n\u003e\u003e\u003e\u003e\u003e 0ecsk9nhLMyylBX/2v4HjCXyayocH8jQ+FpLSP0xxERyS+f1npFX9cxFMq24uXqn\n\u003e\u003e\u003e\u003e\u003e PcnZfLfaSJ6gMbmhbYG5wYDKN3u732j7dLzSJnMW6jk=\n\u003e\u003e\u003e\u003e\u003e =LY1+\n\u003e\u003e\u003e\u003e\u003e -----END PGP SIGNATURE-----\n\u003e\u003e\u003e\u003e _______________________________________________\n\u003e\u003e\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e",
"sig": "b14b55e5202011f019f83b82189b0c724eb39465cd1dd78f3a40bcaa942c590e214eca3d142dd1c77b781cef47c02f237331c334cbebf015c05d6251c5413e1e"
}