so you want to basically do 3 steps:

1.) base58decode the address
2.) remove last 4 Bytes (this is a checksum)
3.) remove first byte (this is network identifier)

There are many tools out there, but you didn't tell us, what operating system you use.
On https://rosettacode.org/wiki/Bitcoin/address_validation are many different address validators, see if this fits your needs.
The bitcoin explorer provides as well a decode function: https://github.com/libbitcoin/libbitcoin-explorer/wiki/bx-base58check-decode
And there was also a Perl version: http://lenschulwitz.com/base58

Not sure if a final tool exists, that picks up your somehow formatted list, and converts it, but with a little bit coding know-how, the links above will do :-)

A warm welcome to the world of crypto currencies, we need more developpers.

There's no such thing as a "best place"... It is always different, and somewhere else 
But there are learning sources, next to bitcoin.org, as the reference page.
And the world doesn't stop with bitcoin, there's the whole altcoin world.

I had it very easy to get started, after reading Andreas book "Mastering Bitcoin", which is available in many languages, and can be read online.
bitcoin.stackexchange.com is a webpage, that serves as a Q&A forum, and many, many technical questions are answered there, especially when it comes to details of how to construct transactions.

And then it depends, what you want to program. A web page accepting coins - good start! A wallet software? This is a task, which requires serious knowledge on crypto and security. Usually you need some years of experience in this area to start building a secure wallet. A whole new crypto coin? Phew :-)

I am uncomfortable with "they". Too many people here say they should/they must, so that I can ... Why they? Anything that is contributed? Have you supported the community with code to resolve GUI issues? Would you pay the developper for your requirement?

Pieter Wuille explained in a stack exchange task, that since version 12 the bitcoin core software can expire transactions, which are longer than 72 hours in the mempool. This would keep the mempool fresh.

I am asking myself, why this is the third question of this crazy construct within this week... coincidence?

So: why would the miners accept this? When they know, that afterwards the currency is out of value?
They can't even use the remaining hardware to mine other coins, cause they know, that history shows, when bitcoin goes down, all other currencies go down - and vice versa.
The incentive for the miners is not recognizable.

Besides that nobody knows, how many miners there are (yes, there are pools, but then what?), you would need +8billion to bribe the miners. 16 billion is the amount of newly generated bitcoins at a rate of 10.000 Euro/CHF/USD ...
To whom would go the transactions of this size? To an exchange? to a bank? Who would be your counter party? Who is going to loose the large amount, if you take "your" transaction back with the miners after 15 blocks?
I guess, nobody takes a risk, that is higher than everything else that have been seen before? An alien bank perhaps, that doesn't care, if they loose 16billion?

This is not an attack on bitcoin currency. This is an attack construction, which has no visible chance of getting realized. As such the headline and the word "attack" is highly misleading.

not sure how to get to the gurus - usually in such forums there are, or I heard, that there is a bitcoin IRC chat.
But hey, gurus don't work on assumptions! 
I can see the theoretical approach, yes. What makes it a bit complicated, is that there are so many conditions around it, that the attack is not visible anymore. And if these surrounding conditions are true, then you can "bribe" any secure system, be it PoW or anything else... This goes into a trust discussion.
In bitcoin/crypto currencies there is an underlying mathematical model on game theory and encryption. I think you need to start talking this language, to get a proper answer. So something like a mathematical calculation of the things happening in your approach.

I wouldn't like to see this.  
Maybe you can first of all explain, what you think can be achieved with smart contracts on bitcoin.
Then explain, what you think, why a complete turing machine is required to do a smart contract (use cases?).
Then what you have done / tried to do with bitcoin, and why it wouldn't fit, and hence the need for a turing complete EVM comparable environment.
Why not do it in a side chain, and proof, that it works (ehm, eh, it doesn't in Ethereum, repeatedly - we'd like to be secured with our funds).

Just because it's technically feasable? Certainly not a good start...

most people read both forums  

this one here is better to have discussions going back and forth.
I'd add two things: bitcoin was structured in a way, that game theory-wise it is more beneficial to particpate in the game, than trying to play against it.
Renlord has a similiar wording in his reply.
I have an issue with your idea of majority attack:
they would not be higher. Currently there is a hashing power of the equivalent to roughly 800.000 mining boxes type "AntMiner S9". This is making the network is stable, resistant and protected. For a 51% attack you'd need to buy 400.000, and bring them on the network (their power cosumption is 1200W, so you'd need a coal or gas power plant, industrial grade level). If you want to "buy" the miners (bribe), then it requires a lot of communication to them, and a financial incentive. Would the miners follow the fork (bribe), if they can see, that they will loose the value of the bitcoins to be mined? I mean, after such an attack would have worked out, the value of bitcoin would run against zero (quickly). What is the remaining incentive for a miner?
Your one-time bribe would maybe need to be equivalent to a 1 year income of a miner, and this for 51%. So your invest would need to be in the billion range. Current 12,5BTC reward is ~10.000 EURO/CHF/USD, 6 per hour, 21 per day is 18mio a day. And you need 51% of miners. So who would "accept" your initial transaction, that you even could spend it later on?

