đź“… Original date posted:2012-05-29
đź“ť Original message:Peter, I like the idea of being able to know what fees to expect from different miners (it is like a service description / SLA for their service), but I would prefer a more distributed discovery mechanism for the information on the fees (Spent 10 years on Grid Computing...).
Miners could e.g. include a pointer to a webpage (or even their min fee) in the coinbase (encoded properly, like the "/P2SH/" string for BIP0016). That way clients could look it up them selves or you could create sites accumulating this information from the chain it self.
So something like :
const char* service_sla = "|https://my_ubercool_asic_mining_pool/sla.php|";
COINBASE_FLAGS << std::vector<unsigned char>(service_sla, service_sla+strlen(service_sla));
The format of the sla.php page should then be specified too - but it could be a json-rpc call returning a json object like (as result):
{
sla_version: "0.1",
accept_no_fee_tx: false,
min_fee: 50000,
big_tx_fee: 10000, // extra fee pr kb
}
I guess miners could work out a more suitable set of fees...
Seems like this calls for a BIP ?
/M
On 28/05/2012, at 16:54, Peter Vessenes wrote:
> One of the issues here though is that it would be nice if miners published their own tx rules -- it might be hard to impute them from data.
>
> I had started a thread about this on bitcoin.org some time ago, and I don't recall what the general outcome was.
>
> I had imagined an open service whereby a miner could publish a short string in their conbase tying to the service and the service would have different metadata, including the miner's transaction guarantees.
>
> We offered to host this before, and would still be willing to host such a service.
>
> Peter
>
> On Sat, May 26, 2012 at 7:52 AM, Stefan Thomas <moon at justmoon.de> wrote:
> Zooko is spot on - slower confirmations will give people a reason to set
> higher fees. As soon as fees reach a level where they matter, even
> botnet operators will be looking into ways of including transactions for
> some extra profit.
>
> In the meantime slightly slower confirmations aren't a problem. Consider
> that even if it takes four blocks to get your transaction included
> instead of one, once it is included, you still benefit from every new
> block in terms of security. So if you're looking for six confirmations
> for example, even a three block delay will only be a 50% delay for you.
> And of course there are techniques for instant transactions which
> continue to be refined and improved.
>
> As for the proposed solutions: Punishing 1-tx blocks is complete and
> utter nonsense. It's trivial to include a bogus second transaction.
>
> Any additional challenges towards miners like hashes of the previous
> block are at best useless. If I was running a botnet, I'd just grab that
> hash from a website (pretty good chance Blockchain.info will have it :P)
> or mining pool or wherever and keep going undeterred. At worst they may
> affect scalability one day. You might imagine a peer-to-peer network of
> miners who for cost reasons don't download all blocks anymore, but
> verify only a percentage of them at random. They might then exchange
> messages about invalid blocks including a proof (invalid tx, merkle
> branch) why the block is invalid. This is just one idea, the point is
> that assumptions about what a legitimate miner looks like may not always
> hold in the future.
>
> Finally, there is an ethical aspect as well. If a miner wishes not to
> include my transaction that is his choice. He has no more an obligation
> to sell his service to me than I have to buy it from him. If I really,
> really want him to include my transaction I will have to offer to pay more.
>
> If we as developers think that confirmations are too slow or that more
> blocks should include transactions, then the right measures would be:
>
> - Educating users about the relationship between confirmation speed and fees
> - Raising the default transaction fee
>
> Every market has a supply curve, so it is economically to be expected
> that there will be some miners who don't include transactions, simply
> because they are at that end of the supply curve where it is not worth
> it for them to sell their service. All markets must have a certain
> tension - there must be miners who don't include transactions for there
> to be users who want their transactions included more quickly. In other
> words there must be somebody not confirming if confirmations are to have
> value. If you interfere with that all you'll accomplish is keep
> transaction fees below market level, which will make the transition from
> inflation-financed hashing to transaction-financed hashing more painful
> and disruptive.
>
> Cheers,
>
> Stefan
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
> --
>
> Peter J. Vessenes
> CEO, CoinLab
> M: 206.595.9839
> Skype: vessenes
> Google+
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Michael Gronager, PhD
Director, Ceptacle
Jens Juels Gade 33
2100 Copenhagen E
Mobile: +45 31 45 14 01
E-mail: gronager at ceptacle.com
Web: http://www.ceptacle.com/
Michael Grønager [ARCHIVE] /
npub15f…xlq6h
2023-06-07 10:10:15
in reply to nevent1q…88dr
Author Public Key
npub15fmnxm546tg2sv0l7elusrvqsgezdzdg3m0flpml5fr2qf3f5slskxlq6hSeen on
wss://relay.nostr.bandPublished at
2023-06-07 10:10:15Event JSON
{
"id": "6a44fb332d663438dad74b7d49a0e6ad66197c46556b5dcfd58227f0cb597a43",
"pubkey": "a277336e95d2d0a831fff67fc80d8082322689a88ede9f877fa246a02629a43f",
"created_at": 1686132615,
"kind": 1,
"tags": [
[
"e",
"bea123cfa1dde96d98089cdcf953f77564e34363cd7b11c4a3504634664d4aa2",
"",
"root"
],
[
"e",
"3374349e9d9f0c8e3674d612f8006476635b1930e0f214742e2ca040aabeba82",
"",
"reply"
],
[
"p",
"c8914ab5f1efb93771e9c5b7fe20dcff2c343f46f4846ae6689a0c9478b04e01"
]
],
"content": "đź“… Original date posted:2012-05-29\nđź“ť Original message:Peter, I like the idea of being able to know what fees to expect from different miners (it is like a service description / SLA for their service), but I would prefer a more distributed discovery mechanism for the information on the fees (Spent 10 years on Grid Computing...).\n\nMiners could e.g. include a pointer to a webpage (or even their min fee) in the coinbase (encoded properly, like the \"/P2SH/\" string for BIP0016). That way clients could look it up them selves or you could create sites accumulating this information from the chain it self.\n\nSo something like :\n const char* service_sla = \"|https://my_ubercool_asic_mining_pool/sla.php|\";\n COINBASE_FLAGS \u003c\u003c std::vector\u003cunsigned char\u003e(service_sla, service_sla+strlen(service_sla));\n \nThe format of the sla.php page should then be specified too - but it could be a json-rpc call returning a json object like (as result):\n{ \n sla_version: \"0.1\",\n accept_no_fee_tx: false,\n min_fee: 50000,\n big_tx_fee: 10000, // extra fee pr kb\n}\nI guess miners could work out a more suitable set of fees...\n\nSeems like this calls for a BIP ?\n\n/M\n\n\n\nOn 28/05/2012, at 16:54, Peter Vessenes wrote:\n\n\u003e One of the issues here though is that it would be nice if miners published their own tx rules -- it might be hard to impute them from data.\n\u003e \n\u003e I had started a thread about this on bitcoin.org some time ago, and I don't recall what the general outcome was.\n\u003e \n\u003e I had imagined an open service whereby a miner could publish a short string in their conbase tying to the service and the service would have different metadata, including the miner's transaction guarantees.\n\u003e \n\u003e We offered to host this before, and would still be willing to host such a service.\n\u003e \n\u003e Peter\n\u003e \n\u003e On Sat, May 26, 2012 at 7:52 AM, Stefan Thomas \u003cmoon at justmoon.de\u003e wrote:\n\u003e Zooko is spot on - slower confirmations will give people a reason to set\n\u003e higher fees. As soon as fees reach a level where they matter, even\n\u003e botnet operators will be looking into ways of including transactions for\n\u003e some extra profit.\n\u003e \n\u003e In the meantime slightly slower confirmations aren't a problem. Consider\n\u003e that even if it takes four blocks to get your transaction included\n\u003e instead of one, once it is included, you still benefit from every new\n\u003e block in terms of security. So if you're looking for six confirmations\n\u003e for example, even a three block delay will only be a 50% delay for you.\n\u003e And of course there are techniques for instant transactions which\n\u003e continue to be refined and improved.\n\u003e \n\u003e As for the proposed solutions: Punishing 1-tx blocks is complete and\n\u003e utter nonsense. It's trivial to include a bogus second transaction.\n\u003e \n\u003e Any additional challenges towards miners like hashes of the previous\n\u003e block are at best useless. If I was running a botnet, I'd just grab that\n\u003e hash from a website (pretty good chance Blockchain.info will have it :P)\n\u003e or mining pool or wherever and keep going undeterred. At worst they may\n\u003e affect scalability one day. You might imagine a peer-to-peer network of\n\u003e miners who for cost reasons don't download all blocks anymore, but\n\u003e verify only a percentage of them at random. They might then exchange\n\u003e messages about invalid blocks including a proof (invalid tx, merkle\n\u003e branch) why the block is invalid. This is just one idea, the point is\n\u003e that assumptions about what a legitimate miner looks like may not always\n\u003e hold in the future.\n\u003e \n\u003e Finally, there is an ethical aspect as well. If a miner wishes not to\n\u003e include my transaction that is his choice. He has no more an obligation\n\u003e to sell his service to me than I have to buy it from him. If I really,\n\u003e really want him to include my transaction I will have to offer to pay more.\n\u003e \n\u003e If we as developers think that confirmations are too slow or that more\n\u003e blocks should include transactions, then the right measures would be:\n\u003e \n\u003e - Educating users about the relationship between confirmation speed and fees\n\u003e - Raising the default transaction fee\n\u003e \n\u003e Every market has a supply curve, so it is economically to be expected\n\u003e that there will be some miners who don't include transactions, simply\n\u003e because they are at that end of the supply curve where it is not worth\n\u003e it for them to sell their service. All markets must have a certain\n\u003e tension - there must be miners who don't include transactions for there\n\u003e to be users who want their transactions included more quickly. In other\n\u003e words there must be somebody not confirming if confirmations are to have\n\u003e value. If you interfere with that all you'll accomplish is keep\n\u003e transaction fees below market level, which will make the transition from\n\u003e inflation-financed hashing to transaction-financed hashing more painful\n\u003e and disruptive.\n\u003e \n\u003e Cheers,\n\u003e \n\u003e Stefan\n\u003e \n\u003e ------------------------------------------------------------------------------\n\u003e Live Security Virtual Conference\n\u003e Exclusive live event will cover all the ways today's security and\n\u003e threat landscape has changed and how IT managers can respond. Discussions\n\u003e will include endpoint security, mobile security and the latest in malware\n\u003e threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e \n\u003e \n\u003e \n\u003e -- \n\u003e \t\n\u003e Peter J. Vessenes\n\u003e CEO, CoinLab\n\u003e M: 206.595.9839\n\u003e Skype: vessenes\n\u003e Google+\n\u003e \n\u003e ------------------------------------------------------------------------------\n\u003e Live Security Virtual Conference\n\u003e Exclusive live event will cover all the ways today's security and \n\u003e threat landscape has changed and how IT managers can respond. Discussions \n\u003e will include endpoint security, mobile security and the latest in malware \n\u003e threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\nMichael Gronager, PhD\nDirector, Ceptacle\nJens Juels Gade 33\n2100 Copenhagen E\nMobile: +45 31 45 14 01\nE-mail: gronager at ceptacle.com\nWeb: http://www.ceptacle.com/",
"sig": "065fb2b928375d00ace5dcfdbbd161d36a17512eadfcb5912b6ca0ca94d4e03982dfe87b6fbc5000543432aa23636248997ca0e875d4d66590c421c2b27a6ca7"
}