Wladimir | 18 Sep 14:52 2014
Picon

Re: [ann] Bitcoin Core 0.9.3 rc2 is available for download

FYI rc2 has been uploaded last weekend to
https://bitcoin.org/bin/0.9.3/test/, with some further fixes in
network and memory behaviour

- Remove a useless millisleep in socket handler
- Stricter memory limits on CNode
- Better orphan transaction handling
- Add `-maxorphantx=<n>` and `-maxorphanblocks=<n>` options for
control over the maximum orphan counts

Wladimir

------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
Vezalke | 17 Sep 21:28 2014
Picon

Re: Payment Protocol Proposal: Invoices/Payments/Receipts

Alan Reiner <etotheipi <at> gmail.com> writes:

> 
> 
> 
> On Thu, Dec 6, 2012 at 11:56 AM, Gavin Andresen <gavinandresen <at>
gmail.com> wrote:When I say "pass around" I'm not thinking of users copying
and pasting, that would be a terrible user experience; all of that
communication needs to happen automatically behind the scenes. Lets tackle
that after we've got the simpler customer-pays-merchant flow working nicely
(funded-escrow-pays-merchant is a subset of that, anyway).
> 
> 
> 
> 
> I think that the "pass around" method needs to happen in addition to the
methods of transparent protocols that occur behind the scenes.  For one,
there's a lot of CONOPs that need to be worked out by getting knowledgeable
people using it, and providing feedback about how it could/should/will be
used and how it could be improved.  The pass-around method is simpler to
implement and still usable by the types of users that will be using it in
the beginning -- experts.  Also, I see that for very large, important
multi-sig tx/contracts/escrow, the "manual" method might be preferred --
much the same way many people prefer manual-transmission cars even though
automatics are "easier" -- some people/organizations will want the control.   
> 
> I'm all for protocols that enable higher-level access to this
functionality, I'm just saying there should be lower-level access, too.
> 
> 
(Continue reading)

ggprodukcija kig | 15 Sep 09:32 2014
Picon

how

Hi

i have some money on btc. How invest, and where invest for more eranig
------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Peter Todd | 13 Sep 15:55 2014

Does anyone have anything at all signed by Satoshi's PGP key?

So far I have zero evidence that the common claim that "Satoshi PGP
signed everything" was true; I have no evidence he ever
cryptographically signed any communications at all.

--

-- 
'peter'[:-1] <at> petertodd.org
00000000000000000ce4f740fb700bb8a9ed859ac96ac9871567a20fca07f76a
------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Mark van Cuijk | 12 Sep 22:59 2014

Re: BIP72 amendment proposal

On 12 Sep 2014, at 20:43 , bitcoin-development-request <at> lists.sourceforge.net wrote:

> Specifically relevant here:
> http://security.stackexchange.com/questions/34796/truncating-the-output-of-sha256-to-128-bits.
> 
> If you're going to truncate though, why not just leave the amount of
> bits up the the person generating the QR code? The client simply takes
> the hash prefix (any length up to full 256-bits) and makes sure it's a
> strict prefix of the actual hash of the payment request.

If you do so, please make sure the length of the hash is included in the PaymentDetails/PaymentRequest. If
someone parses the URI and doesn’t have an authenticated way of knowing the expected length of the hash,
a MITM attacker can just truncate the hash to lower security.

/Mark
------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
Mark van Cuijk | 12 Sep 12:11 2014

Re: BIP72 amendment proposal

On 12 Sep 2014, at 11:55 , bitcoin-development-request <at> lists.sourceforge.net wrote:

> The hash is meant to link the trust anchor (e.g. the QR code) to the
> payment request message in a secure way. This will solve the problem
> several apps are comparing address+amount fields as a workaround
> instead, preventing some advanced BIP70 usecases. When these apps read a
> matching hash, they need not compare any of the other fields.

Sounds like a good plan.

Do you have a list (possibly incomplete) of apps that perform this kind of checking? We’re currently
working with some parties in a supply chain to allow a consumer payment on a retail website to
automatically pay supply chain parties, the way BIP70 allows with multiple outputs on a transaction.
This behaviour would prohibit this use case.

/Mark
------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
Andreas Schildbach | 12 Sep 11:29 2014
Picon

BIP72 amendment proposal

This is the discussion post corresponding to this PR:
https://github.com/bitcoin/bips/pull/106

"Amend BIP72 by an "h" parameter, which contains a hash of the
PaymentRequest message that is fetched via the "r" parameter.

The hash is meant to link the trust anchor (e.g. the QR code) to the
payment request message in a secure way. This will solve the problem
several apps are comparing address+amount fields as a workaround
instead, preventing some advanced BIP70 usecases. When these apps read a
matching hash, they need not compare any of the other fields.

Thanks to Julian Haight for helping with the standard."

------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
Wladimir | 1 Sep 10:25 2014
Picon

Testing and reviewing requested for work on Bitcoin Core wallet

Hello,

Cozz Lovan has been doing great work on Bitcoin Core's wallet code lately.

