Bitcoin Forum
June 12, 2024, 06:42:54 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 3 4 5 6 »
1  Economy / Services / Re: [$] Need developer. Add Bitcoin Core RPC command [deleteaddress] on: June 17, 2016, 01:26:40 PM
It might be a good idea to see what problem you are trying to solve. It's quite dangerous to have a command that nukes private keys from your wallet, because that is how people shoot their feet off.
2  Other / MultiBit / Re: Why I can't send btc from multibit to greenaddress? on: June 26, 2015, 11:58:46 AM
Have you verified it understands *any* P2SH address? I had problems in the past with bc.info not understanding P2SH.
3  Bitcoin / Development & Technical Discussion / Re: SPV client backed by personal full node? on: June 25, 2015, 01:22:06 PM
Unfortunately the wallet silently fails, so you lose any privacy benefits if it can not connect.

I think connecting to a Tor hidden node makes more sense for now, since it's already authenticated and encrypted. The wallet currently doesn't connect to those though.
4  Bitcoin / Development & Technical Discussion / Re: Lightning Network (another proposal to make bitcoin scale) on: March 27, 2015, 01:09:31 PM
http://www.coindesk.com/could-the-bitcoin-lightning-network-solve-blockchain-scalability/

"If the bitcoin blockchain were a horse, ordinary hub-and-spoke payment channel proposals would be proposing to replace that horse with a truck; the Lightning guys are proposing to replace that horse with a rocket ship."  -- Peter Todd

Requires some more work and a soft fork to implement. The future looks bright Smiley

A leading candidate for testing the soft-fork on a sidechain perhaps.

Merge-mined sidechains require a fork too!  Cheesy

I guess a federated sidechain could do it.
5  Bitcoin / Development & Technical Discussion / Re: BIP proposal: Automatic Wallet Backup scheme on: February 24, 2015, 01:45:49 PM
Have you discussed this scheme with hardware wallet makers?

It'd be great if there were any way possible to get this to work with Trezor/Ledger, but I'm unaware of their ability to do symmetric encryption schemes.

Otherwise, it seems quote well-thought out.
6  Economy / Service Discussion / Re: Blockchain.info - where are the private keys? on: February 23, 2015, 03:40:32 PM

So if they keep private keys (in encrypted form), why haven't they been hacked.  It seems like they'd have a shitload of keys and after someone got those they'd have very little trouble 'guessing' passwords against them.  Are you sure they keep private keys in their database?  Seems like a very big target to me.


You're 100% right. bc.info is not a safe wallet. Javascript/password based wallets are dangerous, and bc.info doesn't have a great track record.
7  Bitcoin / Development & Technical Discussion / Re: Individual Block Difficulty Based on Block Size on: February 20, 2015, 01:41:21 PM
We need most of the planet's double-sha256 capability devoted to Bitcoin mining instead of doing something else.

As long as that condition holds, the actual hash rate isn't very important.

That's not clear at all. We need, at a minimum, a majority of *active* hashrate to not "attack" the network. 

Your economic theories aside, there is very little consensus on how we will achieve this.

I'm an optimist. I'd like to think that regardless of block size, a million people will donate a little bit of hashing on their USB sticks at a loss leading to an extremely hard to censor network. The other equilibrium aren't nearly so clean.
8  Bitcoin / Development & Technical Discussion / Re: Individual Block Difficulty Based on Block Size on: February 18, 2015, 02:45:09 AM
stuff

The key is all those fees will just be going towards non-hashing. Security of network will most likely die with an infinite blocksize unless a minimum fee is imposed by miners via soft-fork.
9  Other / Archival / Re: delete on: February 17, 2015, 05:18:11 PM
Shame. I'd feel pretty badly treated if I were EK, nothing but venom hurled his way and then didn't even acknowledge his ideas when he gave them away for free.

Check his claims history. Big waster of time, historically.
10  Bitcoin / Development & Technical Discussion / Re: Multi-language consensus library on: February 17, 2015, 02:02:10 PM
For clarification: Do you mean port the GUI/wallet parts into different languages?

