Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Why is domain costs listed as $15k when they were already purchased? Did you purchase them from 3rd parties? Who paid for that?Those domains have been obtained by ChainSquad GmbH out of pocket. The .exchange domain was the most expensive in
bitshares.legal, bitshares.works and bitshares.exchange don't have domain information public, why? Who owns them now?
I suggest the team add extra budget to improve SEO for bitshares.foundation. The reason why those lawyers, exchange and any parties want to contact Bitshares will go bitshares.org because bitshares.org is listed as Top One when Google Search "Bitshare".I would ask the web devs to do the basic SEO, thanks for letting us know.
The cost should not be "up to $15k" but should be an already-known number.The domain costs are fixed - the other items are budgets for development
When can we vote on this ?Actually, the blockchains knows this worker already. A bug in the UI prevents users from voting on it. A fix for this has been merged already and I hope the web devs can make an "early" release
also, will this websites be available fully open under MIT in github ? so we can clone them, send pull requests ? i understand the .legal maybe will not accept pull requests but the others ?Whatever the community pays will be published Open Source on github.
Hello, I would like to get the following example from the PyBitshares documentation [1] to work:Surprise to me. Keywork parameters have to come after positional arguments in python.Code: [Select]
from bitshares import BitShares
bitshares = BitShares()
bitshares.wallet.unlock("wallet-passphrase")
bitshares.transfer("<to>", "<amount>", "<asset>", "[<memo>]",
account="<from>")
Although this is not the meat of my problem, you cannot supply keyword parameters after positional parameters. Therefore the call toCode: [Select].transfer()cannot haveCode: [Select]account=<from>parameter at the end.
Anyway, moving on to the real issues, it seems that before you can get this example to work, you need to decide on a wallet operation model (Wallet Database, Provide Keys, Force Keys). For this discussion, I would like to focus on providing keys.Wallet Import Format - it's the "usual" way of providing a private key ... they look like this:
The Bitshares constructor [2] accepts a `keys` parameter whose value may be an array, dictionary or string. This leads to the following questions:
1 - what is a wif key? What does "wif" stand for?
2 - Where would I access the private key for an OpenLedger account? Please provide a precise navigation sequence.Account Menu -> Permissions -> Active Key -> (click the bold key) -> show wif key
3 - Where would I access the private key for a Crypto-Bridge account? Please provide a precise navigation sequence.same as above - if you use the same account on both platforms, there is no need to do the process twice.
4 - Once I find the private key how does one supply it? The docs state the types of things that the `keys` parameter accepts, but it does not show how to supply it.
from bitshares import BitShares
bitshares = BitShares()
bitshares.wallet.create("secret-passphrase")
bitshares.wallet.addPrivateKey("<wif-key>")
After looking at the wallet documentation [3] I have a few more questions:Yes - the library figures this out automatically.
1 - after adding a private key, does PyBitshares automatically know which Bitshares account it belongs to?
For instance, if I add the private keys for the the bitshares user bev123 [4] am I able to call getActiveKeyForAccount [5] and supply 'bev123' as the name of the account?
Still same error for me.The issue is actuall on openssl binary since the default does not use SNI which is required on the haproxy.
!
In a hardfork, yes.This will ultimately raise a few questions about the STEALTH token which is a FeeBacked Asset that has been given by Dan for the development of Stealth. If the backend devs where to continue its development using funds from the reserves, it would only be fair to re-evaluate how well those that currently hold STEALTH (those that have interest in its development and usage), performed in the last 2-3 years.If solely implemented by the bitshares-core dev worker proposal then non-FBA is appropriate, otherwise fair enough. There'd be nothing stopping the copy/pasting of the stealth code without the FBA though right?
For me, it never made sense to work on STEALTH only so that some other people (STEALTH holders) can earn money of it.
I object to chris4210 advising anybody about anythingAs you can see from the linked document, the invitation covers the Committee as it is approved by the BTS holders. This also means, that it is up to the BTS holders to decide WHO that is. Of course, as votes come and go, the Advisory Board changes.
