[Bitcoin-development] GBT 2.0 wishlist

2014-04-29 Thread Luke-Jr
Let's try to get GBT 2.0 off the ground finally.. :)

Here's some wishlist items/ideas:
- Extremely low bandwidth use (binary protocol, with compression support)
- UDP-based transport protocol? (so message order need not be preserved at the
  expense of latency)
- Ability to instruct miners to insert (username,hash-of-username,hash-of-
  options-array,hash-of-both,etc) in coinbase at a given position (this
  enables cheaper proof-of-work auditing of a pool's rewards; it can just
  save/publish shares meeting higher targets and anyone can verify the shares
  were found by a given username/hash)
- Always encrypted (once by the server), with optional authentication via
  CA/namecoin/URI
- Incrementing precommit id so miners can precommit to settings without 
  needing a new/custom coinbase
- Multiple clients should share bandwidth on a LAN (similar to slush's stratum
  proxy)
- Convey prevblock as block header so we can follow blockchains securely.
- Fee logic: pools can claim as much coinbase distribution as they require
  (with hint from miner); miners are expected to ensure subsidy + transaction 
  fees tally up to the required total; any fees beyond requires total may be
  distributed as the miner wishes. Potentially, pools could allow 50% (or
  similar) participation allowing a miner to use multiple pools at the same
  time.

Rather than polluting the main development mailing list with what is sure to 
have quite a bit of discussion, I have asked kinlo (who hosts the poolowners 
mailing list) to provide a dedicated list for this purpose. Interested parties 
should please subscribe via http://list.pfoe.be/mailman/listinfo/gbt2 and send 
replies to g...@list.pfoe.be (once a draft BIP is ready, the main dev mailing 
list will be once again CC'd).

Luke

--
Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.  Get 
unparalleled scalability from the best Selenium testing platform available.
Simple to use. Nothing to install. Get started now for free.
http://p.sf.net/sfu/SauceLabs
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] BIP - Hash Locked Transaction

2014-04-25 Thread Luke-Jr
This one looks entirely useless (it cannot be made secure), and the assertion 
that it is necessary for atomic cross-chain transfers seems unfounded and 
probably wrong...

Luke

On Friday, April 25, 2014 6:49:37 PM Tier Nolan wrote:
 As part of the atomic cross chain system, outputs need to be hash locked.
 
 https://github.com/TierNolan/bips/blob/bip4x/bip-0045.mediawiki
 
 https://bitcointalk.org/index.php?topic=193281.msg2224949#msg2224949
 
 A user needs to provide x corresponding to hash(x) in order to spend an
 output.
 
 Under the protocol, one of the participants is required to provide the
 secret number in order to spend an output.  Once they do that, the other
 participant can use the secret number to spend an output on the other
 chain.  This provides a mechanism to link the 2 chains together (in
 addition to lock times).  Once the first output is spent, that commits the
 transfer.
 
 This is half of the scripting operations required to implement the
 protocol.
 
 The proposal is to make this an adder on to the other standard
 transactions.  It does a check that the hash matches, and then runs the
 standard transaction as normal.
 
 Adding the prefix to a P2SH transactions wouldn't work, since the template
 wouldn't match.
 
 A script of this form could be embedded into a P2SH output.
 
 I think that is ok, since embedding the password in the hashed script
 gets all the benefits.
 
 If there is agreement, I can code up the reference implementation as a PR.

--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] BIP - Selector Script

2014-04-25 Thread Luke-Jr
I believe you meant to link here instead?
https://github.com/TierNolan/bips/blob/bip4x/bip-0046.mediawiki

This looks reasonable from a brief skim over, but does not define any use 
cases (it mentions necessary for atomic cross chain transfers, but does not 
explain how it is useful for that - perhaps that belongs in another BIP you 
haven't written yet, though). IMO, it should also require P2SH.

Luke


On Friday, April 25, 2014 6:49:35 PM Tier Nolan wrote:
 This is a BIP to allow the spender to choose one of multiple standard
 scripts to use for spending the output.
 
 https://github.com/TierNolan/bips/blob/bip4x/bip-0045.mediawiki
 
 This is required as part of the atomic cross chain transfer protocol.  It
 is required so that outputs can be retrieved, if the process ends before
 being committed.
 
 https://bitcointalk.org/index.php?topic=193281.msg2224949#msg2224949
 
 The script allows multiple standard scripts to be included in the
 scriptPubKey.
 
 When redeeming the script the spender indicates which of the standard
 scripts to use.
 
 Only one standard script is actually executed, so the only cost is the
 extra storage required.
 
 A more ambitious change would be a soft fork like P2SH, except the spender
 is allowed to select from multiple hashes.  Effectively, it would be
 Multi-P2SH.
 
 This gets much of the benefits of MAST, but it requires a formal soft fork
 to implement.
 
 If there is agreement, I can code up the reference implementation as a PR.
 The multi-P2SH might actually be easier.

--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] BIP - Selector Script

2014-04-25 Thread Luke-Jr
On Friday, April 25, 2014 8:02:41 PM Tier Nolan wrote:
 I don't think the cross chain system needs a BIP (except to justify this
 one).
 
 If cross chain transfer become popular, then it would be useful to ensure
 that clients are interoperable, but first things first.  If the
 transactions aren't accepted in any chains, then everything stalls.

I think you may be misunderstanding what BIPs are. They do not force nodes to 
take on any given relay/mining policy (thus, BIPs should never talk about 
IsStandard at all). They define standard for interoperability between 
software. So, if you want nodes to relay these transactions, you need to 
convince them, not merely write a BIP for the transaction format. Defining a 
BIP for cross-chain trading would be one way to do that.

 Secure transfers require that the malleability issue is fixed, but that is
 a separate issue.  I am assuming that will be fixed at some point in the
 future, since micro-payment channels also requires that it is fixed.

The malleability issue has been known for years.
I wouldn't expect any special effort made to fix it...

 A soft fork that expands P2SH functionality would be even better, but I
 would rather not let the best be the enemy of the good.

There is some ongoing discussion of a softfork to basically redo the Script 
language entirely, but it will take quite a bit of time and development before 
we'll see it in the wild.

Luke

P.S. Did the BIP editor assign these numbers? If not, best to keep them 
numberless until assigned, to avoid confusion when people Google the real BIP 
44 and 45...

--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] New BIP32 structure

2014-04-23 Thread Luke-Jr
On Wednesday, April 23, 2014 7:29:04 PM Pavol Rusnak wrote:
 On 04/23/2014 09:00 PM, Tier Nolan wrote:
  The point is to have a single system that is compatible over a large
  number of systems.
 
 There is such system and it is called BIP32.
 
 On the other hand, in BIP64 we try to put a set of restrictions and
 rules on top of BIP32. There will always be some special usecases where
 BIP64 is not a good fit and there's no reason why you cannot use BIP32
 in a different manner using a different purpose field.
 
 Examples: Electrum does not want to use accounts and they start to use
 scheme m/65'/change/address (where change = 0 or 1). Or Andreas
 Schildbach wants to have refunds chain so he uses m/66'/chain/address
 (where chain = 0, 1 or 2).
 
 We wanted to find one good solution that fits all, but unfortunately it
 turned out everyone wants something a little bit different.

Why do clients need to use the features in BIP 64? If Electrum doesn't want to 
use accounts, then it can just use account 0 for everything. Refund chains are 
definitely a third case that should be added to the external and 
internal/change address division... and a wallet not implementing refund 
addresses would simply not use that chain.

Luke

--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] New BIP32 structure

2014-04-23 Thread Luke-Jr
On Wednesday, April 23, 2014 7:49:38 PM Pavol Rusnak wrote:
 On 04/23/2014 09:44 PM, Luke-Jr wrote:
  Why do clients need to use the features in BIP 64? If Electrum doesn't
  want to use accounts, then it can just use account 0 for everything.
  Refund chains are
 
 As Andreas wrote earlier in this thread: There is no bare minimum.
 Either you implement the BIP fully or not.
 
 What you suggest does not follow the principle of least surprise.
 Suppose user imports his BIP64 compatible wallet into Electrum, which
 claims it is BIP64 compatible, but actually implements just a subset of
 the spec (sticking account index to 0). The user now sees just a
 fraction of his coins and is puzzled.

Any wallet should import all the coins just fine, it just wouldn't *use* any 
account other than 0. Remember addresses are used to receive bitcoins; once 
the UTXOs are in the wallet, they are no longer associated with the address or 
any other details of how they were received.

Luke

--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] New BIP32 structure

2014-04-23 Thread Luke-Jr
On Wednesday, April 23, 2014 7:57:46 PM slush wrote:
 On Wed, Apr 23, 2014 at 9:55 PM, Luke-Jr l...@dashjr.org wrote:
  Any wallet should import all the coins just fine, it just wouldn't *use*
  any
  account other than 0. Remember addresses are used to receive bitcoins;
  once the UTXOs are in the wallet, they are no longer associated with the
  address or
  any other details of how they were received.
 
 Wallet don't see UTXO until it scans all branches/accounts on HD node
 import.

Yes, it should scan all possible (under the BIP-defined structure) branches 
regardless of which features it supports.

Luke

--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] New BIP32 structure

2014-04-23 Thread Luke-Jr
On Wednesday, April 23, 2014 8:01:16 PM Tamas Blummer wrote:
 On 23.04.2014, at 21:55, Luke-Jr l...@dashjr.org wrote:
  Any wallet should import all the coins just fine, it just wouldn't *use*
  any account other than 0. Remember addresses are used to receive
  bitcoins; once the UTXOs are in the wallet, they are no longer
  associated with the address or any other details of how they were
  received.
 
 This is a bit idealistic.
 The wallet has to know how it got the UTXO in order to be able to spend it.

No it doesn't... Just the assigned scriptPubKey and secret(s) required to 
satisfy it.

--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] New BIP32 structure

2014-04-23 Thread Luke-Jr
On Wednesday, April 23, 2014 8:04:03 PM Pavol Rusnak wrote:
 On 04/23/2014 10:01 PM, Luke-Jr wrote:
  Yes, it should scan all possible (under the BIP-defined structure)
  branches regardless of which features it supports.
 
 So you suggest to scan for accounts, show balances but don't allow user
 to spend them? Does not seem right to me.

Scan all branches for UTXOs, then you have the balance for the wallet. Account 
balances are metadata, so cannot be known from the seed alone. If you want to 
have a way to restore accounts, you must define some more detailed wallet file 
format (which could be built on top of this).

On Wednesday, April 23, 2014 8:04:35 PM you wrote:
 On 23.04.2014, at 22:02, Luke-Jr l...@dashjr.org wrote:
  On Wednesday, April 23, 2014 8:01:16 PM Tamas Blummer wrote:
  The wallet has to know how it got the UTXO in order to be able to spend
  it.
  
  No it doesn't... Just the assigned scriptPubKey and secret(s) required to
  satisfy it.
 
 To know the secret it needs to know which key coordinate to use that is
 logically the same as knowing the address it used to receive it.

Sure, it *knows* what address was used to receive it. But at the point it's a 
UTXO, that address is no longer relevant.

Luke

--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] New BIP32 structure

2014-04-23 Thread Luke-Jr
On Wednesday, April 23, 2014 8:16:45 PM Pavol Rusnak wrote:
 On 04/23/2014 10:09 PM, Luke-Jr wrote:
  Scan all branches for UTXOs, then you have the balance for the wallet.
  Account balances are metadata, so cannot be known from the seed alone.
  If you want to have a way to restore accounts, you must define some more
  detailed wallet file format (which could be built on top of this).
 
 I think one of the following is happening:
 
 a) you have not read the document
 b) you don't understand what accounts are, because you have not read
the document
 c) you don't understand how restoring accounts work, because you
have not read the document
 d) you don't understand that accounts funds are not meant to be mixed
together, because you have not read the document
 e) I got your emails wrong because I am not a native speaker,
but please read the the document ;-)

You missed one:
f) I missed the part where BIP 32 redefined account to mean subwallet 
instead of what has traditionally been called account in Bitcoin.

:)

In that case, single-subwallet wallet software probably needs to have the user 
provide a subwallet number in addition to the seed.

Luke

--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] New BIP32 structure

2014-04-23 Thread Luke-Jr
On Wednesday, April 23, 2014 8:35:50 PM Pavol Rusnak wrote:
 On 04/23/2014 10:32 PM, Luke-Jr wrote:
  f) I missed the part where BIP 32 redefined account to mean subwallet
  instead of what has traditionally been called account in Bitcoin.
 
 Ah, okay. The last time I saw Bitcoin-qt it was still using independent
 addresses.

It is. Accounts have been a bitcoind feature since before 0.4.

  In that case, single-subwallet wallet software probably needs to have the
  user provide a subwallet number in addition to the seed.
 
 Which brings us back to my original complaint that the user can be
 confused because he doesn't see all his funds.

