Re: [Bitcoin-development] BIP0032

2013-05-27 Thread Amir Taaki
Yeah, I tried implementing it based on the document there and the code that is 
available in sipa's repo on GitHub but it's not enough. I'm waiting until there 
is an implementation of this concept before moving on it.




 From: Michael Gronager grona...@ceptacle.com
To: bitcoin-development@lists.sourceforge.net 
Sent: Monday, May 27, 2013 2:39 PM
Subject: Re: [Bitcoin-development] BIP0032
 

Which again means that the statement regarding Audits through the Master
Public key, M, is wrong - only incoming and outgoing transaction of
_publicly_ derived wallets will be part of the audit... Privately
derived wallets cannot be obtained, though you could, without loss of
security, share also the addition points from privately derived wallets:
(m/i')*G, but there is no concept of a single public master key.

==
Audits: M
In case an auditor needs full access to the list of incoming and
outgoing payments, one can share the master public extended key. This
will allow the auditor to see all transactions from and to the wallet,
in all accounts, but not a single secret key.
==



--
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


[Bitcoin-development] message dissemination

2013-01-14 Thread Amir Taaki
cool paper: 
http://phys.org/news/2013-01-algorithm-message-dissemination-decentralized-networks.html#jCp


--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122412
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] BIP 32 HD wallets, accounts should be labels not numbers

2012-12-03 Thread Amir Taaki
Can this be amended? I think it makes much more sense to allow people to input 
labels not numbers at this level.

General category names for different accounts is much more human than numbers, 
and you can still use incrementing numbers if you prefer.


--
Keep yourself connected to Go Parallel: 
BUILD Helping you discover the best ways to construct your parallel projects.
http://goparallel.sourceforge.net
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] BIP 32 HD wallets, accounts should be labels not numbers

2012-12-03 Thread Amir Taaki
ok, also what is the reasoning behind serialising points using a compressed 
format before going into the hash function? I'm looking at the sec1-v2.pdf and 
the compression format is a little confusing.

I think the octet string for X is 32 bytes (using q = curve.order) and 
secp256k1 is a prime field so we follow step 2.2.1



From: Pieter Wuille pieter.wui...@gmail.com
To: Amir Taaki zgen...@yahoo.com 
Cc: bitcoin-development@lists.sourceforge.net 
bitcoin-development@lists.sourceforge.net 
Sent: Monday, December 3, 2012 2:54 PM
Subject: Re: [Bitcoin-development] BIP 32 HD wallets, accounts should be labels 
not numbers




On Mon, Dec 3, 2012 at 2:49 PM, Amir Taaki zgen...@yahoo.com wrote:

Can this be amended? I think it makes much more sense to allow people to input 
labels not numbers at this level.

General category names for different accounts is much more human than numbers, 
and you can still use incrementing numbers if you prefer.


There is no way to iterate over all strings. The intention is that a wallet 
application can detect a new account that becomes in use (e.g. during disaster 
recovery), so the accounts get assigned incrementing numbers.

I wouldn't mind adding the ability to do non-standard derivations using 
arbitrary strings, if this recoverability property is not desired.

-- 
Pieter

--
Keep yourself connected to Go Parallel: 
BUILD Helping you discover the best ways to construct your parallel projects.
http://goparallel.sourceforge.net
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] BIP 35: add mempool message

2012-08-16 Thread Amir Taaki
My thoughts:

The extension is simple. It's only really useful for the use-cases listed if 
the majority of nodes implement it. As I view the proposal, it is perfectly 
simple and uncomplicated. If it's implemented, then I suggest to just increment 
version and make it part of the protocol.

On the flipside it is another notch in complicating an already diffuse 
protocol, but it seems a rather benign offense in that regard compared to other 
changes (past and future).



- Original Message -
From: Pieter Wuille pieter.wui...@gmail.com
To: Jeff Garzik jgar...@exmulti.com
Cc: Bitcoin Development bitcoin-development@lists.sourceforge.net
Sent: Thursday, August 16, 2012 6:56 PM
Subject: Re: [Bitcoin-development] BIP 35: add mempool message

On Thu, Aug 16, 2012 at 01:32:04PM -0400, Jeff Garzik wrote:
 Consensus was we should do a BIP for all P2P changes, so here it is...
  feedback requested.
 
 https://en.bitcoin.it/wiki/BIP_0035

I like the idea of being able to query the memory pool of a node; the
implementation is straightforward, which is good. Maybe effectively using the
command can be added? I suppose it is interesting in general for nodes to
get a memory pool refill at startup anyway.

 1) Upon receipt of a mempool message, the node will respond
    with an inv message containing MSG_TX hashes of all the
    transactions in the node's transaction memory pool.
 
    An inv message is always returned, even if empty.

I'm not sure about this last. What is it good for? inv packets can always be
sent, even not in response to others, so it is not that this gives you an
acknowledgement the mempool is updated?

 3) Feature discovery is enabled by checking two version message attributes:
 
    a) Protocol version = 60002
    b) NODE_NETWORK bit set in nServices

This seems safe, although it forces other full implementations that want to
expose protocol version 60002 (or later) to also implement this. What do they
think about this?

I would like to suggest to allocate an extra service bit for this. We still
have 63 left, and this is a well-defined and useful extra service that was
not yet provided by any earlier node. Doing that would also mean that
mempool-providing survices may be discovered before connecting to them, as
the service bits are carried around in addr messages. Any opinions about that?

-- 
Pieter

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] BIP 35: add mempool message

2012-08-16 Thread Amir Taaki
MSG_MEMTX solves the issue of not knowing whether a given inv is in response to 
a mempool command or not.

I don't buy the argument that always sending a response inv makes things 
easier because code should always be able to handle misbehaviour from the 
remote node (ommiting the inv). However I would argue that it is good to have 
it, as it makes designing flows of logic much easier (first send this, wait for 
response, do this, ...).



- Original Message -
From: Stefan Thomas m...@justmoon.de
To: bitcoin-development@lists.sourceforge.net
Cc: 
Sent: Thursday, August 16, 2012 8:21 PM
Subject: Re: [Bitcoin-development] BIP 35: add mempool message

 This seems safe, although it forces other full implementations that want to
 expose protocol version 60002 (or later) to also implement this. What do they
 think about this?

BitcoinJS will implement it, it's a useful feature and there is no
reason not to support it.

Two comments from my end:

- This is just a thought, but I wouldn't mind using a new inv_type for
this, e.g. MSG_MEMTX. I could conceivably see a future where broadcast
and relay txs are stored in a very fast local cache whereas the general
mempool is stored in a slower data structure. By being able to
distinguish incoming getdata requests I can save a few milliseconds by
querying the right storage right away. Might also help with things like
telling apart broadcast/relayed transactions from the response to a
mempool request for purposes like DoS scoring etc.

Not a big deal by any means, but I also don't see a downside to it.
inv_types are not a scarce resource, we have four billion of them available.

For now clients would just treat MSG_TX and MSG_MEMTX interchangeably.

- If a node doesn't have anything in it's mempool it sends back an empty
inv message. This is either ambiguous (if other things also send empty
inv messages in the future) or arbitrary (why should an empty inv be
associated with a mempool request of all things.) Instead why not
respond with an inv message that contains a single element of type
MSG_MEMTX and hash 0. That would a very direct way to indicate that this
response is associated with a mempool request.


I'm not married to either suggestion, just trying to add my perspective.
One thing you notice when reimplementing Bitcoin is that Bitcoin's
protocol leaves out a lot of information not for space reasons, but
because the reference client's implementation doesn't happen to need it.
Sometimes however this locks other clients into doing things the same
way. If we can make the protocol a bit richer, especially if this
doesn't cost any extra bytes, then we should consider it as it might
help some implementation down the road make a neat optimization.


On 8/16/2012 7:56 PM, Pieter Wuille wrote:
 On Thu, Aug 16, 2012 at 01:32:04PM -0400, Jeff Garzik wrote:
 Consensus was we should do a BIP for all P2P changes, so here it is...
  feedback requested.

 https://en.bitcoin.it/wiki/BIP_0035
 I like the idea of being able to query the memory pool of a node; the
 implementation is straightforward, which is good. Maybe effectively using the
 command can be added? I suppose it is interesting in general for nodes to
 get a memory pool refill at startup anyway.

 1) Upon receipt of a mempool message, the node will respond
    with an inv message containing MSG_TX hashes of all the
    transactions in the node's transaction memory pool.

    An inv message is always returned, even if empty.
 I'm not sure about this last. What is it good for? inv packets can always be
 sent, even not in response to others, so it is not that this gives you an
 acknowledgement the mempool is updated?

 3) Feature discovery is enabled by checking two version message attributes:

    a) Protocol version = 60002
    b) NODE_NETWORK bit set in nServices
 This seems safe, although it forces other full implementations that want to
 expose protocol version 60002 (or later) to also implement this. What do they
 think about this?

 I would like to suggest to allocate an extra service bit for this. We still
 have 63 left, and this is a well-defined and useful extra service that was
 not yet provided by any earlier node. Doing that would also mean that
 mempool-providing survices may be discovered before connecting to them, as
 the service bits are carried around in addr messages. Any opinions about that?



--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development



[Bitcoin-development] BIP 22 - getmemorypool

2012-07-30 Thread Amir Taaki
Hi,

luke-jr wants me to split this BIP into 3 separate BIPs because he says that 
other devs felt it was too unfocused and covered too many topics. However this 
discussion took place on IRC, and I never saw any of it to ascertain what 
happened (BIP 1 says drafts should be evaluated on the mailing list).

I think a discussion of BIP 22 perhaps did happen on the mailing list, but I 
don't remember it. Sorry if that's the case.

Anyway before granting the permission to allow this proposal to be pared down, 
and new BIPs granted for the non-core parts of this proposal, I want to know 
what people think. I'm not a miner myself, so I'm prescient of my lack of 
knowledge in the topic.


https://en.bitcoin.it/wiki/BIP_0022

Thanks


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] script tests - invalid script in script_valid.json?

2012-07-29 Thread Amir Taaki
Hi!

Is this a valid script?

[1 0 1, WITHIN NOT]

The first value (1) is tested to make sure it is between the lower (0) and 
upper (1) value. This evaluates to true, placing on the stack a single byte of 
[01]. NOT then inverses this to a 0 byte false value of [].

What am I missing here?

Thanks

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] script tests - invalid script in script_valid.json?

2012-07-29 Thread Amir Taaki
oh, bitcoin...

Thanks justmoon :D



