Bitcoin Forum
March 19, 2024, 04:03:52 AM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 2 [3] 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 ... 71 »
41  Bitcoin / Meetups / Re: Edmonton Meet-Up: Thursday, July 25 on: January 16, 2015, 04:58:01 AM
It took me an embarrassing number of refreshes of http://www.meetup.com/BEMU-Bitcoin-Edmonton-Meet-Up/ to realize that the November Meet-up was not going to happen due to this post:
BEMU moving to G+ and Facebook!

Fortunately, it looks like somebody wants to try to start the group up again (missed event by 2 days):
1st 2015 MeetUp & Idea Pitch
42  Economy / Speculation / Re: Taking a loan to buy bitcoin on: January 16, 2015, 04:42:15 AM
I am considering a loan myself: but not until I have the cash-flow to avoid being forced to sell early.

Essentially, you should be able to comfortably service the debt for a year or more as the price of Bitcoin goes through it's usual roller-coaster. That implies you should avoid loans that require you to sell if the price of Bitcoin drops too much as well.


I was dumb and did not follow my advice: Bought at a "low" of $400 in November (before having enough income to choose when to sell)

I'm very new to bitcoin and read in this thread about a crash that BTC went through. What happened at the last crash of BTC? Did it go down very fast, too fast to respond if I need at least half a day to respond?

Say BTC indeed does go belly up, would you still have time to take your losses (sell at too low price) or is there a chance it would drop to zero all at once?
The bulk of the last crash happened within about 2 hours. After about a day, the price did drop in half again, but there is no guarantee that would happen every time.

For Bitcoin to go to zero, something drastic would have to have happened. I missed a $150-$300 buy window because I did not want to take a loan. I don't think the Price will drop below $300, but I don't know where the real "floor" price is.

Looks like I was wrong about the $300 price floor. I did the math, and can't get money to the exchange until the 27th (5 business day hold at bank + 2 business day transfer to exchange, including 2 weekends).

