Bitcoin Forum
July 07, 2024, 10:15:46 PM *
News: Latest Bitcoin Core release: 27.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 »
101  Alternate cryptocurrencies / Speculation (Altcoins) / Re: The market is moving up on: August 01, 2018, 03:08:07 PM
this is great news that bitcoin is growing in price, though it has come down today. But the growth will be
102  Alternate cryptocurrencies / Altcoin Discussion / Re: If bitcoin does not survive... on: July 31, 2018, 03:37:44 PM
Don't worry, bitcoin will live
103  Bitcoin / Mining support / Re: Electric Wiring for Multiple Miners from 220V on: November 25, 2017, 12:07:31 AM
Use a dual 6-20p outlet:

https://www.amazon.com/Leviton-5842-I-Receptacle-Commercial-Grounding/dp/B000U3BVMI

Attached to two 6-20p to c13 y splitter cables like this:

https://www.rackmountpdu.com/category/189-6-20p-to-c13-splitter-power-cords.aspx

That will do 4 units for less than the cost of a PDU alone.




Current plan will be the following:

Get a 40A dryer cable and run that to a 3 gang box.  Get 3 of these receptacles and build my own box from those, then get cables from the receptacles to the miners.
104  Bitcoin / Mining support / Electric Wiring for Multiple Miners from 220V on: November 24, 2017, 02:22:24 PM
I have a single outlet at 220V on a 40A breaker.  I want to run about 7500W of miners off of this outlet.  Some thoughts on how I could do this:

Disassemble the outlet and split the wire into multiple outlet boxes in parallel and use the new outlets.

Find an appropriate PDU for the miners.  (Having trouble finding one with the appropriate input and enough current ratings).

Any other options I am missing?

105  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN] [OCHO] Bitcoin Ocho aka The Future [OCHO] on: December 14, 2016, 08:23:59 PM
I am a brocho.  Please merge my pull request.
106  Alternate cryptocurrencies / Altcoin Discussion / Re: Monero dev makes shockingly obvious discovery Ethereum is a centralized scamcoin on: May 26, 2016, 07:42:22 PM
Bitcoin maximalist will be hating. Smart people realized that the only way is to have cooperations between the main cryptocurrencies. Ethereum can do things that Bitcoin can't and Bitcoin is a better form of value storage.

What can ethereum do other than make it easier to scam people through DAOs?
107  Bitcoin / Development & Technical Discussion / Re: bitcoin "unlimited" seeks review on: January 06, 2016, 01:36:43 AM
[ I really like the concept of BU - mainly because it is the most decentralised approach ]

I am curious as to what people think will happen, IF people started running BU, and the CORE said ' USE THESE SETTINGS ' , would the majority of people use them ?

I think they would.

In fact I think the CORE boys are doing themselves a disservice, by not realising that 'almost' everyone would still follow their lead. Easily the majority.

AND - importantly - even though we would still be using the settings CORE feels is right, because we were given a choice and not forced, there would be no animosity. win win.

People are funny like that.


And you would be surprised by how easy it would be to manipulate a small number of people to change a few settings to cause chaos for them, then have them have a really bad experience, then get press about how bad it is and how they lost their money.  This is a clear intent to break everything and make it too chaotic to be usable.
108  Bitcoin / Development & Technical Discussion / Re: bitcoin "unlimited" seeks review on: January 05, 2016, 02:28:36 AM
This bitcoin-dev post from 2012 by Stefan Thomas explains the philosophy behind BU exceptionally well:

http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2012-June/001551.html

Quote
The real limits are the bandwidth, computing and memory resources of participating nodes. For the sake of argument suppose a 1 TB block was released into the network right now and we'll also assume there was no block size limit of any kind. Many nodes would likely not be able to successfully download this block in under 10-30 minutes, so there is a very good chance that other miners will have generated two blocks before this block makes its way to them.

What does this mean? The miner generating a 1 TB block knows this would happen. So in terms of economic self interest he will generate the largest possible block that he is still confident that other miners will accept and process. A miner who receives a block will also consider whether to build on it based on whether they think other miners will be able to download it. In other words, if I receive a large block I may decide not to mine on it, because I believe that the majority of mining power will not mine on it - because it is either too large for them to download or because their rules against large blocks reject it.

It seems the idea was not really explored further until now.

The counter-argument given by GMaxwell in that thread?