I don't see how. The user knows he has money in different subwallets. As long 
as he has a way to specify which subwallet he is accessing in single-subwallet 
clients, there shouldn't be a problem.

Luke

--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] New BIP32 structure

2014-04-23 Thread Luke-Jr
On Wednesday, April 23, 2014 8:43:57 PM Pavol Rusnak wrote:
 On 04/23/2014 10:41 PM, Luke-Jr wrote:
  I don't see how. The user knows he has money in different subwallets. As
  long as he has a way to specify which subwallet he is accessing in
  single-subwallet clients, there shouldn't be a problem.
 
 Right. But these clients have no right to call themselves BIP64
 compatible then.

Then BIP 64 is pretty restrictive. Most end users really have no need for 
subwallet support.

--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] New BIP32 structure

2014-04-23 Thread Luke-Jr
On Wednesday, April 23, 2014 9:33:48 PM Pavol Rusnak wrote:
 On 04/23/2014 11:22 PM, Gregory Maxwell wrote:
  Hopefully it would be clarified as only a MUST NOT do so silently...
  I have funds split across two wallets and it WONT LET ME SPEND THEM
  sounds like a terrible user experience. :)
 
 That is a subjective matter. To me it makes PERFECT SENSE that funds
 across accounts NEVER MIX. One can still send funds from one account to
 another and then perform another spend.

Only by crossing the blockchain unnecessarily.

 That's what I consider a consistent and thus GOOD user experience.
 What's the purpose of Accounts if wallet mixes coins among them anyway?

To keep balances separated. For example, I might have an account for each of 
my children, move their allowance money to it every day/week (off-chain), and 
they can spend only what they have in their account. Or an exchange might have 
an account for each user's deposits. In neither case, would it make sense to 
pay special attention to which UTXOs are consumed in transactions from any of 
the account.

The only use case that requires tracking UTXOs per-account is when you want to 
have multiple uncoordinated copies of the wallet in use at the same time, and 
therefore need to immediately identify which account a transaction came from 
based on the UTXOs it consumed - although even then, you could still mix funds 
as long as you use only the first UTXO for tracking, so maybe there isn't even 
a niche use case! In any case, Trezor, being a hardware wallet, should never 
overlap with this niche...?

 I know it's not good to use classic bank accounts as analogy, but that's
 exactly how they work. Or have you every done ONE transaction from two
 bank accounts simultaneously?

Bad analogy. Banks *always* mix funds. You don't expect your bank wire to use 
exactly the specific dollar bills you deposited, do you??

Luke

--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Ubuntu LTS Packaging?

2014-04-12 Thread Luke-Jr
On Saturday, April 12, 2014 2:26:07 PM Oliver Egginger wrote:
 Hello,
 
 so far, nothing yet?
 
 See: https://launchpad.net/~bitcoin/
 
 I'm developing currently a LiveCD for hot/cold wallet management on
 Ubuntu LTS basis. For critical vulnerabilities I have to provide timely
 updates. I have now decided to maintain my own repository for this
 project. If there are better alternatives, let me know.

This mailing list is for development, not support.

The PPA you linked has 0.9.0, which is the latest relevant version for 
packaging.

Luke

--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test  Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Finite monetary supply for Bitcoin

2014-04-01 Thread Luke-Jr
On Tuesday, April 01, 2014 7:00:07 PM Pieter Wuille wrote:
 Hi all,
 
 I understand this is a controversial proposal, but bear with me please.
 
 I believe we cannot accept the current subsidy schedule anymore, so I
 wrote a small draft BIP with a proposal to turn Bitcoin into a
 limited-supply currency. Dogecoin has already shown how easy such
 changes are, so I consider this a worthwhile idea to be explored.
 
 The text can be found here: https://gist.github.com/sipa/9920696
 
 Please comment!

I cleaned it up a bit. By 2214, we should be using tonal numbers after all:

https://gist.github.com/luke-jr/9920788

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Finite monetary supply for Bitcoin

2014-04-01 Thread Luke-Jr
Please, *music* is obsolete, but inline replies *are not*!

On Tuesday, April 01, 2014 7:16:42 PM Benjamin Cordes wrote:
 luke, you might enjoy the book Topos of Music. It's a complete
 mathematical music theory by a student of Grothendieck. He advanced
 Euler's theories of harmony based on advanced category theory. I'm
 sure there are many applications to Bitcoin.
 
 On Tue, Apr 1, 2014 at 9:12 PM, Luke-Jr l...@dashjr.org wrote:
  On Tuesday, April 01, 2014 7:00:07 PM Pieter Wuille wrote:
  Hi all,
  
  I understand this is a controversial proposal, but bear with me please.
  
  I believe we cannot accept the current subsidy schedule anymore, so I
  wrote a small draft BIP with a proposal to turn Bitcoin into a
  limited-supply currency. Dogecoin has already shown how easy such
  changes are, so I consider this a worthwhile idea to be explored.
  
  The text can be found here: https://gist.github.com/sipa/9920696
  
  Please comment!
  
  I cleaned it up a bit. By 2214, we should be using tonal numbers after
  all:
  
  https://gist.github.com/luke-jr/9920788
  
  -
  - ___
  Bitcoin-development mailing list
  Bitcoin-development@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Handling miner adoption gracefully for embedded consensus systems via double-spending/replace-by-fee

2014-03-24 Thread Luke-Jr
On Saturday, March 22, 2014 8:47:02 AM Peter Todd wrote:
 To make a long story short, it was soon suggested that Bitcoin Core be
 forked - the software, not the protocol - and miners encouraged to
 support it.

There's been at least one public miner-oriented fork of Bitcoin Core since 0.7 
or earlier. Miners still running vanilla Bitcoin Core are neglecting their 
duty to the community. That being said, the more forks, the better for 
decentralisation.

Luke

--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] moving the default display to mbtc

2014-03-13 Thread Luke-Jr
On Thursday, March 13, 2014 4:37:02 PM slush wrote:
 Display based on locale.

Please don't bring locale into this. Bitcoin has always been intentionally 
locale-independent (hence BTC using xxx,xxx,xxx.xx format even in locales 
which swap the commas and periods). Localising display makes different locales 
more or less incompatible at a human level, even if they use the same 
blockchain.

Luke

--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] New side channel attack that can recover Bitcoin keys

2014-03-08 Thread Luke-Jr
On Wednesday, March 05, 2014 4:21:52 PM Kevin wrote:
 How can we patch this issue?

No need, it is not an issue for Bitcoin.

Properly used, there is only ever one signature per public key.

Luke

--
Subversion Kills Productivity. Get off Subversion  Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works. 
Faster operations. Version large binaries.  Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Procedure for non-tech contributions

2014-03-02 Thread Luke-Jr
On Sunday, March 02, 2014 11:02:14 PM Tom Geller wrote:
 Peter writes:
  MtGox does host the bitcoin wiki, so yes, the funds probably do go to a
  wallet held by MtGox in some fashion.
 
 The foolishness of sending a payment to a Mt. Gox-held wallet -- which is
 required to edit the wiki -- strikes me as a pressing issue. If I
 understand it correctly, this is a hard blocker that'll stop *all* new
 contributors. Further, I registered for the wiki and never got my
 confirmation email. Methinks the whole thing is broken. :(

We've been working on moving the wiki to new hosting, but it isn't a very high 
priority (at least for MtGox). PM SomeoneWeird on IRC, as he is currently 
handling manually approving new accounts for editing.

Luke

--
Subversion Kills Productivity. Get off Subversion  Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works. 
Faster operations. Version large binaries.  Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] New to this list

2014-03-02 Thread Luke-Jr
On Monday, March 03, 2014 3:34:27 AM Kevin wrote:
 Hello.  I am a developer and I wish to contribute to bitcoin.  Where is
 the best place to start?

Unit tests. This will be valuable to the projects and also help you learn how 
things work.

--
Subversion Kills Productivity. Get off Subversion  Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works. 
Faster operations. Version large binaries.  Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] On OP_RETURN in upcoming 0.9 release

2014-02-24 Thread Luke-Jr
On Monday, February 24, 2014 11:06:30 PM Andreas Petersson wrote:
 Regarding 80 bytes vs smaller: The objectives should be that if you are
 determined to put some extra data in the blockchain, OP_RETURN should be
 the superior alternative. if a user can include more data with less fees
 using a multisig TX, then this will happen.
 
 eventually dust-limit rules will not be the deciding factor here, since
 i suspect block propagation times will have a stronger effect on
 effective fees. therefore a slightly larger payload than the biggest
 multisig TX is the right answer. - that would be = 64x3 bytes = 192 bytes.
 (this is my understanding of how large a 3-of-3 multisig tx can be, plus
 1.5 bits encoded in the n parameter)

Perhaps I ought to redo my data carrier configuration option as a max size?

Luke

--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis  security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability

2014-02-12 Thread Luke-Jr
On Wednesday, February 12, 2014 8:27:52 PM Mark Friedenbach wrote:
 On 02/12/2014 08:44 AM, Alan Reiner wrote:
  Changing the protocol to use these static IDs is a pretty fundamental
  change that would never happen in Bitcoin.   But they can still be
  useful at the application level to mitigate these issues.
 
 Not to mention that it would be potentially very insecure to have
 consensus depend on data (scriptSigs) which are not hashed in the Merkle
 structure of a block.
 
 Not that anyone on this list has suggested such a change, but I've seen
 it raised multiple times on the forum

This would be a problem if it was used in the merkle tree, but I'm pretty sure 
using it for input selection would be pretty safe. One could even avoid the 
index by simply using the hashScript as the sole input value; then even 
CoinJoins would be safe without breaking chains of transactions (although this 
would break address reuse entirely - but I don't see that as a problem in a 
theoretical world). One of those things that an altcoin could improve upon 
Bitcoin with... ;)

--
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Embedded consensus system upgrade procedures

2014-02-09 Thread Luke-Jr
On Sunday, February 09, 2014 5:12:14 PM Peter Todd wrote:
 We have an embedded consensus system and we want to be able to upgrade
 it with new rules.

This asserts a central authority and gives developers too much power.

--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121051231iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability

2014-02-09 Thread Luke-Jr
On Sunday, February 09, 2014 11:33:02 PM Pieter Wuille wrote:
 The proposed document is here: https://gist.github.com/sipa/8907691

Rule 3  4 are already enforced.

AFAIK nVersion==3 transactions are not currently considered non-standard?

Luke

--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121051231iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] BIP0039: Final call

2014-01-20 Thread Luke-Jr
On Monday, January 20, 2014 5:42:37 PM slush wrote:
 Hi all,
 
 during recent months we've reconsidered all comments which we received from
 the community about our BIP39 proposal and we tried to meet all
 requirements for such standard. Specifically the proposal now doesn't
 require any specific wordlist, so every client can use its very own list of
 preferred words. Generated mnemonic can be then applied to any other
 BIP39-compatible client. Please follow current draft at
 https://github.com/trezor/bips/blob/master/bip-0039.mediawiki.

How are they compatible if they could be using entirely different word lists??

 Because we're quickly moving towards release of Trezor firmware and we need
 to finalize this part of the firmware, we're asking for the last comments
 to current BIP39 draft.

Maybe I'm missing something, but shouldn't this be a client-side thing, not 
implemented in the Trezor firmware at all?? O.o;;

Luke

--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Bitcoin Core 0.9rc1 release schedule

2014-01-17 Thread Luke-Jr
On Friday, January 17, 2014 8:53:47 PM Jeff Garzik wrote:
 vendor hat: on  BitPay sure would like to see CPFP in upstream.
 
 I think the main hurdle to merging was that various people disagreed
 on various edge case handling and implementation details, but no
 fundamental objections.

Heck, even I disagree with implementation details, but it's still better than 
nothing. We can always merge major reorganisations/reimplementations later 
when they're written: merging this one doesn't mean we're stuck with it 
forever...

Luke

--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Bitcoin Core 0.9rc1 release schedule

2014-01-16 Thread Luke-Jr
On Thursday, January 16, 2014 9:09:52 AM Wladimir wrote:
 Hello all,
 
 It has been way to long since last major release. Many improvements and new
 features have been added to master since, so we'd like to do a 0.9rc1
 release soon.
 
 The current aim is next month, February 2014.
 
 Of course there are still some open issues that need to be resolved before
 release
 https://github.com/bitcoin/bitcoin/issues?milestone=12state=open
 
 If there is something else that you're working on and needs to end up in
 0.9, or know of some nasty bug in master that should absolutely be solved
 first, please tell.
 
 Wladimir

https://github.com/bitcoin/bitcoin/pulls/luke-jr

These are pretty much all well-tested and stable for months now.

--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Suggestion: allow receivers to pay optional fee for transactions without fees

