@Clueless I think I've made a decision. The Android wallet backup scenario is a trainwreck. I think we need to do the bip39 and use seeds and launch the Android wallet with that.

Elliptic curve keys only

Doesn't bip39 have something to do with seed phrases?

Yes

We would make the client support seeds and do hierarchical deterministic keys like many other coins.

Why is the current situation a trainwreck? What have you guys implemented so far?

We have a pretty solid Android client implementation. however the backup strategy involves exporting the wallet file and saving that somewhere reasonable.

it seems that the only good way to do that is through the Android share interface which is basically just asking for people to do something like send it to their various Hangouts contacts rather than Google drive or Dropbox

Seems error prone

On an unrelated note, maybe you can clear something up for me - every now and then in discussion someone will claim that SNOW uses 0-conf, similar to BCH and NANO from what I can surmise. But I can't find anything about 0-conf in the wiki. Can you give me a brief explanation on how it works for Snowblossom?

Concept is called first scene first added. FSFA

it means that if a transaction spends unspent outputs and goes into the mempool no other transaction will be accepted into the mempool to spends the same outputs

So the bottom line is once a transaction as seen on the network it's very likely to be confirmed.

So good enough for most transactions like in a retail or food setting.

Does that essentially mean transactions are instant? What kind of issue would prevent a transaction from being confirmed?

For real estate or automobiles might want to wait for a few confirmations

Ok, so it's more of a trust thing. I guess what I'm trying to understand is the difference between FSFA and and a fast TPS

There are a few things that could prevent a transaction from being confirmed. Like restarting miner nodes, network fragments or races

Latency vs rate

FSFA allows for low latency, nearly instant for most purposes

TPS is about total network transaction rate.

That makes sense. So if I'm correct, if the network is congested one solution would be to raise block size. Is this the plan if SNOW ever achieves mass adoption and use?

Yeah, short to medium term is increase block size

Beyond that we have some ideas for sharding into a group of interdependent chains

Gets complicated of course

Interesting. Lots to keep up with, but I look forward to keeping up with SNOW's development in the future

It is an interesting time to be a cryptography nerd

I sometimes wonder if you guys ever consider expanding your team. Different devs and whatnot. But I can also imagine that sometimes you don't want too many cooks in the kitchen

I'm always open to more contributors

@Fireduck I agree.

It is what people know and expect now.

Boxes is into a corner

Can you figure out what our hd path should be?

Is the mitigation of centralization strategy only the anti-ASIC PoW or are their any other technologies/features involved?

@Fireduck Registration points https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki#Account https://github.com/satoshilabs/slips/blob/master/slip-0044.md ``` # REFERENCE SEE BIP44 m/purpose'/coin_type'/account'/change/address_index # BITCOIN m/44'/0'/0'/0/0 m/0x8000002C'/0x80000000'/0'/0/0 # SNOW SUGGESTIONS # hex(base32('snow'), testnet hex+1 # SNOW m/44'/37725'/0'/0/0 m/0x8000002C'/0x8000935D'/0'/0/0 # SNOW TESTNET1 m/44'/37726'/0'/0/0 m/0x8000002C'/0x8000935E'/0'/0/0 # Coin 600 # SNOW m/44'/600'/0'/0/0 m/44'/0x8000002C'/0x80000258'/0'/0/0 # SNOW TESTNET1 m/44'/601'/0'/0/0 m/44'/0x8000002C'/0x80000259'/0'/0/0 # SNOW RESERVED m/44'/602'/0'/0/0 m/44'/0x8000002C'/0x8000025A'/0'/0/0 # SNOW RESERVED 2 m/44'/603'/0'/0/0 m/44'/0x8000002C'/0x8000025B'/0'/0/0 ```

2338: snow, 2339: testnet, 2340: snow identity, 2341: snow node id

keeps it like the port numbers

yup, those are open.

Cool. Want to register those on that site?

Hopefully I'll have time today to get to work

@Fireduck Hrm, I don't get 0x80000001 Testnet (all coins)

I feel like I should reserve a few

So they want all testnet on that?

Fine with me

here's what I got so far

