Bitcoin Forum
December 06, 2016, 04:26:32 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 [613] 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 ... 744 »
  Print  
Author Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool  (Read 2031631 times)
rav3n_pl
Legendary
*
Offline Offline

Activity: 1320


Don`t panic! Organize!


View Profile
February 28, 2015, 07:14:05 PM
 #12241

Wait, did I miss somewhere fact, that Forrestv abandoned project?

1Rav3nkMayCijuhzcYemMiPYsvcaiwHni  Bitcoin stuff on my OneDrive
My RPC CoinControl for any coin https://bitcointalk.org/index.php?topic=929954
My SatoshDice bot https://bitcointalk.org/index.php?topic=897685
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481041592
Hero Member
*
Offline Offline

Posts: 1481041592

View Profile Personal Message (Offline)

Ignore
1481041592
Reply with quote  #2

1481041592
Report to moderator
1481041592
Hero Member
*
Offline Offline

Posts: 1481041592

View Profile Personal Message (Offline)

Ignore
1481041592
Reply with quote  #2

1481041592
Report to moderator
rav3n_pl
Legendary
*
Offline Offline

Activity: 1320


Don`t panic! Organize!


View Profile
February 28, 2015, 07:16:10 PM
 #12242


Here is what I get from python command line, obviously not a pub key hash:

Code:
^??7?Jn?Kdѳ?D2?ه??2Vxk??)2?#÷M???Z?U)5&VfK?

Here is the script:

Code:
DONATION_SCRIPT = '4104ffd03de44a6e11b9917f3a29f9443283d9871c9d743ef30d5eddcd37094b64d1b3d8090496b53256786bf5c82932ec23c3b74d9f05a6f95a8b5529352656664bac'.decode('hex')

I believe the (intentional) complexities of this script are what causes blockchain.info to flag p2pool generation TXs as potential double spends...


Simple:
Code:
rav3n@bitrav3n:~$ bitcoin-cli decodescript '4104ffd03de44a6e11b9917f3a29f9443283d9871c9d743ef30d5eddcd37094b64d1b3d8090496b53256786bf5c82932ec23c3b74d9f05a6f95a8b5529352656664bac'
{
    "asm" : "04ffd03de44a6e11b9917f3a29f9443283d9871c9d743ef30d5eddcd37094b64d1b3d8090496b53256786bf5c82932ec23c3b74d9f05a6f95a8b5529352656664b OP_CHECKSIG",
    "reqSigs" : 1,
    "type" : "pubkey",
    "addresses" : [
        "1Kz5QaUPDtKrj5SqW5tFkn7WZh8LmQaQi4"
    ],
    "p2sh" : "3HW5FVVo3TpKD1rPpsHX2VeJNmfE4Lqe91"
}

1Rav3nkMayCijuhzcYemMiPYsvcaiwHni  Bitcoin stuff on my OneDrive
My RPC CoinControl for any coin https://bitcointalk.org/index.php?topic=929954
My SatoshDice bot https://bitcointalk.org/index.php?topic=897685
windpath
Legendary
*
Offline Offline

Activity: 938


View Profile WWW
February 28, 2015, 08:43:32 PM
 #12243

Wait, did I miss somewhere fact, that Forrestv abandoned project?

No, I don't believe he has.

This is an attempt to create an incentive for someone to come up with a solution to the scalability issues.

Perhaps if the pot got big enough Forrest would focus back on P2Pool, and I for one would be ecstatic if he figured it out and claimed the bounty.

I don't fault him at all for not being active, he is young and has other interests, P2Pool has represented an enormous contribution and I am grateful for all his work.

Since virtually no one I'm aware of pays the donation this could be an opportunity to create an incentive that gets work moving again.

We still need to define the criteria for success very clearly before we can start thinking about setting up a pot though...



Meuh6879
Legendary
*
Offline Offline

Activity: 1078



View Profile
March 01, 2015, 08:17:42 PM
 #12244

the problem of P2Pool is that you must have a dedicate PC to run bitcoin core server mode and P2Pool client (or server).
with the only ethernet autonomous miner bitcoin, the miners don't want a complex point-of-connexion to mine.

that's why new pool from manufactured miner device are a success.

P2Pool is good for an emergency system in my sense.
I trust and believe in P2Pool ... but i'm not the one that have 700TH/s in power  Grin


French ... but not so much   ---===---   P2P ... it's people at the end   ---===---   P2Pool (10,9 GH/s).
Comment miner des bitcoins ? Un tutoriel est là : https://bitcointalk.org/index.php?topic=1114415.0
Bitcoin change everything ... an explain of this fact : https://www.youtube.com/watch?v=joITmEr4SjY
K1773R
Legendary
*
Offline Offline