Quote
By itself letting the size float has non-trivial existential risk. A Bitcoin with expensive transactions due to competition for space in blocks can be front-ended with fast payment systems and still provide the promised decentralized currency. Bitcoin with a very large blockchain and blocks does not.

Funny that would be at the top of his mind.

Quite the foresight by good ol gmax.



The real question is where did Blockstream find a time machine to go back and bribe him then?
109  Bitcoin / Development & Technical Discussion / Re: bitcoin "unlimited" seeks review on: January 04, 2016, 03:21:57 AM
I am very enthusiastic about Bitcoin Unlimited and think it is a great idea. (Disclaimer: I am a big blocker, and see BU as the mechanism that will end up bringing higher maximum block sizes that can let Bitcoin scale with on-chain transactions. Anyway, my stance on big blocks is, I think, independent of my argument below.)

As Zangelbert Bingledack has argued before, BU lets users do something that they can already do, albeit currently in a more complicated way. Let's suppose a group of miners decide that a blockchain with 2 MB blocks is acceptable to them, and want to gamble that other miners and economic actors (like exchanges) will think likewise and accept such big blocks too. They can already upgrade to a blockchain that supports larger blocks by recompiling their own custom version of Bitoin Core where they substitute a higher value for the integer constant MAX_BLOCK_SIZE. If these miners command a minority of the total hashing power, they will find that whenever they try to relay a 1.9-MB block, it gets stalled among nodes that refuse to relay it and the block gets orphaned and rejected by the longest chain. Now they could keep on trying to propagate their blocks and use human-communication channels like this forum to try to attract other miners and users to the 2-MB camp, but there is something that will probably put them off and that makes it hard for this approach to succeed: the moral aspect. Right now, the more common view is that a block that exceeds the 1-MB cap is an "invalid" block that violates the consensus rules, just as would be a block that contains, say, invalid transactions or incorrect hash values. This leads to a situation where the miners sending 1.9-MB blocks out to the open will get rejected as "malicious" or "attacking" nodes. Any reputable mining company won't want to be associated with such antics, and will understandably keep their blocks under the limit to be seen as well-behaved legit nodes.

Now the great idea behind BU is that it completely eliminates this moral aspect by taking the maximum block size out of the consensus rules. Under BU, the blockchain becomes a parameterised family of N-capped blockchains. If BU becomes the main Bitcoin implementation, miners may freely choose to decide that they can support a 2-MB-capped blockchain or a 32-MB-capped blockchain without anyone shouting at them "malicious!", "attacker!", "you filthy rascal, impostor of a node, boo, boo, boo!!!". The moral aspect vanishes as it is now just as legit to adhere to any cap. Those who only support the 1-MB-capped blockchain will reject any blocks bigger than 1 MB, while the 2-MB-capped blockchain nodes may keep on trying to build a longer chain. It's important to note that the blockchain only splits when a subset of the miners advocating for an N-capped blockchain command more hashing power than those miners that advocate for M-capped blockchains such that M < N. At that point, two things could happen: a node supporting the M-capped blockchains may accept that a longer chain now has larger blocks and raise their M parameter to match at least N, the new proof-of-work consensus, or insist that they won't support such large blocks and keep on mining a shorter chain of blocks that respect their M limit. This might lead to several alternative chains coexisting for some time, but the ensuing chaos should be very brief as the free market will rapidly settle for one of them. My feeling is that this would be the chain with the higher block sizes and the larger proof-of-work behind it.

How will the growth of the block size cap happen under this mechanism? I think the pressure on miners to increase the limit will grow as the cap starts to be hit. As more users try to send (on-chain) Bitcoin payments, the 1 MB limit will be hit more and more often and a backlog of transactions will start to grow. This will lead to users complaining about their transactions being stuck in limbo and some negative media reporting about it ("Bitcoin network collapsing" and the like). Under such strained conditions, which we may start to see pretty soon, the Bitcoin price will take a battering in the exchanges with miners starting to worry about their income and realising that they're jeopardising the Bitcoin network and their earnings by not raising the cap. I could be wrong about all this, of course, but then it would be the free market which would prove me wrong by settling on a tightly capped blockchain. In any case, thanks to the mechanism that BU provides, raising the block size limit can be a market-driven smooth transition rather than an incessant and unseemly fracas among the core developers in the mailing lists and IRC channels.

via Imgflip Meme Maker
110  Bitcoin / Development & Technical Discussion / Re: bitcoin "unlimited" seeks review on: January 03, 2016, 06:36:14 PM
A very simple attack can be done on the network.