Porting consensus code would defeat the whole purpose.
11  Bitcoin / Development & Technical Discussion / Re: about UTXOs with OP_RETURN on: February 10, 2015, 02:32:11 PM
Using OP_RETURN for embedding data for a colored coin like system is called "embedded consensus systems". The data could just as well be junk.

You don't get to use miners to enforce validity of these "transactions", so you have to verify it yourself as a user of the system. 

12  Bitcoin / Development & Technical Discussion / Re: What is a Bitcoin soft fork? (in laymen's terms) on: February 06, 2015, 02:06:50 PM
https://bitcoin.org/en/developer-guide#consensus-rule-changes 

bitcoin.org documentation explains it quite nicely.

I am also writing up a blog post Soon^TM to rephrase and give some history.
13  Other / Archival / Re: delete on: February 02, 2015, 10:00:35 PM
I totally believe you. Dang it where's my sarcasm font?
14  Bitcoin / Development & Technical Discussion / Re: 50% attack for ~800 BTC after block reward halving on: January 30, 2015, 04:03:28 PM
This attack will probably always be viable in some sense once the rapid pace of ASIC development slows down to a (relative) crawl.

When dark hashpower is >> hashrate, anyone can buy and spin up hardware, with the marginal cost being electricity.

Groups will most likely hold onto miners even if they aren't being used in case the hashrate dips too much or they get invested in a block race.
15  Bitcoin / Development & Technical Discussion / Re: Are BTC Devs Doing Enough To Encourage Adoption of BTC? on: January 26, 2015, 01:51:50 PM
Core dev work is *almost* orthogonal to making it go "mainstream".  

It's like arguing TCP/IP developers aren't doing enough to make Facebook go viral.

You want Core devs to make sure the core consensus mechanism is humming along. Almost nothing else. 

edit: The blockchain is to give a partial ordering off data published. Nothing else. It's not magic.
16  Bitcoin / Mining support / Re: Hide bitcoin process on: December 11, 2014, 07:41:58 PM
1) Send in your 2 weeks notice. 

2) Tell your family you love them. 

3) Turn yourself in for theft.
17  Other / Off-topic / Re: Collisions for Hash SHA256 will kill Bitcoin. on: December 06, 2014, 11:09:07 PM
lmao this thread.

I'm guessing the pixel values were mutated until a collision occurred, right?

Some stuff: http://stackoverflow.com/questions/933497/create-your-own-md5-collisions
18  Alternate cryptocurrencies / Altcoin Discussion / Re: Idea for ASiC resistance on: November 20, 2014, 03:18:20 PM


If the choice for the algorithm depends on the hash of the previous block, I cannot see how anyone could steer the next function?

A large pool/ASIC group could grind blocks until they get blocks that steer it to something they like.  

Pool is good at hashing alg X. It's at Y, which is close to X, giving an advantage. They decide they will only release blocks if it moves it closer to X. Once X is achieved they own the dominant hashing power by manufacturing fiat.

But also, as mentioned before, you're going to get naturally bad PoW algorithms that don't scale correctly, or take too long to verify, etc. Even without "malicious" actors you're going to possibly get crazy behavior.
19  Bitcoin / Development & Technical Discussion / Re: O(1) block propagation on: November 20, 2014, 02:31:18 PM

Since only miners create IBLT blocks, but all nodes would need to process them, it seems the best implementation method is split the IBLT software into two parts:

I might be wrong, but in the short term it's not as big a deal that regular nodes get these IBLT stuff. Full nodes care much less about ~15 seconds of latency.

Long term it might make sense.
20  Alternate cryptocurrencies / Altcoin Discussion / Re: Idea for ASiC resistance on: November 20, 2014, 02:24:02 PM
There have been similar proposals before to do this, but it isn't immediately clear it's wanted, or that it provably will stop ASICs. 

Also it may lead to people trying to steer the next function into functions it can do better than competition.

Pages: [1] 2 3 4 5 6 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!