Bitcoin Forum
December 04, 2016, 02:12:39 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 [186] 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 ... 744 »
  Print  
Author Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool  (Read 2029255 times)
Smoovious
Hero Member
*****
Offline Offline

Activity: 504

Scattering my bits around the net since 1980


View Profile
October 31, 2012, 11:49:22 PM
 #3701

And anyone (everyone?) with an ASIC, having invested hundreds of dollars, will be a "serious miner" in my eyes...
Some people, such as myself, can't really afford the high bandwidth usage of running a node. That's the main reason I switched pools.
Well... a while ago, pyramining briefly switched over to my public node while they were working on some stuff.

I ended up having between 200-400GH/s at the time, and everything seemed to go just fine with my bandwidth, so p2pmining should be ok with the added bandwidth of the ASIC traffic.

If p2pmining would let you use higher diff shares, or maybe they can set up a high-hash node too. They're pretty much doing their own sub-share-chain, so maybe they will do something to accommodate the ASICs.

Not sure if they would tho. It sounded like they came into existence mainly to cater to the smaller miner who needed lower-diff shares.

-- Smoov

ps: Krak is in one of the outlying cities/towns that don't have a lot of infastructure to spread around. Rural-ish kind of area. That's where his main bandwidth bottleneck is. They get priced accordingly. Too much demand, not enough supply. So they get capped more. Sad
1480817559
Hero Member
*
Offline Offline

Posts: 1480817559

View Profile Personal Message (Offline)

Ignore
1480817559
Reply with quote  #2

1480817559
Report to moderator
1480817559
Hero Member
*
Offline Offline

Posts: 1480817559

View Profile Personal Message (Offline)

Ignore
1480817559
Reply with quote  #2

1480817559
Report to moderator
1480817559
Hero Member
*
Offline Offline

Posts: 1480817559

View Profile Personal Message (Offline)

Ignore
1480817559
Reply with quote  #2

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

Posts: 1480817559

View Profile Personal Message (Offline)

Ignore
1480817559
Reply with quote  #2

1480817559
Report to moderator
1480817559
Hero Member
*
Offline Offline

Posts: 1480817559

View Profile Personal Message (Offline)

Ignore
1480817559
Reply with quote  #2

1480817559
Report to moderator
organofcorti
Donator
Legendary
*
Offline Offline

Activity: 1946


Poor impulse control.


View Profile WWW
October 31, 2012, 11:52:24 PM
 #3702

I don't think ASICs will need any special support. P2Pool can provide getwork results fast enough for hundreds of GH/s (from a normal computer) and could be optimized for more. In addition, any timestamp rolling multiplies that.
What about mining on a remote node? It seems like ASICs could kill P2P Mining.

Any serious P2Pool user, one serious enough to have ASICs, should definitely have their own P2Pool node...

As Con writes, soon the only profitable miners with be ASIC based. The proportion of the network hashrate of an ASIC will be significantly lower than it would be now since the overall network hashrate will have increased significantly. Will ASICS still be a problem for p2Pool in this case?

Bitcoin network and pool analysis 12QxPHEuxDrs7mCyGSx1iVSozTwtquDB3r
follow @oocBlog for new post notifications
btharper
Sr. Member
****
Offline Offline

Activity: 389



View Profile
October 31, 2012, 11:55:28 PM
 #3703

And anyone (everyone?) with an ASIC, having invested hundreds of dollars, will be a "serious miner" in my eyes...
Some people, such as myself, can't really afford the high bandwidth usage of running a node. That's the main reason I switched pools.

Really? P2Pool uses ~3 GB/month, normally. How much is too much for you?

With a normal pool, one getwork response/submit takes about 800 bytes of data, plus some HTTP stuff, so about 1KB for every 4 GH (2^32). At 1 GH/s, over a month, that's 650 MB (1 * (24*60*60*30) * (1000/4) / 1e6). It's probably a bit higher than that due to miners requesting more work than they need. In addition, that number scales linearly with the amount of hashing power you have, so with 3 GH/s, you're on par with P2Pool's bandwidth usage.