- Original Message -
From: Stefan Thomas m...@justmoon.de
To: bitcoin-development@lists.sourceforge.net
Cc: 
Sent: Sunday, July 29, 2012 1:33 PM
Subject: Re: [Bitcoin-development] script tests - invalid script in 
script_valid.json?

OP_WITHIN is lower-bound-inclusive, but upper bound exclusive, so 1 0 1 WITHIN 
is false.


bool fValue = (bn2 = bn1  bn1  bn3);

https://github.com/bitcoin/bitcoin/blob/master/src/script.cpp#L854

On 7/29/2012 6:31 PM, Amir Taaki wrote:
 Hi!

 Is this a valid script?

 [1 0 1, WITHIN NOT]

 The first value (1) is tested to make sure it is between the lower (0) and 
 upper (1) value. This evaluates to true, placing on the stack a single byte 
 of [01]. NOT then inverses this to a 0 byte false value of [].

 What am I missing here?

 Thanks

 --
 Live Security Virtual Conference
 Exclusive live event will cover all the ways today's security and 
 threat landscape has changed and how IT managers can respond. Discussions 
 will include endpoint security, mobile security and the latest in malware 
 threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development



--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] OP_RESEVERVED and IsPushOnly

2012-07-26 Thread Amir Taaki
Meh, probably harmless, but...

As best I can tell, OP_RESERVED does absolutely nothing (a NOP).

CScript::IsPushOnly(...) counts this as a push operation.


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Merge branch on github

2012-07-21 Thread Amir Taaki
Hey,

https://github.com/bitcoin/bitcoin.org/pull/46

I tried to keep it professional, and non spammy.


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Berlin Hackathon

2012-07-17 Thread Amir Taaki
Video from the event: http://www.youtube.com/watch?v=EQ2rb4pHH1g


The Hackathon is over, thanks for all the participants and sponsors! I 
had loads of fun, and there were lots of great ideas flying around!

Thanks especially to:

- IN-Berlin, for providing the space to hold the hackathon!
- Sponsors: bitstamp.net, bitcoin2012.com and localbitcoins.com
- Room77 (the restaurant at the end of capitalism), for hosting the afterparty 
and the burgers  pampero 
- Jury: yossarian + other people who attended the presentations 

The results - winner first

1. Offline transactions for BitcoinJ/Android bitcoin wallet: Andreas Schildbach 
and grazcoin
- Ability for Android Wallet to do offline transactions
2. Bitcoin Pong: genjix
- Multiplayer pong, where you can win (or lose) bitcoins 
3. acceptbit.com: Jeremias Kangas and Stefan Thomas
- an ultra-safe merchant tool, where you can accept payments without sharing 
your private keys 
4. BitcoinJ Multisig: yellowhat and PK
- way to do multisig transactions for BitcoinJ/Android
5. Double-spend monitor: genjix
- tool to monitor double spends
6. Bitcoin-autosave: Mike Hearn
- BitcoinJ improvements (Mike did also loads of other stuff, and helped with 
winner project too)
7. Live-calculator: genjix
- Tool for btc accepting restaurants
8. Bitcoin mages: genjix
- Strategy game, where you play for bitcoins
9. Embed block message: genjix
- simple tool for embedding messages in block chain

Source code

genjix: https://gitorious.org/bitcoin-hackathon
acceptbit.com: https://github.com/kangasbros/electrumpos
Bitcoin Wallet: https://github.com/livne/Bitcoin-Wallet-for-Android (branch 
hackathon)

Other

Participants, send jeremias your bitcoin addresses please 

The next hackathon will be organized before bitcoin london conference, Wed 12th 
and Thur 13th september, london. 

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] bitcoin.org - remove hackathon

2012-07-17 Thread Amir Taaki
Yes, but then they should not be sponsors.

There's a very good reason why Wikipedia does not have advertisements. That is, 
the fear of advertisers influence on the neutral content. It is inevitably a 
corrupting influence. I want a good fun conference like the hackathon we just 
held.



- Original Message -
From: Andreas Petersson andr...@petersson.at
To: bitcoin-development@lists.sourceforge.net
Cc: 
Sent: Tuesday, July 17, 2012 11:25 AM
Subject: Re: [Bitcoin-development] bitcoin.org - remove hackathon

Am 17.07.2012 11:17, schrieb Amir Taaki:
 Like I really do not wish to sell a speaker slot, but if I have to (to pay 
 the bills) then it will be obvious due to scheduling and disclaimers that 
 speakers are sponsors.


Personally, i really don't mind sponsored speakers. If they have 
somewhat relevant topics they keep the event from becoming a circlejerk.
for example i would really like to hear about payments innovation 
outside bitcoin.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Electrum mailing list

2012-07-17 Thread Amir Taaki
https://lists.sourceforge.net/lists/listinfo/electrum-discuss


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Bitcoin Wallet for Android

2012-07-09 Thread Amir Taaki
Hey,

I just saw this added to the clients page. One of the conditions we set for 
that page was that all the clients must have the entire sourcecode available 
for review, and users should be able to run it from the sourcecode. Is the 
sourcecode for this client available for review? I couldn't find it.

Otherwise, we should make a separate section for non-opensource clients.


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Bitcoin Wallet for Android

2012-07-09 Thread Amir Taaki
OK thanks. I just went and made those sections then saw your posts.

Anyway we have a section for proprietary clients now. Please tell me if 
anything looks disagreeable, http://bitcoin.org/clients.html

One thing I'm going to do is randomise the positioning order within sections 
upon refresh.



- Original Message -
From: m...@henricson.se m...@henricson.se
To: bitcoin-development@lists.sourceforge.net
Cc: 
Sent: Monday, July 9, 2012 11:19 AM
Subject: Re: [Bitcoin-development] Bitcoin Wallet for Android

Sources are available here:

http://code.google.com/p/bitcoin-wallet/

Mats

Quoting Amir Taaki zgen...@yahoo.com:

 Hey,

 I just saw this added to the clients page. One of the conditions we  
 set for that page was that all the clients must have the entire  
 sourcecode available for review, and users should be able to run it  
 from the sourcecode. Is the sourcecode for this client available for  
  review? I couldn't find it.

 Otherwise, we should make a separate section for non-opensource clients.


 --
 Live Security Virtual Conference
 Exclusive live event will cover all the ways today's security and
 threat landscape has changed and how IT managers can respond. Discussions
 will include endpoint security, mobile security and the latest in malware
 threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development




--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Random order for clients page

2012-07-09 Thread Amir Taaki
JS randomisation is bad. People shouldn't need JS to view a webpage.

Only you have a problem with this page. I don't see why Bitcoin-Qt needs to be 
first either when it dominates the front page. It is perfectly fine as it is.

You are not a developer of any alternative clients, and this is a webpage for 
Bitcoin clients. I have made a change to remove a source of disputes, and make 
the process more fair and equal. Your suggestion to remove the clients page is 
your bias towards thinking that there should be only one Bitcoin client that 
everyone uses (the one which you contribute towards).

If you want to suggest removing the clients page, then fine, lets also remove 
all reference to Bitcoin-Qt from the front-page and turn it into a 
http://bittorrent.org/ style website.

Fact is that the other clients are rapidly becoming stable and mature, and the 
ecosystem is diversifying. The argument that the other clients were not up to 
scratch held maybe a few months ago, but not now.



- Original Message -
From: Gregory Maxwell gmaxw...@gmail.com
To: Amir Taaki zgen...@yahoo.com
Cc: bitcoin-development@lists.sourceforge.net 
bitcoin-development@lists.sourceforge.net
Sent: Monday, July 9, 2012 5:04 PM
Subject: Re: [Bitcoin-development] Random order for clients page

On Mon, Jul 9, 2012 at 11:54 AM, Amir Taaki zgen...@yahoo.com wrote:
 Took me a while, but finally got it working.
 Entries on the clients page are randomly ordered when the page is generated.
 https://github.com/bitcoin/bitcoin.org/commit/6850fc8c83494d6ec415ea9d36fb98366373cc03
 We should regenerate the page every 2 days. This gives fair exposure to all 
 the clients listed.

If you had authored this as a pull request rather than making the
change unilaterally I would have recommended leaving it so the
reference client was always first. I also would have suggested that it
use JS randomization instead of jekyll in order to get more even
coverage, though I think thats a more minor point.

Some people were concerned when this page was created that it would
just be a source of useless disputes.  I think its becoming clear that
this is the case. I think the cost of dealing with this page is
starting to exceed the benefit it provides and we should probably
consider removing it.


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Random order for clients page

2012-07-09 Thread Amir Taaki
This page really does matter to alternative clients. If you measure the click 
through statistics, then they are a significant portion of the 
traffic. By removing this page, you are directly stunting Bitcoin's 
growth.

The only thing that's changed between now and this morning is: 

- Addition of Bitcoin Wallet for Android
- Randomisation of entries

I actually got permission from everyone involved before making the page.If you 
want to remove the page, then we should see a vote by:

- laanwj
- gavin
- sipa
- jgarzik
- BlueMatt
- Diapolo
- luke-jr
- you
- jim from multibit
- gary rowe
- ThomasV
- me
- etotheipi
- Andreas Schildbach
- justmoon
- Mike Hearn
You're proposing to remove the page. You know, and I know and I know that you 
know that nobody visits the Wiki. Your proposal is not move to Wiki really 
but remove from bitcoin.org. Keep bitcoin.org for Bitcoin-Qt only which is 
against the stated goals of the rest of your team members (gavin, sipa, 
jgarzik).


Have you tried the new clients? I've tried all 4, and they are all well written.

Try the new version of Electrum, https://gitorious.org/electrum/electrum - it's 
more featureful and secure than Bitcoin-Qt what with deterministic wallets, 
brain-wallets, prioritising addresses, frozen addresses, offline transactions - 
none of which Bitcoin-Qt has.

MultiBit is also very good with QR integration and the ability for merchants to 
quickly set themselves up. It's full of guiding help text, and has this 
paradigm to allow people to work with keys.


Bitcoin Wallet for Android has one of the best bitcoin UIs I've seen and is 
extremely well thought out in how the user navigates through the software.

The Bitcoin network could function perfectly fine with Electrum nodes and 
miners. You would still have miners and we wouldn't have the problem now with 
huge blocks because miners would be economically incentivised to 
keep blocks small. But that's another discussion.

Technically speaking, the randomisation is fine now. It achieves its intended 
effect, as the page is regenerated daily.

This does not need to be a source of arguing. I see no problem with having this 
page be a neutral overview of the main clients (as we all agreed together in 
the beginning):
- Source must be public, and users must be able to run from source.
- Description should be non-spammy and neutral sounding. Cover the negative 
aspects.
Randomisation of the order simply makes that fairer. Alphabetical is not a good 
option (as others have suggested) because it can be gamed.

