Ron Elliott [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2014-06-17 to 2014-07-04
💬 Posted a total of 3 messages
📚 Participated in the following categories: Bitcoin-development
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 15:23:36

- reply

📅 Original date posted:2014-07-04
📝 Original message:I feel everyone should re-read that last paragraph as it carries the most
weight IMO.
On Fri, Jul 4, 2014 at 9:50 AM, kjj <bitcoin-devel at jerviss.org> wrote:
> Just some general comments on this topic/discussion.
>
> I suspect that there exist no algorithms which cannot be done better in
> an application-specific device than in a general purpose computer. And
> if there is such a thing, then it must necessarily perform best on one
> specific platform, making that platform the de facto application
> specific device.
>
> I'm not sure how one would go about proving or disproving that, but it
> seems very likely to be true.
>
> IO-bound is exactly the same as memory bound, for devices that have
> enough memory. 20 GB is already trivial today, and you don't really get
> into ask-the-wife-for-permission money until you cross 128 GB. The
> exception would be if the IO was to an oracle outside of the device's
> control, and artificially limited in throughput. Such a centralized
> oracle would be contrary to the goals usually stated by people thinking
> about anti-ASIC designs, so there isn't much point.
>
> Keeping the algorithm simple, and ASIC-easy, has one other advantage.
> Just about anyone can sit down and design an ASIC for SHA, for example,
> leading to diversity in the marketplace. A harder algorithm can still
> be made into an ASIC (or more generally into an ASD), but will require
> more skilled designers, more expensive fabrication, etc. This actually
> concentrates the ASIC advantage into the hands of fewer people, which
> again, is contrary to the stated goals.
>
>
> ------------------------------------------------------------------------------
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
- Ron
end of line.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140704/99018773/attachment.html>

2023-06-07 15:23:36

- reply

2023-06-07 15:23:00

- reply

📅 Original date posted:2014-06-17
📝 Original message:as I understood your proposal the entire block would be created on the
miner rather than just the block header. Currently miners do not receive a
list of transactions, they receive information required to create the block
header, this is how you keep miners honest. if the miner is creating the
full block we are right back to where we were.
I've only worked with implementing the mining process for a few months now
so someone correct me if I have the process wrong
On Jun 17, 2014 7:01 AM, "Raúl Martínez" <rme at i-rme.es> wrote:
> Because he cant change the coinbase once the proof of work is done.
> El 17/06/2014 15:58, "Ron Elliott" <ronaldbelliott at gmail.com> escribió:
>
>> In this scenario how do you ensure the miner solving the block cannot
>> reapportion the subsidy to himself rather than the pool?
>> On Jun 17, 2014 2:09 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
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140617/14874493/attachment.html>

2023-06-07 15:23:00

- reply

2023-06-07 15:22:59

- reply

📅 Original date posted:2014-06-17
📝 Original message:In this scenario how do you ensure the miner solving the block cannot
reapportion the subsidy to himself rather than the pool?
On Jun 17, 2014 2:09 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140617/7251f9ba/attachment.html>

2023-06-07 15:22:59

- reply