Re: [Bitcoin-development] BIP 0021 idea: sendmany

2013-05-22 Thread Wladimir
Do you have a specific use case in mind?

Maybe - if you have a percentage slider like with humble bundles you can
make it more explicit what part went where?

In any case, if you're really interested in this you need to write a new
BIP that extends 21. Any syntax will do does not help in implementation
:-)

Wladimir
Multiple recipients/amounts. Any syntax you like. Thanks!

--
Try New Relic Now  We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app,  servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
Try New Relic Now  We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app,  servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] UUID to identify chains (payment protocol and elsewhere)

2013-05-22 Thread Melvin Carvalho
On 21 May 2013 01:59, Mark Friedenbach m...@monetize.io wrote:

 At the developer round-table it was asked if the payment protocol would
 alt-chains, and Gavin noted that it has a UTF-8 encoded string
 identifying the network (main or test). As someone with two
 proposals in the works which also require chain/coin identification (one
 for merged mining, one for colored coins), I am opinionated on this. I
 believe that we need a standard mechanism for identifying chains, and
 one which avoids the trap of maintaining a standard registry of
 string-to-chain mappings.

 Any chain can be uniquely identified by its genesis block, 122 random
 bits is more than sufficient for uniquely tagging chains/colored assets,
 and the low-order 16-bytes of the block's hash are effectively random.
 With these facts in mind, I propose that we identify chains by UUID.

 So as to remain reasonably compliant with RFC 4122, I recommend that we
 use Version 4 (random) UUIDs, with the random bits extracted from the
 double-SHA256 hash of the genesis block of the chain. (For colored
 coins, the colored coin definition transaction would be used instead,
 but I will address that in a separate proposal and will say just one
 thing about it: adopting this method for identifying chains/coins will
 greatly assist in adopting the payment protocol to colored coins.)

 The following Python code illustrates how to construct the chain
 identifier from the serialized genesis block:

  from hashlib import sha256
  from uuid import UUID
  def chain_uuid(serialized_genesis_block):
  h = sha256(serialized_genesis_block).digest()
  h = sha256(h).digest()
  h = h[:16]
  h = ''.join([
  h[:6],
  chr(0x40 | ord(h[6])  0x0f),
  h[7],
  chr(0x80 | ord(h[8])  0x3f),
  h[9:]
  ])
  return UUID(bytes=h)

 And some example chain identifiers:

  mainnet:  UUID('6fe28c0a-b6f1-4372-81a6-a246ae63f74f')
  testnet3: UUID('43497fd7-f826-4571-88f4-a30fd9cec3ae')
  namecoin: UUID('70c7a9f0-a2fb-4d48-a635-a70d5b157c80')

 As for encoding the chain identifier, the simplest method is to give
 network the bytes type, but defining a UUID message type is also
 possible. In either case bitcoin mainnet would be the default, so the
 extra 12 bytes (vs: main or test) would only be an issue for
 alt-chains or colored coins.


This is essentially name spacing.  As registries grow namespaces become
more important.  In bitcoin's quest for decentrality there's also the
question of who maintains the registry.

Some out of band algo/hash could work so long as there was a one to one
relationship between the described object and the UUID.  In this case the
gensis block may not uniquely identify a coin.

The normal way to namespace a registry on the internet is to allow it to be
a URI.  In this case an http style uri has the added bonus side effect that
it can be dereferencable and both human and machine readable.  So yes
something like org.bitcoin.* is good, just simply growing things to http
style uris is cleaner, imho



 Kind regards,
 Mark Friedenbach


 --
 Try New Relic Now  We'll Send You this Cool Shirt
 New Relic is the only SaaS-based application performance monitoring service
 that delivers powerful full stack analytics. Optimize and monitor your
 browser, app,  servers with just a few lines of code. Try New Relic
 and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
Try New Relic Now  We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app,  servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] UUID to identify chains (payment protocol and elsewhere)

2013-05-22 Thread Jeff Garzik
On Wed, May 22, 2013 at 6:27 AM, Melvin Carvalho
melvincarva...@gmail.com wrote:
 Some out of band algo/hash could work so long as there was a one to one
 relationship between the described object and the UUID.  In this case the
 gensis block may not uniquely identify a coin.

What does this mean?  It seems extremely unlikely that two different
genesis blocks will have the same hash.

-- 
Jeff Garzik
exMULTI, Inc.
jgar...@exmulti.com