2014-01-16 Thread Luke-Jr
On Friday, January 17, 2014 2:39:31 AM Christophe Biocca wrote:
 To clarify, there are proposals to make miners recognize this
 situation and account for it, only eligius is running it at the moment
 IIRC:
 http://bitcoin.stackexchange.com/questions/8390/are-there-any-pools-or-larg
 e-miners-running-child-pays-for-parent-patch Right now if you were to try
 it likely wouldn't result in inclusion. But this is on the radar, and I
 suspect it'll eventually get merged into mainline.

If you did it and relayed directly to Eligius, it'd probably get mined.. the 
hard part is creating the transaction - once that's done it's smooth sailing 
;)

Side note: mining nodes should *not* be running mainline. In fact, they should 
be setting up their own customised transaction policies.

--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] The insecurity of merge-mining

2013-12-31 Thread Luke-Jr
On Wednesday, January 01, 2014 4:53:42 AM Peter Todd wrote:
 On Tue, Dec 31, 2013 at 01:14:05AM +, Luke-Jr wrote:
  On Monday, December 30, 2013 11:22:25 PM Peter Todd wrote:
   that you are using merge-mining is a red-flag because without majority,
   or at least near-majority, hashing power an attacker can 51% attack
   your altcoin at negligible cost by re-using existing hashing power.
  
  I strongly disagree on this isolated point. Using the same logic, Bitcoin
  is vulnerable to an attacker at negligible cost by re-using existing
  hashing power from mining Namecoin. Any non-scam altcoin is pretty safe
  using merged mining, since any would-be attacker is going to have it in
  their interests to invest in the altcoin instead of attacking it. It's
  only the scam ones that want to pump  dump with no improvements, that
  are really at risk here.
  
  The rational decision for a non-scam altcoin, is to take advantage of
  merged mining to get as much security as possible. There are also some
  possible tricks to get the full security of the bitcoin miners even when
  not all participate in your altcoin (but this area probably needs some
  studying to get right).
 
 You assume the value of a crypto-currency is equal to all miners, it's
 not.
 
 Suppose I create a merge-mined Zerocoin implementation with a 1:1
 BTC/ZTC exchange rate enforced by the software. You can't argue this is
 a scamcoin; no-one is getting rich. There's a 1:1 exchange rate so the
 only thing you can do with the coin is get some privacy. But inevitably
 some miners won't agree that enabling better privacy is a good thing, or
 their local governments won't. Either way, they can attack the Zerocoin
 merge-mined chain with a marginal cost of nearly zero.

Not necessarily. If Zerocoin was tied directly to Bitcoin proof-of-work, the 
worst they could do is not-participate by mining empty blocks.

 OTOH if the Zerocoin scheme was implemented by embedding ZTC
 transactions within standard Bitcoin transactions - even without any
 attempt at hiding them - the attackers would need a 50% majority of
 hashing power to succeed. Of course potentially slow confirmations is a
 trade-off, but that's likely a perfectly OK trade-off in this case.

Potentially slow confirmation is also the only shortcoming of using Bitcoin's 
proof-of-work directly.

Luke

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Looking for GREAT C++ developer for exciting opportunity in bitcoin space

2013-12-30 Thread Luke-Jr
On Monday, December 30, 2013 11:22:25 PM Peter Todd wrote:
 that you are using merge-mining is a red-flag because without majority, or
 at least near-majority, hashing power an attacker can 51% attack your
 altcoin at negligible cost by re-using existing hashing power.

I strongly disagree on this isolated point. Using the same logic, Bitcoin is 
vulnerable to an attacker at negligible cost by re-using existing hashing 
power from mining Namecoin. Any non-scam altcoin is pretty safe using merged 
mining, since any would-be attacker is going to have it in their interests to 
invest in the altcoin instead of attacking it. It's only the scam ones that 
want to pump  dump with no improvements, that are really at risk here.

The rational decision for a non-scam altcoin, is to take advantage of merged 
mining to get as much security as possible. There are also some possible 
tricks to get the full security of the bitcoin miners even when not all 
participate in your altcoin (but this area probably needs some studying to get 
right).

Luke

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] RFC: MERGE transaction/script/process for forked chains

2013-12-17 Thread Luke-Jr
On Tuesday, December 17, 2013 10:41:30 PM Troy Benjegerdes wrote:
 I want to get some feedback.. I've used distributed version control
 systems for a long time, and the most useful feature is to be able
 to merge two different forks.
 
 So what's the equivalent of this for Bitcoin or other crypto-currencies?
 
 Let's suppose that me and my friends get 'islanded' from the rest of
 the internet for a week, but we still want to trade bitcoin. It would
 work if there are local miners, until we reconnect.
 
 Suppose we have the main chain (Alice), while bob is on a boat, trading
 with some friends, but has no network connectivity.
 
 When bob reconnects with Alice, a 'Merge' transaction happens where a
 miner looks at bob's forked blockchain, sees no double-spends, and
 includes BOTH chains.
 
 Now suppose someone on bob's boat has a buggy client, or sent a
 transaction before disconnect that results in a double-spend on the
 merge.
 
 So we have a merge conflict, which generally requires human interaction,
 so bob and his friends broadcast a MERGE request with a transaction fee
 sufficient to cover reconciling the double-spends, AND incentivize a
 miner to do some extra work to merge.
 
 Thoughts everyone?

This is interesting, but I'm not sure it has the right incentives. First, it 
adds more reason for miners to *avoid* including transactions (they might turn 
out to be double-spends and make merging costly). Second, it gives people 
reason to double-spend (the miner might cover the cost of it). Finally, you 
don't appear to address how to deal with the subsidy - do both miners get it?

Luke

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?

2013-12-08 Thread Luke-Jr
On Sunday, December 08, 2013 8:51:07 PM Drak wrote:
 Otherwise, who has admin rights to the code projects
 (github/sourceforge/this mailing list)? Those people have proven they can
 be trusted so far.

Can someone explain how Sirius has proven the least bit untrustworthy?

Luke

--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?

2013-12-08 Thread Luke-Jr
On Sunday, December 08, 2013 9:16:09 PM Saïvann Carignan wrote:
  1) Who pays for it? Most obvious answer: Foundation. However there's
  currently a fairly clear line between the foundation website and the
  bitcoin.org http://bitcoin.org website. I personally am fine with the
  bitcoin foundation funding the website, it's a lot closer to the bitcoin
  community than github. But some people might care. So next step would be
  to contact the Foundation board and see if they're willing to fund it.
 
 Actually I might find way to fund it. But I needed to have ACK 
 comments from developers before anything.
 
 ...
  4) Who admins it?
 
 Obviously, I thought it would be important that the server is owned by
 someone who can be trusted, with ssh access for all core developers.
 
  5) Who controls DNS for it?
 
 I'm not sure we'll get any change on this level. I have no idea if the
 domain is in good hands, except for the fact that nothing bad happened
 thus far. If anything, moving it to core developers (as intended when
 the domain was registered) would make more sense IMO. But again, is it
 possible, I don't know.

I don't think core developers should be directly in control here any more 
than the Foundation should. Developers are good for development, not 
necessarily web or server admin tasks. Only those directly involved in the 
needed roles should have access IMO.

Luke

--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Move authorative source for BIPs to git repository

2013-12-05 Thread Luke-Jr
On Thursday, December 05, 2013 1:37:10 PM Wladimir wrote:
 Hello all,
 
 A while ago after discussion on the mailing list a repository was set up to
 store the BIP documents, as this is deemed a more secure solution than
 having them on the wiki:
 
 https://github.com/bitcoin/bips
 
 To prevent confusion the next step should probably be to replace the BIPs
 on the wiki with links to the github documents, with a notice that changes
 should be proposed on github or mailed to the BIP editor (gmaxwell).
 
 Agreed?

I think this would stifle active BIP draft editing. We're already having a 
hard time getting some developers to write BIPs for their proposals - I don't 
think we should be putting up bigger hurdles.

Luke

--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] moving the default display to mbtc

2013-11-15 Thread Luke-Jr
On Saturday, November 16, 2013 12:41:56 AM Drak wrote:
 So a payment clears after one confirmation, but you might want to wait
 until the payment has been confirmed n times.
 Then at least you are not using the same word for two different meanings
 and you're using stuff more familiar in popular lexicon.
 I dont think it's helpful for users if we use the word blocks.

Confirmations in a numeric context isn't correct, though. We're using to it 
because we've been using Bitcoin so long, but to the average person they would 
expect it to mean something more than it is. If not referring to blocks, then 
perhaps witnessed N times?

 For years, people had a problem with  email address, instead using email
 number but they got there eventually. Most people nowadays use email
 address
 So payment address or bitcoin address make better sense here when
 qualified as a foo address and not just an address
 
 You could also call it payment id, but I dont think invoice id since
 no-one pays to an invoice id that's just a reference for a payment, not the
 destination.
 
 People are very familiar with Paypal these days, and are familiar with
 paypal address or their paypal id so again I think valid contenders are
 bitcoin address or bitcoin id.

I think you might be demonstrating my point with regard to user confusion 
here. Bitcoin addresses are *not* like email addresses, paypal ids, etc. 
Bitcoin addresses aren't the destination - they're point to a destination (an 
account in a wallet), but they also represent information such as who is 
paying and what for - in other words, a specific invoice.

Luke

--
DreamFactory - Open Source REST  JSON Services for HTML5  Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
Free app hosting. Or install the open source package on any LAMP server.
Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] moving the default display to mbtc

2013-11-14 Thread Luke-Jr
On Thursday, November 14, 2013 11:45:51 AM Melvin Carvalho wrote:
 Would now be a good time to start thinking about changing the default
 display in the software.  Perhaps initially it could be a dropdown display
 option, then at some point mbtc becomes the default?

There's already a dropdown display option...

--
DreamFactory - Open Source REST  JSON Services for HTML5  Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
Free app hosting. Or install the open source package on any LAMP server.
Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] moving the default display to mbtc

2013-11-14 Thread Luke-Jr
On Thursday, November 14, 2013 10:07:58 PM Allen Piscitello wrote:
 Obviously the answer is to just display all fees and trading rates as BTC
 or MBTC (.005 MBTC fee? how cheap!).  On a more serious note, the
 transition should definitely be thought out well as it could be very
 damaging to have this confusion, but I would prefer to do it only once
 rather than twice.

I wonder if it might make sense to bundle some other terminology fixups at the 
same time.

Right now, Bitcoin-Qt has been using the term confirmations (plural) to 
refer to how many blocks deep a transaction is buried. We also use the term 
confirmation to refer to the point where a transaction is accepted as paid. 
IMO, the latter use makes sense, but the former leads to confusion especially 
in light of scamcoins which abuse this confusion to claim they have faster 
confirmations, implying that the actual confirmation occurs faster when it 
really doesn't. 5 blocks deep may not be more clear to laymen, but at least 
it makes it harder for people to confuse with actual confirmation.

I think we all know the problems with the term address. People naturally 
compare it to postal addresses, email addresses, etc, which operate 
fundamentally different. I suggest that we switch to using invoice id to 
refer to what is now known as addresses, as that seems to get the more natural 
understanding to people. On the other hand, with the advent of the payment 
protocol, perhaps address/invoice id use will die out soon?

Thoughts?

Luke

--
DreamFactory - Open Source REST  JSON Services for HTML5  Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
Free app hosting. Or install the open source package on any LAMP server.
Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] moving the default display to mbtc

2013-11-14 Thread Luke-Jr
On Thursday, November 14, 2013 10:53:16 PM Alan Reiner wrote:
 I really like the XBT idea.  It makes a lot of sense to match the ISO
 currency symbol (though the ISO guys will have to adjust the way they've
 defined the XBT).  And I do agree that going right to uBTC and
 skipping mBTC makes sense, too.
 
 I'd prefer them not be called micro bitcoins.  I really want to call
 them microbes ... but I'm not sure that has the right flavor for money
 transfer :)  Please give me 872 microbes.  Perhaps we just call them
 bits.  Or even micros or microbits.  As I write this, I realize
 there's probably 872 threads on the forums about this already...
 
 But we would want to promote a consistent term, to avoid further
 confusion when people use different names for the new unit.  It's not
 guaranteed to be successful, but if we pick a good name, and build it
 into the interface on the first release pushing the new unit, we have a
 chance to make the transition even easier.

As long as we're using SI units, IMO we should stick to SI. That means micro-
bitcoins. *Informally/spoken*, an abbreviation like mibicoins might make 
sense.

Luke

--
DreamFactory - Open Source REST  JSON Services for HTML5  Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
Free app hosting. Or install the open source package on any LAMP server.
Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] idea

2013-11-09 Thread Luke-Jr
On Saturday, November 09, 2013 8:16:07 PM Chris Evans wrote:
 maybe add an optional note field to transaction so the receiver knows who
 sent the btc

This mailing list is for development discussion, NOT bug reports nor feature 
requests.

