[BBR] Boolberry Hash-on-blockchain discussion - page 2.

crypto_zoidberg

hero member

Activity: 976

Merit: 646

Quote from: smooth on April 30, 2014, 09:03:20 PM

You most certainly can't have SPV clients if verifying the block header pow requires the entire block chain.

As far as the pow itself I'm still not quite sure what you are trying to accomplish.

Sorry if i'm not clear.
We are looking for a way to be memory hard (at mining) on the one hand, on the other to use wider cpu instruction set (if possible). In our opinion it make sense in ASIC protection. Please correct me if i wrong.
At the same time we want to have cheap PoW check operation(the reason why we changing CryptoNote PoW).

Quote from: smooth on April 30, 2014, 09:03:20 PM

As far as the bitcoin transaction volume you mentioned, I consider that very low if you are designing for the long term.

But it seems you have through this through a fair amount and if you are launching in two days I doubt it makes sense to change the pow right before launch, so I guess we'll just see how it goes. You can always hard fork, but that gets much more difficult to accomplish over time.

Probably it's better to spend one week for discussion before launch than stress network with hard fork.

digicoin

legendary

Activity: 1106

Merit: 1000

Is it possible to extend daemond to return full list of block header hashes instead of the full blockchain? What is the security implications of this approach? E.x: a malicious/compromised node can response with purposefully modified hash list?

I believe that this coin can take CryptoNote as its core technology but it must separate itself from Bytecoin to make room for improvement. At least for the middle term.

smooth

legendary

Activity: 2968

Merit: 1198

Quote from: crypto_zoidberg on April 30, 2014, 05:19:39 AM

The real problem i think is to have SPV client with this approach.
What do you think ?

You most certainly can't have SPV clients if verifying the block header pow requires the entire block chain.

As far as the pow itself I'm still not quite sure what you are trying to accomplish. As far as the bitcoin transaction volume you mentioned, I consider that very low if you are designing for the long term.

But it seems you have through this through a fair amount and if you are launching in two days I doubt it makes sense to change the pow right before launch, so I guess we'll just see how it goes. You can always hard fork, but that gets much more difficult to accomplish over time.

crypto_zoidberg

hero member

Activity: 976

Merit: 646

Quote from: smooth on April 29, 2014, 06:52:10 PM

I may not understand what you are trying to accomplish.

If H1 is slow but does not require a lot of random access to memory, then you can run H1 on a GPU or ASIC, then deliver a set of indexes into the blockchain to the node.

That's why H1 have to be fast, as you wrote in shortcomings.

Quote from: smooth on April 29, 2014, 06:52:10 PM

If the blockchain fits in memory then you are doing a handful of memory accesses and the other work may dominate. If the blockchain does not fit in memory, then you are giving a huge advantage to people with large solid state drives (flash or battery DRAM) or probably better the ability to store the block chain in a memory kvs across multiple servers.

This may frustrate decentralization because you are better off just maintaining a connection to a node/pool with such a device than running node yourself.

Let's do some calculations to see what we have:
To get hashing data from block we use:
1. Coinbase outs: usualy 10*32 = 320 bytes.
2. Tx hashes: 32 * (from 1 to 80) (80 is current bitcoin transaction flow) = from 32 to 2560 bytes

With 720 block per day we will increase scratchpad from 92 MB to 758MB per year. Enough to make ASIC's stay away but ok for normal miners. Even if we will be a very success and will get tx flow like a bitcoin in next ten years, scratchpad will be about 10GB, not a problem even now.

The real problem i think is to have SPV client with this approach.
What do you think ?

Quote from: smooth on April 29, 2014, 06:52:10 PM

If you want to use the block chain for PoW like Ethereum to require miners to run nodes (but see above), then you can probably do something simple like:
B = block
E = hash function, such as Keccak
B(i) = blockchain data at index i (mod len(blockchain) or some such)

H1=E(B)
H2=E(B+1)
PoW= E(B(H1))+H2)
Could be repeated, but not sure that adds much.
Maybe that is close to what you propose, but again I don't see the point to using a scratchpad at all. The blockchain is essentially your scratchpad.

We do very similar:
E' - first phase hash.
E - final phase hash.
H1' and H1' - is different parts of same hash (low and high) used to address random block

