It's actually an option in SMF, there's no limit though, it's either on or off.
A tiny bit of modification to the source could change that. It's actually an option in SMF, there's no limit though, it's either on or off.
So either you see no quotes or all quotes? That's pretty crap tbh, this forum is huge. I'd be ready to donate to get rid of those multiquotes... And I am poor as shit. No, it's "No nested quotes or nested quotes", quotes are always enabled. |
|
|
|
Address is 160 bits, public key is 256 bits (Compressed public keys are 33 bytes[...]. The older uncompressed keys are 65 bytes ( Source)), correct? This means there's obvious duplication. Now, question is:- If someone receives money on address A, then uses keypair B to spend the money on address A, then receives some more money to address A, can keypair C (Assuming RIPEMD-160 of the public key hashed to the same thing) then spend the money on address A, even though keypair B has already been 'registered' in the blockchain? Is there any validation? Or, is it simply "looks good, let's go"? Obviously, this isn't a threat as the chances are insanely low, but, just wondering. |
|
|
|
Amazing,
if you buy into MT Gox you have a:
90% chance that you won't see 100% of your money
80% chance that you will see at least 10% of your money
5% chance that you will see any profit
and a
100% chance that you will have learned a valuable lesson.
♫ This is ten percent luck, twenty percent skill ♫ ♫ Fifteen percent concentrated power of will ♫ ♫ Five percent pleasure, fifty percent pain ♫ ♫ And a hundred percent reason to remember the name! ♫ |
|
|
|
How do I know? I checked. Simple as, your transactions are public, it's a P2P network, simple as. I have downloaded all of your transactions, ever. As for people who post addresses in their signatures, most (At-least, me), change it after every donation within a few hours.
haha that is what I asked you so you looked @ my address :p i thought you were stalking me every now and then ..!  so you do that for every address you see or mine was special , because i don't think so. Around 50% of addresses I look at, percentage is higher when I'm bored. |
|
|
|
Why are you reusing addresses?
that may be because i don't have enough funds in btc wallet that i'll think about its security as of now.. but yeah you got a point..!  but how do you know i use this address lot :pand same thing applies same thing goes for members who flaunts there btc addresses in there signatures thats vulnerable too. And i think we must not take this thread off topic, and just try to keep it fun one... if you have any suggestion PMs are welcomed Thanks BTW How do I know? I checked. Simple as, your transactions are public, it's a P2P network, simple as. I have downloaded all of your transactions, ever. As for people who post addresses in their signatures, most (At-least, me), change it after every donation within a few hours. |
|
|
|
Found This in yahoo answers  i like these alot. yahoo answers is full of trolls. send me your bitcoin address n will send a tip tanks Thanks for acknowledging spent 15mins to search and 2mins to edit[yahoo ads under question] BTC: 13AxqUHW2AD6G33Szm5Vsvmfn5CpiED7ip Why are you reusing addresses? |
|
|
|
Yes, Armory will not show you any tx that don't satisfy "isFinal()" conditions. A transaction is considered not final if: (1) Locktime+OneDay is in the future (2) Any TxIns have non-0xFFFFFFFF sequence numbers Why is one day added to the locktime? Because I was being ultra-conservative, and wasn't 100% positive that I was handling the timezones correctly (which would open up an attack vector to pay someone using Armory then retract it). Therefore it should show up by tomorrow. I would've been smarter about it, but I didn't have the patience to go hand-craft some transactions and mess with my locale to test the timezones, just to handle a case that 99.99% of users will never hit. Congrats on being in the top 0.01% So, it will appear tomorrow in my transaction list instantly with however many confirmations it has 'n all that? Personally, I feel a single confirmation should overrule it all, shouldn't it? My understanding is if it's got a single confirmation, and, that block isn't invalidated/orphaned, then, that transaction can't be taken back, or, am I misunderstanding? |
|
|
|
Refer to:- Are you saying no one will mine because there will be too much competition?
|
|
|
|
this is an old theory.
if one can inject a virus signature in to the bitcoin blocks which are distributed, theoretically you can get antivirus software to remove a large chunk of the nodes online, reducing the distribution of the network and perhaps making a 51% more feasible. It's been discussed for years.
realistically, mining has become quite centralized at major pools with specialized hardware, the real world impact of such an attempt would be little more than a minor annoyance for some non technical users, and be of no gain to anybody.
Can I ask how mining being centralized changes anything? The attack is still just as valid, include a detected signature in a valid transaction, and, it'll be mined by miners (Other than yourself). |
|
|
|
|
And then get mugged in the street?
Have to pay for special hardware to be able to decode this stuff?
Only have a limited amount of seeds per-person?
Being able to be tracked by any entity that can force you to validate yourself?
I'm good.
|
|
|
|
Don't mind doing that. My question, is , HOW? I can't find any commands to do that....
%appdata%\Armory %appdata%\Bitcoin |
|
|
|
God dammit, I probably should read the whole page before giving up  Anyway, not had a chance to actually test anything since (Eating something at the moment), but, can I confirm, if I wanted to do '0x0103', I should do 0xfd0301? EDIT:- Finally finished my TV show and food, I can confirm it was as I thought, thanks! 01000000014665a822ecf6c9741c6646b244e571ba305f18f3665f707ef5aea0f29d78fa99010000000100ffffffff01107a070000000000
fd0301
4c
ff
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
76
88
00000000 |
|
|
|
https://en.bitcoin.it/wiki/Protocol_specification#txField size:- 1+ How on earth do I actually mark it as greater than one? I tried just throwing another byte in there, but, that results in errors, I have this commented transaction so far:- 01000000014665a822ecf6c9741c6646b244e571ba305f18f3665f707ef5aea0f29d78fa99010000000100ffffffff01107a070000000000 //boring transaction stuff
07 //0x07 bytes script
4c //0x4c states "next byte defines how many bytes I should push to the stack"
03 //0x03 bytes
8f7a3c //Those 0x03 bytes, 0x8f, 0x7a, and, 0x3c
76 //OP_DUP
88 //OP_EQUALVERIFY
00000000 //More boring transaction stuff (locktime) Which, results in:- {
"hash": "5e4a2e55b8c21d491749d1009f568192e211fa931e78af343675fedf2371041d",
"ver": 1,
"vin_sz": 1,
"vout_sz": 1,
"lock_time": 0,
"size": 68,
"in": [
{
"prev_out": {
"hash": "99fa789df2a0aef57e705f66f3185f30ba71e544b246661c74c9f6ec22a86546",
"n": 1
},
"scriptSig": "OP_FALSE",
"sequence": 4294967295
}
],
"out": [
{
"value": "0.00490000",
"scriptPubKey": "8f7a3c OP_DUP OP_EQUALVERIFY"
}
]
}However, like I said, I can't for the life of me work out how to increase the scriptPubKey to > 0xFF, imagine I have this:- 01000000014665a822ecf6c9741c6646b244e571ba305f18f3665f707ef5aea0f29d78fa99010000000100ffffffff01107a070000000000 //boring transaction stuff
0301 //(0x07 + 0xff - 0x03) bytes script, 0x0103, bytes reversed to 0x0301.
4c //0x4c states "next byte defines how many bytes I should push to the stack"
ff //0xff bytes
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa //Those 0xff bytes, a bunch of 0xAA
76 //OP_DUP
88 //OP_EQUALVERIFY
00000000 //More boring transaction stuff (locktime) Results in:- {
"hash": "a530ba3415952af7ed24f297fea7570219f401046fb50ac01d4c773bd2101bd0",
"ver": 1,
"vin_sz": 1,
"vout_sz": 1,
"lock_time": 2863311530,
"size": 64,
"in": [
{
"prev_out": {
"hash": "99fa789df2a0aef57e705f66f3185f30ba71e544b246661c74c9f6ec22a86546",
"n": 1
},
"scriptSig": "OP_FALSE",
"sequence": 4294967295
}
],
"out": [
{
"value": "0.00490000",
"scriptPubKey": "4c "
}
]
}If I don't switch the bytes around for byte script length:- 01000000014665a822ecf6c9741c6646b244e571ba305f18f3665f707ef5aea0f29d78fa99010000000100ffffffff01107a070000000000 //boring transaction stuff
0103 //(0x07 + 0xff - 0x03) bytes script, 0x0103, bytes reversed to 0x0301.
4c //0x4c states "next byte defines how many bytes I should push to the stack"
ff //0xff bytes
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa //Those 0xff bytes, a bunch of 0xAA
76 //OP_DUP
88 //OP_EQUALVERIFY
00000000 //More boring transaction stuff (locktime) Equals:- {
"hash": "68ceb346c7711a74f31b8a285014ee08a58050480f69c5ee97cc75e803cf1c2e",
"ver": 1,
"vin_sz": 1,
"vout_sz": 1,
"lock_time": 2863333196,
"size": 62,
"in": [
{
"prev_out": {
"hash": "99fa789df2a0aef57e705f66f3185f30ba71e544b246661c74c9f6ec22a86546",
"n": 1
},
"scriptSig": "OP_FALSE",
"sequence": 4294967295
}
],
"out": [
{
"value": "0.00490000",
"scriptPubKey": ""
}
]
}Any help on making scripts > 0xFF? All I'm currently getting is it overflowing into lockTime.
|
|
|
|
Imagine anti-virus A detects "0xAABBCCDEEFF" as a virus, okay? I submit a transaction which has the script, simply:- 0xAABBCCDDEEFF OP_DUP OP_EQUALVERIFY At this point, basically, you're sending "0xAABBCCDDEEFF" to the mempool, duplicating it (OP_DUP), testing if 0xAABBCCDDEEFF and itself (OP_DUP) are the same, if so, the transaction is valid. So, now it's a valid transaction, it'll be mined, and, it'll be put into the blockchain, this is where issues occur, suddenly, everybody who is running that anti-virus suddenly gets a warning, and, their antivirus starts quarantining the blockchain!What's to stop this from occurring? It may cost an attacker a mBTC or so to actually pay for a transaction with a virus binary attached to it (As it'll probably be a few tens of KB), but, until the anti-virus vendor manually marks the blockchain as not a virus, surely it'll show up in a scan-time scan (And maybe even runtime, as, Bitcoin-QT will have "0xAABBCCDDEEFF" in memory). |
|
|
|
Fair enough. Although now if you get bored, you can be the person who codes up a simple web service that stores locktimed transactions and broadcasts them when appropriate. :-)
But then people have to trust me to broadcast 'em, isn't the whole point of bitcoin peer to peer implementations to not rely on any single person  Anyway, it'd be very simple to do, I would do it, but, the issue is that I couldn't guarantee uptime of months on months (Which, I know some people would want, to say "I want this broadcasted in X months/years"), so, I'm not going to. |
|
|
|
|
Show Posts