Bitcoin does not currently support any built-in mechanism for conveying the 
sender of a transaction nor notes. It is advised to collect any such 
information you need before giving someone a payment address.

Luke

--
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most 
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Message Signing based authentication

2013-11-02 Thread Luke-Jr
On Sunday, November 03, 2013 1:19:51 AM Allen Piscitello wrote:
 I actually had a use case in my case where it was possible, and that was
 the check I used to get around it, just configured it so that I always
 generated a new key when I needed to set up a 2 of 2 Multisig Refund Tx.
  It was either that or making sure I had no unspent outputs.  The use case
 of doing it was laziness in just creating a single key.

Use cases mean an actual use, not mere laziness. Bitcoin as a system has 
always required a unique EC key (and address) for each transaction.

Luke

--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Message Signing based authentication

2013-11-01 Thread Luke-Jr
On Saturday, November 02, 2013 5:01:43 AM bitcoingr...@gmx.com wrote:
 In celebration of the 5 year anniversary of the Bitcoin whitepaper, we are
 delighted to introduce the Message Signing based authentication method. In
 brief, the authentication work as follows:
 Server provides a token for the client to sign.
 client passes the signed message and the bitcoin address back to the
 server. server validates the message and honors the alias (optional) and
 bitcoin address as identification. http://forums.bitcoingrant.org/
 Above is a proof of concept forum that utilize this authentication method.

Congratulations! You've reinvented what Eligius and Bitcoin-OTC have been 
doing for years! :)

There's no reason to ask the user to provide the address every time, though...

Luke

--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Feedback requested: reject p2p message

2013-10-27 Thread Luke-Jr
On Sunday, October 27, 2013 2:32:57 PM Mike Hearn wrote:
 Currently bitcoinj gets a small but steady stream of bug reports of the form
 my transaction did not propagate. It's flaky because the library picks one
 peer to send the transaction to, and then watches it propagate across the
 network. But if that selected peer refuses the tx for whatever reason, that
 propagation never comes, and there's currently no timeout to make it retry
 with a different node.

Sounds like the real bug is BitcoinJ relies on good/servant behaviour from 
other nodes. Don't assume your random node isn't hostile. Handling a peer 
that doesn't relay your transaction for any reason (including if they lie to 
you about having done so) should be expected behaviour.

Luke

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Feedback requested: reject p2p message

2013-10-27 Thread Luke-Jr
On Sunday, October 27, 2013 10:52:25 PM Gavin Andresen wrote:
 If anybody has strong feelings about what the reject categories should be,
 then please take the time to write a specific list, I can't read your
 mind

It might make sense to use the rejection reasons from BIP 22 where applicable.

https://en.bitcoin.it/wiki/BIP_0022#Appendix:_Example_Rejection_Reasons

Luke

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment protocol for onion URLs.

2013-10-25 Thread Luke-Jr
On Saturday, October 26, 2013 3:31:05 AM Gregory Maxwell wrote:
 One limitation of the payment protocol as speced is that there is no
 way for a hidden service site to make use of its full authentication
 capability because they are unable to get SSL certificates issued to
 them.
 
 A tor hidden service (onion site) is controlled by an RSA key.
 
 It would be trivial to pack a tor HS pubkey into a self-signed x509
 certificate with the cn set to f.onion.
 ...
 Thoughts?

Is there any point to additional encryption over tor (which afaik is already 
encrypted end-to-end)? Is there a safe way to make this work through tor entry 
nodes/gateways?

It'd be nice to have a way to support namecoin-provided keys too...

Luke

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Proposal to replace BIP0039

2013-10-24 Thread Luke-Jr
On Thursday, October 24, 2013 5:29:18 PM thoma...@gmx.de wrote:
 I would like to propose a new BIP, that replaces BIP0039.

BIP 39 is still a draft. Just suggest revisions to the author(s)...

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Revisiting the BIPS process, a proposal

2013-10-21 Thread Luke-Jr
On Monday, October 21, 2013 7:38:37 PM Jean-Paul Kogelman wrote:
 1) Should the protocol specification page also be codified into BIP(s)?

Probably wouldn't hurt, but it'd likely need a rewrite in a more modular and 
formal form.

 2) Should the current wiki pages be taken down / forwarded to the git repo
 or be auto updated from the git repo?

Since it's the same format, I'd keep it up there, maybe with a link to the git 
repo on the main BIP index wiki page.

 3) Even though the information in BIP 50 is valuable, should it really be
 considered a BIP?

It's a hardforking protocol change, so IMO yes.

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] A critique of bitcoin open source community

2013-10-19 Thread Luke-Jr
On Saturday, October 19, 2013 9:16:24 PM Jean-Paul Kogelman wrote:
 I have a question regarding this part. I wrote a BIP for base 58 encoding /
 encryption of BIP 32 root keys. The BIP page states that we shouldn't add
 to this list ourselves, but should contact you for a BIP number. I have
 contacted you a couple times on bitcointalk for a BIP number, but haven't
 received a response (or do those requests explicitly have to go to your
 email address)?

See BIP 1 for the process.. proposals go to this mailing list first.

Luke

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60135031iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Blockchain archival

2013-09-07 Thread Luke-Jr
On Saturday, September 07, 2013 11:21:31 PM rob.gold...@astutium.com wrote:
  bitcoin protocol needs an archival system so the blockchain doesn't
  become too big to download
 
 Some people may want it all ...
 
 Balance at Point-In-Time summaries (say up to the penultimate
 difficulty adjustment) would be one simple way.
 And make new-adopters get up and running in minutes not days, which can
 only be a good thing.

There's no reason to require the full blockchain download before being up and 
running. Bitcoin-Qt 0.9 will (probably) have Pieter's work in this area to be 
usable very quickly, and download/verify the history in the background 
(there's no way to be completely trust-free without this).

 If going that route, then solutions to the 'consolidate addresses/wallets'
 question and formal 'discard' of addresses could get addressed.

Not sure what you mean here. Addresses and wallets are two completely 
different things. Addresses are single-use destinations that point to a wallet 
(which is itself private and unknown to the network).

Luke

--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58041391iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Making bitcoin traceability harder

2013-08-21 Thread Luke-Jr
Faré,

Let me start out by noting that there are plenty of good ideas which could be 
implemented, but haven't been yet, and might take a long time to get to. There 
are only a couple handfuls of Bitcoin developers, and even fewer of us who are 
able to work full-time on Bitcoin development. Perhaps surprisingly, even this 
often isn't the bottleneck to new functionality: we have a terrible shortage 
of testers, needed to make sure improvements don't break things in subtle 
ways. So, while your ideas are appreciated, please keep in mind that it may 
take time to add them, and you can help Bitcoin development much more by 
aiding in testing currently-written-but-untested features.

With regard to your points made specifically, please note that addresses are 
intended to be single-use only. Thus, the recurrent user of address A/B are 
not using Bitcoin correctly already, which is why they are so easy to trace. 
As far as keeping change amounts as powers of two, while I would personally 
love to find a justification for power-of-two amounts, I don't see how this 
would help privacy. I think it would actually hurt privacy, as change would 
now be clearly identifiable. Furthermore, it would necessarily have to throw 
away excess as a transaction fee - some users would be very upset with this.

As you suggest, it is of course already best practice for merchants (and 
individuals!) to use a unique payment address for every transaction. Gavin's 
payment protocol work has been making some great progress toward improving 
usability for this. There is also a general consensus that Bitcoin-Qt's 
Receive coins tab could be significantly improved to discourage address 
reuse further. I don't believe it has been discussed to have merchants use 
multiple addresses/coins for a single payment; that might be worth some 
further discussion here as a privacy extension, but I don't think many would 
consider it an urgent issue (it may help, but probably not enough to make it 
worthwhile).

Luke


On Wednesday, August 21, 2013 3:39:12 AM Faré wrote:
 Dear bitcoin developers,
 
 trading arbitrary amounts of bitcoins makes it easier to trace who
 does what just by observing the amounts being traded, and where the
 residual money ends up: e.g. you can identify that obviously, the
 recurrent user of address A sent 2.5 bitcoins to the recurrent user of
 address B, keeping the rest of his money in A. If instead bitcoin
 users practice the discipline, enforced by the client software by
 default, of only keeping a power-of-two amount of satoshis in use-once
 wallets except where public donation addresses are meant, then tracing
 suddenly becomes much harder.
 
 Whether this particular discipline is the best to implement or not,
 shouldn't bitcoin clients enforce SOME discipline that makes tracing
 harder? After all we know that uniformed goons are eager to watch
 who's trading with whom and to crack down on users. We shouldn't be
 making it easy for them, though this will mean slightly higher
 transaction cost. Merchants would then generate not one but a series
 of new addresses at each transaction, and the customer would send
 appropriately sized buckets of satoshis to each of the addresses.
 There should just be a standard way to specify an amount and a list of
 addresses as a target for payment, that merchants can communicate to
 customers (though that might require e.g. higher resolution QR codes).
 
 Has this idea already been considered before? Accepted or rejected?
 
 —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics•
 http://fare.tunes.org Of course, Third World leaders love you. By
 ascribing third world ills to First World sins, you absolve them of blame
 for their countries' failure to advance. — John McCarthy
 
 ---
 --- Introducing Performance Central, a new site from SourceForge and
 AppDynamics. Performance Central is your source for news, insights,
 analysis and resources for efficient Application Performance Management.
 Visit us today!
 http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] LevelDB in master

2013-08-16 Thread Luke-Jr
Now-merged pull request #2702 appears to have put the master branch on an 
unofficial Ripple fork of LevelDB, rather than merely updating us to LevelDB 
1.12.0. While Vinnie did somewhat disclose this, I don't see any evidence the 
nature of this was fully understood by others. As I understood the pull 
request, the Ripple and Bitcoin fork was just LevelDB with the changes we 
had already made. Mike's comments on the pull request (his audit) suggest that 
this may have been the case in an earlier revision of it. But in fact, there 
appear to be a number of other changes included in what was finally merged a 
few weeks ago. Furthermore, Ripple's fork did not do a proper git merge of 
upstream, thus there is a break in git history, and, more importantly, a 
number of upstream fixes (including some we have had reported to the Bitcoin 
issue tracker) were not included in this merge.

I've pushed three branches to https://github.com/luke-jr/leveldb :
  bitcoin-1.5   Our old/unreleased LevelDB 1.5 fork, for reference
  bitcoin   Our LevelDB 1.7 fork, included in 0.8.x
  bitcoin-upOur LevelDB 1.7 fork, merged with upstream LevelDB 1.12

A diff from current master (Ripple LevelDB 1.12 fork) to bitcoin-up:
  https://gist.github.com/luke-jr/6248543

Thoughts?

Luke


signature.asc
Description: This is a digitally signed message part.
--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with 2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] btc name server

2013-08-02 Thread Luke-Jr
Chris,

First, an important point: addresses are not wallet ids. They are single-use 
destinations for a single transaction. It isn't intended that anyone should 
remember them, just that they should send them electronically (or with eg, QR-
Codes). Bitcoin does not (yet?) have a person/wallet identity system, but 
there are other mechanisms for this already (eg, PGP).

With regard to your idea, I believe it is satisfied by the new Payment 
Protocol that Gavin has been working on. You will be able to publish a URI for 
a website which people can reuse to pay you more than once.

Luke


On Friday, August 02, 2013 8:40:27 PM Chris Evans wrote:
 wonder if it would be good idea to have a alias to wallet id nameserver in
 the client software where a person can use a english name to describe a
 wallet public key address?  and the software can use it to look up the
 wallet id.
 
 wallet ids are hard to remember/recall.
 
 -chris
 http://tawhakisoft.com/

--
Get your SQL database under version control now!
Version control is standard for application code, but databases havent 
caught up. So what steps can you take to put your SQL databases under 
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Opcode whitelist for P2SH?

2013-07-28 Thread Luke-Jr
On Sunday, July 28, 2013 7:39:08 PM John Dillon wrote:
 What are your thoughts on creating a whitelist for specific opcodes that
 would apply to scripts serialized using P2SH, retaining the existing
 standard whitelist for scriptPubKeys? (I would still recommend dropping
 pay-to-pubkey and pay-to-multisig due to their potential for dumping data
 in the UTXO set)

This would be reasonable for miners, but for interoperability between wallets, 
some specific standard forms would still be necessary without a much smarter 
solver (which would then expand the code required to implement a wallet, which 
is unfortunate if not entirely necessary).

--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Linux packaging letter

2013-07-23 Thread Luke-Jr
On Tuesday, July 23, 2013 10:02:28 PM Scott Howard wrote:
 1) It appears that the consensus of upstream developers is that any
 distributed binary should only be linked against libraries that the
 bitcoin developers have tested and audited since any compatibility bug
 is a risk to both the user and the network.
 
 Response: Is there a way to certify the Debian libraries? Debian
 bitcoind/bitcoin-qt runs the compile test during all architectures.

