before segwit is released someone can make a segwit tx. where the witness data is not part of the transaction.
Yes, but only for spending from an output of the type OP_0 <20 bytes> or anything similar. The witness data must still be in the transaction when you are spending from an output that has anything like OP_CHECKSIG in the output script. i think knightdb cannot get beyond the concept that segwit is not foolproof. so its best i leave him to wallow in his small box of bug free perfect code, cushioning himself with candyfloss clouds and pink unicorns. blissfully ignorant that the world is not the dream laid out on whitepapers, while he pretends it is
have a good month everyone
I think franky1 cannot get beyond the concept of how bitcoin works and is just spouting bullshit to make himself seem better than anyone else. He simply doesn't know how bitcoin works or is trolling. New local rule: franky1 is banned from this thread from this post onwards. |
|
|
|
Just to summ up / that attack would be like that:
A miner
1) modifies his own mining code to enter already the SW link into the correct place
2) mines a BAD block NOW, Long time before SW goes live
3) Now he can do lots of real txs like spending BTC (but get back when)
4) SW goes live and all blocks down to his BAD block get orphaned and his spending from 3) are neglegted
? correct ?
Soft-forks are not enforced on the older parts of the chain. Only in blocks from two weeks after 95% of the hash-power had signaled their intent to enforce (counted over a 2016 block interval after the change start-time). For prior soft-forks, like strictder, there are many historical violations before where it was enforced. It does not make the chain invalid, only violations after the point where the new rule's enforcement begins would do so. Thanks & yes, I got that. But this soft fork happens at 4) or two weeks later. The question is, whether the new coded miners (SW enabled) will orphane the non SW chain down two that BAD block made in 2) because they will all agree that this BAD but old block is the last valid SW one since it contains the correct LAST correct SW entry? The problem is that the bad block cannot exist in the first place. You cannot spend from an output that you do not own. Segwit does not change this behavior. |
|
|
|
Strongly advise not to attempt Bitcoin pruning mode with Armory.
Not just strongly advise, but you actually can't. Armory will not work with a pruned Bitcoin Core at all. |
|
|
|
franky went on irc to try to explain his scenario. this is the part of the exchange that matters because this is wher ethe flaw in his attack is explained (and i have been giving this explanation for the past couple of pages). Franky is testicools here. testicools> ok.. lets try this from a different angle. maybe that would clarify it. i make a transaction to spend satoshis 2009 stash.. BEFORE the checkpoint. if your saying anyone can spend that transaction after i have made it.. then goodluck
<CodeShark> how do you intend to spend satoshi's 2009 stash unless you have satoshi's private keys?
<testicools> because im using segwit code before its released so the signature doesnt get validated..
<CodeShark> you still need to have valid signatures to spend satoshi's stash
<CodeShark> satoshi's stash is not held in anyone-can-spend outputs
<testicools> old clients wont see the signature area..
<CodeShark> those signatures will be in the old area
<CodeShark> to spend a nonsegwit output you use a nonsegwit input
<testicools> not if i write a segwit transaction
<sipa> that would be invalid
<sipa> he output being soent determines where the signatures go
<testicools> but sgwit transactions are not invalid because old clients just treat them as funky transactions
<sipa> the outout being soent determines where the signatures go
<sipa> you can't use a segwit transaction to spend satoshi's coins. not to old clients, not to new ones
<sipa> please read up on the design
<testicools> so no one can move coins between old and new.. that makes segwit useless ..
<sipa> yes you can
<sipa> being segwit is a per-input and per-output thing
<CodeShark> to spend a nonsegwit output you use a nonsegwit input - the transaction containing this input can still have segwit outputs
<sipa> you can have a transaction that spends from a segwit output and moves to a normal one or the other way around
<sipa> but to spend a non-segwit output, you need non-segwit input
<sipa> and the other way aroundt
|
|
|
|
I dident know anything about bitcoin was just learning on the fly so I had a blockchain walet with my coin in It and I have a coinbase account to sell what I wanna sell but I was nervous I'd send it to the wrong address n lose my 200 so I just did like a test send I dident know about dust and all that. I'm saying once it clears or goes back I'll be able to send most my coin to my coinbase account right?
Yes |
|
|
|
please advise me how to contact them for trade here using the escrow system here? need to have an escrow to minimize the risk.are those escrows trustworthy?
Just send the escrow a PM with the details of the trade. Make sure that you check the escrow's ANN thread for exact details on what you should do and what the escrow will do. The escrows listed on the OP are considered trustworthy. |
|
|
|
So worst comes to worst since I sent it 24 hrs ago by tomorrow or the next day I'll be free to resend the full amount and all
It depends on the wallet you used. Some wallets, if you leave them open, will constantly rebroadcast the transaction. This means that to have the transaction dropped from the network (and thus have the Bitcoin sent back), you will need to shut down the wallet and not open it for a few days. If you used an online wallet, it depends on the service whether they will continue to broadcast the transaction. For example, blockchain.info will drop the transaction after three days thus allowing you to respend the Bitcoin after three days if you use blockchain.info's wallet. |
|
|
|
Was my first time and I wanted to test out sending a small amount to make sure I was correct but I send one to small now it's been stuck and I can't use any other coin I have . I relize my mistake but don't know how long it will take to come back to me or go threw any thing I can do? https://blockchain.info/address/15bU6TxAtXo1Bty5UkzAwr8RqGQneyTCabYou have a dust output of 0.00000009 BTC. This is insanely small and, because it is dust, is considered non-standard. This means that it is unlikely that your transaction will confirm soon. To not be sending dust, all of your transaction's outputs need to be greater than 2730 satoshis. |
|
|
|
but how do you know that.. like i said have they tried segwit on the testnet and then had other non-segwit implementations on the same chain to see how they react..
like i said unless they are going to try everything they cannot promise everything
They will be. Prior to deployment on the mainnet, segwit will be deployed on the testnet. I do not know whether they have had non-segwit nodes on the segnet chain. It is fairly trivial though to implement a node to run on segnet and see if it works. If you think that they aren't going to test everything, why don't you help out and test things yourself? It is all publicly available. If I sold you a car radio, and claimed that it was 'backwards compatible' with your car, and then later you read the manual and discovered that it causes your airbags to no longer work, and you'd have to buy some new airbags from me as well just to be safe and secure again - you wouldn't call my radio 'compatible' with your car, would you?
Clearly that isn't backwards compatible, but that is not an analogy for segwit. |
|
|
|
It is up to the developers of the other software to follow the publicly available specs
nooo backward compatible soft fork means that segwit has be be sure to work with other implementations that already exist.. not the other way round It is backwards compatible. If the current implementations that already exist chose not to use segwit, they would be fine and can continue to function. What I meant is that if those implementations want to support segwit, it is up to them to implement it in their own software without any bugs. They can follow the publicly available documents that specify the exact changes that segwit makes. |
|
|
|
"Before being added to Bitcoin Core, it will be tested very thoroughly over several days or even weeks to make sure that it is all ready."
Is that really enough?
It is also being tested right now and has been tested for the past couple of months since the first segnet went up. With the amount of testing going on, it is enough. 4 years of thousands of people using bitcoin and they still found a bug in 2013. and 2014 and 2015 so ahandful of people now and again doing transactions in their spare time.. well it really doesnt compare. by the way reading the irc logs, you cannot really see much chatter about then trying to break it using scenarios it seems more like making sure coins arnt accidentally lost rather then purposefully trying to gain/move/create/destroy coins. try not to have blind faith in a system thats not even released. after all everything thinks windows works but i bet everyone knows what a blue screen of death is there are atleast 12 different implementations of bitcoin all wrote with different languages and multiple version.. im damn sure they are not going to test all of them to live up to the promise of bug free backward compatibility that cannot be hacked or abused. Segwit is conceptually sound. When it comes to implementation, there can be bugs, and that is what the testing is for, finding the implementation bugs and making sure that it is implemented to spec in their software. It is up to the developers of the other software to follow the publicly available specs to properly implement segwit. Also the segwit irc is #segwit-dev and that is where segwit discussion happens, not #bitcoin-dev or #bitcoin-core-dev |
|
|
|
You are misusing word "spam" here. I'm not spamming.
Also you clearly misunderstand the issue when site rep isn't answering questions
about this
Do you know what "constructive" means?
There can be positive and negative constructive feedback and questions
It does not mean "I'll fill this thread with positive nonsense". That's not constructive. That's called shilling.
Constructive means that the post is on topic and adds to the discussion that is happening in the thread. Right now, you are not being constructive. Welcome to my ignore list, don't expect any further responses. Same with twitchyseal (you're probable alt). He is probably on Roslinpl's ignore list because he keeps spamming this thread which is why he gets no response. I do ask that you take your complaints to another thread because complaints about Betcoin do not belong in the signature campaign thread. Only complaints about the sig campaign belong here, not about the service. Edit: Please note I am not a shill nor am I affiliated with Betcoin except for this sig campaign. |
|
|
|
knightdk what is your relationship with Betcoin, except that you get paid for every silly post you type?
My relationship is that I get paid. For all of my constructive posts. I'm asking questions regarding this Betcoin campaign, what kind of posts count as constructive posts,
as I'm pretty sure word "constructive" is misued there and Betcoin just wants to fill threads with hyperpositive nonsense.
Where are you getting that constructive is being misused here? I'm responding to you because I have seen you and twitchyseal (especially him) continue to spam this thread. |
|
|
|
"Before being added to Bitcoin Core, it will be tested very thoroughly over several days or even weeks to make sure that it is all ready."
Is that really enough?
It is also being tested right now and has been tested for the past couple of months since the first segnet went up. With the amount of testing going on, it is enough. |
|
|
|
I'm fairly sure questions towards Betcoin rep on public forum, where they want visibility, is fair to assk and answer questions in public. That makes roslinpl's work also here much easier.
Asking/answering questions via PM would be viable only if you want to hide questions asked.
This is a signature campaign thread, not the right place to have a discussion about Betcoin. Do that in their official thread or somewhere else, not here. That kind of stuff does not belong in this thread. Personal attacks on the people who run the site and this campaign are not going to help you. |
|
|
|
As Betcoin official representative I suppose you are here to answer question from crowd and not just fill the thread, right?
Looking forward for answers! Thanks!
Dude, please stop spamming this thread. If you want to ask roslinpl a question, do it in a PM. You are fairly off topic for this thread. BTW, the official rep for betcoin is the account Betcoin.ag. |
|
|
|
Cheers, i was thinking it was something a little more technical than that....lol
It is. In every transaction, there is a field called the scriptsig for the input. Since a coinbase transaction doesn't have an input, anything can be put in the scriptsig. Most miners will then put something in the scriptsig that identifies which miner mined that block. However, this is not guaranteed to be accurate since any miner can put any message there. It can be spoofed. The IP address of the miner/pool node that relays the block that is solved is also available and can be compared to know mining pool addresses. If you notice when it's an unknown miner who solved the block the IP is listed instead of the pool name.
No. It is not possible to know the IP address from which a block or transaction originated. Blockchain.info only lists the IP address of the first node which relayed the block or transaction to it. That node is not necessarily the node that created the block or tx. |
|
|
|
And those outputs right now do not exist, or if they do, they are intentionally created
welcome to the conversation.. like i said pages ago. a MALICIOUS pool grabs the code from testnet/github. to do exactly that.. finally i think you are piecing it all together, bravo. The code is different from actual transaction outputs. Actual transaction outputs do not exist that are the segwit output type that anyone can spend from. They can't just use that code and grab any random output to spend from like that because that isn't how it works. why the F*ck are you talking about anyone can spends.. ur obsessed with trying to make op_0 sound like op_true.. please think outside of the spoonfd mantra of the glossy magazines you have been handed i have no clue why you are trying to bring in op_true scenario's into this.. I'm not talking about OP_TRUE"s. Why the fuck do you think I am talking about those. When I refer to anyone can spend, I mean that the script is in such a way (doesn't matter how) that anyone is able to spend that output. Why don't you do as I said above and give specific examples of how exactly your attack would work. And by specific I mean writing out what the input and output scripts would look like and taking a random transaction that currently exists and explain how that works with the attack. |
|
|
|
And those outputs right now do not exist, or if they do, they are intentionally created
welcome to the conversation.. like i said pages ago. a MALICIOUS pool grabs the code from testnet/github. to do exactly that.. finally i think you are piecing it all together, bravo. The code is different from actual transaction outputs. Actual transaction outputs do not exist that are the segwit output type that anyone can spend from. They can't just use that code and grab any random output to spend from like that because that isn't how it works. |
|
|
|
When these outputs are spent by the input of another transaction, the signature is not in the scriptsig. THAT IS ALL THAT THIS DOES!
seriously you said it yourself but you are not realising what you are saying read the part i quoted you.. and realise that because OLD clients wont see the signatures because of exactly what you said.. then there does not need to be a signature.. because old clients wont validate it.. they would blindly overlook it if they seen a funky transaction in a block that has no scriptsig where it suppose to be.. so a malicious miner can just not sign it. (because they dont even have that random inputs key), knowing the rest of the network would overlook it. But only the segwit output types can be spent like that. Only p2wpkh and p2wsh do not need the signatures in the scriptsig. And those outputs right now do not exist, or if they do, they are intentionally created to be able to be spent by anyone. |
|
|
|
|
Show Posts