Activity: 1526


/dev/null


View Profile
March 02, 2015, 07:45:27 AM
 #12245

Wait, did I miss somewhere fact, that Forrestv abandoned project?

No, I don't believe he has.

This is an attempt to create an incentive for someone to come up with a solution to the scalability issues.

Perhaps if the pot got big enough Forrest would focus back on P2Pool, and I for one would be ecstatic if he figured it out and claimed the bounty.

I don't fault him at all for not being active, he is young and has other interests, P2Pool has represented an enormous contribution and I am grateful for all his work.

Since virtually no one I'm aware of pays the donation this could be an opportunity to create an incentive that gets work moving again.

We still need to define the criteria for success very clearly before we can start thinking about setting up a pot though...
ah, really?
https://bitcointalk.org/index.php?topic=329860.msg3537926#msg3537926
forrestv said he will take onto those problems... nothing more to say.

[GPG Public Key]  [Devcoin Builds]  [BBQCoin Builds]  [Multichain Blockexplorer]  [Multichain Blockexplorer - PoS Coins]  [Ufasoft Miner Linux Builds]
BTC/DVC/TRC/FRC: 1K1773RbXRZVRQSSXe9N6N2MUFERvrdu6y ANC/XPM AK1773RTmRKtvbKBCrUu95UQg5iegrqyeA NMC: NK1773Rzv8b4ugmCgX789PbjewA9fL9Dy1 LTC: LKi773RBuPepQH8E6Zb1ponoCvgbU7hHmd EMC: EK1773RxUes1HX1YAGMZ1xVYBBRUCqfDoF BQC: bK1773R1APJz4yTgRkmdKQhjhiMyQpJgfN
windpath
Legendary
*
Offline Offline

Activity: 938


View Profile WWW
March 02, 2015, 04:10:15 PM
 #12246

Wait, did I miss somewhere fact, that Forrestv abandoned project?

No, I don't believe he has.

This is an attempt to create an incentive for someone to come up with a solution to the scalability issues.

Perhaps if the pot got big enough Forrest would focus back on P2Pool, and I for one would be ecstatic if he figured it out and claimed the bounty.

I don't fault him at all for not being active, he is young and has other interests, P2Pool has represented an enormous contribution and I am grateful for all his work.

Since virtually no one I'm aware of pays the donation this could be an opportunity to create an incentive that gets work moving again.

We still need to define the criteria for success very clearly before we can start thinking about setting up a pot though...
ah, really?
https://bitcointalk.org/index.php?topic=329860.msg3537926#msg3537926
forrestv said he will take onto those problems... nothing more to say.

Yes, unfortunately he took the 2k from the Litecoin devs in November 2013 and has not yet come up with a solution...

windpath
Legendary
*
Offline Offline

Activity: 938


View Profile WWW
March 02, 2015, 04:19:17 PM
 #12247

I know a bunch of us have nodes in the northeast US...

Anyone planning on attending the MIT Bitcoin Expo this coming weekend?

I'll be there and would love to meet some of you folks face to face (perhaps over a cocktail or 3) Smiley

http://mitbitcoinexpo.org/

Tix are $175 for non students, impressive lineup of speakers...

TheAnalogKid
Sr. Member
****
Offline Offline

Activity: 266


View Profile
March 02, 2015, 06:49:59 PM
 #12248

So, here's an oddball suggestion to re-think P2Pool.

Does the mining itself really have to be distributed?  What if we all "solo-mined", but then pooled together the solved block income and then just distributed the income amongst all miners recorded as having done work?

It would be a centralized, de-centralized pool.  Follow me on this...

First, why re-invent the wheel and try to rewrite the P2Pool code?  We know the inherent issues with it and it seems that most agree it is a daunting, if insurmountable, task given the time required to do so and the lack of the most important thing - money - to provide the incentive.

It would seem to me to be a much better use of resources to find things that could be leveraged together that already exist, and just contract those to write the needed subsequent "glue" bits to make it all work.

I've been mining on Nastypool, with the NastyPoP payout method, and this is what gave me the idea.

Why not use the CKpool/CKDB solo method, and have everyone currently running a P2Pool node setup their own CKPool solo nodes.  Miners connect to them and it would be pretty much normal solo mining, without the issues of ever increasing share difficulty.  Latency would be no longer an issue, because you're not racing each other and the other nodes to get your shares in the chain faster, you could mine wherever and have more of your work count, instead of being DOA.

