Bitcoin Forum
December 05, 2022, 06:10:40 PM *
News: Reminder: do not keep your money in online accounts
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 »
1  Economy / Invites & Accounts / For sale Bitmain Account with one Antminer D3 Paid on: August 11, 2017, 07:03:15 PM
I'm selling my bitmain account with One Antminer D3 Paid today Shipping :1-15 Nov

I want to sell for 0.6 btc

You can change shipping

(by default was US)

more detail by PM

thank you
2  Economy / Currency exchange / Exchange 200$ paypal for 200$ btc on: August 11, 2017, 05:46:47 PM
Exchange 200$ paypal for 200$ btc

let me know
trade 1:1

pm me
3  Bitcoin / Bitcoin Technical Support / Sequential repeatable address generator (as opposed to random) on: June 25, 2014, 11:26:25 AM
I need to create addresses, given a creation range, that are essentially sequential.

I realize that the addresses themselves will not be sequential... It is the keys. Where they are valid.

The purpose is so that I can re-create a series of addresses, without having to worry about losing the wallet due to corruption, theft, or any other act of nature. I do understand the implications that if I can recreate them, that anyone-else can, if they know the sequence.

I have used the "bitcoinjs-min" v0.2.0 for a test-run, but I can not get it to create anything sequential. (Even when I give it a specific value, it just dies and doesn't create anything at all.)

I don't need or want any fancy salt or super-finder or other interfering code, since that will be added later. I just need it pure KISS.

Code:
rawPrivKey = MakePrivateKey(X); // Raw key "X" being the specific value to use, or find the first valid key from there.
myPrivKey = MakePrivateKey(rawPrivKey); // WIF Uncompressed
myPubKeyU = GetPublicKeyU(rawPrivKey); // Address Uncompressed
myPubKeyC = GetPublicKeyC(rawPrivKey); // Address Compressed

Simplified:
ValidValues = new GetValidSet(X); // Returns the first valid value and the actual set data, from X-???
MySet = ValidValues.Set(); // "WIF-Private-Key, Address-Uncompressed, Address-Compressed"
LastValue = ValidValues.Last(); // This would be X+whatever, if it was 2000 values before a valid one was found, X+2000

(For wallet compatibility I need both compressed and uncompressed output for addresses. This is because not all wallets check both unless you explicitly add the other one also, on import.)

That will be used in a loop, so I can generate the sequence of addresses. X = 1-100, 594-694, 23953223193478-23953223193578 etc...

The code I use now is this...
Code:
rawPrivKey = new Bitcoin.ECKey(); // Generates a random private key *** Need this specific range
myPrivKey = rawPrivKey.toWif(); // Converts raw private key to WIF format
myPubKeyU = rawPrivKey.getPub().getAddress(); // Gets uncompressed public address from raw private key
myPubKeyC = rawPrivKey.getPub('compressed').getAddress(); // Gets compressed public address from raw private key

*** The use for Bitcoin.ECKey();, shows that I should be able to use a value in the brackets, but there is no functioning documented code I could find, indicating what it allows for a valid value. Tried raw numbers, HexToBytes, BytesToHex, 'strings'... anything I place in the brackets just cause it to crash and the code never executes beyond that point. The actual code does not help. There is so much bloat in there to handle every browser and every possible font/iso-format/unicode/variable/object/error... yet it just dies. xD So much for effective bloat.

Anyone think they can help?

Major bonus points if you can do this in VB6, or make this a simple 32-bit DLL file. xD
4  Bitcoin / Hardware / AMT Order List, Revised. on: April 22, 2014, 01:18:19 PM
The original list can be found here. LINK: AMT Order List

Please no trolls. This is not a thread to discuss power consumption, hash rates, how good your attorney is, how many unanswered phone calls, etc

Post your order number, date you ordered, model and amount and whether you have received it.

I will try to keep it as organized as I can. You may also mention RMA status, if you have a issue with the delivered item. However, this is not a form of contact for RMA, for AMT. Please contact them directly for assistance. This is only for historic records of business with forum-members. If you have made a purchase, and are not yet a member of the forum, please sign-up, and make a post with your information.

Thanks, JD (ISAWHIM)

P.S. Please let me know of any changes to your order-status, or corrections.

NOTE: Pending orders may have been received, they have just not been reported as received.

PENDING
ORDERS
.........................................................................
UsernameOrder #Date OrderedModel #Quantity
....................................................................................................
Boaz3337610.01.2014320?
VBT40310.03.20131922
mmfiore41410.04.2014192?
geoloudon47710.06.20131921
otep49210.21.20131.21
NaranKPatel51510.12.20131.21
NaranKPatel51910.15.20131.21
wtiger12752110.14.20131.21
ladi4ever53310.31.20131.22
russellthies54110.23.20131.21
clenell61011.11.20131.21
ladi4ever63111.12.20131.21
rzrminer64011.12.20131.21
tonyca64511.12.20131.21
cowpiboy66611.14.20135201
cowpiboy67211.15.20135201
captin crunch67611.15.20131.21
cicask8ers68611.15.20141.21
chlangyue016869011.16.20141.21
chlangyue016869111.16.20141.21
? ? ? ? ? ? ?69911.16.20131.21
termonator6170011.19.20131.21
cowpiboy70911.21.20131.21
cowpiboy71011.21.20131.21
captin crunch71611.22.20131.22
russellthies79811.29.20131.21
C0Kez3R084712.03.20131.21
Squeeky6284912.04.20131.21
Chazaki89912.05.20131.22
mdtspain94412.08.20131.21
tonyaca96212.12.20131.21
ISAWHIM96812.10.20131.21
Nyboe105112.13.20131.22
cowpiboy105612.13.20141.21
frank754106812.13.2013801
mvick112712.21.20141.21
eightcylinders118812.26.20131.21
eightcylinders119612.29.20131.21
asprin12??01.03.20141.21
mdiggy127501.08.20131.21
l12132701.13.20141.24 of 5
drpibb81135601.27.20141.21
raydeeyo143302.01.20141.21
delta1299145202.03.20145203
petermolloy148502.13.20141.21
NotFuzzyWarm156502.26.20145201


NOTE: Some 1.2 THs miners arrived as a partial kit-form*, out of shipping-sequence, as per request.
* Kit forms have been delivered without a CPU-Case, LCD-Display or a PSU.


RECEIVED
ORDERS
.........................................................................
UsernameOrder #Date OrderedModel #Quantity
...................................................................................................
WinterParker??1281
BiomechReviewN/A801
pierred50110.10.20131921
avaughan458011.13.20131.21
avaughan465011.13.20131.21
swiftshoot80312.01.20131281
Khanduras80512.01.20131281
C0Kez3R084712.03.2013801
YourPalToots86712.04.20131.21
fryarminer88812.05.2013801
Stan-O92812.09.2013801
mrpark95?12.09.20131.21
FrictionlessCoin96112.12.20131.21
Casiriamine112112.24.20131.22
l12132701.13.20141.21 of 5
mellorbo142801.30.20145201
rik_khaos143201.31.20141.21
opieum2149302.14.20141.22


REFUNDED
ORDERS
.........................................................................
UsernameOrder #Date OrderedModel #Quantity
....................................................................................................
elaramus399???


5  Other / Off-topic / Anyone here that ever played "Rifts" RPG? Or any other table-top RPG? on: March 10, 2014, 02:56:29 AM
Just bored, looking to fill time. I was curious if anyone here ever played "Rifts", the RPG game by Kevin Siembieda of "Palladium Books".

After seeing the artwork from the game "Destiny", and after having played "Fallout 3", I kept having flashbacks to that game. Well, that and the old Battle-Mech game. (The RPG, not the video-games. Though the video-games were fun for a bit too. They just didn't capture the point of wielding all that power correctly. Always felt drunk playing the computer-game. lol. Though, I think I was actually always drunk, playing the RPG table-top game anyways. That part is fuzzy.)

Anywho, I saw that they started listing a bunch of older books for sale again. However, they refuse to accept PayPal, and I forgot to push Bitcoins, which I assume they would be more receptive to. I got pissed that no-one there was willing to accept PayPal for my $300 order I just placed. lol. So I hung-up and went right to eBay instead. (Now I own half their damn collection, and eBay members got a nice $1000 worth of my funds.)

Not that I was going to play again... I just wanted it to have in my collection. Loved the art-work.

So... Are there any old-school players here, or new ones?

I also played old D&D, and "Car Wars" by Steve Jackson, the creator of "GURPS". However, I think I enjoyed Rifts better. Might have been the alcohol and creative people I played with. I don't think there was ever a serious moment in any of our games. Pure random torture to each-other, and from the game-master. (Oh, how I hate that title... lol. Should have been called the "Annoying guy who loved to torment others". Ok, Game-master is much shorter, and rolls off the tongue better.)

For those who have no idea what "Rifts" is...

Take "World of Warcraft Online", merge that with "Skyrim", merge that with "Fallout 3", merge that with "Grand Theft Auto XVIIXMCXVII", merge that with "Crysis", merge that with "Destiny", merge that with "Tomb Raider XCVMCXII", merge that with "Star Wars", and then shake and stir until you are completely shit-faced.

Spend ten days making a character, perfectly for your needs... Then have a game-master throw you into situations where all that perfection is useless... Before killing your hard work, or dragging your half-dead character around the world. Ultimately, resurrecting you, to kill you again, over and over. Good times!
6  Economy / Economics / nearly $700,000,000.00 USD moved in 24 hours on: March 06, 2014, 04:54:55 AM
I am seeing many large volumes in $24,000 to $380,000 USD moving across the block-chain right now...
Another three $356,000 USD just rolled by...
Just saw two for $640,000 USD...

Tons of them... (About 40+ between that range, and many more $1,000-$6,000... Miners buying more miners?)

Not sure if this is buying/selling, or deposits for cashing-out, or thieves moving some of that stolen BTC from GOX...

But blockchain is zooming tonight!
https://blockchain.info/

P.S. These are individual transactions, not whole blocks of transactions...

Not like the normal volumes I usually see, of only $300-$2,000 USD every day.

Seems like there is millions and millions moving around the last 24 hours...
https://blockchain.info/largest-recent-transactions

Smallest of the last 100 top transactions was $513,912.09 USD... Largest was $9,525,426.76 USD

That is nearly $700,000,000.00 USD moved in 24 hours... Nice!
(Why does that number sound familiar? Oh yea, Mt. Gox... Funny thing to see, no?)
7  Bitcoin / Bitcoin Discussion / Bitcoins, The Movie... on: February 25, 2014, 04:21:59 PM
So when is the movie coming-out...

I am sure all of this drama and FUD will make for a great movie, or a reality show...

Anyone want to help me write the script?

Should it be serious, a comedy, a horror story, a documentary, pure speculation (in the spirit of BTC itself), or just pure FUD (as if all the FUD were actual truth, and real)?

I'll take donations to get started. Make it a fully public world-wide event... But charge for "Day-One" private access before public release... then sell to the rights for those who still watch movies in theaters. Living forever in torrents and YouTube, after that.

Pre-orders now accepted. xD (Seriously)
8  Other / Off-topic / Lets turn the moon into a giant world clock! on: February 20, 2014, 01:59:29 AM
Lets turn the moon into a giant world clock!

I was thinking that this could be done with a simple laser, from a satellite/satellites, orbiting the moon itself. (For the dark-spot.)

For the light spot, simple shadow-casting by solar-automated sheets of plywood/solar-panels would suffice for hours and minutes represented as numbers like a digital watch. (Since the same side of the moon always faces the earth, it would only have to be adjusted once every few hundred years as the moon slowly rotates away.)

I figure it would also have to be mirrored-time (digital representation), so those below the equator would not see it upside-down. GMT time, for simplicity.

Something to compliment my sun-dial, for the night-time, when my sun-dial is useless.

Any thoughts?

Oh and ditch this whole time-zone crap... Just one time, all the time... no daylight savings. Get up earlier, why burden us all with time-zones and DST adjustments twice a year. "Noon" and "Midnight" have been irrelevant since time was invented. It has no relevance anymore.

Oh, and lets paint the surface green or blue, to match the earth... I am tired of looking at that ugly grey color!

You'll never be able to say... Sorry I was late, I didn't know what time it was... (At night)

Don't worry, this will not hurt watch sales. (People still buy those things?)

Oh, the "atomic clock" signal that feeds GPS would be used for keeping it correct. No winding involved, or batteries to replace.
9  Economy / Speculation / Super Speculator... 2.0 (It is that easy, it will happen.) on: February 19, 2014, 03:56:29 PM
1: MtGox opens the flood-gates (Prior to announcement, found by just trying to withdraw.)
2: Someone detects large moves in the block-chain, but coins were already sitting in wait on the other exchanges.
3: Some idiot prematurely dumps and causes a panic on the high exchanges.
4: The panic-Buy on MtGox runs up into crazy highs, with high resistance.
5: Other exchanges see rise, they rise in confusion/competition... (Wrong move)
6: Everyone with BTC on MtGox, who was going to move, tries to move... Some don't make it in time...
7: Other exchanges panic-sell with the actual dumping that follows. Get knocked down after crazy high prices just made a bunch of people a lot of money.
8: No intentions of cashing-out for the money on the other exchanges, the dumps go lower, in pure panic now...
9: All that "money" just gotten, is now used to buy-up all those panic-lows...
10: Quietly, they move the massive qty of BTC back to MtGox, waiting for the money to come a month later, from USA income-tax-returns. (Play money, to arrive in MtGox, now that the panic is over, and all exchanges are equally low, but MtGox still remains just enough under the highs, to get the deposits.)
11: Out of the remaining dust, the holders of money at the other exchanges just decide to cash-out the funds they had to spend on BTC... Some to deposit back on MtGox for the lower rates... After all, they have time, there is still another month expected before the actual peak-rush to come.
12: MtGox works overtime getting deposits into the exchange, opening an American bank, a Chinese bank, and a European bank... Near instant deposits, with no need for "international fees".
13: The world returns to normal as BTC hits a yearly true peak of $6000/BTC
14: Following months returns BTC back to a normal price of $900-$1240, for those who waited for the rush to end, fueling next years peak of $25,000

Anyone want to take bets? JK, I don't gamble... Want to sell me your BTC? (Ironic)

Oh, and LTC crashes as everyone cashes out for all those uber-high BTC values, and uber-low BTC prices. (On BTCe)

Take note to the $40 million dollars 43K BTC listed above $1240-$2590/BTC on MtGox, up to $6000/BTC, which does not even show on the volume charts. $6000/BTC shows once in a while... volume beyond $2590/BTC seems to just not display, but it is there.

Only $5 million below buying price on MtGox... not worth cashing-out to anyone with any value in BTC... not even a stupid guy with millions of BTC would take that big loss. lol.

I think I summed-up about 550,000 BTC swapped around $240-$500 on MtGox the last few days... That's a lot of discount BTC people got in the cash-out and run-around. Discounts stopped rolling in though, the last few hours before the gates are ready to open.
10  Economy / Goods / Removed, sold. on: February 16, 2014, 11:08:01 AM
Items sold.
11  Bitcoin / Hardware / Looking for support... Not money... Unique chip design. on: February 10, 2014, 04:06:55 AM
Using the chip itself (package), to broadcast/receive the data as light. Using open-air, not fiber-optics. (Since this would not be broadcasting feet and miles, just inches.)

This, being a open-source project.

I have thought about this for years, yet I have never found a good reason to "realize" the idea, until now.

For the record, I do not design chips beyond software, however, my ability is personally irrelevant to this concept.

This is my thoughts/observations...
1: Many chips now have few external "supporting hardware dependencies". (Unlike the past, where capacitors, resistors, RF-filters, and various other "physical components" were needed.)
2: The chips/dies are getting smaller, but packages are not. (This due in part to the large number of communication wires and thermal-dissipation surface needed for many designs.)
3: Smaller dies in larger packages, adds slight delays over traditional "wires/traces", which can cause various timing issues or signal-losses, as well as collecting RF-noise and undesired capacitance. (Since a wire along plastic/glass/insulation is essentially a capacitor.)
4: Mounting chips limits heat dissipation, with one side constantly resting on an insulation glass PCB surface, and sitting on traces contained within the insulation PCB layers.

My original idea (not original itself, just saying it was my first thought), was to simply use a LED source, attached to a chip's edge. The connection being the data-lines themselves. (This was on a tiny Atmel-Atmega chip.) Though it worked great, the idea sat dormant for years again.

What I am thinking now, is that the LED component, or LASER-LED, could be built right inside of the chip. This would not "demand", "Fiber-optics", though isolated fiber-optic lines would create better isolation.

With the ability to easily isolate and create specific light frequencies with the new LEDs, and sensors, I think it is time for this idea to be explored again.

In the advent of bitcoins, for ASIC mining, I think this concept "realized", would seriously help advance bitcoin mining, and have a mutual relationship with the rest of the advancements in technology, as a whole. It is about time we gave chips an upgrade. Going smaller is not much of an advancement.

The reason it would really help mining, would be the following...
1: You would only need two terminals for the chip. Positive and negative, for power.
2: You would need few micro-connections to the die. Only the two power, and two for the emitter/detector.
3: There would be almost no RF noise from the data, as it is not broadcast over wires.
4: There would be a great chance to split dies into smaller pieces, using internal optics, to assist in a wider thermal-footprint.
5: The chip could have thermal dissipation on both sides of the chip, with a direct internal "ground" leaf.
6: The heat-sink itself, could be the dies RF-shielding, and also the light-channel guide.
7: You have greater freedom of where the individual components of any "unit", as a whole, could be positioned. (As opposed to being limited to the PCB itself.)
8: More distantly, using RF-power, you could eliminate all external wire-connections entirely. (Using that empty space in the chip itself as the location of the wire-coil that capture RF-noise for power.)
9: The light itself can be the "timing", and the "data I/O", and even power, on smaller levels. (Solar.)

You could instantly feed every chip, all at the same time, the new data to be processed. You would not have to individually communicate or regulate communications. Same for the "results", which only one chip will broadcast, and each other chip can instantly prepare for new data, before being told. (Since they can openly see the others results. Unless they are all isolated with fiber-optic lines.)

So... any thoughts... questions?

Which individual chip "now", has the least demand for external supporting hardware. The block-erupter chips seems to have few external physical components required. Even if the external connections are limited, this still has a "first-step" use. (Stripping all the data-lines is the major thing. Heck, PCIe would be the size of one LED, if you removed the data-lines and redundant power-lines. See where I am headed with this now...)
12  Economy / Economics / Mine VS. Invest VS. Trade on: December 25, 2013, 07:25:54 PM
I was curious if anyone has done a side by side "speculative" and "historic" comparison of the following...

Mining BTC, with "standard" and "next-gen" hardware. (Including operation and purchase losses.)
VS.
Investing directly, by just buying coins, at various levels. (Including worst-case "top-peak" values.)
VS.
Simple trading, using realistic gains/losses, and difficulty. (Including small and large volumes.)

I do all three. Though I mine with cards that could only be used until the ASIC's arrived, which now mine scrypt-coins, to exchange for BTC.

This is what I have noticed...
My greatest return was from cross-trading alt-coins, which were traded after being mined, then ultimately cashed-out for BTC, near the top-peak. These are now being traded, to increase value and/or volume, for when the tides switch again, to a rising market.

My expenses from mining, including hardware (considered to be 100% loss, as I plan to run it until it all dies), was a rather large investment. Even though it was, and still is, hardware that is "best" for mining scrypt-coins.

Looking back, if I simply invested that money directly in BTC, it would have been about 100x greater. Now I have used those funds to purchase "next-gen" hardware ASIC's, and I am starting to wonder if I should have just kept the money to reinvest directly, Via trades.

The problem I see, with trading, is the growing volume becomes harder and harder to trade. Along with the generous, but still expensive, two-way trade-fee eating some of that reward. I could trade 2-20 BTC without issues, but now it is growing into thousands to trade, so losses become greater. (You have to wait forever for someone to snag-it, or attempt to pump/manipulate, to get a decent volume at the price you want to trade. Which does not always work when someone with opposing plans and higher volumes, knocks your efforts down a few notches.)

So, for the others who do this... what type of returns do you get? (Gains and/or Losses)

As per my findings, I may surrender to simply buying BTC directly, at (perceptive) lows. Then hope the highs I see (short-term), are the highs of the moment, and flip for an extra chance at a slightly higher return. (Which I realize actually impedes the growth of the initial investment potential, but it also helps limit the market from exploding out of control, which has as much of a negative impact, as it does for positive impact.)

Obviously, I would only use money that I still feel I can confidently risk the potential associated losses with the gains.
13  Alternate cryptocurrencies / Altcoin Discussion / For consideration, next-gen coins... Gen-3 on: August 03, 2013, 04:29:58 AM
To start-off, I would like to clarify what I believe are the two generations of coins here.

First, as I see it, Bitcoins, Litecoins, Feathercoins, Mincoins, Worldcoins, etc... are all POW (Proof of work) Gen-1 coins. You mine them, you find blocks, you make tx's.

Second, as I see it, PPcoins, Bottlecaps, and other POW/POS (Proof of work/Proof of stake) Gen-2 coins. You mine them, you find blocks, you make tx's, and you gain rewards for holdings through staked coins.

Third, as I see it, would be a coin that does additional work, beyond POW/POS, like Primecoin, which (forgive my lack of knowledge here on the coin) seems to be additionally generating or solving portions of prime-calculations, but with no actual reward for that work, directly. (Not to the miners, though I am sure the programmer is getting credit or use from the calculations.)

Or...

Third, as I see it, would be a coin that takes previous knowledge of other coins short-falls and strengths, and finds alternatives to subdue the bad and enhance the good, in a semi-dramatic way. (Eg, not just changing values of times, blocks, rewards, or logos.)

My suggestions, as poor as they are, are for Gen-3 coins. As I am sure the suggestions would surely disrupt the long-standing value and familiarity with existing coins structures.

##############################
Feel free to skip past my observations (Marked below)
##############################

To this, I have to add the following observations...
- Block-time targets of less than 1 minute are not good for the network. They do not propagate fast enough, leading to many avoidable and undesired forks/orphans. This is partly due to the nature of mining, which anyone can find 10 or more blocks within the first-find, well before the first block has traversed the net. Each new block is a new lotto-ticket, and a 1000000-diff block has as much chance of being found as a 1-diff block. Though it is more rare... when 10 DO get found, that instantly creates a fork on half the network. Half mining on the 10-blocks ahead, and half mining on the 10-blocks behind. Issue also related to retargeting block times...

- Block retarget times of a fixed-length of blocks, which is non-adaptive per-block, is bad for the network. With the known issue of coin-jumpers, this becomes more clear, mostly to any new or slower coin. Waiting for x-blocks before a diff-change after a coin has been mined to hell, into the ground, makes constant miners leave. They do not want to stay and mine a coin that once offered them 200 a day, but now only offers them 50 a day, which it will offer them for the next x-blocks. The diff-adjustment would be fine, if the coin had a constant x-miners STILL hashing away at that speed, but they all leave once they drive the diff through the roof and value into the ground.

- Block rewards that decay with more power, or are too high. This, I have mixed feelings about, because this seems to be one of the most abused and least knowledgeable areas of the programmers focus. Sorry, but there are only about three coins that I have seen, with true "economic planning" with relation to this major core element of the coins. They just throw values into the program and "hope it all works out". I only see two instances where this is sort-of true, but it is an illusion hidden by denial. lol. The three instances which have taken this major issue into consideration, just failed to capture the reality of what they intended to do, though they did it the best they could, without having to rewrite the whole program.

- Single-chains that allow you to MINE while disconnected from "the majority", creating forks and allowing, time-warp attacks, 51% attacks, stall-attacks, and various other exploits. Not to mention tx's being delayed, ignored, dumped, erased, because of some of the above issues.

- Block-spending and tx-spending, without consideration for age of tx-origin or age of block-origin. This issue goes beyond user issues, and into exchanges. Naturally any tx from any block that appears on "the chain you are on", which is valid, is accepted. However, if there is a fork, and that young-tx comes from a young-block on this fork... The TX has a good chance to be erased, along with the block it originated from. However, and older block, and tx, even if it was in the fork... would simply just move to the other fork after a correction. (I believe), as those coins were not generated in the fork, and thus, have the ability to move. Having the ability to say, when a fork is detected or not, no I will not give you credit for this exchange until the fork has resolved... due to that specific coin coming from a block that is not below the hard-code... yet, still accepting a coin coming from a block below the hard-coded block... would greatly reduce a lot of spending issues.

- Fixed IP's never "trying" for more than the ones you constantly connect to, without regard for others being closer, or attempting to "confirm" that the ones you are connected to, have the correct chain. This is another problem that aids to the issues above. There does not seem to be any "trying" for more connections. There is no "stay connected to one slow connection", while also "staying connected to the "one closest and fastest responding connection". There is no warning about, "multiple block-heights detected, mine with caution.", or "Which block-height would you like to connect to." (For instances where selection is critical, or can be used to choose not to RISK mining on a wrong chain.)

###########################
End of observations
###########################

My suggestions for consideration... and why... (Not that all suggestions are good, or worth throwing into one coin, or clearly extrapolated.)

1: Non-decentralized block-height tracking and block-height confirmation. (Every n-th block, you check if the block-height you are mining is correct. If not, you get a link to someone with the correct block-height. The correct block-height is simply the tallest one, that audits-out correctly, which has been reported or tracked by the centralized sources, and spread through the decentralized mining network of nodes.)

2: Minimum block-time of 1 minute, from last block. Forget diff-settings. The best diff submitted, after 1 minute from the last blocks time, gets the solution. (Waiting for 30-seconds of mining, before attempting to submit solutions. Submitting the best of what you found, while you race yourself.) If a solution is submitted, you have to beat that solution, before the minute is up. The first best solution after a minute, is the new block solution you want to build off of. (The other best solution is dynamic diff adjustments. Using the target of 1-min, after every block, it adjusts to compensate. EG, one fast block found in 0.5 seconds, forces a diff for the next block to be real high. About half-height, since this was obviously a "lucky shot", but someone-else may have a "luck-shot" on the next block, and it would again adjust higher, to compensate. If not, then it reduces by half, and half again, and half again, until the target of 60 in the hour have been reached.)

3: Mandatory minimum and maximum tx volume, and mandatory minimum and maximum tx-fees. Except for internal moves, within your own wallet. (See below.) This would be as follows... Assume the minimum unit is 0.00000001 (8 decimals). Minimum tx being 0.00001 (5 decimals), with a minimum tx-fee of 0.00000001 (8 decimals) or 0.1%. {for the minimum tx volume, that would be 0.00000001 or 0.1%} Also having a maximum tx volume of 10,000 to limit theft and make attacks that spend fraudulent coins, less of an impact. EG, they would have to create TONS of fake transactions, not one giant transaction of 100,000,000. This fee being deposited into block 0, which can never be withdrawn from, but is always tracked. Used to eat-up coins, so creation of coins can be off-set by high-volumes of tx's, and also for block-height confirmation, for auditing.

4: Wallet-2-wallet moves, being a zero-tx move. One that is done by the wallet, without instruction, to consolidate coins to one location or address within the wallet, to reduce dust. No dust transactions. If dust is detected, then auto-move the funds into one address, prior to sending, without the dust-fees. It is the wallet that made the dust, beyond our control, but we get charged a penalty for the system creating dust. That is not needed. Nor is a "tax" on moving coins from one address in a wallet, to another, for consolidation and dust-removal.

5: Multiple chains, linked as one. I would personally use 8 or 10 or 16 or whatever, related to the last digit of the "sending" account. This way an attacker would need that many MORE computers to attempt to actually attack a network. All transactions moving forward, first withdrawn, if available... then in the next up-coming block, the deposit is made, which matches the initial withdraw. Each hashed to the block below, of the same ID... 2, 2, 2, 2, 2... as a column, and that also hashed to the adjacent block... 2->3->4->... 9->0 (0 of the next row, from 9 of the last row.) Like a giant knitted scarf. Tongue All transactions moving forward, so a withdraw from account xxxxxxxxxxx7 going to yyyyyyyyyy7 would be deposited in the next block up, since withdraws should NOT be in the same block as the deposits, in any chain.

6: Secondary rewards, that are realistic and not ones that will impact the system in a horribly negative way. Holding coins makes less available, yes... but that artificially increases the value, which leads to dumping large holdings. Unlike a bank, where your holdings are lent-out to others, which the banks offer you a "return on that money you let them borrow"... Holding these coins should NOT have rewards, unless those holdings are destroyed, to be payed-back, from TX gains, in the future. (See above). Abundance would be reduced, and depending on the quantity you destroy, the more you should make from the tx-fees. (In this case, your destroyed coins would be added to another account in block 0, so you would get those back later, along with coins from tx-fees, rewarded by the system.) EG, if you destroy 1000 coins, and that is 1/10,000th of the total destroyed coins, then you get rewarded with 1/10,000th of the last deposited tx-fees, and that same number of coins which you destroyed. If 1/10,000th of tx's was 100 coins, you would get back 200 coins, 100 from tx-fees that others paid, and 100 of your coins back, leaving you with 900 destroyed coins left to gain from.)

7: Third party rewards, lets say encryption services... you, while generating hashes, are creating a cypher-key for something like a website, for use in private strong encryption, that is disposable. They buy coins from anyone, and attach "work" to those coins. If you get that block, and solve that work, you get that coin as a reward, which replaces one of the normally "generated" coins from "nothing". Though it is not a direct reward to YOU, it is to the network as a whole. Because that is one less coin in circulation, and that was one coin that someone earned, possibly you, which was purchased for physical money, for real work. (Unlike prime-coins, which I am sure the programmers are making a killing off, but not offering that reward to the miners or the system, by destroying coins, or reducing coins created from "nothing".)

8: Block rewards should start super small, and rise with network growth but rewarding less per user, only decaying in the event of abundance or over-growth, for stability. Starting with a reward of 2000, when there are 10 people, then lowering to 200 when there are 100 people, then decaying further to 20 when there are 1,000 people, and ultimately going to 2 for 10,000 miners, and then zero... is just freaking stupid. That is zimbabweism in reverse. Just as going in the other direction is just as bad, growing to keep everyone mining and getting the same reward, no matter how many people mine. (I don't think anyone has done that yet, but I imagine someone will.) Having a coin value that adjusts to the power of the network, increasing to allow nearly the same reward, but slightly less with more power, encourages growth and use. EG, rewarding 1 for 1 miner, 0.9 per miner for 10 miners, 0.8 per miner for 100 miners, 0.7 per miner for 1,000 miners, 0.6 per miner for 10,000 miners... until it goes to 0.1, then it gets dramatic and goes to 0.05, 0.025, 0.0125, etc... With supplemented "coins from nothing", coming from "real work" or "transfer fees", to keep the "coins from nothing", limited. If there are more miners, then there are more people trading. If the price is not jumping all over creation, matching the production, then there will be more people trading. The more people trading, the more fees, the more fees, the less coins are created. That balances out. (If not, you make slight adjustments to the values... SLIGHT... ones that will not threaten transactions or mining, in a seriously negative way. EG, through public consensus.)

9: Reduce the need for pools. Solo-mining should be possible, at any point in time. Coins that spent so much time "trying to decentralize" and "trying to beat the man"... seem to only favor "centralized exchanges and pools" and "only favor the MAN with the biggest GPU army." Kind of defeats the purpose of the coins, almost as much as dust-fees and killing micro-transactions, which was the whole purpose of bitcoins in the first place... for micro-transactions. They didn't put all those decimals in there for fun. Much of the above, mostly #8, goes towards "solo mining", and it also goes towards coin-hoppers. If they hop, they get less. If they stay, they get more. Those that stay, don't get raped by the hoppers. The more the merrier, pools or solo.

10: Lock and hold transactions. This is for traders and exchanges and for escrow use, mostly... and for "trusted" stores that would like to reduce transfer overhead. You make a tx, but the money does not actually leave your wallet. It remains in your wallet, unlocked only to the recipient. They don't have to take it until they need it, or they can unlock it back to you, or forward and unlock it to a third-party. EG, You want to trade it at an exchange. You unlock it to them, they see it is available, but they don't take it until you actually trade it. Then, they can forward it to the new owner, only loosing one transfer fee, not two transfer fees. (One fee depositing it to the exchange, one fee depositing it to the new owner, after they withdraw it.) Also, the network has one less transaction to deal with, and if you decide not to trade, the exchange has the ability to just refund your coins back to you, without a fee, or with only one fee. Same for an escrow account, where you unlock it to the service, and the service unlocks it to the recipient, in the event that both parties are in agreement. Shops can leave funds there, returning them without loss, if they decide they can not send an item, or in the event that they legally have to return the funds due to shipping or other issues. But, for all intense purposes, that unlocked money is out of your wallet control, and in control of the new owner you unlocked it to. It is also your proof of payment, and proof that they got it, as it would indicate "collected". Like a receipt system, without the other party having to actually be online with a wallet, to give you a receipt, or without having to clutter the network with receipt transactions returning to the sender.

11: This one is a little harder... but... if the rewards were offered to "the best 100 submitted solutions", that would greatly increase the participation of those who solo-mine, and also make it nearly impossible for an attack, and make any attack easy to detect and reject. Spreading the wealth, demanding that only one "best solution per wallet" is submitted would also thwart any pools from mining, or massive coin-hopper individuals with uber solo-mining ability from disrupting the network. Keeping the "reward solutions" separate from the diff-1 tx solutions, would allow reward solutions to be able to be removed after every hard-coded block. (Since those solutions were all confirmed by 1000+ audits, and are no longer needed as proof of work to be used in the chain, only the short and simple diff-1 solutions that locked the tx-blocks are needed at that point, which holds the 100 accounts that submitted solutions.)

############################
End of my thoughts for consideration... You can wake-up now...
############################
14  Economy / Currency exchange / sold on: June 17, 2013, 08:13:09 PM
I am trying to buy MNC (MinCoins), but having a difficult time getting BTC or MNC...
15  Alternate cryptocurrencies / Altcoin Discussion / Anti-Orphan (51%) attack... (Natural or actual attack) on: June 09, 2013, 05:34:39 PM
I am just thinking out-loud here, and I may be completely off on this possible suggestion... (as always). Tongue

But...

If the wallets/servers/programs were setup to only allow a stack of 8 blocks, before they have to "get a new block, with a non-ME header"... That would ensure that 51% was not possible, would it not? EG, If I mine with my army-o-miners, and start a fake-block and hit block #8, the network will just reject the addition of block #9 with that same "miner account" as the first transaction. Thus, no-one "adding to the fake chain", which is causing all the "valids from the real chain to become an orphan".

Going a step further... If you force a "reject" of a double-block mined by the same "wallet"... That would auto-round-robbin the entire chain. Thus, once you "hit a block", you have to wait for anyone-else to have found the "next block", then you can start mining again. (That would also force large single-wallet pools to create multiple wallets, thus, again, ensuring that no 51% attack was possible, unless there were only two miners/wallets running at the same time.)

The chances of hitting two blocks in a row are slim. The wait-time for a new block to be available is not a major loss, and ensures that even less losses from 51% and orphans.

(NOTE: A maliciously created server/wallet that "allows" these blocks to happen, would not function when the others have these limitations set in place. That would cause the fake block to continue to be mined alone, never getting past that 8th block. He/she can mine away all day, nothing would ever confirm.)

Also, why is it when an "orphan" is found... do the wallets/servers not "grab another chain", that is not orphaning... or "force a chain revalidate", to detect and kill the fake chain, before it grows. (Kill = ignore it as a group/network.)
16  Economy / Speculation / Here comes the hell-storm... Massive cash-in... on: June 02, 2013, 08:34:02 AM
Just when you thought the market had a stable value... Boom... someone with millions if holdings goes and cashes out, all at once.

Tongue

Good time to buy!

The sky is falling, the sky is falling! No, just the value of bitcoins. xD

Almost up to 20,000 BTC cashed-in... What is that, like $2,500,000 that was cashed-in for about $125/btc...

LOL, they are waiting for everyone to raise the price again... so they can cash-out on a second run, with less losses. You can see them slowing down as they knock the value down.

Smart, they cashed-out on all the markets at once... Instead of just dropping one market, they hit them all. lol. I smell ASIC dust in those transactions.
17  Bitcoin / Mining software (miners) / log-in to multiple pools... CGminer on: May 25, 2013, 05:34:07 AM
I know the program has the ability to switch pools, but I am trying to log-in to multiple pools at the same time.
EG...
Pool A, logged in, doing 50% work
Pool B, logged in, doing 50% work...

So that in the event pool A stops responding, the program will do this...
Pool A, dead, doing 0%
Pool B, logged in, doing 100%

Until the pools is restored, then it would return to a split-load... (Or whatever proportion I have set for that pool.)

(As opposed to using a separate machine on each pool, which has to constantly pool-hop... thus, loosing out of actual earnings.)

Because having a foot in every pool, keeps you closer to 100% luck. (Well, about 80%, because 20% of the pools will not let you in.)

I thought this was how load-balance worked, but I am not seeing it do that. It is still only picking one pool in my setup. Am I doing it wrong?
18  Economy / Digital goods / Just a warning... Game bundles from video-cards... on: May 23, 2013, 09:05:15 AM
AMD is having "issues" with many pre-claimed game-cards. (They may even just say it is claimed, just to have you confirm an actual purchase.)

The issue is two things...
1: There is a game-code generator in peoples hands. They are selling "valid" codes that are not "real". (Valid = works when you punch-in the numbers. But because it is not real, when the actual owner claims the code, you loose the game.)
2: Codes can be "seen" before they are scratched-off. People are reading the codes, selling them, and then activating them for themselves, or for another person. That invalidates the code they sold you.

What AMD is doing to resolve this issue...
1: Make all codes invalid.
2: Make the customer contact them for manual submission of codes.
3: Make the customer provide proof of sale, and item, and ticket.
- Photo of billing invoice (You can block the personal information, just not the sales ID)
- Photo of shipping invoice (You can block the personal information, just not the item ID)
- Photo of actual purchased item. (UPC and item codes from bottom of the boxes.)
- Photo of actual scratched card, and the PLUS-CODE under the proof-of-purchase ID from the UPC symbol. (The Plus code is what validates the scratched code. Not the UPC symbol, those are not unique to each card-code.)

Please have these photos sent to those who are making a purchase for your game-code cards. They will need it, and will come back and complain if they can not register, and are told WRONGFULLY, that the game-code is already registered.

This comes directly from AMD's mouth. They DO NOT CARE that you are reselling the free game-codes. But they want sellers and buyers to know that this information WILL BE REQUIRED for ALL future game-codes, due to the above stated issues.
19  Bitcoin / Development & Technical Discussion / ISAWHIM on how bitcoin should work on: May 22, 2013, 02:23:05 AM
Just a thought...

Since you guys refuse to simply "only download portions of the chain related to THIS new wallet"... (or the portions related to an older one, if restored.)
EDIT: Also, don't create a KEY until we tell you to... you create keys for no reason... we may be trying to restore a wallet, and that key is now wasted. Has no use, could have been someone-else's key. If we use it, and THEN choose to encrypt, you make it sound as if any coins in the wallet will now be lost, on that key... Why, that is bass-ackwards. Tell us to create a password, before giving us a key/address. Only IF we tell you we want to MAKE a wallet, not RESTORE or ADD a wallet that we are trying to fix.

Can you then implement some simple standard compression for the chain. Only uncompressing and "adding to OUR database", the transactions related to us.

Here is the kicker...

The compression of historic block segments... compress it AFTER a two-part process.
1: Split the block data into EVEN and ODD bytes. (0A0e0P020E0r) = [0000000]&[AeP2Er]
- That allows the common RLE/zip/gzip/arj/rar etc... to compress better. "0x" is a common occurrence in ALL files. As are "xZ"...
2: After initial compression, apply another compression on the original, with a randomly selected method...
- bit-shifting all data x-bits
- CRC or SHA or MD5 key (OR, AND, XOR, NOT, NAND...) Altering the values in a reversible way, with that key...
- Then try the available compression again. The smaller of the two files will remain, and be broadcast back out. The larger file will not be saved, and never again become propagated.

Over time, the entire database will at-least be compressed one level. Followed by repeated random attempts to "alter the data in a restorable method", to yield smaller and smaller chunks the more it is used/loaded/saved/shared.

This would NOT be done to every chunk, by every user. Simply do one chunk at start-up, and one upon receipt of a new block, optionally (instead of a "fee", or in addition to a fee.) do one with every "free transaction" sent out (Not compressing the transaction, just attempting to compress an uncompressed or "large" block randomly from the hard-drive archive of blocks.

(Note, you would be surprised how many zipped files can be compressed down to 50%, or 10%, after simply doing the even-odd split, and a simple bit-shift. Files that normally actually become larger once zipped, due to them not having any apparent pattern within, to compress... like images and databases.)

The resulting block compressor would record the method (CRC/SHA/MD5) key-used {dkfs9d7f9sSTD8sd5} and RATIO to ORIGINAL-UNCOMPRESSED. Then the actual data to be manipulated.

Reversing the process should be rather fast, and would not need to be done on the whole archive. Just on the parts that pertain to the wallets first index, if that is known. (Could be gotten from any block-index explorer.) Provided that segments record the "continue-from" key, which is the block-segment separator. (The "result" from having previously processed from the original gen block, up to the last processed block-segment separator.)
20  Bitcoin / Development & Technical Discussion / Coin-eater... on: May 18, 2013, 08:24:01 AM
Just for curiosity...

What measures are in place to stop a "miner" within a "pool" from doing this...
- Mine away all the useless shares (Which takes no effort)
- Don't actually mine for any coins... (Thus saving a lot of power, and being able to mine multiple pools at once.)
- Collect a percentage from the useless processed shares in the pools.

or...
- Mine away in a pool...
- Use your own wallets server-id, instead of the pools id... Thus, when you find a block, you keep it... and still get rewards for shares from the pool. (Only using your ID on the blocks, not the shares, which are returned.)
- Mine multiple pools, processing useless shares, while collecting the found blocks for yourself... Thus, ensuring invalid blocks are always returned to the pool, too late, after they have deposited into your wallet.
Pages: [1] 2 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!