There is absolutely no reason to remove this page unless you think bitcoin.org 
is only for Bitcoin-Qt which is against the wishes of gavin, sipa, jgarzik, and 
the long-term stated goal of bitcoin.org as a neutral resource for the 
community.



- Original Message -
From: Gregory Maxwell gmaxw...@gmail.com
To: Amir Taaki zgen...@yahoo.com
Cc: bitcoin-development@lists.sourceforge.net 
bitcoin-development@lists.sourceforge.net
Sent: Monday, July 9, 2012 6:46 PM
Subject: Re: [Bitcoin-development] Random order for clients page

On Mon, Jul 9, 2012 at 12:09 PM, Amir Taaki zgen...@yahoo.com wrote:
 JS randomisation is bad. People shouldn't need JS to view a webpage.

JS randomization doesn't imply needing JS to view the page. It implies
needing JS to see it in random order.  You could also combine it with
the server-side randomization if you care about non-js being non
random, though I don't think it matters.

As others have pointed out I don't generally think the randomization
is good in principle, but if its done it should at least achieve its
goals.

 Only you have a problem with this page. I don't see why Bitcoin-Qt needs to 
 be first either when it dominates the front page. It is perfectly fine as it 
 is.

I'll let other people speak for themselves, but I did consult others
before reverting your last batch of changes.

More generally, we have pull requests in order to get some peer review
of changes.  Everyone should use them except for changes which are
urgent or trivially safe.  (Presumably everyone with access knows how
to tell if their changes are likely to be risky or controversial)

 You are not a developer of any alternative clients, and this is a webpage for 
 Bitcoin clients. I have made a change to remove a source of disputes, and 
 make the process more fair and equal. Your suggestion to remove the clients 
 page is your bias towards thinking that there should be only one Bitcoin 
 client that everyone uses (the one which you contribute towards).

I'm strongly supportive diversity in the Bitcoin network, and some alt
client developers can speak to the positive prodding I've given them
towards becoming more complete software. If I've said anything that
suggests otherwise I'd love to be pointed to it in order to clarify my
position.

Unfortunately none of the primary alternatives are yet complete, the
network would be non-function if it consisted entirely of multibit or
electrum nodes

Re: [Bitcoin-development] Random order for clients page

2012-07-09 Thread Amir Taaki
By that time in the future, when there are many clients, there should just be a 
flat list or no list at all.



- Original Message -
From: Nils Schneider n...@nilsschneider.net
To: bitcoin-development@lists.sourceforge.net
Cc: 
Sent: Monday, July 9, 2012 6:33 PM
Subject: Re: [Bitcoin-development] Random order for clients page

I don't think that's a good idea as it can easily confuse or annoy users
when things move around. The ordering should be preserved as much as
possible so users can remember where they found a client they liked
(e.g. 2nd row, 1st column and screenshot with light and blue colors).
Making them search the entire page is inefficient and will just get
worse once there are many clients on the page (and I think that's the goal).

On 09.07.2012 17:54, Amir Taaki wrote:
 Took me a while, but finally got it working.
 
 Entries on the clients page are randomly ordered when the page is generated.
 
 https://github.com/bitcoin/bitcoin.org/commit/6850fc8c83494d6ec415ea9d36fb98366373cc03
 
 We should regenerate the page every 2 days. This gives fair exposure to all 
 the clients listed.
 
 
 --
 Live Security Virtual Conference
 Exclusive live event will cover all the ways today's security and 
 threat landscape has changed and how IT managers can respond. Discussions 
 will include endpoint security, mobile security and the latest in malware 
 threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development
 


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] BIP 34: Block v2, Height in Coinbase

2012-07-06 Thread Amir Taaki
It would be nice if Bitcoin was engineered this way from the start. The amount 
of workarounds, special cases and code bloat to deal with the fact that txs are 
non-unique was a massive headache for me.





From: Mark Friedenbach m...@monetize.io
To: Jeff Garzik jgar...@exmulti.com 
Cc: Bitcoin Development bitcoin-development@lists.sourceforge.net 
Sent: Friday, July 6, 2012 6:56 PM
Subject: Re: [Bitcoin-development] BIP 34: Block v2, Height in Coinbase


On Fri, Jul 6, 2012 at 9:49 AM, Jeff Garzik jgar...@exmulti.com wrote:

On Fri, Jul 6, 2012 at 12:45 PM, Peter Vessenes pe...@coinlab.com wrote:
 The proposal is simple, and it's a small change for miners, I imagine.

 My question is: why?

 I worry about stuffing too many requirements on the coinbase. I suppose
 the coinbase is easily extendible if we run out of bytes, but I think I'd
 like to see some more discussion / good / bad type cases for making this
 change. What do we get over just the prev_hash by doing this?

With the existing setup (sans height in coinbase), you might not have
unique transactions, with all that entails.


But those issues are solvable through other, non-backwards incompatible means. 
For example, mandate that a transaction hash, output index refers to the 
first such pair that is not already spent. No?

Mark
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] New P2P commands for diagnostics, SPV clients

2012-06-15 Thread Amir Taaki
Why though? The bottleneck is not network traffic but disk space 
usage/blockchain validation time.



- Original Message -
From: Mike Hearn m...@plan99.net
To: Jeff Garzik jgar...@exmulti.com
Cc: Bitcoin Development bitcoin-development@lists.sourceforge.net
Sent: Friday, June 15, 2012 3:43 PM
Subject: Re: [Bitcoin-development] New P2P commands for diagnostics, SPV clients

 Yes, the format is something that must be hashed out (no pun
 intended).  Need input from potential users about what information
 they might need.

Matts point that a branch-per-transaction may duplicate data is well
made, that said, I suspect a format that tries to fix this would be
much more complicated.

How about see this project as a three part change?

First step - add the mempool command and make nodes sync up their
mempools on startup.

Second step - if protocol version = X, the block message consists
of a header + num transactions + vectorhash  instead of the full
transactions themselves.

On receiving such a block, we go look to see which transactions we're
missing from the mempool and request them with getdata. Each time we
receive a tx message we check to see if it was one we were missing
from a block. Once all transactions in the block message are in
memory, we go ahead and assemble the block, then verify as per normal.
This should speed up block propagation. Miners have an incentive to
upgrade because it should reduce wasted work.

Third step - new message, getmerkletx takes a vectorhash and returns
a merkletx message: merkle branch missing the root + transaction data
itself for each requested transaction. The filtering commands are
added, so the block message now only lists transaction hashes that
match the filter which can then be requested with getmerkletx.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Near-term scalability

2012-06-15 Thread Amir Taaki
 less expensive. This is no more real or less artificial then an
 imposed licensing fee or the like and it is not subject to market
 forces.

Sure, the market is not always efficient nor desirable. This seems more like a 
social question though about choice and information. I do strongly feel that 
users should have more control over their technology, and a say in how Bitcoin 
operates. It is our job to present the choices and inform them to make good 
decisions. If we think how to implement this with a social component of the 
users operating the network rather than hard and fast rules, I think that's the 
preferrable way.

Part of the problem is that Satoshi didn't totally anticipate the growth of the 
network. The block reward (the subsidy) is too high, which is why transactions 
can afford to be so cheap. What would happen if blocks required a cumulative 
fee of XN BTC for N transactions before being accepted?



- Original Message -
From: Gregory Maxwell gmaxw...@gmail.com
To: Amir Taaki zgen...@yahoo.com
Cc: 
Sent: Friday, June 15, 2012 8:43 PM
Subject: Re: [Bitcoin-development] Near-term scalability

On Fri, Jun 15, 2012 at 2:38 PM, Amir Taaki zgen...@yahoo.com wrote:
 Forcing users to switch addresses per received payment to work around a bad 
 fee system would be a braindead decision. You might love software and playing 
 with web plugins, but not everyone does. Artists like Rap News can right now 
 simply throw up an address and begin accepting donations. That's a hugely 
 powerful and impactful selling point for Bitcoin.

And that use case does not need fast confirmations!

This is making the point.

there are no artificial barriers to entry beyond the base cost. This network 
would always be competitive and strictly operate based on market dynamics.

The users of bitcoin can collectively choose how expensive operating a
full node is by accepting validation rules that allow it to be more or
less expensive. This is no more real or less artificial then an
imposed licensing fee or the like and it is not subject to market
forces.


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Proposed new P2P command and response: getcmds, cmdlist

2012-06-15 Thread Amir Taaki
Introspection/command discovery is nice, but I would prefer it to be 
immediately done in the first version exchange so no assumptions as to how a 
network is operating need to be made.

I like the idea of a flat list of commands. It might make sense to have 
meta-commands that alias to groups of commands. i.e original for the 
current core subset up to (and including) pong. The aliases could exist in a 
text definition file which is held on github or bitcoin.org/


- Original Message -
From: Jeff Garzik jgar...@exmulti.com
To: Bitcoin Development bitcoin-development@lists.sourceforge.net
Cc: 
Sent: Saturday, June 16, 2012 2:13 AM
Subject: [Bitcoin-development] Proposed new P2P command and response: getcmds, 
cmdlist

Outside of major features advertised network-wide in nService bits,
P2P protocol lacks a good method of enumerating minor features or
extensions.  The version number increment is coarse-grained, and is
not self-documenting.  A simple extension which lists supported
commands is added, as demonstrated in this pull request:

    https://github.com/bitcoin/bitcoin/pull/1471

Another option is for verack to return this information at login,
eliminating the need for a separate command/response.

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

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] SatoshiDice and Near-term scalability

2012-06-15 Thread Amir Taaki
Did anyone try sending them an email asking them to stop or offering help to 
fix their site? What did they say? I'm sure they would try to be accomodating.



- Original Message -
From: Jonathan Warren jonat...@bitcoinstats.org
To: bitcoin-development@lists.sourceforge.net
Cc: 
Sent: Saturday, June 16, 2012 4:35 AM
Subject: Re: [Bitcoin-development] SatoshiDice and Near-term scalability

Yes, I measure mainnet confirmation times on a regular basis.
http://bitcoinstats.org/post/tx-confirmation-times-June2012.png

Before fairly recently, fee-paying transactions never took anywhere close to
this long to be confirmed. 

Jonathan Warren
(Bitcointalk: Atheros)

-Original Message-
From: Jeff Garzik [mailto:jgar...@exmulti.com] 
Sent: Friday, June 15, 2012 1:17 PM
To: bitcoin-development@lists.sourceforge.net
Subject: [Bitcoin-development] SatoshiDice and Near-term scalability

