š
Original date posted:2013-10-24
š Original message:On Thu, Oct 24, 2013 at 04:46:41PM +0200, Mike Hearn wrote:
> Well, miners are all supposed to be more or less equivalent - modulo
> differences in tx acceptance policies - so I'd hope that having out of bad
> fee mechanisms yet still broadcasting the TX isn't that common. If it was
> broadcasted, it should get mined in short order, otherwise things are going
> wrong.
Eligius has contracts to do transaction mining, and it's currently 10%
of the hashing power.
As I said elsewhere, a good use-case for OOB fee payment is for
merchants who use the payment protocol, and want to get their customers
transactions mined as efficiently and cheaply as possible.
(child-pays-for-parent has more blockchain bloat and thus extra expense)
> On Thu, Oct 24, 2013 at 4:43 PM, Peter Todd <pete at petertodd.org> wrote:
>
> > Anyway, in what circumstance would a customer want an exclusive contract
> > with a miner?
> >
>
> I was thinking for transactions that aren't standard so have to be
> submitted to miners directly.
Sure, but even then there's no harm in letting more than one miner know
about it.
There's even an existing form of this: P2Pool lets shares be accompanied
by up to 50KB worth of transactions of any form.
--
'peter'[:-1]@petertodd.org
000000000000000d2860c825ea223b805c60a33b26b9b70616698033d360b066
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 685 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131024/2cd3d55b/attachment.sig>;
Peter Todd [ARCHIVE] /
npub1m2ā¦a2np2
2023-06-07 15:07:53
in reply to nevent1qā¦t2dp
Author Public Key
npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2Published at
2023-06-07 15:07:53Event JSON
{
"id": "f7da0ce1d0ec5fd9fcf482a5be7a775a6a97b9df6b57ca2dc4448296d560ac51",
"pubkey": "daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa",
"created_at": 1686150473,
"kind": 1,
"tags": [
[
"e",
"82aca9d85d9f8088587f8710d511958183b300f7daa0a8fd33090fc324b509ac",
"",
"root"
],
[
"e",
"223eaef525be21128b4419703834b9628b96028c62b93f798cc4de02548959f3",
"",
"reply"
],
[
"p",
"f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2"
]
],
"content": "š
Original date posted:2013-10-24\nš Original message:On Thu, Oct 24, 2013 at 04:46:41PM +0200, Mike Hearn wrote:\n\u003e Well, miners are all supposed to be more or less equivalent - modulo\n\u003e differences in tx acceptance policies - so I'd hope that having out of bad\n\u003e fee mechanisms yet still broadcasting the TX isn't that common. If it was\n\u003e broadcasted, it should get mined in short order, otherwise things are going\n\u003e wrong.\n\nEligius has contracts to do transaction mining, and it's currently 10%\nof the hashing power.\n\nAs I said elsewhere, a good use-case for OOB fee payment is for\nmerchants who use the payment protocol, and want to get their customers\ntransactions mined as efficiently and cheaply as possible.\n(child-pays-for-parent has more blockchain bloat and thus extra expense)\n\n\u003e On Thu, Oct 24, 2013 at 4:43 PM, Peter Todd \u003cpete at petertodd.org\u003e wrote:\n\u003e \n\u003e \u003e Anyway, in what circumstance would a customer want an exclusive contract\n\u003e \u003e with a miner?\n\u003e \u003e\n\u003e \n\u003e I was thinking for transactions that aren't standard so have to be\n\u003e submitted to miners directly.\n\nSure, but even then there's no harm in letting more than one miner know\nabout it.\n\nThere's even an existing form of this: P2Pool lets shares be accompanied\nby up to 50KB worth of transactions of any form.\n\n-- \n'peter'[:-1]@petertodd.org\n000000000000000d2860c825ea223b805c60a33b26b9b70616698033d360b066\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 685 bytes\nDesc: Digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131024/2cd3d55b/attachment.sig\u003e",
"sig": "e5bbeed4016f236afc3bd822dd11133e2d458c098d35352ad3c264be6b3575eb926d7dca1e7c04644ea21e4e788fa2cacc420aa75437a413659f7224499ad49b"
}