--
Try New Relic Now  We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app,  servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] UUID to identify chains (payment protocol and elsewhere)

2013-05-22 Thread Melvin Carvalho
On 22 May 2013 16:07, Jeff Garzik jgar...@exmulti.com wrote:

 On Wed, May 22, 2013 at 6:27 AM, Melvin Carvalho
 melvincarva...@gmail.com wrote:
  Some out of band algo/hash could work so long as there was a one to one
  relationship between the described object and the UUID.  In this case the
  gensis block may not uniquely identify a coin.

 What does this mean?  It seems extremely unlikely that two different
 genesis blocks will have the same hash.


Two coin ecosystems could have the same genesis block



 --
 Jeff Garzik
 exMULTI, Inc.
 jgar...@exmulti.com

--
Try New Relic Now  We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app,  servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] UUID to identify chains (payment protocol and elsewhere)

2013-05-22 Thread Jeff Garzik
On Wed, May 22, 2013 at 10:12 AM, Melvin Carvalho
melvincarva...@gmail.com wrote:
 On 22 May 2013 16:07, Jeff Garzik jgar...@exmulti.com wrote:

 On Wed, May 22, 2013 at 6:27 AM, Melvin Carvalho
 melvincarva...@gmail.com wrote:
  Some out of band algo/hash could work so long as there was a one to one
  relationship between the described object and the UUID.  In this case
  the
  gensis block may not uniquely identify a coin.

 What does this mean?  It seems extremely unlikely that two different
 genesis blocks will have the same hash.


 Two coin ecosystems could have the same genesis block

That has really, really bad side effects.  The whole point of the
bitcoin consensus algorithm is to avoid situations like this.

We don't want to encourage that behavior with code.

-- 
Jeff Garzik
exMULTI, Inc.
jgar...@exmulti.com

--
Try New Relic Now  We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app,  servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] UUID to identify chains (payment protocol and elsewhere)

2013-05-22 Thread Luke-Jr
On Wednesday, May 22, 2013 2:20:22 PM Jeff Garzik wrote:
 On Wed, May 22, 2013 at 10:12 AM, Melvin Carvalho
 
 melvincarva...@gmail.com wrote:
  On 22 May 2013 16:07, Jeff Garzik jgar...@exmulti.com wrote:
  On Wed, May 22, 2013 at 6:27 AM, Melvin Carvalho
  
  melvincarva...@gmail.com wrote:
   Some out of band algo/hash could work so long as there was a one to
   one relationship between the described object and the UUID.  In this
   case the
   gensis block may not uniquely identify a coin.
  
  What does this mean?  It seems extremely unlikely that two different
  genesis blocks will have the same hash.
  
  Two coin ecosystems could have the same genesis block
 
 That has really, really bad side effects.  The whole point of the
 bitcoin consensus algorithm is to avoid situations like this.
 
 We don't want to encourage that behavior with code.

In some cases, multiple currencies can use the same blockchain (not just the 
singular genesis block). This use case *is* something we want to encourage - 
no reason for people to make an entirely new blockchain if their altcoin fits 
within the scope of Bitcoin or another existing altchain.

--
Try New Relic Now  We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app,  servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] UUID to identify chains (payment protocol and elsewhere)

2013-05-22 Thread Jeff Garzik
On Wed, May 22, 2013 at 10:29 AM, Luke-Jr l...@dashjr.org wrote:
 In some cases, multiple currencies can use the same blockchain (not just the
 singular genesis block). This use case *is* something we want to encourage -
 no reason for people to make an entirely new blockchain if their altcoin fits
 within the scope of Bitcoin or another existing altchain.

OK, let me qualify.  Layers on top are one thing, but we really do not
want to support cases like the fork that leaves the genesis block
intact, and leaves the subsidy at 50.0 BTC forever.

-- 
Jeff Garzik
exMULTI, Inc.
jgar...@exmulti.com

--
Try New Relic Now  We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app,  servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] UUID to identify chains (payment protocol and elsewhere)

2013-05-22 Thread Gavin Andresen
Getting back to the original proposal:

RE: uuid instead of main / test in the payment protocol:

I vote no.

The payment protocol will become at least 3 BIPs:

1) Protocol messages (current gist, essentially)
2) MIME type
3) bitcoin: URI extension

An alt coin will need its own version of (2) and (3), so when you
click on a foocoin: link a foocoin-specific MIME type is fetched and
foocoin.exe is launched to handle the request.

