Re: [Bitcoin-development] About watch-only addresses

2014-10-18 Thread Flavien Charlon
Also, I was wondering if there were nightly builds I could try this from?

On Fri, Oct 17, 2014 at 9:36 PM, Flavien Charlon 
flavien.char...@coinprism.com wrote:

 Hi,

 What is the status of watch-only addresses in Bitcoin Core? Is it merged
 in master and usable? Is there documentation on how to add a watch-only
 address through RPC.

 Also, I believe that is going towards the 0.10 release, is there a
 rough ETA for a release candidate?

 Thanks
 Flavien

--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] About watch-only addresses

2014-10-18 Thread Wladimir
On Fri, Oct 17, 2014 at 10:36 PM, Flavien Charlon
flavien.char...@coinprism.com wrote:
 Hi,

 What is the status of watch-only addresses in Bitcoin Core? Is it merged in
 master and usable? Is there documentation on how to add a watch-only address
 through RPC.

It has been merged. There is the importaddress RPC call, which works
the same as importprivkey except that you a pass it an address.

 Also, I believe that is going towards the 0.10 release, is there a rough ETA
 for a release candidate?

Yes - aim is in a few months, probably by the end of the year.

AFAIK there are no nightly builds at this moment. Warren Togami was
building them for a while (at http://nightly.bitcoin.it/) but he
stopped some time around June.

It's not recommended to use master without at least a little bit of
development/debugging experience of yourself (to trace down problems
when they appear), so it's best to build it yourself if you're going
to test day-to-day development versions.

Wladimir

--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Proposal for extra nonce in block header

2014-10-18 Thread Timo Hanke
Greg,

I'd like to ask you to assign a BIP number to this proposal and open
another round of discussion.

There is now a reference implementation available as pull request #5102
(https://github.com/bitcoin/bitcoin/pull/5102).

It introduces a new version number (3) to properly distinguish the
interpretation of the version number and allow for a clean upgrade
process.

Unittests are included.

The updated BIP draft in .mediawiki format is available here:
https://github.com/BlockheaderNonce2/bitoin/wiki

Thanks,
Timo

On Sun, May 04, 2014 at 05:26:06PM +0200, Mike Hearn wrote:
 Although I agree 32 bits for a version is overkill, I really don't like the
 idea of you simply ignoring the protocol spec to try and reduce your own 
 costs.
 Especially because in future we should make unknown versions a validation 
 rule,
 so we can easily trigger hard forks.
 
 If this change was introduced through a proper process and software was
 properly upgraded to understand the new header format, that'd be one thing.
 Arbitrarily exploiting what is IMHO a missing rule in the rule set to shave a
 bit more profit is something else.
 
 
 On Sun, May 4, 2014 at 5:14 PM, Timo Hanke timo.ha...@web.de wrote:
 
  If changing the structure of the block header, wouldnt you also need to
  increment the version number to 3?
 
 No, in this case I don't think so. Incrementing the version number has
 two purposes:
 
 1. inform old clients that something new is going on
 2. be able to phase out old version numbers and block them once the new
 version number becomes a supermajority.
 
 None of these two is necessary here. Old clients already recognize the
 new block headers as something new because they look like very high
 version numbers to them. And there is no reason to ever phase out blocks
 that have zero in the MSBs of the version.
 
 On Sun, Apr 27, 2014 at 10:17:11AM +0200, Melvin Carvalho wrote:
  On 27 April 2014 09:07, Timo Hanke timo.ha...@web.de wrote:
 
      I'd like to put the following draft of a BIP up for discussion.
 
      Timo
 
      # Abstract
      There are incentives for miners to find cheap, non-standard ways to
      generate new work, which are not necessarily in the best interest of
 the
      protocol.
      In order to reduce these incentives this proposal re-assigns 2 bytes
 from
      the version field of the block header to a new extra nonce field.
      # Copyright
      # Specification
      The block version number field in the block header is reduced in 
 size
 from
      4 to 2 bytes.
      The third and fourth byte in the block header are assigned to the 
 new
 extra
      nonce field inside the block header.
      # Motivation
      The motivation of this proposal is to provide miners with a cheap
      constant-complexity method to create new work that does not require
      altering the transaction tree.
 
      Furthermore, the motivation is to protect the version and timestamp
 fields
      in the block header from abuse.
      # Rationale
      Traditionally, the extra nonce is part of the coinbase field of the
      generation transaction, which is always the very first transaction 
 of
 a
      block.
      After incrementing the extra nonce the minimum amount of work a 
 miner
 has
      to do to re-calculate the block header is a) to hash the coinbase
      transaction and b) to re-calculate the left-most branch of the 
 merkle
 tree
      all the way to the merkle root.
      This is necessary overhead a miner has to do besides hashing the
 block
      header itself.
      We shall call the process that leads to a new block header from the
 same
      transaction set the _pre-hashing_.
 
      First it should be noted that the relative cost of pre-hashing in 
 its
      traditional form depends
      on the block size, which may create an unwanted incentive for miners
      to keep the block size small. However, this is not the main
 motivation for
      the current proposal.
 
      While the block header is hashed by ASICs, pre-hashing typically
 happens on
      a CPU because of the greater flexibility required.
      Consequently, as ASIC cost per hash performance drops the relative
 cost of
      pre-hashing increases.
 
      This creates an incentive for miners to find cheaper ways to create
 new
      work than by means of pre-hashing.
      An example of this currently happening is the on-device rolling of
 the
      timestamp into the future.
      These ways of creating new work are unlikely to be in the best
 interest of
      the protocol.
      For example, rolling the timestamp faster than the real time is
 unwanted
      (more so on 

Re: [Bitcoin-development] About watch-only addresses

2014-10-18 Thread Felipe Micaroni Lalli
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

This feature makes possible Bitcoin Core to read a balance of any
public address via RPC call or, after importing the balance, it became
available only via QT interface?

On 18-10-2014 07:13, Wladimir wrote:
 On Fri, Oct 17, 2014 at 10:36 PM, Flavien Charlon 
 flavien.char...@coinprism.com wrote:
 Hi,
 
 What is the status of watch-only addresses in Bitcoin Core? Is it
 merged in master and usable? Is there documentation on how to add
 a watch-only address through RPC.
 
 It has been merged. There is the importaddress RPC call, which
 works the same as importprivkey except that you a pass it an
 address.
 
 Also, I believe that is going towards the 0.10 release, is there
 a rough ETA for a release candidate?
 
 Yes - aim is in a few months, probably by the end of the year.
 
 AFAIK there are no nightly builds at this moment. Warren Togami
 was building them for a while (at http://nightly.bitcoin.it/) but
 he stopped some time around June.
 
 It's not recommended to use master without at least a little bit
 of development/debugging experience of yourself (to trace down
 problems when they appear), so it's best to build it yourself if
 you're going to test day-to-day development versions.
 
 Wladimir
 
 --

 
Comprehensive Server Monitoring with Site24x7.
 Monitor 10 servers for $9/Month. Get alerted through email, SMS,
 voice calls or mobile push notifications. Take corrective actions
 from your mobile device. http://p.sf.net/sfu/Zoho 
 ___ Bitcoin-development
 mailing list Bitcoin-development@lists.sourceforge.net 
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development
 

- -- 
Felipe Micaroni Lalli

Walltime: https://walltime.info
Bitcoin Paranoid Android developer
PGP ID: 0x4c0afccfed5cde14
BTC: 1LipeR1AjHL6gwE7WQECW4a2H4tuqm768N

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJUQrS8AAoJEEwK/M/tXN4UcsgQAMKyKFO2EcJ1+Ib08c5dJAft
VGNzf9c7TQtv/wfTWwqfD0QlkZ0jYqgoEJIflYJi7DhqFARQg2nTJIDoKAyDypaH
0x7ckt0G4Fp4Dq9GQAqyJq+5NFTO+S4LpnhzMGDLE6PZNOeoDRYf8GbuzNjCAU6s
huB9OhvXa4XZ2azsFnAhx3CcM98jTcbm0SLctqlTcHr//FMjEJioDFZATutlu8be
/PIhQ6OkfjBSeZv7A4lwgd0vbGJ8ioEkLMmjzYgfeaZG5KxOJXXzX9nDysAw7O3U
jXE/zpm9pFqZ9uhgdG1gzTBoROn49xZmycA82NbTn8/+mLrK7WYFei3Th5V0G1DG
hUI0vEb8g6id+y3w0HWnYqquFZBFOLNfs7ONsKdqvMj+ci2+IavAU7SY51BQcEwm
GW6d24Fd9/zhliEmFzq61xvOj5Rgcj7piGH/qMtGKYececS0tFMxQ4IDH+bkxKhr
lZ00Zk0K4bTCq3cASjP9L9AgV3zmTOUfe9RMtIHTJq79TIDPbBCsz2PrbtAcgWGZ
vb/08asgPC2FZHKOWf1TGiDr34JlBPhNKVKfiDuxbGqLGjlhYrdqkl1CrVqJP7dW
dxvEkwittodLc5MnVdS7QIHfjXJ/UEbyINIe7zrX/7w3pf0aLAX0KaxpDpfBessD
Nf2y99ZocpddQu0/EDJl
=Ctf/
-END PGP SIGNATURE-

--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development