BTC GBP – Bitcoin to Pound Price Chart — TradingView — UK

PSA: bfgminer doesn't work with bitcoin classic via GBT

Bfgminer doesn't work "out of the box" with bitcoin classic nodes via GBT. Before you get your pitchforks, its not like Luke-jr snuck some code in recently to cause an incompatibility. He is, however, unwilling to make it work as he doesn't "support altcoins" (even though bfgminer has had support for scrypt ASICs for quite some time). Still waiting for a reply from Luke-jr on whether he will merge support for bitcoin classic if someone else maintains that piece of code. Hopefully he will, as I think it would look bad on classic to have separate mining software. At that point it looks more like an altcoin. I won't speculate as to whether or not this is something Luke-jr would like to achieve.
I'm no developer, but from what I can tell its a problem with block version checks in bfgminer or libblkmaker. Shouldn't be too hard to change.
I also think this ought to get some visibility from people who can actually change the code without breaking it. If any large miner is running miners with bfgminer (or potentially anything based on libblkmaker) and it just immediately doesn't work with bitcoin classic, I doubt they're going to bother to figure this all out themselves. They'll just switch back to Core.
Note that cgminer works fine, (but is unfortunately not stable on my setup). And I was honestly not trolling Luke-jr on this issue. I really would like to be solo mining on a bitcoin classic node.
submitted by Whiteboyfntastic1 to Bitcoin_Classic [link] [comments]

SegWit GBT updates | Luke Dashjr | Jan 30 2016 /r/bitcoin_devlist

SegWit GBT updates | Luke Dashjr | Jan 30 2016 /bitcoin_devlist submitted by BitcoinAllBot to BitcoinAll [link] [comments]

PSA: bfgminer doesn't work with bitcoin classic via GBT /r/Bitcoin_Classic

PSA: bfgminer doesn't work with bitcoin classic via GBT /Bitcoin_Classic submitted by BitcoinAllBot to BitcoinAll [link] [comments]

ProfitCoins.com - Bitcoin mining pool | PPLNS | Stratum | GBT |Auto-Payout

Let us present to you a new pool:
ProfitCoins.com
Special features of our pool: - Fees 0% - Payments to BTC - Auto-payment options - Real-time statistics - transparent dynamic statistics where you can see a number of shares submitted by every user, their awards, times when when users were awarded etc. - Supports Russian and English versions - Efficient and knowledgeable technical support - User-friendly interface - Stratum
Welcome to our pool for joint bitcoin generation!
submitted by ProfitCoins to Bitcoin [link] [comments]

Bitcoin Unlimited - Bitcoin Cash edition 1.5.0.2 has just been released

Download the latest Bitcoin Cash compatible release of Bitcoin Unlimited (1.5.0.2, November 13th, 2018) from:
 
https://www.bitcoinunlimited.info/download
 
This is a minor bugs fix only release version based of Bitcoin Unlimited compatible with the Bitcoin Cash specifications you could find here:
This release also provides an RPC called 'signdata' to generate signatures compatible with the CHECKDATASIG opcode. Like 1.5.0.1 it is compatible with both Bitcoin Cash and SV changes to the consensus rules. SV features set is disabled by default, the default policy is to activate the set of changes as defined by the bitcoincash.org.
List of notable changes and fixes to the code base:
 
Release notes: https://github.com/BitcoinUnlimited/BitcoinUnlimited/blob/dev/doc/release-notes/release-notes-bucash1.5.0.2.md
 
PS:
submitted by s1ckpig to btc [link] [comments]

The Hardfork that Bitcoin REALLY Needs! (Not blocksize related)

We’re all witnessing an extreme amount of new hashing power increasing the difficulty to heights never seen before. This might seem like a good thing, more hashing power securing the Bitcoin network… But wait, have a look at the hashrate distribution: https://www.blocktrail.com/BTC/pools
There are a total of 5 GIANT pools controlling ~82% of the TOTAL hashrate and increasing. I miss the times when people were running ASICs of their own and mining was truly decentralized. Right now, there is an unintentional incentive for miners to centralize. This has to change if Bitcoin is to become the solid foundation securing not only transactions on its own blockchain, but every layer that’s going to be relying on Bitcoin in the future (merged-mined sidechains, DNS-records, smart contracts and paymentchannels etc).
The proposal to eliminate the unintentional incentive to centralize mining is to integrate a P2Pool fashioned mining protocol that would distribute the block reward to both big and small miners giving each their fair share. This solution would benefit EVERYONE in the Bitcoin community EXCEPT for the 5 biggest mining pools as they would have to share some of their reward with smaller miners. This has been thought of as a major roadblock to integrating this change because the biggest miners won’t mine on the new version because it’s giving them less reward.
This topic has been suggested before but it never gained any traction due to the issue raised above. But in fact this is not really an issue. Imagine if the update was rolled with the consensus of the entire community except for the few biggest miners refusing to adopt it and still stubbornly mining on the old version. Their so beloved block reward would be worthless and they’d be forced to update. This is exactly the same reason why miners don’t create more than 25 new bitcoins per block even if they wanted to do so. Because they know that the rest of the Bitcoin community would consider their blocks worthless, that’s why they obey the rules of consensus.
tl;dr
submitted by Kalle303 to Bitcoin [link] [comments]

PSA: Miners SHOULD NOT signal segwit if the community is not in widespread agreement that it is a good idea

Softforks require community support, and miners should evaluate this before signalling activation of them. If the community is significantly divided over whether a softfork should be deployed, miners should not signal support for the softfork until this contention is resolved.
Bitcoin Core and [segwit-capable] derivatives by default will indicate to segwit-enabled miners that they should signal for segwit support, but GBT's versionbits support (see BIP 9) is intentionally designed such that the miner may safely choose to ignore this recommendation and omit the signal - Core does not force anyone to signal segwit. Miners and pools should choose whether to signal for segwit (and other softforks or policy decisions) on their own, and not rely on defaults.
People using stratum mining pools should note that they may not be able to override the pools' decisions. If your pool does not disclose to you whether they signal for a given softfork, or they signal (or don't-signal) for one inappropriately, you should switch to a pool that matches your position.
Note that I am intentionally not saying whether or not segwit actually is controversial here. Personally, I support segwit and think the only rational objection is that the block size limit increase may be unsafe if we cannot trust miners to continue making 1 MB or smaller blocks for the near future. But the community should make their own decision (perhaps post your position here for miners to see), and miners should decide whether or not to signal based on the community's consent.
submitted by luke-jr to Bitcoin [link] [comments]

PSA: Miners SHOULD NOT signal segwit if the community is not in widespread agreement that it is a good idea

Softforks require community support, and miners should evaluate this before signalling activation of them. If the community is significantly divided over whether a softfork should be deployed, miners should not signal support for the softfork until this contention is resolved.
Bitcoin Core and [segwit-capable] derivatives by default will indicate to segwit-enabled miners that they should signal for segwit support, but GBT's versionbits support (see BIP 9) is intentionally designed such that the miner may safely choose to ignore this recommendation and omit the signal - Core does not force anyone to signal segwit. Miners and pools should choose whether to signal for segwit (and other softforks or policy decisions) on their own, and not rely on defaults.
People using stratum mining pools should note that they may not be able to override the pools' decisions. If your pool does not disclose to you whether they signal for a given softfork, or they signal (or don't-signal) for one inappropriately, you should switch to a pool that matches your position.
Note that I am intentionally not saying whether or not segwit actually is controversial here. Personally, I support segwit and think the only rational objection is that the block size limit increase may be unsafe if we cannot trust miners to continue making 1 MB or smaller blocks for the near future. But the community should make their own decision (perhaps post your position here for miners to see), and miners should decide whether or not to signal based on the community's consent.
submitted by luke-jr to btc [link] [comments]