So from "my" logic, a 51% attack the way you described it, seems not feasable.

But maybe there are some experts here, who have a sound knowledge and better understanding?

not sure if this is going to be a comedy (or a hoax?)

@honadu:
you are a new member in the forum, and your question is way too short, and also lacks a "common sense" of information.
Your last link with the tx ID is invaluable information, cause this tx happened 8 years ago as a coinbase tx. It's output is a public key, which transforms to this address: 12bAezJkUhUxUDVZUypN9HP7obfWm58hSw - definitely something else than your first post.

You might want to step back, rethink what you want to ask, and if english is not your native language (neither it is mine), take someone to give you a helping hand and try to rephrase precisely, what you need.
This would start with what you have (equipment/software), what you have done (sent tx and dates), and what you are looking for (probably some funds).
This would make it easy for us to help.

this ?


which is base58 encoded: 16rCmCmbuWDhPjWTrpQGaU3EPdZF7MTdUk

which points to an address with 100.000s of bitcoins, which probably belong to an exchange...
btw: you may want to remove the "!", this looks offending.
Also it would be better to provide the transaction ID, then people can better help out.

I see, you are worried about the use case.
But yes, looking at the values, this is quite some money today. I know that exchanges take of a lot of their inputs into cold storage.
But as the previous op said, without knowing the details, it is highly speculative.

and can the headine please be changed to something like "I don't undersand why base58decoding returns different values"?
And also get these annoying fire symbols removed ...
Maybe moderators can change this.

it is simply a very large tx with many, many inputs, sent to a single output. A typical usecase can be imagined this way:
you have a shop, where you sell daily products against bitcoins to your never changing bitcoin address, and at the year end (after 1000 or more tx) you consolidate everything into cold storage... of course hundreds of more thinkable use cases.
These type of tx are quite normal, just here the size is tremendous.

To get an idea how tx work, you may want to look into bitcoin.org (into the developper section), or I recommend the book "Mastering Bitcoin" from Andreas, which is also online available.

I took a quick look at the second sig, and the length field of the signature for R-value:


I can see a double zero is there, so the length of the R-Value should be 21hex, 33 bytes decimal. In you case it would end with "02".
However: the 02 should be the  type tag indicating length for S-Value, and 21 the length for your S-Value (which it is...).
I just added a "DD" into the end of the R-Value, then it decodes correctly:


So I guess the library you are using is not assembling the signatures correctly. What are you using?

if there is something of value for you, that you want to buy, then make sure upfront, that mothing can happen, and don't trust the vendor. Easy as this. In the bitcoin world you use an "escrow service", which is realized with multisig. Searching the forum for "escrow" will guide you in the right direction.
Oh, you might turn your headline into "a very, very small problem with cryptocurrency used in ecommerce !!!"

can you maybe outline a bit, what you expect to see, or what makes you so suspicious that you identified a hash160 problem?

I posted my answer as well on your question in stackexchange...

https://bitcoin.stackexchange.com/questions/63489/why-is-scriptsig-filled-with-scriptpubkey-before-signing-a-transaction/63519#63519

Looks like the formatting is a bit shuffled, can't get it clearly.
This is what I understand happens on the stack for a multisig P2SH tx (I ignore the 0 at the beginning for the CHECKMULTISIG bug):


So when I want to unlock the tx, I drop Sig1, Sig2 and <redeem script> on the stack. Then the part of the locking script, and it gives:


(from Andreas' book "Mastering Bitcoin"):
The two scripts are combined in two stages. First, the redeem script is checked against the locking script to make sure the hash matches.

Replacing the <redeem script> and assuming the 20-byte hash of redeem script is "54c557e07dde5bb6cb791c7a540e0a4796f5e97e", we get this:


And then, if the redeem script hash matches, this will be executed:
    <Sig1> <Sig2> OP_2 PK1 PK2 PK3 OP_3 CHECKMULTISIG

oh, the reference is on pages 151ff on the second edition of the book I mentioned.

next to bitcoin.org and the developpers section and  Andreas' book "Mastering Bitcoin", this helped me alot to understand the underlying details:
http://www.righto.com/2014/02/bitcoins-hard-way-using-raw-bitcoin.html

Andreas has a very good explanation on Bitcoin Transactions in his book "Mastering Bitcoin", which is also online readable: file:///Data/Crypto_CCY/Mastering_Bitcoin_2nd.pdf

There is page 141ff for the tx part, and beginning with 151ff he explains the use case for P2SH in detail for multisig purposes.