If I'd heard more complaints about bandwidth, I could have added an option to decrease the number of peers. Bandwidth usage is proportional to the number of peers you have, and 5 is probably enough, so you could halve the usage easily.
How hard would it be to implement GBT for pyraminingP2Pool? Seems like that would mitigate a few issues for remote miners anyway.

While I'm asking, is the P2Pool codebase setup for the block reward halving already? (I'd imagine so, but it gets messy otherwise).

Edit: Pyramining is already setup how they want to and will probably continue in the same. GBT support for p2pool was what I meant to ask about.
kano
Legendary
*
Online Online

Activity: 1918


Linux since 1997 RedHat 4


View Profile
October 31, 2012, 11:58:42 PM
 #3704

Any serious P2Pool user, one serious enough to have ASICs, should definitely have their own P2Pool node...
...With ASICs being 50x more efficient, the only people mining in the future, bar a very few exceptions, will all be running ASICs.

And anyone (everyone?) with an ASIC, having invested hundreds of dollars, will be a "serious miner" in my eyes...
Even the people buying coffee warmers for $150 are serious miners?

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
kano
Legendary
*
Online Online

Activity: 1918


Linux since 1997 RedHat 4


View Profile
November 01, 2012, 12:00:33 AM
 #3705

And anyone (everyone?) with an ASIC, having invested hundreds of dollars, will be a "serious miner" in my eyes...
Some people, such as myself, can't really afford the high bandwidth usage of running a node. That's the main reason I switched pools.

Really? P2Pool uses ~3 GB/month, normally. How much is too much for you?

With a normal pool, one getwork response/submit takes about 800 bytes of data, plus some HTTP stuff, so about 1KB for every 4 GH (2^32). At 1 GH/s, over a month, that's 650 MB (1 * (24*60*60*30) * (1000/4) / 1e6). It's probably a bit higher than that due to miners requesting more work than they need. In addition, that number scales linearly with the amount of hashing power you have, so with 3 GH/s, you're on par with P2Pool's bandwidth usage.

If I'd heard more complaints about bandwidth, I could have added an option to decrease the number of peers. Bandwidth usage is proportional to the number of peers you have, and 5 is probably enough, so you could halve the usage easily.
How hard would it be to implement GBT for pyramining? Seems like that would mitigate a few issues for remote miners anyway.

While I'm asking, is the P2Pool codebase setup for the block reward halving already? (I'd imagine so, but it gets messy otherwise)
Depending on the number of outstanding transactions and what transactions AREN'T being ignored, it is possible for GBT to use more bandwidth than GetWork ...

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
sharky112065
Sr. Member
****
Offline Offline

Activity: 383



View Profile
November 01, 2012, 12:19:34 AM
 #3706

I don't think ASICs will need any special support. P2Pool can provide getwork results fast enough for hundreds of GH/s (from a normal computer) and could be optimized for more. In addition, any timestamp rolling multiplies that.
What about mining on a remote node? It seems like ASICs could kill P2P Mining.

Any serious P2Pool user, one serious enough to have ASICs, should definitely have their own P2Pool node...

Because of course no one uses a remote p2pool node for a failover backup. /sarcasm

Sounds like no real testing has been done to verify it will not be an issue.

I'm starting to get the feeling that you are sticking your  head in the sand and hoping that everything will just work.

Donations welcome: 12KaKtrK52iQjPdtsJq7fJ7smC32tXWbWr
btharper
Sr. Member
****
Offline Offline

Activity: 389



View Profile
November 01, 2012, 12:20:53 AM
 #3707

And anyone (everyone?) with an ASIC, having invested hundreds of dollars, will be a "serious miner" in my eyes...
Some people, such as myself, can't really afford the high bandwidth usage of running a node. That's the main reason I switched pools.

Really? P2Pool uses ~3 GB/month, normally. How much is too much for you?

With a normal pool, one getwork response/submit takes about 800 bytes of data, plus some HTTP stuff, so about 1KB for every 4 GH (2^32). At 1 GH/s, over a month, that's 650 MB (1 * (24*60*60*30) * (1000/4) / 1e6). It's probably a bit higher than that due to miners requesting more work than they need. In addition, that number scales linearly with the amount of hashing power you have, so with 3 GH/s, you're on par with P2Pool's bandwidth usage.