Hard-fork requires a very high level of community buy-in, because it shuts
out older clients who will simply refuse to consider 1MB blocks valid.

Anything approaching that level of change would need some good, hard data
indicating that SatoshiDice was shutting out the majority of other traffic.
Does anyone measure mainnet normal tx confirmation times on a regular
basis?  Any other hard data?



--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Fw: Punishing empty blocks?

2012-05-28 Thread Amir Taaki
That's a cool idea. Very meta.


From: Peter Vessenes pe...@coinlab.com
To: Stefan Thomas m...@justmoon.de 
Cc: bitcoin-development@lists.sourceforge.net 
Sent: Monday, May 28, 2012 4:54 PM
Subject: Re: [Bitcoin-development] Punishing empty blocks?


One of the issues here though is that it would be nice if miners published 
their own tx rules -- it might be hard to impute them from data.

I had started a thread about this on bitcoin.org some time ago, and I don't 
recall what the general outcome was.

I had imagined an open service whereby a miner could publish a short string in 
their conbase tying to the service and the service would have different 
metadata, including the miner's transaction guarantees.

We offered to host this before, and would still be willing to host such a 
service.

Peter


On Sat, May 26, 2012 at 7:52 AM, Stefan Thomas m...@justmoon.de wrote:

Zooko is spot on - slower confirmations will give people a reason to set
higher fees. As soon as fees reach a level where they matter, even
botnet operators will be looking into ways of including transactions for
some extra profit.

In the meantime slightly slower confirmations aren't a problem. Consider
that even if it takes four blocks to get your transaction included
instead of one, once it is included, you still benefit from every new
block in terms of security. So if you're looking for six confirmations
for example, even a three block delay will only be a 50% delay for you.
And of course there are techniques for instant transactions which
continue to be refined and improved.

As for the proposed solutions: Punishing 1-tx blocks is complete and
utter nonsense. It's trivial to include a bogus second transaction.

Any additional challenges towards miners like hashes of the previous
block are at best useless. If I was running a botnet, I'd just grab that
hash from a website (pretty good chance Blockchain.info will have it :P)
or mining pool or wherever and keep going undeterred. At worst they may
affect scalability one day. You might imagine a peer-to-peer network of
miners who for cost reasons don't download all blocks anymore, but
verify only a percentage of them at random. They might then exchange
messages about invalid blocks including a proof (invalid tx, merkle
branch) why the block is invalid. This is just one idea, the point is
that assumptions about what a legitimate miner looks like may not always
hold in the future.

Finally, there is an ethical aspect as well. If a miner wishes not to
include my transaction that is his choice. He has no more an obligation
to sell his service to me than I have to buy it from him. If I really,
really want him to include my transaction I will have to offer to pay more.

If we as developers think that confirmations are too slow or that more
blocks should include transactions, then the right measures would be:

- Educating users about the relationship between confirmation speed and fees
- Raising the default transaction fee

Every market has a supply curve, so it is economically to be expected
that there will be some miners who don't include transactions, simply
because they are at that end of the supply curve where it is not worth
it for them to sell their service. All markets must have a certain
tension - there must be miners who don't include transactions for there
to be users who want their transactions included more quickly. In other
words there must be somebody not confirming if confirmations are to have
value. If you interfere with that all you'll accomplish is keep
transaction fees below market level, which will make the transition from
inflation-financed hashing to transaction-financed hashing more painful
and disruptive.

Cheers,

Stefan


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development



-- 

Peter J. Vessenes
CEO, CoinLab
M: 206.595.9839
Skype: vessenes
Google+ 

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net

Re: [Bitcoin-development] BIP 33 - Stratized Nodes

2012-05-16 Thread Amir Taaki
A bloom filter seems like an interesting idea. However this proposal is 
concerned mainly with the initialisation stage, whereas this bloom filter is 
for pushed blocks.

This proposal still updates new transactions and blocks in the same way, and 
it's not inconceivable to later use a bloom filter to make that part more 
efficient (although it's questionable if pushing this server side would be a 
good idea as it would now need to track an additional client state).


From: Mike Hearn m...@plan99.net
To: Amir Taaki zgen...@yahoo.com 
Cc: bitcoin-development@lists.sourceforge.net 
bitcoin-development@lists.sourceforge.net 
Sent: Wednesday, May 16, 2012 5:46 PM
Subject: Re: [Bitcoin-development] BIP 33 - Stratized Nodes


Thanks for getting this started. 

With regards to the specific proposal, I don't believe it's the best option and 
still plan to eventually implement the original design outlined more than a 
year ago in this thread:

https://bitcointalk.org/index.php?topic=7972.msg116285#msg116285

Namely that you use a new protocol command to set a Bloom filter on a 
connection. Only transactions matching that filter will appear in relayed 
inventory. Blocks that are requested will arrive as a header plus 
transaction/merkle branch pairs. Clients are expected to maintain and track the 
block chain as per usual, but instead of downloading the whole chain and then 
dropping the irrelevant transactions, that filtering is done server side. By 
strengthening or weakening the Bloom filters you can choose your preferred 
point on the privacy/bandwidth-usage spectrum. It is a fairly simple change to 
the Satoshi and BitcoinJ codebases but still allows clients to gain confidence 
in their balance by examining the chain, and this is true even in the presence 
of a hijacked internet connection (you can't trust pending transactions that 
way, but you can still trust confirmed transactions).

The filters would be applied to each data block in each script rather than 
having a specific knowledge of addresses. In this way you can select for things 
like multisig outputs or outputs which don't use addresses / pubkeys to 
authenticate.

I could write a BIP for this alternative protocol if somebody else wants to 
implement it. I was going to wait until I had time to do both BIP and 
implementation, but I think some simple optimizations to BitcoinJ can keep its 
performance good enough for the short term.  

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] BIP 33 - Stratized Nodes

2012-05-16 Thread Amir Taaki
 1) This is cool and useful (but see 3)

 2) This is significantly less secure than validating an entire blockchain; 
 it's certainly worth working out some use cases here in more detail than just 
 a sample conversation. More on this below
 3) What about discovery? Will a client now have the chance to look for 
 NODE_STRATIZED clients on IRC? How do you envision a stratized server decides 
 which transactions to relay/store? Or is it just a caching layer in front of 
 a high quality blockchain service? If it is just a caching service, the 
 question of cache hits / misses is an interesting one as well. 

Stratized nodes do discovery as normal. Service nodes are explicitly chosen 
like IRC servers are for IRC clients.


 4) What are the economic motivations to run a stratized server? Other than 
 cheating people of course.

None. Same as BitTorrent super-nodes, Tor relays or email servers. People don't 
need economic motivation for everything.


 5) Seems like a 'send me everything for this source address' is going to save 
 a lot of roundtrip conversations for what I imagine the most common request 
 will be.

That's a bad idea. I prefer to keep each request minimal to prevent resource 
starvation and simplify the protocol (while shifting the onus onto the client). 
Also the history can be resolved with multiple services while the data is being 
downloaded and sorted.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Bitcoin intro and talks in Berlin (11th May at 20:00)

2012-05-08 Thread Amir Taaki
c-base is holding a day on p2p technologies on the 11th. From 20:00 will be the 
section on Bitcoin.

If you want to do a talk, then email me (gen...@riseup.net) and I’ll add you to 
the schedule.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] new bitcoin.org clients page

2012-05-02 Thread Amir Taaki
This is like the most annoying thing about email. Often with group emails, 
we'll be having a conversation then someone will click reply instead of group 
reply and the convo will go on for a while. Eventually I'll realise the persons 
are missing and add them back in.

On Yahoo mail (which I use for spam/mailing lists), to do reply all involves 
clicking a tab, scrolling down and clicking Reply All. Normally I instead go 
through the steps of reply, delete To, re-enter bitco... select drop down, 
click send.

Anyone know how to make reply all the default in mutt? And how can I exclude it 
from re-including my own email when I do a group reply so I don't get the same 
email again.



- Original Message -
From: Jeff Garzik jgar...@exmulti.com
To: grarpamp grarp...@gmail.com
Cc: bitcoin-development@lists.sourceforge.net
Sent: Wednesday, May 2, 2012 7:29 PM
Subject: Re: [Bitcoin-development] new bitcoin.org clients page

On Wed, May 2, 2012 at 12:58 PM, grarpamp grarp...@gmail.com wrote:
 Try Reply to All

 That puts the sender in 'to' and list in 'cc',
 which dupes to the sender and eventually
 blows out the to and cc lines as everyone
 chimes in and doesn't trim. 'reply to' solves
 most of that. assuming the list sw can do it.

Reply-To Munging Considered Harmful
http://www.unicom.com/pw/reply-to-harmful.html



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

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] new bitcoin.org clients page

2012-04-30 Thread Amir Taaki
Check it :) https://github.com/bitcoin/bitcoin.org/pull/34

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] new bitcoin.org clients page

2012-04-30 Thread Amir Taaki
Are we looking at the same list? Because here is the order I added: Bitcoin-Qt, 
Armory, Electrum and MultiBit. Maybe try CTRL-F5 to force a refresh of your 
browser.

Also about the descriptions: yeah I know. I think it's better to put this up 
first and then have everyone submit their own descriptions and screenshots. 
Otherwise it'll be a nightmare to coordinate until everything is perfect. I did 
message you on IRC today but maybe you were offline.

I didn't copy paste the Armory description from the website because it really 
sounds too spammy like a sales pitch. Here I was trying to give an even handed 
balanced overview of all the clients. For each client I was trying to empaphise 
a 'theme'. Bitcoin-Qt is stability. Armory is advanced. Electrum is convenient. 
MultiBit is ease of use.


From: Alan Reiner etothe...@gmail.com
To: Amir Taaki zgen...@yahoo.com 
Cc: bitcoin-development@lists.sourceforge.net 
bitcoin-development@lists.sourceforge.net 
Sent: Monday, April 30, 2012 7:23 PM
Subject: Re: [Bitcoin-development] new bitcoin.org clients page


Hey, looks good!  I'm glad to see them sorted alphabetically :)

A couple comments:  I don't think the entries for wallet security and 
backups accurately describe Armory.  Wallet Security should say 
Encrypt/Offline or something to to that effect -- after all, offline wallets 
are the holy grail feature of the Armory.  And backups should say something 
like One-time Printable if it fits within the box.  

Otherwise, I really like the layout and design.  Although despite the fact I 
enjoy being first on the list, I think Bitcoin-Qt should still go first.  It is 
the reference client, and I think it's relevant that it is the de-facto 
client for the majority of users, and the one with the most quality control and 
stability.

-Alan



On Mon, Apr 30, 2012 at 1:50 PM, Amir Taaki zgen...@yahoo.com wrote:

Check it :) https://github.com/bitcoin/bitcoin.org/pull/34

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] bitcoin.org luke-jr/multiclient branch

2012-04-29 Thread Amir Taaki
Hi,

Can we pull this? It's been there for almost 20 days now.


https://github.com/bitcoin/bitcoin.org/pull/32

My comment:
As a first step, this should probably be pulled right away and then 
any improvements can be made after. Lets get the ball rolling rather 
than debating the colour of the bike-shed!
http://hackerspaces.org/wiki/The_Bikeshed_Anti-Pattern

Although I agree with Mike Hearn - far better would be a grid of 4 
columns and X rows. Each box has a linkable title, a picture and then 
850 word blurb from the project. I mean where would libbitcoin fit in 
here? I'd want to say the design philosophy behind it and that there's 
Python bindings - a circular peg that doesn't fit in the square boxes of this 
table. Although whatever, that's not important. I'm just happy to 
see MultiBit, Electrum and Armory get exposure.

Anyone that wants to see what it looks like can add this to their hosts file:

176.31.24.241  bitcoin.org

Then navigate to http://bitcoin.org


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Trusted identities

2012-04-26 Thread Amir Taaki
look at the first line of the if statement


// Check for conflicts with in-memory transactions
CTransaction* ptxOld = NULL;
for (unsigned int i = 0; i  tx.vin.size(); i++)
{
COutPoint outpoint = tx.vin[i].prevout;
if (mapNextTx.count(outpoint))
{
// Disable replacement feature for now
return false;

// Allow replacing with a newer version of the same transaction
if (i != 0)
return false;
ptxOld = mapNextTx[outpoint].ptx;
if (ptxOld-IsFinal())
return false;
if (!tx.IsNewerThan(*ptxOld))
return false;
for (unsigned int i = 0; i  tx.vin.size(); i++)
{
COutPoint outpoint = tx.vin[i].prevout;
if (!mapNextTx.count(outpoint) || mapNextTx[outpoint].ptx != 
ptxOld)
return false;
}
break;
}
}



From: Peter Vessenes pe...@coinlab.com
To: Peter Todd p...@petertodd.org 
Cc: bitcoin-development@lists.sourceforge.net 
Sent: Thursday, April 26, 2012 6:11 PM
Subject: Re: [Bitcoin-development] Trusted identities


These are interesting thoughts, karma for bitcoins essentially.

I would like CoinLab to publish a 'cost of subverting 1-n transactions with 90% 
probability' metric soon, and I think it would help everyone to understand what 
that number is.

When we started out, you probably needed to wait 5 blocks for $10 or $20 of 
bitcoin value transfer.

Now, I'd happily accept a $1k transaction with 1 confirmation. 

More difficulty shortens the safe time we can transact large volumes in, which 
is good for the network.

I'm not sure of the current implementation of replacement transactions, can 
anyone on the core team speak to this? Can I replace transactions, or is that 
part of the spec unimplemented or deprecated right now?

Peter



On Thu, Apr 26, 2012 at 8:49 AM, Peter Todd p...@petertodd.org wrote:

It recently occured to me that we can use the public nature of the block
chain to create trusted identities, for a specific form of trust.

Lets suppose Alice has some bitcoins held at bitcoin address A. She
wants to establish trust in the identity associated with the ECC
keypair associated with A, for instance for the purpose of having other
users trust her not to attempt to double spend. Since the trust she
seeks is financial in nature, she can do this by valuing the identity
associated with A, by delibrately throwing away resources. A simple way
to do this would of course be to transfer coins to a null address,
provably incurring a cost to her.

A more socially responsible way would be for her to create a series of
transactions that happen to have large, and equal, transaction fees.
Bitcoin makes the assumption that no one entity controls more than 50%
of the network, so if she makes n of these transactions consecutively,
each spending m BTC to transaction fees, there is a high probability
that she has given up at least n/2 * m BTC of value. This of course is
all public knowledge, recorded in the block chain. It also increases the
transaction fees for miners, which will be very important for the
network in the future.

Now Bob can easily examine the block chain, and upon verifying Alice's
trust purchase, can decide to accept a zero-confirmation transaction at
face value. If Alice breaks that promise, he simply publishes her signed
transaction proving that Alice is a fraudster, and future Bob's will
distrust Alice's trusted identity, thus destroying the value needed to
create it.

In effect, we now have a distributed green address system.

Now Alice could try to mount a double-spend attack on a whole bunch of
people at once, hoping to have them all accept the transaction. However
as it is the just trust them model works pretty well already.


A good usecase for this idea, beyond the obvious fast payments
application, is a distributed anonymizer. Alice can now publish her
request to anonymize coins, and other trusted identities can make their
bids. If Alice accepts a bid from Bob, she will want Bob to send her the
anonymized coins *prior* to her transaction going through, thus breaking
the temporal connection between the transactions. Now Alice can give Bob
the signed payment transaction, and Bob can submit his payment
transaction to the network first, knowing that Alice isn't going to try
to rip him off. Bob can also have a trusted identity which signed the
contract for the anonymizer transaction, and similarly if he rips Alice
off, she can publish it for the world to see.

A more subtle effect, is this makes sybil attacks more difficult. To
pretend to be a thousand identities is going to now require 1,000 * n
coins, and attempting to pull this attack off inherently strengthens the
bitcoin network. Obviously we can apply this principle to other things
like tor nodes as well.

--
http://petertodd.org 

[Bitcoin-development] AreInputsStandard() mistake

2012-04-24 Thread Amir Taaki
Hey,

Only a small thing - I think the first check in that function should be an 
assert. There is a problem if that function is called a coinbase tx.


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Adding request/reply id in messages

2012-04-12 Thread Amir Taaki
This is a bad idea. The bitcoin protocol is (mostly) stateless. Stateless 
protocols are more secure.




 From: Pieter Wuille pieter.wui...@gmail.com
To: Gavin Andresen gavinandre...@gmail.com 
Cc: bitcoin-development@lists.sourceforge.net 
Sent: Thursday, April 12, 2012 5:01 PM
Subject: Re: [Bitcoin-development] Adding request/reply id in messages
 
On Thu, Apr 12, 2012 at 11:41:05AM -0400, Gavin Andresen wrote:
 On Wed, Apr 11, 2012 at 2:39 PM, Christian Bodt sirk...@gmail.com wrote:
  I would like to discuss the following bitcoin protocol improvement proposal:
 
           Adding request/reply id in all messages (in the message header,
  based on what was done for the checksum field)
 
 That seems like a perfectly reasonable protocol improvement to me.
 Anybody else have an opinion?

If there is a reasonable use for it, I have no objections.

However: the bitcoin P2P protocol is not fully request-reply based, and trying 
to use
it that may be be less intuitive than how it looks. For example, doing a second
identical getblocks request will not result in more inv replies, as the 
client
prevents retransmits. This is not a large problem, but maybe such an extension
should also include an extra denied message, which is sent if the client is
unwilling to answer (and may also be used to report transactions that are not
accepted into the memory pool, for example).

-- 
Pieter

--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Adding request/reply id in messages

2012-04-12 Thread Amir Taaki
Jeff elaborated the problems very well, but I just want to add this:

Your change is essentially relying (trusting) the server to track a piece of 
information (your state). Anytime you start depending on another node in some 
way, it is opening yourself up to be exploited. Nodes should be doing their 
owning state maintainance, not relying on external parties.


I am very much against the change. As someone who has implemented the complete 
bitcoin protocol, I had no problems implementing the blockchain download. In 
fact, I dislike that nodes have to store the last inventory they sent as part 
of a getblocks in order to trigger the next round. It's be better if there was 
no state whatsoever.


From: Jeff Garzik jgar...@exmulti.com
To: sirk...@gmail.com 
Cc: bitcoin-development@lists.sourceforge.net 
Sent: Thursday, April 12, 2012 6:12 PM
Subject: Re: [Bitcoin-development] Adding request/reply id in messages

On Wed, Apr 11, 2012 at 2:39 PM, Christian Bodt sirk...@gmail.com wrote:
 Hi,

 I would like to discuss the following bitcoin protocol improvement proposal:

          Adding request/reply id in all messages (in the message header,
 based on what was done for the checksum field)

 The original reason is that I found it very hard to implement robust
 blockchain downloading as we are missing context information:
 The download protocol relies on the other peer sending one (or more) inv
 reponse(s) to getblocks and sending the hashContinue.
 But if the other peer doesn't send a response to getblock, send a partial
 response to getblocks, mixes it with some unrelated blocks inventories
 or doesn't send the hashContinue it is very hard to detect and handle
 (e.g. ban the peer and switch to another).  This could cause some DoS
 attacks by misbehaving peers.

If the peer is misbehaving, then disconnect.  Your protocol change
does not offer any clear benefits in this area, as these sorts of
attacks/misbehaviors/bugs are still just as possible, and just as
damaging (or not).

Just disconnect the strange peer!

 The problems are that 1/ we don't know how many inv messages to wait for
 after getblocks and 2/ we don't know how to distinguish between result of
 getblocks and spontaneous inv notifications.
 The same is true for  addr messages (it is both a notification and reply)
 but this is less of a problem as a lack of response to getaddr
 doesn't constitute a DoS.

 The idea would be to add a new requestid field in messages and define the
 following:


Stateless protocols have a lot of value.  They are easiest to
implement, and easier to prove correct.  Existing clients like
ArtForz' half-a-node, variants of which are deployed all over the
place in bitcoin-land, rely on the stateless-ness to one degree or
another.

Stateful protocols, too, have their problems as well.  One must add
code to help remain synchronized between local and remote states,
which your suggested change only hints at.  NFSv4 and RPC have a long
history of dealing with stateful-ness issues.  Obviously bitcoin P2P
is nowhere near as complex, but the history of NFS development offers
several lessons applicable to your proposed change.

Overall, IMO your listed reasons for needing this major change
(stateless-stateful) do not really justify the change.  Handling
initial block download can be accomplished in a number of ways, and
peer(s) may crash or return odd results.  You must handle these cases
properly, regardless of the presence of req/reply id's.

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

--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] BIP 16 changes (list inside)

2012-03-18 Thread Amir Taaki
Hi,

Is this an accurate and precise summary of the changes needed for P2SH and BIP 
16?

== Block validation (starting with ProcessBlock) ==

* SigOpCount is now a LegacySigOpCount (CheckBlock)
* Main body of AcceptBlock() and rest of ProcessBlock() is unchanged.
* AddToBlockIndex() unchanged
* Some nice efficient improvements to SetBestChain(), but not related to BIP 16
* ConnectBlock() has new SigOp calculation.
* No important changes to FetchInputs()/ConnectInputs()