... or a specific MIME type is fetched and delivered to the
HandlesLotsOfCoins application (... and it knows what MIME type it is
getting, so can Do the Right Thing).

If a payment request is delivered via HTTP or email, it will be
bundled up in an envelope of some sort with the MIME type attached.

So, after further thought, I've changed my mind: which coin would be
encoded in the MIME type.  Which chain for that coin would be encoded
in PaymentDetails.network.

-- 
--
Gavin Andresen
Chief Scientist, Bitcoin Foundation
https://www.bitcoinfoundation.org/

--
Try New Relic Now  We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app,  servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] BIP 0021 idea: sendmany

2013-05-22 Thread shaker521
You can pull use cases out of thin air. Humble Bundle is a perfect example.

BIP 0001 instructed me to introduce the idea here before performing the labor 
of writing a new BIP. If others reply in support then the labor will be 
justified.

The intended purpose is to give users the simplest way to perform a transaction 
with multiple outputs. Ideal would be to provide a single URI (or QR code or 
what have you) that specifies all of the outputs (address:amount pairs) and 
minimizes opportunities for user error, e.g. by omitting or altering an output. 
I'll take you through the process that brought me to the solution below.

The main part of the current bitcoin URI scheme is a single bitcoinaddress. If 
the sendmany scheme left this foundation unchanged there will be difficulty 
with both semantics and backwards compatibility.

Contemplate some use cases for sendmany URIs. Are each of the outputs in a 
given transaction equally important? In other words, are all outputs necessary 
to fulfill the terms of the exchange between the parties? I would say so.

Not that the bitcoin client should forbid changing the outputs after processing 
the URI, but that it should reject the entire URI if the client does not 
support the multi-output syntax.

The discussion of backward compatibility in BIP 0021 recommends against 
reqparams being used in a mission-critical way while users upgrade their 
clients. A reqparams approach would permit the gravest possible error, i.e. an 
older client silently discarding all but the first address and allowing the 
user unwittingly to violate the terms of the exchange AND irreversibly send 
some BTC to a possibly adversarial party. We must guard against this 
potentially devastating failure mode.

After a study of pchar and other BNF terms (http://www.w3.org/TR/hdml20-8.html) 
I propose the following format with optional labels and amounts:

bitcoin:label/address:amount;label/address:amount?params

Before arriving at this format I tried and rejected these other output formats:
address/label:amount (ambiguous since : and amount are allowed in label's 
*pchar)
address:amount/label (less readable since the label is split from its referent)

The proposed format keeps labels and addresses together for human readability. 
The label delimiter / is a reserved character which eliminates ambiguous 
cases, making this format easy for bitcoin clients to parse.

Therefore I propose the following grammar:

bitcoinurn = bitcoin: outputs [ ? bitcoinparams ]
outputs= output *[ ; output ] | bitcoinaddress
output = [ label / ] bitcoinaddress [ : amount ]
bitcoinaddress = base58 *base58
amount = *digit [ . *digit ]
bitcoinparams  = bitcoinparam *[  bitcoinparam ]
bitcoinparam   = amountparam | labelparam | messageparam | otherparam | reqparam
amountparam= amount= amount
labelparam = label= label
label  = *pchar
messageparam   = message= *pchar
otherparam = pchar *pchar = *pchar
reqparam   = req- pchar *pchar = *pchar

This may be added under Simpler syntax:

bitcoin:address[:amount][/label][;address[:amount][/label]][?message=message]

As well as these examples:

bitcoin:Bitcoin+Foundation/1BTCorgHwCg6u2YSAWKgS17qUad6kHmtQW

bitcoin:eBook+Store/175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W:0.1;Bob+Author/1F4JfsqiDTG7vjnsz5daUrz2yexQGXB8uo:1.9?message=Purchased+eBook:+Bobgraphy

Brief testing with MultiBit shows that the URIs above are fully rejected by the 
client. This is the desired behavior for clients lacking support for 
multiple-output URIs. Thus we guard against the devastating failure mode 
outlined above.

Do you appreciate my work? Send a tip:
1F4JfsqiDTG7vjnsz5daUrz2yexQGXB8uo


--
Try New Relic Now  We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app,  servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] BIP 0021 idea: sendmany

2013-05-22 Thread shaker521
bitcoin:address[:amount][/label][;address[:amount][/labe
l]][?message=message]

Correction:
bitcoin:[label/]address[:amount][;[label/]address[:amount]][?message=message]


--
Try New Relic Now  We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app,  servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development