If I'd heard more complaints about bandwidth, I could have added an option to decrease the number of peers. Bandwidth usage is proportional to the number of peers you have, and 5 is probably enough, so you could halve the usage easily.
How hard would it be to implement GBT for pyramining? Seems like that would mitigate a few issues for remote miners anyway.

While I'm asking, is the P2Pool codebase setup for the block reward halving already? (I'd imagine so, but it gets messy otherwise)
Depending on the number of outstanding transactions and what transactions AREN'T being ignored, it is possible for GBT to use more bandwidth than GetWork ...
Whoops, I misspoke, corrected the original post. I meant to ask how hard it would be to setup support for GBT (or stratum, or anything else) in p2pool, as this would be one way to improve remote mining.
lenny_
Legendary
*
Offline Offline

Activity: 953



View Profile
November 01, 2012, 12:21:55 AM
 #3708

Anyone running Ztex USB-FPGA on p2pool for long time? Can you please post your stats, efficiency, and stales (orphans/DOA)?
forrestv
Hero Member
*****
Offline Offline

Activity: 510


View Profile
November 01, 2012, 12:29:20 AM
 #3709

Because of course no one uses a remote p2pool node for a failover backup. /sarcasm

Sounds like no real testing has been done to verify it will not be an issue.

I'm starting to get the feeling that you are sticking your  head in the sand and hoping that everything will just work.

It's kind of hard to test with something that you're not even sure exists... Tongue

Anyway, with sane nTime rolling and adaptive pseudoshare targets, getworks can provide more than enough work to remote hosts with very low bandwidth. Everything for nTime rolling is already there (the HTTP header), and adaptive targets are disabled temporarily, but I'll re-enable them for the next release.

How hard would it be to implement GBT for pyraminingP2Pool? Seems like that would mitigate a few issues for remote miners anyway.

While I'm asking, is the P2Pool codebase setup for the block reward halving already? (I'd imagine so, but it gets messy otherwise).

Edit: Pyramining is already setup how they want to and will probably continue in the same. GBT support for p2pool was what I meant to ask about.

I really don't see any issue with getwork. Why is GBT necessary?

P2Pool can handle reward halving.

EDIT: Getwork does have some problems with timestamp rolling. Depending on how ASIC miners handle it, it could work, but I'll start working on GBT support to allow timestamp rolling.

1J1zegkNSbwX4smvTdoHSanUfwvXFeuV23
btharper
Sr. Member
****
Offline Offline

Activity: 389



View Profile
November 01, 2012, 12:41:49 AM
 #3710

I don't think ASICs will need any special support. P2Pool can provide getwork results fast enough for hundreds of GH/s (from a normal computer) and could be optimized for more. In addition, any timestamp rolling multiplies that.
What about mining on a remote node? It seems like ASICs could kill P2P Mining.

Any serious P2Pool user, one serious enough to have ASICs, should definitely have their own P2Pool node...

Because of course no one uses a remote p2pool node for a failover backup. /sarcasm

Sounds like no real testing has been done to verify it will not be an issue.

I'm starting to get the feeling that you are sticking your  head in the sand and hoping that everything will just work.

Well... a while ago, pyramining briefly switched over to my public node while they were working on some stuff.

I ended up having between 200-400GH/s at the time, and everything seemed to go just fine with my bandwidth, so p2pmining should be ok with the added bandwidth of the ASIC traffic.

If p2pmining would let you use higher diff shares, or maybe they can set up a high-hash node too. They're pretty much doing their own sub-share-chain, so maybe they will do something to accommodate the ASICs.

Not sure if they would tho. It sounded like they came into existence mainly to cater to the smaller miner who needed lower-diff shares.

-- Smoov

ps: Krak is in one of the outlying cities/towns that don't have a lot of infastructure to spread around. Rural-ish kind of area. That's where his main bandwidth bottleneck is. They get priced accordingly. Too much demand, not enough supply. So they get capped more. Sad

