|
In a A-vs-B game where the criteria is a hash of the combined transactions, it should be perfectly fair. Just don't reveal either txid until you have both in hand (reveal a [randomly] salted hash if you want to prove that one party or the other has made their move).
|
|
|
|
We have a long list of blocks in the "Strange Blocks" list on blockchain: https://blockchain.info/strange-transactions. That list goes back to late May, and a cursory glance suggests every one of p2pool's blocks appears there. It looks like one of us isn't getting paid  Since this is always at the bottom of each transaction list: 1Kz5QaUPDtKrj5SqW5tFkn7WZh8LmQaQi4 0.0123456789 BTC
Unable to decode input address 0 BTC Does that mean 1Kz5Q is the one not getting paid? Are those coins redistributed among the miners (I'm not sure they could be), or just lost? Should we worry about this at all? No, p2pool shares are regular bitcoin blocks. The generation transaction includes a bogus transaction to keep track of internal state (actually, a hash of the share chain). Incidentally, the current protocol actually had a change to that bogus transaction to make it more network friendly. |
|
|
|
|
And if that isn't enough, bitcoin has a bunch of magic numbers in it. Most of them seem to have been picked because they were round numbers that fit into a broad range of values that were "good enough".
Consider that the average block time could have been chosen anywhere from 1 second to 86400 seconds. 1 second is clearly too short for network convergence. 86400 seconds is clearly too long for effective commerce. Between those two extremes is a broad band that is "good enough" for both, as well as regions that are questionable for one or the other. Would 60 seconds be too short? Probably. 120? Maybe. Would 3600 seconds be too long? Probably. 1800? Maybe.
And the various magic numbers interact. For example, the block time and the subsidy function come together to set the generation curve.
Satoshi was either very lucky, or very thoughtful. The numbers he picked all came together to give us a workable system. The success of the system gives a very strong (quasi)anthropic argument: we are here discussion the merits of various key values because the system works well enough for us to care about it. If he had chosen poorly, bitcoin would not have taken off.
And finally, consider litecoin. Litecoin has a 150 second block time. This number appears to still be large enough that convergence isn't a huge problem. But litecoin does not appear to be used for commerce other than buying and selling litecoins, so a shorter time seems to provide no commercial benefits. If the long block time was holding us back, the world would have beaten a path to litecoin.
|
|
|
|
This exact scenario happened with terracoins a few month ago. Basically what happened was that someone pointed an ASIC at terracoins and this push the difficulty EXTREMELY high, and then they stopped mining, leaving the difficulty extremely high for 8 days and no terracoin transactions were able to be processed because it took an extremely long time for the remaining miners to process any blocks.
This has been happening to scamcoins (or "alt"coins, if you prefer) for years. There are plenty of threads from 2011 and 2012 discussing this. I'll summarize them for you, since you don't seem to know how to search for them. 1. Most of us think that a sudden major drop in hash rate would be a symptom of the effective end of bitcoin anyway, so there isn't much point worrying about it. 2. Mechanisms to quickly reduce difficulty require an asymmetric difficulty adjustment system. 3. Asymmetry in that system is a huge security problem. It lets a small miner create fake chains to fool nodes that are booting for the first time, and it lets a (relatively) large miner dominate the entire network and manipulate it to his liking. 4. #3 is not theoretical. Artforz pwn3d one of the original scamcoins right after they patched to "solve" the problem described in the part of your post that I quoted. |
|
|
|
Is this the best place for you to get an answer?
I believe it is quite good. As far as I know in many situation only way to get Yifu attention, is to publicly show that Avalon business is not much better then BFL... Really? This is a terrible place to contact them. Just like everywhere else. Tickets are ignored. PMs are ignored. Emails are ignored. Even phone calls are ignored. The next step for me is a certified letter from my lawyer to their registered agent. |
|
|
|
Note that I'm looking for options short of invoking the legal system. I'd never collect a civil judgment, and all a criminal complaint (grand theft) would do is ban Yifu from attending conferences in the US.
Have you tried calling him? That aside, IIRC Bitsyncom LLC. is an American company and Yifu resides in New York. Yes, I've tried calling him. I've even left voicemail. That voicemail was even polite and factual, which is surprising when you consider how pissed off I am. Looks like Bitsyncom is a Nevada LLC. https://nvsos.gov/sosentitysearch/CorpDetails.aspx?lx8nvq=ozwghIfOnmFj64qH4nYDaA%253d%253d&nt7=0With that in mind, I'm setting up appointments next week to discuss the matter with my attorney, and with the local prosecutor. |
|
|
|
|
You really shouldn't mess with the file directly. Treat it like a black box and use the proper tools (bdb).
+1 to anyone making proper documentation of the key/value pairs though. I can think of a number of useful utilities that could be made more easily if people knew how.
|
|
|
|
|
Yes, the root problem that you can't omit a leading argument. All three of the parameters are optional, but if present, they will be interpreted in the order listed. This may not be obvious to people that don't program much, so I'm pointing it out to future searchers.
The default account is named by an empty string. If you look at the bitcoind source code, you'll see that the account name defaults to '*', and is overwritten with the first argument.
|
|
|
|
This example says that you need to satisfy a multisig with two keys, until the transaction reaches a certain depth, when it can be redeemed by one script. The idea is that it removes the risk of the counterparty disappearing by giving the first guy the ability to reclaim his money in the future.
To be clear the protocol implemented now is that a time-locked refund tx is created when tx1 is created that returns the money in the future, but ultimately there will always be a short time window where the counter-party can vanish leaving the funds locked. Jeremy Spilman's solution was to have the counter-party also include some funds, so that their funds would be locked as well so the counter-party has strong incentives to not allow this to happen; I'm not sure what bitcoinj has implemented. I was browsing the forums while ignoring a boring presentation. I didn't read the whole exchange in detail, just enough to confirm my guess at the function of the script presented. As you may have noticed from my post, I'm not as willing to handwave over adding state to transactions. I follow the argument about checking history as well as confirmations. I think that it might be too complicated to make reasonably accurate estimates of security once branching is added. |
|
|
|
Sorry I don't understand <height + n> OP_DEPTH OP_LESSTHAN
IF 2 PK1 PK2 CHECKMULTISIG
ELSE PK1 CHECKSIG
ENDIF OP_DEPTH "puts the number of stack items onto the stack." What's its function here? No, it puts the current depth of the transaction into the stack. It makes the script stateful (often considered bad, see the discussion on the dev list). This example says that you need to satisfy a multisig with two keys, until the transaction reaches a certain depth, when it can be redeemed by one script. The idea is that it removes the risk of the counterparty disappearing by giving the first guy the ability to reclaim his money in the future. |
|
|
|
For some reason I got two payouts on the last two blocks (one normalish sized and one super tiny)?
Also, the payout on my node looks way low:
Payout if a block were found NOW: 0.01026656 BTC to ***. Expected after mining for 24 hours: 0.134 BTC per block.
This is running at ~7.5Ghash for well over a day, so it should be closer to the 0.134 value. It seems like the "payout if block were found now" is actually the smaller of the two payments that I got for the last couple blocks? What's going on here??
You have two different addresses with shares in the current share chain. And you can only expect the 24 hour payment estimate to match the actual payment you get from a block when the expected time per block is 24 hours. |
|
|
|
I see a lot of 2011 and 2012 threads getting new posts, usually by relatively new users making lots of short (one or two line) posts.
Giving a permanent -10 penalty to activity rating would make this activity useless for people hoping to boost their activity for PM or trust purposes, but not be overly punitive for people that really think that an old thread deserves a new read.
Also, I mentioned it in a different thread, but figure it is worth repeating here. Ignores earned should deduct from activity, either actual activity or effective activity used for spamming.
You're assigning some arbitrary value to that number on the left there again. Like people did with the postcount. Which was the reason why postcount got removed in the first place. Here is a Public Service Announcement: Penis size is unrelated to either activity or postcount size. No one cares about activity or postcount size. If you DO care aout activity or postcount size nonetheless, please stay calm, sit down in a quiet place and wait for help to arrive. A unit of helper monkey will be dispatched as soon as possible. You might not have gotten the memo, but the ability to send PMs is linked to penis size activity. |
|
|
|
|
I see a lot of 2011 and 2012 threads getting new posts, usually by relatively new users making lots of short (one or two line) posts.
Giving a permanent -10 penalty to activity rating would make this activity useless for people hoping to boost their activity for PM or trust purposes, but not be overly punitive for people that really think that an old thread deserves a new read.
Also, I mentioned it in a different thread, but figure it is worth repeating here. Ignores earned should deduct from activity, either actual activity or effective activity used for spamming.
|
|
|
|
Why do people with shares in SD suddenly feel compelled to turn them into fiat?
Exactly. This idea has been almost the sole reason for the sudden price drop, and I think that's simply not the case. To a first approximation, everyone talks their book. They start with a conclusion and then try to justify it. Everything in the speculation forum is either post-hoc logic, or voodoo (chart analysis). |
|
|
|
i dare you give me a piece of c code(10-20 lines) that i can't explain. Okay, I'll give you an easy one. How about two statements? [...] An implementation of f() constructed from your English description must produce identical results for all possible val and l on the range 0-31 inclusive. a function f is given 2 arguments, one integer named l and and a 32-bit unsigned integer named val and returns a 32 bit unsigned integer. if the value of l is strictly larger then 16 we reassign the variable val to the sum of: val shifted l minus 16 to the left(or is it right? im left-right confused!) the lower l minus 16 bits of val plus 2 to the l - 16 power minus 1, shifted l - 16 times to the left if the value of l is less or equal to 16 set val to itself shifted 16 - l times to the right return val But what you're not understanding the function. All you're doing is repeating it word for word. He meant you couldn't explain it colloquially. i dare you give me a piece of c code(10-20 lines) that i can't explain. Okay, I'll give you an easy one. How about two statements? [...] An implementation of f() constructed from your English description must produce identical results for all possible val and l on the range 0-31 inclusive. but no i have no idea of what the code is doing, but it seems like some insanely optimized bit twiddling computation, its probably a estimation of some mathematical function. I really dislike bit twiddling magic, its just as incomprehensible as brainfuck or APL. hey look, gmaxwell delivered and you failed. its a part of a code that computed a overestimate of log_2 An overestimate of log 2 is easy. It doesn't need two parameters... |
|
|
|
i laugh at people who think they are math experts.
there are 2 (followed by 160 zero) possible combinations.. some of you naively believe that if you start at 1 and count upwards it would take 2(followed by 160 zero's) to find a collision.
this would only be the case if the addresses were made in lets say Hex of all F's..
but in reality ITS RANDOM
the addresses can be ANYWHERE between 1 and 2 (followed by 160 zero's).
meaning its just as likely that a randomiser picked 10 as it would pick 100,000,000,000,000.
with an estimated 84mill addresses being used, there is a chance that one of these 'used' addresses is randomised in the low range.
put simply
its random. they are not all clumped up at the far end of the spectrum.
to add to that depending on the degree (amount of significant figures) were used before hashing and converting, can far reduce the potential 'luck'.
this is why i feel the bitcoin foundation are rightly so in adding the new feature for version 0.9 of bitcoin-QT to not require random addresses per transaction.
Just FYI, 2 160 != 2*10 160. Also, 'random' is a double-edged sword. What you gain by having keys fail to cluster near the far end, you lose by having to check each one. |
|
|
|
it makes it nearly impossible to create a alternative client, when the "standard" mutates all the time. bitcoin needs diversity in clients.
Would you like to only be able to use internet explore? sure it would work good. but really?
The standard does not mutate all the time (though I do agree client diversity is a good thing). It mutates with every commit to the satoshi client repo. Code is not a standard. No, it really doesn't. Sipa's patch last year changed how this particular implementation behaves, only. It was not a change in the protocol. The change was not binding on anyone else. P.S. The standardization thing is discussed in endless detail in many other threads. Please read some of those before posting again. You have contributed nothing new to the debate; even your pointless personal attacks are reruns. |
|
|
|
assert 1 == ssl.ECDSA_sign(0, hash, len(hash), mb_sig, ctypes.byref(sig_size0), self.k)
return mb_sig.raw
I believe this code is wrong. ECDSA_sign takes a pointer siglen for the length of the buffer. The reason it passes a reference there and not a value is because it writes the resulting length back to it. Otherwise there would be no way to know the length other than the maximum since, obviously, char * doesn't encode a size. Your code appears to do nothing with the returned size. This is wrong, and it means you're reading past the end of the destination array. Be glad the additional space contains only zeros and not your private key. |
|
|
|
@kokjo: mind sharing the code how to embed the OpenSSL-created signature into a sigScript? I expect the problem is caused by how you wrap/pad it, rather than with the signature itself.
sc = [script.OP_PUSH(sig+"\x01"), script.OP_PUSH(key.publickey)]
tx.inputs[0].script = script.encode_script(sc)
as said before its the statoshi clients problem, not me generating bad(wrongly padded) signatures. i already have tracked down the problem in the satoshi client. I decoded the transaction you provided by hand. It is wrong, and I told you where it was wrong. The satoshi client is only broken if you got that hex as the output of signrawtransaction. |
|
|
|
|
Show Posts
