Topic: [ANN] BITGESELL - Store of value (Burn rate is 90% of tx fees) #realstoreofvalue - page 55. (Read 26730 times)

There is an idea not to store keys on the backend.
The user is allowed to enter a private key for each action, the bot removes it from the correspondence (the key does not remain on the telegram servers and on the bot), and uses it to perform one operation
How is the idea? Is this good for not storing keys on the server?

Can you please tell me what parameters use for bgsell network?

exports.bitgesel = {
   messagePrefix: '\ x18Bitgesel Signed Message: \ n',
   bech32: 'bc',
   bip32: {
     public: 0x0488b21e,
     private: 0x0488ade4,
   },
   pubKeyHash: 0x00,
   scriptHash: 0x05,
   wif: 0x80,
};

You can, such thing probably would be more suitable for web-based solutions, IMHO, but looks ok to me.


I am not familiar with Telegram bot architecture, but If the private key itself is stored in that telegram client on a mobile device or a computer and not passed to somewhere (of couse the wallet/bot code should have access to it), it fits the criteria.

Hi!

question from the hackathon https://mybglwallet.com/
Can I use third-party APIs in my wallet? To get balance and blocks

In the criteria, there is also such a parameter: private keys stored at the user side only
I have a Telegram bot, and the keys will be stored in the keyboard object (only our software and the user have access to them)
Is it a parameter valid in this case?

Or Silvio :-)

Good luck in the final hours everyone!

If I'm not mistaken, it was still Satoshi (to keep the tribute mb), but feel free to name it Gesell, why not

Hi!

What is the smallest unit name of Bitgesell cryptocurrency?

1 BGL = 10000000 [BGL_UNIT_NAME]

Gesell?

Please see my post at:
https://bitcointalksearch.org/topic/m.55538976

The transaction could be sent using sendtoaddress RPC command to a node, however, this is only for the
wallet represented by the node itself, and won't suit client wallet software. The client wallet approach can be simulated through using JSON RPC or BGL-cli
(without writing any code) as a sequence of these commands:

1. createrawtransaction - this will return the 'raw' unsigned transaction, pass parameters to what address and what amount to send;
2. signrawtransaction - sign raw transaction with a private key, making it valid, so it would be accepted by other nodes' validation mechanism and could be broadcasted to network;
3. sendrawtransaction - check that signed tx is ok and broadcast it to network to be included into blockchain block when mined;

wallet could use node call to get 1., or can implement this function itself;
wallet should implement 2. as this involves private key and it should stay at the user;
signed transaction is passed as param to 3. and essentially that's it.

Whoa, that's a nice one!
You can try to estimate yourself with any approach you like based on recent blocks or mempool state (mb we can add some bonus points for this actually) or just use some fixed value (e.g. 0.0015 BGL/Kb) for now. There are less transactions than in BTC currently and also node should gather stats to be able to set fee automatically, so some of the newer BTC fee-related things are not completely suitable for BGL currently. Fixed fee is a completely acceptable solution for now (if it also could be customized, as usually is the case in wallet software - would be good too).

questions from the hackathon:

how can we estimate the optimal transaction fee for a new transaction?

General question. How to create transactions for sending coins?

Run with -debug option and check startup log. Node should start syncing blockchain automatically (it should start in ~30 seconds from process start).
Check for messages like
It would mean it's reaching other peers and will sync block to max height (32570 in this example) available.
Messages should be present like these:
InitialBlockDownload is true would mean node is syncing and not ready yet. UpdateTip appears when blockchain chunk is synced. You can delete .BGL/blocks and .BGL/chainstate directories to resync the blockchain.
When BGLd is running and syncing, you can run some RPC commands to check the status, e.g.:

This displays blockchain state of current node. In this example it's still downloading blocks (on 28806 of 32572 currently).

Please check 'blockchain' RPC section in Bitcoin Core reference:
https://bitcoin-rpc.github.io/en/doc/0.17.99/rpc/blockchain/getblock/

For example:


I think the reasonably good approach will assume (or check) that the node is synced (initial block download = false) and getblockcount would return blockchain height. The currently mined block but not yet written block is the next integer.


For the purpose of initializing existing wallet balance, it most probably should be up to the last block, so the full scan from 0 to getblockcount, because at any arbitrary block there could be utxo present for some address. Maybe if more conditions is present, this could be narrowed down. BGL blockchain is very compact now so probably any optimizations regarding this may be not of a very high priority.

Hope this helps!

Thx!
4 questions

1) Node and mainnet are not synchronized if I understand correctly. Can you tell me how to check this? And how to synchronize a node with Mainnet?
2) How to request the last block in a node?
3) Is there a method to get the current block number?
4) how can i find out the last possible stop_height value for the method rescanblockchain?