There are really 3 parameters that can be set at each node:

1) Maximum generation size (only used by miners)

2) Maximum relay size (used to propagate to peers)

3) Maximum acceptance size and # of blocks ahead to force an automatic change of parameters (This mechanism is one I am less sure of how it works).


I'll ignore the first parameter since it's set by miners.  Suppose I want big blocks in my unlimited node.  I set a max relay size of 32MB and max acceptance size of 32MB (the maximum allowed?).  I will accept anything I see that is the longest chain and pass everything along.

Now suppose I connect to a bunch of nodes, and they have much lower limits - the max relay they have is 2MB, and max acceptance is 2MB.  I will never see any blocks bigger than 2MB!  Even if the majority of nodes were accepting large blocks, and I just got connected to a few small block nodes, I'm screwed.  I'm out of sync with everyone else, and there's nothing I can do to sync up.

The attack is simple - launch a bunch of nodes, try to connect to as many nodes as possible, and stop relaying anything big.

In a large enough network, this doesn't even need to be accidental.  Some poor sap gets unlucky and connects to all small block users, and can't ever get an update.  The end result is many chains and chaos.

Of course this is solved in an interesting mechanism - a bunch of people get together and talk and coordinate limits and upgrade together... hmmm.... sounds familiar.
111  Bitcoin / Development & Technical Discussion / Re: bitcoin "unlimited" seeks review on: January 03, 2016, 04:04:00 AM
It is entirely obvious the MO of Unlimited.

1)  Create chaos.  By having all kinds of forks and "emergent" consensus, no one will know what to trust, and the network becomes useless and untrustworthy.

2)  Distract development on Bitcoin.  Any time spent having to refute this nonsense is time that could be spent on other tasks that are actually useful.

3)  Find new suckers.  The "Trump" effect.  Appeal to the lowest common denominator for those without critical thinking skills, develop a following, then use it as a fundraising attempt.  Just wait - they will be begging for money from their "government" as taxes and use it to fund themselves.

It's fairly obvious that this is an unworkable idea that will result in very bad things for anyone who uses it.  Give a warning for such users, and anyone stupid enough to follow these fools off a cliff without a parachute can suffer the consequences.
112  Bitcoin / Bitcoin Discussion / Re: Bad vibe in Texas on: March 13, 2014, 08:30:57 PM
The difference is freedom of trade. DEMOCRATS are much more likely to throw a high tax on gains so we can pay for more entitlements and big government programs like free healthcare for all.
Good thing the Republicans never increase spending on boondoggles like endless war or drug crimes!
I never said republicans are a great choice, just a better choice.

I guess getting your pinky amputated over your ring finger might be a better choice too.
113  Bitcoin / Bitcoin Discussion / Re: Bad vibe in Texas on: March 13, 2014, 08:16:05 PM
The difference is freedom of trade. DEMOCRATS are much more likely to throw a high tax on gains so we can pay for more entitlements and big government programs like free healthcare for all.
Good thing the Republicans never increase spending on boondoggles like endless war or drug crimes!
114  Bitcoin / Development & Technical Discussion / Re: Are multi-sig M-of-N transactions with N > 3 supported? on: March 10, 2014, 06:37:43 PM
Multisig transactions bigger than 3-of-3 are valid but not standard.  This means that doing such transactions is technically valid, and if they show up in the blockchain, they will be accepted by all peers on the network.  However, no peers running unmodified Bitcoin clients will even forward the transactions, and miners will not mine them if they see them.  If you broadcast a 5-of-7 multi-sig transaction (create or spend), it will be DOA to most/all of your peers.

If you want to use them, you must seek out a miner who will agree to mine these transactions for you, and it will take a very long time for it to get into the blockchain.  i.e. if you make an agreement with a miner that represents 0.5% of the total network mining power, it will take an average of 200 blocks (1.3 days) for it to be mined.  It may take a few hours, or a week, depending on that miner's short-term luck.

I know as a matter of direct experiment that this is at least partly incorrect. I've sent several 3 of 4 multisig transactions to random electrum servers and they got picked up fine. (for clarity: spend from 3 of 4 p2sh address transactions)

More to the point, read Peter Todd's response to my query about this here: https://bitcointalk.org/index.php?topic=390046.msg5571289#msg5571289
(you might need to read the conversation before and after)