It doesn't need to be audited by any given person or team, just someone who 
understands the issues and can dedicate the time to doing a competent audit.
Testing bitcoind/bitcoin-qt is not sufficient: you must guarantee that your 
libraries (especially LevelDB) are bug-for-bug compatible with the ones used 
by everyone else. And not only the current versions, but every future version 
to ever hit the repository. This means a lot of additional work for the 
maintainers of the library packages, and the security team; for example, the 
security team must understand that they *cannot* deploy a critical security 
bugfix to LevelDB until someone competent has reviewed that it is 
behaviourally (including bug behaviours!) compatible with the versions in use 
everywhere else/previously. I think it is likely all this additional 
work/delays will be considered unacceptable to your library/security teams, 
thus using the bundled/embedded LevelDB is probably the best solution.

 MIPS has been failing recently, but no one has looked into it yet.
 Perhaps it's not worth developers efforts yet, but at some point the
 technology should reach a point it can be redistributed.

MIPS (and any other big endian architecture) has *always* failed on the 
Satoshi codebase, and will not be supported until someone has time to dedicate 
to fixing the numerous little-endian assumptions in the code. I have an 
incomplete port, but it isn't very high on my priority list to figure out what 
else it's missing.

 2) Bitcoin is new technology, so any patches have the ability of
 harming both the network and user.
 
 Response: I, and I'm sure everyone else working on it, totally agrees.
 All patches are public [1], you can see that the patches are only to
 the build system (except for one adding a debug message). Is there a
 specific patch or bug that is problematic? This seems to be
 reiterating (1) above: don't patch the build system to use libraries
 that were not audited by the developers.
 
 The two solutions are: (1) no one besides the upstream developers
 compiles and distributes binaries, ever, or (2) upstream comes up with
 a system where someone besides them can compile working binaries for
 distribution. Most likely the best solution is to do (1) until
 upstream sets up a system to allow (2).

Debian could probably get away with packaging Bitcoin-Qt and bitcoind as-is 
with no modifications, and not have any problems. It's only when you begin 
making modifications that it becomes a problem. There are also some concerns 
that it puts a much larger price on compromising Debian's build servers and/or 
repositories (suddenly the attacker can steal a LOT of money).

The official binaries are not simply built by upstream developers: using 
Gitian, *anyone* can produce bit-for-bit identical binaries. Official releases 
are only published after 3 or more people have done an independent compile and 
signed the output. It would be excellent if the whole of Debian could work 
toward achieving this level of security eventually, which would make 
distributing Bitcoin node software much safer as well.

Luke


signature.asc
Description: This is a digitally signed message part.
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Endianness (was: Linux packaging letter)

2013-07-23 Thread Luke-Jr
On Wednesday, July 24, 2013 3:54:25 AM Wendell wrote:
 Is there a substantial barrier to endian independence in the Bitcoin
 codebase?

I got the obvious stuff ('endian' branch in my repo), but it still didn't work 
when I moved on. I haven't had time to try to figure out why not yet.

Luke

--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] libzerocoin released, what about a zerocoin-only alt-coin with either-or mining

2013-07-14 Thread Luke-Jr
On Sunday, July 14, 2013 7:22:10 PM John Dillon wrote:
  Merged mining is not mining the coin for free. The total reward (ie
  btc + frc + nmc + dvc) should tend to equal the mining costs. But the
  value comes from demand, not costs. So if people demand it more it
  price will rise no matter how is mined. And if the price rises it will
  make sense to spend more on mining.
 
 Merge mining is very much mining a coin for free. Ask not what the total
 reward is, ask that the marginal cost of merge mining an additional coin
 is.

But the total reward is what mining will tend toward equalizing in costs.
In any case, the cryptocurrencies are neutral to cost of mining, or perhaps 
even benefit from it being as cheap as possible: if it's cheaper to mine, you 
can get an even higher difficulty/security out of it.

 The issue is that unless there is a cost to mining a *invalid* block
 the merge mined coin has little protection from miners who mine invalid
 blocks, either maliciously or through negligence. If the coin isn't worth
 much, either because it's market value is low or the worth is negative to
 the malicious miner, your theories of value have nothing to do with the
 issue.

Invalid blocks are rejected by validating clients in all circumstances.

I suspect you may mean a block that doesn't include transactions you want 
confirmed. In that case, you must not be paying sufficient fees for the miner 
to consider it worth their time, or must be doing something the miner 
considers fundamentally objectionable (in which case they won't be satisfied 
by any fee). But these miners, unless they are able to acquire over 50% of the 
hashrate (in which case the cryptocoin is compromised), are not the only ones 
mining blocks, and if another miner accepts your transactions there is no 
issue.

Luke


signature.asc
Description: This is a digitally signed message part.
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] libzerocoin released, what about a zerocoin-only alt-coin with either-or mining

2013-07-14 Thread Luke-Jr
On Sunday, July 14, 2013 7:42:06 PM Pieter Wuille wrote:
 On Sun, Jul 14, 2013 at 07:33:06PM +, Luke-Jr wrote:
   The issue is that unless there is a cost to mining a *invalid* block
   the merge mined coin has little protection from miners who mine invalid
   blocks, either maliciously or through negligence. If the coin isn't
   worth much, either because it's market value is low or the worth is
   negative to the malicious miner, your theories of value have nothing
   to do with the issue.
  
  Invalid blocks are rejected by validating clients in all circumstances.
 
 I don't think that's what John means.
 
 If you have hash power for the parent chain, mining invalid blocks for the
 merge-mined chain costs you nothing. Yes, they will be invalid, but you've
 lost nothing.

Nor gained anything. So the lesser chain maybe can't trust SPV.
But trusting SPV was already a bad idea anyway.

Note that the parent chain is not in any privileged position here either: a 
merged-mined chain could provide the value to the miner he is interested in, 
while he sees nothing of the parent chain. In short, merged mining is pretty 
much unavoidable in any case.

 The basic assumption underlying mining security is that it is more
 profitable to collaborate with mining a chain (and profit from the block
 payout) than to attack it. In the case of merged mining, this assumption
 is not valid.

The basic assumption of SPV is that more people will be assisting rather than 
making invalid blocks. That motive doesn't necessarily need to be economic, 
nor do proper validating clients rely on it. The only real assumption behind 
mining is that the majority will not be aiming to reverse transactions with 
valid blocks.

P.S. How about a Zerocoin with no-reward/PoSacrifice merged mining as well as 
(rewarded) Prime POW; maybe with no subsidy halving, to try a new economic 
idea as well ;)


signature.asc
Description: This is a digitally signed message part.
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] libzerocoin released, what about a zerocoin-only alt-coin with either-or mining

2013-07-14 Thread Luke-Jr
On Monday, July 15, 2013 12:12:23 AM Peter Todd wrote:
 On Sun, Jul 14, 2013 at 08:16:41PM +, Luke-Jr wrote:
  P.S. How about a Zerocoin with no-reward/PoSacrifice merged mining as
  well as (rewarded) Prime POW; maybe with no subsidy halving, to try a
  new economic idea as well ;)
 
 Your ideas about making an alt-coin have anything to do with hashing
 power might be a lot more convincing if you hadn't 51% attacks alt-coins
 in the past.

Slander like this does not belong on the dev ML.

--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org

2013-06-27 Thread Luke-Jr
On Thursday, June 27, 2013 5:30:21 PM Jeff Garzik wrote:
 * Very real possibility of an overall net reduction of full nodes on P2P
 network

Even a reduction of *nodes at all*, as I've never seen a listening bitcoinj or 
MultiBit node. :/

Jim, will MultiBit be adding p2p listening support?

 I'm sure others can come up with a few more.

Possibly against: Does MultiBit still promote Bitcoin misunderstandings with 
misinformation like from addresses? (my apologies if I am remembering a 
different client)

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

Build for Windows Store.

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


Re: [Bitcoin-development] Decentralizing mining

2013-06-14 Thread Luke-Jr
On Friday, June 14, 2013 8:06:54 PM Peter Todd wrote:
 On Mon, Jun 10, 2013 at 09:23:14PM +, Luke-Jr wrote:
  Might as well just use higher difficulty shares (each one audited) for
  the same effect. Block proposals allow the miner to tell the pool its
  transaction set once (per txset change) for any number of shares.
 
 That's a good point - the current practice most pools seem to follow of
 about a share per second seems very excessive to me. On the other hand,
 it does have good user optics. The right solution might be something
 akin to P2Pool where the UI level is telling the user shares are being
 found so it's clear stuff is happening, but under the hood only a
 small subset are ever sent to the pool.

Share rate is relevant to more than user information - it also affects the 
variance of reward/payout. I disagree with claiming shares are found when 
they're not sent to the pool - this makes auditing and troubleshooting more 
difficult; for example, see the GUIMiner bug where it reports shares despite 
misinterpreting the pool's target and submitting nothing at all (this happens 
when the pool uses pdiff 1).

   # Pool work
   
   So does eliopool already accept arbitrary shares like this and do the
   correct accounting already? (IE adjust share amount based on fees?)
   What happens when the pool doesn't get the share directly, but does
   see the new block?
   
   + possible protocol extensions
  
  I don't follow.
 
 What part don't you follow?

I don't understand the first two questions here at all.

Luke

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

Build for Windows Store.

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


Re: [Bitcoin-development] is there a way to do bitcoin-staging?

2013-06-14 Thread Luke-Jr
Note that the earn a mixture of BTC and TBC, but not both in full volume 
only works for TBC because the price is by definition fixed with BTC.
I'm not sure how you could implement something like this for an altcoin where 
the price is floating independently of Bitcoin.. that is, how you would know 
the right amount of Bitcoin to require sacrificed.

Luke


On Friday, June 14, 2013 8:50:31 PM Adam Back wrote:
 Agreed.  What I mean is a coinbase for parity-priced alt-coin would be
 intentionally considered (and required by the alt-coin to be considered) an
 invalid bitcoin address, and vice versa.  The difference is for this
 purpose it is both valid alt-coin coinbase (as well as unspendable bitcoin
 coinbase).
 
 Adam
 
 On Fri, Jun 14, 2013 at 03:20:58PM -0400, Peter Todd wrote:
 On Thu, Jun 13, 2013 at 03:39:32PM +0200, Adam Back wrote:
  I had one thought towards this which is a different kind of merged
  mining.
  
  I think a fair merged mining aiming for price parity would be done by
  the miner having to choose the altcoin or btc at mine time, and altcoin
  chain considering btc mine unspendable and bitcoin considering ac
  unspendable.
 
 One way to look at what you are describing is to say you want to prove
 your sacrifice of potential BTC earnings. That goes back to the PoW
 hashcash stuff I mentioned earlier, and is accomplished by simply mining
 shares with an unspendable coinbase to prove you did work that could
 have resulted in Bitcoins, but didn't.
 
 ---
 --- This SF.net email is sponsored by Windows:
 
 Build for Windows Store.
 
 http://p.sf.net/sfu/windows-dev2dev
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development

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

Build for Windows Store.

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


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

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

This is true or false based on CONTEXT.

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

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

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

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

 
 snip
 

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

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

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

Luke

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

Build for Windows Store.

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


Re: [Bitcoin-development] Decentralizing mining

2013-06-10 Thread Luke-Jr
On Monday, June 10, 2013 9:09:13 PM Peter Todd wrote:
 # Protocol Work

This is basically done.

 Basic idea is the miner makes two connections, their pool, and a local
 bitcoind.
 
 They always (usually?) work on the subset of transactions common to both
 the pool's getblocktemplate and their local one. When they find a share
 if it doesn't meet difficulty they just hand it to the pool. Currently
 that is done by handing the whole block over, correct? I know the BIP
 says otherwise, but we should optimize this to just hand over tx hashes
 where possible.

The plan was to tell the pool it doesn't need to send transactions at all, and 
only work on the ones from bitcoind. Currently, share submissions are just the 
block header and coinbase transaction; in this case, however, the miner will 
need to send merkle links also, possibly just once via a block proposal in 
advance.

 If the share does meet difficulty, hand it to both the pool and the
 local bitcoind. Should hand it to the pool first though, because the
 pool likely has the fastest block propagation, then hand it to local
 bitcoind. An optimized version may want to have some record of measured
 bandwidth - this applies Bitcoin in general too, although also has other
 issues.

Currently, BFGMiner is doing submission to the pool, waiting for a response, 
then submitting to a local bitcoind. This is because the pool might need to 
receive/record the share before it processes the block on bitcoind, or you 
could lose credit for it. The response from the pool is rather small (a single 
TCP packet), so this shouldn't delay much longer.

 ## Reducing bandwidth
 
 How about for normal shares we just pass the block header, and have the
 pool randomly pick a subset of transactions to audit? Any fraud cancels
 the users shares. This will work best in conjunction with a UTXO proof
 tree to prove fees, or by just picking whole shares randomly to audit.

