đ
Original date posted:2014-06-17
đ Original message:But miners dont want to run full nodes, its better to develop some SPV like
that connects to some nodes.
Also I believe that stratum mining protocol improves some performance
things that GBT lacks.
If a new protocol that requires blocks created by miners is developed and
named in a cool way, miners could ask for protocol support to his favourite
pool.
El 17/06/2014 20:26, "Karel BĂlek" <kb at karelbilek.com> escribiĂł:
> On Tue, Jun 17, 2014 at 4:20 PM, Christophe Biocca
> <christophe.biocca at gmail.com> wrote:
> > https://en.bitcoin.it/wiki/Getblocktemplate is supposed to solve most
> > of the pooling-centralization problems.
>
> This. There is no need to create anything new when GBT already exists.
> In my opinion.
>
> > Unfortunately, it is opt-in,
> > and GHash.io doesn't support it.
>
> Yep. As pools in general are not a part of the bitcoin protocol itself
> (nobody cares how the work happened), I am not sure how this can be
> forced.
>
> > Also most miners don't care and don't do the work to set it up. To do
> > transaction inclusion themselves, they'd need to run a full node,
> > which is a bit more work and resources than just pointing hashpower at
> > a stratum server.
>
> Also, yep. If the miners cared about 51% attack, they wouldn't join
> ghash in the first place. All the miners willingly accept the risk in
> joining the big pool.
>
> K. B.
>
> > If you figure out a way to make GBT widely used (>50% hashpower), kudos
> to you.
> >
> > On Tue, Jun 17, 2014 at 4:57 AM, RaĂșl MartĂnez <rme at i-rme.es> wrote:
> >> First of all I apologice due to the possible mistakes in my writing
> below, I
> >> am not a Bitcoin developer but I have some knowledge about it.
> >>
> >> ----
> >>
> >> We all know the recent news, Ghash pool controlling 51% of the hashrate.
> >> While some consider it a threat others think that is not harmful.
> >>
> >> The thing is that we have to do something to stop this from happening
> again.
> >>
> >> My proposal is to start thinking about miners that join a pool like
> >> independent miners and not slave miners, this includes creating a new
> mining
> >> protocol that does not rely on the pool sending the list of
> transactions to
> >> include in a block. Each individual miner has to collect transactions
> by his
> >> own and mine that, this can be achieved by running a full node or by
> running
> >> a SPV like node that ask other nodes for transactions.
> >>
> >> Once this protocol is developed and standarised we as a community could
> >> require all pools to use it (because its better, because is more
> >> trustless...), not by imposing it but by recommending it.
> >>
> >> Pool owners could send some instructions using this protocol to the
> miner
> >> about how many transactions to include per block (some pools want small
> >> blocks), how many 0 fee transactions to include, how much is the
> minimum fee
> >> per Kb to include transactions and some info about the Coinbase field
> in the
> >> block.
> >>
> >> This way is impossible to perform some of the possible 51% attacks:
> >>
> >> A pool owner cant mine a new chain (selfish mining) (pool clients have
> a SPV
> >> or full node that has checkpoints and ask other peers about the length
> of
> >> the chain)
> >> A pool owner can't perform double spends or reverse transactions (pool
> >> clients know all the transactions relayed to the network, they know if
> they
> >> are already included on a block)
> >> A pool owner cant decide which transactions not to include (but they can
> >> configure the minimum fee).
> >> A pool owner cant get all the rewards by avoiding other pools from
> mining
> >> blocks (Because the pool client knows the last block independently that
> is
> >> from his pool or other).
> >>
> >>
> >> The only thing that a 51% pool owner can do is to shut down his pool and
> >> drop the hashrate by 51% because he does not control the miners.
> >>
> >> If the pool owner owns all the hardware in the pool my proposal is not
> >> valid, if the pool clients dont use this protocol my proposal is not
> valid.
> >>
> >>
> >> I want to know if this is possible or its been developed or there is
> already
> >> a working protocol that works like this, also I want to read other
> people's
> >> ways to address this threat, thanks for reading.
> >>
> >>
> ------------------------------------------------------------------------------
> >> HPCC Systems Open Source Big Data Platform from LexisNexis Risk
> Solutions
> >> Find What Matters Most in Your Big Data with HPCC Systems
> >> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> >> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
> >> http://p.sf.net/sfu/hpccsystems
> >> _______________________________________________
> >> Bitcoin-development mailing list
> >> Bitcoin-development at lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >>
> >
> >
> ------------------------------------------------------------------------------
> > HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
> > Find What Matters Most in Your Big Data with HPCC Systems
> > Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> > Leverages Graph Analysis for Fast Processing & Easy Data Exploration
> > http://p.sf.net/sfu/hpccsystems
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140617/679356fb/attachment.html>;
RaĂșl MartĂnez [ARCHIVE] /
npub1w8âŠa0p0k
2023-06-07 15:23:01
in reply to nevent1qâŠjcdd
Author Public Key
npub1w8ktyq2eljfp607atjk67x29ye6d4l8ugd49twgmpuqnn7eruy2sza0p0kPublished at
2023-06-07 15:23:01Event JSON
{
"id": "19e4ce2a4c4acc70d7673ebe07b9efbdbcbb386d4c6750007ee7ef0a6ae0080a",
"pubkey": "71ecb20159fc921d3fdd5cadaf19452674dafcfc436a55b91b0f0139fb23e115",
"created_at": 1686151381,
"kind": 1,
"tags": [
[
"e",
"6bc868376bf534c9693ce952d73821ac6830976dc7d5d1162ea531f68bf60bda",
"",
"root"
],
[
"e",
"1b3b8a487576a10f98fcfb1df98c7d3f7b2dd679224496b7d98c10828f6a7f49",
"",
"reply"
],
[
"p",
"9a50a6d4edfc66217b3a72f2f0dbda3e04036869f4d046dd56a1356caa962719"
]
],
"content": "đ
Original date posted:2014-06-17\nđ Original message:But miners dont want to run full nodes, its better to develop some SPV like\nthat connects to some nodes.\n\nAlso I believe that stratum mining protocol improves some performance\nthings that GBT lacks.\n\nIf a new protocol that requires blocks created by miners is developed and\nnamed in a cool way, miners could ask for protocol support to his favourite\npool.\nEl 17/06/2014 20:26, \"Karel BĂlek\" \u003ckb at karelbilek.com\u003e escribiĂł:\n\n\u003e On Tue, Jun 17, 2014 at 4:20 PM, Christophe Biocca\n\u003e \u003cchristophe.biocca at gmail.com\u003e wrote:\n\u003e \u003e https://en.bitcoin.it/wiki/Getblocktemplate is supposed to solve most\n\u003e \u003e of the pooling-centralization problems.\n\u003e\n\u003e This. There is no need to create anything new when GBT already exists.\n\u003e In my opinion.\n\u003e\n\u003e \u003e Unfortunately, it is opt-in,\n\u003e \u003e and GHash.io doesn't support it.\n\u003e\n\u003e Yep. As pools in general are not a part of the bitcoin protocol itself\n\u003e (nobody cares how the work happened), I am not sure how this can be\n\u003e forced.\n\u003e\n\u003e \u003e Also most miners don't care and don't do the work to set it up. To do\n\u003e \u003e transaction inclusion themselves, they'd need to run a full node,\n\u003e \u003e which is a bit more work and resources than just pointing hashpower at\n\u003e \u003e a stratum server.\n\u003e\n\u003e Also, yep. If the miners cared about 51% attack, they wouldn't join\n\u003e ghash in the first place. All the miners willingly accept the risk in\n\u003e joining the big pool.\n\u003e\n\u003e K. B.\n\u003e\n\u003e \u003e If you figure out a way to make GBT widely used (\u003e50% hashpower), kudos\n\u003e to you.\n\u003e \u003e\n\u003e \u003e On Tue, Jun 17, 2014 at 4:57 AM, RaĂșl MartĂnez \u003crme at i-rme.es\u003e wrote:\n\u003e \u003e\u003e First of all I apologice due to the possible mistakes in my writing\n\u003e below, I\n\u003e \u003e\u003e am not a Bitcoin developer but I have some knowledge about it.\n\u003e \u003e\u003e\n\u003e \u003e\u003e ----\n\u003e \u003e\u003e\n\u003e \u003e\u003e We all know the recent news, Ghash pool controlling 51% of the hashrate.\n\u003e \u003e\u003e While some consider it a threat others think that is not harmful.\n\u003e \u003e\u003e\n\u003e \u003e\u003e The thing is that we have to do something to stop this from happening\n\u003e again.\n\u003e \u003e\u003e\n\u003e \u003e\u003e My proposal is to start thinking about miners that join a pool like\n\u003e \u003e\u003e independent miners and not slave miners, this includes creating a new\n\u003e mining\n\u003e \u003e\u003e protocol that does not rely on the pool sending the list of\n\u003e transactions to\n\u003e \u003e\u003e include in a block. Each individual miner has to collect transactions\n\u003e by his\n\u003e \u003e\u003e own and mine that, this can be achieved by running a full node or by\n\u003e running\n\u003e \u003e\u003e a SPV like node that ask other nodes for transactions.\n\u003e \u003e\u003e\n\u003e \u003e\u003e Once this protocol is developed and standarised we as a community could\n\u003e \u003e\u003e require all pools to use it (because its better, because is more\n\u003e \u003e\u003e trustless...), not by imposing it but by recommending it.\n\u003e \u003e\u003e\n\u003e \u003e\u003e Pool owners could send some instructions using this protocol to the\n\u003e miner\n\u003e \u003e\u003e about how many transactions to include per block (some pools want small\n\u003e \u003e\u003e blocks), how many 0 fee transactions to include, how much is the\n\u003e minimum fee\n\u003e \u003e\u003e per Kb to include transactions and some info about the Coinbase field\n\u003e in the\n\u003e \u003e\u003e block.\n\u003e \u003e\u003e\n\u003e \u003e\u003e This way is impossible to perform some of the possible 51% attacks:\n\u003e \u003e\u003e\n\u003e \u003e\u003e A pool owner cant mine a new chain (selfish mining) (pool clients have\n\u003e a SPV\n\u003e \u003e\u003e or full node that has checkpoints and ask other peers about the length\n\u003e of\n\u003e \u003e\u003e the chain)\n\u003e \u003e\u003e A pool owner can't perform double spends or reverse transactions (pool\n\u003e \u003e\u003e clients know all the transactions relayed to the network, they know if\n\u003e they\n\u003e \u003e\u003e are already included on a block)\n\u003e \u003e\u003e A pool owner cant decide which transactions not to include (but they can\n\u003e \u003e\u003e configure the minimum fee).\n\u003e \u003e\u003e A pool owner cant get all the rewards by avoiding other pools from\n\u003e mining\n\u003e \u003e\u003e blocks (Because the pool client knows the last block independently that\n\u003e is\n\u003e \u003e\u003e from his pool or other).\n\u003e \u003e\u003e\n\u003e \u003e\u003e\n\u003e \u003e\u003e The only thing that a 51% pool owner can do is to shut down his pool and\n\u003e \u003e\u003e drop the hashrate by 51% because he does not control the miners.\n\u003e \u003e\u003e\n\u003e \u003e\u003e If the pool owner owns all the hardware in the pool my proposal is not\n\u003e \u003e\u003e valid, if the pool clients dont use this protocol my proposal is not\n\u003e valid.\n\u003e \u003e\u003e\n\u003e \u003e\u003e\n\u003e \u003e\u003e I want to know if this is possible or its been developed or there is\n\u003e already\n\u003e \u003e\u003e a working protocol that works like this, also I want to read other\n\u003e people's\n\u003e \u003e\u003e ways to address this threat, thanks for reading.\n\u003e \u003e\u003e\n\u003e \u003e\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e \u003e\u003e HPCC Systems Open Source Big Data Platform from LexisNexis Risk\n\u003e Solutions\n\u003e \u003e\u003e Find What Matters Most in Your Big Data with HPCC Systems\n\u003e \u003e\u003e Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.\n\u003e \u003e\u003e Leverages Graph Analysis for Fast Processing \u0026 Easy Data Exploration\n\u003e \u003e\u003e http://p.sf.net/sfu/hpccsystems\n\u003e \u003e\u003e _______________________________________________\n\u003e \u003e\u003e Bitcoin-development mailing list\n\u003e \u003e\u003e Bitcoin-development at lists.sourceforge.net\n\u003e \u003e\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e \u003e\u003e\n\u003e \u003e\n\u003e \u003e\n\u003e ------------------------------------------------------------------------------\n\u003e \u003e HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions\n\u003e \u003e Find What Matters Most in Your Big Data with HPCC Systems\n\u003e \u003e Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.\n\u003e \u003e Leverages Graph Analysis for Fast Processing \u0026 Easy Data Exploration\n\u003e \u003e http://p.sf.net/sfu/hpccsystems\n\u003e \u003e _______________________________________________\n\u003e \u003e Bitcoin-development mailing list\n\u003e \u003e Bitcoin-development at lists.sourceforge.net\n\u003e \u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140617/679356fb/attachment.html\u003e",
"sig": "3e251ed5554ee070da109d31e029cf55c8fb96bfd5f53f7334ffa38fab0d1069775b2ebe85f919a1ed1d0cebc3ccc88a7870c1b8820e2bffd38f47d40ecd1730"
}