bitpay / wallet Goto Github PK

an other attack vector:

• one copayer could send many pubkey he control during the wallet creating.
• this is similar to open the creation link from many devices. it is difficult
  to prevent.

a similar attack would be that a copayer modify the metada by adding info about other copayers, like adding to 'seenBy / rejectedBy' arrays the Ids of copayers that are no them. maybe we can put there signatures, so every copayer can verify them:

seenBy[peeId] = {
timestamp: ,
sig: <signature(privKey, 'seen' + ntxid + timestamp')>,
}

rejectedBy[peeId] = {
timestamp: ,
sig: <signature(privKey, 'rejected' + ntxid + timestamp')>,
}

This could be more elegant fixed with: https://github.com/bitpay/copay/issues/135

First of all, thank you for all of the effort you guys are putting towards this project!

I am interested in utilizing Copay in my own app. Is there a resource for helping developers understand Bitcore / Copay so that it can flourish within the Bitcoin ecosystem?

It may be too early to get answers to some of these questions, but I am going to ask anyway.

At a high level - here are my questions:

1. Is there any resource for installing Copay? What are the requirements? What areas of the code can easily be modified to support different use cases, etc.

2. Do you need access to a bitcoind server? Is there an API that can be used to interact with the Bitcoin Network that is a hosted by a trusted 3rd party (i.e. Bitpay / Blockchain.info / etc)

Thanks in advance!

Don't retry if it's the initial connection (other peer might not be there)

warning: possible EventEmitter memory leak detected. 11 listeners added. Use emitter.setMaxListeners() to increase limit.

and now, with the new setup, I cannot set money.

1. make the address to udpate
2. REMOVE the amount confirmation. The utxos are pulled for creating the TX anyways, and there the comprobation is done.

Structure described here: http://sourceforge.net/p/bitcoin/mailman/message/32148600/

When you:

• receive a payment in an address after it was generated by a peer
• and you are not in the address page

address it not updated on the header.

From Tx proposal:
(Create a Tx that competes with this one) button
- need to use the same UTXOS:
=> Will have a max amount

In the tx list will be show as:
  (competes with) and signing / reject button will need to be adapted
  to make sense with competing tx logic.

. Once utxos become availalbe, it will grab them to create a normal TxProposal.
. It will show at TX proposal as 'unfounded'. Send amount X to (addr) to found it.
(addr) is a wallet's p2sh addr.
. In can be rejected by peers before been founded. (same logic as normal txProposals)

As @ryanxcharles said:

trying to measure the security of the peerjs IDs vs. the 256 bit private keys of bitcoin:

>>> 2**256
115792089237316195423570985008687907853269984665640564039457584007913129639936L
>>> 36**len("23hy8uy7qwitr23")
221073919720733357899776L

i think we should use longer IDs than those peerjs IDs

Right now we have this line of code in index.html:

<link href='http://fonts.googleapis.com/css?family=Ubuntu:300,400,700,700italic' rel='stylesheet' type='text/css'>

We should make sure our app has all fonts, CSS, and whatnot locally so that we're using any content from third party servers.

bitpay/bitcore#240

• inexistent peerId

PeerSignedInfo
.info
.signature

• Not mergeable
• Not relayable
• Yes storable

=> i.e. it can only be downloaded from the source peer.

info can have
.nickname
.seen=[ntxids]
.reject=[ntxids]
.sign=[ntxids]
.create=[ntxids]
and many more things in the future.

and put online copayers in header.

• #signin 'create' / join wallet can take some time.
• create address
• sign TX. /
  • open wallet
  • connecting to wallet.

It is testing an old version of copay.

Install copay in github pages for testnet

after signing / reject a tx.

Make sure copay works in chrome mobile + firefox mobile
(layer + features)

• Copayer's backup can be downloaded with a one-time
  use wallet that already have txProposals in it.
• These unfounded txProposals wont even have the
  p2sh address (no pubkeys yet), but they will generete
  them once the wallet have the pubkeys.
• In order to the peers to find themself, a date/time meeting
  can be scheduled and saved on the wallet, as a message. If once of
  the participants is non-human, the copay can be always open to
  facilitate the pubkey gathering. That is already implemented on
  copay.
• some kind of simple scripting could be made to implement that.
  • tx1=create tx with params:
  • if tx1 is rejected: tx2=(); message:()

=> so a user can download the new onetime wallet,
and follow the onscreen steps to do a decentralized
complex financial transaction.

@ryanxcharles knows what this is about