Might as well just use higher difficulty shares (each one audited) for the 
same effect. Block proposals allow the miner to tell the pool its transaction 
set once (per txset change) for any number of shares.

IF bandwidth becomes a real problem, I have a draft of a GBT 2.0 that does 
some more improvement in this area.

 # Pool work
 
 So does eliopool already accept arbitrary shares like this and do the
 correct accounting already? (IE adjust share amount based on fees?) What
 happens when the pool doesn't get the share directly, but does see the
 new block?
 
 + possible protocol extensions

I don't follow.

 # Miner work
 
 Basically we need code to merge the two block templates together to find
 commonality. I guess you probably want to implement this in bfgminer
 first, so add the code to libblkmaker first, then maybe python-blkmaker.

libblkmaker's API was designed for this from the start, so it should be fairly 
easily implemented.

 We also want an automatic fallback to local solo mining if the pool
 can't be contacted.
 
 + possible protocol extensions

Failover already functions, but probably could use a rewrite...

Luke

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

Build for Windows Store.

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


Re: [Bitcoin-development] Proposal: soft-fork to make anyone-can-spend outputs unspendable for 100 blocks

2013-06-06 Thread Luke-Jr
On Thursday, June 06, 2013 7:59:16 PM Andreas M. Antonopoulos wrote:
 Is there any consideration given to the fact that bitcoin can operate as a
 platform for many other services, if it is able to be neutral to payload,
 as long as the fee is paid for the transaction size?

This doesn't work like you might think: first of all, the fees today are 
greatly subsidized - the actual cost to store data in the blockchain is much 
higher than most storage solutions. Secondly, only the miner receives the 
fees, not the majority of nodes which have to bear the burden of the data.
That is, the fee system is setup as an antispam/deterrant, not as payment for 
storage.

 Unless I have misunderstood this discussion, it seems to me that this is a
 bit like saying in 1990 IP Is only for email, the majority of users want
 email, we shouldn't allow video, voice or images. Ooops, there goes the
 web.

Not the same thing at all; nobody is forced to store/relay video/voice/images 
without reimbursement. On the other hand, any full Bitcoin node is required to 
at least download the entire blockchain once. And the network as a whole 
suffers if nodes decide to start not-storing parts of the blockchain they 
don't want to deal with.

 Is it possible to solve this by solving the issue of provably un-spendable
 outputs without foreclosing on the possibility of other types of
 transaction payloads (ie, not money), that would open the possibility for a
 myriad of layered apps above? For example, hashes of content that is
 external to bitcoin, that people want to pay to have timestamped in the
 blockchain, as provably unspendable outputs.

This is how merged mining solves the problem. A single extra hash in the 
coinbase can link the bitcoin blockchain up with unlimited other data.

 The social compact is to accept transaction for fee. I think it is a major
 mistake to make decisions that discriminate on the content of the
 transaction, saying that some uses are not appropriate. If the fee is paid
 and it covers the size of the transaction, why would it matter if it is not
 a payment?

See above.

 I could be totally misreading this thread, too, so please allow me some
 slack if I have!
 
 On Thu, Jun 6, 2013 at 12:14 PM, Luke-Jr l...@dashjr.org wrote:
  On Saturday, June 01, 2013 7:30:36 PM Peter Todd wrote:
   scriptPubKey: data OP_TRUE
   
   ...
   Along with that change anyone-can-spend outputs should be make
  
  IsStandard()
  
   so they will be relayed.
  
  Data does not belong in the blockchain. People running nodes have all
  implicitly agreed to store the blocks for financial purposes, and storing
  data
  is a violation of that social contract. Proof-of-stake may be arguably
  financial, but I'm sure there must be a way to do it without spamming
  people
  against their consent.
  
   The alternative is sacrifices to unspendable outputs, which is very
   undesirable compared to sending the money to miners to further
   strengthen the security of the network.
  
  The alternative is to make other standard outputs unable to store data as
  well.
  
  Luke
  
  
  -
  - How ServiceNow helps IT people transform IT departments:
  1. A cloud service to automate IT design, transition and operations
  2. Dashboards that offer high-level views of enterprise services
  3. A single system of record for all IT processes
  http://p.sf.net/sfu/servicenow-d2d-j
  ___
  Bitcoin-development mailing list
  Bitcoin-development@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Proposal: soft-fork to make anyone-can-spend outputs unspendable for 100 blocks

2013-06-06 Thread Luke-Jr
On Thursday, June 06, 2013 8:16:40 PM Andreas M. Antonopoulos wrote:
  This doesn't work like you might think: first of all, the fees today are
  greatly subsidized - the actual cost to store data in the blockchain is
  much higher than most storage solutions. Secondly, only the miner receives
  the fees, not the majority of nodes which have to bear the burden of the
  data. That is, the fee system is setup as an antispam/deterrant, not as
  payment for
  storage.
 
 There's a difference between storing the content itself, and storing just a
 hash to content (which however is not spendable payment). I undertand why
 content itself doesn't belong. But it goes too far to say that only
 payments should be allowed.

Because payments are the only thing everyone using Bitcoin has agreed to use 
the blockchain for. Furthermore, there is no *reason* to store non-payments in 
the blockchain. If there was in fact such a use case, things might be arguable 
- but there isn't any I'm aware of.

 If the fees are not enough, fix the fee structure, don't stop incredibly
 innovative and promising uses of the distributed timestamping database.
 That is definitely throwing the baby out with the bathwater. If the issue
 is size, then address that, rather than the content itself.

The issue is using other peoples' resources for something they did not agree 
to use it for. The fees aren't merely not enough, they were never *intended* 
to be cost of storage. They are cost of security and prevent spamming.

 Discriminating based on transaction content violates neutrality of the
 protocol and in my mind removes a very very large possibility of future
 innovation. If bitcoin is a *platform* and not just a payment system, then
 it needs to be neutral to content, like TCP/IP so that other protocols can
 be layered. Solve the size problem itself, without picking and chosing
 which uses of bitcoin are good and which are bad or spam. I think it
 risks killing a tremendous amount of innovation just as it is starting.

The concepts behind Bitcoin are applicable to future innovation, but this can 
all be accomplished without spamming Bitcoin itself.

  Not the same thing at all; nobody is forced to store/relay
  video/voice/images without reimbursement. On the other hand, any full
  Bitcoin node is required to at least download the entire blockchain once.
  And the network as a whole suffers if nodes decide to start not-storing
  parts of the blockchain they don't want to deal with.
  
  So don't store content, but allow hashes of content.
 
 Again, I think it is extreme and extremely restrictive to say that ONLY
 payments are allowed.

Non-payments are quite possible without the Bitcoin blockchain itself. If 
you're worried that not enough people will store the alternative-non-payment 
data, then you are essentially saying that voluntary participation is not 
enough and that forced storage is your solution. I don't think this is what 
you intend...

  This is how merged mining solves the problem. A single extra hash in the
  coinbase can link the bitcoin blockchain up with unlimited other data.
 
 Can you explain this part or refer me to some docs? What do you mean by
 coinbase, I assume not the company.

The Bitcoin blockchain protocol has 95 bytes per block reserved for miners to 
put extra data. Currently, this is used for extranonces, political or other 
short messages (such as in the Genesis block), miner signatures, and also, 
as I mentioned, merged mining. Merged mining works by tying a non-
transactional merkle tree to the blockchain. The block coinbase stores the 
hash of the top of this merkle tree, so any data within the merkle tree can 
prove it is associated to the block. The merged mining merkle tree then stores 
hashes of multiple other data sets: for example, a Namecoin block can be 
referenced in a merged mining merkle tree, to use the Bitcoin block's proof-
of-work for itself (so, miners can mine both Bitcoin and Namecoin using the 
same hashing effort). You could also add other non-transactional blocks to the 
merged mining merkle tree, for generic timestamping or really anything at all.

Luke

--
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] 0.8.2 branch

2013-05-29 Thread Luke-Jr
On Thursday, May 30, 2013 2:54:00 AM grarpamp wrote:
 Should there not be a 0.8.2 branch laid down at 09e437b (v0.8.2)
 in which the like of release build stoppers or critfixes such as d315eb0
 are included... for those tracking that level of defect without
 wishing to track all the growing post release slush in HEAD?

I'll branch 0.8.x sometime in the next few weeks.

Stable branches are maintained on Gitorious for now:
http://gitorious.org/bitcoin/bitcoind

Luke

--
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with 2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Modularizing Bitcoin

2013-05-26 Thread Luke-Jr
On Thursday, May 16, 2013 10:02:05 AM bitcoingr...@gmx.com wrote:
 One of the main goals will be to separate the wallet from the node, as we
 have already done with mining.

How is this different from what Electrum has already done?

Luke

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


Re: [Bitcoin-development] Modularizing Bitcoin

2013-05-26 Thread Luke-Jr
On Thursday, May 16, 2013 10:55:44 AM Addy Yeow wrote:
 Is the number representing the count for the client nodes?
 
 I was curious of the count myself earlier this week and started to
 traverse down the network using getaddr message starting from seed
 nodes and found upward to 57k nodes running protocol = 70001 with
 timestamp no older than 24 hours.

This sounds accurate for listening nodes, and similar to what my own system 
counts: http://luke.dashjr.org/programs/bitcoin/files/charts/security.html

Of course, it doesn't include the (many?) connect-only nodes (eg, mobile or 
firewall/NAT'd) or non-p2p nodes (eg, Electrum).

Luke

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


Re: [Bitcoin-development] (no subject)

2013-05-25 Thread Luke-Jr
On Saturday, May 25, 2013 8:25:35 AM Melvin Carvalho wrote:
 It might be an idea to have 'rule change' fixes and 'bug fix' releases go
 out separately

Bitcoin is a consensus system. You can't run clients with different rules on 
the same blockchain/network - it just won't work! Maybe we're now talking 
about mere client default policies? In which case, you should be able to 
configure previous behaviour...

If you want just bug fixes and rule changes, without policy default changes, 
new features, etc, you can use the 0.4.x - 0.7.x backports. But be advised 
these are short-term solutions and won't be maintained forever - so you really 
should try to get the behaviour you want from the current release. If you 
can't for some reason, please do report a bug explaining what it is the older 
version was capable of that the new one isn't!

Luke

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


Re: [Bitcoin-development] Tentitive port for FreeBSD

2013-05-24 Thread Luke-Jr
On Saturday, May 25, 2013 3:36:46 AM Robert Backhaus wrote:
 Here is the link to the FreeBSD build system 'port' that I am planning to
 get committed when 0.8.2 is released. Any comments appreciated.
 
 The Makefile mostly just applies the users request for GIU/QR/UPNP. The
 major change is using the external port for leveldb. The files directory
 contains 5 patches - 2 that add boost-crypto to LIBS because we still need
 that until boost is updated, one that patches the build to use that
 external leveldb, and 2 minor fixes that are needed to build. I have got
 branches ready for pullreqs on those minor fixes - I'll double check them
 and make pullreqs this evening.
 
 Again, any comments very welcome.

Would be nice if you could help test (and use?) the pull request for system 
LevelDB support: https://github.com/bitcoin/bitcoin/pull/2241
Note that you should be careful to tie your port to the specific LevelDB 
version bundled, to avoid any risk of unexpected hardforking bugs or fixes in 
upstream LevelDB.

For the other patches, please try to find a portable solution (if they aren't 
already) and open pull requests on github.

Thanks,

Luke

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


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

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

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

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


Re: [Bitcoin-development] RFC: extend signmessage/verifymessage to P2SH multisig

2013-04-13 Thread Luke-Jr
On Sunday, April 14, 2013 5:09:58 AM Peter Todd wrote:
 Currently signmessage/verifymessage only supports messages signed by a
 single key. We should extend that to messages signed by n-of-m keys, or
 from the users point of view, P2SH multisig addresses.

I think it would be wise to figure out HD wallet changes before trying to 
extend message signing. For privacy/safety, it would be a good idea to avoid 
signing with the same private key twice under any circumstances, so it might 
make sense to create a new address format the represent a chain of keys 
instead of one key or combination of keys.

Luke

--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis  visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] A bitcoin UDP P2P protocol extension

2013-03-23 Thread Luke-Jr
On Saturday, March 23, 2013 10:42:26 AM Randy Willis wrote:
 Introducing super-nodes with thousands of connected peers can greatly help
 here.

UDP is connectionless.
I would hope any UDP bitcoin protocol doesn't try to emulate a connection. :/

Luke

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Upcoming network event: block v2 lock-in