By default, the node (when started without any arguments as BGLd) will sync to production mainnet, then listen to the localhost RPC without login or password, if you want to expose it somewhere, create a file
~/.BGL/BGL.conf

Operating System	Default BGL datadir	Typical path to configuration file
Windows	%APPDATA%\BGL\	C:\Users\username\AppData\Roaming\BGL\BGL.conf
Linux	$HOME/.BGL/	/home/username/.BGL/BGL.conf
Mac OSX	$HOME/Library/Application Support/BGL/	/Users/username/Library/Application Support/BGL/BGL.conf

You can also use Bitcoin Core-based config tools, like e.g.:
https://jlopp.github.io/bitcoin-core-config-generator/ (mb a bit complex one)
Just the file name and location is different.

Hi!

Could you please give an example of a node configuration for BGL?

1. This not an 'another fork' of bitcoin, this is an attempt to create new asset with new economical properties. I could use other code base, e.g. Eth one, or from one of the altcoins, so the emphasis is more on economics, not the programming. So I chose to use bitcoin code for this goal.
2. The goal is not technology for the sake of technology, even more, let me put it rather bluntly, other approaches (of consensus, infrastructure, programming languages, etc.) yet to have reach BTC success and adoption.
3. I lean towards PoW consensus, because this mechanics is the only one existing right now that is directly bound with material world through physical principle. In the end, if to extrapolate, PoW stimulates more efficient hardware, and more efficient technological process and faster chips, which moves digital economy forward. We share this evolutionary approach with bitcoin.
4. Miners get coin for spending real material resources that cost traditional money (GPUs, ASICs RnD and making of them, electricity paid in yuan). But to compensate for mining costs they have to sell mined coin. This allows for the distribution and rotation of the coin, helping with fair pricing, material world connection and liquidity.

5. You've asked great first question. I'd like to send you some BGL coins as a bonus for it (if you have BGL address, please send me). There is hackathon going for next 2 days, we should have wallet software updates hopefully, if you don't have BGL address, come back in few days

Just a small hints list that may help in solving the task:
- Get a wallet address for test and private key (every team should be provided one);
- Set up a full node and run it (binary package is OK, use clean Ubuntu VM), let it sync, it does that in 3-5 minutes;
- When running node for the first time it would create ~/.BGL directory, new wallet and addresses (older-fashioned, BTC-Core way derivation);
- Play with RPC:
  - use dumpwallet to save 'your' addresses;
  - send a transaction from provided wallet to 'your' address using a sequence of:
    createrawtransaction/signrawtransaction/sendrawtransaction
    wait for the block to be mined and coins arrive at your wallet
- Check most important changes that were implemented from bitcoin regarding wallet interaction:
  - hashing algo change for blocks/transactions: hash.h, class CHash256 was split into additional CHash256BlockOrTransaction (keccak);
  - signing salt is changed (search for strMessageMagic);
- Pick some open-source BTC compatible wallet that you think is robust enough;
- Make changes;
- Test changes.
This is a pretty bird-eye view, but hopefully can help.

Today 2020 year
not 2017
not 2018
not 2019!!
And humanity has PoS, BFT and oher types of consensus..
Graphene, tendermint.. so many blockchain frameworks
Ethereum change consensus to PoS at 1th December..
Proof of Work is unfriendly to the environment and outdated technology.
And my question is..
Why you make another fork of bitcoin in 2020 year!??
 

Upon request of EmmaWu we support Bitgesell wallet hackathon.

 Just created draft BGL JS library https://github.com/bitaps-com/jsbgl

Signed transaction working example
https://github.com/bitaps-com/jsbgl/blob/beta/test/jsbgl.test.js#L2112

https://bgl.bitaps.com/78c5454deb539ca6712a548ecef6b84061d79318a3ff565ce9854f403c37cc59

Example changes from jsbtc  to  jsbgl

https://github.com/bitaps-com/jsbgl/blob/beta/src/classes/transaction.js#L608

We invite everyone to contribute to this library

Hope it will help for Bitgesell wallet hackathon participants

New winner of the transaction contest!
https://bglcontest.bitaps.com/
Block  # 32405
2020-11-06 12:55
bgl1qqz9ckd6lyu0n9mng9wjajwz4r3u6uw7r4zf0ze  (19682 transactions) - one more record!
Congrats!
reward is here 4332879ac0cb96d7ea80ded59426cd5d4079b8d2f3d1cc6521085e09e8b4a749

Tomorrow is the start of a Bitgesell wallet hackathon. I would be supporting and answering questions here, AFAIK there would be some checkpoints specifically for Q&A sessions, nonetheless I would try to constantly be here from early evening CET to answer questions (mostly on the technical side). Please try to elaborate on the topic and everything should be alright. Best of luck to the teams!