If anyone cares about Bitcoin Core's wallet, for example its
performance, do help testing and reviewing these improvements so that
they can make it into 0.10:

Subtract fee from amount
https://github.com/bitcoin/bitcoin/pull/4331

[Wallet] Improve ReorderTransactions(..)
https://github.com/bitcoin/bitcoin/pull/4697

[Wallet] Replace OrderedTxItems(..) with in-memory map
https://github.com/bitcoin/bitcoin/pull/4702

[Qt] Call checkBalanceChanged() periodically instead for every updated tx
https://github.com/bitcoin/bitcoin/pull/4712

Move g_signals.SetBestChain(..) below SyncWithWallets
https://github.com/bitcoin/bitcoin/pull/4798

[Wallet] Call SetBestChain before and after rescan
https://github.com/bitcoin/bitcoin/pull/4800

[Wallet] Do not flush the wallet in AddToWalletIfInvolvingMe(..)
https://github.com/bitcoin/bitcoin/pull/4805

Wladimir

------------------------------------------------------------------------------
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
Matt Corallo | 28 Aug 22:21 2014

RIP Hal Finney

I'm sure many of you have already seen this, but Hal Finney passed away
on Tuesday. While his body is being cryogenically preserved, we should
all take a moment to thank Hal for everything he did for the cypherpunk
community, specifically helping hugely in the early days of Bitcoin as
well as PGP.

Matt

http://lists.extropy.org/pipermail/extropy-chat/2014-August/082585.html

------------------------------------------------------------------------------
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
Wladimir | 28 Aug 16:41 2014
Picon

[ann] Bitcoin Core 0.9.3 rc1 is available for download

Bitcoin Core version 0.9.3rc1 is now available from:

  https://bitcoin.org/bin/0.9.3/test/

This is a release candidate (test version) for a new minor version
release, bringing
only bug fixes and updated translations.

Please report bugs using the issue tracker at github:

  https://github.com/bitcoin/bitcoin/issues

Upgrading and downgrading
==========================

How to Upgrade
--------------

If you are running an older version, shut it down. Wait until it has completely
shut down (which might take a few minutes for older versions), then run the
installer (on Windows) or just copy over /Applications/Bitcoin-Qt (on Mac) or
bitcoind/bitcoin-qt (on Linux).

If you are upgrading from version 0.7.2 or earlier, the first time you run
0.9.3 your blockchain files will be re-indexed, which will take anywhere from
30 minutes to several hours, depending on the speed of your machine.

Downgrading warnings
--------------------

The 'chainstate' for this release is not always compatible with previous
releases, so if you run 0.9.x and then decide to switch back to a
0.8.x release you might get a blockchain validation error when starting the
old release (due to 'pruned outputs' being omitted from the index of
unspent transaction outputs).

Running the old release with the -reindex option will rebuild the chainstate
data structures and correct the problem.

Also, the first time you run a 0.8.x release on a 0.9 wallet it will rescan
the blockchain for missing spent coins, which will take a long time (tens
of minutes on a typical machine).

0.9.3 Release notes
=======================

RPC:
- Avoid a segfault on getblock if it can't read a block from disk
- Add paranoid return value checks in base58

Protocol and network code:
- Don't poll showmyip.com, it doesn't exist anymore
- Add a way to limit deserialized string lengths and use it
- Add a new checkpoint at block 295,000
- Increase IsStandard() scriptSig length
- Avoid querying DNS seeds, if we have open connections

Wallet:
- Check redeemScript size does not exceed 520 byte limit
- Ignore (and warn about) too-long redeemScripts while loading wallet

GUI:
- fix 'opens in testnet mode when presented with a BIP-72 link with no fallback'
- AvailableCoins: acquire cs_main mutex
- Fix unicode character display on MacOSX

Miscellaneous:
- key.cpp: fail with a friendlier message on missing ssl EC support
- Remove bignum dependency for scripts
- Upgrade OpenSSL to 1.0.1i (see
https://www.openssl.org/news/secadv_20140806.txt - just to be sure, no
critical issues for Bitcoin Core)
- Upgrade miniupnpc to 1.9.20140701
- Fix boost detection in build system on some platforms

Credits
--------

Thanks to everyone who contributed to this release:

- Andrew Poelstra
- Cory Fields
- Jeff Garzik
- Johnathan Corgan
- Julian Haight
- Michael Ford
- Pavel Vasin
- Peter Todd
- Pieter Wuille
- Rose Toomey
- Ruben Dario Ponticelli
- Trevin Hofmann
- Wladimir J. van der Laan
- Zak Wilcox

As well as everyone that helped translating on
[Transifex](https://www.transifex.com/projects/p/bitcoin/).

------------------------------------------------------------------------------
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
Mem Wallet | 27 Aug 02:57 2014
Picon

standardize on bitcoin signed ecies ?


Does anyone see a value in a standardized PGP-style message,
which would allow someone performing a bitcoin transaction to
send signed encrypted messages using only public and private
bitcoin keys ?

I'd like to propose a signed encrypted message protocol, in case
someone see's value in encoding such a thing into a BIP.

------------------------------------------------------------------------------
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Gmane