Topic: Bamboo: New crypto using ED25519 signing keys - page 5. (Read 4650 times)

If you post in the discord we will help you get it running!

I can't get the gpu miner to work.  It launches, but shuts down after a couple seconds. 

At the moment the team is working on another pool and numbers of nodes to secure the network is rising. Website should be online soon.

We've launched pool mining and GPU miner. Together these improvements have yielded hash rates up to 175+ GHashes/sec

We're launching a new program to expand the reach of the network: Node operators are offered 50BMB monthly (there is a small staking fee to ensure quality node operation) The goal is to reach 100 nodes by mid-May. Message us on discord if you're interested!

https://discord.gg/H7CMnXrY

Bamboo offers light code, faster transactions and our own blockchain (we are not a fork of any other coins out there).

---

https://github.com/De-Crypted/dcrptd-miner/releases/tag/1.0.0.rc8

Whitepaper now available here:
 https://www.dropbox.com/s/lctbgrhv53vcpla/Bamboo-Whitepaper.pdf?dl=1

Website coming soon!

Whitepaper will come soon and also our website will come with it. We are still in early stage and our progress is going further. We would like to invite new people with this to join also our discord: https://discord.gg/3H29Zhrz7C

I see, it must have been frustrating and a difficult situation for all, but things are back on track. Excellent news!

When will you have a complete whitepaper?  
You mentioned a draft version on discord. I'm thrilled to check it out when it is finalized, it should be there when you set up a website for the project.

We had another attack on the network and the chain was forked. Miners lost blocks between 18K and ~34K.

This was a very complex attack and nearly 3M BMB were stolen by attackers in total. The stolen funds have been recovered and placed in a community account.

Details on the origins of the attack and it's mitigation are available in this post-mortem:
https://www.dropbox.com/s/12b8js0kvfvtv79/Bamboo_Attack_Post-Mortem.pdf?dl=1

We had another attack on the network and the chain was forked. Miners lost blocks between 18K and ~34K.

This was a very complex attack and nearly 3M BMB were stolen by attackers in total. The stolen funds have been recovered and placed in a community account.

Details on the origins of the attack and it's mitigation are available in this post-mortem:
https://www.dropbox.com/s/12b8js0kvfvtv79/Bamboo_Attack_Post-Mortem.pdf?dl=1

Great work, I am glad it was discovered this early in development and just 2 people were affected.   

Quick update:

Yesterday the network had a breach where an issue with the public key to wallet verification enabled somone to steal and re-sell 800K BMB.

The patch for this issue was simple, and the cost of not having the patch catastrophic (it enabled anyone to steal funds with a simple tampering of transaction data because the signature attached to a transaction was not checked against the withdrawing wallet to ensure they were both from the same private key).

Luckily the funds were returned by the buyer.

You can see the patch here:
https://github.com/mr-pandabear/bamboo/commit/e8336611c3f4add703e925d65c581dfc516cc0bd#diff-bb0926cbaf68b7b7f85dbfae0e096e891684164d8b0602fac0cc3ebbccb1885aR122


The network has now been patched and is functioning as normal.

This pull/36 looks good I just have some comments:

1. https://github.com/mr-pandabear/bamboo/pull/36/files#diff-eae33aa8c4451ec780de10579fcb2ea0e24eb73f51d763a644d80269796e5e16R13-R34 There should be functions that
a) allocate a temporary
b) memcpy into it
c) advance the cursor automatically by the correct number of bytes (take char& argument and advance it)
d) return the temporary
This way, everything will get cleaner, just write such functions for uint8_t, uint16_t, uint32_t uint64_t.

2. Where is htonll defined (64 bit version). Didn't now about it, I thought the 64 bit version does not exist and one has to use be64toh?
3. The bounds checks such as https://github.com/mr-pandabear/bamboo/pull/36/files#diff-b82141a62c41308dc177b35e12e9aedcea86c92d94ddc96e7c35570b0499c4a3R176 are error-prone, I would really use exceptions directly in the parser functions such as https://github.com/mr-pandabear/bamboo/pull/36/files#diff-77098f03ea93c1f33e959abf1779714cbf9ac364d993ef4f91877a6168ef5540R12 to check for range overflow, exceptions are not that expensive. So you would write a class containing a cursor and a buffer end and would take instances of this type as parameter of the parser by reference and advance the internal cursor and do the bounds check against the end, throwing in case of an overflow. This makes everything so much easier and cleaner.
4. https://github.com/mr-pandabear/bamboo/pull/36/files#diff-b82141a62c41308dc177b35e12e9aedcea86c92d94ddc96e7c35570b0499c4a3R176 Why are you allowing excessive bytes? I would consider it as an invalid submit if there are some more bytes at the end, i.e. if buffer.size() - sizeof(BlockHeader) % sizeof(TransactionInfo) != 0. Finally, all bytes should be consumed.

Okay, got rid of the lambdas and added tests for the totalWork computation.

PR ready for handling network serialization/deserialization properly:
https://github.com/mr-pandabear/bamboo/pull/36/files