Maxmempooltx settings for XT v.B for the current spam attack.

The random discard of transaction once max transactions is reached looks like it is going to be pertinent soon. The current average spam transaction is ~14,793 bytes. That means the default setting of 50,000 transactions should top out your ram usage at around 740 mb. If this is lower than your node can handle it would be beneficial for you to raise the limit. If it's too high you probably need to adjust it down.
submitted by Not_Pictured to bitcoinxt [link] [comments]

Bitcoin Unlimited - Bitcoin Cash edition 1.5.0.2 has just been released

Download the latest Bitcoin Cash compatible release of Bitcoin Unlimited (1.5.0.2, November 13th, 2018) from:
 
https://www.bitcoinunlimited.info/download
 
This is a minor bugs fix only release version based of Bitcoin Unlimited compatible with the Bitcoin Cash specifications you could find here:
This release also provides an RPC called 'signdata' to generate signatures compatible with the CHECKDATASIG opcode. Like 1.5.0.1 it is compatible with both Bitcoin Cash and SV changes to the consensus rules. SV features set is disabled by default, the default policy is to activate the set of changes as defined by the bitcoincash.org.
List of notable changes and fixes to the code base:
 
Release notes: https://github.com/BitcoinUnlimited/BitcoinUnlimited/blob/dev/doc/release-notes/release-notes-bucash1.5.0.2.md
 
PS:
submitted by s1ckpig to Bitcoincash [link] [comments]

Solution to 51% Crisis: getblocktemplate() ?

I will keep it short:
It seems the solution to our 51% crisis has been already created:
The question is: Why aren't the big pools using it ?
EDIT: Specifically, it does not solve the 51% attack problem. It solves current 51% crisis. It simply does not allow a pool operator to easily execute 51% attack or other similiar attacks.
EDIT2: Actually i might be wrong this time. Feel free to downvote
submitted by ShadowOfHarbringer to Bitcoin [link] [comments]

Bitcoin Unlimited - Bitcoin Cash edition 1.5.0.2 has just been released

Download the latest Bitcoin Cash compatible release of Bitcoin Unlimited (1.5.0.2, November 13th, 2018) from:
 
https://www.bitcoinunlimited.info/download
 
This is a minor bugs fix only release version based of Bitcoin Unlimited compatible with the Bitcoin Cash specifications you could find here:
This release also provides an RPC called 'signdata' to generate signatures compatible with the CHECKDATASIG opcode. Like 1.5.0.1 it is compatible with both Bitcoin Cash and SV changes to the consensus rules. SV features set is disabled by default, the default policy is to activate the set of changes as defined by the bitcoincash.org.
List of notable changes and fixes to the code base:
 
Release notes: https://github.com/BitcoinUnlimited/BitcoinUnlimited/blob/dev/doc/release-notes/release-notes-bucash1.5.0.2.md
 
PS:
submitted by s1ckpig to bitcoin_unlimited [link] [comments]

End of day summary - 01/09

The Dow rose 102.80, or 0.41%, to 25,385.80, the Nasdaq gained 6.19, or 0.09%, to 7,163.58, and the S&P 500 advanced 3.58, or 0.13%, to 2,751.29.
All main stock benchmarks closed at records on Tuesday with the S&P 500 notching six consecutive records to kick off a new year, something it has not done since 1964. Two of the S&P 500's heaviest sectors--health care and financials--led the charge on Tuesday, bouncing back from a disappointing showing on Monday.
The financial sector rallied 0.7% amid a steepening of the yield curve, which translates to an increase in the spread between what lenders charge on loans and what they pay on deposits. The yield on the benchmark 10-yr Treasury note jumped to 2.55% after settling Monday at 2.48% while the 2-yr yield finished flat at 1.96%.
The industrial sector finished just a step below health care and financials at the top of the sector standings with a gain of 0.6%. BA jumped 2.7% to a new record high, helping give the Dow an edge over the S&P 500 and the Nasdaq; Boeing is the priciest, and therefore the most influential, component in the price-weighted Dow.
The consumer discretionary sector (+0.1%) also finished in the green, but the seven remaining groups settled in the red. The top-weighted technology space lost 0.3% with semiconductor giant INTC losing 2.5%. INTC shares extended early losses after MSFT said fixes for Intel chip vulnerabilities--which were reported last week--could significantly slow certain servers and personal computers.
Retailers struggled in general, trimming gains from a two-month run, but TGT had a positive outing after raising its earnings guidance for the fourth quarter. TGT shares added 2.9% while the XRT declined 1.1%.
Among the notable gainers was GBT, which jumped 19% after the company announced that the FDA has granted Breakthrough Therapy Designation to voxelotor for the treatment of sickle cell disease. Also higher was ABAX, which gained 16% after the company reported preliminary results for the third quarter that were better than expected. KODK doubled after boarding the blockchain bandwagon. “We are using Ethereum Smart Contracts, but we’re also developing our own proprietary blockchain and will evaluate the optimal solution during development,” Kodak said in a statement.
Among the noteworthy losers following their pre-announcements of quarterly results were EXPR, which slid 20%, ELF, which fell 11%, and URBN, which dropped 4%.

Currency

The U.S. Dollar Index is up 0.2% at 92.56, returning to levels from the last week of December.

Treasury

The 2s10s spread expanded seven basis points to 59 bps while the 2s30s spread also expanded seven basis points, increasing to 92 bps. This leaves the two spreads at levels from the third week of December.

Commodity

WTI crude futures advanced 1.9% to $62.92 per barrel, closing at a three-year high. The advance came in front of tomorrow morning's weekly crude inventory report from the Energy Information Administration, which has shown a draw in U.S. inventories for seven weeks in a row. The energy sector, which typically moves in tandem with energy prices, lost 0.3%, trimming its 2018 gain to 4.2%.

Crypto

YTD

Summary scrapped from the interweb. Took 1.05 seconds.
submitted by hibernating_brain to thewallstreet [link] [comments]

Making pooled mining immune to 51% attacks, selfish mining, etc. by bundling an SPV client into mining software.

This idea has been floating in my mind for a while, but I haven't seen anyone else mention it. Figured it was worth discussing.

The problem

The threat posed by pools is that they indirectly control large amounts of hashing power. Miners are mining blindly on whatever header the pool gives them, and hence can be made to attack the network at their leisure.

GetBlockTemplate