Then, at the top level, here's the code that would need to be implemented - the ability to catalog and share the information about each miner on each node, the amount of work they're doing, and finally the blocks that are solved.

From that info, you could run periodic payouts for all miners (maybe weekly, every 3 or 5 days, whatever) based upon all the pooled BTC from all the blocks and transactions solved during that period.

You could implement a 3 of 5 majority (5 of 7, whatever of whatever), where trusted stakeholders (windpath, CK/Kano, etc) run the major nodes which form a distributed cluster of the main information store.  You could also have one entity hold the "hot" wallet containing that rounds' BTC, and payout the distributions. 

The resources for pool nodes and onwers would be less, since you'd probably need to only replicate database transactions now, instead of full sharechains, etc.
The CKpool code is written in C/C++ and is performant and scalable, something which P2Pool will never be.

If the theory of luck and variance holds true, where over time an amount of hashrate will still solve the same amount of blocks, it shouldn't matter whether you're solo mining with 200GH/s, or 200TH/s, over time you'll still get the same payout.  Even if your miner never solved a block on your own solo node, you'd still get equal payouts from the nodes who did solve them.

If you leave the 0.9% (or even round it up to 1.0%) fee in there like CK/Kano have for their pool, it allows money to flow back to the developers who are spending their time writing and maintaining this.  If you do round it up to 1.0%, maybe that 0.1% could be re-distributed to those running a pool node, as a thank you for the services.  As much as I like 0 fee, it really doesn't draw people in anymore - I see pools with 4% fees running with miners on them, because they offer a gamble at something.

I don't know, just tossing the idea out there.  Might be completely stupid and unfeasible, but honestly at this point I think P2Pool's days are numbered without finding a solution, and it'll probably have to be pretty radical for it to work.


Gws24
Sr. Member
****
Offline Offline

Activity: 465


View Profile
March 02, 2015, 07:19:27 PM
 #12249

Quote
You could implement a 3 of 5 majority (5 of 7, whatever of whatever), where trusted stakeholders (windpath, CK/Kano, etc) run the major nodes which form a distributed cluster of the main information store.  You could also have one entity hold the "hot" wallet containing that rounds' BTC, and payout the distributions.

And that is centralization and imho unwanted.

TheAnalogKid
Sr. Member
****
Offline Offline

Activity: 266


View Profile
March 02, 2015, 08:16:56 PM
 #12250

Quote
You could implement a 3 of 5 majority (5 of 7, whatever of whatever), where trusted stakeholders (windpath, CK/Kano, etc) run the major nodes which form a distributed cluster of the main information store.  You could also have one entity hold the "hot" wallet containing that rounds' BTC, and payout the distributions.

And that is centralization and imho unwanted.
Then build the code so that every node keeps that information store, instead of just 3 or however many, and then it's not centralized.  99% of the nodes could then drop off and as long as one is running you're still good.

The biggest hurdle is the "caretaker" of the wallet holding the BTC during the current "round", or don't have the concept of a round, and continue to use immediate PPLNS payouts to worker addresses.  Then you're also not centralized there either.

yslyung
Legendary
*
Offline Offline

Activity: 1050


Mine Mine Mine


View Profile
March 02, 2015, 08:49:13 PM
 #12251

p2pool is 0 fees & it does sounds centralised
windpath
Legendary
*
Offline Offline

Activity: 938


View Profile WWW
March 02, 2015, 09:01:53 PM
 #12252

I've been thinking about this for a while with decentralized and trust-less at the top of my list.

I think a solution based on serial micro-payments (or similar) makes more sense and will protect the trust-less decentralized nature of P2Pool.

Today I saw this video, it's "Lecture 3 - Mechanics of Bitcoin" from the Princeton University course, the link starts at 34:30 where he starts to talk about serial micro-payments.

His example is for by the minute telephone billing, it's not the actual solution for P2Pool, but pretty close (I hope)

If you watch, in his example, replace Alice with P2Pool and Bob with a miner...

https://www.youtube.com/watch?v=t3hJsFpPmXs&feature=youtu.be&t=34m30s

I guess my first question is can anyone tell me why something like this would not work?



TheAnalogKid
Sr. Member
****
Offline Offline

Activity: 266


View Profile
March 02, 2015, 09:36:22 PM
 #12253

I guess my first question is can anyone tell me why something like this would not work?
Not sure how micropayments are connected to the core problems of P2Pool being the performance/scalability and the relativity of higher hashrate to larger share diffs.