2013-03-23 Thread Luke-Jr
On Saturday, March 23, 2013 5:28:55 PM Jeff Garzik wrote:
 On Sat, Mar 23, 2013 at 1:09 PM, Luke-Jr l...@dashjr.org wrote:
  I don't think anyone is mining using bitcoind 0.7 or later?
 
 slush, BTC Guild, ozcoin too I think, several others.

Not for producing coinbases (where BIP 34 is implemented).

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Upcoming network event: block v2 lock-in

2013-03-23 Thread Luke-Jr
On Saturday, March 23, 2013 5:47:46 PM Jeff Garzik wrote:
 On Sat, Mar 23, 2013 at 1:43 PM, Luke-Jr l...@dashjr.org wrote:
  On Saturday, March 23, 2013 5:28:55 PM Jeff Garzik wrote:
  On Sat, Mar 23, 2013 at 1:09 PM, Luke-Jr l...@dashjr.org wrote:
   I don't think anyone is mining using bitcoind 0.7 or later?
  
  slush, BTC Guild, ozcoin too I think, several others.
  
  Not for producing coinbases (where BIP 34 is implemented).
 
 Sure, that is largely the pool server layer.  But it is misleading to
 imply that bitcoind is nowhere in the stack.

Context is everything.
bitcoind is nowhere in the implementation of the miner end of BIP 34.

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Upcoming network event: block v2 lock-in

2013-03-23 Thread Luke-Jr
On Saturday, March 23, 2013 6:21:32 PM Jeff Garzik wrote:
 On Sat, Mar 23, 2013 at 1:51 PM, Luke-Jr l...@dashjr.org wrote:
  bitcoind is nowhere in the implementation of the miner end of BIP 34.
 
 Again, not strictly true.
 
 bitcoind's 'getblocktemplate' RPC call used by some supplies the block
 version, selects transactions for the miner, and other tasks integral
 to the implementation of the miner and BIP 34.

Transaction selection and everything else bitcoind does, is irrelevant to BIP 
34. It is incompatible with getblocktemplate for coinbase-creating software to 
produce v2 blocks without implementing BIP 34 themselves, even if the upstream 
GBT server specifies it.

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] 0.8.1 ideas

2013-03-15 Thread Luke-Jr
On Friday, March 15, 2013 5:06:20 PM Benjamin Lindner wrote:
 On Mar 13, 2013, at 8:18 PM, Cameron Garnham da2...@gmail.com wrote:
  For me, everyone signed up to bitcoin thinking that there was a 1MB /
  block limit.  The lock limits were unexpected, and could be considered
  extremely uncontroversial to remove.
 
 This. Software behavior which is not described by the source code should
 not be considered an integral part of the rule set. Any influence of
 external libraries on the consensus mechanism is unacceptable.

Note that the lock limits were explicitly set in the bitcoind source code.

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] 0.8.1 ideas

2013-03-13 Thread Luke-Jr
On Wednesday, March 13, 2013 3:18:36 PM Gregory Maxwell wrote:
 On Wed, Mar 13, 2013 at 8:05 AM, Peter Todd p...@petertodd.org wrote:
  If we're going to consider doing this, at minimum we need to also
 
 I beg people to not derail discussion about fixing things with
 discussion of other controversial changes.

I figured 2 MB in 2-3 years was fairly uncontroversial.
If not, let's scrap that idea for now.

 Luke-jr, any chance in getting you to revise your proposal to narrow
 the scope to things that don't need serious debate?

It was a one-time start the conversation proposal.
I expect what we end up going with may be substantially different.

Luke

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] 0.8.1 ideas

2013-03-13 Thread Luke-Jr
On Wednesday, March 13, 2013 5:41:29 PM you wrote:
 I'm not sure I understand the need for hard forks. We can get through this
 crisis by mining pool collusion to prevent forking blocks until there is
 widespread adoption of patched clients.

Anything requiring widespread adoption of patched clients *is by definition* a 
hard fork.

 Proposal:
 
 1) Patch the pre-0.8 branches to support an increased lock count, whatever
 number is required to make sure that this problem never shows up again at
 the current block size (I defer to Luke-Jr and gmaxwell's numbers on this).

This is a hard fork.

The only way to avoid a hard fork is to apply the existing lock limit to all 
clients forever. That would be fine, except that pre-0.8 clients cannot reorg 
N blocks without dividing that limit by (N * 2) + 1; that leaves us with the 
limit of around 1000 locks per block on average. Each transaction uses at 
least 3 locks on average (many times more). So about 300 transactions per 
block. This is a much smaller limit than the 1 MB we've been assuming is the 
bottleneck so far, and the need to increase it is much more urgent - as Pieter 
noted on IRC, we are probably already using more than that even ignoring DP 
spam. The only reason pre-0.8 clients have survived as well as they have thus 
far is because the blockchain has managed to avoid very deep reorgs.

Luke

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Blocksize and off-chain transactions

2013-03-13 Thread Luke-Jr
On Wednesday, March 13, 2013 6:01:02 PM Michael Gronager wrote:
 Please note that it was not 0.8 that had issues, but 0.7(and downwards).

While 0.7 and earlier do have issues, they also define the Bitcoin protocol. 
0.8's failure to comply with the protocol is an issue.


--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] 0.8.1 ideas

2013-03-13 Thread Luke-Jr
On Wednesday, March 13, 2013 6:27:13 PM Mark Friedenbach wrote:
 Luke-Jr is suggesting that we add-to/modify the bitcoin protocol rules
 which all verifying implementations must adhere to. I'm suggesting that we
 instead change the old codebase to do what we expected it to do all along
 (what 0.8 does and what every other verifying implementation does), and
 through miner collusion buy ourselves enough time for people to update
 their own installations.

Curiously enough, at least MtGox's custom implementation stuck with the 
canonical blockchain despite 0.8's accidental rule change.

 I know there's people here who will jump in saying that the bitcoin
 protocol is the behavior of the Satoshi client, period. But which Satoshi
 client? 0.7 or 0.8? How do you resolve that without being arbitrary? And
 regardless, we are moving very quickly towards a multi-client future. This
 problem is very clearly a *bug* in the old codebase. So let's be forward
 thinking and do what we would do in any other situation: fix the bug,
 responsibly notify people and give them time to react, then move on. Let's
 not codify the bug in the protocol.

No, if any other client released diverged from the consensus of all 
past/existing clients, we would do the same thing: call it a formerly unknown 
protocol rule, that this new client has a bug implementing, and be done with 
it.

The only reason this particular issue needs special treatment is because the 
implications of the new rule mean that we're up against a hard limit in the 
protocol today rather than 2 years from now.

Luke

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] 0.8.1 ideas

2013-03-13 Thread Luke-Jr
On Wednesday, March 13, 2013 9:06:44 PM Andy Parkins wrote:
 On Wednesday 13 Mar 2013 12:56:29 Luke-Jr wrote:
  Here's a simple proposal to start discussion from...
 
 It seems to me that the biggest failure was not the development of two
 chains, but the assurance to users (by the client) that their transactions
 were confirmed.

These are both the same thing.

Luke

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Some PR preparation

2013-03-12 Thread Luke-Jr
On Tuesday, March 12, 2013 7:03:54 AM Alan Reiner wrote:
 I'm sure it won't be long before Slashdot and a variety of sources start
 reporting on this event.  Bitcoin has been in the media a lot lately, so
 this story is likely to get some attention.  The blowback of this event
 is mostly psychological, so I think it would be exceptionally wise to
 start preparing PR comments that can be posted on articles immediately
 after they go public.  This event is likely draw much more negative
 attention than it deserves, and getting some positiveinformed comments
 posted up front will potentially make a difference in the way the story
 is received.
 
 Undoubtedly, many articles (and especially commenters) will shape this
 into the end of Bitcoin.   I would describe it as there was a short
 and mostly-harmless lapse in the ability of the network to reach a
 consensus, causing transactions to get delayed by a few hours.   It
 *really* needs to be emphasized that coins are safe, and nothing anyone
 has/could do will change that.  And that it would've been extremely
 difficult to exploit for gain.  Transactions got delayed while a bug was
 fixed.  End of story.

I think we should be careful not to downplay the reality either.
For a number of hours, transactions could have received up to N confirmations 
and then still been reversed. While we could contact the bigger payment 
processors, I saw people still trying to buy/sell on OTC, whom could have been 
scammed even by taking standard precautions.

Luke

--
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester  
Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the  
endpoint security space. For insight on selecting the right partner to 
tackle endpoint security challenges, access the full report. 
http://p.sf.net/sfu/symantec-dev2dev
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] [PATCH] Change recommended fee to 0.001 BTC

2013-03-11 Thread Luke-Jr
On Monday, March 11, 2013 7:27:51 PM Rune K. Svendsen wrote:
 From: Rune K. Svendsen runesv...@gmail.com
 
 On the Main tab in the Options dialog, it previously said a minimum
 fee of 0.01 is recommended. This amounts to about $0.50 at today's
 price. Change this to 0.001 to be more sensible. We could even go
 lower, perhaps.

Please use GitHub pull requests (or at least publish a git repository) rather 
than mailing patches..

I'd suggest two commits for this:
1. Move the recommended fee outside the translatable string (bonus points to 
format it using the user's preferred unit)
2. Change the recommended fee in one place

Whether the recommended fee *should* be changed or not, I have no opinion on.
Eligius uses a lower minimum fee, but I believe most pools/miners will treat 
anything under 0.01 BTC as if it were no fee at all...

Luke

--
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester  
Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the  
endpoint security space. For insight on selecting the right partner to 
tackle endpoint security challenges, access the full report. 
http://p.sf.net/sfu/symantec-dev2dev
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] [PATCH] Change recommended fee to 0.001 BTC

2013-03-11 Thread Luke-Jr
On Monday, March 11, 2013 9:17:25 PM Rune Kjær Svendsen wrote:
 On Mon, Mar 11, 2013 at 9:46 PM, Luke-Jr l...@dashjr.org wrote:
  On Monday, March 11, 2013 8:34:52 PM Rune Kjær Svendsen wrote:
   Ok. I'll fork on Github. Looking at the source, and some Qt
  
  documentation,
  
   it should be doable to do string substitution for both the value and
   the unit.
  
  Side note: I imagine you'd be substituting a formatted string, and using
  some
  other function to format the string (which already exists to decide how
  to display units elsewhere).
 
 I'm not entirely sure what you mean by this. I plan on using the method
 described on this page http://doc.qt.digia.com/3.1/i18n.html under Use
 QString::arg() for Simple Arguments and then just putting a %1 and %2 in
 the translation strings and substituting for value and unit, respectively.
 Haven't tested it yet, but that's what I plan to do.

eg, use a single %1 with
BitcoinUnits::format(walletModel-getOptionsModel()-getDisplayUnit(), amount)

 Where do you want the constant defined? In main.h alongside MIN_TX_FEE
 and MIN_RELAY_TX_FEE?

Sounds reasonable.

--
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester  
Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the  
endpoint security space. For insight on selecting the right partner to 
tackle endpoint security challenges, access the full report. 
http://p.sf.net/sfu/symantec-dev2dev
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Blockchain as root CA for payment protocol

2013-02-09 Thread Luke-Jr
On Saturday, February 09, 2013 2:33:25 PM Timo Hanke wrote:
  Why don't you use namecoin or another alt-chain for this?
 
 Because namcoin tries to solve a different problem, DNS, whereas I want
 to establish an identity for a payment protocol.

What is the technical difference here? Namecoin ties names to data; DNS is a 
specific namespace in it. There is no reason I know of that this identity 
stuff cannot be a new namespace.

 You can argue that alt-chains _can_ be as strong as bitcoin, but they
 don't _have to_ be. There is no guarantee how many people will
 cross-mine.

This is true of namecoin, but it does not have to be true of new merged-mined 
data. You could very well require the Bitcoin proof-of-work to be valid and 
the master header to be in the Bitcoin blockchain.

 The alt-chain could even disappear at some point. If at some point your alt-
 chain is no longer being worked on, then how do you prove that some old
 bitcoin transaction went to an address for which there was a valid
 id/certificate at the time of sending? If the certificate is based inside
 bitcoin's blockchain then you will have a proof for the correct destinations
 of all your old transactions as long as bitcoin exists.

Yes, if people stop using your system, it won't work. Consider that a this 
idea failed scenario, where it doesn't matter.

Luke

--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] 0.8.0rc1 status

2013-02-08 Thread Luke-Jr
On Friday, February 08, 2013 11:49:09 PM Gavin Andresen wrote:
 Windows builds are varying with every compile, and I think I finally
 figured out why: we are not passing the -frandom-seed flag down into
 the leveldb build (I used objdump to dump two different binaries, and
 they differed only in the names of some leveldb objects). That should
 be an easy makefile fix.

FWIW, this should be already mostly-fixed in pull #2243 I submitted 9 days 
ago... only thing not in that pull is changing gitian to use the standard 
CXXFLAGS rather than our non-standard DEBUGFLAGS (whether DEBUGFLAGS should be 
propagated to LevelDB or not is another conversation I guess).

