 Show Posts
|
|
Pages: [1]
|
We've launched Snowblossom. Clean, Original Code. Custom POW. UTXO Built into Blocks Headers. Truly ASIC, Miner Centralization, and Quantum Resistant. No Premining. We're looking for legitimate involvement and interest. https://snowblossom.org/https://github.com/snowblossomcoin/snowblossomThe features we enable include: 1. Aggressive IO based PoW with large deterministic files should be very hard to ASIC in any sort of cost effective way 2. Quantum Resistance - Large RSA key support 3. UTXO root hash in block header to be able to give provable results to light clients It has the usual features as well: Child-pays-for-parent (CPFP) Transaction immutability Resilient peer-to-peer network Decentralized design Halfing-block reward over time First Seen First Added FSFA (double-spend protection) Thanks for your time. Spin up a node a check it out. There are still some rough edges, but everything is working. |
|
|
|
I have a question about SSL versions. I have a java electrum server and with new versions of jvm it doesn't allow connections using SSLv2 or SSLv3. Here is a summary of what versions exist: http://en.wikipedia.org/wiki/Transport_Layer_Security#CipherIn short, for security reasons it would be good to go to TLSv2 as soon as is reasonable. Before I go on, I should note that this has nothing to do with the security of your bitcoin, your keys or your seed. All the SSL link is protecting is the privacy of which addresses you ask an electrum server about. This isn't super important because we are mostly using self-signed certs and these connections could be main in the middled already. So anyways, existing clients can't connect to my servers via SSL since the java SSL implementation wants some flavor of TLS now. The client python code does: ssl.wrap_socket(s, ssl_version=ssl.PROTOCOL_SSLv23, ... In new versions of python, SSLv23 doesn't mean SSLv2 or 3 only, it actually means anything not SSLv1. So after people start running newer python, this setting of SSLv23 will be fine. However it probably would be better to call for PROTOCOL_TLSv1_2 at some point. So really nothing needs be done. In my testing it looks like some of the existing python electrum servers support TLS 1.2 already. |
|
|
|
I've tried this with 0.8 release branch, 0.9 and head. I get the same results for each. The getdifficulty returns 1.0 and the found blocks confirm that this seems to be the case. However, getblocktemplate is showing a much harder difficulty in the target: 00000000000003a2d80000000000000000000000000000000000000000000000 Broken up for readability: 00000000000003a2 d800000000000000 0000000000000000 0000000000000000 For that difficulty it should be something like: 0000000100000000 0000000000000000 0000000000000000 0000000000000000 The most recent found block agrees with this: 0000000076f8abad2 ./bitcoind -testnet getblocktemplate ...transactions omitted... "coinbasevalue" : 2500081729, "target" : "00000000000003a2d80000000000000000000000000000000000000000000000", "mintime" : 1424334619, "mutable" : [ "time", "transactions", "prevblock" ], "noncerange" : "00000000ffffffff", "sigoplimit" : 20000, "sizelimit" : 1000000, "curtime" : 1424334619, "bits" : "1a03a2d8", "height" : 323482 } ./bitcoind -testnet getdifficulty 1.00000000 I'm trying to run some blocks on testnet to make sure my mining pool software still works correctly.  |
|
|
|
https://github.com/fireduck64/jelectrumI have created a fresh electrum server that uses java and bitcoinj. It replicates all features of the standard python electrum server (that I know about). If anyone tried it in the last week, I just changed some things around in the database. You'll have to nuke your mongodb DB and sync fresh.
|
|
|
|
|
I think I have my electrum server implementation feature complete. More testing is needed.
You can help me by trying it out:
h.1209k.com:50001:t
h.1209k.com:50002:s
It is about 4k lines of java. It syncs faster than the python reference server using multiple threads to import the transactions for a block. It also works on the transactions for multiple blocks at once. It uses a local mongodb instance for data storage, but it could use pretty much any fast key-value store. It syncs the entire blockchain from scratch in about 3 days (faster on fast hardware+ssd).
In my testing, it seems to be faster to sync a large wallet (300+ addresses) about twice as fast but I haven't done rigorous testing there yet.
I hope to release the code later this week.
If you encounter problems and want to help track them down please reproduce them on:
h.1209k.com:50015:t
This port records all TCP traffic in and out for debugging purposes. Then let me know the time you did it as exactly as you can and I'll be able to pull the logs.
FYI, if you want to connect to a single server and no other the command line looks like this:
electrum -1 -s h.1209k.com:50006:s
|
|
|
|
So in the electrum protocol there is a "utxo_root" with the block headers. What is that about? The only thing I've been able to find is this discussion: https://bitcointalk.org/index.php?topic=101734.0This discussion is more focuses on adding it to the bitcoin blockchain. Can anyone offer and guidance on how electrum is implementing this or how the clients will use it? I am in the process of building an alternative electrum server and am trying to make it feature compatible. |
|
|
|
|
I am in the process of writing an alternative electrum server. Without derailing into why I am doing that I have a few questions.
When a client calls blockchain.address.subscribe the response seems to be a hash of the transaction IDs and block heights known to that server in a particular form.
- descending order by block height
- For each transaction: "txid:height:"
All this sha256ed and then returned.
Does this checksum need to be the same between electrum servers? (Do I need to do the same exact things to be compatible?)
If so, what do I put for height if a transaction is unconfirmed?
How do I order them if they are at the same height?
If there is a doc somewhere that has this spelled out, I would love that.
|
|
|
|
http://1209k.com/brainv2/About People love the idea of a memorizable key for bitcoin wallets. There is an appeal to having something in your head worth something and having it written no where and not stealable without a $5 wrench. Problem What people currently refer to as a "brainwallet" is simply a passphrase run through a single SHA-256 and then the result is the private key for a bitcoin address. The problem here is that an attacker can download the blockchain and then run very fast attacks basically hashing any text they can find to see if it hashes to a key which has some bitcoins. And when they find one, they drain that address. They can do this very fast since a single SHA-256 is quite cheap. This leads to sadness. Solution An awesome answer is key stretching. The short version is that a function is used to make it more time complex to test a key. As a simple example, lets say rather than SHA-256 once, it is SHA-256 a million times. That means it is a million times more expensive for an attacker to test each possible password. Then you make it even better by adding in something unique to the user. This makes the attacker have to do much more work as each different salt uses a different input on its million SHA-256 operations.
|
|
|
|
|
Unless I am just not seeing it, the gap limit option seems to not be there anymore in electrum 1.9 on windows.
Due to some silly that I'd rather not get into I need to restore a wallet with a gap limit of around 25.
I managed to work around by loading the wallet in 1.8.1, setting the gap limit and then loading it in 1.9 just fine.
|
|
|
|
|
Supposing I have enough bitcoin to justify either expense in the name of security, which would be better:
A) A netbook running linux (probably debian) and electrum. I would use it for nothing else and would use disk encryption.
B) My existing moderately secure computers running electrum and using Trezor devices for high value wallets?
(bitcointrezor.com)
Anyone have any arguments for either? I am somewhat inclined towards netbook but that is mostly because I can get my hands on one now.
|
|
|
|
I have a piece of artwork that was savaged in an unfortunate incident involving a small child and a pink highlighter. What I need is for someone to remove the pink highlighter marks and any crinkles in the paper as best you can. It doesn't need to be perfect, it just needs to be good enough to look ok when printed on a reasonable ink jet printer at about 8" x 5". I'd prefer if the edits were done on the high res one, but I am fine with either: https://s3-us-west-2.amazonaws.com/fdk-share/BirdsHiRes.png [ 52mb, 5796x7620 ] https://s3-us-west-2.amazonaws.com/fdk-share/BirdsLowRes.png [ 5mb, 1449x1905 ] I'll pay up to 10 people 0.5 BTC for a reasonable effort and 5 BTC for the submission that I think is best. I'll close the contest and award the winner in about 27 hours, at 2012.10.17 00:00 UTC. (I've run a similar graphics task a while back: https://bitcointalk.org/index.php?topic=87869) |
|
|
|
I can have a few hundred BTC on hand if there is interest. I'll sell for around MtGox 24 hour low unless the market is going crazy. Cash only. Email fireduck@gmail.com to setup a meeting. I should be there part of the day Friday and most of the day Saturday. I have an awesome green Nyan cat shoulder bag. It isn't for sale, but will help identify me. I will have preprinted addresses from bitaddress.org which I can give out, but obviously having your own address and not trusting me would be more secure. Please bring address as QR code. |
|
|
|
I'd like to announce the Horrible Horrendous Terrible Tremendous Mining Pool http://hhtt.1209k.com/The special feature here is higher difficulty work units to reduce network chatter. It uses difficulty 32 work units (for now). Getting ready for higher hash rate butterflies in October. If you have a 1GH/s setup now and see the shares scrolling by at one every few seconds, imagine what it will be like with a 40GH/s BFL SC Single. There is simply no need for all that traffic. The time when difficulty one pool proof of works made sense is over. |
|
|
|
I need 16 small graphics created. I have example images of each of what I am looking for roughly. Here is how I'd like to work this. The first image is a llama. I want it in a simple cartoonish style. It needs to be png with a transparent background and 32x32. Here is a model image, showing the pose I want. I just want the llama, no background. http://img.1209k.com/e996d81bb03a4b9a29e6405e8a424ad2.jpgSend me your submissions. If I like it, I hire you and give you the rest of the list of items. If it is a solid entry but I don't like it I'll send you 0.5 BTC and thank you for your time. If it is not a solid entry, I'll thank you for your time. (Entirely my decision). Please sent bitcoin address with submissions and post submissions on thread for everyone to enjoy. I'll of course want to do a little back and forth revising the images but I'm not very picky and will do my best to not waste anyone's time. |
|
|
|
|
Lets say I am a p2pool miner. Lets also say that I have a bitcoin service where it would be really handy to get transactions into the blockchain. These would be transactions from my customers who may have included an insufficient fee and I'd like to help them out.
Can I include whatever transactions I like in my p2pool share blocks and then have them include in the next p2p main chain block? I get a share every few hours at least and then p2pool gets a block in the main chain several times a day.
I haven't figure out what information is in the p2pool chain vs the main chain. I suspect what I want is impossible but I haven't been able to sufficiently understand the p2pool code to be sure.
My guess is that whoever makes the block that goes into the main chain includes whatever transactions their local bitcoind thinks are good. So if I happened to be the one who got the real block and modified my bitcoind to do what I want it would work. However, that isn't very likely.
|
|
|
|
|
