|
Only Full Members and up can have avatars. To get to full member, you need to post (but not spam) to increase your activity. You can only earn 14 activity points every two week period.
Also, please use the search function, this question has been asked by others literally thousands of times. Just search if you have a question and if you can't find the answer, then ask.
|
|
|
|
Coming to the topic, whats Ognasty's 1/2 BTC suggestion by the way? Didn't have the time to go through the whole thread, but it seems well accepted.
tl;dr pay 2 BTC to get a special rank that can have a signature, everyone else either has super stripped down signature or none. |
|
|
|
Thank you all
Then when I feel the buyer is kind of shady, I will tell him to add a high enough transaction fee, I read somewhere about 40 satoshi/byte is more than enough, and wait for a first confirmation before sending.
For the fees, you can check https://bitcoinfees.21.co/ for the current fee state of the network and choose what is best for you. IMO you should always wait for one confirmation before sending because sometimes users will pay a low fee accidentally and the transaction will disappear from the network so you won't get your money. |
|
|
|
To expand, when you have the "signature" part of a transaction, in order to validate it, you need to concatenate the output script that it's spending.
So an output script might be:
OP_DUP OP_HASH160 XXXXXX OP_EQUALVERIFY OP_CHECKSIG
--snip--
OP is not asking about p2pkh outputs but rather p2pk outputs A p2pk output looks like When spending it, the input script is just The stack becomes <signature> <pubkey> OP_CHECKSIG OP_CHECKSIG is the only action here and it checks that the signature and pubkey matches. Because the pubkey is already pushed to the stack by the output script, there is no need to include it in the input. |
|
|
|
Correct me if I'm wrong.
K is the RNG variable.
Based on your privkey and K, you come up with a signature. Using the same variables, there are only so many combinations you can come up with. Meaning that an RNG can stumble upon previous combinations.
Simplified:
Imagine your name. That is your private key. The place number of each letter of your name (a=1, b=2, etc) is added and multiplied to a number rolled on a die. There are only 6 outcomes. Signatures are the same, but with alot more than 6 outcomes.
That is true, but considering k is a large number (256 bits IIRC), the probability of randomly selecting the same number twice is extremely low. |
|
|
|
In block 200'000 I notice two strange transactions.
Usually input script is signature + 33 or 65 key. These have signature alone
Those spend pay to pubkey outputs. Since the previous output already has the public key in it, and pushes it, there is no need to push the public key as part of the input script.script |
|
|
|
Unfortunately, one of the most notorious signature campaigns, (the one I am currently involved in at the moment,) has the help of a Global Moderator, and it is still heavily abused. Poor guy has to keep playing wack-a-mole and have hundreds of accounts banned from the campaign, and the spammers still crop up like so many weeds.
It's why campaigns need to set the entry barrier high as well. Don't accept low ranking members and check the post quality of those applying so that you don't have to keep kicking people out. Only in Bitcoinland do people complain about a 20 month ROI. Rest assured that signature campaigns would have to pay more.
I'm fairly inexperienced when it comes to ROI'ing on things, so I don't have anything to compare that to. It just seems like a lot of time and a lot of posts. |
|
|
|
I like OgNasty's proposal, although I do agree with others that 2BTC is a fairly high barrier. With my current sig campaign, that would take me 20 months to earn. I think something between 0.75 to 1BTC is more reasonable and more attainable.
I also think that we need to be harsher on campaign managers to enforce their rules more strictly and have stricter rules about spam. I think that punishing managers for their campaigners' spammy behavior would be a good incentive to get them to be stricter. Perhaps giving out bans to managers if their campaigners are being spammy and nothing is done about them after they are informed of spammers.
The amount of course will have to vary based on the USD-BTC exchange rate. Signature campaign payments are linked to USD and of course, this payment would have to be linked to USD as well. Not all campaigns are linked to USD. Many campagins, such as betcoin's, are Bitcoin only. This forum is Bitcoin only. I see no reason as to why the rate of the payment should be linked to a fiat currency. If it were to be linked to something, I would rather that it be related to the campaign rates and only change when campaign rates shift dramatically, as they did with the last big increase we had a few months ago. |
|
|
|
|
I like OgNasty's proposal, although I do agree with others that 2BTC is a fairly high barrier. With my current sig campaign, that would take me 20 months to earn. I think something between 0.75 to 1BTC is more reasonable and more attainable.
I also think that we need to be harsher on campaign managers to enforce their rules more strictly and have stricter rules about spam. I think that punishing managers for their campaigners' spammy behavior would be a good incentive to get them to be stricter. Perhaps giving out bans to managers if their campaigners are being spammy and nothing is done about them after they are informed of spammers.
|
|
|
|
Well.. I wonder what my seed belongs to then..
Maybe Multibit HD or Electrum. |
|
|
|
I use Multibit (classic).
I want to check that my seed works and will recover by btc in the event of failure.
How can I check my seed works?
You can create a new wallet and restore from that seed. If it works, then you will see the same addresses. However, Multibit classic does not have a seed. Multibit HD uses deterministic keys which has the seed, but Multibit Classic does not. |
|
|
|
I'm not aware of any wallet that implements multisig escrow. If people want to use multisig they have to manipulate raw ECDSA keys. Not to mention payment processors like bitpay are not compatible with multisig at all.
Far from complicating the process, I'm advocating making it simpler by creating good UIs for multisig escrow.
Armory has a GUI for multisig, but you still have to enter the raw public keys. Unfortunately, this is really the only way to do that since addresses map to the hash of the key, and not the key itself. Perhaps there can be a way to lookup the public key of a previously used address, but it wouldn't work if the address is new. |
|
|
|
Probably a bug in the accounts system which is slated for removal anyways. It is deprecated and no longer supported.
hope it will be fixed soon. Bug is appear in current 0.12.1 version. But maybe it's not a bug, and feature which is worse. It probably won't be fixed. The "fix" will be the complete removal of the account system, something that is planned to happen soon. Anyways, it is still probably a good idea to create an issue about this on github. Did you see this behavior in previous versions. |
|
|
|
"Then 65 bytes are pushed. This pushes the pubkey of the address this output is for. The last byte is OP_CHECKSIG."
Data block 65 bytes is before opcode OP_CHECKSIG
Those 65 bytes are the public key for the address. It is a pay to pubkey output. |
|
|
|
|
Probably a bug in the accounts system which is slated for removal anyways. It is deprecated and no longer supported.
|
|
|
|
This explain a bit. How locate useful data? The block data before OP_CHECKSIG?
What do you mean "block data before OP_CHECKSIG"? |
|
|
|
I have posted before, but now all i get is the wait 360 seconds message even after waiting 30 mins still the same.
Any reason i could post, but not anymore?
Every time you try to post, the timer resets. |
|
|
|
My example:
First transaction of block 200'000:
bitcoin-cli getrawtransaction dbaf14e1c476e76ea05a8b71921a46d6b06f0a950f17c5f9f1a03b8fae467f10
This is a coinbase transaction so it is special. Conbase transactions are always the first transaction of a block. I don't know why in first script first opcode is 3? Pushes 3 bytes to stack? why?
It pushes three bytes which is the block height in little endian format. The remainder of the script is arbitrary data that the miner includes in the script. This usually is where the extra nonce goes and the miner will put info to identify who mined the block. Second script : 0x41: pushes 65 bytes? but while script has 65 bytes
The script is 67 bytes. Then 65 bytes are pushed. This pushes the pubkey of the address this output is for. The last byte is OP_CHECKSIG. |
|
|
|
What is the difference between normal and merchant? I can't get it
Normal will display all of the information for the account. Merchant hides some of it to prevent buyers from knowing what the actual account being sold is but it still allows them to see some stats about the account being sold. |
|
|
|
Maybe is possible to avoid reading indices?
I first read headers of all block, next I compute hash (how fields use specifically to compute hash besides nonce?, next I will build chain tree and select the longest chain.
Sure, you can do it that way too. Each block is the 4 byte magic bytes, then the size of the block, then the block in raw format. The first 80 bytes is the header and that is hashed using sha256d. The output is then represented using little endian. The rest of the block is just the transactions. For full info on the serialized format, see https://bitcoin.org/en/developer-reference#serialized-blocks |
|
|
|
|
Show Posts