GetBlockTemplate was supposed to fix this problem by allowing miners to do their own transactions (and making what they're mining completely transparent). This works, but adoption is low for a few reasons:
TLDR: GBT is a great way to neuter the ability of pools to do bad things™, but it isn't widely deployed due to the resource requirements and setup effort of using it properly.
Most/All the big threats posed by a large pool boil down to:
In both cases, the fact that this is occuring is actually detectable regardless of mining protocol (getwork,stratum,GBT), because the parent block hash is part of the header the miner is hashing. So the information you need to know whether you're being used to attack the network has been available all along.

The suggestion

By bundling an SPV client into mining software, all miners can verify that they're building on top of a block that is:
  1. Known to the network (blocking selfish mining).
  2. The tip of the longest chain (blocking orphaning of other blocks/51% attacks).
If this isn't the case, they can switch to their backup pool.

Advantages of the approach:

Disadvantages:

Does this work, or am I missing something obvious?
submitted by ninja_parade to Bitcoin [link] [comments]

Decentralizing mining with pooled-solo mode

submitted by petertodd to Bitcoin [link] [comments]

F2Pool is not properly validating blocks, their fork is winning temporarily. SPV clients and Blockchain.info are inaccurate

https://blockchain.info/block/00000000000000000cb7a20ee4e199e347ad7369936abae53a1518efa531ec61
You'll notice that your up to date full node and other properly run block explorers won't even recognize 00000000000000000cb7a20ee4e199e347ad7369936abae53a1518efa531ec61 since it's an invalid block.
This fork should resolve itself once F2Pools fork loses. All miners using F2Pool should migrate until F2Pool updates.
Edit: Antpool just mined a block on top of that, leave antpool as well https://blockchain.info/block/00000000000000000966d65e0fd87d1d5a8f154a2c955816c28e2006e381aa18
Just to be clear I am not endorsing blockchain.info and am in fact only using their links because they are using an out of date client that considers these blocks valid.
Right now the invalid fork is at 363734, the valid fork is at 363732, they the split starts at 363731 (they both agree on block 363730). In other words the invalid fork is 4 blocks deep, the valid fork is 2. SPV clients may be inaccurate.
Edit 2: invalid fork at 5 blocks deep, valid fork at 2. Fortunately most of these blocks don't have transactions except for 94 in 0000000000000000009cc829aa25b40b2cd4eb83dd498c12ad0d26d90c439d99 (the rest have only the coinbase tx).
Edit 3: Since Antpool + F2Pool + BTCNuggets aren't following the rules and comprise about 40% of the hashrate, until they update you can expect forks like this that will be quite long.
If you're a miner, validate blocks. Not validating blocks is harmful to the network, run a full node and use GBT with a pool providing that option or P2Pool and you won't even have to worry about your hash power contributing to this.
Edit 4: The invalid fork is winning 6-2, anyone who is told by either their SPV client, Blockchain.info or an old Bitcoin client that they have 6 confirmations actually has 0, these 99 transactions are on an invalid blockchain and will be reorged out in a 6 block reorg.
Edit 5: 5-6 now, it's almost over, F2Pool is not mining for now it seems.
Edit 6: Fork is over until it happens again. Mine fully validating!
submitted by 110101002 to Bitcoin [link] [comments]

Forcenet: an experimental network with a new header format | Johnson Lau | Dec 04 2016

Johnson Lau on Dec 04 2016:
Based on Luke Dashjr’s code and BIP: https://github.com/luke-jbips/blob/bip-mmhf/bip-mmhf.mediawiki , I created an experimental network to show how a new header format may be implemented.
Basically, the header hash is calculated in a way that non-upgrading nodes would see it as a block with only the coinbase tx and zero output value. They are effectively broken as they won’t see any transactions confirmed. This allows rewriting most of the rules related to block and transaction validity. Such technique has different names like soft-hardfork, firmfork, evil softfork, and could be itself a controversial topic. However, I’d rather not to focus on its soft-hardfork property, as that would be trivial to turn this into a true hardfork (e.g. setting the sign bit in block nVersion, or setting the most significant bit in the dummy coinbase nLockTime)
Instead of its soft-HF property, I think the more interesting thing is the new header format. The current bitcoin header has only 80 bytes. It provides only 32bits of nonce space and is far not enough for ASICs. It also provides no room for committing to additional data. Therefore, people are forced to put many different data in the coinbase transaction, such as merge-mining commitments, and the segwit commitment. It is not a ideal solution, especially for light wallets.
Following the practice of segwit development of making a experimental network (segnet), I made something similar and call it the Forcenet (as it forces legacy nodes to follow the post-fork chain)
The header of forcenet is mostly described in Luke’s BIP, but I have made some amendments as I implemented it. The format is (size in parentheses; little endian):
Height (4), BIP9 signalling field (4), hardfork signalling field (3), merge-mining hard fork signalling field (1), prev hash (32), timestamp (4), nonce1 (4), nonce2 (4), nonce3 (compactSize + variable), Hash TMR (32), Hash WMR (32), total tx size (8) , total tx weight (8), total sigops (8), number of tx (4), merkle branches leading to header C (compactSize + 32 bit hashes)
In addition to increasing the max block size, I also showed how the calculation and validation of witness commitment may be changed with a new header. For example, since the commitment is no longer in the coinbase tx, we don’t need to use a 0000….0000 hash for the coinbase tx like in BIP141.
Something not yet done:
  1. The new merkle root algorithm described in the MMHF BIP
  2. The nTxsSigops has no meaning currently
  3. Communication with legacy nodes. This version can’t talk to legacy nodes through the P2P network, but theoretically they could be linked up with a bridge node
  4. A new block weight definition to provide incentives for slowing down UTXO growth
  5. Many other interesting hardfork ideas, and softfork ideas that works better with a header redesign
For easier testing, forcenet has the following parameters:
Hardfork at block 200
Segwit is always activated
1 minutes block with 40000 (prefork) and 80000 (postfork) weight limit
50 blocks coinbase maturity
21000 blocks halving
144 blocks retarget
How to join: codes at https://github.com/jl2012/bitcoin/tree/forcenet1 , start with "bitcoind —forcenet" .
Connection: I’m running a node at 8333.info with default port (38901)
Mining: there is only basic internal mining support. Limited GBT support is theoretically possible but needs more hacking. To use the internal miner, writeup a shell script to repeatedly call “bitcoin-cli —forcenet generate 1”
New RPC commands: getlegacyblock and getlegacyblockheader, which generates blocks and headers that are compatible with legacy nodes.
This is largely work-in-progress so expect a reset every couple weeks
jl2012
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 671 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161205/126aae21/attachment.sig
original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-Decembe013338.html
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

I need some help figuring out how to build my watch app

Hello fellow iOS programmers!
I always wanted to learn how to program an app for iOS/watchOS. Two weeks ago I bought the new Apple Watch Series 1 as a way to motivate myself to start building some apps. I want to build a "Stock Ticker" for cryptocurrency. Instead of displaying stock (ex: AAPL, GOOG, GPRO,...), the app would display some cryptocoins (Bitcoin, Ethereum, Litecoin,..). I found an api that monitor the prices of all those coins and return a JSON with all the necessary information. I am currently using Alamofire to get the JSON. I parse it then I load the value in the appropriate place in the UI of the watch. Currently, the HTTP call is done on my watch in the willActivate() function. I also added a refresh button to manually do another HTTP request to get the latest price. The app "technically" works but I know this is far from the correct way to do it. I want to make the price update live automatically at a specified interval. What would be the best way to achieve this without draining the watch and still being efficient? Should the query be done on the watch or the phone? Also I want to cache the latest price so everytime I reload the app, I display the last price while loading the new one. Where should I cache it and what is the best practice
I am currently learning how to program for iOS as I am making the app. I just wanted some insight on what I should learn and how should I build it. I want to make it right :D
Any help is appreciated.
Thanks
P.S. Here is a picture of the current app
submitted by jusleg to iOSProgramming [link] [comments]

F2Pool has enabled full replace-by-fee | Peter Todd | Jun 19 2015

Peter Todd on Jun 19 2015:
Yesterday F2Pool, currently the largest pool with 21% of the hashing
power, enabled full replace-by-fee (RBF) support after discussions with
me. This means that transactions that F2Pool has will be replaced if a
conflicting transaction pays a higher fee. There are no requirements for
the replacement transaction to pay addresses that were paid by the
previous transaction.
I'm a user. What does this mean for me?
In the short term, very little. Wallet software aimed at average users
has no ability to reliably detect conditions where an unconfirmed
transaction may be double-spent by the sender. For example, Schildbach's
Bitcoin Wallet for Android doesn't even detect double-spends of
unconfirmed transactions when connected to a RBF or Bitcoin XT nodes
that propagate them. The least sophisticated double-spend attack
possibly - simply broadcasting two conflicting transactions at the same
time - has about 50% probability of success against these wallets.
Additionally, SPV wallets based on bitcoinj can't even detect invalid
transactions reliably, instead trusting the full node(s) it is connected
too over the unauthenticated, unencrypted, P2P protocol to do validation
for them. For instance due to a unfixed bug¹ Bitcoin XT nodes will relay
double-spends that spend the output of the conflicting transaction. I've
personally tested this with Schildbach's Bitcoin Wallet for Android,
which shows such invalid transactions as standard, unconfirmed,
transactions.
Users should continue to assume that unconfirmed transactions could be
trivially reversed by the sender until the first confirmation. In
general, only the sender can reverse a transaction, so if you do trust
the sender feel free to assume an unconfirmed transaction will
eventually confirm. However, if you do not trust the sender and/or have
no other recourse if they double-spend you, wait until at least the
first confirmation before assuming the transaction will go through.
In the long term, miner support of full RBF has a number of advantages
to users, allowing you to more efficiently make transactions, paying
lower fees. However you'll need a wallet supporting these features; none
exist yet.
I'm a business. What does this mean for me?
If you use your own node to verify transactions, you probably are in a
similar situation as average users, so again, this means very little to
you.
If you use a payment processotransaction API such as BitPay, Coinbase,
BlockCypher, etc. you may or may not be accepting unconfirmed
transactions, and they may or may not be "guaranteed" by your payment
processor even if double-spent. If like most merchants you're using the
API such that confirmations are required prior to accepting orders (e.g.
taking a meaningful loss such as shipping a product if the tx is
reversed) nothing changes for you. If not I recommend you contact your
payment processor.
I'm a miner. Why should I support replace-by-fee?
Whether full or first-seen-safe⁵ RBF support (along with
child-pays-for-parent) is an important step towards a fully functioning
transaction fee market that doesn't lead to users' transactions getting
mysteriously "stuck", particularly during network flooding
events/attacks. A better functioning fee market will help reduce
pressure to increase the blocksize, particularly from the users creating
the most valuable transactions.
Full RBF also helps make use of the limited blockchain space more
efficiently, with up to 90%+ transaction size savings possible in some
transaction patterns. (e.g. long payment chains⁶) More users in less
blockchain space will lead to higher overall fees per block.
Finally as we'll discuss below full RBF prevents a number of serious
threats to the existing level playing field that miners operate in.
Why can't we make accepting unconfirmed txs from untrusted people safe?
For a decentralized wallet, the situation is pretty bleak. These wallets
only have a handful of connections to the network, with no way of
knowing if those connections give an accurate view of what transactions
miners actually know about.
The only serious attempt to fix this problem for decentralized wallets
that has been actually deployed is Andresen/Harding's double-spend
relaying, implemented in Bitcoin XT. It relays up to one double-spend
transaction per double-spent txout, with the intended effect to warn
recipients. In practice however this functionality makes it easier to
double-spend rather than harder, by giving an efficient and easy way to
get double-spends to miners after the fact. Notably my RBF
implementation even connects to Bitcoin XT nodes, reserving a % of all
incoming and outgoing connection slots for them.
Additionally Bitcoin XT's double-spend relaying is subject to attacks
include bandwidth exhaustion, sybil attacks, and Gervais's non-sybil
interactive attacks⁷ among many others.
What about centralised wallets?
Here the solutions being deployed, planned, and proposed are harmful,
and even represent serious threats to Bitcoin's decentralization.
Confidence factors
Many services such as BlockCypher² have attempted to predict the
probability that unconfirmed transactions will be mined, often
guaranteeing merchants payment³ even in the event of a double-spend. The
key component of these predictions is to sybil attack the P2P network as
a whole, connecting to as many nodes as possible to measure transaction
propagation. Additionally these services connect to pools directly via
the getblocktemplate protocol, repeatedly downloading via GBT the lists
of transactions in the to-be-mined blocks to determine what transactions
miners are attempting to mine.
None of these measures scale, wasting significant network and miner
resources; in one instance a sybil attack by Chainalysis even completely
blocked the users of the SPV wallet Breadwallet⁴ from accessing the
network. These measures also don't work very well, giving double-spend
attackers incentives to sybil attack miners themselves.
Transaction processing contracts with miners
The next step after measuring propagation fails is to contract with
miners directly, signing contracts with as much of the hashing power as
possible to get the transactions they want mined and double-spends
rejected. The miners/pools would then provide an authenticated API
endpoint for exclusive use of this service that would allow the service
to add and remove specific transactions to the mempool on demand.
There's a number of serious problems with this:
1) Mining contracts can be used to double-spend
...even when they're being used "honestly".
Suppose Alice is a merchant using CoinPayCypher, who has contracts with
75% of the hashing power. Bob, another merchant, meanwhile uses a
decentralized Bitcoin Core backend for payments to his website.
Mallory wants to double-spend Bob's to buy his expensive products. He
can do this by creating a transaction, tx1, that pays Alice, followed by
a second transaction, tx2, that pays Bob. In any circumstance when
Mallory can convince Bob to accept tx2, but prevent Bob from seeing tx1,
the chance of Malory's double-spend succeeding becomes ~75% because
CoinPayCypher's contracts with mining ensure the transaction paying
Alice will get mined.
Of course, dishonest use and/or compromise makes double-spending
trivial: Malory can use the API credentials to ask miners to reject
Bob's payment at any time.
2) They still don't work, without 51% attacking other miners
Even if CoinPayCypher has 75% of the hashing power on contract, that's
still a potentially 75% chance of being double-spent. The 25% of miners
who haven't signed contracts have no decentralized way of ensuring
they don't create blocks with double-spends, let alone at low cost. If
those miners won't or can't sign contracts with CoinPayCypher the only
next step available is to reject their blocks entirely.
3) Legal contracts give the advantage to non-anonymous miners in
Western jurisdictions
Suppose CoinPayCypher is a US company, and you're a miner with 1%
hashing power located in northern China. The barriers to you succesfully
negotiating a contract with CoinPayCypher are significant. You don't
speak the same langauge, you're in a completely different jurisdiction
so enforcing the legal contract is difficult, and being just 1%,
CoinPayCypher sees you as insignificant.
Who's going to get the profitable hashing power contracts first, if at
all? Your English speaking competitors in the west. This is inherently a
pressure towards centralization of mining.
Why isn't this being announced on the bitcoin-security list first?
I've had repeated discussions with services vulnerable to double-spends;
they have been made well aware of the risk they're taking. If they've
followed my own and others' advice they'll at minimum have constant
monitoring of the rate of double-spends both on their own services and
on the P2P network in general.
If you choose to take a risk you should accept the consequences.
How do I actually use full RBF?
First get the full-RBF patch to v0.10.2:
[https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.10.2](https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.10.2) 
The above implementation of RBF includes additional code to find and
preferentially connect to other RBF nodes, as well as Bitcoin XT nodes.
Secondly, try out my replace-by-fee-tools at:
[https://github.com/petertodd/replace-by-fee-tools](https://github.com/petertodd/replace-by-fee-tools) 
You can watch double-spends on the network here:
[http://respends.thinlink.com/](http://respends.thinlink.com/) 
References
1) "Replace-by-fee v0.10.2 - Serious DoS attack fixed! - Also novel
variants of existing attacks w/ Bitcoin XT and Android Bitcoin Wallet", 
Peter Todd, May 23rd 2015, Bitcoin-development mailing list,
http://www.mail-archive.com/[email protected]/msg07795.html
2) "From Zero to Hero: Bitcoin Transactions in 8 Seconds",
June 2nd, 2014, Erik Voorhees,
https://medium.com/blockcypher-blog/from-zero-to-hero-bitcoin-transactions-in-8-seconds-7c9edcb3b734
3) Coinbase Merchant API, Accessed Jun 19th 2015,
https://developers.coinbase.com/docs/merchants/callbacks#confirmations
4) "Chainalysis CEO Denies 'Sybil Attack' on Bitcoin's Network",
March 14th 2015, Grace Caffyn, Coindesk,
http://www.coindesk.com/chainalysis-ceo-denies-launching-sybil-attack-on-bitcoin-network/
5) "First-Seen-Safe Replace-by-Fee",
May 25th 2015, Peter Todd, Bitcoin-development mailing list,
http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg07829.html
6) "Cost savings by using replace-by-fee, 30-90%",
May 25th 2015, Peter Todd, Bitcoin-development mailing list,
http://www.mail-archive.com/[email protected]/msg07813.html
7) "Tampering with the Delivery of Blocks and Transactions in Bitcoin",
Arthur Gervais and Hubert Ritzdorf and Ghassan O. Karame and Srdjan Capkun, Cryptology ePrint Archive: Report 2015/578, Jun 10th 2015, [http://eprint.iacr.org/2015/578](http://eprint.iacr.org/2015/578) 

'peter'[:-1]@petertodd.org
0000000000000000070a2bb3b92c20d5c2c971e6e1a7abe55cdbbe6a2dd9a5ad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 650 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150619/fa3a7c7a/attachment.sig>
original: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008843.html
submitted by bitcoin-devlist-bot to bitcoin_devlist [link] [comments]

10/11 Wednesday Stock Market Movers & News

Good morning traders of the StockMarket sub! Happy Wednesday to all of you! Here are your pre-market stock market movers & news this morning-

Frontrunning: October 11

STOCK FUTURES NOW:

(CLICK HERE FOR STOCK FUTURES CHARTS!)

YESTERDAY'S MARKET HEAT MAP:

(CLICK HERE FOR YESTERDAY'S MARKET HEAT MAP!)

YESTERDAY'S S&P SECTORS:

(CLICK HERE FOR YESTERDAY'S S&P SECTORS CHART!)

TODAY'S ECONOMIC CALENDAR:

(CLICK HERE FOR TODAY'S ECONOMIC CALENDAR!)

THIS WEEK'S ECONOMIC CALENDAR:

(CLICK HERE FOR THIS WEEK'S ECONOMIC CALENDAR!)

THIS WEEK'S IPO'S:

(CLICK HERE FOR THIS WEEK'S IPO'S!)

THIS WEEK'S EARNINGS CALENDAR:

($BAC $C $JPM $DAL $DPZ $BLK $FAST $WFC $CUDA $OZRK $PNC $LNN $FRC $FHN $JBHT $DFRG $VOXX $SAR $HAWK $EXFO)
(CLICK HERE FOR THIS WEEK'S EARNINGS CALENDAR!)

THIS MORNING'S PRE-MARKET EARNINGS CALENDAR:

NONE.

EARNINGS RELEASES BEFORE THE OPEN TODAY:

(CLICK HERE FOR THIS MORNING'S EARNINGS RELEASES!)

EARNINGS RELEASES AFTER THE CLOSE TODAY:

(CLICK HERE FOR THIS AFTERNOON'S EARNINGS RELEASES!)

THIS MORNING'S ANALYST UPGRADES/DOWNGRADES:

(CLICK HERE FOR THIS MORNING'S UPGRADES/DOWNGRADES!)

THIS MORNING'S INSIDER TRADING FILINGS:

(CLICK HERE FOR THIS MORNING'S INSIDER TRADING FILINGS!)

TODAY'S DIVIDEND CALENDAR:

(CLICK HERE FOR TODAY'S DIVIDEND CALENDAR LINK #1!)
(CLICK HERE FOR TODAY'S DIVIDEND CALENDAR LINK #2!)

THIS MORNING'S MOST ACTIVE TRENDING DISCUSSIONS:

  • HMNY
  • MNKD
  • ACRX
  • DAL
  • SNN
  • INAP
  • DQ
  • BLK
  • MU
  • UNG
  • FAST
  • BIOP
  • UGAZ
  • OZRK
  • RRC
  • PYPL
  • XLP
  • SNAP
  • FB
  • BUD
  • GBT
  • MACK
  • SNE
  • CZR

THIS MORNING'S STOCK NEWS MOVERS:

(source: cnbc.com)
BlackRock – The asset management firm reported adjusted quarterly profit of $5.92 per share, well above the consensus $5.56 a share estimate. Revenue also beat forecasts. BlackRock now has close to $6 trillion under management and CEO Larry Fink told CNBC strength in the global economy is helping spur investor demand.

STOCK SYMBOL: BLK

(CLICK HERE FOR LIVE STOCK QUOTE!)
Delta Air Lines – The airline beat forecasts by four cents a share, with adjusted quarterly profit of $1.57 per share. Revenue was ahead of forecasts, as well. Delta CEO Ed Bastian told CNBC that the airline had a very good quarter, especially considering the impact of the various hurricanes, and that strong demand is overcoming industry pricing pressure for Delta.

STOCK SYMBOL: DAL

(CLICK HERE FOR LIVE STOCK QUOTE!)
FedEx – KeyBanc began coverage of FedEx with an "overweight" rating, saying the delivery company will benefit from improving air freight demand as well as a favorable macroeconomic environment.

STOCK SYMBOL: FDX

(CLICK HERE FOR LIVE STOCK QUOTE!)
American Express – Wells Fargo added American Express to its "priority stock" list, saying the credit card issuer has survived the "perfect storm" of the past few years and is back in a winning position.

STOCK SYMBOL: AXP

(CLICK HERE FOR LIVE STOCK QUOTE!)
General Electric – JPMorgan Chase is calling the early exit of several key executives a negative, and said that it now sees a dividend cut as increasingly likely.

STOCK SYMBOL: GE

(CLICK HERE FOR LIVE STOCK QUOTE!)
Amazon.com – A Morgan Stanley analyst wrote a note saying Amazon's private label business could add $1 billion annually to the bottom line by 2019.

STOCK SYMBOL: AMZN

(CLICK HERE FOR LIVE STOCK QUOTE!)
Alibaba – Alibaba is investing $15 billion in overseas research hubs, unveiling plans to build such facilities in China, Israel, the U.S., Russia, and Singapore.

STOCK SYMBOL: BABA

(CLICK HERE FOR LIVE STOCK QUOTE!)
Molina Healthcare – Molina appointed former Aetna executive Joseph Zubretsky as President and Chief Executive Officer, effective November 6. Chief Financial Officer Joseph White had been serving as interim CEO of the health insurer following the dismissal in May of Mario Molina, as well as CFO John Molina.

STOCK SYMBOL: MOH

(CLICK HERE FOR LIVE STOCK QUOTE!)
Time Inc. – Time is cutting back on both the circulation and frequency of its well-known magazines, including Time, Sports Illustrated, Entertainment Weekly, and Fortune, as part of a cost-cutting and restructuring program.

STOCK SYMBOL: TIME

(CLICK HERE FOR LIVE STOCK QUOTE!)
Equifax – The credit reporting agency's massive data breach compromised driver's license data for about 10.9 million Americans, according to The Wall Street Journal citing people familiar with the matter.

STOCK SYMBOL: EFX

(CLICK HERE FOR LIVE STOCK QUOTE!)
Allergan – The drugmaker's recent patent deal with a Native American tribe is drawing the ire of health insurers, hospitals, and generic drugmakers. A coalition made up of those groups have asked Congress to examine the deal, calling it a brazen attempt to circumvent U.S. law. Allergan had maintained that the move was a way to protect its intellectual property from "unfair challenges."

STOCK SYMBOL: AGN

(CLICK HERE FOR LIVE STOCK QUOTE!)
Symantec – Symantec has stopped letting governments review software source code. CEO Greg Clark told Reuters that allowing such scrutiny compromises the security of the cybersecurity firm's products.

STOCK SYMBOL: SYMC

(CLICK HERE FOR LIVE STOCK QUOTE!)
Micron Technology – Micron shares are under pressure after the chip maker announced plans for a $1 billion secondary stock offering. Micron plans to use the proceeds to pay down its debt.

STOCK SYMBOL: MU

(CLICK HERE FOR LIVE STOCK QUOTE!)
Johnson & Johnson – J&J was upgraded to "buy" from "hold" at Jefferies, citing the company's growth prospects, with the price target for the stock increased to $157 per share from $145.

STOCK SYMBOL: JNJ

(CLICK HERE FOR LIVE STOCK QUOTE!)
Barracuda Networks – Barracuda reported adjusted quarterly profit of 17 cents per share, matching estimates, while the cybersecurity company's revenue exceeded forecasts. Shares are under pressure, however, on lower-than-expected current-quarter earnings and revenue guidance.

STOCK SYMBOL: CUDA

(CLICK HERE FOR LIVE STOCK QUOTE!)

FULL DISCLOSURE:

bigbear0083 has no positions in any stocks mentioned. Reddit, moderators, and the author do not advise making investment decisions based on discussion in these posts. Analysis is not subject to validation and users take action at their own risk.

DISCUSS!

What is on everyone's radar for today's trading day ahead here at StockMarket?

I hope you all have an excellent trading day ahead today on this Wednesday, October the 11th! :)

submitted by bigbear0083 to StockMarket [link] [comments]

Extension block proposal by Jeffrey et al | Luke Dashjr | Apr 04 2017

Luke Dashjr on Apr 04 2017:
Recently there has been some discussion of an apparent work-in-progress
extension block proposal by Christopher Jeffrey, Joseph Poon, Fedor Indutny,
and Steven Pair. Since this hasn't been formally posted on the ML yet, perhaps
it is still in pre-draft stages and not quite ready for review, but in light
of public interest, I think it is appropriate to open it to discussion, and
toward this end, I have reviewed the current revision.
For reference, the WIP proposal itself is here:
https://github.com/tothemoon-org/extension-blocks 
==Overall analysis & comparison==
This is a relatively complicated proposal, creating a lot of additional
technical debt and complexity in comparison to both BIP 141 and hardforks. It
offers no actual benefits beyond BIP 141 or hardforks, so seems irrational to
consider at face value. In fact, it fits much better the inaccurate criticisms
made by segwit detractors against BIP 141.
That being said, this proposal is very interesting in construction and is for
the most part technically sound. While ill-fit to merely making blocks larger,
it may be an ideal fit for fundamentally different block designs such as
Rootstock and MimbleWimble in absence of decentralised non-integrated
sidechains (extension blocks are fundamentally sidechains tied into Bitcoin
directly).
==Fundamental problem==
Extension blocks are a risk of creating two classes of "full nodes": those
which verify the full block (and are therefore truly full nodes), and those
which only verify the "base" block. However, because the extension is
consensus-critical, the latter are in fact not full nodes at all, and are left
insecure like pseudo-SPV (not even real SPV) nodes. This technical nature is
of course true of a softfork as well, but softforks are intentionally designed
such that all nodes are capable of trivially upgrading, and there is no
expectation for anyone to run with pre-softfork rules.
In general, hardforks can provide the same benefits of an extension block, but
without the false expectation and pointless complexity.
==Other problems & questions==
These outpoints may not be spent inside the mempool (they must be redeemed
from the next resolution txid in reality).
This breaks the ability to spend unconfirmed funds in the same block (as is
required for CPFP).
The extension block's transaction count is not cryptographically committed-to
anywhere. (This is an outstanding bug in Bitcoin today, but impractical to
exploit in practice; however, exploiting it in an extension block may not be
as impractical, and it should be fixed given the opportunity.)
The merkle root is to be calculated as a merkle tree with all extension
block txids and wtxids as the leaves.
This needs to elaborate how the merkle tree is constructed. Are all the txids
followed by all the wtxids (tx hashes)? Are they alternated? Are txid and
wtxid trees built independently and merged at the tip?
Output script code aside from witness programs, p2pkh or p2sh is considered
invalid in extension blocks.
Why? This prevents extblock users from sending to bare multisig or other
various possible destinations. (While static address forms do not exist for
other types, they can all be used by the payment protocol.)
Additionally, this forbids datacarrier (OP_RETURN), and forces spam to create
unprovably-unspendable UTXOs. Is that intentional?
The maximum extension size should be intentionally high.
This has the same "attacks can do more damage than ordinary benefit" issue as
BIP141, but even more extreme since it is planned to be used for future size
increases.
Witness key hash v0 shall be worth 1 point, multiplied by a factor of 8.
What is a "point"? What does it mean multiplied by a factor of 8? Why not just
say "8 points"?
Witness script hash v0 shall be worth the number of accurately counted
sigops in the redeem script, multiplied by a factor of 8.
Please define "accurately counted" here. Is this using BIP16 static counting,
or accurately counting sigops during execution?
To reduce the chance of having redeem scripts which simply allow for garbage
data in the witness vector, every 73 bytes in the serialized witness vector is
worth 1 additional point.
Is the size rounded up or down? If down, 72-byte scripts will carry 0
points...)
==Trivial & process==
BIPs must be in MediaWiki format, not Markdown. They should be submitted for
discussion to the bitcoin-dev mailing list, not social media and news.
Layer: Consensus (soft-fork)
Extension blocks are more of a hard-fork IMO.
License: Public Domain
BIPs may not be "public domain" due to non-recognition in some jurisdictions.
Can you agree on one or more of these?
https://github.com/bitcoin/bips/blob/mastebip-0002.mediawiki#Recommended_licenses

Abstract

This specification defines a method of increasing bitcoin transaction
throughput without altering any existing consensus rules.
This is inaccurate. Even softforks alter consensus rules.

Motivation

Bitcoin retargetting ensures that the time in between mined blocks will be
roughly 10 minutes. It is not possible to change this rule. There has been
great debate regarding other ways of increasing transaction throughput, with
no proposed consensus-layer solutions that have proven themselves to be
particularly safe.
Block time seems entirely unrelated to this spec. Motivation is unclear.
Extension blocks leverage several features of BIP141, BIP143, and BIP144 for
transaction opt-in, serialization, verification, and network services, and as
such, extension block activation entails BIP141 activation.
As stated in the next paragraph, the rules in BIP 141 are fundamentally
incompatible with this one, so saying BIP 141 is activated is confusingly
incorrect.
This specification should be considered an extension and modification to
these BIPs. Extension blocks are not compatible with BIP141 in its current
form, and will require a few minor additional rules.
Extension blocks should be compatible with BIP 141, there doesn’t appear to be
any justification for not making them compatible.
This specification prescribes a way of fooling non-upgraded nodes into
believing the existing UTXO set is still behaving as they would expect.
The UTXO set behaves fundamentally different to old nodes with this proposal,
albeit in a mostly compatible manner.
Note that canonical blocks containing entering outputs MUST contain an
extension block commitment (all zeroes if nothing is present in the extension
block).
Please explain why in Rationale.
Coinbase outputs MUST NOT contain witness programs, as they cannot be
sweeped by the resolution transaction due to previously existing consensus
rules.
Seems like an annoying technical debt. I wonder if it can be avoided.
The genesis resolution transaction MAY also include a 1-100 byte pushdata in
the first input script, allowing the miner of the genesis resolution to add a
special message. The pushdata MUST be castable to a true boolean.
Why? Unlike the coinbase, this seems to create additional technical debt with
no apparent purpose. Better to just have a consensus rule every input must be
null.
The resolution transaction's version MUST be set to the uint32 max (`232 -
1`).
Transaction versions are signed, so I assume this is actually simply -1.
(While signed transaction versions seemed silly to me, using it for special
cases like this actually makes sense.)

Exiting the extension block

Should specify that spending such an exit must use the resolution txid, not
the extblock's txid.
On the policy layer, transaction fees may be calculated by transaction cost
as well as additional size/legacy-sigops added to the canonical block due to
entering or exiting outputs.
BIPs should not specify policy at all. Perhaps prefix "For the avoidance of
doubt:" to be clear that miners may perform any fee logic they like.
Transactions within the extended transaction vector MAY include a witness
vector using BIP141 transaction serialization.
Since extblock transactions are all required to be segwit, why wouldn't this
be mandatory?
consensus rule.
Note this makes adoption slower: wallets cannot use the extblock until the
economy has updated to support segwit-native addresses.
To reduce the chance of having redeem scripts which simply allow for garbage
data in the witness vector, every 73 bytes in the serialized witness vector is
worth 1 additional point.
Please explain why 73 bytes in Rationale.
This leaves room for 7 future soft-fork upgrades to relax DoS limits.
How so? Please explain.
A consensus dust threshold is now enforced within the extension block.
Why?
If the second highest transaction version bit (30th bit) is set to to 1
within an extension block transaction, an extra 700-bytes is reserved on the
transaction space used up in the block.
Why wouldn't users set this on all transactions?
default_witness_commitment has been renamed to
default_extension_commitment and includes the extension block commitment
script.
default_witness_commitment was never part of the GBT spec. At least describe
what this new key is.
Should be just extblk if backward compatibility is supported (and !extblk
when not).
The "deactivation" deployment'...[message truncated here by reddit bot]...
original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/013981.html
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

10/11 Wednesday Stock Market Movers & News

Good morning traders of the stocks sub! Happy Wednesday to all of you! Here are your pre-market stock market movers & news this morning-

Frontrunning: October 11

STOCK FUTURES NOW:

(CLICK HERE FOR STOCK FUTURES CHARTS!)

YESTERDAY'S MARKET HEAT MAP:

(CLICK HERE FOR YESTERDAY'S MARKET HEAT MAP!)

YESTERDAY'S S&P SECTORS:

(CLICK HERE FOR YESTERDAY'S S&P SECTORS CHART!)

TODAY'S ECONOMIC CALENDAR:

(CLICK HERE FOR TODAY'S ECONOMIC CALENDAR!)

THIS WEEK'S ECONOMIC CALENDAR:

(CLICK HERE FOR THIS WEEK'S ECONOMIC CALENDAR!)

THIS WEEK'S IPO'S:

(CLICK HERE FOR THIS WEEK'S IPO'S!)

THIS WEEK'S EARNINGS CALENDAR:

($BAC $C $JPM $DAL $DPZ $BLK $FAST $WFC $CUDA $OZRK $PNC $LNN $FRC $FHN $JBHT $DFRG $VOXX $SAR $HAWK $EXFO)
(CLICK HERE FOR THIS WEEK'S EARNINGS CALENDAR!)

THIS MORNING'S PRE-MARKET EARNINGS CALENDAR:

NONE.

EARNINGS RELEASES BEFORE THE OPEN TODAY:

(CLICK HERE FOR THIS MORNING'S EARNINGS RELEASES!)

EARNINGS RELEASES AFTER THE CLOSE TODAY:

(CLICK HERE FOR THIS AFTERNOON'S EARNINGS RELEASES!)

THIS MORNING'S ANALYST UPGRADES/DOWNGRADES:

(CLICK HERE FOR THIS MORNING'S UPGRADES/DOWNGRADES!)

THIS MORNING'S INSIDER TRADING FILINGS:

(CLICK HERE FOR THIS MORNING'S INSIDER TRADING FILINGS!)

TODAY'S DIVIDEND CALENDAR:

(CLICK HERE FOR TODAY'S DIVIDEND CALENDAR LINK #1!)
(CLICK HERE FOR TODAY'S DIVIDEND CALENDAR LINK #2!)

THIS MORNING'S MOST ACTIVE TRENDING DISCUSSIONS:

  • HMNY
  • MNKD
  • ACRX
  • DAL
  • SNN
  • INAP
  • DQ
  • BLK
  • MU
  • UNG
  • FAST
  • BIOP
  • UGAZ
  • OZRK
  • RRC
  • PYPL
  • XLP
  • SNAP
  • FB
  • BUD
  • GBT
  • MACK
  • SNE
  • CZR

THIS MORNING'S STOCK NEWS MOVERS:

(source: cnbc.com)
BlackRock – The asset management firm reported adjusted quarterly profit of $5.92 per share, well above the consensus $5.56 a share estimate. Revenue also beat forecasts. BlackRock now has close to $6 trillion under management and CEO Larry Fink told CNBC strength in the global economy is helping spur investor demand.

STOCK SYMBOL: BLK

(CLICK HERE FOR LIVE STOCK QUOTE!)
Delta Air Lines – The airline beat forecasts by four cents a share, with adjusted quarterly profit of $1.57 per share. Revenue was ahead of forecasts, as well. Delta CEO Ed Bastian told CNBC that the airline had a very good quarter, especially considering the impact of the various hurricanes, and that strong demand is overcoming industry pricing pressure for Delta.

STOCK SYMBOL: DAL

(CLICK HERE FOR LIVE STOCK QUOTE!)
FedEx – KeyBanc began coverage of FedEx with an "overweight" rating, saying the delivery company will benefit from improving air freight demand as well as a favorable macroeconomic environment.

STOCK SYMBOL: FDX

(CLICK HERE FOR LIVE STOCK QUOTE!)
American Express – Wells Fargo added American Express to its "priority stock" list, saying the credit card issuer has survived the "perfect storm" of the past few years and is back in a winning position.

STOCK SYMBOL: AXP

(CLICK HERE FOR LIVE STOCK QUOTE!)
General Electric – JPMorgan Chase is calling the early exit of several key executives a negative, and said that it now sees a dividend cut as increasingly likely.

STOCK SYMBOL: GE

(CLICK HERE FOR LIVE STOCK QUOTE!)
Amazon.com – A Morgan Stanley analyst wrote a note saying Amazon's private label business could add $1 billion annually to the bottom line by 2019.

STOCK SYMBOL: AMZN

(CLICK HERE FOR LIVE STOCK QUOTE!)
Alibaba – Alibaba is investing $15 billion in overseas research hubs, unveiling plans to build such facilities in China, Israel, the U.S., Russia, and Singapore.

STOCK SYMBOL: BABA

(CLICK HERE FOR LIVE STOCK QUOTE!)
Molina Healthcare – Molina appointed former Aetna executive Joseph Zubretsky as President and Chief Executive Officer, effective November 6. Chief Financial Officer Joseph White had been serving as interim CEO of the health insurer following the dismissal in May of Mario Molina, as well as CFO John Molina.

STOCK SYMBOL: MOH

(CLICK HERE FOR LIVE STOCK QUOTE!)
Time Inc. – Time is cutting back on both the circulation and frequency of its well-known magazines, including Time, Sports Illustrated, Entertainment Weekly, and Fortune, as part of a cost-cutting and restructuring program.

STOCK SYMBOL: TIME

(CLICK HERE FOR LIVE STOCK QUOTE!)
Equifax – The credit reporting agency's massive data breach compromised driver's license data for about 10.9 million Americans, according to The Wall Street Journal citing people familiar with the matter.

STOCK SYMBOL: EFX

(CLICK HERE FOR LIVE STOCK QUOTE!)
Allergan – The drugmaker's recent patent deal with a Native American tribe is drawing the ire of health insurers, hospitals, and generic drugmakers. A coalition made up of those groups have asked Congress to examine the deal, calling it a brazen attempt to circumvent U.S. law. Allergan had maintained that the move was a way to protect its intellectual property from "unfair challenges."

STOCK SYMBOL: AGN

(CLICK HERE FOR LIVE STOCK QUOTE!)
Symantec – Symantec has stopped letting governments review software source code. CEO Greg Clark told Reuters that allowing such scrutiny compromises the security of the cybersecurity firm's products.

STOCK SYMBOL: SYMC

(CLICK HERE FOR LIVE STOCK QUOTE!)
Micron Technology – Micron shares are under pressure after the chip maker announced plans for a $1 billion secondary stock offering. Micron plans to use the proceeds to pay down its debt.

STOCK SYMBOL: MU

(CLICK HERE FOR LIVE STOCK QUOTE!)
Johnson & Johnson – J&J was upgraded to "buy" from "hold" at Jefferies, citing the company's growth prospects, with the price target for the stock increased to $157 per share from $145.

STOCK SYMBOL: JNJ

(CLICK HERE FOR LIVE STOCK QUOTE!)
Barracuda Networks – Barracuda reported adjusted quarterly profit of 17 cents per share, matching estimates, while the cybersecurity company's revenue exceeded forecasts. Shares are under pressure, however, on lower-than-expected current-quarter earnings and revenue guidance.

STOCK SYMBOL: CUDA

(CLICK HERE FOR LIVE STOCK QUOTE!)

FULL DISCLOSURE:

bigbear0083 has no positions in any stocks mentioned. Reddit, moderators, and the author do not advise making investment decisions based on discussion in these posts. Analysis is not subject to validation and users take action at their own risk.

DISCUSS!

What is on everyone's radar for today's trading day ahead here at stocks?

I hope you all have an excellent trading day ahead today on this Wednesday, October the 11th! :)

submitted by bigbear0083 to stocks [link] [comments]

How To Buy Cryptocurrencies In EUROPE With EUR, CHF, GBP Day Trading My Watchlist Analysis Britissh Pound GBP/USD Long Target 1.28000/1.32123 Goosebet GBT Tokens MiningStakingEnglish Birchwood Viceroy 33 - GBP 39,950 Are you ready? If you miss Day 1 of this Dapp, you will be disappointed!

easteregg69: 3x pricetag on.. easteregg69: Sell at D0.2299737. MASUDQUIT: yoda pump. easteregg69: 400+ HEX for rewards since yesterday..Checking honeyposts. easteregg69: Honeypots*. easteregg69: Get in to some contracts.. K9crypts: I had profits 3200btc in yobit within 5 years. easteregg69: K9crypts, Early adopter.Grand old man. tablepiece: K9crypts, i lost 3200 btc Bitcoin ATMs are also expanding in the United Kingdom and are a convenient way to purchase BTC. In London alone, there are around 167 Bitcoin ATMs in and around the city. However, it is much preferred you use Coinbase UK or another exchange considering that ATMs tend to have much higher fees. Good day, GBT communities. The front of Bitcoin address starts with 1,3(Mainnet)/ m,n(testnet) and a bitcoin address is an identifier of 26–35 alphanumeric characters, beginning with the GBT believes that this transformation will enable blockchain to increase its adoption in mainstream financial products, and also provide accountable data transfer, audit, and storage. With the aim of completely reforming the blockchain sector, Pablo commented that GBT was eager to start incorporating Gopher’s tech into its systems and products. The world’s first cryptocurrency, Bitcoin is stored and exchanged securely on the internet through a digital ledger known as a blockchain. Bitcoins are divisible into smaller units known as satoshis — each satoshi is worth 0.00000001 bitcoin.

[index] [18845] [22896] [22055] [12703] [3702] [9355] [16153] [29901] [6841] [8587]

How To Buy Cryptocurrencies In EUROPE With EUR, CHF, GBP

This quick tutorial shows you how to convert your bitcoin into GBP in the coinbase back office and then to withdraw that money to your bank account. If you don't yet have a coinbase account, you ... Day Trading Feelings Don't have them! Really though leave your feelings about the Stock Market, the economy and all that at the door we got no room for them around here! We find ourselves saying ... Guys, This video is about Goosebet and how profitable mining in Goosebet platform is currently and you get nice benifits just being on this platform in terms of BTC, ETH, TRX and USDT on daily ... Banking on Bitcoin YouTube Movies. 2017 · Documentary; 1:23:41. DIY Garage Shelves / Shelf / Workbench / Storage / industrial - Duration: 23:36. Wood Nerds Recommended for you. 23:36. Sign in to like videos, comment, and subscribe. Sign in. Watch later

Flag Counter