Search content
Sort by
Showing 8 of 8 results by yshurik
Re: BitBay OFFICIAL BITBAY Thread Smart Contracts Decentralized Markets Rolling Peg
⭐ Merited by suchmoon (4)
Dynamic Peg FAQ OF THE DAY
Does the Dynamic Peg make BitBay a stablecoin?
Find the answer here:
https://forum.bitbay.market/t/does-the-dynamic-peg-make-bitbay-a-stablecoin/2176
See the Dynamic Peg action live now at https://exchange.latoken.com/exchange/BAY-BTC
Does the Dynamic Peg make BitBay a stablecoin?
Find the answer here:
https://forum.bitbay.market/t/does-the-dynamic-peg-make-bitbay-a-stablecoin/2176
See the Dynamic Peg action live now at https://exchange.latoken.com/exchange/BAY-BTC
These tips are great thanks.
2 questions
I just want to make sure of
1/ if I buy from the Bay Reserve on latoken
Can I withdraw to my standard Bay receive address and the exchange will release. My local wallet will auto recognise and assign these to my reserve bay holdings?
2. Is there a very detailed guide on sending my local liquid to local frozen?
For dzimbeck - yes I agree with that.
Thank you
1. Qt wallet will receive it immediately but it does not sum up to reserve. It will become frozen for 1 month so you can not spend it (though you can stake it), when 1 month will pass it may sum up with reserve and liquid depend on peg level after one month (for example if peg will be zero after one month, then all coins will become liquid of course)
2. In Qt wallet you just choose "transfer type" when send
Re: BitBay OFFICIAL BITBAY Thread Smart Contracts Decentralized Markets Rolling Peg
Thanks for the replies.
@shaydinblue: I was aware that the peg is active, I was really just following up on the post by BitBayDoc re freezing/reserving. BBD said he was not going to freeze/reserve until after next update, implying he had the choice. I was just wondering why coins were being reserved without any action being taken.
@yshurik: what exactly is the difference between reserved coins and frozen coins?
@shaydinblue: I was aware that the peg is active, I was really just following up on the post by BitBayDoc re freezing/reserving. BBD said he was not going to freeze/reserve until after next update, implying he had the choice. I was just wondering why coins were being reserved without any action being taken.
@yshurik: what exactly is the difference between reserved coins and frozen coins?
Liquid can be transferred to another address without limitations same as standard coins.
Reserve can be transferred to another address but then it got frozen - can not move for a month.
When month passes frozen txout can be moved again.
Liquids move fast, reserve moves with a month lock.
Re: BitBay OFFICIAL BITBAY Thread Smart Contracts Decentralized Markets Rolling Peg
Further to my post (above) the total number of reserved coins has now risen to 1,370,000.
What does this mean, if anything? (given that I haven't actually done anything?)
What does this mean, if anything? (given that I haven't actually done anything?)
It means the whole system is deflating now. Liquidity is turning into reserves.
Re: BitBay OFFICIAL BITBAY Thread Smart Contracts Decentralized Markets Rolling Peg
Updated QT wallet to v3 and it stuck on block 2459220, 38 hours ago. Synced from scratch. How fix it?
This may happen as not 100% nodes were updated before hard fork.
So you unluckily stuck into abandoned chain looks like.
Simplest and quick way:
1. stop qt wallet
2. backup wallet.dat somewere
3. remove all files in datafolder except wallet.dat
4. place bootstrap.dat in datafolder
5. start qt wallet
bootstrap file is updated up to Jan 23 - bypassing fork point, so you should be safe after resync.
it may take 2-3 hours to load from bootstrap which is much faster then ordinary resync.
Re: BitBay OFFICIAL BITBAY Thread Smart Contracts Decentralized Markets Rolling Peg
Has anyone ever tried to use the RPC commands of the wallet?
It tried both bitbay-qt and bitbayd (newest github clone), and everytime I send a request I only get "empty responses".
This is what I send:
The same Curl command works for many other currency wallets, only bitbay is making problems.
The port is configurated in bitbay.conf and netstat is showing bitbay listening on this port, so to that point everthing seems to be correct.
Looks like either a problem in my command or a problem in bitbay wallet RPC implementation?
But other wallets from other currencies would also respond an adequate JSON encoded error message in the case the given command is invalid. Bitbay just does nothing.
It tried both bitbay-qt and bitbayd (newest github clone), and everytime I send a request I only get "empty responses".
This is what I send:
Code:
curl -u bitbayrpc:BBZP3Q4MqWqksU -X post -d '{"id": "0", "method":"getinfo", "params": []}' -H 'content-type: application/json' http://127.0.0.1:25001
Curl always reports:Code:
curl: (52) Empty reply from server
I tried GET and POST and digest auth. Everytime same behaviour. The same Curl command works for many other currency wallets, only bitbay is making problems.
The port is configurated in bitbay.conf and netstat is showing bitbay listening on this port, so to that point everthing seems to be correct.
Looks like either a problem in my command or a problem in bitbay wallet RPC implementation?
But other wallets from other currencies would also respond an adequate JSON encoded error message in the case the given command is invalid. Bitbay just does nothing.
Hi, http method should be written in upper case:
-X POST
(-x post will not work)
Related to a lot of discussions about the increasing of block sizes in bitcoin.
Just interesting to hear a word from bitcoin core developers if there considered an approach of reducing time between blocks to be adaptive depending on network load (amount of transactions), of course in some ranges (can the network actually work in right way with time between blocks just as 1 minute) instead of a lot of attempts to increase blocksize and creates a lot of incompatibilities.
Also if it is considered, does it turn to be hard or soft forks?
Just interesting to hear a word from bitcoin core developers if there considered an approach of reducing time between blocks to be adaptive depending on network load (amount of transactions), of course in some ranges (can the network actually work in right way with time between blocks just as 1 minute) instead of a lot of attempts to increase blocksize and creates a lot of incompatibilities.
Also if it is considered, does it turn to be hard or soft forks?
Any solution that adjusts dynamically based on the amount of transactions is likely to be exploited, as spam transactions are easily created. Dynamically adjusting block times would require dynamically adjusting network difficulty, which even in a relatively simple use case such as BCH's EDA already prove to lead to problematic side effects. Additionally you'd need to find a new metric on how to define difficulty periods based on hashrate and to dynamically adjust block rewards, as otherwise you'd unwillingly increase Bitcoin's issuance rate.
Either way, as it would require some deep changes in the current consensus it would likely require a hardfork.
The approach as you describe it sounds kinda familiar to me, but I don't think Core ever considered it.
interesting, maybe a bit different approach, not dynamically adjusting network difficulty at all, but having an multiplier/divider like from 1 to 5, so max=5 means that pool of transactions is too high (like more 100K), so with miners will have choice - mine "standard" block in 10 minutes and get 12btc or mine "fast" block in 2 minutes but get 12/5 btc.
Related to a lot of discussions about the increasing of block sizes in bitcoin.
Just interesting to hear a word from bitcoin core developers if there considered an approach of reducing time between blocks to be adaptive depending on network load (amount of transactions), of course in some ranges (can the network actually work in right way with time between blocks just as 1 minute) instead of a lot of attempts to increase blocksize and creates a lot of incompatibilities.
Also if it is considered, does it turn to be hard or soft forks?
Just interesting to hear a word from bitcoin core developers if there considered an approach of reducing time between blocks to be adaptive depending on network load (amount of transactions), of course in some ranges (can the network actually work in right way with time between blocks just as 1 minute) instead of a lot of attempts to increase blocksize and creates a lot of incompatibilities.
Also if it is considered, does it turn to be hard or soft forks?
btw, I am wondering what would happen if some transaction will be sent during the hard fork. What can be the logic flow behind that leads to loosing of funds for some user (sender or receiver)?