== Script ==

* Solver has special case to check for TX_SCRIPTHASH. Returns hash of input 
eval script
* Another Solver which a) returns signature of pubkey script or b) 
TX_SCRIPTHASH - finds redeem script in KeyStore and returns it.
* ExtractAddress(es)
* VerifyScript:
** After running input script (scriptSig), copy stack
** Evaluate script as normal
** if block date (fValidatePayToScriptHash) and output script (scriptPubKey) is 
P2SH:
*** scriptSig must be only push operations
*** evaluate last item of copied stack as a script using the copied stack as 
the stack
* SigOpCount (used inside CBlock::ConnectBlock main loop) does scoring 
checksigs and multisigs.
** Newly added DecodeOP_N to normal SigOpCount

== Address ==

* Set main hash160 data with a beginning byte (nVersion) of 0x05


--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] BIP 18 (or not?)

2012-03-14 Thread Amir Taaki
Hi,

luke-jr withdrew BIP 16 and put forwards support for BIP 17. So now there's a 
consensus to move forwards.

However he submitted BIP 18 to me today. From looking it over, I'm not even 
sure the idea is tenable nor see the purpose when we are adopting BIP 17. 
Personally I'd rather not see a high turnover in protocol design when something 
works (now that we have viable multisig transactions) even compromising on the 
position of a perfect design.

https://en.bitcoin.it/wiki/BIP_0018

Usually for a BIP, someone submits it to me, I review to see whether the idea 
is technically sound (not making judgements on the validity), the community 
discusses the idea and I evaluate the support at the end to change the status. 
In general I try to accept all BIPs in the interests of fairness, rather than 
holding a vote or being the executioner.

Once the champion has asked the Bitcoin community as to whether an idea has 
any chance of acceptance, a draft BIP should be presented 
to bitcoin-development@lists.sourceforge.net. This gives the author a chance to 
flesh out the draft BIP to make properly formatted, of high quality, and to 
address initial concerns about the proposal.
Following a discussion, the proposal should be sent to the Bitcoin-dev list 
with the draft BIP and the BIP editors b...@bitcoin.org. This draft must be 
written in BIP style as described below, else it will be sent back without 
further regard until proper formatting rules are followed.

I don't think BIP 18 has followed this discussion before being accepted. 
Neither have many other BIPs as we're a small community, and so far we avoided 
this unneeded level of bureaucracy. However I think this is a good thing to do 
here.

Should BIP 18 be accepted into the repo or not?

The BIP editor will not unreasonably deny a BIP. Reasons for denying BIP 
status include duplication of effort, being technically unsound, not providing 
proper motivation or addressing backwards compatibility, or not in keeping with 
the Bitcoin philosophy.

For a BIP to be accepted it must meet certain minimum criteria. It must be a 
clear and complete description of the proposed enhancement. The enhancement 
must represent a net improvement. The proposed implementation, if applicable, 
must be solid and must not complicate the protocol unduly.

(quotes from BIP 1)

--
Virtualization  Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] JSON-RPC is BIP territory or not?

2012-03-02 Thread Amir Taaki
Hi,

I got sent this BIP:

https://en.bitcoin.it/wiki/BIP_DRAFT:_getmemorypool#JSON-RPC_Method:_getmemorypool


What is your opinion on this? Is it BIP related?

It is a implementation-specific non-bitcoin-protocol proposal. My understanding 
of BIPs is that
they apply across bitcoin implementations and largely focus on the most generic 
use-cases
(like the URIs) and the protocol. Things which affect all clients, and allow 
the system to function
as a united whole.

That BIPs especially focus on the protocol, and that something like this is 
outside the mandate
of the BIP process.

For instance, we could imagine a future scenario. Bitcoin-Qt is currently based 
off bitcoind's
codebase. However wumpus built the client in mind with an abstraction layer to 
enable multiple
backends (a good design). In our hypothetical situation, there are 3 different 
backend codebases
using Bitcoin-Qt. I do not think a proposal to mandate a changing to 
Bitcoin-Qt's abstraction
layer or a change in the UI placement would be appropriate BIP material.

OTOH, many clients do need to make use of URIs and the BIP process is totally 
correct, as it
standardises a behaviour which is needed for interoperability of the network 
and community.

Thoughts?--
Virtualization  Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Duplicate transactions vulnerability

2012-02-29 Thread Amir Taaki
I support BIP 30.

I gave it a thought. The other ways of resolving this issue, all have various 
niggles. This is the best way.



 From: Pieter Wuille pieter.wui...@gmail.com
To: Zooko Wilcox-O'Hearn zo...@zooko.com 
Cc: Bitcoin Dev bitcoin-development@lists.sourceforge.net 
Sent: Wednesday, February 29, 2012 4:47 PM
Subject: Re: [Bitcoin-development] Duplicate transactions vulnerability
 
On Tue, Feb 28, 2012 at 06:41:31PM -0700, Zooko Wilcox-O'Hearn wrote:
 Could you spell out the attack explicitly? Presumably there aren't a
 lot of people with the malice energy to perform the attack but not
 to figure it out for themselves. I, however, have the niceness
 energy to think about it for a few minutes but not to figure it out
 for myself. If in your opinion it is realistically dangerous to post
 it publicly, would you be so kind as to include me in the private
 sharing of the explanation?

It's not exactly a secret anymore, as the patch also references it.
Russell O'Connor described the attack on his blog:
http://r6.ca/blog/20120206T005236Z.html

-- 
Pieter

--
Virtualization  Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development--
Virtualization  Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Building BDB on MingW

2012-02-24 Thread Amir Taaki
I followed the instructions from build-msw.txt and am getting the same issue 
from here:

https://bitcointalk.org/index.php?topic=45507.0


MSYS shell:

cd /c/db-4.8.30.NC-mgw/build_unix
sh ../dist/configure --enable-mingw --enable-cxx
make

$ make

./libtool --mode=compile gcc -c -I. -I../dist/..  -O3  
../dist/../mutex/mut_win32.c
libtool: compile:  gcc -c -I. -I../dist/.. -O3 ../dist/../mutex/mut_win32.c  
-DDLL_EXPORT -DPIC -o .libs/mut_win32.o
In file included from ./db_int.h:886:0,
                 from ../dist/../mutex/mut_win32.c:12:
../dist/../dbinc/repmgr.h:502:13: error: two or more data types in declaration 
specifiers
../dist/../dbinc/repmgr.h:502:1: warning: useless type name in empty declaration
make: *** [mut_win32.lo] Error 1[/quote]

Any ideas? Sadly the proposed fix in that thread didn't work.

--
Virtualization  Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] BIP 21 accepted, new BIP 19

2012-02-05 Thread Amir Taaki
BIP 21 had broad consensus among the major implementations:
https://en.bitcoin.it/wiki/BIP_0021


BIP 19 is a document to propose adding a new payment type to the scripting 
system's template list.
https://en.bitcoin.it/wiki/BIP_0019

I haven't fully evaluated it completely but it seems solid. My only thoughts is 
that it uses a bunch of arithmetic operators which can behave in strange ways.--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] BIP 20 Rejected, process for BIP 21N

2012-01-31 Thread Amir Taaki
 excuse me if it was already discussed, but maybe using satoshis instead of 
 decimal bitcoin would be better ? choice? We all know about pains with 
 proper handling decimal numbers across of all implementations - and  it's 
 not only about json-rpc.


Yeah well it's up to the people who are making this stuff to decide :)


On Tue, Jan 31, 2012 at 3:27 PM, Amir Taaki zgen...@yahoo.com wrote:

BIP 20 really has no support among implementations such as Bitcoin-Qt, 
Electrum, MultiBit or Bitcoin-JS. As the most active and visible user facing 
GUI projects (all with some form of URI Scheme), their opinion carries the most 
weight. To a lesser degree Bitcoin-Qt has the large majority of users too 
(although that's a line of reasoning I'd discourage).

Normally we should probably Reject BIP 21 and re-submit a new standard (for 
history's sake), but as a) BIP 21 is largely a copy paste of BIP 20 sans some 
sections b) it is still a draft, probably the best thing here is if you all 
agree on something to run it by BlueMatt and then we'll make it the new BIP 21.

I can see a consensus forming on most parts. Just the send private key is 
contentious, and there's the topic of adding a time to expire field for 
merchants (this is a very good idea IMO).

Also BIP 20 is problematic because it is incompatible with about every 
standard on the web. All the HTML, URI and everything uses decimal numbers 
alone. I see no reason for breaking with tradition. Note that everytime I have 
to write Color or Vectorize (as a British speaker) in my code, I die a little 
inside. But it's convention and American English = International English. Also 
it would be cool if all code used a *real* international language (like 
Esperanto) but the world ain't perfect! We live in a decimal-counting 
English-speaking Windows-using God-worshipping world!

(no offense to decimal-counting English-speaking Windows-using God-worshipping 
world- I do half those things too :)

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Fw: Quote on BIP 16

2012-01-29 Thread Amir Taaki
(oops sorry greg- replied to you by mistake)

That address he gives is 77 characters/bytes (same thing). What I'm asking is 
how can it be so small. I know that it's encoding a script, but then I started 
trying to imagine what kind of script and to me it seems that 2 public keys are 
too large for those 77 characters when encoded.

That is the example quoted on the forums:
57HrrfEw6ZgRS58dygiHhfN7vVhaPaBE7HrrfEw6ZgRS58dygiHhfN7vVhaPaBiTE7vVhaPaBE7Hr


Could it be a mistake?


- Original Message -
From: Gregory Maxwell gmaxw...@gmail.com
To: Amir Taaki zgen...@yahoo.com
Cc: bitcoin-development@lists.sourceforge.net 
bitcoin-development@lists.sourceforge.net
Sent: Sunday, January 29, 2012 5:19 AM
Subject: Re: [Bitcoin-development] Quote on BIP 16

On Sat, Jan 28, 2012 at 11:52 PM, Amir Taaki zgen...@yahoo.com wrote:
 How could you have a 70 byte long address without a P2SH scheme? Is this a 
 mistake?

...  No it's not a mistake.  P2SH _prevents_ needing long addresses.

Lets unpack the acronym pay to script _hash_.  Hashes only need to
be 128-256 bits in size or so to have acceptable security, so you
don't need something longer than that for paying to a hash.

Note that gavin is saying 70 characters, not bytes.

Without some form of P2SH then only way for you to make a personal
choice of asking people to pay to a two-factor protected account or
two a multiparty trust that manages the finances of an organization
is using some form of P2S, pay-to-script.

