Bitcoin Forum
December 10, 2016, 07:21:44 AM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 [37]
  Print  
Author Topic: Wonder who this solominer is? 88.6.216.9  (Read 55433 times)
Shadow383
Sr. Member
****
Offline Offline

Activity: 336


View Profile
May 10, 2012, 04:15:29 PM
 #721

Honestly we need strongly signed blocks.  It can be optional but I imagine most pools would sign their blocks.  Major farms (GBLSE) would sign blocks to prove their contract's hashing power.  I think a majority of p2pool miners and even some solo miners would strongly sign their blocks. 

While not everyone would sign blocks it would eliminate the false positives and reduce the amount of unknown to the truly unknown.

Strongly signed blocks can be the precursor for more complex pool based services (like 0-confirm surety contracts).
What is the benefit of signed blocks? So we can see who mined it?
Yes. Right now, anyone can put almost anything in the blockchain to "prove" who made a block, but that doesn't stop anyone from putting someone else's info in to masquerade as them. There isn't usually any incentive to do that though, except in the case of something such as a botnet.
And can you imagine the chaos if someone with a moderate sized botnet started posing as a popular pool? It could make it appear that a pool was scamming its miners by not reporting blocks.
I think the major pools should publish the IP addresses that they publish blocks on, so that we can get a handle on who is submitting which blocks even before we start looking at signing.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481354504
Hero Member
*
Offline Offline

Posts: 1481354504

View Profile Personal Message (Offline)

Ignore
1481354504
Reply with quote  #2

1481354504
Report to moderator
1481354504
Hero Member
*
Offline Offline

Posts: 1481354504

View Profile Personal Message (Offline)

Ignore
1481354504
Reply with quote  #2

1481354504
Report to moderator
rjk
Sr. Member
****
Offline Offline

Activity: 420


1ngldh


View Profile
May 10, 2012, 04:17:03 PM
 #722

Honestly we need strongly signed blocks.  It can be optional but I imagine most pools would sign their blocks.  Major farms (GBLSE) would sign blocks to prove their contract's hashing power.  I think a majority of p2pool miners and even some solo miners would strongly sign their blocks. 

While not everyone would sign blocks it would eliminate the false positives and reduce the amount of unknown to the truly unknown.

Strongly signed blocks can be the precursor for more complex pool based services (like 0-confirm surety contracts).
What is the benefit of signed blocks? So we can see who mined it?
Yes. Right now, anyone can put almost anything in the blockchain to "prove" who made a block, but that doesn't stop anyone from putting someone else's info in to masquerade as them. There isn't usually any incentive to do that though, except in the case of something such as a botnet.
And can you imagine the chaos if someone with a moderate sized botnet started posing as a popular pool? It could make it appear that a pool was scamming its miners by not reporting blocks.
I think the major pools should publish the IP addresses that they publish blocks on, so that we can get a handle on who is submitting which blocks even before we start looking at signing.
If they are going to always publish blocks from a specific IP as a way of identification, then they will need to disable relaying functionality, otherwise said botnet would just relay through them.

Mining Rig Extraordinaire - the Trenton BPX6806 18-slot PCIe backplane [PICS] Dead project is dead, all hail the coming of the mighty ASIC!
pieppiep
Sr. Member
****
Offline Offline

Activity: 402



View Profile
May 10, 2012, 04:19:10 PM
 #723

You don't need a protocol change to do that if it's already possible to put your information in it.
Just change the extra information to
your name + previous block hash you've mined + sign(your name + previous block hash)
It should be possible to not insert this information so real anonymous mining stays possible.
rjk
Sr. Member
****
Offline Offline

Activity: 420


1ngldh


View Profile
May 10, 2012, 04:21:30 PM
 #724

You don't need a protocol change to do that if it's already possible to put your information in it.
Just change the extra information to
your name + previous block hash you've mined + sign(your name + previous block hash)
It should be possible to not insert this information so real anonymous mining stays possible.
Anyone can get the previous hash from your pool. It's in the blockchain, after all.