H1=E'(B)
PoW= E(H1 + E(B(H1')) + E(B(H1'')) )

E' can be a keccak(at least it should be as fast as keccak), but better to use some hash with more complicated instruction set as i said (64-bits numbers multiplication, AES/SSE)

smooth

legendary

Activity: 2968

Merit: 1198

I may not understand what you are trying to accomplish.

If H1 is slow but does not require a lot of random access to memory, then you can run H1 on a GPU or ASIC, then deliver a set of indexes into the blockchain to the node. If the blockchain fits in memory then you are doing a handful of memory accesses and the other work may dominate. If the blockchain does not fit in memory, then you are giving a huge advantage to people with large solid state drives (flash or battery DRAM) or probably better the ability to store the block chain in a memory kvs across multiple servers.

This may frustrate decentralization because you are better off just maintaining a connection to a node/pool with such a device than running node yourself.

If you want to use the block chain for PoW like Ethereum to require miners to run nodes (but see above), then you can probably do something simple like:

B = block
E = hash function, such as Keccak
B(i) = blockchain data at index i (mod len(blockchain) or some such)

H1=E(B)
H2=E(B+1)
PoW= E(B(H1))+H2)

Could be repeated, but not sure that adds much.

Maybe that is close to what you propose, but again I don't see the point to using a scratchpad at all. The blockchain is essentially your scratchpad.

tromp

legendary

Activity: 990

Merit: 1108

Quote from: crypto_zoidberg on April 29, 2014, 06:18:37 PM

Quote from: tromp on April 29, 2014, 12:54:13 PM

If you want to strengthen the ASIC resistance of CryptoNight and avoid the slowness of verification,
why not use an a-symmetric memory-bound proof-of-work like Momentum or my Cuckoo Cycle?

Thank you for suggestion, will look at this. How long it do one check in microseconds?

42x2 siphashes and 2 sha256 hashes can't take more than a few microsecs...

smooth

legendary

Activity: 2968

Merit: 1198

Quote from: BitRock on April 29, 2014, 11:11:40 AM

CPU coins are heaven of botnet. Does Blockchain-based hash or cryptoNote against botnet?

Botnets mining (which is stupid for them) is a good thing longer term. Not something to be worried about. This is obvious to anyone who thinks through the economic and game theory aspects of it.

crypto_zoidberg

hero member

Activity: 976

Merit: 646

Quote from: tacotime on April 29, 2014, 01:11:28 PM

This doesn't really prevent botnets... you can just torrent the blockchain and distribute it amongst all peers in the botnet. Worse, it totally breaks any chance of having SPV clients in the future.

Not agree about SPV clients. I've posted before in this thread: https://bitcointalksearch.org/topic/m.6464526

crypto_zoidberg

hero member

Activity: 976

Merit: 646

Quote from: tromp on April 29, 2014, 12:54:13 PM

If you want to strengthen the ASIC resistance of CryptoNight and avoid the slowness of verification,
why not use an a-symmetric memory-bound proof-of-work like Momentum or my Cuckoo Cycle?

Thank you for suggestion, will look at this. How long it do one check in microseconds?

crypto_zoidberg

hero member

Activity: 976

Merit: 646

Quote from: BitRock on April 29, 2014, 11:11:40 AM

CPU coins are heaven of botnet. Does Blockchain-based hash or cryptoNote against botnet?

WE ARE AGAINST ANY KIND OF CRIMINAL.

Probably in future, when blockchain will not fit in a memory of a typical workstation with 4GB RAM it may became not effective to mine with botnets. But not sure about this.
Anyway, it can be said for any ASIC-resistent project, isn't it?

tacotime

legendary

Activity: 1484

Merit: 1005

Quote from: crypto_zoidberg on April 29, 2014, 05:55:47 PM

Quote from: digicoin on April 29, 2014, 01:29:58 AM

However, the wallet needs to operate on the whole blockchain if I understand correctly. Downloading and sync-ing the full blockchain is not easy on a mobile device

Not really. When you creates a new wallet you don't need to read all blockchain that have been before, obviously there are can't be a transactions to this address you just created. (and wallet keys file actually keeps creation timestamp inside). You only need a chain of block hashes, that can be fetched very fast(Wallet data file keeps hashes chain to be able detect and handle splits in daemon). So it can be easily implemented in mobile device. Even for bytecoin huge blockchain the hashes in new just created and synchronized wallet takes about 18MB, and it can be reduced without big effort.

Ah... I guess if you only use header data it's not much of an issue for an SPV client, but then I'm not sure if this affords additional security to the hash function.

crypto_zoidberg

hero member

Activity: 976

Merit: 646

Quote from: digicoin on April 29, 2014, 01:29:58 AM

However, the wallet needs to operate on the whole blockchain if I understand correctly. Downloading and sync-ing the full blockchain is not easy on a mobile device

Not really. When you creates a new wallet you don't need to read all blockchain that have been before, obviously there are can't be a transactions to this address you just created. (and wallet keys file actually keeps creation timestamp inside). You only need a chain of block hashes, that can be fetched very fast(Wallet data file keeps hashes chain to be able detect and handle splits in daemon). So it can be easily implemented in mobile device. Even for bytecoin huge blockchain the hashes in new just created and synchronized wallet takes about 18MB, and it can be reduced without big effort.

crypto_zoidberg

hero member

Activity: 976

Merit: 646

Quote from: axo on April 29, 2014, 01:07:07 AM

Using the blockchain is a good idea to prevent gpu mining in the long term (when it cannot fit in the gpu memory) because the slow transfer speed from host memory to gpu memory.
I'm not sure it could be a problem for realizing an ASIC. In the pipeline there is a step that picks up relative small amount of data from big set of data and fills the relative small pipeline memory (actually 130k is not small but in the future it could be). This is a bottleneck but not so big as for GPUs.
The problem with ASIC is not only the bigger calculation power than cpu, but the better energy efficiency. The problem with ASIC remain if it is possible to realize an ASIC not faster than a cpu but that requires thousands times lesser energy.

An idea: what about using the selector hash to vary the instructions sequence of second hash? In that case the ASIC pipeline becomes inefficient and similar to cpu.

mmm...do you mean some kind of polymorphic hash?...

tacotime

legendary

Activity: 1484

Merit: 1005

This doesn't really prevent botnets... you can just torrent the blockchain and distribute it amongst all peers in the botnet. Worse, it totally breaks any chance of having SPV clients in the future.

koop4u

sr. member

Activity: 308

Merit: 250

+1

tromp

legendary

Activity: 990

Merit: 1108

Quote from: crypto_zoidberg on April 28, 2014, 09:54:25 PM

Let's open hash-function discussion friends.
Just want to uncover our approach and show differences with CryptoNote that we use in our project announced here: https://bitcointalksearch.org/topic/bbr-boolberry-privacy-and-security-guaranteed-since-2014-577267

First of all I want to say that CryptoNote hash function (so called cn_slow_hash) is actually a very strong protected from ASIC's with different CPU instructions set as well as memory consuming algo. cn_slow_hash works hard on 2MB scratchpad and most of this scratchpad are fits in CPU cache.

Shortcomings
1. H1, as well as final hash (keccak) have to be very fast, otherwise memory consuming accent will be slight. If H1 is slow than possible to implement some specific hardware working similar to Instruction pipeline
2. Despite the first, H1 have to have modern cpu instructions set - 64-bits numbers multiplication, AES/SSE instructions to make ASIC engineers bloody mad.

Wellcome to comment.

If you want to strengthen the ASIC resistance of CryptoNight and avoid the slowness of verification,
why not use an a-symmetric memory-bound proof-of-work like Momentum or my Cuckoo Cycle?

BitRock

full member

Activity: 137

Merit: 100

CPU coins are heaven of botnet. Does Blockchain-based hash or cryptoNote against botnet?

kalisto

sr. member

Activity: 245

Merit: 250

Quote from: digicoin on April 29, 2014, 01:29:58 AM

However, the wallet needs to operate on the whole blockchain if I understand correctly. Downloading and sync-ing the full blockchain is not easy on a mobile device

It needs the whole blockchain but it doesn't care if this is a remote blockchain like a bitcoinj implementation.

digicoin

legendary

Activity: 1106

Merit: 1000

Quote from: crypto_zoidberg on April 28, 2014, 11:13:26 PM

Quote from: digicoin on April 28, 2014, 10:10:26 PM

Adam Back raises a concern on the possibility to run a SPV client on CryptoNote blockchain. He does not find a way yet. Running a full node is not an option to mobile clients like iPad or Android client. Do you have any improvement on this issue?

If you don't want to mine on ipad or on android you do nod need to have a node on it - Cryptonote wallet is designed as separate process and can be connected theoretically to any daemon. (or to few daemons to be sure)

However, the wallet needs to operate on the whole blockchain if I understand correctly. Downloading and sync-ing the full blockchain is not easy on a mobile device

axo

full member

Activity: 131

Merit: 100

Using the blockchain is a good idea to prevent gpu mining in the long term (when it cannot fit in the gpu memory) because the slow transfer speed from host memory to gpu memory.
I'm not sure it could be a problem for realizing an ASIC. In the pipeline there is a step that picks up relative small amount of data from big set of data and fills the relative small pipeline memory (actually 130k is not small but in the future it could be). This is a bottleneck but not so big as for GPUs.
The problem with ASIC is not only the bigger calculation power than cpu, but the better energy efficiency. The problem with ASIC remain if it is possible to realize an ASIC not faster than a cpu but that requires thousands times lesser energy.

An idea: what about using the selector hash to vary the instructions sequence of second hash? In that case the ASIC pipeline becomes inefficient and similar to cpu.

Topic: [BBR] Boolberry Hash-on-blockchain discussion - page 2. (Read 6869 times)