Luke

--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-11-26 Thread Luke-Jr
On Monday, November 26, 2012 11:32:46 PM Gregory Maxwell wrote:
 Obviously the state of the world with browsers is not that good... but
 in our own UAs we can do better and get closer to that.

This effectively centralizes Bitcoin (at least in the eyes of many) and even 
if each competing client had their own list, you'd be back to the original 
problem of not being sure your CA is on all lists.

 Would you find it acceptable if something supported a static whitelist
 plus a OS provided list minus a user configured blacklist and the
 ability for sophisticated users to disable the whitelist?

How is this whitelist any different from the list of CAs included by default 
with every OS?

--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] IRC meeting agenda, 18:00 UTC Thursday

2012-11-06 Thread Luke-Jr
On Tuesday, November 06, 2012 6:47:34 PM Gavin Andresen wrote:
 Thursdays at 18:00 UTC (6PM Europe/1PM east US/10AM west US) seem to
 be a good time for the core dev team to meet on the #bitcoin-dev
 freenode IRC channel to chat.
 
 I'd like to talk about:
 
 o Can we put together a TODO list to get to a 0.8 release candidate ?
 
 o Is it time to feature-freeze 0.8 and work on just testing the new
 features and fixing existing bugs (the issues list keeps getting
 longer and longer ... )?

Not much has changed besides internal workings, right?
Though perhaps that's still significant enough for 0.8.

 o BIP process: are we happy with how it is working? What can we do to
 improve it?

Amir seems to be more and more absent these days, so it might be nice to setup 
a successor failsafe in the event that he cannot be reached. It would be a 
shame for the BIP process to fall apart merely because we can't get numbers 
assigned.

But more important to the success of BIP today, I think, is encouraging wider 
community participation. The stratum mining mess seems to be a direct result 
of lack of participation in the GBT BIP process (resulting in it not being as 
ideal as some pools desire) and lack of any peer review/contribution toward 
the stratum protocol. What can we do to increase awareness of BIP and 
encourage more collaboration?

Luke

--
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] IRC meeting agenda, 18:00 UTC Thursday

2012-11-06 Thread Luke-Jr
On Tuesday, November 06, 2012 7:56:23 PM slush wrote:
 On Tue, Nov 6, 2012 at 7:13 PM, Luke-Jr l...@dashjr.org wrote:
  But more important to the success of BIP today, I think, is encouraging
  wider community participation.
 
 It's not about BIP process, it's possibly about content of particular
 proposals.
 ...
 I promised to write BIP draft for Stratum, I proposed and implemented
 get_transactions method to allow Stratum jobs inspection. What more do you
 want, seriously? I'm soo tired by you, Luke.

Perhaps the problem lies in misunderstanding of the BIP process, then, rather 
than awareness of it. BIP isn't just write a document; that's just the first 
step. The main thing is that it gets peer review, changed to meet the 
community's needs, and when done should result in a common standard suitable 
to the needs of the whole community. Whatever the reason, there was a failure 
of key members of the community to participate in the GBT BIP process and 
ensure it addressed their needs/wants; identifying and addressing that is 
something that would improve the BIP process.

get_transactions is a step in the right direction, and I don't think anyone 
expects Stratum to reach the same level as GBT overnight considering it took 
months for GBT (though I have no doubt now that the GBT discussions have taken 
place, that some dedicated individual could probably combine the two if they 
dedicated a few days to it). My comments, however, were not intended to bash 
stratum or mere complain about the past (it can't be changed), but an attempt 
to learn from the past and figure out how we can improve things the next time 
around.

Luke


--
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Hosting of compiled bitcoin client

2012-10-14 Thread Luke-Jr
On Sunday, October 14, 2012 8:52:33 PM Kyle Henderson wrote:
 Given that sourceforge has shown to restrict access to a number of
 countries at the request of the USA

This needs some clarification. If the USA has requested it, then presumably 
there's some legality involved, and our US developers shouldn't be made liable 
for it. The specific reason SourceForge has restricted access should be made 
known so non-US developers (or gitian builders) can evaluate their own laws 
and hopefully at least one will be in a jurisdiction that allows it.
But GitHub is also US-located, so hosting it there may be a problem too.

Luke

--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Segmented Block Relaying BIP draft.

2012-09-10 Thread Luke-Jr
On Monday, September 10, 2012 3:07:52 PM Matthew Mitchell wrote:
 Here is a BIP draft for improving the block relaying and validation so that
 it can be done in parallel and so that redundancy can be removed. This
 becomes more beneficial the larger the block sizes are.
 
 https://en.bitcoin.it/wiki/User:MatthewLM/ImprovedBlockRelayingProposal

Most of the problem with block propagation lies in implementation, not 
protocol... Distributing missing transaction on an as-needed basis is a 
possible improvement at the protocol level, but there hasn't (AFAIK) been any 
research into whether the little benefit outweighs the cost yet. In any case, 
I don't see why 6 new messages are needed instead of simply adding a single 
new type to getinv?

--
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] Version 0.7 release planning

2012-08-02 Thread Luke-Jr
On Thursday, August 02, 2012 4:43:25 PM Jeff Garzik wrote:
 Opening the floor...  What do we collectively want to happen, before
 0.7 release?  What is the todo list for 0.7?

Based on pull-capable dev comments, I've personally noted these branches as 
accepted for 0.7:

 7) HOPEFULLY: Addnode optimization and addnode access via RPC
 BlueMatt https://github.com/bitcoin/bitcoin/pull/1549
 
 8) MAYBE: Transition to requiring block height in block coinbases
 gavinandresen https://github.com/bitcoin/bitcoin/pull/1526
 
 10) I THINK WE WANT THIS?  Make IPv6 support optional again (defaults
 to enabled)
 luke-jr https://github.com/bitcoin/bitcoin/pull/1431

 11) MAYBE: getblocktemplate ('getmemorypool', post IRC debate)
 luke-jr https://github.com/bitcoin/bitcoin/pull/936
+
+ m) getmemorypool: longpolling support
+ luke-jr https://github.com/bitcoin/bitcoin/pull/1355
+
+ m) Refactor transaction/accounting time
+ luke-jr https://github.com/bitcoin/bitcoin/pull/1393

I also personally feel these are appropriate and ready for 0.7:
 4) Add 'mempool' P2P command, and extend 'getdata' behavior
 jgarzik https://github.com/bitcoin/bitcoin/pull/1641
 
 6) JSON-RPC method: prioritisetransaction txid priority delta
 luke-jr https://github.com/bitcoin/bitcoin/pull/1583
 
 9) RPC: add facility to enable RPCs to run outside cs_main, wallet locks
 jgarzik https://github.com/bitcoin/bitcoin/pull/1493
+
+ m) Treat generation (mined) transactions less different from receive
+ transactions
+ luke-jr https://github.com/bitcoin/bitcoin/pull/1409

Also these, but they need testing:
 1) CreateNewBlock: Child-pays-for-parent / Add transaction fee later
 luke-jr https://github.com/bitcoin/bitcoin/pull/1647
 
 5) PROBABLY NOT, BUT MAYBE: Relay blocks as a preview before
 checking the transactions in them
 luke-jr https://github.com/bitcoin/bitcoin/pull/1586
+
+ m) Bitcoin-Qt (Windows only): enable DEP for bitcoin-qt.exe
+ diapolo https://github.com/bitcoin/bitcoin/pull/1614

I also feel it is very important that Wumpus/laanwj decide on a name for his 
client (formerly known as Bitcoin-Qt) and add it to the software instead of 
simply claiming it is Bitcoin as it has for a week or so now - that change 
is anticompetitive and will confuse new users into thinking Bitcoin is the 
software too easily.

Luke

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

2012-07-30 Thread Luke-Jr
On Monday, July 30, 2012 8:26:12 PM Amir Taaki wrote:
 https://en.bitcoin.it/wiki/BIP_0022

Note that the Pooled Mining parts have already been moved to:
https://en.bitcoin.it/wiki/BIP_GMPPM

It just needs a number assigned (as the last part).

--
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] Signing release binaries

2012-07-29 Thread Luke-Jr
On Sunday, July 29, 2012 10:17:51 AM Mike Hearn wrote:
 I guess Gavin would be the final signer.

Considering that Gavin is not interested in participating in any way in the 
stable versions, I would prefer to see someone else responsible for OS-vendor 
signing.


--
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] Scalability issues

2012-07-27 Thread Luke-Jr
On Friday, July 27, 2012 5:59:20 AM grarpamp wrote:
  I now have an 1.8 ghz p3 celeron (128k cache) which should be
  substantially slower than your machine, running vintage 2.6.20 linux.
  Unfortunately I forgot to turn on timestamp logging so I don't know
  how long it took to sync the chain, but it was less than two days as
  that was the span between when I checked on it. It's staying current
 
 Well, are you running bitcoin on, say, an FS with sha256 integrity
 trees for all bits and AES-128-XTS/CBC disk encryption?

Trying to run state-of-the-art encryption on EVERYTHING on an ancient computer 
is fairly ill-advised. I encourage you to continue with the plan to go 
shopping.

 Someone suggested I investigate turning off the above features.
 Since I'd find their loss undesirable [1], and there's not much to be
 tuned there anyways, I've given up and am investigating what more
 GHz and cores will do.
 
 [1] Keeping data both intact and private is a good thing. Does your
 checkbook deserve any less?

Sounds reasonable...
but why do you also need to encrypt 2+ GB of public record?

Luke

--
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-16 Thread Luke-Jr
On Monday, July 16, 2012 11:47:02 PM Jeff Garzik wrote:
 Vladimir does raise a fair point, though.  Hackathon seems appropriate
 for bitcoin.org as it is focused on dev-related activities.  (full
 disclosure: speaking at bitcoin2012.com)  The conference might or
 might not be.  The conference does seem community focused, so I don't
 object to it being on bitcoin.org...  But if consensus prefers
 otherwise, that's OK too.

IMO, bitcoin.org is more community-focussed anyway.
How often do devs use the site, compared to GitHub etc?

Someone else made a pullreq for Bitcoin Magazine; I suggest(ed) that
for-profit organizations should be asked to pitch in some way or another.
Who should organize that, I don't know. If Bitcoin Consultancy/Amir is behind 
the conference, I suggest their/his development contributions should be 
sufficient in that respect.

 PS.  This seems like material for pull requests, which is preferred
 over mailing list email + git push.  When working on the satoshi
 client, we all ACK each other's pull req for anything beyond the
 trivial.

I concur, this should be discussed in a pullreq.

--
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 Luke-Jr
FWIW, all this argumenting is why my original suggestion for a Clients list 
focussed on objective information in alphabetical order.

--
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] 0.6.x - detachdb in wrong place

2012-06-17 Thread Luke-Jr
On Sunday, June 17, 2012 11:04:42 PM grarpamp wrote:
  https://github.com/bitcoin/bitcoin
  https://git.gitorious.org/bitcoin/bitcoind-stable
  
  The latter is Luke's backports of security and stability fixes to
  otherwise unmaintained old versions.
 
 Ah ok, coming from cvs/svn, it's a bit different to find things.
 There's something to be said for maintenance of pior branches.
 Though I see some things I can use in github and my work would
 be more useful there, so maybe I'll stwitch to that from gitorius/0.6.x.
 
 Presumably the github/0.6.2 branch is safe for production?

No, that was a temporary branch of what became the stable 0.6.x branch.
GitHub/master is bleeding edge. For production, you usually want the stable 
branches/releases (which are on Gitorious).

The fix to -detachdb's position in -help was just merged to master, and should 
be backported sometime in the next few days.

Luke

--
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] After compressed pubkeys: hybrid pubkeys

2012-06-16 Thread Luke-Jr
On Saturday, June 16, 2012 11:39:00 PM Gregory Maxwell wrote:
 On Sat, Jun 16, 2012 at 5:41 PM, Gavin Andresen gavinandre...@gmail.com 
wrote:
  RE: 0x06/0x07 'hybrid' public keys:
  Any opinions? Forbidding it certainly makes alternative implementation
  slightly easier in the future, but I'm not sure the hassle of a network
  rule change is worth it.
  
  I say treat any transactions that use them as 'non-standard' -- don't
  relay/mine them by default, but accept blocks that happen to contain
  them.
  
  I agree that a rule change isn't worth it right now, but making them
  non-standard now is easy and should make a rule change in the future
  easier.
 
 ACK.  Hopefully no one will mine these before we can merge denying
 them into another rule change. But if they do, oh well.

I'm willing to make Eligius reject these as well, if someone provides a patch 
that doesn't depend on IsStandard being enforced...

Same goes for rejecting OP_NOPn - I can't see any legitimate reason we'd 
want these on mainnet right now.

Luke

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


  1   2   >