Unless it's in reference to what was said before, the ability to "credit" smaller miners for work they have completed which may have fallen off the chain because there's been no block in more than 3 days.

Chupacabras
Member
**
Offline Offline

Activity: 108


View Profile WWW
March 02, 2015, 11:28:40 PM
 #12254

I've been thinking about this for a while with decentralized and trust-less at the top of my list.

I think a solution based on serial micro-payments (or similar) makes more sense and will protect the trust-less decentralized nature of P2Pool.

Today I saw this video, it's "Lecture 3 - Mechanics of Bitcoin" from the Princeton University course, the link starts at 34:30 where he starts to talk about serial micro-payments.

His example is for by the minute telephone billing, it's not the actual solution for P2Pool, but pretty close (I hope)

If you watch, in his example, replace Alice with P2Pool and Bob with a miner...

https://www.youtube.com/watch?v=t3hJsFpPmXs&feature=youtu.be&t=34m30s

I guess my first question is can anyone tell me why something like this would not work?



Good info. Thanks.

LXC: DFfLxDJfbqXyVNsTeWuARGPfQ2YKRE6y1a
BTC: 1N3misAgyCTW7b5BQojoLx7p9ok39e52UV
Life is like a box of chocolate. Famous Runner Forrest Gump
kano
Legendary
*
Offline Offline

Activity: 1918


Linux since 1997 RedHat 4


View Profile
March 03, 2015, 12:17:41 AM
 #12255

I guess my first question is can anyone tell me why something like this would not work?
Not sure how micropayments are connected to the core problems of P2Pool being the performance/scalability and the relativity of higher hashrate to larger share diffs.

Unless it's in reference to what was said before, the ability to "credit" smaller miners for work they have completed which may have fallen off the chain because there's been no block in more than 3 days.
Both are unrelated to a solution.

P2pool already does effectively do micropayments, though there is an issue with that already in that a small miner will get lots of tiny payouts that will then require more in transaction fee to spend them than the amount of the payouts ...

As for falling off the end of the chain, well that's a two fold issue.
Firstly, if you want to have a higher % of paid shares, you simply increase the size of the chain.
However, at the moment, the % of paid shares is already so high, I'd not understand why anyone would want to increase that ... due to the problem of:
The larger the chain, the larger the block coinbase transaction will be and the smaller the average size of the 'micropayments'

Edit: and just to throw an issue into the basket that same may not notice (but I consider obvious Tongue)
The bitcoin developers are effectively against p2pool since they are against micropayments.
They make comments about small transactions and large fees compared to those small transactions and how small transaction are SPAM (yeah there's a very vocal moron on the subject of SPAM)
If you watch the bitcoin debug.log of the standard bitcoind (not the abortion that moron hides changes in) you will see it spitting out comments about dust transactions and ignoring them all the time ...
Any design of p2pool that supports smaller miners or smaller payouts is directly in contrast with that unless there is some separate store of the smaller shares/payouts to be 'banked' and then paid out once they exceed some consensual limit.
The 'banking' is the issue, since the current design uses the coinbase txn as the distributed bank proof - but you can't go throwing the unpaid part of the bank in there ...

Edit2: and then to add in some possibly useful information Smiley
If you look at how a normal pool works, you see related hints on how to solve some of the problems.
An example would be large vs small miners.
A normal (good) pool adjusts the share rate to be X shares per minute based on the miner rate.
Maybe p2pool could consider some (more complex) version of that in the share chain to force miners to use a diff related to their hash rate and thus allow smaller miners to reduce their variance.
Of course it has the problem of abuse by larger miners splitting up their 'farm' to multiple addresses and thus acting like multiple smaller miners - so that would have to be resolved some way I've got no idea how Smiley

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
windpath
Legendary
*
Offline Offline

Activity: 938


View Profile WWW
March 03, 2015, 02:43:38 AM
 #12256

The bitcoin developers are effectively against p2pool since they are against micropayments.

Yes, I'm cherry picking the quote to respond to, and the rest I will get back with you on later, but this statement simply is not fair or true.

The smallest paid share in the p2pool share chain is currently (right now) 0.00108623 BTC ($0.27).

This hardly represents what most would consider a micro-payment, its over a quarter USD (not a couple pennies, or fractions there of).

Here is an (older) quote from a dev:

Quote
“I think P2Pool makes mining fun again.” -gmaxwell, Bitcoin Core Developer

And I would agree, it does.

TL;DR: Core dev's have nothing against, and in fact support decentralization and trust-less mining pools...

And my thought, is that serial micro-payments will actually reduce smaller payouts....

Lets say the smallest miner on the pool should be able to earn a single bit per block (0.00000100, 100 Satoshi))

