 Show Posts
|
|
Pages: [1] 2 3 »
|
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
User StarMaged on Reddit belongs to Maged of Bitcointalk.org as of 4/20/2014
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
iQIcBAEBAgAGBQJTVGdQAAoJEFmmB2syczYgR+gP/jRkeVwrYHCVyJdpUEqNKrXo
Ukj8qf7SVWelqHIYv5A6YovlaXJHa5uzamxskM57HOEK5BmbvXCQIoGc4qt3ydHo
sJvO62i8+zNPD9Xth1E1UATK3IgztlFWBx2SWQi32UWvc805e5bwhNEX2m4nwueg
cxq4/jMTnG/qO515P0Ph+MHgThn2T8m5iS4oiul7Hr9qH5RIeCMM53f33LivpQpf
AThRMKVAKP4FYRN1/n98V9qIQOLAt6nrLvSu76cm9Whm9eURLFJo9SklyHmoXQaq
OEHwSw/D5/7TSeV5ebiEl/PsWWx8SJ/+T89PzJY1CdZ2Z4NkBTz3ZUsXaotaOcde
r4sk2wc7pJlsJXjRlXHviBYxfGsbxeDI5zMKciBFSG0Qb0vZ8DkuAHolkhYK1tSa
lYcD44lXXqQ8tOL6ogPIA2Ee3v75+4krqecunYN73D+JtKWf5ueN5pS2N/xzV8cb
j878ldtMpd3+/3chUb2TWuuY7SPoi25J4t6cE2uHqc3I5hYbq9G6lD/V/LacTcyt
ZqR6MN+HF6KejrbTkl9uotujDa25nAk3VdDZgv4ccKES/+PuxpWVt1tQw02POogj
miPDOknaLF46aMol/gimCiUewb5+9o6qQ+IRaZElPp/GIf9ypzmSUhJnQ6wvd/ez
NPffKrkrlUXzQkqCHXtv
=ofb6
-----END PGP SIGNATURE-----
|
|
|
|
From the requirements doc: It should be possible to fairly easily undo any admin/mod action done through the Web interface, or even to undo every mod action since a particular time. It would be neat if this could be extended to all mod-like actions (edit, deletes, etc.) even at the user level. For example, if a user makes a stupid edit to one of their posts, instead of having to contact an admin to undo it (assuming they lost the original text), they could undo it themselves. Now, I realize that this isn't very useful, but bear with me... Since the undo functionality would extend all the way down to the user level, it could also be leveraged by mods to undo their own moderation actions. Currently, if a mod screws up and deletes something by accident, they have to go through the same appeals process to the admins that users have to go through. It would be nice if they could undo their own action themselves. Of course, they wouldn't be allowed to undo the actions of other mods, because that's supposed to be done through an appeal. It would only be used by the actioning mod to fix mistakes that they made. |
|
|
|
|
Sometimes when I'm cleaning out a bunch of posts from a thread, I queue up all of my deletions so that they happen all at once. I do this so that the thread doesn't look odd for people who load it while I'm in the middle of cleaning it out. However, one annoying thing is that I can't queue an edit to happen at the same time as the deletions, so if I want things to not look strange, the system encourages me to just delete the post instead. What I would like is the ability to switch to a batch moderation mode that will queue up all of my actions to happen at once when I commit them. This is similar to the concept of a database transaction.
It would also be neat if I could do multiple (named) batches simultaneously.
Here's a common example of what I mean:
Often, I will come into a thread and find that there are three or more topics going on: the original topic, a side topic, and an ad-hominem attack topic. Because a proper topic splitting of these topics would require me to read a post three or more time in the current setup, the system encourages me to just delete all of the off-topic stuff in a single batch so that I only have to read the posts once. It would be nice if I could just start a new batch once I see a new off-topic branch. However, I won't just be splitting the posts in that branch, so don't just assume that this branching implies a batch of just splits. Currently, when I actually care enough to go through this process manually, I'll often split off a post to a side-topic (because it belongs in that topic) only to then delete it (because it violates other guidelines).
So, I guess what I'm asking for is that, in batch moderation mode, there is a split option that can choose between multiple named threads and that split counts as a mod action for the chosen (named) batch.
Hopefully, this makes sense and you can figure something out.
|
|
|
|
As I alluded to in my post-level permissions thread, one nice feature would be user-made usergroups. Basically, you can make a group and use it in place of a specific user in fields that would require a user, such as a PM. You would probably give the group some kind of prefix so that it's clear that it was made by a user. |
|
|
|
It would be neat if each individual post had UNIX-like permissions so that you could grant or take away moderation abilities (i.e. edit/delete) for an individual post for usergroups lower in the hierarchy than you. To best illustrate this, here are two use cases where this would be useful: 1) Post locking (not to be confused with thread locking): When a moderator needs to remove something from a post and wants to make sure that the user cannot re-add it, it would be useful for a moderator to remove the edit permission for that post from the posting user. If this action was done by someone high up, they may not want lower mods to overrule them, so it would also be useful to remove the edit permission from lower-level moderators. 2) Wiki posts: Many forums have the concept of a wiki post where any user can modify the post. Wouldn't it be neat if every post was just a subcase of that? Below the Original Poster permissions group, there could be an All Users group that can be granted the edit permission. Although I envision there being an advanced permissions editing menu, I would expect these common actions to be a simple alias to those permission settings. While we're talking post permissions, I might as well add that a separate "read" permission would also come in handy. Use cases: 1) Moderators can leave hidden posts saying things like "I cleaned up this thread up to here, and this is what I did". (Hidden-from-the-user mod notes for individual posts would be nice too, but that's a separate feature) 2) Users could make custom usergroups and make it so only people in that group and above (OP, mods, admins) can read the post. Think of it like Kickstarter's backer-only updates. |
|
|
|
The Core Developers of Bitcoin released the 0.9.0 FINAL of Bitcoin Core (aka Bitcoin QT).DOWNLOAD:https://bitcoin.org/bin/0.9.0/bitcoin-0.9.0-linux.tar.gzhttps://bitcoin.org/bin/0.9.0/bitcoin-0.9.0-macosx.dmghttps://bitcoin.org/bin/0.9.0/bitcoin-0.9.0-win.ziphttps://bitcoin.org/bin/0.9.0/bitcoin-0.9.0-win32-setup.exehttps://bitcoin.org/bin/0.9.0/bitcoin-0.9.0-win64-setup.exe15616baea0640277c81a8ca4d3e0d963834b8a7d bitcoin-0.9.0-linux.tar.gz
82b7210587c2037beb5d0b3b9ef2643b7580dfe7 bitcoin-0.9.0-macosx.dmg
5bac25ffc2afa7eaea2bbbd783b787325cf8b537 bitcoin-0.9.0-win.zip
23b315772c86389a8ac05c13bd352f4ec631a659 bitcoin-0.9.0-win32-setup.exe
b404b0ed348be5b15c0704bfdc6b838a732c338e bitcoin-0.9.0-win64-setup.exe This is a Final Version, but its the same as 0.9.0rc3Sources:https://github.com/bitcoin/bitcoin/releaseshttp://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.9.0/https://bitcoin.org/bin/0.9.0/README.txtBitcoin Core version 0.9.0 is now available from:
https://bitcoin.org/bin/0.9.0/
This is a release candidate for a new major version. A major version brings
both new features and bug fixes.
Please report bugs using the issue tracker at github:
https://github.com/bitcoin/bitcoin/issues
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), uninstall all
earlier versions of Bitcoin, 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.0 your blockchain files will be re-indexed, which will take anywhere from
30 minutes to several hours, depending on the speed of your machine.
On Windows, do not forget to uninstall all earlier versions of the Bitcoin
client first, especially if you are switching to the 64-bit version.
Windows 64-bit installer
-------------------------
New in 0.9.0 is the Windows 64-bit version of the client. There have been
frequent reports of users running out of virtual memory on 32-bit systems
during the initial sync. Because of this it is recommended to install the
64-bit version if your system supports it.
NOTE: Release candidate 2 Windows binaries are not code-signed; use PGP
and the SHA256SUMS.asc file to make sure your binaries are correct.
In the final 0.9.0 release, Windows setup.exe binaries will be code-signed.
OSX 10.5 / 32-bit no longer supported
-------------------------------------
0.9.0 drops support for older Macs. The minimum requirements are now:
* A 64-bit-capable CPU (see http://support.apple.com/kb/ht3696);
* Mac OS 10.6 or later (see https://support.apple.com/kb/ht1633).
Downgrading warnings
--------------------
The 'chainstate' for this release is not always compatible with previous
releases, so if you run 0.9 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).
Rebranding to Bitcoin Core
---------------------------
To reduce confusion between Bitcoin-the-network and Bitcoin-the-software we
have renamed the reference client to Bitcoin Core.
Autotools build system
-----------------------
For 0.9.0 we switched to an autotools-based build system instead of individual
(q)makefiles.
Using the standard "./autogen.sh; ./configure; make" to build Bitcoin-Qt and
bitcoind makes it easier for experienced open source developers to contribute
to the project.
Be sure to check doc/build-*.md for your platform before building from source.
Bitcoin-cli
-------------
Another change in the 0.9 release is moving away from the bitcoind executable
functioning both as a server and as a RPC client. The RPC client functionality
("tell the running bitcoin daemon to do THIS") was split into a separate
executable, 'bitcoin-cli'. The RPC client code will eventually be removed from
bitcoind, but will be kept for backwards compatibility for a release or two.
`walletpassphrase` RPC
-----------------------
The behavior of the `walletpassphrase` RPC when the wallet is already unlocked
has changed between 0.8 and 0.9.
The 0.8 behavior of `walletpassphrase` is to fail when the wallet is already unlocked:
> walletpassphrase 1000
walletunlocktime = now + 1000
> walletpassphrase 10
Error: Wallet is already unlocked (old unlock time stays)
The new behavior of `walletpassphrase` is to set a new unlock time overriding
the old one:
> walletpassphrase 1000
walletunlocktime = now + 1000
> walletpassphrase 10
walletunlocktime = now + 10 (overriding the old unlock time)
Transaction malleability-related fixes
--------------------------------------
This release contains a few fixes for transaction ID (TXID) malleability
issues:
- -nospendzeroconfchange command-line option, to avoid spending
zero-confirmation change
- IsStandard() transaction rules tightened to prevent relaying and mining of
mutated transactions
- Additional information in listtransactions/gettransaction output to
report wallet transactions that conflict with each other because
they spend the same outputs.
- Bug fixes to the getbalance/listaccounts RPC commands, which would report
incorrect balances for double-spent (or mutated) transactions.
- New option: -zapwallettxes to rebuild the wallet's transaction information
Transaction Fees
----------------
This release drops the default fee required to relay transactions across the
network and for miners to consider the transaction in their blocks to
0.01mBTC per kilobyte.
Note that getting a transaction relayed across the network does NOT guarantee
that the transaction will be accepted by a miner; by default, miners fill
their blocks with 50 kilobytes of high-priority transactions, and then with
700 kilobytes of the highest-fee-per-kilobyte transactions.
The minimum relay/mining fee-per-kilobyte may be changed with the
minrelaytxfee option. Note that previous releases incorrectly used
the mintxfee setting to determine which low-priority transactions should
be considered for inclusion in blocks.
The wallet code still uses a default fee for low-priority transactions of
0.1mBTC per kilobyte. During periods of heavy transaction volume, even this
fee may not be enough to get transactions confirmed quickly; the mintxfee
option may be used to override the default.
0.9.0 Release notes
=======================
RPC:
- New notion of 'conflicted' transactions, reported as confirmations: -1
- 'listreceivedbyaddress' now provides tx ids
- Add raw transaction hex to 'gettransaction' output
- Updated help and tests for 'getreceivedby(account|address)'
- In 'getblock', accept 2nd 'verbose' parameter, similar to getrawtransaction,
but defaulting to 1 for backward compatibility
- Add 'verifychain', to verify chain database at runtime
- Add 'dumpwallet' and 'importwallet' RPCs
- 'keypoolrefill' gains optional size parameter
- Add 'getbestblockhash', to return tip of best chain
- Add 'chainwork' (the total work done by all blocks since the genesis block)
to 'getblock' output
- Make RPC password resistant to timing attacks
- Clarify help messages and add examples
- Add 'getrawchangeaddress' call for raw transaction change destinations
- Reject insanely high fees by default in 'sendrawtransaction'
- Add RPC call 'decodescript' to decode a hex-encoded transaction script
- Make 'validateaddress' provide redeemScript
- Add 'getnetworkhashps' to get the calculated network hashrate
- New RPC 'ping' command to request ping, new 'pingtime' and 'pingwait' fields
in 'getpeerinfo' output
- Adding new 'addrlocal' field to 'getpeerinfo' output
- Add verbose boolean to 'getrawmempool'
- Add rpc command 'getunconfirmedbalance' to obtain total unconfirmed balance
- Explicitly ensure that wallet is unlocked in `importprivkey`
- Add check for valid keys in `importprivkey`
Command-line options:
- New option: -nospendzeroconfchange to never spend unconfirmed change outputs
- New option: -zapwallettxes to rebuild the wallet's transaction information
- Rename option '-tor' to '-onion' to better reflect what it does
- Add '-disablewallet' mode to let bitcoind run entirely without wallet (when
built with wallet)
- Update default '-rpcsslciphers' to include TLSv1.2
- make '-logtimestamps' default on and rework help-message
- RPC client option: '-rpcwait', to wait for server start
- Remove '-logtodebugger'
- Allow `-noserver` with bitcoind
Block-chain handling and storage:
- Update leveldb to 1.15
- Check for correct genesis (prevent cases where a datadir from the wrong
network is accidentally loaded)
- Allow txindex to be removed and add a reindex dialog
- Log aborted block database rebuilds
- Store orphan blocks in serialized form, to save memory
- Limit the number of orphan blocks in memory to 750
- Fix non-standard disconnected transactions causing mempool orphans
- Add a new checkpoint at block 279,000
Wallet:
- Bug fixes and new regression tests to correctly compute
the balance of wallets containing double-spent (or mutated) transactions
- Store key creation time. Calculate whole-wallet birthday.
- Optimize rescan to skip blocks prior to birthday
- Let user select wallet file with -wallet=foo.dat
- Consider generated coins mature at 101 instead of 120 blocks
- Improve wallet load time
- Don't count txins for priority to encourage sweeping
- Don't create empty transactions when reading a corrupted wallet
- Fix rescan to start from beginning after importprivkey
- Only create signatures with low S values
Mining:
- Increase default -blockmaxsize/prioritysize to 750K/50K
- 'getblocktemplate' does not require a key to create a block template
- Mining code fee policy now matches relay fee policy
Protocol and network:
- Drop the fee required to relay a transaction to 0.01mBTC per kilobyte
- Send tx relay flag with version
- New 'reject' P2P message (BIP 0061, see
https://gist.github.com/gavinandresen/7079034 for draft)
- Dump addresses every 15 minutes instead of 10 seconds
- Relay OP_RETURN data TxOut as standard transaction type
- Remove CENT-output free transaction rule when relaying
- Lower maximum size for free transaction creation
- Send multiple inv messages if mempool.size > MAX_INV_SZ
- Split MIN_PROTO_VERSION into INIT_PROTO_VERSION and MIN_PEER_PROTO_VERSION
- Do not treat fFromMe transaction differently when broadcasting
- Process received messages one at a time without sleeping between messages
- Improve logging of failed connections
- Bump protocol version to 70002
- Add some additional logging to give extra network insight
- Added new DNS seed from bitcoinstats.com
Validation:
- Log reason for non-standard transaction rejection
- Prune provably-unspendable outputs, and adapt consistency check for it.
- Detect any sufficiently long fork and add a warning
- Call the -alertnotify script when we see a long or invalid fork
- Fix multi-block reorg transaction resurrection
- Reject non-canonically-encoded serialization sizes
- Reject dust amounts during validation
- Accept nLockTime transactions that finalize in the next block
Build system:
- Switch to autotools-based build system
- Build without wallet by passing `--disable-wallet` to configure, this
removes the BerkeleyDB dependency
- Upgrade gitian dependencies (libpng, libz, libupnpc, boost, openssl) to more
recent versions
- Windows 64-bit build support
- Solaris compatibility fixes
- Check integrity of gitian input source tarballs
- Enable full GCC Stack-smashing protection for all OSes
GUI:
- Switch to Qt 5.2.0 for Windows build
- Add payment request (BIP 0070) support
- Improve options dialog
- Show transaction fee in new send confirmation dialog
- Add total balance in overview page
- Allow user to choose data directory on first start, when data directory is
missing, or when the -choosedatadir option is passed
- Save and restore window positions
- Add vout index to transaction id in transactions details dialog
- Add network traffic graph in debug window
- Add open URI dialog
- Add Coin Control Features
- Improve receive coins workflow: make the 'Receive' tab into a form to request
payments, and move historical address list functionality to File menu.
- Rebrand to `Bitcoin Core`
- Move initialization/shutdown to a thread. This prevents "Not responding"
messages during startup. Also show a window during shutdown.
- Don't regenerate autostart link on every client startup
- Show and store message of normal bitcoin:URI
- Fix richtext detection hang issue on very old Qt versions
- OS X: Make use of the 10.8+ user notification center to display Growl-like
notifications
- OS X: Added NSHighResolutionCapable flag to Info.plist for better font
rendering on Retina displays.
- OS X: Fix bitcoin-qt startup crash when clicking dock icon
- Linux: Fix Gnome bitcoin: URI handler
Miscellaneous:
- Add Linux script (contrib/qos/tc.sh) to limit outgoing bandwidth
- Add '-regtest' mode, similar to testnet but private with instant block
generation with 'setgenerate' RPC.
- Add 'linearize.py' script to contrib, for creating bootstrap.dat
- Add separate bitcoin-cli client
Credits
--------
Thanks to everyone who contributed to this release:
- Andrey
- Ashley Holman
- b6393ce9-d324-4fe1-996b-acf82dbc3d53
- bitsofproof
- Brandon Dahler
- Calvin Tam
- Christian Decker
- Christian von Roques
- Christopher Latham
- Chuck
- coblee
- constantined
- Cory Fields
- Cozz Lovan
- daniel
- Daniel Larimer
- David Hill
- Dmitry Smirnov
- Drak
- Eric Lombrozo
- fanquake
- fcicq
- Florin
- frewil
- Gavin Andresen
- Gregory Maxwell
- gubatron
- Guillermo Céspedes Tabárez
- Haakon Nilsen
- HaltingState
- Han Lin Yap
- harry
- Ian Kelling
- Jeff Garzik
- Johnathan Corgan
- Jonas Schnelli
- Josh Lehan
- Josh Triplett
- Julian Langschaedel
- Kangmo
- Lake Denman
- Luke Dashjr
- Mark Friedenbach
- Matt Corallo
- Michael Bauer
- Michael Ford
- Michagogo
- Midnight Magic
- Mike Hearn
- Nils Schneider
- Noel Tiernan
- Olivier Langlois
- patrick s
- Patrick Strateman
- paveljanik
- Peter Todd
- phantomcircuit
- phelixbtc
- Philip Kaufmann
- Pieter Wuille
- Rav3nPL
- R E Broadley
- regergregregerrge
- Robert Backhaus
- Roman Mindalev
- Rune K. Svendsen
- Ryan Niebur
- Scott Ellis
- Scott Willeke
- Sergey Kazenyuk
- Shawn Wilkinson
- Sined
- sje
- Subo1978
- super3
- Tamas Blummer
- theuni
- Thomas Holenstein
- Timon Rapp
- Timothy Stranex
- Tom Geller
- Torstein Husebø
- Vaclav Vobornik
- vhf / victor felder
- Vinnie Falco
- Warren Togami
- Wil Bown
- Wladimir J. van der Laan |
|
|
|
Since this story is to important to ignore: http://mag.newsweek.com/2014/03/14/bitcoin-satoshi-nakamoto.html"I am no longer involved in that and I cannot discuss it," he says, dismissing all further queries with a swat of his left hand. "It's been turned over to other people. They are in charge of it now. I no longer have any connection." Related threads: Satoshi Nakamoto found :DWill Satoshi visit us soon?2014-03-06 CNBC - Father of bitcoin living reclusive life in CaliforniaYet another pseudo-Satoshi, or just how derpy is this Gavin character?Nakamoto, Satoshi, New Info, hopes it clears up some stuff.*BREAKING NEWS* 28 year old pic of Satoshi is Revealed! *BREAKING NEWS*So it was not "a group of people"Satoshi looks so Cute[2014-03-06]The Face Behind BitcoinSign the Whitehouse petition! Have Satoshi Nakamoto acknowledged!Quote attributed to Nakamoto in Newsweek article makes no reference to bitcoinIf it was realFrom Genesis Block: 12c6DSiU4Rq3P4ZxziKxzrL5LmMBrzjrJXhypothesis on why I think the real Sotoshi was foundSatoshi Nakamoto Doxxed: Don't Blame The Reporter[2014-03-06] VICE - Has Satoshi Nakamoto Been Unmasked?[2014-03-06] "Let's pretend the government agencies are coming after you"...And Wikipedia declares it is realSatoshi's Daughter Says Her Father Distrusted GovernmentDorian Nakamoto does NOT speak English well and he ain't Satoshi, see article:If you're the real Satoshi Nakamoto, please post a signed message.Gavin regrets after Satoshi revealedPrediction of price due to Satoshi's reveal?If that really is Satoshi, how can we help him?I'm gathering all theories about Satoshi NakamotoNakamoto Found?Satoshi Nakamoto Found, Now what?It's Official - Now STFU (Satoshi Found)The Real Satoshi Nakamoto Found! [PICS]Donation to Satoshi - Collection of train models.What would happen if Satoshi dumped his coins?**Breaking news** Satoshi Nakamotos identity revealedRun Satoshi Run ! What he must do...[2014-03-06] Leah Goodman Claims to Have 'Found' Satoshi Nakamoto***Breaking*** Satoshi Nakamoto gefunden (German) Real "Satoshi Nakamoto" revealed. (India) Satoshi Nakamoto descoperit? (Romanian) [CCN FR] Satoshi Nakamoto aurait été retrouvé par le site Newsweek (French) Extra!!! Acharam o Satoshi Nakamoto na California!!! (Portuguese) SATOSHI NAKAMOTO (Portuguese) Identidad de Satoshi Nakamoto revelada (supuesta mente) (Spanish) Scoperta l'identità di Satoshi Nakamoto (Italian) Satoshi Nakamoto gevonden? (Dutch) İddia: Newsweek'e Göre Satoshi Nakamoto California'da Bulundu (Turkish) |
|
|
|
What is KYC ?Know your customer (KYC) refers to due diligence activities that financial institutions and other regulated companies must perform to ascertain relevant information from their clients for the purpose of doing business with them. The term is also used to refer to the bank regulation which governs these activities. Know Your Customer processes are also employed by companies of all sizes for the purpose of ensuring their proposed agents', consultants' or distributors' anti-bribery compliance. Banks, insurers and export credit agencies are increasingly demanding that customers provide detailed anti-corruption due diligence information, to verify their probity and integrity. Who has to enforce KYC ?Know your customer (KYC) falls under the responsability of each financial institution and/or regulated company. The regulations require these entities to adopt KYC procedures. It assists them in knowing / understanding the customers and their financial dealings better to monitor their transactions for identification and prevention of suspicious transactions. KYC RecommendationsKYC controls typically include the following: - Collection and analysis of basic identity information (referred to in US regulations and practice a "Customer Identification Program" or CIP) - Name matching against lists of known parties (such as "politically exposed person" or PEP) - Determination of the customer's risk in terms of propensity to commit money laundering, terrorist finance, or identity theft - Creation of an expectation of a customer's transactional behavior - Monitoring of a customer's transactions against their expected behaviour and recorded profile as well as that of the customer's peers KYC Jurisdiction and LocalityKYC regulations are local, and differ from country to country. Jurisdiction is also, on a coutry to country basis. To know more about your specific country, visit: http://kycmap.comKYC and Bitcoin ExchangesStricter KYC policies: Bitstamp https://www.bitstamp.net/privacy-policy/Bitfinex https://www.bitfinex.com/pages/tos or refer inquiries to compliance@bitfinex.comBTCChina (only since new PBOC guidance, Dec 2013) (link?) Cavirtex https://www.cavirtex.com/faqCoinbase https://coinbase.com/legal/privacyKraken https://www.kraken.com/legal/verification (their General Counsel, Constance Choi is a well known specialist in the Regulatory and Compliance field) Cryptonit https://cryptonit.net/regulationsLoose or non-existant KYC policies: BTC-e (??) Crypsty (??) LocalBitcoin (p2p based, limited KYC?)
What is AML?Standing for "Anti-money Laundering", it is a set of procedures, laws or regulations designed to stop the practice of generating income through illegal actions. In most cases money launderers hide their actions through a series of steps that make it look like money coming from illegal or unethical sources was earned legitimately. Who has to enforce AML?In response to mounting concern over money laundering, the Financial Action Task Force on Money Laundering (FATF) was established by the G-7 Summit that was held in Paris in 1989. The Task Force was given the responsibility of examining money laundering techniques and trends, reviewing the action which had already been taken at a national or international level, and setting out the measures that still needed to be taken to combat money laundering. In April 1990, less than one year after its creation, the FATF issued a report containing a set of Forty Recommendations, which provide a comprehensive plan of action needed to fight against money laundering. The FATF calls upon all countries to take the necessary steps to bring their national systems for combating money laundering and terrorism financing into compliance with the new FATF Recommendations, and to effectively implement these measures. Again, as in the case of KYC, financial institutions and/or regulated companies are responsible for the implementation of internal AML policies. AML Jurisdiction and LocalityAML regulations are also local, and differ from country to country. Some countries choose a top-down approach, inheriting much of their AML policies from the FATF, while others go for a bottom-up approach and then have to reconcile both policies. Extreme countries where such reconciliation is impossible (generally due to Government unwillingness) are excluded from the FATF membership, with the corollary of increased complications to access the international markets and financing. For a full list of FATF members, visit: http://en.wikipedia.org/wiki/Financial_Action_Task_Force_on_Money_LaunderingAML and Bitcoin ExchangesCurrently in compliance: Bitstamp https://www.bitstamp.net/aml-policy/Bitfinex https://www.bitfinex.com/pages/tos or refer inquiries to compliance@bitfinex.comCavirtex https://www.cavirtex.com/why_virtex#proactively_workingCoinbase https://coinbase.com/legal/privacyKraken https://www.kraken.com/legal/aml (their General Counsel, Constance Choi is a well known specialist in the Regulatory and Compliance field) Cryptonit https://cryptonit.net/regulationsUnknown status: BTCChina (unclear since new PBOC guidance, Dec 2013) (are they financial institutions?) BTC-e https://btc-e.com/page/1LocalBitcoin (p2p based, limited or no AML?)
WARNING:Assume that restrictions for any Bitcoin to National Currency exchange may become more restrictive at any time in the future. Many exchanges in the past have restricted currency deposits or withdrawals proactively as BitStamp has, without any explicit order from a government agency to do so at the time. Others like BTCChina have in response to concerns made even the ability to continue to login to their platform contingent on supplying further identifying information. In the past surprise changes to AML/KYC requirements have lead users of exchanges to have their access to deposited funds substantially delayed while complying with new requirements or even lost access to their deposited funds completely if they could not comply with the new requirements. Changing AML/KYC exchange enacted AML/KYC requirements have affected users of all major exchanges that handle both Bitcoin and National currency. People who continue using such exchanges should prepare for the contingency that their exchange of choice will change their AML/KYC requirements in the future.
|
|
|
|
Bitcoin-Qt version 0.8.6 final is now available from: http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.8.6/This is a maintenance release to fix a critical bug; we urge all users to upgrade.Please report bugs using the issue tracker at github: https://github.com/bitcoin/bitcoin/issuesHow to Upgrade -------------- If you already downloaded 0.8.6rc1 you do not need to re-download. This release is exactly the same. 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.8.6 your blockchain files will be re-indexed, which will take anywhere from 30 minutes to several hours, depending on the speed of your machine. 0.8.6 Release notes =================== - Default block size increase for miners. (see https://gist.github.com/gavinandresen/7670433#086-accept-into-block) - Remove the all-outputs-must-be-greater-than-CENT-to-qualify-as-free rule for relaying (see https://gist.github.com/gavinandresen/7670433#086-relaying) - Lower maximum size for free transaction creation (see https://gist.github.com/gavinandresen/7670433#086-wallet) - OSX block chain database corruption fixes - Update leveldb to 1.13 - Use fcntl with `F_FULLSYNC` instead of fsync on OSX - Use native Darwin memory barriers - Replace use of mmap in leveldb for improved reliability (only on OSX) - Fix nodes forwarding transactions with empty vins and getting banned - Network code performance and robustness improvements - Additional debug.log logging for diagnosis of network problems, log timestamps by default - Fix Bitcoin-Qt startup crash when clicking dock icon on OSX - Fix memory leaks in CKey::SetCompactSignature() and Key::SignCompact() - Fix rare GUI crash on send - Various small GUI, documentation and build fixes Warning ------- - There have been frequent reports of users running out of virtual memory on 32-bit systems during the initial sync. Hence it is recommended to use a 64-bit executable if possible. A 64-bit executable for Windows is planned for 0.9. Note: Gavin Andresen's GPG signing key for SHA256SUMS.asc has been changed from key id 1FC730C1 to sub key 7BF6E212 (see https://github.com/bitcoin/bitcoin.org/pull/279). |
|
|
|
As I said when I stickied the MtGox AML sticky back in June of 2012, I would really like to see a general AML/KYC sticky for the trading discussion board: I suggest getting the mods to sticky this at the top of the forum. The issue comes up repeatedly and this thread will quickly drop off the page if it's not stickied.
I'll sticky it for now, but I'd much rather that there be a more general AML sticky that discusses the issue as well as this one does and then links to company-specific AML information, such as this thread. Since nobody has written such a sticky, I'm now going to put a bounty on it. I will send BTC0.03 to the address of choice for each person that posts text in this thread that I can use to construct this sticky for which I use at least 5 sentences or lines of text in the sticky's creation. Rules: 1) You can only post the text in this thread, please don't make a new thread for it. Once the sticky is created you may use your text as you see fit, regardless of whether or not you win. 2) Since I am paying for the sticky, I will be the one to post it. By posting in this thread, you hereby grant to me and this forum a non-exclusive, worldwide, royalty free, perpetual license to exploit, commercially or otherwise, the text that you submit for this bounty for its business purposes in all media, in whole or in part, distorted in character or form, including but not limited to, the right to use the submitted text on this website, as well as for its internal, trade, and advertising purposes. 3) If I end up using at least 5 sentences or lines of text from your submission, I will send BTC0.03 to the address of your choice. If you modify someone else's existing submission and I use it, both you and they will be paid as long as your change was significant (at least 5 new sentences/lines, or at my discretion). If this chain is too long, I'll probably just accept another submission or an earlier point in the chain and edit it myself, so please don't abuse this. 4) I am not obligated to accept any submission. 5) This bounty closes once I feel that we have something sticky-worthy and I post the new sticky. I look forward to this bounty's results! UPDATE:Thanks to everyone for their contribution! The sticky has now been created. I will leave this open for further edits, but they will be paid at my sole discretion, instead of at a set amount. |
|
|
|
Get excited. Bitcoin Black Friday is finally here! With over 320 deals listed, you're certain to find something you like! Check it out: http://BitcoinBlackFriday.com We like Bitcoin because it’s nearly anonymous peer-to-peer money that can speed up social change through the web. It does three things: free speech is not subject to the wrath of governments, privacy and anonymity is essential to it, and it could cut down on the excesses of the financial industry. Help us show the world that Bitcoin is here to stay. Join our social media Thunderclap to spread the word about Bitcoin Black Friday. So what can you expect on Bitcoin Black Friday? We’ve got deals of up to 75% off listed from awesome online businesses like OK Cupid, Reddit, Namecheap, GSM Nation, CheapAir.com, Humble Bundle, Private Internet Access, PureVPN, and hundreds more. You can literally buy ANYTHING with Bitcoin this year, from organic wine to underwear to smartphones to gift cards to major retailers. The goal of Bitcoin Black Friday was to help push Bitcoin into the mainstream and we’ve already succeeded! Our little community event has been seeing tons of traffic and internet buzz and we’ve already been featured on top news shows with stories in CNBC, CNN Money, MarketWatch, and CNET. It's a very exciting time for Bitcoin. It’s been awesome to have Fight for the Future supporting Bitcoin Black Friday this year, and it’s made all the difference. Make sure to check them out and support their ongoing campaigns for Internet freedom and privacy. We’re super excited about Friday, and very glad to have you participating. Please tell your friends about Bitcoin Black Friday by forwarding this email, and joining the Thunderclap. That’s the easiest way you can help make this a historic year for Bitcoin and defend everyone’s favorite digital currency. Thanks so much! Bitcoin Black Friday team http://BitcoinBlackFriday.com |
|
|
|
On October 3, it was discovered that an attacker inserted some JavaScript into forum pages. The forum was shut down soon afterward so that the issue could be investigated carefully. After investigation, I determined that the attacker most likely had the ability to execute arbitrary PHP code. Therefore, the attacker probably could have accessed personal messages, email addresses, and password hashes, though it is unknown whether he actually did so. Passwords were hashed very strongly. Each password is hashed with 7500 rounds of sha256crypt and a 12-byte random salt (per password). Each password would need to be individually attacked in order to retrieve the password. However, even fairly strong passwords may be crackable after a long period of time, and weak passwords (especially ones composed of only a few dictionary words) may still be cracked quickly, so it is recommended that you change your password here and anywhere else you used the password. The attacker may have modified posts, PMs, signatures, and registered Bitcoin addresses. It isn't practical for me to check all of these things for everyone, so you should double-check your own stuff and report any irregularities to me. How the attack was doneI believe that this is how the attack was done: After the 2011 hack of the forum, the attacker inserted some backdoors. These were removed by Mark Karpelles in his post-hack code audit, but a short time later, the attacker used the password hashes he obtained from the database in order to take control of an admin account and insert the backdoors back in. (There is a flaw in stock SMF allowing you to login as someone using only their password hash. No bruteforcing is required. This was fixed on this forum when the password system was overhauled over a year ago.) The backdoors were in obscure locations, so they weren't noticed until I did a complete code audit yesterday. After I found the backdoors, I saw that someone (presumably the attacker) independently posted about his attack method with matching details. So it seems very likely that this was the attack method. Because the backdoors were first planted in late 2011, the database could have been secretly accessed any time since then. It was initially suspected by many that the attack was done by exploiting a flaw in SMF which allows you to upload any file to the user avatars directory, and then using a misconfiguration in nginx to execute this file as a PHP script. However, this attack method seems impossible if PHP's security.limit_extensions is set. The futureThe forum is now on a new server inside of a virtual machine with many extra security precautions which will hopefully provide some security in depth in case there are more exploits or backdoors. Also, I have disabled much SMF functionality to provide less attack surface. In particular, non-default themes are disabled for now. I'd like to publish the forum's current code so that it can be carefully reviewed and the disabled features can be re-enabled. SMF 1.x's license prohibits publishing the code, though, so I will have to either upgrade to 2.x, get a special copyright exception from SMF, or do the auditing myself. During this investigation, a few security disadvantages to 2.x were brought to my attention, so I don't know whether I want to upgrade if I can help it. (1.x is still supported by SMF.) Special thanks to these people for their assistance in dealing with this issue: - warren - Private Internet Access - nerta - Joshua Rogers - chaoztc - phantomcircuit - jpcaissy - bluepostit - All others who helped -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
As of October 7 2013, the Bitcoin Forum has been restored to bitcointalk.org.
-----BEGIN PGP SIGNATURE-----
iF4EAREIAAYFAlJSRF8ACgkQxlVWk9q1keemWgD/WcvrsikPq6AHpEo20KGmQInp
FlyAWNbX74z65KJrsUEBAIcCzYnHZ7gAs49mlhSq1fR9o2LZCETV3BJveCTu7lAi
=b9Xb
-----END PGP SIGNATURE----- |
|
|
|
Bitcoin-Qt version 0.8.3 is now available from: http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.8.3/This is a maintenance release to fix a denial-of-service attack that can cause nodes to crash. Please report bugs using the issue tracker at github: https://github.com/bitcoin/bitcoin/issues0.8.3 Release notesTruncate over-size messages to prevent a memory exhaustion attack. Fix a regression that causes excessive re-writing of the 'peers.dat' file.
Thanks to Peter Todd for responsibly disclosing the vulnerability ( CVE-2013-4627 ) and creating a fix. |
|
|
|
In light of the ongoing legal attacks against Bitcoin from the US government, I figured I would bring this to everyone's attention: Effective the May 31st, 2013 Tangible Cryptography has suspended new purchases of Bitcoins through our service FastCash4Bitcoins. We take this step in response to a notice received on the same day from the Commonwealth of Virginia that a complaint has been made that our company is operating as an unlicensed money transmitter. The Virginia Corporation Commission did an initial investigation in response to the complaint, and determined that our activity may constitute money transmission under Virginia law. The Commission's initial assessment has factual errors which we intend to address. The notice indicated that it appears that our company is issuing Bitcoins through the use of the website https://fastcash4bitcoins.com , which may constitute "sale of issuance of stored value" under Virginia law. As our clients are well aware this is simply an incorrect assessment of our business activity. The site is used to facilitate the purchase of Bitcoins from clients. Tangible Cryptography is acting as a buyers not issuer of virtual currency. Furthermore there is no obligation for redemption, or holding of customer funds, as would occur in a stored value system. The view that buying, selling, or even issuing new Bitcoins would be seen as stored value is at odds with the guidance from FinCEN earlier this year, that exchangers (and issuers) of virtual currency are not issuers of prepaid access (stored value). The company has been given thirty days to provide written explanation on why our activity is exempt from licensing under current law. The commission has formally stated that unless exempt from licensing we must stop further activity until such time as we apply for and obtain a Money Transmitter license. The prudent action is for the company to suspend all new transactions while we respond to the Commission's notice We want to reassure our valued clients that all completed transactions have been paid. At this time there has been no freeze, hold, or closure of our payment accounts. We are one of the few Bitcoin related enterprises which can definitively say that to date, no client has lost funds as a result of theft, hacking, or fraud through fault or negligence by Tangible Cryptography or the services it provides. The future and direction of Tangible Cryptography will depend on the outcome of our response to the Virginia Corporation Commission. While we hope for a timely resolution we recommend our existing clients make alternative arrangements as it is difficult to provide an estimate on how long such a resolution may take. Staff Tangible Cryptography, LLC |
|
|
|
I recently saw a discussion where this was asked and apparently nobody knew the answer: What about these altcoins makes them worthy of investment? Please, enlighten me. I can crank out several per day.
To start with, how appropriate their title is. I'm asking about inherent value. Vaginacoin is about as inherently valuable as every other release on this forum. Well, after much observation, let me tell you what the answer is. For at least the first year, the most valuable feature of any altcoin is its development team. Most especially, the altcoin's lead developer. This is the only reason why Litecoin is succeeding where other altcoins have failed. Some people think that what you really need is good marketing, but they fail to see that good marketing comes naturally from a strong dev team. I'd be interested to see what everyone's thoughts on this are. |
|
|
|
It didn't work out that way, according to a lawsuit filed today by Coinlab's attorneys in Washington State. Coinlab alleges that Mt. Gox has breached a contract clause which was supposed to give Coinlab exclusive access to the North American market. "Defendants have breached the exclusivity provisions of the Agreement by directly servicing customers in the United States and Canada since the Agreement took effect," the lawsuit states.
Coinlab also says Mt. Gox hasn't allowed them to transition existing U.S. and Canadian customers from Mt. Gox to Coinlab, as agreed in the contract. "Despite repeated requests to do so, Mt. Gox has failed to deliver all passwords, Yubikeys, administrative logins and any other security information required so that CoinLab may assume operation of the Bitcoin exchange services for customers in the United States and Canada."
Coinlab is demanding $75 million in damages, and even that, it says, "likely underestimates the actual damages." http://gawker.com/massive-bitcoin-business-partnership-devolves-into-75-487857656?rev=1367540238This is gonna be interesting given that there are very high profile Bitcoin people on both sides of this lawsuit (Roger Ver is a CoinLab investor). |
|
|
|
|