However, publishing some kind of signature based on the block number or hash, signed by a pool's private key would be ideal.

Mining Rig Extraordinaire - the Trenton BPX6806 18-slot PCIe backplane [PICS] Dead project is dead, all hail the coming of the mighty ASIC!
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
May 10, 2012, 09:00:37 PM
 #725

You don't need a protocol change to do that if it's already possible to put your information in it.
Just change the extra information to
your name + previous block hash you've mined + sign(your name + previous block hash)
It should be possible to not insert this information so real anonymous mining stays possible.

That won't work but I wasn't suggesting a breaking protocol change but rather an agreed upon optional standard which is fully backwards compatible.

Instead something like pools (optionally) create a public private keypair used for signing (probably should have mechanism for revocation or replacement).
The pool would modify the getwork so that they hash some standardized identifer (should be specific to the block to avoid substitution attack) and sign it.

Yes I was indicating such a system should be optional but sites like blockchain.info could scan the block look for a signature and then verify it w/ the pool's public key.    In cases where the block can't be verified (or no signature is present) blockchain.info and other sites could still try to guestimate the origin by IP address.  As long as the signature is placed somewhere which isn't a breaking change uniformed clients would simply ignore it.
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
May 10, 2012, 09:09:00 PM
 #726

You don't need a protocol change to do that if it's already possible to put your information in it.
Just change the extra information to
your name + previous block hash you've mined + sign(your name + previous block hash)
It should be possible to not insert this information so real anonymous mining stays possible.
Anyone can get the previous hash from your pool. It's in the blockchain, after all.

However, publishing some kind of signature based on the block number or hash, signed by a pool's private key would be ideal.

Except in a 51% attack. Smiley

The signature would need to contain something specific to the block (like merkle tree hash).
R-
Full Member
***
Offline Offline

Activity: 238

Pasta


View Profile WWW
May 20, 2012, 04:05:25 PM
 #727

Did we figure this one out?
swissmate
Sr. Member
****
Offline Offline

Activity: 252



View Profile
May 20, 2012, 04:12:15 PM
 #728

Might be the supercomputer at Granada's University, I went to see it and it is BIG AS HELL with loads of gpu's

Bitcoin adress:1HtrosDCEM3zMJ1RbsK9g4vpe3DTotBhVh


Need any translation?
Aseras
Hero Member
*****
Offline Offline

Activity: 658


View Profile
May 20, 2012, 10:03:23 PM
 #729

Key pair signing would also enable other things like enabling revocation of transactions. A method could be developed that would enable stolen coins to be recovered or made worthless.

Say a large amont of coins were stolen. If they had a private key assigned, an insurance transaction could be made for the same amount with a revocation key attached to invalidate the transfer after a lengthy confirmation period. As soon as the transaction hits the chain the addresses are block from transferring coins. This could also be challenged by doing another challenge transaction in the same way.  You could add in some security features like requiring a public ip address to broadcast during the entire revocation period to dispute. In that way the source could be traced. For a thief they would not be able to "afford" the chargeback or hide anonymously. It's not free per se to do either so it's not readily abuseable.




You don't need a protocol change to do that if it's already possible to put your information in it.
Just change the extra information to
your name + previous block hash you've mined + sign(your name + previous block hash)
It should be possible to not insert this information so real anonymous mining stays possible.

That won't work but I wasn't suggesting a breaking protocol change but rather an agreed upon optional standard which is fully backwards compatible.

Instead something like pools (optionally) create a public private keypair used for signing (probably should have mechanism for revocation or replacement).
The pool would modify the getwork so that they hash some standardized identifer (should be specific to the block to avoid substitution attack) and sign it.

Yes I was indicating such a system should be optional but sites like blockchain.info could scan the block look for a signature and then verify it w/ the pool's public key.    In cases where the block can't be verified (or no signature is present) blockchain.info and other sites could still try to guestimate the origin by IP address.  As long as the signature is placed somewhere which isn't a breaking change uniformed clients would simply ignore it.

Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 [37]
  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!