The way I see them working:

Let say a miner starts on the pool with 1 TH/s.

Lets further assume that the payout is around .001 BTC per block found (for the sake of argument).

This miner opts-in to the serial micro-payment structure by setting up his multi-sig, a 2 of 2, 1 key signed by the pool on block generation, and 1 signed by him to spend.

If the miner does not spend the previous payouts they are included in the next block the pool finds, along with the .001 from the current block, effectively now a .002 payout (creating a potential double spend of an unspent multi-sig tx).

However since the first found blocks coins never got the second sig, the coins are not spent and are still available in a trust-less way.

This miner goes on to have a payout of .001 per block found, without ever signing the 2nd key for the payout, that only the miner has, and the payouts accrue over time, lets say for 10 blocks...

On the 10th block found the miner decides that .01 (10*.001) is enough to justify a payout and signs the 10th round of the .001 payout block transactions (that accrue), resulting in a payout of .01 (instead of 10 payouts of .001) to the address they specified when they set up the multi-sig and the accrued txs are all signed at once reducing tx fees.

This is grossly simplified, and I'm still wrapping my head around how to explain it, but I feel like I'm onto something.

If anyone gets it and thinks it might work, or has other holes to poke please do....


Edit: watch the video to get a feel for how serial multi-sig works:
Quote
If you watch, in his example, replace Alice with P2Pool and Bob with a miner...

https://www.youtube.com/watch?v=t3hJsFpPmXs&feature=youtu.be&t=34m30s


norgan
Sr. Member
****
Offline Offline

Activity: 308

Decentralize your hashing - p2pool - Norgz Pool


View Profile WWW
March 03, 2015, 03:52:11 AM
 #12257

ok I'm having a brainfart or something has changed in the config.

installed bitcoind 0.10.0 with existing bitcoin.conf from 0.9. Ran p2pool and get 401 authorization required.

Code:
C:\p2pool\run_p2pool.py -a 1MinerGcfwXJW6BETKLPQTmKYomc1uGAXy --bitcoind-config-path C:\D Drive\Bitcoin\bitcoin.conf -n 59.167.237.19:9333 -n 115.70.176.17:9333 -n 203.219.14.204:9333 --max-conns 30 --give-author 0 --iocp --irc-announce
pause

Do we have to specify the password now or something?
 

Miner, tech geek, operator of NorgzPool - Sydney Australia P2Pool Node creator of p2pool fancy front end

Tips: 1NorganBbymShTN2MMpfGzRYJF8mcPeXjv Exchange BTC locally in Australia or Donate to p2pool miners
-ck
Moderator
Legendary
*
Offline Offline

Activity: 1988


Ruu \o/


View Profile WWW
March 03, 2015, 03:57:17 AM
 #12258

installed bitcoind 0.10.0 with existing bitcoin.conf from 0.9
rpcallowip format changed

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
norgan
Sr. Member
****
Offline Offline

Activity: 308

Decentralize your hashing - p2pool - Norgz Pool


View Profile WWW
March 03, 2015, 04:14:04 AM
 #12259

installed bitcoind 0.10.0 with existing bitcoin.conf from 0.9
rpcallowip format changed
Ah! I thought I was going crazy. Do you recall off hand what the syntax is?

Edit: I wasn't using rpcallow before. Is it required now??
Code:
server=1
daemon=1
rpcuser=bitcoinrpc
rpcpassword=**************
blockprioritysize=0
blockmaxsize = 500000
mintxfee = 0.0001
minrelaytxfee = 0.0001
maxconnections=20
disablewallet=1

added: rpcallowip=::/0

and still getting 401.

Miner, tech geek, operator of NorgzPool - Sydney Australia P2Pool Node creator of p2pool fancy front end

Tips: 1NorganBbymShTN2MMpfGzRYJF8mcPeXjv Exchange BTC locally in Australia or Donate to p2pool miners
xyzzy099
Legendary
*
Offline Offline

Activity: 939



View Profile
March 03, 2015, 04:28:55 AM
 #12260

installed bitcoind 0.10.0 with existing bitcoin.conf from 0.9
rpcallowip format changed
Ah! I thought I was going crazy. Do you recall off hand what the syntax is?

If you were using something like 'rpcallowip=192.168.1.*' before, change it to 'rpcallowip=192.168.1.0/24' (or equivalent that suits your local network).

Libertarians:  Diligently plotting to take over the world and leave you alone.
Pages: « 1 ... 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 [613] 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 ... 744 »
  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!