https://blockchain.info/tx/7945140310e5e22e2d38f41eba3422e11e92719aad527e6e4a4d7b660ac5cda7?show_adv=true

The tx is large (17K) but it includes >0.1mBTC per KB in fees, it has no double spent or unconfirmed inputs, and it has no dust outputs.  The interesting thing is that the tx was sent from Bitcoin Core (v0.91).  That node does not have direct connectivity to blockchain.info so it must have been relayed by at least one peer.  The recipient node is also using Bitcoin Core v0.91 but the tx is not in the memory pool and my assumption is that the recipients peers are dropping it.  The question is why?  Possibly a difference in relaying rules on older nodes (and the recipient is unlucky enough to have all older nodes as peers?  As of the time of the post it hasn't been included in a block but I am more concerned with what would keep it from being seen as an unconfirmed tx by the recipient node.

On edit: ok it was just included in a block and the recipient node instantly recognized and reported the confirmed tx but why wasn't it relayed prior to being confirmed.

Merge mining is an awesome concept which can "reuse" the existing Bitcoin infrastructure to secure multiple blockchain type systems (not all of which need to be "currencies").  As currently implemented I believe it will not be a viable option for new chains as Bitcoin tx volume grows.  Correction: overhead grows only by the log of the tx volume so this is less of an issue although the overhead could be dropped further.

To link the aux chain to the bitcoin PoW the block hash of the aux chain needs to be encoded in the bitcoin block.  As the bitcoin block structure has no field for holding arbitrary values it is encoded in the coinbase transaction.  To link the coinbase tx to the merkle root hash in the blockheader requires recording the merkle branch.  The size of the merkle branch in bytes is (32 * num_txns / 2). (32 * log2(num_txns).  

One way to improve the efficiency of merged mining would be to add an fixed length "aux" 32 byte field to the blockheader.  This would make the bitcoin block header marginally larger but wouldn't make the full block any larger.  The bitcoin protocol can be extended by introducing a new version of the block header. It would be optimal to bundle a number of changes together in the next version of the blockheader.

Some ideas on how the blockheader can be extended in a manner which doesn't break compatibility with existing ASIC infrastructure:
https://bitcointalk.org/index.php?topic=626377.0

What does "keypool reserve" & "keypool return" in the debug log indicate?

2014-05-26 16:34:01 keypool reserve 9028
2014-05-26 16:34:01 keypool return 9028
2014-05-26 16:34:01 keypool reserve 9028
2014-05-26 16:34:01 keypool return 9028

Should this activity be banned?

https://bitcointalk.org/index.php?topic=621411.msg6913184#msg6913184

I can't see a purpose for doing this other than it would allow someone to instantly delete any or all of their posts in the future.   I doubt bitcointalk maintains archives of all linked images so post "history" would be useless for verifying or restoring "deleted" posts.

As a side note it makes quoting a pain in the ass, is just generally disruptive, and makes the contents unsearchable but I am more concerned with the malicious use.

[If the orphan cost is higher than the fee paid then the miner has no direct economic incentive to include the transaction. Including the transaction will in the long run reduce the net revenue paid to the miner.]

The economics of orphans as it relates to transactions has become more understood in the last year.  I started thinking about how it would affect a currency like Peercoin (PPC) which doesn't compensate miners with transaction fees and instead burns them.   Will this create an economic disincentive for miners to include transactions in the next block?

Peercoin has a low level of persistent inflation.  PoS will increase the coin supply by 1% annually.  Peercoin is a hybrid coin with both PoW and PoS.  The PoW component contributed to the majority of the inflation in its early history but it will decay to a negligible level over time.  For the purpose of this question the PoW component can be ignored.   PPC offsets this new minting by destroying the transaction fees instead of paying them to miners as with Bitcoin et al.   Monetary inflation will approach at rate of:  m = 1% - (tx fees / money supply).  Unlike some inflation zealots I have no issue with this.  Inflation is capped at 1% and in reality will be lower, it is even possible the coin will be slightly deflationary.   In the long run a monetary system with <1% inflation or <1% deflation is not a material change to a money supply which is static.  Burning the tx fees is an interesting way to provide a counterbalance to the continual minting of new coins.  This structure however creates an economic disincentive to miners in the form of uncompensated orphan costs.  This shouldn't be viewed as judgement on the developers.  Peercoin launched almost two years ago and there was less discussion on the economics of transaction selection at that time.

For those unfamiliar with the term, orphan costs refer to the economic cost of including one more transaction in the next block.  All blockchain based currencies have orphaned blocks.  Orphaned blocks are due to a second competing block being found after a miner has found a block but before the block has propagated the entire network (specifically to all miners).  The larger the latency between when a block is found and when it has finished propagating the higher the probability that a competing block will be found.  Although it isn't the only factor the size of the block contributes to the latency.  All other factors being the same a block which is twice as large, will take twice as long to propagate and thus has twice the chance of being orphaned.   The cost can be expressed as Bitcoins (or uBTC) per kB.  If the orphan cost is higher than the fee paid then the miner has no direct economic incentive to include the transaction.  Including the transaction will in the long run reduce the net revenue paid to the miner.  To date most miners have been forward looking and include transactions even if they do marginally reduce net revenue however a system based on direct economic benefit is stronger than one based on charity or working for the common good.  

There are some optimizations that are possible and with Bitcoin the declining subsidy and rising number of paying transactions will reduce the orphan cost over time.  The burning of fees on the Peercoin network means that all transactions are essentially unpaid from the view of the miner.  Peercoin can use the same optimizations proposed for Bitcoin to reduce the orphan cost but the gross revenue for all transactions will always be zero.  This means that all transactions will have a negative effect on net revenue and there is no economic incentive to include the transaction in the next block.  The maximum net revenue is already available by mining an empty block and including any additional transactions only serves to lower the miners net revenue.  The more transactions the miner includes the less net revenue he receives.  Some miners may work for the common good and there is an indirect mutual benefit by supporting the network, however arrangements which lack a direct benefit can lead to a tragedy of the commons.

Do you see this as an issue for Peercoin or more widely for any system where the fees are burned?  How can the disincentive be reduced or eliminated?  I have a couple ideas (but they all involve hard forks).  I will post them later but I would like to see other viewpoints first.

Bitcoin relies on random numbers for keys and signatures.  Bitcoin clients/wallets may also rely on them for encryption (salt), and seed generation (HD wallets).  The cryptographic primitives used in Bitcoin have been extensively tested and in all likelihood can not be "broken" but if used with flawed or backdoored PRNG all that security can be bypassed.  

Is your PRNG (pseudo random number generator) secure?  The reality is that it may very well be, but providing it is a very difficult task and impossible when the operating system is not built from source (although one may be able to prove the reverse in some cases).  An alternative is a hardware RNG device, sometimes called a TRNG (true random number generator).  Generally speaking they are expensive and unless open source you are merely trading one opaque box for another.   Designing a hardware device that outputs numbers which appear to be statistically random but are very much deterministic is trivial (a simple example would be take the HMAC of an incrementing counter with a known password).  

Alpharand is an experiment to look into an open source TRNG.  Hardware random number generators can be categorized as by their source of entropy.  Some use sampling of a chaotic system (like radio "noise) however they need to be carefully monitored.  Other devices uses quantum mechanics as the source of entropy.  Quantum mechanics are non-deterministic at least based on our current (limited) understanding of the universe.  

The classic quantum randomness example is firing a single photon at a half mirror. If properly calibrated, some of the time the photon will bounce off the mirror and some of the time it will pass through.  The event can be observed but not predicted.   The action of each individual photon is non deterministic.  This is not (yet) suitable for a DIY project as single photon emitters are expensive.  Another quantum event that can be observed relatively easy is the radioactive decay of unstable isotopes.   The half life of a material gives us the length of time before half of the isotopes has decayed, however the decay of an individual atom is once again non-deterministic.  More useful for our purposes, the length of time between any two decays is also non-deterministic.

I am looking for a lightweight implementation of basic ECDSA operations, preferably in C#.  If not C# then second choice would be Java (as it can be rather easily be translated to c#) but any language is better than nothing.

I am aware that there is bouncy castle however that is a very heavy interconnected library with lots of complex inheritance which makes parsing out the "necessary bits" probably more of a pain.  I would prefer a simple flat set of minimal classes but even parsing from a lighter library would be a better option.  Yes in general I subscribe to the "never roll your own" theory of development but this is a special case.  A vendor sent me a programmable smartcard development kit for evaluation and it has pretty impressive specs.  Still it is a smartcard so we are talking tens of KB of memory (combined storage and operating memory) so any code is going to need to be scaled down.   SHA-256 (and AES if I wanted to incorporate that for delayed tx signing have hardware support so that is a non-issue.  Rolling an implementation of RIPEMD-160 (thanks mono source code) was rather trivial but ECDSA is a whole different beast.

Bitcoin uses a single static curve (secp256k1) so there is no need for library support for named curves or custom curve params, the secp256k1 parameters coded as constants will work just fine.

Bitcoin relies on random numbers for keys and signatures.  Clients may also rely on them for encryption (salt), and seed generation (HD wallets).

Proving a PRNG is secure is a very difficult task and is impossible when the operating system is not built from source.  Quantum mechanics are non-deterministic and thus provide an alternative method of generating randomness.

I just need to wait for a missing component to arrive.

(Stupid broken image proxy - direct link http://i.minus.com/ibzPEHrUJ3pByt.jpg )
Bonus points if you can figure out what it is without using google.

Bitcoin relies heavily on cryptographically secure PRNG and as we have seen from the android exploit, ensuring high entropy is often a challenge.  This functionality is handled by the operating system which means the security of the client becomes heavily dependent on the security of underlying operating system.  Even if we discount the possibility of three letter agencies intentionally weakening the PRNG (which they may do even for non-Bitcoin reasons and Bitcoin users become collateral damage) there is always the possibility of implementation bug in certain situations.

There is a proposal for deterministic ECDSA signatures
http://tools.ietf.org/html/rfc6979

This would remove the need for random values as nonces in Bitcoin transaction signatures.
HD wallets remove the need for random values when generating private keys.
HD wallet seeds still need a high entropy random number but as this only needs to be done once it could even be done by dice rolls (100 rolls of standard six sided for 256 bit seed).

[via]

I got this email today and here is how it shows up in gmail

BTC-E no_reply@btc-e.com via smtp.com     5:58 AM (5 hours ago)
to me

Hello!
We inform you that you scan the downloaded document # 14327223 http://ge.tt/... <rest of url redacted> can not be verified for the following reason:
-Specified in the certificate data in a language other than the language passport data
Please provide a new file to check.
Sincerely,

Representative Director
BTC-E Co., Ltd.
Shibuya-ku, Tokyo

One thing to look for is this

BTC-E no_reply@btc-e.com via smtp.com

what this is saying is the email was sent indicating it was sent from btc-e.com however it actually came from smtp.com.  Now that this isn't that uncommon many sites move their email off their domain however there is a way of authenticating these off email domains and it wasn't done.

So any time you see a "via" in gmail be wary.  There is a high chance it is a phishing attempt.  It could be an uneducated operator or some misconfiguration but your phishing radar should be going off when you see a redirected email.

Looking at the source

Delivered-To: <redacted>
Received: by 10.170.132.70 with SMTP id y67csp158747ykb;
        Tue, 11 Mar 2014 02:58:50 -0700 (PDT)
X-Received: by 10.66.162.74 with SMTP id xy10mr46827749pab.4.1394531930066;
        Tue, 11 Mar 2014 02:58:50 -0700 (PDT)
Return-Path: <no_reply@btc-e.com>
Received: from mailer134.gate183.sl.smtp.com (mailer134.gate183.sl.smtp.com. [192.40.183.134])
        by mx.google.com with ESMTP id pi6si17253804pbb.10.2014.03.11.02.58.49
        for <gerald@tangiblecryptography.com>;
        Tue, 11 Mar 2014 02:58:50 -0700 (PDT)
Received-SPF: softfail (google.com: domain of transitioning no_reply@btc-e.com does not designate 192.40.183.134 as permitted sender) client-ip=192.40.183.134;
Authentication-Results: mx.google.com;
       spf=softfail (google.com: domain of transitioning no_reply@btc-e.com does not designate 192.40.183.134 as permitted sender) smtp.mail=no_reply@btc-e.com;
       dkim=pass header.i=@smtp.com
Return-Path: <no_reply@btc-e.com>
X-MSFBL: Z2VyYWxkQHRhbmdpYmxlY3J5cHRvZ3JhcGh5LmNvbUAxOTJfNDBfMTgzXzEzNEBz
   bXRwY29tXzExQA==
DKIM-Signature: v=1; a=rsa-sha256; d=smtp.com; s=smtpcomcustomers; c=relaxed/simple;
   q=dns/txt; i=@smtp.com; t=1394531929;
   h=From:Subject:To:Date:MIME-Version:Content-Type;
   bh=EptpTsx18R734YExCd0CN520kmNgDylmBwR2r+Pyuqw=;
   b=f2hvNXaJT9YyFXhXAYg7qRLTST5KlgacBGLJE/rQYLnlNXuiUMbLxMlOvgePe0Mc
   lmS0HCW2hdDJ4BGdqwpVWMxdTIUR8JtiIz8XF4oSkXTYG80GoFz5SWxGfX7w4K9j
   9gqnLIbogpkBa+DxB0xX7pENIlH6Pf/XkyQScWaf1bA=;
Received: from [216.55.179.130] ([216.55.179.130:61625] helo=216-55-179-130.dedicated.codero.net)
   by sl-mta06.smtp.com (envelope-from <no_reply@btc-e.com>)
   (ecelerity 3.5.5.39309 r(Platform:3.5.5.0)) with ESMTPSA (cipher=AES256-SHA)
   id DD/65-01037-95EDE135; Tue, 11 Mar 2014 09:58:49 +0000
From: "BTC-E" <no_reply@btc-e.com>
Message-ID: <DD.65.01037.95EDE135@sl-mta06>
Subject: BTC-E Passport
To: <redacted>
Content-Type: multipart/alternative; boundary="chnq7o2neA2=_nG4ebCT6XPRtS76K4DnFp"
MIME-Version: 1.0
Organization: BTC-E
Date: Tue, 11 Mar 2014 02:58:51 -0700
X-SMTPCOM-Tracking-Number: 755a5166-7a64-405b-9339-37db125228cb
X-SMTPCOM-Sender-ID: 24012
X-SMTPCOM-Spam-Policy: SMTP.com is a paid relay service. We do not tolerate UCE of any kind. Please report it ASAP to abuse@smtp.com

A couple of things in here.  The first is that the sent from and reply to emails are simply lines of text.  There is absolutely no security.  You can send email with a from email address of obama@whitehouse.com as easily as you can type the letters.  So never rely on those.

This show where the email actually originated from

Received: from mailer134.gate183.sl.smtp.com (mailer134.gate183.sl.smtp.com. [192.40.183.134])

now as I said before it isn't that uncommon for email to originate off domain however this is the warning sign

spf=softfail (google.com: domain of transitioning no_reply@btc-e.com does not designate 192.40.183.134 as permitted sender) smtp.mail=no_reply@btc-e.com;

In simple terms it is saying btc-e has not approved the originating server to send email on its behalf.  Google should really make these types of "soft" failures more pronounced with scary warnings but they don't.

Lastly the actual originator is a commercial service.  They provided this information in the header

X-SMTPCOM-Tracking-Number: 755a5166-7a64-405b-9339-37db125228cb
X-SMTPCOM-Sender-ID: 24012
X-SMTPCOM-Spam-Policy: SMTP.com is a paid relay service. We do not tolerate UCE of any kind. Please report it ASAP to abuse@smtp.com

If your email client gives you the option to report as phishing (not just report as spam) be sure to do so.  Most will forward this back to in this case to abuse@smtp.com.
You can also manually forward it to abuse@smtp.com and report it is phishing.

http://www.reddit.com/r/Bitcoin/comments/1zz21j/mtgox_2014_hack_database_revealed_live_from_mark/

(oh and the dump is hosted on Mark's blog).

WARNING:  I haven't verified or scanned the files.  It is at least possible they contain malware including the bitcoin stealing kind.   BE SMART and take precautions when downloading unknown files from self described hackers.

On edit: the exe in the zip file a wallet stealer.  Don't run unless you have too many bitcoins and then it will solve that problem for you.

In a very brief phone conversation with Business Insider Friday, Arthur Nakamoto indicated he'd been misquoted or misinterpreted in some way, and had harsh words for McGrath Goodman.  "She's destroying my eldest brother," he said, adding, "this is sick," before hanging up.

http://www.businessinsider.com/arthur-nakamoto-newsweek-interview-2014-3

Los Angeles County sheriff's deputies say that a Newsweek reporter's story exposing what the magazine claims is the founder of Bitcoin did quote them and the man featured in the article accurately, a spokesman said.

The San Gabriel Valley suburb of Temple City  was inundated by reporters Thursday after Newsweek alleged resident Dorian Nakamoto was really "Satoshi Nakamoto," the man behind the virtual currency. In the Newsweek article he is quoted as telling the reporter "I'm no longer involved in that and I cannot discuss it" while deputies are present.

http://www.latimes.com/local/lanow/la-me-ln-la-sheriffs-say-satoshi-nakamoto-man-did-talk-about-bitcoin-to-newsweek-reporter-20140307,0,609860.story#axzz2vKdnQjGj

https://www.youtube.com/watch?v=GrrtA6IoR_E

... tomorrow they would have a press statement saying the Satoshi story was incorrect but it isn't their fault due to a fact malleability bug.


Too soon?

Occam's razor time.  Do you think Satoshi (creator of Bitcoin) would have trouble unsubscribing from a mailing list?
Newsweek ruined this man's life for nothing.  

just a reminder folks:

if you can't figure out how to handle list commands like
unsubscribing or changing your message preferences by yourself,
please contact me directly rather than dump a message into 230
mailboxes of people who can do nothing about it.

\dmc



At 4:47 PM -0700 5/30/02, dorian nakamoto wrote:
>i do not wish to be flooded w/your e-mails.
>please delete me:
>
>   [EMAIL PROTECTED]
>
>no, i don't wish goto each individual's msgs that i've
>rcvd so he won't send me anymore.  i want 1 swooping
>act.
>
>thx
>--- Jim Curry <[EMAIL PROTECTED]> wrote:
>>  Tony:
>>
>>  I see different options to check incoming emails but
>>  no mention of the
>>  software checking outgoing.  Where do you see that?
>>
>>  Jim
>>
>
>
>__________________________________________________
>Do You Yahoo!?
>Yahoo! - Official partner of 2002 FIFA World Cup
>http://fifaworldcup.yahoo.com

https://www.mail-archive.com/sslivesteam@colegroup.com/msg09756.html

http://www.techworm.net/2014/03/mtgox-source-code-leaked-by-hacker-on.html

As a developer all I can say is ...
I have nothing to say just stunned silence that this was the codebase used to process millions of dollars and BTC everyday.

[Bitcoin Axiom #0 - If you do not have the private keys for your bitcoins, then you have no bitcoins.]

Bitcoin Axiom #0 - If you do not have the private keys for your bitcoins, then you have no bitcoins.

If you deposit your bitcoins with an exchange then although their site may display an amount of bitcoins what you have is an IOU for a certain amount of bitcoins.   An IOU is a form of debt, it only has value as long as it is honored.  A significant portion of debt is never repaid.  Bitcoin has no counterparty risk, a bitcoin IOU does have counterparty risk.

[Gox is the worst-run business in the history of the world]

“Gox is the worst-run business in the history of the world,” said Roger Ver, in an instant message interview. Ver is a bitcoin advocate who lives across the street from Mt. Gox’s Tokyo offices and tried to help out the troubled exchange the last time it was hacked, back in 2011.

http://www.wired.com/wiredenterprise/2014/02/bitcoins-mt-gox-implodes/


Thanks for making me laugh.  I can visualize a frustrated Roger typing that out.  That is it folks, I am going to bed.

Gox is dead, long live Bitcoin!

BitSimple's "logo"? Yeah that was done by me (an enterprise backend developer who gets confused with paint) as a way of getting up and running quickly.  It served its purpose but I don't want to make any more artists cry, so it is high time to get something a "little" better.    Help us give these talented designers some feedback by picking your favorite in this poll.  

<link removed - voting closed>

I promise it only takes a few second.  I am sure the designers would love to hear any specific feedback and we can share the results with the designer so be honest they are big kids.

Thank you for your help,