In other words, you'd have to have an address that encodes a full
script specification for the sender to pay to,  instead of just
encoding its hash.  As a result these addresses would be much longer
(and potentially very long).

The minimum size of a two address involving encoded script would be on
that order, but they get bigger quite quickly if you add more options
to the script (actually 70 sounds quite small, it should be more like
100 for a minimum two pubkey script).

In addition to the unworkability of very long addresses as described
by gavin (amusingly I am unable to copy and paste the quoted example
in one go) a P2S solution has several problems which you might
consider more or less important:


(1) They are highly vulnerable to invisible substitution.  E.g. I can
trivially take a P2S address, change one or two characters and get a
script which is redeemable by anyone.  With P2SH you have to do
computation which is exponential in the number of unchanged digits to
get a look alike address.

(2) The sender is fully responsible for fees related to the enlarged
transactions. Even if _you're_ willing to take the txn-processing time
and fee burden of a 30 person joint trust address,  random e-commerce
sites will not be and will randomly reject your addresses.

(3) They create another input vector for non-trivial data which must
be inspected and validated, potentially presenting an attack surface.

(4) They leave the complicated (long) release rules in the transaction
outputs.  When a transaction is mined we can't be sure if it will ever
be redeemed. The outputs are unprunable.   In a future world where
many nodes prune output space is far more important than input space
and it would make sense to require more fees for it because we're
never sure how long it would need to be stored (making it an
attractive target for someone who wants to make Bitcoin unusable by
spamming it with worthless data).  P2SH reduces output sizes to the
absolute minimum without inflating the total data size.

--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Controlled block generation in fuzzer for testing blockchain

2012-01-29 Thread Amir Taaki
I added the ability to do controlled generation of blocks to gavin's fuzzer

https://github.com/genjix/bitcoin/tree/fuzzer


bitcoind -daemon
bitcoind 
setfuzzpreviousblock 0019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
bitcoind setgenerate true

It will start hashing the block with the previous hash field set 
to 0019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f and the 
target as 0x1dff

On completion it will dump the hex value of the block to debug.log and exit.

You can then feed that block to your implementation in whatever controlled 
manner you wish (i.e with libbitcoin I made a simple tool in a few lines to 
read the hex and send it via the network in localhost). If anyone wants the 
libbitcoin tool then let me know and i'll paste it over on IRC.

--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Quote on BIP 16

2012-01-28 Thread Amir Taaki
Gavin said:
Part of the controversy is whether really long bitcoin addresses would work-- 
would it be OK if the new bitcoin addresses were really long and looked 
something like 
this:  57HrrfEw6ZgRS58dygiHhfN7vVhaPaBE7HrrfEw6ZgRS58dygiHhfN7vVhaPaBiTE7vVhaPaBE7Hr
(or possibly even longer)

I've argued no: past 70 or so characters it becomes a lot harder to copy and 
paste, a lot harder to scan an address with your eyes to see if you're paying 
who you think you're paying, harder to create a readable QR code, harder to 
upgrade website or database code that deals with bitcoin addresses, etc. There 
is rough consensus that very-long addresses are not workable.

How could you have a 70 byte long address without a P2SH scheme? Is this a 
mistake?

--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Quote on BIP 16

2012-01-28 Thread Amir Taaki
2 compressed pubkeys


- Original Message -
From: Amir Taaki zgen...@yahoo.com
To: bitcoin-development@lists.sourceforge.net 
bitcoin-development@lists.sourceforge.net
Cc: 
Sent: Sunday, January 29, 2012 4:52 AM
Subject: [Bitcoin-development] Quote on BIP 16

Gavin said:
Part of the controversy is whether really long bitcoin addresses would work-- 
would it be OK if the new bitcoin addresses were really long and looked 
something like 
this:  57HrrfEw6ZgRS58dygiHhfN7vVhaPaBE7HrrfEw6ZgRS58dygiHhfN7vVhaPaBiTE7vVhaPaBE7Hr
(or possibly even longer)

I've argued no: past 70 or so characters it becomes a lot harder to copy and 
paste, a lot harder to scan an address with your eyes to see if you're paying 
who you think you're paying, harder to create a readable QR code, harder to 
upgrade website or database code that deals with bitcoin addresses, etc. There 
is rough consensus that very-long addresses are not workable.

How could you have a 70 byte long address without a P2SH scheme? Is this a 
mistake?

--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] GetBlocksToMaturity

2012-01-27 Thread Amir Taaki
Why add 20 to COINBASE_MATURITY there?

The underlying protocol accepts spent transactions at 100 (COINBASE_MATURITY) 
so this seems more like a measure to put people off spending until 120 
confirms. If you are determined enough to hack your client, you can still spend 
before 120 but after 100.

Why is this?

Did Satoshi overestimate how many competing races there would be between mined 
blocks?--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] BIP 0020: URI Scheme

2012-01-27 Thread Amir Taaki
BIP 0020 is the old URI scheme BIPisized.

ATM it is Draft status.

I do not know enough about the discussion back last year to know whether to 
move it to Accepted status or not. My feelings are that having a re-decision 
(even if it was accepted last year) is healthy since it makes no sense to have 
a standard before a standardisation process existed.

For now, it is Draft status until there's a general agreement.
--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Fuzzer?

2012-01-25 Thread Amir Taaki
Hey,

I heard there is a fuzzer in the works? Where can I find more details of this? 
I'm going to write one for libbitcoin, but if one already exists then I'd 
rather build on and use that.

Something simple like:
- Set previous block hash, set current target
- Start hashing
- Connect and send to specified host (i.e localhost)

That way I can force re-organisations and stress the blockchain algorithm. 
Should be trivial for me to build, but worth asking anyway :)

Thanks

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Meeting 10 Jan 2012 at 21:00 UTC

2012-01-04 Thread Amir Taaki
Hey,

Will get around to that write-up. Here is the page for next Tuesday:


https://en.bitcoin.it/wiki//10_Jan_2012

Feel free to add talking/discussion points to the agenda.


--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Meeting 21:00 UTC #bitcoin-dev Freenode IRC

2012-01-02 Thread Amir Taaki
This meeting is to discuss the new OP_EVAL changes coming to bitcoin.

A good summary of the past discussion so far by justmoon can be found:
http://privatepaste.com/4088b049af

Hopefully this can become a weekly thing. For now this is to discuss and inform 
about the coming changes to bitcoin.

--

Where: Freenode IRC #bitcoin-dev
When:  21:00 UTC (16:00 New York time) until 22:00*
What:  OP_EVAL

Bitcoin is starting decentralising as any healthy free thinking community
should. Projects are thiving and the economy is growing. New ideas are
being realised and will edge out old models disruptively.

My hope is that we don't all become fractured. By having weekly regular
meetings, projects can harmonise in lock step. Concepts and algorithms can
be proposed and debated. You'd be surprised what having a scheduled regular
platform can achieve. A soap-box on an island in central waters.

For me, I don't have time to wade through IRC discussions, forum posts and
mailing lists. At least if the important things are discussed in one place
it makes bitcoin development and the system more accessible.

Before meeting:

- A wiki page is created for in advance of a weekly meeting.
- Announced on forums/mailing lists.
- Throughout the week talking points are added to the meeting page.

After:

- Log of discussion is posted online.
- I will type an accessible summary for the community at large on
http://bitcoinmedia.com/
- Next weekly meeting is scheduled.

Amir Taaki

*We can go over this hour, but this is to stop meetings dwindling off topic
into banal banter and stay focused.

--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Protocol extensions

2011-12-18 Thread Amir Taaki
Has anyone considered 'snapshot' frames (blocks).

Message to node:

getsnapshot: hash

Node responds with a 'block' message.

Then the hash for that particular snapshot is hardcoded into the sourcecode. It 
would replace the checkpoints and use the last hash in that list.

Validating blocks is pretty fast right up until block 135k, which is where time 
taken balloons and starts become exponentially slower. As blockchain grows 
linearly, resources needed grows exponentially if you think about it.




 From: Alan Reiner etothe...@gmail.com
To: bitcoin-development@lists.sourceforge.net 
Sent: Sunday, December 18, 2011 6:06 PM
Subject: Re: [Bitcoin-development] Protocol extensions
 

