Bitcoin Forum
December 14, 2019, 07:59:23 AM *
News: Latest Bitcoin Core release: 0.19.0.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 [693] 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 »
  Print  
Author Topic: [ANN] Spondoolies-Tech - carrier grade, data center ready mining rigs  (Read 1256618 times)
This is a self-moderated topic. If you do not want to be moderated by the person who started this topic, create a new topic.
OgNasty
Donator
Legendary
*
Offline Offline

Activity: 3122
Merit: 1747


I 💚 Bitcoin


View Profile
January 21, 2016, 09:53:23 PM
Last edit: January 22, 2016, 10:29:58 AM by OgNasty
 #13841

Quote
Quoting a recent Hacker News comment of mine (https://news.ycombinator.com/threads?id=tromp)
 Bitcoin mining could be more decentralized if it better resembled a lottery, where huge numbers of people play for an expected loss.

Ya, lets make it so the people who are the backbone of Bitcoin all lose money in a gambling ring!  That's the solution!

1576310363
Hero Member
*
Offline Offline

Posts: 1576310363

View Profile Personal Message (Offline)

Ignore
1576310363
Reply with quote  #2

1576310363
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1576310363
Hero Member
*
Offline Offline

Posts: 1576310363

View Profile Personal Message (Offline)

Ignore
1576310363
Reply with quote  #2

1576310363
Report to moderator
1576310363
Hero Member
*
Offline Offline

Posts: 1576310363

View Profile Personal Message (Offline)

Ignore
1576310363
Reply with quote  #2

1576310363
Report to moderator
1576310363
Hero Member
*
Offline Offline

Posts: 1576310363

View Profile Personal Message (Offline)

Ignore
1576310363
Reply with quote  #2

1576310363
Report to moderator
Guy Corem
Donator
Legendary
*
Offline Offline

Activity: 1288
Merit: 1035


Spondoolies, Beam & DAGlabs


View Profile WWW
January 22, 2016, 12:05:25 PM
 #13842

Memory bound hashing is very good suggestion: https://github.com/tromp/cuckoo
Is that really any better?

Quoting a recent Hacker News comment of mine (https://news.ycombinator.com/threads?id=tromp)
Quote
Bitcoin mining could be more decentralized if it better resembled a lottery, where huge numbers of people play for an expected loss.

In other words, the lack of people mining at a loss makes mining profitable and hence subject to forces of centralization.

There are several reasons why mining as a lottery substitute is rare, a major one being that commodity hardware is inefficient by many orders of magnitude, making even a botnet next to useless.

Perhaps, if a proof of work, whose efficiency gap (with custom hardware) is at most an order of magnitude, were adopted (or slowly phased in), enough lottery players would arise to make mining unprofitable at scale.

Botnets should then just be welcomed as a modest increase in decentralization.

However I don't expect Spondoolies-Tech to support this vision of unprofitable mining...

Disclaimer: I designed Cuckoo Cycle
Hello John, nice to meet you in our little thread. Mind the dog.
Although I really like Cuckoo Cycle, memory bound hashing is too much susceptible to BotNets, unlike GPU hashing.

The biggest problem with PoW change in general is hash-rate oscillation. Emin Gün Sirer just solved it for me. I'll publish my suggestion soon.
In an essence, It allow automatic change of PoW with only one Hard Fork needed.

Guy

New Mimblewimble implementation: https://www.beam.mw
Spondoolies is back with the SPx36: https://www.spondoolies-tech.com/products/spx36
Guy Corem
Donator
Legendary
*
Offline Offline

Activity: 1288
Merit: 1035


Spondoolies, Beam & DAGlabs


View Profile WWW
January 23, 2016, 06:18:32 PM
 #13843

Lesson learned from the Classic coup attempt or why Core needs to prepare a GPU only PoW:
https://medium.com/@vcorem/lesson-learned-from-the-classic-coup-attempt-or-why-core-needs-to-prepare-a-gpu-only-pow-6a9afe18e4b0#.u3mah7u5q

New Mimblewimble implementation: https://www.beam.mw
Spondoolies is back with the SPx36: https://www.spondoolies-tech.com/products/spx36
dogie
Legendary
*
Offline Offline

Activity: 1652
Merit: 1119


dogiecoin.com


View Profile WWW
January 23, 2016, 06:36:41 PM
 #13844


I think the question everyone has been asking is, why are you advocating for PoW changes that delete your own company?

el_rlee
Legendary
*
Offline Offline

Activity: 1584
Merit: 1005



View Profile
January 23, 2016, 07:43:48 PM
 #13845


I think the question everyone has been asking is, why are you advocating for PoW changes that delete your own company?

Bizarre.

Can we take it as granted, that there will be no SP50? It's a real pity watching!
 
tromp
Hero Member
*****
Offline Offline

Activity: 619
Merit: 547


View Profile
January 23, 2016, 08:08:46 PM
 #13846

Lesson learned from the Classic coup attempt or why Core needs to prepare a GPU only PoW:

...
prepare a large set of cryptographic hash functions, at least 100 or more initially. Any simple (not memory hard) function will do
...
Each PoW function actually serves for 5 months
...

This proposal if implemented correctly, will bring a never ending GPU mining on Core chain.

Won't this centralize on private armies of GPU programmers hired to optimize all these hash functions, which they then of course will keep private?

Or perhaps it will centralize on private armies of FPGA designers and (access to) FPGA foundries?

Who will be responsible for developing the GPU code that the public at large is supposed to run?
Will they cater to all the different GPU architectures and models?
Guy Corem
Donator
Legendary
*
Offline Offline

Activity: 1288
Merit: 1035


Spondoolies, Beam & DAGlabs


View Profile WWW
January 23, 2016, 08:11:40 PM
 #13847

Lesson learned from the Classic coup attempt or why Core needs to prepare a GPU only PoW:

...
prepare a large set of cryptographic hash functions, at least 100 or more initially. Any simple (not memory hard) function will do
...
Each PoW function actually serves for 5 months
...

This proposal if implemented correctly, will bring a never ending GPU mining on Core chain.

Won't this centralize on private armies of GPU programmers hired to optimize all these hash functions, which they then of course will keep private?

Or perhaps it will centralize on private armies of FPGA designers and (access to) FPGA foundries?

Who will be responsible for developing the GPU code that the public at large is supposed to run?
Will they cater to all the different GPU architectures and models?

Hi John,
Yes I agree there will be race to develop GPUs (and maybe FPGAs).
There will also be massive deployments of GPUs farms.
I don't see the above as bad things.

Guy

New Mimblewimble implementation: https://www.beam.mw
Spondoolies is back with the SPx36: https://www.spondoolies-tech.com/products/spx36
el_rlee
Legendary
*
Offline Offline

Activity: 1584
Merit: 1005



View Profile
January 23, 2016, 08:24:09 PM
 #13848

Lesson learned from the Classic coup attempt or why Core needs to prepare a GPU only PoW:

...
prepare a large set of cryptographic hash functions, at least 100 or more initially. Any simple (not memory hard) function will do
...
Each PoW function actually serves for 5 months
...

This proposal if implemented correctly, will bring a never ending GPU mining on Core chain.

Won't this centralize on private armies of GPU programmers hired to optimize all these hash functions, which they then of course will keep private?

Or perhaps it will centralize on private armies of FPGA designers and (access to) FPGA foundries?

Who will be responsible for developing the GPU code that the public at large is supposed to run?
Will they cater to all the different GPU architectures and models?

Hi John,
Yes I agree there will be race to develop GPUs (and maybe FPGAs).
There will also be massive deployments of GPUs farms.
I don't see the above as bad things.

Guy

Maybe I'm a bit naive, but isn't the hashpower keeping the network safe? So nobody can take it over? Aren't ASICs doing that job pretty well?
Changing the PoW - that's an altcoin then. The current miners will not follow, so it's gonna split into two - of which only one has powerful ASIC mining which is doing above mentioned job pretty fine.
Is there something I don't get?
Guy Corem
Donator
Legendary
*
Offline Offline

Activity: 1288
Merit: 1035


Spondoolies, Beam & DAGlabs


View Profile WWW
January 23, 2016, 08:57:33 PM
 #13849

Lesson learned from the Classic coup attempt or why Core needs to prepare a GPU only PoW:

...
prepare a large set of cryptographic hash functions, at least 100 or more initially. Any simple (not memory hard) function will do
...
Each PoW function actually serves for 5 months
...

This proposal if implemented correctly, will bring a never ending GPU mining on Core chain.

Won't this centralize on private armies of GPU programmers hired to optimize all these hash functions, which they then of course will keep private?

Or perhaps it will centralize on private armies of FPGA designers and (access to) FPGA foundries?

Who will be responsible for developing the GPU code that the public at large is supposed to run?
Will they cater to all the different GPU architectures and models?

Hi John,
Yes I agree there will be race to develop GPUs (and maybe FPGAs).
There will also be massive deployments of GPUs farms.
I don't see the above as bad things.

Guy

Maybe I'm a bit naive, but isn't the hashpower keeping the network safe? So nobody can take it over? Aren't ASICs doing that job pretty well?
Changing the PoW - that's an altcoin then. The current miners will not follow, so it's gonna split into two - of which only one has powerful ASIC mining which is doing above mentioned job pretty fine.
Is there something I don't get?
Please read the article. The scenario I'm describing is AFTER Classic was activated.

New Mimblewimble implementation: https://www.beam.mw
Spondoolies is back with the SPx36: https://www.spondoolies-tech.com/products/spx36
OgNasty
Donator
Legendary
*
Offline Offline

Activity: 3122
Merit: 1747


I 💚 Bitcoin


View Profile
January 23, 2016, 09:16:41 PM
 #13850

Can you imagine giving ASIC manufacturers the power to influence a PoW system?

Guy Corem
Donator
Legendary
*
Offline Offline

Activity: 1288
Merit: 1035


Spondoolies, Beam & DAGlabs


View Profile WWW
January 23, 2016, 09:19:02 PM
 #13851

Can you imagine giving ASIC manufacturers the power to influence a PoW system?
Have you read the article ?

New Mimblewimble implementation: https://www.beam.mw
Spondoolies is back with the SPx36: https://www.spondoolies-tech.com/products/spx36
p3yot33at3r
Sr. Member
****
Offline Offline

Activity: 266
Merit: 250



View Profile
January 23, 2016, 09:19:47 PM
 #13852

Hello Guy,

Nice to see you back  Wink

Interesting subject & conversation. Personally, I'll go with whatever the concensus is regarding Bitcoin but what I'd like to see, in whatever client is adopted/survives is that any block that contains zero transactions be rejected by the network. This would not only help speed up transactions, but also give the badly coded/lazy/greedy pools a kick up the backside to sort their act out. If there is an algo change, so be it, the huge asics farms can mine other SHA256 coins, which will create competition & thus encourage innovation. I'm sure it won't be the last time a change is implemented by whoever or for whatever means, it's evolution. Nothing stays the same, especially in the coding/crypto world. If it did, it would be surpassed by a more forward thinking & innovative coin & die.

There seems to be a lot of panic & agendas regarding what's going to happen, but I think it's mostly unfounded & Bitcoin will do what it has always done - find a way & overcome any hurdles it comes across on this fun & interesting journey we're on.
tromp
Hero Member
*****
Offline Offline

Activity: 619
Merit: 547


View Profile
January 23, 2016, 09:27:36 PM
 #13853

any block that contains zero transactions be rejected by the network. This would not only help speed up transactions, but also give the badly coded/lazy/greedy pools a kick up the backside to sort their act out.

Sadly, they will just change from 0 tx blocks to 1 tx blocks (in addition to coinbase), where the single tx is not even from the mempool, but their own private spend that doesn't need checking for validity.

You can't force miners to add useful transactions. You can only provide incentives.
p3yot33at3r
Sr. Member
****
Offline Offline

Activity: 266
Merit: 250



View Profile
January 23, 2016, 10:17:33 PM
 #13854

any block that contains zero transactions be rejected by the network. This would not only help speed up transactions, but also give the badly coded/lazy/greedy pools a kick up the backside to sort their act out.

Sadly, they will just change from 0 tx blocks to 1 tx blocks (in addition to coinbase), where the single tx is not even from the mempool, but their own private spend that doesn't need checking for validity.

You can't force miners to add useful transactions. You can only provide incentives.

Then that also needs to be addressed. Blockes that contain tx's that aren't from the mempool should also be rejected. There is always a way..... Wink
smooth
Legendary
*
Offline Offline

Activity: 2338
Merit: 1140



View Profile
January 23, 2016, 10:56:51 PM
 #13855

any block that contains zero transactions be rejected by the network. This would not only help speed up transactions, but also give the badly coded/lazy/greedy pools a kick up the backside to sort their act out.

Sadly, they will just change from 0 tx blocks to 1 tx blocks (in addition to coinbase), where the single tx is not even from the mempool, but their own private spend that doesn't need checking for validity.

You can't force miners to add useful transactions. You can only provide incentives.

Then that also needs to be addressed. Blockes that contain tx's that aren't from the mempool should also be rejected. There is always a way..... Wink

There is no "the mempool"

Relativity means there can never be an objective mempool.

I don't think this is really a problem though. Transaction fees are precisely a bribe to a miner to include the transaction in the block. The mechanism exists, so use it.

2112
Legendary
*
Offline Offline

Activity: 2114
Merit: 1032



View Profile
January 24, 2016, 12:22:48 AM
 #13856

There is no "the mempool"

Relativity means there can never be an objective mempool.

I don't think this is really a problem though. Transaction fees are precisely a bribe to a miner to include the transaction in the block. The mechanism exists, so use it.
It would be relatively easy to approximate the existence of the global pending transaction list. I hate the term "mempool" because it is just an example of terminal in-box-thinking. "The mempool" is just a database stored in a really primitive way in memory, instead of some more advanced way like storing them in a https://en.wikipedia.org/wiki/In-memory_database .

The implementation would require folding the p2p-pool mining protocol into the main protocol where it would serve as a sort of proof-of-transmission that is resistant to the Sybil attacks. This has been discussed many times before.

Anyway, that isn't going to be implemented in Bitcoin for political reasons, not for any technical/scientific/economic reasons.


Please comment, critique, criticize or ridicule BIP 2112: https://bitcointalk.org/index.php?topic=54382.0
Long-term mining prognosis: https://bitcointalk.org/index.php?topic=91101.0
smooth
Legendary
*
Offline Offline

Activity: 2338
Merit: 1140



View Profile
January 24, 2016, 12:30:25 AM
 #13857

There is no "the mempool"

Relativity means there can never be an objective mempool.

I don't think this is really a problem though. Transaction fees are precisely a bribe to a miner to include the transaction in the block. The mechanism exists, so use it.
It would be relatively easy to approximate the existence of the global pending transaction list. I hate the term "mempool" because it is just an example of terminal in-box-thinking. "The mempool" is just a database stored in a really primitive way in memory, instead of some more advanced way like storing them in a https://en.wikipedia.org/wiki/In-memory_database .

The implementation would require folding the p2p-pool mining protocol into the main protocol where it would serve as a sort of proof-of-transmission that is resistant to the Sybil attacks. This has been discussed many times before.

Yes and every time it is discussed it is a dead end because in order to succeed it needs exactly the sort of consensus algorithm that proof-of-work implements. There is no such thing as "proof-of-transmission" as a consensus algorithm that is sybil resistant, at least none that has been shown.

2112
Legendary
*
Offline Offline

Activity: 2114
Merit: 1032



View Profile
January 24, 2016, 12:47:33 AM
Last edit: January 24, 2016, 12:59:04 AM by 2112
 #13858

Yes and every time it is discussed it is a dead end because in order to succeed it needs exactly the sort of consensus algorithm that proof-of-work implements. There is no such thing as "proof-of-transmission" as a consensus algorithm that is sybil resistant, at least none that has been shown.
P2P-pool works and is Sybil-resistant. Its faster and easier blocks serve as a very good approximation of global convergence to a single second-level slower and harder block.

The obstacles are purely non-technical. Many people find it profitable not to look for solutions. That's pretty much most of the story. Edit: the rest of the story is more like religious/theological argumentation in https://en.wikipedia.org/wiki/Eschatology .

Please comment, critique, criticize or ridicule BIP 2112: https://bitcointalk.org/index.php?topic=54382.0
Long-term mining prognosis: https://bitcointalk.org/index.php?topic=91101.0
smooth
Legendary
*
Offline Offline

Activity: 2338
Merit: 1140



View Profile
January 24, 2016, 01:12:20 AM
 #13859

Yes and every time it is discussed it is a dead end because in order to succeed it needs exactly the sort of consensus algorithm that proof-of-work implements. There is no such thing as "proof-of-transmission" as a consensus algorithm that is sybil resistant, at least none that has been shown.
P2P-pool works and is Sybil-resistant. Its faster and easier blocks serve as a very good approximation of global convergence to a single second-level slower and harder block.

P2pool doesn't really "work" because its cost is outsize with its benefits. I used p2pool when I used to mine so I'm well aware of both. You can't really justify using it unless you are trying to be altruistic.

scyth3
Sr. Member
****
Offline Offline

Activity: 495
Merit: 251


View Profile
January 24, 2016, 02:20:43 AM
 #13860

Can you imagine giving ASIC manufacturers the power to influence a PoW system?
Have you read the article ?

I have, and I agree with Guy. We should boycott Bitcoin Classic.
Pages: « 1 ... 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 [693] 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!