Search content
Sort by
Showing 20 of 63 results by mrpandabear
Excellent! Could you tell me about Bamboo Networks future vision, what you have in store for us? Next steps and such, investors would be happy to learn more. How is the new algo holding up? How you see crypto in a few years and Bamboo in it?
I am going to be sharing a new whitepaper soon. Ultimately I see Bamboo as layer-1 of an entirely new ecosystem of apps that are all extensions of the core Bamboo blockchain. The next step will be introducing what I call "programs", programs are new blockchains which represent locked capital on layer-1... these chains execute on their own over the locked capital pool and can implement any verifiable program using something called zero-knowledge proofs. At the core this is very similar to a smart contract, except all smart contracts will be required to be verifiable in bamboo... there is nothing analagous to the EVM in ethereum where code actually runs on Layer 1.
At present I am diving very deeply into how to compile programs written in C to an architecture known as TinyRAM using a project called pequin:
https://github.com/pepper-project/pequin
The core of my vision is that these verifiable programs should be very easy to write and compile... which is currently not the case. More to share later.
Quick announcement: Members of our dev team are working on adding web miner (WASM) support to ShifuPool. This is a really exciting development 
You will soon be able to mine directly on the web!
You will soon be able to mine directly on the web!PUFFERFISH2 algorithm has now been released to live node. @Decrypted and @CoinfuMasterShifu have run pool and miner against testnet and everythinig appears to be functional. The switchover will happen at block 124,500 with the first pufferfish mined block being 124,501.
@Decrypted will be releasing an updated miner that will be necessary to continue mining bamboo past block 124,500. Will post to this thread to give the update once miner is released.
@Decrypted will be releasing an updated miner that will be necessary to continue mining bamboo past block 124,500. Will post to this thread to give the update once miner is released.
As mentioned we are now the first cryptocurrency to run a full node in browser over WebRTC.
This is pretty big leap -- a big barrier to entry to running nodes is the network setup -- the requirement that one have an externally accessible IP address -- Bamboo no longer requires this. Our vision is to have hundreds of thousands of nodes as literally anyone that has a browser can now host an ephemeral node, no externally accessible IP required.
This is pretty big leap -- a big barrier to entry to running nodes is the network setup -- the requirement that one have an externally accessible IP address -- Bamboo no longer requires this. Our vision is to have hundreds of thousands of nodes as literally anyone that has a browser can now host an ephemeral node, no externally accessible IP required.
We are about to release some very cool updates. Our node server is being ported to run in WebAssembly using the emscripten SDK. This will enable anyone to host a bamboo node simply by opening a tab in their browser. We believe this is the first time any cryptocurrency has had this capability and it will allow our network of nodes to grow much faster -- no download or complicated server configuration necessary
I've updated the link in the main post -- seems it was expiired : https://discord.gg/2m9m2cnBk7
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
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
Whitepaper now available here:
https://www.dropbox.com/s/lctbgrhv53vcpla/Bamboo-Whitepaper.pdf?dl=1
Website coming soon!
https://www.dropbox.com/s/lctbgrhv53vcpla/Bamboo-Whitepaper.pdf?dl=1
Website coming soon!
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
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
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
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
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
Okay, got rid of the lambdas and added tests for the totalWork computation.
Here is a gist of what I am thinking for serializing/deserializing these structs, does this look reasonable?
https://gist.github.com/mr-pandabear/991b758cff11d3723d4c7fd5e414f1ff
Here is a gist of what I am thinking for serializing/deserializing these structs, does this look reasonable?
https://gist.github.com/mr-pandabear/991b758cff11d3723d4c7fd5e414f1ff
That is a really interesting proposition, will follow up in PM later tonight.
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?
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?
I re-wrote a much simpler Merkle hash computation here:
https://github.com/mr-pandabear/bamboo/blob/b2dd0f392f3be3b2db861bc450268ae88135d987/src/core/merkle_tree.cpp
So the problem we will introduce by creating a new Merkle calculation is that we will now have two hashing schemes and need to handle validating each one differently based on block number. This is a little bit ugly. I wonder how bad the construction I had earlier is in terms of the length of the proofs it would generate. If it's not that bad my inclination is to just leave it and we will have slightly non-standard Merkle proofs.
https://github.com/mr-pandabear/bamboo/blob/b2dd0f392f3be3b2db861bc450268ae88135d987/src/core/merkle_tree.cpp
So the problem we will introduce by creating a new Merkle calculation is that we will now have two hashing schemes and need to handle validating each one differently based on block number. This is a little bit ugly. I wonder how bad the construction I had earlier is in terms of the length of the proofs it would generate. If it's not that bad my inclination is to just leave it and we will have slightly non-standard Merkle proofs.
3. Yeah, I'll make a note to rename this in the codebase. The set<string> nonce was there to originally implement a per block nonce (in fact there was no TXDB in the original version and transactions were only accepted with a particular blockID to ensure that they could not be repeated in future blocks... this design was very cumbersome as you'd have to discard and re-submit transactions if they didn't make it into a particular block. A 5 character nonce string was used to ensure a lack of repeats within a given block but removed with the introduction of the txdb). TXDB was introduced in this commit:
https://github.com/mr-pandabear/bamboo/commit/b2c09d315bdc2acb5f817755df10391f61f0cdc0#diff-70e9ec68696d98d3955ce2a5ba9954596b47e14c812d2b13ee724a2529a0a5e7
4. Yes they worked like a charm
5. My plan is to correct for the larger 6.6M but not the 268.1507 ... yes agree that the 6.6M coins were minted
6. Makes sense, will make a note to put announcements here as well. Speaking of which we released a Windows light wallet:
https://github.com/mr-pandabear/bamboo-wallet/releases/tag/v0.0.1-alpha
7. See 3.
8. I didn't feel fully confident in the Merkle tree implementation and had an itch I'd get it wrong. Luckily it seems the bug you point out just prevents verification in log(TX count) hashes ... but is enough to prevent tampering with block contents (I think?). The ideal would be to use a good open source implementation. I'll probably swap it out for this one:
https://github.com/microsoft/merklecpp
https://github.com/mr-pandabear/bamboo/commit/b2c09d315bdc2acb5f817755df10391f61f0cdc0#diff-70e9ec68696d98d3955ce2a5ba9954596b47e14c812d2b13ee724a2529a0a5e7
4. Yes they worked like a charm
5. My plan is to correct for the larger 6.6M but not the 268.1507 ... yes agree that the 6.6M coins were minted
6. Makes sense, will make a note to put announcements here as well. Speaking of which we released a Windows light wallet:
https://github.com/mr-pandabear/bamboo-wallet/releases/tag/v0.0.1-alpha
7. See 3.
8. I didn't feel fully confident in the Merkle tree implementation and had an itch I'd get it wrong. Luckily it seems the bug you point out just prevents verification in log(TX count) hashes ... but is enough to prevent tampering with block contents (I think?). The ideal would be to use a good open source implementation. I'll probably swap it out for this one:
https://github.com/microsoft/merklecpp
1. Yes, some sloppiness here.
2. Self addressed transactions are not a problem ... they just equate to a no-op. Ofc, there is the potential for an attacker to flood the system with self-addressed transactions or zero-valued transactions. This edge case should be handled.
The negative -1 transaction you showed is the one that caused a faulty tx of sz 2^64 that I ignored during the fork. The ledger was never updated but the block was not rejected so it was a bug :/
3. Yeah, I agree it doesn't make that much sense. It can easily be set to anything anyone wants. The nonce parameter and blockID was removed after the fork but I left timestamp in. It's a wasted space :|
4. I think I used this or something similar to get Monero first time.
5. I am still not sure if I really want to mess with it. I think the cleanest solution is just to mint an additional 6.6M coins and leave it at that.
6. I agree though that if the coin gains value (which we all hope it does) ... then it will be important for those with large holdings such as early miners to remain anonymous lest they become targets for attackers.
2. Self addressed transactions are not a problem ... they just equate to a no-op. Ofc, there is the potential for an attacker to flood the system with self-addressed transactions or zero-valued transactions. This edge case should be handled.
The negative -1 transaction you showed is the one that caused a faulty tx of sz 2^64 that I ignored during the fork. The ledger was never updated but the block was not rejected so it was a bug :/
3. Yeah, I agree it doesn't make that much sense. It can easily be set to anything anyone wants. The nonce parameter and blockID was removed after the fork but I left timestamp in. It's a wasted space :|
4. I think I used this or something similar to get Monero first time.
5. I am still not sure if I really want to mess with it. I think the cleanest solution is just to mint an additional 6.6M coins and leave it at that.
6. I agree though that if the coin gains value (which we all hope it does) ... then it will be important for those with large holdings such as early miners to remain anonymous lest they become targets for attackers.