For a quick answer. But the longer answer is still that getwork is anticipated not to work as well with ASICs. Hence the several new implementations out there to address this GBT and Stratum are the main two that I've seen.
btharper
Sr. Member
****
Offline Offline

Activity: 389



View Profile
November 01, 2012, 12:47:34 AM
 #3711

It's kind of hard to test with something that you're not even sure exists... Tongue

Anyway, with sane nTime rolling and adaptive pseudoshare targets, getworks can provide more than enough work to remote hosts with very low bandwidth. Everything for nTime rolling is already there (the HTTP header), and adaptive targets are disabled temporarily, but I'll re-enable them for the next release.

How hard would it be to implement GBT for pyraminingP2Pool? Seems like that would mitigate a few issues for remote miners anyway.

While I'm asking, is the P2Pool codebase setup for the block reward halving already? (I'd imagine so, but it gets messy otherwise).

Edit: Pyramining is already setup how they want to and will probably continue in the same. GBT support for p2pool was what I meant to ask about.

I really don't see any issue with getwork. Why is GBT necessary?

P2Pool can handle reward halving.

EDIT: Getwork does have some problems with timestamp rolling. Depending on how ASIC miners handle it, it could work, but I'll start working on GBT support to allow timestamp rolling.
The main problem I see coming is that even the slowest announced ASIC (BFL's Jalapeno) can go faster than one getwork per second. Most devices are a lot faster. Pulling the work away from the pools and closer to the actual device is a decent looking way to deal with that. I'm not aware of any huge issues with timestamp rolling as long as they can get enough getwork blocks, especially after a longpoll when they need more new pieces of work to start working on the new block (small surges of getworks every 10 seconds when a block comes out seems excessive).
forrestv
Hero Member
*****
Offline Offline

Activity: 510


View Profile
November 01, 2012, 01:07:26 AM
 #3712

The main problem I see coming is that even the slowest announced ASIC (BFL's Jalapeno) can go faster than one getwork per second. Most devices are a lot faster. Pulling the work away from the pools and closer to the actual device is a decent looking way to deal with that. I'm not aware of any huge issues with timestamp rolling as long as they can get enough getwork blocks, especially after a longpoll when they need more new pieces of work to start working on the new block (small surges of getworks every 10 seconds when a block comes out seems excessive).

On my desktop, P2Pool can supply ~130 getworks/second, or enough work for 520 GH/s (130/s * 4 GH), without any timestamp rolling. With timestamp rolling one minute backwards and forwards, it can supply 62 TH/s (520 GH/s * 120) of work, or 480 GH/s (1/s * 4 GH * 120) of work at a rate of one getwork per second.

I don't think ASICs will need any special support. P2Pool can provide getwork results fast enough for hundreds of GH/s (from a normal computer) and could be optimized for more. In addition, any timestamp rolling multiplies that.
What about mining on a remote node? It seems like ASICs could kill P2P Mining.
The earlier argument (^) about remote miners not working was a bit of a farce, as shown by the above numbers.

The thing to focus on in order to make sure things work is the timestamp rolling support in ASIC mining software. We need to ensure that it can roll ahead of the current time (and potentially backwards, though that would require an extension to getwork).

I looked at GBT, and I don't see it improving anything. It requires sending the entire block template (potentially up to 1 MB) to miners every 10 seconds, which is definitely impractical for remote miners. An extension to GBT that allowed only sending the merkle root would avoid this, though.

1J1zegkNSbwX4smvTdoHSanUfwvXFeuV23
-ck
Moderator
Legendary
*
Offline Offline

Activity: 1988


Ruu \o/


View Profile WWW
November 01, 2012, 01:27:45 AM
 #3713

I looked at GBT, and I don't see it improving anything. It requires sending the entire block template (potentially up to 1 MB) to miners every 10 seconds, which is definitely impractical for remote miners. An extension to GBT that allowed only sending the merkle root would avoid this, though.
Yes we're debating that very point at length in the GBT thread at the moment, as I do not see the advantage of that either, only potential disadvantage of increasing network bandwidth, or worse, encouraging not perpetuating transactions. Stratum on the other hand uses merkle branches to negate this effect entirely and the bandwidth is virtually static regardless of the miner's hashrate or transaction count.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
Luke-Jr
Legendary
*
Offline Offline

Activity: 2086



View Profile
November 01, 2012, 01:44:15 AM
 #3714

It requires sending the entire block template (potentially up to 1 MB) to miners every 10 seconds, which is definitely impractical for remote miners. An extension to GBT that allowed only sending the merkle root would avoid this, though.
Sending only the merkle root, whether it be via getwork, Stratum, or some new GBT extension, makes the pool centralized, and kinda defeats the entire point of p2pool... Perhaps it would make sense for "remote" p2pool servers to be the first to move forward with mandatory-miner-provides-the-transactions GBT?

btharper
Sr. Member
****
Offline Offline

Activity: 389



View Profile
November 01, 2012, 04:15:19 AM
 #3715

The main problem I see coming is that even the slowest announced ASIC (BFL's Jalapeno) can go faster than one getwork per second. Most devices are a lot faster. Pulling the work away from the pools and closer to the actual device is a decent looking way to deal with that. I'm not aware of any huge issues with timestamp rolling as long as they can get enough getwork blocks, especially after a longpoll when they need more new pieces of work to start working on the new block (small surges of getworks every 10 seconds when a block comes out seems excessive).

On my desktop, P2Pool can supply ~130 getworks/second, or enough work for 520 GH/s (130/s * 4 GH), without any timestamp rolling. With timestamp rolling one minute backwards and forwards, it can supply 62 TH/s (520 GH/s * 120) of work, or 480 GH/s (1/s * 4 GH * 120) of work at a rate of one getwork per second.

I don't think ASICs will need any special support. P2Pool can provide getwork results fast enough for hundreds of GH/s (from a normal computer) and could be optimized for more. In addition, any timestamp rolling multiplies that.
What about mining on a remote node? It seems like ASICs could kill P2P Mining.
The earlier argument (^) about remote miners not working was a bit of a farce, as shown by the above numbers.

The thing to focus on in order to make sure things work is the timestamp rolling support in ASIC mining software. We need to ensure that it can roll ahead of the current time (and potentially backwards, though that would require an extension to getwork).

I looked at GBT, and I don't see it improving anything. It requires sending the entire block template (potentially up to 1 MB) to miners every 10 seconds, which is definitely impractical for remote miners. An extension to GBT that allowed only sending the merkle root would avoid this, though.
Then this may be less of an issue than I expected. I'd imagine it depends some on the hardware it's being run on, though I have no idea what you're running your node off of.

It may be easy enough to just give out work that has a 1 minute old timestamp and just allow 2 minutes of rolltime.
kano
Legendary
*
Online Online

Activity: 1918


Linux since 1997 RedHat 4


View Profile
November 01, 2012, 11:43:28 AM
 #3716

The main problem I see coming is that even the slowest announced ASIC (BFL's Jalapeno) can go faster than one getwork per second. Most devices are a lot faster. Pulling the work away from the pools and closer to the actual device is a decent looking way to deal with that. I'm not aware of any huge issues with timestamp rolling as long as they can get enough getwork blocks, especially after a longpoll when they need more new pieces of work to start working on the new block (small surges of getworks every 10 seconds when a block comes out seems excessive).

On my desktop, P2Pool can supply ~130 getworks/second, or enough work for 520 GH/s (130/s * 4 GH), without any timestamp rolling. With timestamp rolling one minute backwards and forwards, it can supply 62 TH/s (520 GH/s * 120) of work, or 480 GH/s (1/s * 4 GH * 120) of work at a rate of one getwork per second.

I don't think ASICs will need any special support. P2Pool can provide getwork results fast enough for hundreds of GH/s (from a normal computer) and could be optimized for more. In addition, any timestamp rolling multiplies that.
What about mining on a remote node? It seems like ASICs could kill P2P Mining.
The earlier argument (^) about remote miners not working was a bit of a farce, as shown by the above numbers.

The thing to focus on in order to make sure things work is the timestamp rolling support in ASIC mining software. We need to ensure that it can roll ahead of the current time (and potentially backwards, though that would require an extension to getwork).
...
Sorry - I don't get the point of this comment.
Why do you need rolling the time?

Unless I've completely missed your point, you don't need to roll the time with Stratum or GBT, you roll a value in the coinbase instead, named (IMO badly) the secondary nonce instead of screwing with the block timestamp (which is a hack) unnecessary

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
kano
Legendary
*
Online Online

Activity: 1918


Linux since 1997 RedHat 4


View Profile
November 01, 2012, 11:52:38 AM
 #3717

It requires sending the entire block template (potentially up to 1 MB) to miners every 10 seconds, which is definitely impractical for remote miners. An extension to GBT that allowed only sending the merkle root would avoid this, though.
Sending only the merkle root, whether it be via getwork, Stratum, or some new GBT extension, makes the pool centralized, and kinda defeats the entire point of p2pool... Perhaps it would make sense for "remote" p2pool servers to be the first to move forward with mandatory-miner-provides-the-transactions GBT?
If the protocol (Stratum) has the option to request the transaction list - as you already know - then why are you making this statement?
Are you arguing that GBT isn't centralised because you HAVE to receive the full transaction list?
That optionally receiving it isn't good enough? Seriously?

Yeah forrestv it seems that you need to take his hidden agenda comments with a grain of salt.
His agenda is to promote GBT no matter what problems there are with it, and to use dictionary arguments to avoid transparency.

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
forrestv
Hero Member
*****
Offline Offline

Activity: 510


View Profile
November 01, 2012, 01:25:56 PM
 #3718

The earlier argument (^) about remote miners not working was a bit of a farce, as shown by the above numbers.

The thing to focus on in order to make sure things work is the timestamp rolling support in ASIC mining software. We need to ensure that it can roll ahead of the current time (and potentially backwards, though that would require an extension to getwork).
...
Sorry - I don't get the point of this comment.
Why do you need rolling the time?

Unless I've completely missed your point, you don't need to roll the time with Stratum or GBT, you roll a value in the coinbase instead, named (IMO badly) the secondary nonce instead of screwing with the block timestamp (which is a hack) unnecessary

P2Pool can't handle simply altering the coinbase script. P2Pool internally has a structure that describes how to recreate the coinbase transaction, including the coinbase script, but that can't be changed because the hash of that structure is stuck in the last txout. P2Pool uses it to create short, self-contained proofs of work by storing the SHA256 midstate with shares and computing the
generation transaction's hash using that midstate and the hash of that internal structure.

TL;DR: If the coinbase script is altered, the hash in the last txout of the generation transaction has to be changed too.

However, I discovered yesterday that Stratum is flexible enough to roll any data in the coinbase transaction at all, though, so rolling something in the last txout script is probably possible (though it would require a change to P2Pool's rules).

1J1zegkNSbwX4smvTdoHSanUfwvXFeuV23
kano
Legendary
*
Online Online

Activity: 1918


Linux since 1997 RedHat 4


View Profile
November 01, 2012, 01:40:36 PM
 #3719

Um - it's the actual coinbase field itself - the same place where you put all that other random data.
If you can randomly throw merged mining data it there, you should be able to add a 4 byte fields in there that you can roll instead of the ntime field.
I'm not sure what I'm missing here?

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
forrestv
Hero Member
*****
Offline Offline

Activity: 510


View Profile
November 01, 2012, 01:46:42 PM
 #3720

Um - it's the actual coinbase field itself - the same place where you put all that other random data.
If you can randomly throw merged mining data it there, you should be able to add a 4 byte fields in there that you can roll instead of the ntime field.
I'm not sure what I'm missing here?

You could easily roll something in the coinbase script,  yes, but it wouldn't result in a valid p2pool share. The miner would need to be smart enough to update the data in the last txout, which is impractical.

1J1zegkNSbwX4smvTdoHSanUfwvXFeuV23
Pages: « 1 ... 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 [186] 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 ... 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!