The whole point of having headers built at a constant size and generation rate 
is to minimize the amount of data needed to understand of the blockchain 
while simultaneously maximizing integrity/security in the presence of untrusted 
nodes.  Barring the 50%-attack, you only need a couple honest nodes out of 50 
to stay safe (as long as you're waiting for your 6 confirmations).   In fact, I 
would argue that a full node (Satoshi client), has the same level of security 
as a headers-only client... because they both base all their verification 
decisions on computations that end with comparing hashes to the longest-chain 
headers.

In the case that an attacker figures out how to isolate your node
entirely and start feeing you poisoned blocks, then you are
vulnerable with any kind of node, full or lightweight.  I don't see
where the reduced security is.  

The only issue I see is that a truly light-weight, headers-only node
will be having to download an entire block to get one transaction it
needs.  This would be significantly alleviated if nodes can start
requesting merkle-trees directly, even without
merkle-branch-pruning.   If a node can ask for a tx and the
tx-hash-list of the block that incorporated that tx,  he can easily
verify his tx against his no-need-to-trust-anyone headers, and
doesn't have to download MBs for every one.  

As for blockchain pruning... I think it's absolutely critical to
find a way to do this, for all nodes.  I am swayed by Dan Kaminsky's 
scalability warnings, and my instinct tells me that leaving full verification 
to a select few deep-pockets nodes in the future opens up all sorts of 
centralization/power-corporation issues that is contrary to the Bitcoin 
concept.  It is in everyone's best interest to make it as easy as possible for 
anyone to act as a full node (if possible).  As such, I believe that the 
current system of minimizing TxOut size is the right one.  TxIns take up 0 
bytes space in the long-run when taking into account any blockchain 
pruning/snapshot idea (except for nLocktime/seq transactions where the TxIn 
might have to be saved).  

-Alan





On 12/18/2011 12:09 PM, theymos wrote: 
On Sat, Dec 17, 2011, at 05:27 PM, Jordan Mack wrote: 
I don't like the idea of a header only client, unless this is just an
interim action until the full block chain is downloaded in the
background. Development of these types of clients is probably
inevitable, but I believe that this breaks the most fundamental
aspects of Bitcoin's security model. If a client has only headers, it
cannot do full verification, and it is trusting the data from random
anonymous peers. 
A headers-only client is much better than trusting anyone, since an
attacker needs 50% of the network's computational power to trick
such clients. For everyone to keep being a full node, hardware costs would need 
to
constantly go down enough for all nodes to be able to handle enough
transactions to meet demand. If hardware doesn't become cheap enough
quickly enough, either some people would be unable to handle being full
nodes, or the max block size wouldn't rise enough to meet demand and
transaction fees would become noncompetitive. 
--
Learn Windows Azure Live!  Tuesday, Dec 13, 2011
Microsoft is holding a special Learn Windows Azure training event for 
developers. It will provide a great way to learn Windows Azure and what it 
provides. You can attend the event by watching it streamed LIVE online.  
Learn more at http://p.sf.net/sfu/ms-windowsazure
___
Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net 
https://lists.sourceforge.net/lists/listinfo/bitcoin-development 

--
Learn Windows Azure Live!  Tuesday, Dec 13, 2011
Microsoft is holding a special Learn Windows Azure training event for 
developers. It will provide a great way to learn Windows Azure and what it 
provides. You can attend the event by watching it streamed LIVE online.  
Learn more at http://p.sf.net/sfu/ms-windowsazure
___

Re: [Bitcoin-development] [BIP 15] Aliases

2011-12-15 Thread Amir Taaki
This is maybe the best idea. I added it:
https://en.bitcoin.it/wiki/BIP_0015#IP_Transactions

Things I like about this:
- IP transactions are useful, but have a security flaw. This mitigates their 
security problems.
- The code for IP transactions is already in Satoshi client. If other clients 
want to add IP transactions, then it can be done with minimal fuss/bloat.
I feel that for any protocol extension, less is more. The less code 
needed, the better the extension. Not always but generally we want to 
avoid bitcoin protocol bloat which *will* happen far in the future. The 
only way to mitigate how spaghettified the standard will be in the 
future, is by careful cautious planning now.

- We can have a proxy node running 24/7 for us, serving our public keys in lieu 
of us.




 From: theymos they...@mm.st
To: bitcoin-development@lists.sourceforge.net 
Sent: Thursday, December 15, 2011 7:59 PM
Subject: Re: [Bitcoin-development] [BIP 15] Aliases
 
Bitcoin already has code and a protocol for transactions to IP
addresses. Why not reuse that for dynamic address lookup? Just a few
changes are necessary to enable complete u...@server.com handling:
- Extend the protocol so that reply messages can be signed by a fixed
  public key
- Extend checkorder messages so they can specify an account to
  send BTC to. Or standardize on how to put the account into the
  message field.
- Enable DNS lookups for IP transactions. The DNS-only proposals could
  also be used here to avoid having to use the IP transaction protocol
  sometimes. The public key for signing reply messages can be gotten
  from TXT records. This will be safe with DNSSEC and Namecoin. With
  plain DNS Bitcoin could take a SSH-like approach and ask the user to
  verify the public key the first time it is used, remembering it later.

DoS attacks are already handled by the IP transactions code: the same IP
address is always given the same bitcoin address until it pays to that
bitcoin address.

--
10 Tips for Better Server Consolidation
Server virtualization is being driven by many needs.  
But none more important than the need to reduce IT complexity 
while improving strategic productivity.  Learn More! 
http://www.accelacomm.com/jaw/sdnl/114/51507609/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development--
10 Tips for Better Server Consolidation
Server virtualization is being driven by many needs.  
But none more important than the need to reduce IT complexity 
while improving strategic productivity.  Learn More! 
http://www.accelacomm.com/jaw/sdnl/114/51507609/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] [BIP 15] Aliases

2011-12-12 Thread Amir Taaki
I wrote this pre-draft:


https://en.bitcoin.it/wiki/BIP_0015

It's merely a starter for discussions.

Aliases are a way to lookup bitcoin addresses so I can type gen...@genjix.net 
instead of 1jkddsjdskjwnk2j3kj232kjdkj


--
Learn Windows Azure Live!  Tuesday, Dec 13, 2011
Microsoft is holding a special Learn Windows Azure training event for 
developers. It will provide a great way to learn Windows Azure and what it 
provides. You can attend the event by watching it streamed LIVE online.  
Learn more at http://p.sf.net/sfu/ms-windowsazure
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Fwd: [BIP 15] Aliases

2011-12-12 Thread Amir Taaki
 I'm confused about the problem we're trying to solve.

I was in brmlab and wanted to pay 1 BTC for a Club Mate. They had on the wall a 
picture of their QR code and a bitcoin address. I don't own a mobile phone so 
the QR code is 
useless. Then I remembered FirstBits, went to my terminal and typed 
1brmlab. I got their bitcoin address from the website and copied that, 
then opened my terminal and pasted that in to send 1 BTC.

And 
these proposals for Namecoin, would make bitcoin implementations 
dependent on unproven technology. HTTPS/DNSSEC have been around a long 
time and are responsible for many mission critical systems. There's a 
lot of momentum behind those projects. Namecoin by contrast, could die 
tomorrow. And it isn't a big deal that they're centralised. This is a 
convenience for end users and does not affect the core system much.

tl;dr: usability


--
Systems Optimization Self Assessment
Improve efficiency and utilization of IT resources. Drive out cost and 
improve service delivery. Take 5 minutes to use this Systems Optimization 
Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] BIP 0001 now active

2011-11-10 Thread Amir Taaki
I put the status for BIP 0001 to active now. Let me know if there's any 
disagreements with this. I'm on Freenode under the nickname genjix
--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Lock protocol version numbers

2011-11-05 Thread Amir Taaki
From talking with Patrick Strateman (phantomcircuit), he suggested this idea 
(which I will elaborate more on in the BIP):


User-agent strings are a good starting point, however they aren't easy for 
parsing so we'll make a small modification to them.

We need a hierarchy from protocol, variant, gui, flavour, build

/Satoshi:314700/bitcoin-qt:0.4/

How does that sound? In BitcoinJ's case:

/BitcoinJ:0.2/AndroidBuild:0.8/

Thoughts:

- Do we need a freely defined comments field?

/BitcoinJ:0.2[iPad; U; CPU OS 3_2_1]/AndroidBuild:0.8/
/Satoshi:314700/bitcoin-qt:0.4[Ubuntu Oneiric]/




From: Christian Decker decker.christ...@gmail.com
To: Mike Hearn m...@plan99.net
Cc: Amir Taaki zgen...@yahoo.com; bitcoin-development@lists.sourceforge.net 
bitcoin-development@lists.sourceforge.net
Sent: Saturday, November 5, 2011 2:45 PM
Subject: Re: [Bitcoin-development] Lock protocol version numbers


On BitDroid I stopped updating the protocol version at 31700 and set the string 
to be both Version and Client, just like BitcoinJ :-)


On Sat, Nov 5, 2011 at 3:32 PM, Mike Hearn m...@plan99.net wrote:

BitCoinJ already sets the subver field to its name and version.


--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Lock protocol version numbers

2011-11-02 Thread Amir Taaki
Hey,

Can we lock the version numbers to be the protocol version (which changes 
rarely) and instead use the sub_version_num field + revision number for 
individual builds?

Satoshi 0.4
BitcoinJava 120311
bitcoin-js 6

Like so. Otherwise we will have version bumping insanity :)
--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Lock protocol version numbers

2011-11-02 Thread Amir Taaki
Point taken.

About the sub_version_num though. I prefer to let the field by defined clients 
however they wish, with just a guideline suggestion that IDENTIFIER VERSION is 
a format they should follow.

The idea being that different projects would have different release scheduling 
schemes and it'd be restrictive to lock people into the popular major.minor 
system.

So for the current bitcoin to find out the version number of other clients (if 
it was needed), it would have to parse the number from the string:

Satoshi 0.5

Although there would be little reason for this with a sane protocol versioning 
scheme.

If we're agreed then I'll start on that BIP.




From: Gavin Andresen gavinandre...@gmail.com
To: Amir Taaki zgen...@yahoo.com
Sent: Wednesday, November 2, 2011 9:34 PM
Subject: Re: [Bitcoin-development] Lock protocol version numbers

Good idea.

Sounds perfect for a BIP

On Wed, Nov 2, 2011 at 5:23 PM, Amir Taaki zgen...@yahoo.com wrote:
 Hey,
 Can we lock the version numbers to be the protocol version (which changes
 rarely) and instead use the sub_version_num field + revision number for
 individual builds?

-- 
--
Gavin Andresen--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Lock protocol version numbers

2011-11-02 Thread Amir Taaki
Bitcoin is the protocol. The client protocol identifier needs a unique name. It 
is not a public name that anybody ever sees except protocol developers.

For instance with libbitcoin, there might be several clients using it, but 
they'd all have the same protocol identifier.

I think calling it Satoshi is apt homage to the person who made the original 
client reference protocol.

Satoshi
BitcoinCommunityOriginal
...

Take your pick.




From: Luke-Jr l...@dashjr.org
To: bitcoin-development@lists.sourceforge.net 
bitcoin-development@lists.sourceforge.net
Cc: Amir Taaki zgen...@yahoo.com
Sent: Wednesday, November 2, 2011 10:46 PM
Subject: Re: [Bitcoin-development] Lock protocol version numbers

On Wednesday, November 02, 2011 6:33:12 PM Amir Taaki wrote:
 Satoshi 0.5

What is Satoshi 0.5 anyway? 0.5's server is bitcoind and GUI is Bitcoin-Qt; 
the wx GUI client is gone, which is more or less what Satoshi referred to in 
the past...--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Bitcoin Wiki

2011-10-27 Thread Amir Taaki
Anybody know how to contact MT about getting it back online? I still haven't 
finished copy-editing the BIPs and need access to them since there's a new one 
to be added.
--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] My thoughts on DoS code

2011-10-02 Thread Amir Taaki
Hey,

The Zen of Python is relevant here: http://www.python.org/dev/peps/pep-0020/

In the face of ambiguity, refuse the temptation to guess.

If a node incorrectly implements the standard then it should be shunned 
immediately. Not only is this more secure, but it will ensure long term 
compatibility between different implementations. Gavin argues that being a bit 
lenient makes it easier for people working on other implementations.

I'd argue the opposite being the only person that's working on a full node 
implementation. Lucky I know my way around the code, so I don't have to guess. 
But if I did not things would be much harder. Imagine you're trying to interact 
with this protocol and then randomly it will suddenly disconnect you because of 
accumulated errors that have been building up.

Everything should be strict, explicit, unambiguous and loud.

I propose a new message type: error Payload is a uint64_t error_code and 
var_str reason.

Before disconnecting a node you can send it an error message. The error_code is 
the main class of error- i.e version_sent_twice. Reason is just an 
implementation specific string that can add context.

Other possible fields:
uint8_t seriousness (debug, info, warning, error, fatal)
uint8_t action_taken (disconnect, blacklist, .etc)


--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development