I'm in the business of trying larger N transactions (M of N, P2SH) now. Some clarity would be nice Smiley

The problem isn't with the P2SH transaction, but the redeem transaction, which is non-standard if the script is > 500 bytes.  This can lead to some big problems where you make a script that is unspendable, except if you can connect directly to the miners who will mine them.  You don't realize what you have done until it's too late.  There's a solution, but you realize it after the funds are locked up rather than before, which is unfortunate.
115  Bitcoin / Bitcoin Discussion / Re: Bitcoin speech - regulation and Wall St, emerging markets on: March 10, 2014, 02:55:50 AM
Speech on regulation at Texas Bitcoin Conference

http://youtu.be/mOg0MHr-0no


Would love to hear anyone's thoughts on this.

Hi Bruce,

I was there and enjoyed it quite a bit.  Glad to talk to you afterwards, too.
116  Bitcoin / Development & Technical Discussion / Re: Are we prepared for an emergency blockchain fork? on: March 10, 2014, 01:26:07 AM
Why would we even suddenly need an emergency fork?

The discovery of a critical bug in the protocol.


Also an attack that has no way to overcome it other than a hard fork.
I think the basic protocol and blockchain are robust enough to have no forking capable attacks. The last fork was caused by incorrect function of database engine and was resolved on the fly as I was sitting and drinking beer while watching events unfold.

I'm talking about an attack where the fix to it is a hard fork.  For example, if rogue miners started double spending in mass, rolling back the chain, holding the block chain hostage for huge tx fees, etc...
117  Bitcoin / Development & Technical Discussion / Re: Are we prepared for an emergency blockchain fork? on: March 09, 2014, 11:20:47 PM
Why would we even suddenly need an emergency fork?

The discovery of a critical bug in the protocol.


Also an attack that has no way to overcome it other than a hard fork.
118  Bitcoin / Development & Technical Discussion / Re: Are multi-sig M-of-N transactions with N > 3 supported? on: March 09, 2014, 11:10:14 PM
BIP 11 makes M-of-N multi-sig transactions standard --- for N <= 3. What is the current support among miners for the multi-sig transactions with N > 3? (say 3-of-6).

Cross-posted from http://bitcoin.stackexchange.com/questions/23274/are-multi-sig-m-of-n-transactions-with-n-3-supported

Correct me if I am wrong but P2SH replaced OpEval and thus BIP 11 is "obsolete".

This is pretty much true, you can do P2SH to support M of N.  However, I believe the limitation of the ScriptSig is 500 bytes to be declared standard, which basically is X of 3 signatures.  Unless I am misreading the source code.  I would like some clarification of this from someone else if they are sure.
119  Bitcoin / Bitcoin Discussion / Re: Gavin Andreesons protocol extension. The only way to stop fractional exchanges on: February 25, 2014, 09:17:52 PM
I read recently (if not hoax) that Gav was suggesting a protocol addition so that you could prove and exchange has all the BTC it says it has.

Without something like this, I think all exchanges will yield to the temptation to fractional practice, by design or fault.

With it, it would make the btc side one of the safer ways to invest....with any entity as you can check at any tie their claims as to reserves.

No protocol extension is needed for this.  The problem with relying on this methodology is let's say an exchange doesn't actually have your funds.  What are you going to do now?  You are still going to get Goxed.
120  Bitcoin / Development & Technical Discussion / Re: Stealth address with SX (anonymous payments) on: January 18, 2014, 10:31:14 PM


I'm not denying that it is important, but most people will nottake the steps to protect it, and even actively take steps to give it up if it gives them a small benefit.  AT&T is offering high speed internet if they can spy on your data, how many people do you think will do anything extra to hide their privacy?  It sounds like this is intended to be a mainstream and behind-the-scenes implementation, in which case, it simply becomes your address.

More like they feel there is nothing they can do and are simply giving up. As for AT&T, well the threat is still intangible in that case.

There's a different option you can do that costs more, from what I remember about it.
http://gigaom.com/2013/12/11/atts-gigabit-service-is-70-if-you-let-it-spy-on-your-searches/

And the Bitcoin "threat" is equally as intangible.  Users think that following typical procedures, Bitcoin is anonymous!  Why go the extra step?  There are a lot of misconceptions and misuses today, and we probably have the most educated userbase we will have looking forward, right now.
Pages: « 1 2 3 4 5 [6] 7 8 9 10 11 12 13 14 15 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!