``` 2338 | 0x80000922 | SNOW | [Snowblossom](https://github.com/snowblossomcoin) 2339 | 0x80000923 | | [Snowblossom Testnet](https://github.com/snowblossomcoin) 2340 | 0x80000924 | | [Snowblossom Channels - Identity](https://github.com/snowblossomcoin/channels) 2341 | 0x80000925 | | [Snowblossom Channels - Node Identity](https://github.com/snowblossomcoin/channels) 2342 | 0x80000926 | | Snowblossom Reserved ```

If no one pitches a fit, that is fine with me

@Fireduck I mean, that might be what m/purpose is used for. but the documentation sucks

Can you show me the docs?

On mobile chasing child

I wouldn't mind not polluting namespace with our nonsense

@Fireduck No rush. My pull request: https://github.com/satoshilabs/slips/pull/494 The docs: https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki#purpose

Yeah it appears the purpose should be 44 for everything using the standard

I'm confused, if nothing other than m/44 exists, why have m/44

it's so that when somebody comes with up with some weird topological construct using brainspace based on hierarchical ballots somehow they can use a different number for that

My thinking is to use m/44 for coins, m/45 for identity ?

I dunno

https://github.com/bitcoin/bips/blob/master/bip-0045.mediawiki ``` <pre> BIP: 45 Layer: Applications Title: Structure for Deterministic P2SH Multisignature Wallets Author: Manuel Araoz <manu@bitpay.com> Ryan X. Charles <ryan@bitpay.com> Matias Alejo Garcia <matias@bitpay.com> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0045 Status: Proposed Type: Standards Track Created: 2014-04-25 </pre> ==Abstract== This BIP defines a structure for hierarchical deterministic P2SH multi-party multi-signature wallets (HDPM wallets from now on) based on the algorithm described in BIP-0032 (BIP32 from now on) and purpose scheme described in BIP-0043 (BIP43 from now on). This BIP is a particular application of BIP43. ==Motivation== The structure proposed in this document allows for standard ways to create, use, import, and store HDPM wallets. It allows to handle multiple parties sharing an m-of-n wallet, on the following assumptions: * n parties share an m-of-n wallet. * Each party generates their master private keys independently. * Multisig P2SH is used for all addresses. * BIP32 is used to derive public keys, then create a multisig script, and the corresponding P2SH address for that script. * Address generation should not require communication between parties. (Thus, all parties must be able to generate all public keys) * Transaction creation and signing requires communication between parties. This BIP will allow interoperability between various HDPM wallet implementations. ==Specification== We define the following levels in BIP32 path: <code> m / purpose' / cosigner_index / change / address_index </code> Apostrophe in the path indicates that BIP32 hardened derivation is used. Each level has special meaning described in the chapters below. ===Purpose=== Purpose is a constant set to 45, following the BIP43 recommendation. It indicates that the subtree of this node is used according to this specification. <code> m / 45' / * </code> Hardened derivation is used at this level. ===Cosigner Index=== The index of the party creating a P2SH multisig address. The indices can be determined independently by lexicographically sorting the purpose public keys of each cosigner. Each cosigner creates addresses on its own branch, even though they have independent extended master public key, as explained in the "Address generation" section. Note that the master public key is not shared amongst the cosigners. Only the hardened purpose extended public key is shared, and this is what is used to derive child extended public keys. Software should only use indices corresponding to each of the N cosigners sequentially. For example, for a 2-of-3 HDPM wallet, having the following purpose public keys: <pre> 03a473275a750a20b7b71ebeadfec83130c014da4b53f1c4743fcf342af6589a38 039863fb5f07b667d9b1ca68773c6e6cdbcac0088ffba9af46f6f6acd153d44463 03f76588e06c0d688617ef365d1e58a7f1aa84daa3801380b1e7f12acc9a69cd13 </pre> it should use `m / 45 ' / 0 / *` for `039863fb5f07b667d9b1ca68773c6e6cdbcac0088ffba9af46f6f6acd153d44463`, `m / 45 ' / 1 / *` for `03a473275a750a20b7b71ebeadfec83130c014da4b53f1c4743fcf342af6589a38`, and `m / 45 ' / 2 / *` for `03f76588e06c0d688617ef365d1e58a7f1aa84daa3801380b1e7f12acc9a69cd13`, as dictated by their lexicographical order. Software needs to discover all used indexes when importing the seed from an external source. Such algorithm is described in "Address discovery" chapter. Non-hardened derivation is used at this level. ===Change=== Constant 0 is used for external chain and constant 1 for internal chain (also known as change addresses). External chain is used for addresses that are meant to be visible outside of the wallet (e.g. for receiving payments). Internal chain is used for addresses which are not meant to be visible outside of the wallet and is used for return transaction change. For example, if cosigner 2 wants to generate a change address, he would use `m / 45 ' / 2 / 1 / *`, and `m / 45 ' / 2 / 0 / *` for a receive address. Non-hardened derivation is used at this level. ===Address Index=== Addresses are numbered from index 0 in sequentially increasing manner. This number is used as child index in BIP32 derivation. Non-hardened derivation is used at this level. ===HDPM Wallet High-level Description=== Each party generates their own extended master keypair and shares the extended purpose' public key with the others, which is stored encrypted. Each party can generate any of the other's derived public keys, but only his own private keys. ===Address Generation Procedure=== When generating an address, each party can independently generate the N needed public keys. They do this by deriving the public key in each of the different trees, but using the same path. They can then generate the multisig script (by lexicographically sorting the public keys) and the corresponding p2sh address. In this way, each path corresponds to an address, but the public keys for that address come from different trees. ====Receive address case==== Each cosigner generates addresses only on his own branch. One of the n cosigners wants to receive a payment, and the others are offline. He knows the last used index in his own branch, because only he generates addresses there. Thus, he can generate the public keys for all of the others using the next index, and calculate the needed script for the address. Example: Cosigner #2 wants to receive a payment to the shared wallet. His last used index on his own branch is 4. Then, the path for the next receive address is `m/45'/2/0/5`. He uses this same path in all of the cosigners trees to generate a public key for each one, and from that he gets the new p2sh address. ====Change address case==== Again, each cosigner generates addresses only on his own branch. One of the n cosigners wants to create an outgoing payment, for which he'll need a change address. He generates a new address using the same procedure as above, but using a separate index to track the used change addresses. Example: Cosigner #5 wants to send a payment from the shared wallet, for which he'll need a change address. His last used change index on his own branch is 11. Then, the path for the next change address is `m/45'/5/1/12`. He uses this same path in all of the cosigners trees to generate a public key for each one, and from that he gets the new p2sh address. ===Transaction creation and signing=== When creating a transaction, first one of the parties creates a Transaction Proposal. This is a transaction that spends some output stored in any of the p2sh multisig addresses (corresponding to any of the copayers' branches). This proposal is sent to the other parties, who decide if they want to sign. If they approve the proposal, they can generate their needed private key for that specific address (using the same path that generated the public key in that address, but deriving the private key instead), and sign it. Once the proposal reaches m signatures, any cosigner can broadcast it to the network, becoming final. The specifics of how this proposal is structured, and the protocol to accept or reject it, belong to another BIP, in my opinion. ===Address discovery=== When the master seed is imported from an external source the software should start to discover the addresses in the following manner: # for each cosigner: # derive the cosigner's node (`m / 45' / cosigner_index`) # for both the external and internal chains on this node (`m / 45' / cosigner_index / 0` and `m / 45' / cosigner_index / 1`): # scan addresses of the chain; respect the gap limit described below Please note that the algorithm uses the transaction history, not address balances, so even if the address has 0 coins, the program should continue with discovery. Opposite to BIP44, each cosigner branch needs to be checked, even if the earlier ones don't have transactions ===Address ga…

multisig keys, ah, so 45 is taken

the closer to usual patterns we keep it, the easier it will be to integrate ledger and trezor

I don't think there is any centralization effect related to block size, at least not at the numbers being used now

The least error-prone way I'm going to be able to do this is take a dependency on bitcoinj

/poll "Do you understand EC point math" "Yes" "No" "lolwut"

Open Slack to cast your vote in this Simple Poll Open Slack to cast your vote in this Simple Poll Open Slack to cast your vote in this Simple Poll

it’s just a fancy modulo in the end