As we had some issues with newcomers not backup up their wallets properly (the passphrase is not a brainwallet as in NXT) .. I'd like to propose a new initial scheme for the generation of the wallet master key (which is used to derive account keys)
It's quite simple and those of you that have a keyhotee founder id should be pretty familiar with it:

1) the first time a user opens up the wallet he will be asked to enter the following information:
  - first name
  - last name
  - id number
  - mail address
  - birthday
  - BRAINWALLET / passphrase / secret .. or something else that is SOLELY used to generate the key
2) generate the private key according to
   HASH(first name + last name + id number + mail + birthday + brainwallet)
3) Further ask for a passphrase to encrypt the private key after generation
  store ENCRYPT(HASH)
4) done

This way you can force the user initially to make a backup of the most important private key (the wallet master key) and thus also makes a backup of all further used keys as they are hierarchically derived from it!

Note, that basically all (except one) user input can be considered OPTIONAL .. they are only there to increase the entropy ..
the user should be told that no information he enters is stored anywhere ..

Thoughts?

Those of you that registered a name on the blockchain might have noticed that you can store a JSON object associated with your registered name on the blockchain, such as website, mail, ...

I'd recommend we start a discussion about which data active delegates should publish together with their name. This would involve a (not-so-regular) update-transaction. Nothing to special.

Those are the fields I personally would like to see for active delegates:

- website (campaign for the delegate)
- pgp/gpg fingerprint
- mail
- scripthash for price feed script
- delegate slate
- maintainer TITAN address

optionally those keys could could also be published:
- skype
- icq
- twitter
...
- bitmessage
- donation TITAN address
- forum handle
...

What's your view on this? Do we need this? Not required? Should we someday adjust our votes to reflect those entries to?

Disclaimer: My public json data currently only contains the slateID!


Thoughts?

Now, having BTS a single product mainly maintained by I3 (later by the blockchain) .. we need a team of security experts that can handle code issues found by white/gray hats.

As a reference: http://satoshilabs.com/security/

Please also publish some PGP pubkeys!

Hey there,

i couldn't find the a list of properties that should be fulfilled by a delegate to be approved (in general).
My thoughts are that we should have a set of rules (community/shareholder approved) that gives newcomers an idea of which properties are important when voting for delegates.

Consider the following a DRAFT ... and INCOMPLETE:

Vote on a regular basis
Voting helps to keep the competition between delegates alive. Vote as regular as possible, preferably every few weeks.

Do not trust delegates of secret, private or closed businesses
The sole purpose of the delegates are to secure the network independent of their pay. Playing with open cards should be honored while secretly operating delegates should be avoided.

Do not trust groups or teams of delegates
The more delegates a business controls, the more centralized the network becomes. While small groups of only a few delegates per business can be accepted for a short period of time, a permanent active group of delegates should be avoided.

Arrangements or collusion between delegates should result in an immediate disapproval
Under no circumstances should colluding delegates receive any approvals. Arrangements and collusion that become publicly known should be disapproved ASAP.

Prefer delegates that can be linked to known individual
Although a not defined number of anonymous delegates should be tolerated, the gross majority of individuals running a delegate should be publicly known in person. The definition of "publicly known" is entirely up to the voter.

Do not trust any web page telling you how to vote!
Review all sets of delegates/slates offered to you


Further delegate properties that should be included in the voters considerations (random order):
* already voted in and actively producing blocks?
* reliability?
* payrate?
* publicly known owner of the delegate?
* regularly publishes feeds
* up-to-date node software?

Please discuss!

Hey there,

I will be in Austin (TX) for a week and will probably join the Bitcoin Meetup in Austin on Sunday 7th December ..

Besides me, another well-known member of the community  (who doesn't want to be named publicly) will be there too.
So we are at least two in Austin .. and if I am fine from jetlag .. I will join evangelize the Bitcoin people there

Please let us know I you want to join!

For those that did not attend the latest dev hangout, BM briefly explained how cross-chain trading would work.
However, he also stated that ACCT is very low in priority as they see more value from developing escrow ... (imho they are right)

Anyway, I'd like to also let you know how ACCT works.

Let's assume we have Alice wanting to trade 1 bitUSD on BTSX chain for 1 bitUSD
on the DNS chain. Bob wants to do the same .. but the other way round.

Alice goes first (could also be Bob) .. and generates a random passphrase. Let's say

Passphrase: AlIcETraDesWithBoB1USD

Alice generates the hash of the passphrase and gets something like

hash(Passphrase): afb39ca02949c0ae4a6a44e8eef5242fd81bd93072d82ebff145743c1910c098

Alice uses a new kind of transaction (not so new.. it's already in the blockchain and called withdraw_password_type) ..
that transaction goes towards bob and has the following rules

- the transaction is going TO bob
- it has a expiration of .. say 24h .. after that only alice can claim the transaction again
- bob can claim (within 24h) .. ONLY if he knows the password

Alice broadcasts this transaction in the BTSX chain and thus "transfers" the
funds to bob .. who will only be able to claim the shares if alice tells the password!

In the meantime, Bob creates a new transaction in the DNS chain. That
transaction goes to the account name of alice, and uses the exact same hash of
the passphrase (bob see that passphrase from alice's transaction in the btsx
chain) .. and he set's a expiration of less then 24h ..

So, if alice wants to have her shares in the DNS chain, she needs to reveal the
password in order to claim the withdraw_password_type-transaction in DNS.
By doing so, Bob sees the passphrase and can take his shares in the BTSX chain,
beacuse it uses the same passphrase.

Tada .. everything worked out .. everybody happy

Remarks:

- It is crucial to have the the second transaction (bob does not know the
passphrase) .. expire WAY earlier than the first transaction to ensure that
alice cannot reclaim an EXPIRED ACCT transaction

- It is crucial (as usual) that the passphrase is chosen securely, and randomly!!

Anything I forgot to describe? Anything unclear?

Hey friends,

i just found a nice page which we could use to collect the (approx) locations of community members.
The features are:

 * Sign-Up Not Required
 * Custom Fields
 * Map Images
 * Multimedia
 * Customizable Icons
 * Color Regions
 * Marker Groups
 * Entry List
 * Moderated Additions
 * Private Mapping
 * GeoSearch
 * Edit Grids

I have not yet extensively tested the platform but I think we can start from there and export all added locations if required.

view only: http://www.zeemaps.com/view?group=1162907&x=-80.400616&y=37.224179&z=6
add you location: https://www.zeemaps.com/map?group=1162907

Note: Please only add your home town and maybe not put the market at your own house