Re: [Bitcoin-development] Bitcoin addresses -- opaque or not

2013-06-22 Thread Melvin Carvalho
On 11 June 2013 17:29, Luke-Jr l...@dashjr.org wrote:

 On Tuesday, June 11, 2013 1:11:33 PM Melvin Carvalho wrote:
  For the sake of argument let's say that opaque means that you can tell
  nothing about the address by examining the characters.

 This is true or false based on CONTEXT.

 Obviously, an implementation of transaction handling (eg, wallets) needs
 to be
 able to translate addresses to and from what they represent.

 On the other hand, things like URI handlers do not (and should not) try to
 interpret the address as anything other than an arbitrary word (\w+).


Luke, if you think that the sole purpose of a URI scheme is to be used as a
URI handler, I think you've not fully understood the concept.  URIs are the
global variable of the internet, and as such the need to play nicely with
all other URI schemes on the net.  They need to be able to be linked to, to
be defined and documented.  This is important for bitcoin to get right
because bitcoin: needs to treated in a special way on the internet, I just
saw today that it was treated by some software as a relative URL, which is
going to break a ton of stuff.



  My understanding was that they are NOT opaque, and that if that has
  changed, it will invalidate much at least some wiki page, for examples at
  least some of the following would now be false:

 The wiki goes into much detail on how addresses work, which is not the
 concern
 of most software in the Bitcoin ecosystem, but may be of interest to humans
 and developers working on the one component that operates the black box
 that
 addresses are.

  
  snip
  

 These aren't FALSE, they are true at the moment, but subject to revision
 by
 newer standards.

  I also here that there is a LIKELY change from the base58 encoding ...
 when
  was this established?

 I stated (on IRC) that it was likely Bitcoin would change from the base58
 encoding for addresses ... at some unspecified time in the future, to some
 unspecified new encoding that addressed known limitations of base58. What
 those changes will be, or when, are not all established at this time. The
 only
 currently-planned change to addresses (very loosely defined) is inclusion
 of
 the Payment Protocol URIs. But the point is that software developers
 shouldn't
 assume that addresses will remain base58 forever.


I am opposed to address changes in general, until he wider implications are
fully understood.



 Luke

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Proposal: Vote on the blocksize limit with proof-of-stake voting

2013-06-22 Thread Melvin Carvalho
On 10 June 2013 06:09, John Dillon john.dillon...@googlemail.com wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 It has been suggested that we leave the decision of what the blocksize to
 be
 entirely up to miners. However this leaves a parameter that affects every
 Bitcoin participant in the control of a small minority. Of course we can
 not
 force miners to increase the blocksize if they choose to decrease it,
 because
 the contents of the blocks they make are their decision and their decision
 only. However proposals to leave the maximum size unlimited to allow
 miners to
 force us to accept arbitrarily large blocks even if the will of the
 majority of
 Bitcoin participants is that they wish to remain able to validate the
 blockchain.

 What we need is a way to balance this asymetrical power relationship.

 Proof-of-stake voting gives us a way of achieving that balance.
 Essentially for
 a miner to prove that the majority will of the poeple is to accept a larger
 blocksize they must prove that the majority has in fact voted for that
 increase. The upper limit on the blocksize is then determined by the
 median of
 all votes, where each txout in the UTXO set is one vote, weighted by txout
 value. A txout without a corresponding vote is considered to be a vote for
 the
 status quo. To allow the voting process to continue even if coins are
 lost
 votes, including default votes, are weighted inversely according to their
 age
 in years after 1 year. IE a vote with weight 1BTC that is 1.5 years old
 will be
 recorded the same as a 1 year old vote weighted as 0.67BTC, and a 1 day
 old
 and 6 months old UTXO are treated equivalently. The 1 year minimum is
 simply to
 make voting required no more than once per year. (of course, a real
 implementation should do all of these figures by block height, IE after
 52,560
 blocks instead of after 1 year)

 A vote will consist of a txout with a scriptPubKey of the following form:

 OP_RETURN magic vote_id txid vout vote scriptSig

 Where scriptSig is a valid signature for a transaction with nLockTime
 500,000,000-1 spending txid:vout to scriptPubKey:

 OP_HASH160 H(OP_RETURN magic vote_id txid vout vote) OP_EQUAL

 vote_id is the ID of the specific vote being made, and magic is included to
 allow UTXO proof implementations a as yet unspecified way of identifying
 votes
 and including the weighted median as part of the UTXO tree sums. (it also
 allows SPV clients to verify the vote if the UTXO set is a Patricia tree of
 scriptPubKeys) vote is just the numerical vote itself. The vote must
 compute
 the median, rather than the mean, so as to not allow someone to skew the
 vote
 by simply setting their value extremely high. Someone who still remembers
 their
 statistics classes should chime in on the right way to compute a median in
 a
 merkle-sum-tree.

 The slightly unusual construction of votes makes implementation by wallet
 software as simple as possible within existing code-paths. Votes could
 still be
 constructed even in wallets lacking specific voting capability provided the
 wallet software does have the ability to set nLockTime.

 Of course in the future the voting mechanism can be used for additional
 votes
 with an additional vote_id. For instance the Bitcoin community could vote
 to
 increase the inflation subsidy, another example of a situation where the
 wishes
 of miners may conflict with the wishes of the broader community.

 Users may of course actually create these specially encoded txouts
 themselves
 and get them into the blockchain.  However doing so is not needed as a
 given
 vote is only required to actually be in the chain by a miner wishing to
 increase the blocksize. Thus we should extend the P2P protocol with a
 mechanism
 by which votes can be broadcast independently of transactions. To prevent
 DoS
 attacks only votes with known vote_id's will be accepted, and only for
 txid:vout's already in the blockchain, and a record of txouts for whom
 votes
 have already broadcast will be kept. (this record need not be
 authoritative as
 its purpose is only to prevent DoS attacks) Miners wishing to increase the
 blocksize can record these votes and include them in the blocks they mine
 as
 required. To reduce the cost of including votes in blocks 5% of every block
 should be assigned to voting only. (this can be implemented by a soft-fork)

 For any given block actual limit in effect is then the rolling median of
 the
 blocks in the last year. At the beginning of every year the value
 considered to
 be the status quo resets to the mean of the limit at the beginning and end
 of
 the interval.  (again, by year we really mean 52,560 blocks) The rolling
 median and periodic reset process ensures that the limit changes gradually
 and
 is not influenced by temporary events such as hacks to large exchanges or
 malicious wallet software.  The rolling median also ensures that for a
 miner
 the act of including a vote is never wasted due to the 

[Bitcoin-development] bitcoind and C++ namespaces?

2013-06-22 Thread Jeff Garzik
Slowly warming to C++ namespaces.  How about starting small, and
wrapping most stuff inside a bitcoin namespace?  Bike shedding can be
done at any point; the main idea is to start small, and gain
experience.

-- 
Jeff Garzik
Senior Software Engineer and open source evangelist
BitPay, Inc.  https://bitpay.com/

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development