Kinda want to double-down so my average price is around $300. I have no idea if Bitcoin is going to be worth more or less than $250 in 12 days.
43  Bitcoin / Pools / Re: [3500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool on: January 16, 2015, 03:53:37 AM
....(memory usage went up too from 500MB+ to 1500MB+)...

Seriously!? 3 x more memory?

When I played with pypy, I got similar results. I concluded the initial efficiency was simply the number of peers going down.

The system python libraries appeared to be c-optimized though. If the libraries are not compiled, you may see more improvement.
44  Bitcoin / Bitcoin Discussion / Re: It's about time to turn off PoW mining on: January 16, 2015, 03:29:15 AM
I use PoW mining to warm my house.

Then you only mine in winter? good luck with ROI on your hardware.
it would be possible to mine with generally obsolete hardware that is very cheap that double as both a space heater and a miner.

It would also be possible that he lives in a very cold part of the world where it is close year round so he would not need to turn off his miners in the "summer"

I live 55° North. Electric heat is not used much due to the cost. Mostly natural gas is used (which has lower transmission losses).

I also figured out that even space-heaters should be within one generation or so. That way you get more hashing/watt.

Edit: That said, I did spin up an 80-100W "space heater" when it got cold. I earned like $1 worth of Freicoin while using only about $10 worth of electricity ("free" power, but don't want to abuse it).
45  Bitcoin / Bitcoin Discussion / Re: Welcome new Early Adopters on: January 16, 2015, 02:51:00 AM
Looks like people are going to figure out the bottom is in before I get my money to the exchange on the 27th (5 business day hold at the bank+ 2 business days to get stuff over to the exchange).
46  Bitcoin / Bitcoin Discussion / Re: Decentrally mined currency has failed so far on: December 01, 2014, 08:52:13 PM
You apparently don't understand how mining shares work? The hasher sends the share no matter how much below the required share difficulty, thus if low enough it is a block solution. The Secret only obfuscates (from the hasher's view) how far below the target difficulty the share is, but it doesn't change the fact that all the difficulty remains on the miners who are sending shares.

The secret doesn't partition the probability space.
OK, I was misunderstanding that algorithm I was under the impression that the secrethash was calculated first (Extrahash is calculated first).

I bolded your misunderstanding. To be fair, it is also present in the paper referenced. Miners do not submit low difficulty shares because at modern hash-rates, each miner would be getting (using the Bitmain  453GH/s S3 as an example): about 106 shares/second. This uses a lot of bandwidth, while possibly loading the CPU of a busy pool.

Quote from: Meni RosenFeld
  • Every block will have 3 additional field associated with it – SecretSeed, ExtraHash and
SecretHash.
  • ExtraHash must be the hash of SecretSeed.
  • ExtraHash will be a part of the block header and will be one of the fields used in the
calculation of the block hash.
  • SecretHash must be the hash of the concatenation of the block hash and SecretSeed
  • For the block to be valid: Instead of requiring that the block hash is less than
2 256 /(2 32 D), it is required that the block hash is less than 2 256 /2 32 and that SecretHash
is less than 2 256 /D.
[/list]
The pool operator will choose SecretSeed and keep it secret. He will calculate ExtraHash and
provide it to miners along with the other fields that go into the block hash. The miners can
calculate the block hash and see if it is less than 2 256 /2 32 (which happens with probability
2 −32 ) and in this case submit it as a share. They do not know if this is a valid block
because they don’t know SecretSeed and cannot calculate SecretHash. The operator knows
SecretSeed, calculates SecretHash, and if it is less than 2 256 /D (with probability p) this is a
valid block and it is broadcast to the network.

It is not clear to me that the submitted share difficulty can be effectively adjusted.
On second thought, I am having my doubts this algorithm can find high-difficulty shares without 2^32 times the hash-power. (But Because my SINAD ratio is so low today, maybe I am just too tired to see it.)
Edit: I think it is UnunoctiumTesticles that does not understand PoW. The above algorithm appears to move the job of finding a low enough high-difficulty hash (SecretHash) from the hashers with specialized hardware to the Pool operator's CPU. Specialized hardware does not help as the network would be the bottle-neck.

Edit2: The Pool operator can use specialized hardware by treating the Secret seed (never disclosed) as a nonce. This implies that P2Pool can make use of the algorithm as well (by having each node make up their own secret). I think UnunoctiumTesticles said something about how unnecessary complexity should be avoided though. Nevemind, ExtraHash fixes the seed.
47  Bitcoin / Bitcoin Discussion / Re: Decentrally mined currency has failed so far on: December 01, 2014, 07:57:29 PM
It took so long to get back to this.

The SecretSeed does not depend on the contents of the block[1]. Thus I don't see how it is incompatible with any modifications to the contents of the block.

[1] http://arxiv.org/pdf/1112.4980.pdf#page=29

I missed the fundamental issue here: Update: Apparently Did not read the algorithm carefully enough.
Quote from: Meni RosenFeld
For the block to be valid: Instead of requiring that the block hash is less than
2 256 /(2 32 D), it is required that the block hash is less than 2 256 /2 32 and that SecretHash
is less than 2 256 /D.

The Secret, which the hasher knows nothing about has the high-difficulty hash. The block contents, which is what we are trying to protect with PoW, have the low-difficulty hash.

The proposal not only lets the mining pool ignore any hasher suggestions via getblocktemplate; but also allows a well-funded (or even a not-so-well-funded one) adversary attack the network at will with low-difficulty blocks. That is, unless the "SecretHash" is mandatory for all blocks. Edit: I see, low-diff blocks are not allowed unless you have a high-diff secret hash.

Edit2: since I forgot my reasoning within 2 mins, I should expand on this. Because the secret becomes known once the block is published, taking that secret and bundling it into a new attack block is possible. The only way to avoid this to for the SecretHash to include a hash of the block contents and previous block header. This still opens the block-header to manipulation, which has implications for merged-mining and the like.

BTW, I was aware of what the Sybil attack was. As far as I know, there is no general way for P2P software to avoid it.
48  Economy / Speculation / Re: NEW ATH BY END OF JULY & $5000 PER BITCOIN BY END OF YEAR on: December 01, 2014, 05:49:45 PM
I bot 500 dolars of bitcoin on circle.com with moms credit card. Super excited but hop she dont notise or im screved.

This post is so wrong that it is good
  • Taking out a loan to buy Bitcoin
  • Transaction is unauthorized, so will likely be charged back
  • Teen girl persona?

49  Bitcoin / Bitcoin Discussion / Re: Decentrally mined currency has failed so far on: December 01, 2014, 04:57:55 PM

In the Pool analysis paper (section 6.2.3), they don't go into specific math. They don't have to: the operation of hash functions are well-known to computer scientists.

I already replied on this. They do go into the specific math about SecretSeed is < 2^256/D.
No, it is the SecretHash that is required to be < 2^256/D

Quote
Your distrust of I2P seems to boil down to op-sec. That is, you don't trust I2P even if it works as advertised, because to err is human.

No I gave specific issues. You can't relabel those issues as op-sec and be credible.
You:
  • Complained you could not find the documentation
  • Pointed out that Sybils may not honour the requested delay (duh)
  • said "Also I don't trust I2P because it is operating at a very low-level in the network protocol stack, so I don't know how to characterize all potential de-anonymization correlations that can occur higher up the protocol stack."

On the last point, I decided it was complete bull-crap and tried to discern what you actually meant.
It is not job of a low-level protocol to deal with application-level details. Obviously I2P applications should avoid making it easy to "contaminate" your multiple identities.

Quote
I am starting to suspect the OP's goal is to spread FUD. ... However he comes across as a government (or bank) agent with a goal of disrupting any organized resistance.

On what basis? I speak facts. Where is the FUD?

You claim to be knowledgeable in computer science, but appear to miss how hash functions work. This suggests to me that your Computer Science background may be made-up to better fit-in with the community.

You appear to directly conflate tor vulnerabilities with I2P vulnerabilities, even though they are different mixnets with sightly different designs. This suggests you want to subtly encourage people not use such mixnets: because they are not anonymous anyway.

Now, nobody is perfect. Both those points can be explained away simply by saying you missed something. However, you have an arrogant attitude; explicitly claiming that you are smarter than everyone else.
50  Other / Archival / Re: Pictures of your mining rigs! on: December 01, 2014, 04:28:33 PM
Why not use a RasPi? Can run 24/7 on less power and uses UTP/Linux...

My actual rig is is written up here. Though the blade has been replaced by 2 rockminers. Those rockminers have been sitting idle for 4 months Tongue

TL;DR: The RasPi has only 256MB or RAM. That is not really enough to run a full Bitcoin/P2Pool/namecoin node. Together those use at least 1.2GB of RAM on my machine. I am also not sure of the CPU capabilities of the RasPi. Lately P2Pool has been using 40% of one core. I am interested in replacing that machine with something a little less power-hungry though.

I am also going to need moar disk-space soon too. I have only 10GiB left on a 50GiB partition (left 4GiB for swap, 4GiB slack (because: SSD is "not for server use"))
51  Bitcoin / Bitcoin Discussion / Re: Decentrally mined currency has failed so far on: December 01, 2014, 03:58:35 PM
Oblivious shares mean that the block contents are not disclosed to the hasher. The hasher may be working on a malicious branch of the chain without even knowing about it. They may even be crushing start-up alt-coins, or embeding prayers in the block-chain.

I believe oblivious shares can be implemented using a public hash of the block data. The secret can be independent of the compilation of the contents of the block.

As I understand it, the secret can be an arbitrary length: that is the whole point of a hash function.
With oblivious shares, block manipulations possible with getblocktemplate are impossible: since a hashed header implies a read-only block.

Wait I will dig up the math to be sure. I will go eat first outside, reply when I return.

In the Pool analysis paper (section 6.2.3), they don't go into specific math. They don't have to: the operation of hash functions are well-known to computer scientists.

Your distrust of I2P seems to boil down to op-sec. That is, you don't trust I2P even if it works as advertised, because to err is human.

I am starting to suspect the OP's goal is to spread FUD. Maybe he genuinely is scared of the way the world is going (I think we all are). However he comes across as a government (or bank) agent with a goal of disrupting any organized resistance.
 


52  Bitcoin / Bitcoin Discussion / Re: Decentrally mined currency has failed so far on: December 01, 2014, 06:45:54 AM
Oblivious shares mean that the block contents are not disclosed to the hasher. The hasher may be working on a malicious branch of the chain without even knowing about it. They may even be crushing start-up alt-coins, or embeding prayers in the block-chain.

I believe oblivious shares can be implemented using a public hash of the block data. The secret can be independent of the compilation of the contents of the block.

As I understand it, the secret can be an arbitrary length: that is the whole point of a hash function.
With oblivious shares, block manipulations possible with getblocktemplate are impossible: since a hashed header implies a read-only block.
53  Bitcoin / Bitcoin Discussion / Re: Decentrally mined currency has failed so far on: December 01, 2014, 06:23:22 AM
Oblivious shares mean that the block contents are not disclosed to the hasher. The hasher may be working on a malicious branch of the chain without even knowing about it. They may even be crushing start-up alt-coins, or embeding prayers in the block-chain.
54  Bitcoin / Bitcoin Discussion / Re: Decentrally mined currency has failed so far on: December 01, 2014, 06:07:10 AM
None of that applies to the logic of P2Pool though, because even on the feeble fork, it will be more profitable to mine on a regular pool that can't be subject to mining share withholding (assuming the Rosenfeld oblivious shares fix is implemented).

The eligius pool has been going in the opposite direction.

They encourage miners to build their own blocks using the getblocktemplate protocol.

I am not sure I would trust a pool that makes it impossible to verify they are not attacking the network.
55  Bitcoin / Bitcoin Discussion / Re: Decentrally mined currency has failed so far on: December 01, 2014, 05:47:56 AM
Your logic is incorrect on P2Pool because miners will move to a pool that has less leakage of profits.

You were claiming that "regulated" pools would take-over. Such pools would cause profit leakage by black-listing addresses: hurting the fungibility of Bitcoin. Taking a 50% hit on profit may be worth it if it means that Bitcoin remains viable.

Edit:
I2P may or may not have some random delay at the node, I've never found a specification for I2P, nor is there is abundant research on I2P. Thus I can't trust what I can't know.

Do your distrust the things labeled "specification" in this page for some reason?
56  Other / Archival / Re: Pictures of your mining rigs! on: December 01, 2014, 05:42:23 AM
By the way, your laptop is probably going to die like my did. I had to reflash (oven)  my motherboard more than few occasions but finally it gave away. HP made defective design in which the heatsink wasn't able to dissipate heat efficiently.

The documentation for one of my sister's (Toshiba) laptops actually said: "Do not run for more than 30 hours at a time."
57  Bitcoin / Bitcoin Discussion / Re: Decentrally mined currency has failed so far on: December 01, 2014, 05:24:40 AM
Why do you claim that I2P is only a low-latency mix-net?

i2pbote supports randomized message delays.
Quote from: The Tin Hat
But operating over I2P can be thought of as a back-up or fail-safe for I2P-Bote, as it has another trick up its sleeve. I2P-Bote includes a system where-in the user can select a number of nodes through which the messages will be bounced around before going to the distributed hash table to be stored (more on that later). But this alone isn't much different from how I2P works in the first place, therefore I2P-Bote also integrates a delay between each node as the message is bounced around. This delay can be set to a random interval within a range (for example, a random amount of time between 1-60 minutes per bounce). Thus, not only are the emails bounced around between nodes, but the time that the email itself was sent is obfuscated by a randomized delay. This makes it possible to send a message, log off, and have it arrive some time later without any correlation between the time that you were logged onto I2P and the time the message arrived. The combination of the I2P network protocol and the way in which I2P-Bote routes messages provides a robust and redundant anonymization strategy.
...
So far we've established how secure I2P-Bote is due to its default use of end-to-end encryption, and how much anonymity it can provide through its use of relay nodes on top of the I2P network, but the last great feature of I2P-Bote is its resilience. Standard email services are centralized. When a three-letter agency decides to attack one of them (Lavabit) it usually succeeds, causing users to lose their email service, lose access to their previous emails, and have the privacy of those emails compromised. This isn't a problem with I2P-Bote. As mentioned previously, I2P-Bote is decentralized and stores messages in a Distributed Hash Table (DHT). In simple english, this basically means that messages are stored in a database that is spread across I2P-Bote users, making it so that there is no clear target for attack. The messages remain in this hash table for 100 days, during which the recipient is able to download them. The added benefit of storing the messages throughout the network is that it obfuscates your use of I2P-Bote. For example, by relaying, storing, and serving messages, an attacker who is watching your internet connection isn't able to know when you're actually sending a message rather than just contributing to the network.

BTW, the block withholding attack shows up as bad pool luck. As long as honest hash-power out-performs the with-holders, P2Pool can still be useable if you can find a fat enough pipe.

Edit: The delay option is mentioned in the "Future Work" section here.
Quote from: getI2p.net
The Garlic Message mechanism is very flexible and provides a structure for implementing many types of mixnet delivery methods. Together with the unused delay option in the tunnel message Delivery Instructions, a wide spectrum of batching, delay, mixing, and routing strategies are possible.

58  Other / Off-topic / Re: Anonymity: Death of the Stateless Web on: November 28, 2014, 08:48:09 PM
Apparently the Android permissions prompt is optional or something.

Uber's Android App Caught Reporting Data Back Without Permission

59  Bitcoin / Pools / Re: [3500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool on: November 28, 2014, 08:36:30 PM
P2Pool looks busy lately. I noticed the P2Pool stale rate is now at 20%
Code:
2014-11-28 13:29:18.898450 P2Pool: 17324 shares in chain (17328 verified/17328 total) Peers: 22 (16 incoming)
2014-11-28 13:29:18.898605  Local: 0H/s in last 0.0 seconds Local dead on arrival: ??? Expected time to share: ???
2014-11-28 13:29:18.898680  Shares: 0 (0 orphan, 0 dead) Stale rate: ??? Efficiency: ??? Current payout: 0.0000 BTC
2014-11-28 13:29:18.898768  Pool: 2548TH/s Stale rate: 21.6% Expected time to block: 18.9 hours
Nothing to panic about, as with a 30 second share chain interval, that works out to a block propagation lag of only 6 seconds.

My node is using ~40% of one CPU core for P2Pool at the moment (need a new machine with moar CPU and disk space).
60  Alternate cryptocurrencies / Altcoin Discussion / Re: PoS is far inferior to PoW - why are so many people advocating switching to PoS on: November 22, 2014, 07:09:10 PM
I came across a proposal that will introduce Proof-of-Stake to Bitcoin as a non-forking change. (From the coinjoin thread):
Darkwallet's coinjoin works with two parties. One party will wait around with bitcoins they wish to mix. Another party will connect with them whenever they want to do a transactions and the two parties will do a coinjoin. By analogy with exchange matching engines, I will call the first party the coinjoin maker and the second the coinjoin taker.

The idea is that there will be people acting as makers who will slowly mix their coins for the benefit of the takers who want to immediately mix.
...

Proposal: Pay the coinjoin makers. They will put up offers to do coinjoin along with a fee they ask. The coinjoin transaction would be built up in a similar way to the above example, with the coinjoin maker fee being added to the associated change address and taken away from the coinjoin taker's change address.

An implication of this is that darkwallet coinjoin mixing will become like an almost-riskless savings account. We already see that holders of bitcoin are willing to earn just 0.006% per day by lending btc on the bitfinex exchange, and that contains a substantial risk that bitfinex will go disappear or be hacked taking all the bitcoins with it.

So, Bitcoin can benefit from using PoS for coin-mixing. The fear is that without payment, there may be few people outside of 3 and 4 letter agencies willing to risk "tainting" their coins and ending up on a black-list.
 
Edit: That in itself is not really PoS. Where PoS comes in is where you only mix with coins of a certain age to prevent limit  sibyl attacks.
Pages: « 1 2 [3] 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 ... 71 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!