This diff would be especially helpful to get feedback:
https://github.com/mr-pandabear/bamboo/pull/36/files#diff-77098f03ea93c1f33e959abf1779714cbf9ac364d993ef4f91877a6168ef5540

Yes, received it.

I will also look at these cpp files and the other blocks when I have more time.

The struct memory alignment problem is not a protocol problem but a parsing problem. Please don't spoil the project with protocol buffers (msgpack is leaner and nicer but still, you don't need it, just memcpy).

Just memcpy POD-wise with fixed-size data types into a temporary and copy from that instead of reinterpret_cast<>ing. Then it will be fine.
I don't know atm if you did that but don't cast or memcpy large objects because then alignment of member variables matters. Do it for every data type individually: memcpy uint64_t, uint32_t and such things and use use htonl and ntohl, single bytes can be read directly (obviously, because they don't require alignment). Floats are platform dependent and are problematic.

I would write serialization and parsing functions for your data types (or use msgpack if you don't want to do it by hand)
For example instead of
https://github.com/mr-pandabear/bamboo/blob/1ac855ff08db053d5fe10803ec60f86f1227351d/src/core/block.cpp#L48

you would add a serialization function and a parsing function for https://github.com/mr-pandabear/bamboo/blob/1ac855ff08db053d5fe10803ec60f86f1227351d/src/core/block.hpp#L11-L19
by overloading a stream operator for serializing the member types and write a corresponding parser. You would have to write a cursor class that does bound checking and throws in case of bound violations. It is some work but it would play out nicely in the end. Or you just use messagepack (or protocol buffers if you really want to but I don't it). It depends on the number of objects you want to serialize and on the time you want to spend.

---

1. Unsafe reinterpret_cast conversion https://github.com/mr-pandabear/bamboo/blob/1ac855ff08db053d5fe10803ec60f86f1227351d/src/core/api.cpp#L118 Maybe define another type which stores headers as byte sequence with getters? Then you can just initialize them with memcpy. These things need to be done ASAP.
2. No need for lambda callback https://github.com/mr-pandabear/bamboo/blob/1ac855ff08db053d5fe10803ec60f86f1227351d/src/core/header_chain.cpp#L52 since this already happens in a separate thread, the value vector can be returned by the function instead of being a void function. Or better return failure and return the other values by modifying a reference but don't use a lambda.
3. Special attention has to be payed whether the total work computation is correct. https://github.com/mr-pandabear/bamboo/blob/1ac855ff08db053d5fe10803ec60f86f1227351d/src/core/header_chain.cpp#L66 Do you have tests for this? This definitively needs some test and it needs to be wrapped into a function (which has to be tested) to be on the safe side. Instead of `totalWork+= base.pow((int)block.getDifficulty());` you need something like `totalWork.add(block.getDifficulty())` or `totalWork.add(block)`
4. Bad style: https://github.com/mr-pandabear/bamboo/blob/1ac855ff08db053d5fe10803ec60f86f1227351d/src/core/header_chain.cpp#L76 Are there exceptions you don't know the type of? Don't do this to be on the safe side. If you know that your HTTP request only throw exceptions derived from std::exception then if there is another exception you do not expect, you should crash the program because it could be something strange that you would not find out about otherwise. https://www.quora.com/What-does-crash-early-mean-in-software-engineering Never catch all. Actually you should not even catch std::exception but subclasses used in your HTTP client (if there are such, didn't check, otherwise it is a bad library).

Have no time now, will continue later.

That is a really interesting proposition, sent you a DM (let me know if you received it)

You have a good eye.  I think in addition to implementing the pool a deeper code review of, blockchain.cpp, executor.cpp, header_chain.cpp and node synchronization logic from you would also be helpful to make sure the project is as stable as possible as we start to throw more nodes and hash rate at it.

The real vision of this project is to have the most lightweight and minimal production grade blockchain codebase out there that is as simple to understand as possible and is very good at one thing: transactions between person A and B. No frills or fat. I'm slowly getting there but the more help from knowledgeable people the better.

Also: Regarding the cross platform portability of structs / memory alignment issues you pointed out earlier -- what do you think is the best fix? Something like protocol buffers or MessagePack?

EDIT:
For further transparency, I have also found a copy of the chain that happened prior to the first fork (blocks 1 - 7750):
https://drive.google.com/file/d/1XrlbXUlNISf_x04wYiV3FYMr2gKi7NH5/view?usp=sharing

I can write a mining pool, it is a fair amount of work but doable. So how much XMR would you be willing to give me (write me a personal message)? Plus I would like to keep the code for 2 months and host the pool for 5% pool fee (as I said, I don't have any BMB at the moment and now it starts getting interesting). Then after two months I would hand over the code to the community.

Nice idea with the 'leaves' unit

Mining pool would be really good way to spread the hash rate.

Net hashrate climbing, any way to create pool mining?

Thank you, it is good to be here with you guys. Fingers cross for bright future. I think that we might see here interesting times soon.